From nobody Sat Jul 1 10:01:11 2017 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 73650128896 for ; Sat, 1 Jul 2017 10:01:10 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 VeranFDXHF_L for ; Sat, 1 Jul 2017 10:01:08 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 30F7A127ABE for ; Sat, 1 Jul 2017 10:01:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 88EF43B76C; Sat, 1 Jul 2017 20:01:06 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id XgKKk50Po_ut; Sat, 1 Jul 2017 20:01:06 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2DACF283; Sat, 1 Jul 2017 20:01:03 +0300 (EEST) Date: Sat, 1 Jul 2017 20:01:03 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2017 17:01:10 -0000 On Sat, Jun 24, 2017 at 12:05:44PM -0700, Eric Rescorla wrote: > On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara > wrote: > > It seems ACKs work in terms of RSNs. This generates a weirdness that > > a fragment can be known with multiple IDs, in case a packet gets > > delayed enough to trigger retransmission but the original is then > > accepted. But OTOH, retransmission at fragment granularity is useful > > with potentially "obese" messages like Certificate. > > > > This is the calculation I made as well. Note that removing aliasing in this > fashion actually is useful in measuring packet loss (this is what QUIC > does). IMO, since handshake only occurs once per connection and DTLS needs to be implemented on all kinds of constrained devices (on both client and server sides), simplicity is more important than performance. Also, packet loss estimates do not seem useful: There are far too few packets to get useful statistics. -Ilari From nobody Sat Jul 1 10:27:01 2017 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 761551270AC for ; Sat, 1 Jul 2017 10:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 B65nlr8OVmob for ; Sat, 1 Jul 2017 10:26:59 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 14E961201F8 for ; Sat, 1 Jul 2017 10:26:59 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id e201so46095735ybb.1 for ; Sat, 01 Jul 2017 10:26:59 -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=h0tMDWgNMLywxLo1+g3KZ1hjxEk/jDxSxsjtiek/CrA=; b=2GUI/fItTrjQFekIVayqShSd75/SFMOBavOjJqIRqrpKlnnc7UXzAkjIL+cqhWjbYS GOeItIZAJEb8tVYJiWVwgewNpwWSvJthZvNDfy8ELqtC4VROQlQRrVcJMTevn5Va4366 3C2QelaiFjmPylgH5X0/2ycLn18EjwmRbivxgyZFbyXCA9MO8K+Px2I+aM3OtYd49V/H TKF9VIobmZ7hRYhaeK8HO2LETgbSZ/7BXpwo9CNtYBcqY4N3zkJXPjV9VElXj+xsA72S lZFuSmauUTchegvEGU3yIqFqnElC8L5a3eZrdWWk/EBNRo1CDqq7Yp+utG9JMVs17CK4 lj2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h0tMDWgNMLywxLo1+g3KZ1hjxEk/jDxSxsjtiek/CrA=; b=IcNkECwSaaqGHKUeqhKYgo72qy776xen02J2PpUT8cyhm7R4RvBxGzAhUQTm5GPe+J CXUfRiLlAWfc1MmpxovNFN2w4izCEuk9UGH90XQ3+s92e+M11uq9A+OrSaIyomziC0Uw uyEDiJm61273YcZpLzroNSg899H/JLp8vaa3JPbz4IJGif50l5JAVk9pfwK8nV5GZOU4 G/kqn0YMrZDCXwzeJ+wu2AlJx8NvZOUPqAsz7DRPHRHeAP7lsYB9bKzkEUQuVxjHMRsg 4DrNbZboT+x1FDAe/SVvg7vsGMWqOXoF+haI0ZOsTjxY3kj32m4WzwHMPTlQMsD2uiXp JHRg== X-Gm-Message-State: AKS2vOwNvQSqSEK/5S3QAOV5cvuXlnTJHrvd2ObUMDhpePMEXFQ6G+Om ECKFWdw5wbQEAgWQkqqmQFFIG2r+fylw X-Received: by 10.37.162.104 with SMTP id b95mr21595408ybi.29.1498930018301; Sat, 01 Jul 2017 10:26:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 1 Jul 2017 10:26:17 -0700 (PDT) In-Reply-To: <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 1 Jul 2017 10:26:17 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19fcf848d203055344d7e0" Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2017 17:27:00 -0000 --94eb2c19fcf848d203055344d7e0 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara wrote: > On Sat, Jun 24, 2017 at 12:05:44PM -0700, Eric Rescorla wrote: > > On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > It seems ACKs work in terms of RSNs. This generates a weirdness that > > > a fragment can be known with multiple IDs, in case a packet gets > > > delayed enough to trigger retransmission but the original is then > > > accepted. But OTOH, retransmission at fragment granularity is useful > > > with potentially "obese" messages like Certificate. > > > > > > > This is the calculation I made as well. Note that removing aliasing in > this > > fashion actually is useful in measuring packet loss (this is what QUIC > > does). > > IMO, since handshake only occurs once per connection and DTLS needs to > be implemented on all kinds of constrained devices (on both client and > server sides), simplicity is more important than performance. Also, > packet loss estimates do not seem useful: There are far too few packets > to get useful statistics. > I think we definitely want to allow acknowledgements of subcomponents of messages, because otherwise you have to retransmit the entire message, which is painful in the case of the obese messages. This seems to leave one with the option of acknowledging either fragments (which we then need to invent labels for) or records (which already have labels but need a map of RSN to fragment). My feeling is that on balance the latter is a better choice, but I'll have a better sense once we've implemented.... -Ekr --94eb2c19fcf848d203055344d7e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Sat, Jun 24, 2017 at 12:05:44PM -0700, Eric Rescorla wrote: > On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> It seems ACKs work in terms of RSNs. This gene= rates a weirdness that
> > a fragment can be known with multiple IDs, in case a packet gets<= br> > > delayed enough to trigger retransmission but the original is then=
> > accepted. But OTOH, retransmission at fragment granularity is use= ful
> > with potentially "obese" messages like Certificate.
> >
>
> This is the calculation I made as well. Note that removing aliasing in= this
> fashion actually is useful in measuring packet loss (this is what QUIC=
> does).

IMO, since handshake only occurs once per connection and DTLS needs = to
be implemented on all kinds of constrained devices (on both client and
server sides), simplicity is more important than performance. Also,
packet loss estimates do not seem useful: There are far too few packets
to get useful statistics.

I think we de= finitely want to allow acknowledgements of subcomponents of
messa= ges, because otherwise you have to retransmit the entire message,
which is painful in the case of the obese messages. This seems to leave
one with the option of acknowledging either fragments (which we the= n
need to invent labels for) or records (which already have label= s
but need a map of RSN to fragment). My feeling is that on balan= ce the
latter is a better choice, but I'll have a better sens= e once we've implemented....

-Ekr
--94eb2c19fcf848d203055344d7e0-- From nobody Sat Jul 1 14:00:14 2017 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 CBBD9129AE8 for ; Sat, 1 Jul 2017 14:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 Juod0RMdNYD9 for ; Sat, 1 Jul 2017 14:00:10 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4C432124D6C for ; Sat, 1 Jul 2017 14:00:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id EF24465537; Sun, 2 Jul 2017 00:00:07 +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 Mz2DTJgOYhJB; Sun, 2 Jul 2017 00:00:03 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EDCD72313; Sun, 2 Jul 2017 00:00:00 +0300 (EEST) Date: Sun, 2 Jul 2017 00:00:00 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170701210000.ppewrje6jcpy5w2b@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2017 21:00:13 -0000 On Sat, Jul 01, 2017 at 10:26:17AM -0700, Eric Rescorla wrote: > On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara > wrote: > > > On Sat, Jun 24, 2017 at 12:05:44PM -0700, Eric Rescorla wrote: > > > On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara < > > ilariliusvaara@welho.com> > > > wrote: > > > > IMO, since handshake only occurs once per connection and DTLS needs to > > be implemented on all kinds of constrained devices (on both client and > > server sides), simplicity is more important than performance. Also, > > packet loss estimates do not seem useful: There are far too few packets > > to get useful statistics. > > > > I think we definitely want to allow acknowledgements of subcomponents of > messages, because otherwise you have to retransmit the entire message, > which is painful in the case of the obese messages. This seems to leave > one with the option of acknowledging either fragments (which we then > need to invent labels for) or records (which already have labels > but need a map of RSN to fragment). My feeling is that on balance the > latter is a better choice, but I'll have a better sense once we've > implemented.... Just noticed that DTLS allows packing multiple independent fragments into one record (and then multiple records into one packet). Which impiles that an implementation that only prcesses one message at a time is not guaranteed to even be able to generate a valid list of RSNs to ACK, in case the peer sends sufficiently twisted (but still seemingly in-spec) input. What's the alert code for dropping in-spec connection detected as attack traffic? :-) -Ilari From nobody Sat Jul 1 15:53:22 2017 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 813FB126DC2 for ; Sat, 1 Jul 2017 15:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=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 NCbhq0lgLOk6 for ; Sat, 1 Jul 2017 15:53:19 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 D144B126DFF for ; Sat, 1 Jul 2017 15:53:18 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j11so60312011ywa.2 for ; Sat, 01 Jul 2017 15:53:18 -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=h9AT9moSUHcMRFLStVGpR1n1DsfmFQIVqmIV6qPRPcY=; b=QDPnJ6b+rhs1s0Kg2/hCpDBg2uG4XaKCLyzFd5ZFxOwii7j75w2dNkeGdyF5zFJ1Cz FfsDhm/jImGmJbPhz8wPI3YGe6xEuWFa/L4rQu7p0ClG+LpP1hlFlFlHxBukZOzN0CFK /orRchTBiFxn/xtiGYRuvP8CAuZGzxvhsinPAWn9hsyVoDEsz0m1cRR4ta5/eouaZxTP 4jYRFJVk98fc8qFoa5rOwKvHxw+RmoYNd0QesUFWQWylVVyNV6e/IAOW1BvHGKPenE7q tL49FxutkurPCe4tuAhmF7y4dV5oPLpaLqBfk6qy3QRaFXubIrY+anzkBNnu+tlfauY7 IbrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h9AT9moSUHcMRFLStVGpR1n1DsfmFQIVqmIV6qPRPcY=; b=mpAScmw1dj6SO2Mg32BO2QTPRsCJbll1weFB8TC6L/5yxEupeb37cwLmy192CiuYdf rPjuEGVC/dLO6ghH8nmKrPWt4LTjJXDupEdU+r3HiMXOlFMOZ8W8sipakM0PXYgw6u1J hgqtgmUL29hExA7RUKuGu4DLN+0fo2DQFsl81m/LFqLNRzWd9Tp7+ZPLD9F3wowlm/vB omrFcWMCFeGQL+dVIzdF0OeuyAokLUSzOAzyy0DWPWcncVbSiCcuAkeziI6xjCKB1g2Z +WBg6xXxLtqYZMtjrQkZ4qNQ5PBgXepnRJ0+NeAPHU6F65AH/Ioz1DOFLm9HVXQY/RoR uQ3w== X-Gm-Message-State: AKS2vOyMff2FR9ta/sBaldOBQm6aOjZkN0KLLeEDEo91ZYc4eElXG4/0 6KgwaLQQ7iYPRFI2EJ907eZSBJ8uB7H8 X-Received: by 10.129.109.17 with SMTP id i17mr22774021ywc.3.1498949598057; Sat, 01 Jul 2017 15:53:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 1 Jul 2017 15:52:37 -0700 (PDT) In-Reply-To: <20170701210000.ppewrje6jcpy5w2b@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> <20170701210000.ppewrje6jcpy5w2b@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 1 Jul 2017 15:52:37 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114dd50e5430d7055349666e" Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2017 22:53:20 -0000 --001a114dd50e5430d7055349666e Content-Type: text/plain; charset="UTF-8" On Sat, Jul 1, 2017 at 2:00 PM, Ilari Liusvaara wrote: > On Sat, Jul 01, 2017 at 10:26:17AM -0700, Eric Rescorla wrote: > > On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Sat, Jun 24, 2017 at 12:05:44PM -0700, Eric Rescorla wrote: > > > > On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara < > > > ilariliusvaara@welho.com> > > > > wrote: > > > > > > IMO, since handshake only occurs once per connection and DTLS needs to > > > be implemented on all kinds of constrained devices (on both client and > > > server sides), simplicity is more important than performance. Also, > > > packet loss estimates do not seem useful: There are far too few packets > > > to get useful statistics. > > > > > > > I think we definitely want to allow acknowledgements of subcomponents of > > messages, because otherwise you have to retransmit the entire message, > > which is painful in the case of the obese messages. This seems to leave > > one with the option of acknowledging either fragments (which we then > > need to invent labels for) or records (which already have labels > > but need a map of RSN to fragment). My feeling is that on balance the > > latter is a better choice, but I'll have a better sense once we've > > implemented.... > > Just noticed that DTLS allows packing multiple independent fragments > into one record (and then multiple records into one packet). > > Which impiles that an implementation that only prcesses one message at > a time is not guaranteed to even be able to generate a valid list of > RSNs to ACK, in case the peer sends sufficiently twisted (but still > seemingly in-spec) input. > I'm not following how that's true. When you decrypt, you record the received RSNs and when you send an ACK you send the entire list. Then when you finish a flight, you reset the list. Can you maybe show me a sequence of events that would cause an error here? -Ekr --001a114dd50e5430d7055349666e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 1, 2017 at 2:00 PM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Sat, Jul 01, 2017 at 10:26:17AM -0700, Eric Rescorla wrote:
> On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Sat, Jun 24, 2017 at 12:05:44PM -0700, Eric Rescorla wrote: > > > On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara <
> > ilariliusvaara@welho.= com>
> > > wrote:
> >
> > IMO, since handshake only occurs once per= connection and DTLS needs to
> > be implemented on all kinds of constrained devices (on both clien= t and
> > server sides), simplicity is more important than performance. Als= o,
> > packet loss estimates do not seem useful: There are far too few p= ackets
> > to get useful statistics.
> >
>
> I think we definitely want to allow acknowledgements of subcomponents = of
> messages, because otherwise you have to retransmit the entire message,=
> which is painful in the case of the obese messages. This seems to leav= e
> one with the option of acknowledging either fragments (which we then > need to invent labels for) or records (which already have labels
> but need a map of RSN to fragment). My feeling is that on balance the<= br> > latter is a better choice, but I'll have a better sense once we= 9;ve
> implemented....

Just noticed that DTLS allows packing multiple independent fragments=
into one record (and then multiple records into one packet).

Which impiles that an implementation that only prcesses one message at
a time is not guaranteed to even be able to generate a valid list of
RSNs to ACK, in case the peer sends sufficiently twisted (but still
seemingly in-spec) input.

I'm not f= ollowing how that's true. When you decrypt, you record the received
RSNs and when you send an ACK you send the entire list. Then when yo= u
finish a flight, you reset the list. Can you maybe show me a se= quence of events
that would cause an error here?

-Ekr
--001a114dd50e5430d7055349666e-- From nobody Sat Jul 1 21:01:37 2017 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 B8FC6126CD6 for ; Sat, 1 Jul 2017 21:01:35 -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 XS8kd8DDIF_T for ; Sat, 1 Jul 2017 21:01:33 -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 42538124D68 for ; Sat, 1 Jul 2017 21:01:33 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id l13so87472931lfl.1 for ; Sat, 01 Jul 2017 21:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=UrRxo6aBkg3i+g/0PjQqzMT9fYCx2uvngqTdfQewNpM=; b=bZLzDnsuK6orQlyZ5NCHDat+KWu2/CW3LddeqZjrpbIDCn/TOcbOVfEuDD7L+wgO43 luR6H45GCQAd/Y7dmfI8DcNP01Cy2xDZbPAUMpt73ICUJkSEXaayqgZvG0tJIk5+6bLA sqRuqyW0kswX0D3UfMSfjIWIVssOKMOFoGlKr0mjATw0u7U44AYbtg9ISnRpuiJ2crUC H0r0K0BOYK+O71Txc8YFQk5SwvBTd/YioCXNkqUJ7VCXEuCwhp+LN9ZMJQs9dRhAnhis DEPNvLLeRFrJPKWBbkVgGLOU/f7K9d6MegZzBosKrCXF5Z0iM7rRDA3jhukLK4zzfiSK FhyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=UrRxo6aBkg3i+g/0PjQqzMT9fYCx2uvngqTdfQewNpM=; b=oXmX+3vbftWCCv7e888aLfQ+0wPk/p7S7f9V5dXTWeqtjBGReIqRnNiyxSZWb7id5L 3IFglHyUvf1edOtjCDUDYDfyOfj7KuhtOlXEJXjAuGWWYRVGkjU+m/MMm4VYPK12ptYk 2SIhm/ccF68pYLYG3aLzZgblMftGTkXTcn6fIdYJuIZrJQkXKn/+RFQC4EGy46Am5WlG XXg6HSCic/QWA/5n4WHg24JlVlvDBdz43Y4W9goN/sRRFsL/VlV0TC5gOfDZLSmazLct Gju+dg4v8qqSlwv2yXGU6REcidTvrsiXzl/kMQzk+eTvBdK8yBGC5LN0PaHbfPKyvdYI ivpg== X-Gm-Message-State: AIVw11022Ozj8IKoPrb+5awpH7ervAZjlpOObpSnn1iXgm+yMw+MGxy0 f4b7AEYPI3+ehTY2/P/agz2u9KLoI6Jf X-Received: by 10.25.206.203 with SMTP id e194mr1751349lfg.43.1498968091281; Sat, 01 Jul 2017 21:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Sat, 1 Jul 2017 21:01:30 -0700 (PDT) Received: by 10.46.69.84 with HTTP; Sat, 1 Jul 2017 21:01:30 -0700 (PDT) In-Reply-To: <149887161558.430.6454612018892579370@ietfa.amsl.com> References: <149887161558.430.6454612018892579370@ietfa.amsl.com> From: Martin Thomson Date: Sun, 2 Jul 2017 14:01:30 +1000 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="001a1141257e9c4fae05534db4b4" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2017 04:01:36 -0000 --001a1141257e9c4fae05534db4b4 Content-Type: text/plain; charset="UTF-8" Just a bump to -20. Not quite enough time to land a -21 version with the changes to tickets. That might happen during the hackathon. On 30 Jun. 2017 6:14 pm, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security of the IETF. > > Title : Example Handshake Traces for TLS 1.3 > Author : Martin Thomson > Filename : draft-ietf-tls-tls13-vectors-01.txt > Pages : 36 > Date : 2017-06-30 > > Abstract: > Examples of TLS 1.3 handshakes are shown. Private keys and inputs > are provided so that these handshakes might be reproduced. > Intermediate values, including secrets, traffic keys and ivs are > shown so that implementations might be checked incrementally against > these values. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1141257e9c4fae05534db4b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a bump to -20. Not quite enough time to land a -21 v= ersion with the changes to tickets. That might happen during the hackathon.=

On 30 Jun. = 2017 6:14 pm, <internet-dra= fts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Transport Layer Security of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Example Handshake Traces for TLS 1.3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mart= in Thomson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-tls13-vectors-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 36
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-30

Abstract:
=C2=A0 =C2=A0Examples of TLS 1.3 handshakes are shown.=C2=A0 Private keys a= nd inputs
=C2=A0 =C2=A0are provided so that these handshakes might be reproduced.
=C2=A0 =C2=A0Intermediate values, including secrets, traffic keys and ivs a= re
=C2=A0 =C2=A0shown so that implementations might be checked incrementally a= gainst
=C2=A0 =C2=A0these values.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-tls-tls13-vectors/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-tls-tls13-vectors-01
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-vectors-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1141257e9c4fae05534db4b4-- From nobody Sun Jul 2 00:55:30 2017 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 A677D128B93 for ; Sun, 2 Jul 2017 00:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 IFoqOb7jOHrm for ; Sun, 2 Jul 2017 00:54:22 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id DA301127444 for ; Sun, 2 Jul 2017 00:54:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 2ECB33B4E1; Sun, 2 Jul 2017 10:54:19 +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 gQBW3iuLMtgV; Sun, 2 Jul 2017 10:54:18 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D82F22313; Sun, 2 Jul 2017 10:54:16 +0300 (EEST) Date: Sun, 2 Jul 2017 10:54:16 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170702075416.7ozflgnxdo5k7gcd@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> <20170701210000.ppewrje6jcpy5w2b@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2017 07:54:25 -0000 On Sat, Jul 01, 2017 at 03:52:37PM -0700, Eric Rescorla wrote: > On Sat, Jul 1, 2017 at 2:00 PM, Ilari Liusvaara > wrote: > > > On Sat, Jul 01, 2017 at 10:26:17AM -0700, Eric Rescorla wrote: > > > On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara < > > ilariliusvaara@welho.com> > > > wrote: > > > > > Just noticed that DTLS allows packing multiple independent fragments > > into one record (and then multiple records into one packet). > > > > Which impiles that an implementation that only prcesses one message at > > a time is not guaranteed to even be able to generate a valid list of > > RSNs to ACK, in case the peer sends sufficiently twisted (but still > > seemingly in-spec) input. > > > > I'm not following how that's true. When you decrypt, you record the received > RSNs and when you send an ACK you send the entire list. Then when you > finish a flight, you reset the list. Can you maybe show me a sequence of > events that would cause an error here? I think I figured out a case that doesn't involve peer intentionally generating very dubious input: Suppose that certificate is rather big (needs spliting to four parts), and: * The server preprares its flight, giving: - RSN 2:0 -> EncryptedExtensions, Certificate part 1/4 - RSN 2:1 -> Certificate part 2/4 - RSN 2:2 -> Certificate part 3/4 - RSN 2:3 -> Certificate part 4/4, CertificateVerify, Finished. * Now, RSNs 2:1, 2:3 disappear, 2:0 and 2:2 make it through. * Client ACKs RSNs 2:0 and 2:2. * Server sees the ACK, and re-encrypts the offending packets: - RSN 2:4 -> Certificate part 2/4 - RSN 2:5 -> Certificate part 4/4, CertificateVerify, Finished. * Now, RSN 2:4 disappears, 2:5 makes it through. * Client is one-message at a time. It can't ACK anything new. RSNs 2:1, 2:3 and 2:4 are lost. RSN 2:5 can not be ACKed, because that would imply the client received CV and F, which it did not. -Ilari From nobody Sun Jul 2 07:03:15 2017 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 6A8B112EC07 for ; Sun, 2 Jul 2017 07:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 gGy0zqQMglFS for ; Sun, 2 Jul 2017 07:03:12 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id A731912700F for ; Sun, 2 Jul 2017 07:03:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 3F5873B5C4 for ; Sun, 2 Jul 2017 17:03:10 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id vlXyWwGxVJcJ for ; Sun, 2 Jul 2017 17:03:09 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C633627B for ; Sun, 2 Jul 2017 17:03:08 +0300 (EEST) Date: Sun, 2 Jul 2017 17:03:08 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2017 14:03:14 -0000 On Wed, Jun 28, 2017 at 02:15:45PM -0700, Joseph Salowey wrote: > This is the working group last call for > draft-ietf-tls-dnssec-chain-extension-04. > Please send you comments to the list by July 12, 2017. Some comments: 1) Section 3.2. Protocol, TLS 1.3: > The authentication chain will be an extension to the certificate_list > to which the certificate being authenticated belongs. Extension blocks are per-certificate. I presume the extension goes to the extension block of EE certificate? 2) Section 3.2. Protocol, TLS 1.3: I think if one refers to TLS 1.2 section, one should just call out the differences (i.e., where the server extension goes), and not duplicate parts of TLS 1.2 processing. Right now, the text can be fairly easily be misread (e.g., that the restriction on not constructing arbtirary records does not apply). 3) Section 3.4. DNSSEC Authentication Chain Data: > The resource records SHOULD be presented in the canonical form and > ordering as described in RFC 4034 [RFC4034]. What is the expected _receiver_ (i.e., client) behavior? Is the client supposed to run a canonicalization and sorting pass on the records? If the client does not do this, and the server sends noncanonical or unsorted RRset, the validation is going to fail. 4) Section 3.4. DNSSEC Authentication Chain Data: > Each RRset in the sequence is followed by its associated RRsig > record. The RRsig record is in DNS wire format as described in RFC > 4034 [RFC4034], Section 3.1. The signature portion of the RDATA, as > described in the same section, is the following: This seems to imply that all RRs that make RRSet need to be adjacent in the serialization. However, I don't see this explicitly stated anywhere. Also, 'RRsig record' or 'RRsig records'? IIRC, if ZSK is being rolled (and for DNSKEY, if KSK is being rolled), there will be two RRsig records for one RRtype. 5) Section 3.4. DNSSEC Authentication Chain Data: > The first RRset in the chain MUST contain the TLSA record set being > presented. However, if the owner name of the TLSA record set is an > alias (CNAME or DNAME), then it MUST be preceded by the chain of > alias records needed to resolve it. Is there a requirement to order the aliases in order those aliases are followed? 6) Section 3.4. DNSSEC Authentication Chain Data: > The final DNSKEY RRset in the authentication chain corresponds to the > trust anchor (typically the DNS root). This trust anchor is also > preconfigured in the TLS client, but including it in the response > from the server permits TLS clients to use the automated trust anchor > rollover mechanism defined in RFC 5011 [RFC5011] to update their > configured trust anchor. I think this is wrong. The final DNSKEY RRSet does contain the the preconfigured root key. However, it also contains other keys that are used to sign the DS records. The client needs those keys in order to validate the chain, and those keys are rotated every few months for root, instead of every N years. Furthermore, frequently the trust anchor is provisioned as a fake DS record for the root. Validating with such anchor requires sending the root DNSKEY. Real-world zone data (omitted the cryptographic line noise, and added some hilights): $ dig +dnssec -t DNSKEY . ; <<>> DiG 9.10.3-P4-Debian <<>> +dnssec -t DNSKEY . ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3623 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: . 154841 IN DNSKEY 256 3 8 <...> . 154841 IN DNSKEY 257 3 8 <...> . 154841 IN DNSKEY 256 3 8 <...> . 154841 IN RRSIG DNSKEY 8 0 172800 20170711000000 20170620000000 19036 . <...> ;; -------------------------------------------------------------------- ;; Note the "19036" near end of previous line. That field contains the ;; key checksum of the key making the signature. 19036 is the checksum ;; of the well-known IANA root key. ;; -------------------------------------------------------------------- ;; Query time: 0 msec ;; SERVER: ::1#53(::1) $ dig +dnssec -t DS fi. ; <<>> DiG 9.10.3-P4-Debian <<>> +dnssec -t DS fi. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16923 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;fi. IN DS ;; ANSWER SECTION: fi. 66181 IN DS 48592 8 2 <...> fi. 66181 IN RRSIG DS 8 1 86400 20170711050000 20170628040000 14796 . <...> ;; -------------------------------------------------------------------- ;; Note here the key checksum is not "19036", but "14796". The key ;; used is found from the . IN DNSKEY records, and rotated every few ;; months. ;; ;; Also note: DS records are special, and reside on parent side of ;; zone cut, not on child side (another special type is NS, which ;; exists on both sides of the zone cut; all other data RRtypes exist ;; on the child side). ;; -------------------------------------------------------------------- ;; Query time: 0 msec ;; SERVER: ::1#53(::1) 7) Section 4. Construction of Serialized Authentication Chains > The transport is "tcp" for TLS servers, and "udp" for DTLS servers. > The port number label is the left-most label, followed by the > transport, followed by the base domain name. So if this would be used with IETF-QUIC, the labels would be _443._tcp, which is the same as one used by HTTPS, right? -Ilari From nobody Sun Jul 2 12:30:53 2017 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 56866127136 for ; Sun, 2 Jul 2017 12:30:52 -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 gi-Z_5CVVCc9 for ; Sun, 2 Jul 2017 12:30:50 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 514C0126DC2 for ; Sun, 2 Jul 2017 12:30:50 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id j11so64389813ywa.2 for ; Sun, 02 Jul 2017 12:30:50 -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=4HXJ9BvaX68DTGeG1z1cVpMlyHAwMuJ2gP2Lc7UGNks=; b=q2Eti3K0abmCMWbobKcpNyFyG8ZJugUpAlCiIcIaVJLnEYGrgCh7SMKDlXS2BDc/+h bPSu0IMzAi87YnwlbGCUJxRGTr1m/OFiXoaPY5uBbnIP1Y5n4HrQ0LNsgSq/vEdfsKdc flMmGuWJKVfoDagI241o3bWty/HCQXcDxNRi0OWnd37Wzs4G+jXjDcr/F5ovkiuYGuQ2 Rrsia7S6pZKxkl3KVTSiNnK3+L9wu+kOnM8Ay5nBpN6enF2DU3nduhUv5Ily9Ts77XLj +kpEnsR0NjvnUhNFYf2V/ThnmtaagBR628w/AiQ5Y98A2B23hs2/7XLZJe1c8jV6PcUK nXXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4HXJ9BvaX68DTGeG1z1cVpMlyHAwMuJ2gP2Lc7UGNks=; b=oooYu5fwxj6ors0UVWw8a7oKso5eA0whtCTMBZwvEhuVREhvbFXqod7dVRj+ac65pk cPPs+mtDpPbKDAQGJSFnDSNeW9OB84ZMCNzb7quCNyTvm5+2KDnSP7a7Pk3MPiRkD31j fevv90qazvGFeMm9yJ+7ESJT/q1w8vEAVFE8t+VM1RCryIdieqdo3QoC8h6aP77wONlF NR03G9NUjPRQd9JkdD3934y6RQgXul80yeYK2sY17VuvJ2CoCzzh2ocqVL1IM5mkp8wj vaYaQpIA05/3YBRZDrhSqqEZWXx9qLlDRwL3tteg52j+yYYGUebt2SwiK6Yl5ZO4v0pw WAbQ== X-Gm-Message-State: AKS2vOwY7qPVfg97t3dSjtry7epbdSR25W39ZFuAB3xp5zrIHX4jPL35 M7KQg0/vEsYmP8krHiF4b6sMnGAnQ9A+v3o= X-Received: by 10.129.109.206 with SMTP id i197mr17924258ywc.24.1499023849579; Sun, 02 Jul 2017 12:30:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 12:30:09 -0700 (PDT) In-Reply-To: <20170702075416.7ozflgnxdo5k7gcd@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> <20170701210000.ppewrje6jcpy5w2b@LK-Perkele-VII> <20170702075416.7ozflgnxdo5k7gcd@LK-Perkele-VII> From: Eric Rescorla Date: Sun, 2 Jul 2017 12:30:09 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114dd266107f1f05535ab006" Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2017 19:30:52 -0000 --001a114dd266107f1f05535ab006 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 2, 2017 at 12:54 AM, Ilari Liusvaara wrote: > On Sat, Jul 01, 2017 at 03:52:37PM -0700, Eric Rescorla wrote: > > On Sat, Jul 1, 2017 at 2:00 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Sat, Jul 01, 2017 at 10:26:17AM -0700, Eric Rescorla wrote: > > > > On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara < > > > ilariliusvaara@welho.com> > > > > wrote: > > > > > > > Just noticed that DTLS allows packing multiple independent fragments > > > into one record (and then multiple records into one packet). > > > > > > Which impiles that an implementation that only prcesses one message at > > > a time is not guaranteed to even be able to generate a valid list of > > > RSNs to ACK, in case the peer sends sufficiently twisted (but still > > > seemingly in-spec) input. > > > > > > > I'm not following how that's true. When you decrypt, you record the > received > > RSNs and when you send an ACK you send the entire list. Then when you > > finish a flight, you reset the list. Can you maybe show me a sequence of > > events that would cause an error here? > > I think I figured out a case that doesn't involve peer intentionally > generating very dubious input: > > > Suppose that certificate is rather big (needs spliting to four parts), > and: > > > * The server preprares its flight, giving: > > - RSN 2:0 -> EncryptedExtensions, Certificate part 1/4 > - RSN 2:1 -> Certificate part 2/4 > - RSN 2:2 -> Certificate part 3/4 > - RSN 2:3 -> Certificate part 4/4, CertificateVerify, Finished. > > * Now, RSNs 2:1, 2:3 disappear, 2:0 and 2:2 make it through. > > * Client ACKs RSNs 2:0 and 2:2. > > * Server sees the ACK, and re-encrypts the offending packets: > > - RSN 2:4 -> Certificate part 2/4 > - RSN 2:5 -> Certificate part 4/4, CertificateVerify, Finished. > > * Now, RSN 2:4 disappears, 2:5 makes it through. > > * Client is one-message at a time. It can't ACK anything new. RSNs 2:1, > 2:3 and 2:4 are lost. RSN 2:5 can not be ACKed, because that would > imply the client received CV and F, which it did not. Thanks for clarifying your case. I think what you're assuming here is that when the client receives out of order handshake messages, it discards them rather than buffering them. Is that correct? In that case, yes, it should pretend it didn't get the records as well, and I think the right answer would be to not generate a new ACK and rely on the server's retransmission timer (which needs to run anyway). -Ekr --001a114dd266107f1f05535ab006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 2, 2017 at 12:54 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Sat, Jul 01, 2017 at 03:52:37PM -0700, Eric Rescorla wrote: > On Sat, Jul 1, 2017 at 2:00 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Sat, Jul 01, 2017 at 10:26:17AM -0700, Eric Rescorla wrote: > > > On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara <
> > ilariliusvaara@welho.= com>
> > > wrote:
> > >
> > Just noticed that DTLS allows packing mul= tiple independent fragments
> > into one record (and then multiple records into one packet).
> >
> > Which impiles that an implementation that only prcesses one messa= ge at
> > a time is not guaranteed to even be able to generate a valid list= of
> > RSNs to ACK, in case the peer sends sufficiently twisted (but sti= ll
> > seemingly in-spec) input.
> >
>
> I'm not following how that's true. When you decrypt, you recor= d the received
> RSNs and when you send an ACK you send the entire list. Then when you<= br> > finish a flight, you reset the list. Can you maybe show me a sequence = of
> events that would cause an error here?

I think I figured out a case that doesn't involve peer intention= ally
generating very dubious input:


Suppose that certificate is rather big (needs spliting to four parts),
and:


* The server preprares its flight, giving:

- RSN 2:0 -> EncryptedExtensions, Certificate part 1/4
- RSN 2:1 -> Certificate part 2/4
- RSN 2:2 -> Certificate part 3/4
- RSN 2:3 -> Certificate part 4/4, CertificateVerify, Finished.

* Now, RSNs 2:1, 2:3 disappear, 2:0 and 2:2 make it through.

* Client ACKs RSNs 2:0 and 2:2.

* Server sees the ACK, and re-encrypts the offending packets:

- RSN 2:4 -> Certificate part 2/4
- RSN 2:5 -> Certificate part 4/4, CertificateVerify, Finished.

* Now, RSN 2:4 disappears, 2:5 makes it through.

* Client is one-message at a time. It can't ACK anything new. RSNs 2:1,=
=C2=A0 2:3 and 2:4 are lost.=C2=A0 RSN 2:5 can not be ACKed, because that w= ould
=C2=A0 imply the client received CV and F, which it did not.


Thanks for clarifying your case. I think w= hat you're assuming here is
that when the client receives out= of order handshake messages, it discards
them rather than buffer= ing them. Is that correct? In that case, yes, it should
pretend i= t didn't get the records as well, and I think the right answer would
be to not generate a new ACK and rely on the server's retransmi= ssion timer
(which needs to run anyway).

-Ekr




--001a114dd266107f1f05535ab006-- From nobody Sun Jul 2 13:13:33 2017 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 69AD0128B4E for ; Sun, 2 Jul 2017 13:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 p5bWazgm6ISv for ; Sun, 2 Jul 2017 13:13:30 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id D95CE126B72 for ; Sun, 2 Jul 2017 13:13:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 433A13BB2C; Sun, 2 Jul 2017 23:13:27 +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 xYeHXthJWf1o; Sun, 2 Jul 2017 23:13:27 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EA9112315; Sun, 2 Jul 2017 23:13:24 +0300 (EEST) Date: Sun, 2 Jul 2017 23:13:24 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170702201324.dhfybncpih3neuo6@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> <20170701210000.ppewrje6jcpy5w2b@LK-Perkele-VII> <20170702075416.7ozflgnxdo5k7gcd@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2017 20:13:32 -0000 On Sun, Jul 02, 2017 at 12:30:09PM -0700, Eric Rescorla wrote: > On Sun, Jul 2, 2017 at 12:54 AM, Ilari Liusvaara > wrote: > > > Suppose that certificate is rather big (needs spliting to four parts), > > and: > > > > > > * The server preprares its flight, giving: > > > > - RSN 2:0 -> EncryptedExtensions, Certificate part 1/4 > > - RSN 2:1 -> Certificate part 2/4 > > - RSN 2:2 -> Certificate part 3/4 > > - RSN 2:3 -> Certificate part 4/4, CertificateVerify, Finished. > > > > * Now, RSNs 2:1, 2:3 disappear, 2:0 and 2:2 make it through. > > > > * Client ACKs RSNs 2:0 and 2:2. > > > > * Server sees the ACK, and re-encrypts the offending packets: > > > > - RSN 2:4 -> Certificate part 2/4 > > - RSN 2:5 -> Certificate part 4/4, CertificateVerify, Finished. > > > > * Now, RSN 2:4 disappears, 2:5 makes it through. > > > > * Client is one-message at a time. It can't ACK anything new. RSNs 2:1, > > 2:3 and 2:4 are lost. RSN 2:5 can not be ACKed, because that would > > imply the client received CV and F, which it did not. > > > > Thanks for clarifying your case. I think what you're assuming here is > that when the client receives out of order handshake messages, it discards > them rather than buffering them. Is that correct? Yes, that is what one message at a time means. > In that case, yes, it > should pretend it didn't get the records as well, and I think the right > answer would be to not generate a new ACK and rely on the server's > retransmission timer (which needs to run anyway). One thing to note that there is no way for either side to say: "I received _something_, but nothing useful". One could presumably trigger fast retransmit on that. However, using that to trigger fast retransmits of ServerHello might be a bit dubious... There can also be interactions with giving up on fragment transmissions (in order to limit memory usage). Suppose similar case as before, but 2:1 gets lost instead of disappearing, and is found after 2:5 is received by the client. The client will then generate second ACK, which ACKs 2:1. The server then receives the ACK and has no idea what the client is talking about, since server has dropped the state. But presumably fast-retransmits 2:4 and 2:5, now as 2:6 and 2:7 (3rd transmission for both). -Ilari From nobody Sun Jul 2 14:01:36 2017 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 C8578129AB0 for ; Sun, 2 Jul 2017 14:01:34 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 22_fcuO_NKc2 for ; Sun, 2 Jul 2017 14:01:33 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002: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 E880D129AAD for ; Sun, 2 Jul 2017 14:01:32 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id v197so24528859ybv.3 for ; Sun, 02 Jul 2017 14:01:32 -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=ciAxYL/eWXETH+c6iPZssLxfeKbhkCT4w76rb2Ok0/0=; b=WcQ0sKSBKXXe+o3Finhxm+LTHlHqoOkAktL37384fkC4CLucOhxv9sr4CI6gnRhmTq 17t0H+S9TZCLvwJSqufCJf9C9hI/59a1yJ9I6YpDW8MDiQfQ732KJg16D/ilgnlDKpeN 26cc7m8U4dfvsDWWzWesy7hnRMaRJhEVHRJSWTE+epMVkejvSx6UFLmo5hlJkN6RZW6Q vSwO3vj6ir3L+JTudmuRLtxwrmFJoqelC9dA0X2nJAIdUpNtNozQWxznRA8pcqswVPfO qHQxDc4ROOs79TrIlZ6bE0wlfmKQuncwiy1Io5Zc0EWXUc8Xd5v4AQbknFGKKqQ4eKOn RwOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ciAxYL/eWXETH+c6iPZssLxfeKbhkCT4w76rb2Ok0/0=; b=RcArjZOTX32cd8yXx7J5DzbuUnlr4NXVRk0o8bv+dJbceg0dsLqOB8KekaxkcL6Hs5 zwG3aOPu0ZHNsZqxKEnTzfckS9lwRSmFbdDAx7knGwYq0kRntFUsk7meUqC9556DARMP TnK+I/8u8DCQUucGezGKc9QYDdsKXW+hzeAdcPKewdjIUiUygk6jxpVKu7Mo0eICGYYG jdsyvUkZUQCHkke0ACBC+cGH6ji/8xYnoOvzoAVW3huNPk6nHXtY+gT8kGjn9+rByjM0 R8o+urPxfR096ZcH2623BjhJuRh26yyl5gPleKqP9CnfXeoN4QXHIqpULQ85CIRPul+r WN/g== X-Gm-Message-State: AKS2vOy5OYZtN8+sb8E8DZDEzrGaAusrqITm7s/Cj6det3D+3vEfFwPS moGRMOrFK3DrkYNsvH+Pi/JY5cH6uagzYGA= X-Received: by 10.37.48.67 with SMTP id w64mr25009072ybw.89.1499029291618; Sun, 02 Jul 2017 14:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 14:00:51 -0700 (PDT) In-Reply-To: <20170702201324.dhfybncpih3neuo6@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> <20170701210000.ppewrje6jcpy5w2b@LK-Perkele-VII> <20170702075416.7ozflgnxdo5k7gcd@LK-Perkele-VII> <20170702201324.dhfybncpih3neuo6@LK-Perkele-VII> From: Eric Rescorla Date: Sun, 2 Jul 2017 14:00:51 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114899c46f6f4205535bf40e" Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2017 21:01:35 -0000 --001a114899c46f6f4205535bf40e Content-Type: text/plain; charset="UTF-8" On Sun, Jul 2, 2017 at 1:13 PM, Ilari Liusvaara wrote: > On Sun, Jul 02, 2017 at 12:30:09PM -0700, Eric Rescorla wrote: > > On Sun, Jul 2, 2017 at 12:54 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > Suppose that certificate is rather big (needs spliting to four parts), > > > and: > > > > > > > > > * The server preprares its flight, giving: > > > > > > - RSN 2:0 -> EncryptedExtensions, Certificate part 1/4 > > > - RSN 2:1 -> Certificate part 2/4 > > > - RSN 2:2 -> Certificate part 3/4 > > > - RSN 2:3 -> Certificate part 4/4, CertificateVerify, Finished. > > > > > > * Now, RSNs 2:1, 2:3 disappear, 2:0 and 2:2 make it through. > > > > > > * Client ACKs RSNs 2:0 and 2:2. > > > > > > * Server sees the ACK, and re-encrypts the offending packets: > > > > > > - RSN 2:4 -> Certificate part 2/4 > > > - RSN 2:5 -> Certificate part 4/4, CertificateVerify, Finished. > > > > > > * Now, RSN 2:4 disappears, 2:5 makes it through. > > > > > > * Client is one-message at a time. It can't ACK anything new. RSNs 2:1, > > > 2:3 and 2:4 are lost. RSN 2:5 can not be ACKed, because that would > > > imply the client received CV and F, which it did not. > > > > > > > > Thanks for clarifying your case. I think what you're assuming here is > > that when the client receives out of order handshake messages, it > discards > > them rather than buffering them. Is that correct? > > Yes, that is what one message at a time means. > Well it could mean other things. That's why I asked. > In that case, yes, it > > should pretend it didn't get the records as well, and I think the right > > answer would be to not generate a new ACK and rely on the server's > > retransmission timer (which needs to run anyway). > > One thing to note that there is no way for either side to say: "I > received _something_, but nothing useful". Well, we could in fact use an ACK for that, which is basically what TCP does. There can also be interactions with giving up on fragment transmissions > (in order to limit memory usage). > > Suppose similar case as before, but 2:1 gets lost instead of disappearing, > and is found after 2:5 is received by the client. > > The client will then generate second ACK, which ACKs 2:1. The server then > receives the ACK and has no idea what the client is talking about, since > server has dropped the state. But presumably fast-retransmits 2:4 and 2:5, > now as 2:6 and 2:7 (3rd transmission for both). > It's not clear to me it's useful for implementations to delete state in this case. -Ekr > > > -Ilari > --001a114899c46f6f4205535bf40e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 2, 2017 at 1:13 PM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Sun, Jul 02, 2017 at 12:30:09PM -0700, Eric Rescorla wrote:
> On Sun, Jul 2, 2017 at 12:54 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > Suppose that certificate is rather big (n= eeds spliting to four parts),
> > and:
> >
> >
> > * The server preprares its flight, giving:
> >
> > - RSN 2:0 -> EncryptedExtensions, Certificate part 1/4
> > - RSN 2:1 -> Certificate part 2/4
> > - RSN 2:2 -> Certificate part 3/4
> > - RSN 2:3 -> Certificate part 4/4, CertificateVerify, Finished= .
> >
> > * Now, RSNs 2:1, 2:3 disappear, 2:0 and 2:2 make it through.
> >
> > * Client ACKs RSNs 2:0 and 2:2.
> >
> > * Server sees the ACK, and re-encrypts the offending packets:
> >
> > - RSN 2:4 -> Certificate part 2/4
> > - RSN 2:5 -> Certificate part 4/4, CertificateVerify, Finished= .
> >
> > * Now, RSN 2:4 disappears, 2:5 makes it through.
> >
> > * Client is one-message at a time. It can't ACK anything new.= RSNs 2:1,
> >=C2=A0 =C2=A02:3 and 2:4 are lost.=C2=A0 RSN 2:5 can not be ACKed,= because that would
> >=C2=A0 =C2=A0imply the client received CV and F, which it did not.=
>
>
>
> Thanks for clarifying your case. I think what you're assuming here= is
> that when the client receives out of order handshake messages, it disc= ards
> them rather than buffering them. Is that correct?

Yes, that is what one message at a time means.
=
Well it could mean other things. That's why I asked.


> In that case, yes, it
> should pretend it didn't get the records as well, and I think the = right
> answer would be to not generate a new ACK and rely on the server's=
> retransmission timer (which needs to run anyway).

One thing to note that there is no way for either side to say: "= ;I
received _something_, but nothing useful".

=
Well, we could in fact use an ACK for that, which is basically what TC= P does.


There can also be interactions with giving up on fragment transmissions
(in order to limit memory usage).

Suppose similar case as before, but 2:1 gets lost instead of disappearing,<= br> and is found after 2:5 is received by the client.

The client will then generate second ACK, which ACKs 2:1. The server then receives the ACK and has no idea what the client is talking about, since server has dropped the state. But presumably fast-retransmits 2:4 and 2:5,<= br> now as 2:6 and 2:7 (3rd transmission for both).

It's not clear to me it's useful for implementations to de= lete state in this case.

-Ekr

=



-Ilari

--001a114899c46f6f4205535bf40e-- From nobody Sun Jul 2 22:04:24 2017 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 ADBE7130A97 for ; Sun, 2 Jul 2017 22:04: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-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 sV8emuOxC-0Y for ; Sun, 2 Jul 2017 22:04:21 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 23C01130A92 for ; Sun, 2 Jul 2017 22:04:21 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id k14so13448860pgr.0 for ; Sun, 02 Jul 2017 22:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=9eJ0pAKEKOSR9iylTiSLbmX9faNPCSbyOcaPwSYf/fU=; b=dKph+Z+c8EFewGp35Wj6aOTfZSypHLOoSTQ7mTQlK87HMk9oH/3W1hiuYYO16haDsB pGFzKNOvqP2tpJ900wfe7lWhBZrsooPgNKJBK0fHtA/RLCXR7Uq8Ev/FjEyPOH7p7PK5 RfFg965UlG3E9diMXu+4Faz/JowTFZnmSBuYZ5zDr6kxeTCwNTTZh4OHhqSShpPCVMe2 WnxrnluAiSFkCGh5FnwYDLxgQmLRqdpEGwWxs29/bWDIVkYqPe2UBPyNiecmfzCyHvV+ SKPtnyvDtLKFarS2Bk6SFCLRrGEh3Wu5OMh0RPrdPkm4bfoY/VUMJgCI2rm9VVDEXPXZ umMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=9eJ0pAKEKOSR9iylTiSLbmX9faNPCSbyOcaPwSYf/fU=; b=UMUIjw19u91WkxBC/bVC8I9btHGajJhbXXpPJOfQ+0CaujoRV4gDtNSoZ/XOfJtlIZ IohlLpp9F7ZyUdqp30R+y4WYhTHwWFtOIygvt8Ern+nkqkBYXvwpSDmuvBBHQzkElLHQ Osd/hWFunQlecOEcFPpb2hcsp5XOBdRJkRlaSmSKRhPSQLW3SkNK+AEkFklBHnuNs7p7 /gJisk3Ck2gy5DfWqOuMVv+Gy0VsfhI6YN1X16uzVdDKbbb4c5DjRGxR9peYb2niyh/v wVsZViaog0vbe9rC+PM/lGJkV+EIFvqTK2MQdghAVYJYZAB85zKMUokyKvKjByS94ukL gXgw== X-Gm-Message-State: AIVw1120WZ58MTpPIupeIlc5GfpN6v7DoMBLAN+xbIxHtMj+45ZlAJHY fD9s2k+vliRB166oe70= X-Received: by 10.99.121.13 with SMTP id u13mr8445911pgc.147.1499058260484; Sun, 02 Jul 2017 22:04:20 -0700 (PDT) Received: from aspen.local (216-67-119-73-radius.dynamic.acsalaska.net. [216.67.119.73]) by smtp.gmail.com with ESMTPSA id 189sm25408550pgj.67.2017.07.02.22.04.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jul 2017 22:04:19 -0700 (PDT) To: tls@ietf.org References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> From: Melinda Shore Message-ID: Date: Sun, 2 Jul 2017 21:04:13 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XefORClLkKsa1p0qXhqEnrrbROHw7QKqc" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2017 05:04:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XefORClLkKsa1p0qXhqEnrrbROHw7QKqc Content-Type: multipart/mixed; boundary="nSVqAe31sche415Kcpo006vVCl9TEHwDH"; protected-headers="v1" From: Melinda Shore To: tls@ietf.org Message-ID: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> In-Reply-To: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> --nSVqAe31sche415Kcpo006vVCl9TEHwDH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the careful review, Ilari. It's a long weekend in the US but we'll get some proposed text out mid-to-late this week. Melinda --nSVqAe31sche415Kcpo006vVCl9TEHwDH-- --XefORClLkKsa1p0qXhqEnrrbROHw7QKqc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZWdBOAAoJELiGRpM6HoEuYHcQAJo7BPb6Ra+NBbn8iggDO8xy YTtyIXbrDHtBgM30Lh53BamE3PPzjmwomTYIBR1sw31+bqfQhEcM163Y2CBvma1I 6H1pmh3zp3zGhsBrZJ3zdrOOIQsZWWjKkK8aTmLxFnftisw1Y3zxxVR6MpJZpUe7 AYSqDA4H/LQNcTXbdMSnjp08Wn+Vkk6xIJUPQaX1T0qfxILkJ6i3D9yWv18xm6cO kbQJ1y6fY2ctBj7S0eoqjcrpdsIDC7QD/OJ0fF0D7iReZWBqMkxcOe7rcOvVUPxQ RiqO4z2imGCBmOGcRiXtz7FAjdXxrBPBpiVOs2Tz+bA1/bwiYiBfMRNgilJAQa77 z0W6hq04thNTmfzjwnAG/2YRL55W9wnhd47rg+HWZzm51Td3OCwU0GusdjIoZspp OwjdQ6RGWmxK2BDmZKbR0rJNFCHdzC4S6YsjkmKRou5tYFbRPcIE+snxGiGhZQnj K7t5Mo8r0LpZTh7WL4wOM9rhVPIeQp6p5hXWeSIQmlIk6nkXMsGNgCtCp9wpS0np QfuLn2KAd4J9lwyFLxZQlz9t0+mB/jYIZyPIEO4liGgdeUYJGV13bruvLSBR/cTV lgDWP5WRycQy2Xh+YeooyKwiY144Huh2QjWpUDXg2TCZlay60gY25TenR7aSOv+w /iH9AGsQASHRfnkvsqrk =ACgW -----END PGP SIGNATURE----- --XefORClLkKsa1p0qXhqEnrrbROHw7QKqc-- From nobody Mon Jul 3 12:36:05 2017 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 A14D6131756 for ; Mon, 3 Jul 2017 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 AmTs0KgvY-yx for ; Mon, 3 Jul 2017 12:36:00 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD9A13175E for ; Mon, 3 Jul 2017 12:35:59 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id v143so69392633qkb.0 for ; Mon, 03 Jul 2017 12:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-transfer-encoding:from:mime-version:date:message-id:subject :in-reply-to:references:to; bh=0GgmooTEzlja/dqPVA0J7+It7bVrWGvz8+NLPNg83jo=; b=S3KbmzNTEW0WZ0hqR2rn7Grpc9/53b/2Lx5fPmCphs/2Wauz35ZllEZVXONoRagpbz amOOE9VDVjA3bQ/aj2pr32zJv/H2I7hL0zByAwG1CKvHa0nxjolkATxGiXm0ziLwWTDI K8g/WrFNFTI5eAGFEA711uubjeVHuapTV3BGA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :message-id:subject:in-reply-to:references:to; bh=0GgmooTEzlja/dqPVA0J7+It7bVrWGvz8+NLPNg83jo=; b=RdIlWqDJPPOrjQpqdqpWcQwvkKr/B3TIi86hQVbzInDdxLjNlS08nujogYbKJqHG0M tI/HgByb3mqLqyAwDeLy8V+QbprTOzYaRIB+Ia4KdVKZ0yPMee4uIdbCyYU6GbeckAoB GHWJ30lmUQGTSpkrQIL+fLTBPiFvj0xTQipVG0g/jw6hVQ7pHGTeIrDRAxIASWcdpq+p dx0IxgPWwUuQApVqqNtG/lmzupkSniRImlygB5aYc727gEKOitvBWmNyhcNM89O9st1t gmhKUCfnIIhEEtj2UjowZQDwDomuuVtEHtQEnshSCSjo6yjfY6X0KBUs2983y8IV1sBk k5uQ== X-Gm-Message-State: AKS2vOzdNjeJalQa2D73sSUhwIS038rcKUvCfQ31Jw4eQEs09STNIXx8 eJBzA0rq5pA0kceKIijiog== X-Received: by 10.55.20.156 with SMTP id 28mr40647894qku.191.1499110557919; Mon, 03 Jul 2017 12:35:57 -0700 (PDT) Received: from [10.73.144.181] (mobile-166-170-30-26.mycingular.net. [166.170.30.26]) by smtp.gmail.com with ESMTPSA id b81sm9589663qkj.62.2017.07.03.12.35.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 12:35:56 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-B6FA33BD-1FBA-4D3C-8E5F-C02FBF7C3C8E From: Sean Turner Mime-Version: 1.0 (1.0) Date: Mon, 3 Jul 2017 15:35:56 -0400 Message-Id: In-Reply-To: References: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> To: Eric Rescorla , tls@ietf.org X-Mailer: iPhone Mail (14F89) Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2017 19:36:04 -0000 --Apple-Mail-B6FA33BD-1FBA-4D3C-8E5F-C02FBF7C3C8E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable It looks like we're ready to merge this PR please do so. Please note that we will redo WGLC to make ensure that the changes incorpora= ted since the 1st WGLC are the consensus of the WG. spt Sent from my iPhone > On Jun 30, 2017, at 13:23, Eric Rescorla wrote: >=20 >=20 >=20 >> On Fri, Jun 30, 2017 at 10:19 AM, Erik Nygren wrote: >>> On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla wrote: >>>=20 >>>> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk wro= te: >>>>> On 06/29/2017 03:53 PM, Eric Rescorla wrote: >>>>> I have updated the PR to match people's comments. I would like to merg= e this soon, so please get any final comments in. >>>>=20 >>>> I made a couple comments on the PR that are more appropriate for the li= st, so I'll repeat them here and hopefully get replies from the broader audi= ence. >>>>=20 >>>>=20 >>>> First off, I think we should MUST-level require servers to implement a h= ard limit on the number of replays accepted. However, it doesn't quite seem= realistic to require "MUST use either [single-use tickets] or [ClientHello r= ecording]". My preference would be "MUST use either [single-use tickets], [= ClientHello recording], or equivalently strong protection", but I don't know= what level of support we have for such a strong requirement. As an alterna= tive, I will also put out "MUST limit replays to at most the number of endpo= ints capable of accepting connections for a given identity, and SHOULD provi= de even stronger replay protections, such as [single-use tickets] or [Client= Hello recording]." I think we have general agreement that strong anti-repla= y as described in the document is feasible for a single-server deployment, a= nd this last formulation is achievable in multi-server environments by just g= iving each server its own local per-server protection. (My main reason for w= anting a MUST-level hard cap is that I worry that millions/billions of repla= ys will have really nasty consequences in terms of DoS and side channel issu= es.) >>>>=20 >>>> But, this has been quite a long thread spread out over multiple forums/= email subjects, so I've also probably forgotten some of the arguments presen= ted against having MUST-level strong anti-replay requirements; I'd greatly a= ppreciate if someone could repeat them here for everyone's consideration. >>>>=20 >>>>=20 >>>> The pull request also has some text: >>>>=20 >>>> +If the expected arrival time is in the window, then the server >>>> +checks to see if it has recorded a matching ClientHello. It >>>> +either aborts the handshake with an "illegal_parameter" alert >>>> +or accepts the PSK but reject 0-RTT. If no matching ClientHello >>>> +is found, then it accepts 0-RTT and then stores the ClientHello for >>>> +as long as the expected_arrival_time is inside the window. >>>> +Servers MAY also implement data stores with false positives, such as >>>> +Bloom filters, in which case they MUST respond to apparent replay by >>>> +rejecting 0-RTT but MUST NOT abort the handshake. >>>>=20 >>>> I am not sure why we are giving servers a choice between aborting and a= ccepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), e= specially not without giving guidance as to why they might choose one or the= other. My natural inclination would be to have the expected behavior be to= abort and only fall back to the other behavior if using a scheme with false= positives, but Ekr thinks Erik Nygren was in support of just continuing on w= ith 1-RTT. It looks like this was https://github.com/tlswg/tls13-spec/p= ull/1005#discussion_r114924733 , where I ... took the opposite position from= what I just said my "natural inclination" was, amusingly enough. But still= , why does this need to be a choice? Rejecting 0-RTT and continuing on to 1= -RTT seems like it would be reasonable in all the cases mentioned so far. >>>=20 >>> Well, my reason for not wanting to do that is that it's a clear replay a= nd so should >>> be a hard failure. So, I'd be happy to mandate abort the handshake, but i= f we can't >>> agree on that, I'd rather have a choice. >>=20 >> Are there scenarios where the duplication might be accidental rather than= a malicious attack? >> For example, one might see cases where combining 0RTT with TFO and networ= k packet >> duplication could result in two initial 0RTT flights. One could also see= "TCP accelerator" >> middleboxes doing similar things where the first flight gets replayed. >=20 > Sure, and this is a good reason to hard fail because it helps us find stuf= f like that. >=20 >=20 >> In both of these cases, only one will actually successfully establish a T= LS connection >> and move forwards, but if the successful one is the one that is aborted t= hen=20 >> the connection will fail. >=20 > Sure, though of course clients can also retry. >=20 > -Ekr >=20 >=20 > =20 >> If 0RTT is rejected and both are allowed to proceed, >> then the bogus accidental replay will be dropped and the legit connection= will succeed. >>=20 >> Erik >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-B6FA33BD-1FBA-4D3C-8E5F-C02FBF7C3C8E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It looks lik= e we're ready to merge this PR please do so.

Please note that we will redo W= GLC to make ensure that the changes incorporated since the 1st WGLC are the c= onsensus of the WG.

spt

Sent from my iPhone

On Jun 30, 2017, a= t 13:23, Eric Rescorla <ekr@rtfm.com&= gt; wrote:


=

On Fri, Jun 30, 20= 17 at 10:19 AM, Erik Nygren <nygren@akamai.com> wrote:
On Fri, Jun 30, 2017 at 12:53 PM, Eric= Rescorla <ekr@rtfm.com> wrote:

On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <bkaduk@akamai.com>= wrote:
=20 =20 =20
On 06/29/2017 03:53 PM, Eric Rescorla wrote:
=20
I have updated the PR to match people's comments. I would like to merge this soon, so please get any final comments in.

 I made a couple comments on the PR that are more appropriate for the list, so I'll repeat them here and hopefully get replies from the broader audience.


First off, I think we should MUST-level require servers to implement a hard limit on the number of replays accepted.  However, it doesn'= t quite seem realistic to require "MUST use either [single-use tickets] or [ClientHello recording]".  My preference would be "MUST= use either [single-use tickets], [ClientHello recording], or equivalently strong protection", but I don't know what level of support we have for such a strong requirement.  As an alternative, I= will also put out "MUST limit replays to at most the number of endpoints capable of accepting connections for a given identity, and SHOULD provide even stronger replay protections, such as [single-use tickets] or [ClientHello recording]."  I think we have general agreement that strong anti-replay as described in the document is feasible for a single-server deployment, and this last formulation is achievable in multi-server environments by just giving each server its own local per-server protection.  (My main reason for wanting a MUST-level hard cap is that I worry that millions/billions of replays will have really nasty consequences in terms of DoS and side channel issues.)

But, this has been quite a long thread spread out over multiple forums/email subjects, so I've also probably forgotten some of the arguments presented against having MUST-level strong anti-replay requirements; I'd greatly appreciate if someone could repeat them here for everyone's consideration.


The pull request also has some text:

+If the expected arrival time is in the window, then the server
+checks to see if it has recorded a matching ClientHello. It
+either aborts the handshake with an "illegal_parameter" alert
+or accepts the PSK but reject 0-RTT. If no matching ClientHello
+is found, then it accepts 0-RTT and then stores the ClientHello for
= +as long as the expected_arrival_time is inside the window.
+Servers MAY also implement data stores with false positives, such as
+Bloom filters, in which case they MUST respond to apparent replay by
+rejecting 0-RTT but MUST NOT abort the handshake.

I am not sure why we are giving servers a choice between aborting and accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), especially not without giving guidance as to why they might choose one or the other.  My natural inclination would be to have the expected behavior be to abort and only fall back to the other behavior if using a scheme with false positives, but Ekr thinks Erik Nygren was in support of just continuing on with 1-RTT. = ; It looks like this was https://github.com/tlswg/tls13<= wbr>-spec/pull/1005#discussion_r114924733 , where I ... took the opposite position from what I just said my "natural inclination" was, amusingly enough.  But still, why does this need to be a choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it would be reasonable in all the cases mentioned so far.

Well, my reason= for not wanting to do that is that it's a clear replay and so should
<= div>be a hard failure. So, I'd be happy to mandate abort the handshake, but i= f we can't
agree on that, I'd rather have a choice.

Are there scenarios where t= he duplication might be accidental rather than a malicious attack?
=
For example, on= e might see cases where combining 0RTT with TFO and network packet
=
duplication could result in two initial 0RTT flights.  One could a= lso see "TCP accelerator"
middleboxes doing similar things whe= re the first flight gets replayed.
<= div>
Sure, and this is a good reason to hard fail because it h= elps us find stuff like that.


In both of these cases, only one will actually successful= ly establish a TLS connection
and move forwards, but if the su= ccessful one is the one that is aborted then
the connection w= ill fail.

Sure, thou= gh of course clients can also retry.

-Ekr


 
&nb= sp; If 0RTT is rejected and both are allowed to proceed,
then t= he bogus accidental replay will be dropped and the legit connection will suc= ceed.
=

 &nb= sp;      Erik


=


____________________= ___________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/lis= tinfo/tls
= --Apple-Mail-B6FA33BD-1FBA-4D3C-8E5F-C02FBF7C3C8E-- From nobody Mon Jul 3 17:00:20 2017 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 CE340131804; Mon, 3 Jul 2017 17:00:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912641982.16062.7224970010245758978@ietfa.amsl.com> Date: Mon, 03 Jul 2017 17:00:19 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-21.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 04 Jul 2017 00:00:20 -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 : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-21.txt Pages : 143 Date : 2017-07-03 Abstract: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-21 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 17:11:22 2017 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 4146F1317EE for ; Mon, 3 Jul 2017 17:11:20 -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=unavailable 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 ZQ3iB2qftZFC for ; Mon, 3 Jul 2017 17:11:19 -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 589691317EF for ; Mon, 3 Jul 2017 17:02:37 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id a12so28205595ywh.3 for ; Mon, 03 Jul 2017 17:02:37 -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=yecH2VH1+4vjHkasTLU4cYhNDvp/V4nmH3mhFoMEDZo=; b=Jr0ePi3gwOxC+ipGNys3ySNSVD3dUQ5I2AdCUmvqAFgmp/tsVM5/d5qegzJgJR0F+l AkqIuyj9Mgp0dNmB87fb0N1Iw17mueidfi2wS8cQLdpRqX4/ApK+CXsGkvOXMjeDYuGO Qqj7s0CgJb/i01DbCO97Yb8DsuG6nENne/vm8w3yp3fARyryQjdqBG1f6RIWfryXt+JR sAOl0QER6SpnXTQMbuL1wE9M75br9uCH5XKCfEEHEzmjUngcOzpwExL4T/LO3j3F2zGS olSbeETfe6d2yxVb/xRgv5r7rLLE6eKFLD3o0vuXav0IlzK7btH+MgYTncKoWdb6gu2D OQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yecH2VH1+4vjHkasTLU4cYhNDvp/V4nmH3mhFoMEDZo=; b=W23qVpjlvcDZw9ykmnNlVPw714R7Wi0SuyQ0FJqlpdcDW+XjTWMOz7FxOYsPpiVdxJ pi+RhQY4nuIyHOeeaSftg2+9YmqW3R+8F5+vqLTZMBWC5nvIpSlWU7spVNXSbHG4fi2s C9Yn3Uss8r7mwQyJhKBRIfnKCxiT1oen3uZYWDOa+hqAHknRbxUjQ068H4WjgEoWP/Sw L4qPy2vGdj5C6iWC1+XtNBdfW9V9SaR/dmZt9utG+urvhvAwZ9G0rj3eL7wsyImGjYk3 2kJEprV72zAqYewsbUwmS+iVNsZcSs4obGzKP4CuqsvLcZVpldBQWyESMxmJcpHcR9Lz w6Vw== X-Gm-Message-State: AKS2vOzGsurrOPx/Xqs4t5Vbo/pzhO7G+WSxdOEFD3m6HDzXUttyD29D RKFleviPAfxOUvot0gpI5eAOhOG1M/3XE5yMQQ== X-Received: by 10.129.50.140 with SMTP id y134mr28460448ywy.312.1499126556376; Mon, 03 Jul 2017 17:02:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Mon, 3 Jul 2017 17:01:55 -0700 (PDT) From: Eric Rescorla Date: Mon, 3 Jul 2017 17:01:55 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1140932addda6e05537299bc" Archived-At: Subject: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 00:11:20 -0000 --001a1140932addda6e05537299bc Content-Type: text/plain; charset="UTF-8" Hi folks, I just published draft-21, which incorporates the discussions we've been having about 0-RTT replay. This lead to two changes: - Modifying the key derivation for PSKs so that each session ticket is associated with a distinct PSK. - Adding a very extensive description of 0-RTT nti-replay and a SHOULD-level recommendation that servers use some anti- replay mechanism that doesn't allow replay within a given zone. In addition, I have followed Richard Barnes's lead and added key transition events to the state machine. This also clarified that clients should send in-handshake alerts encrypted if they can. I wanted to call the WG's attention to one issue: Currently the extension table says that server_certificate_type goes in the Certificate message, whereas client_certificate_type does not. My reasoning for the latter is that the extensions are attached to individual certificate elements, so it was non-sensical to have a situation where you might have cert A be X.509 and cert B be PGP. I think we should just change server_certificate_type to go in EE, and then maybe in future if people want something cleverer they can add it then. I didn't want to do this without WG discussion, but I think we should and if people don't object I'll do it in a -22. This version also addresses Kathleen's AD Review. Other comments welcome. -Ekr [0] Note that this is a bit tricky when you are also streaming Early Data. --001a1140932addda6e05537299bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I just published d= raft-21, which incorporates the discussions we've
been having= about 0-RTT replay. This lead to two changes:

- M= odifying the key derivation for PSKs so that each session ticket
= =C2=A0 is associated with a distinct PSK.

- Adding= a very extensive description of 0-RTT nti-replay and
=C2=A0 a SH= OULD-level recommendation that servers use some anti-
=C2=A0 repl= ay mechanism that doesn't allow replay within a given
=C2=A0 = zone.

In addition, I have followed Richard Barnes&= #39;s lead and added
key transition events to the state machine. = This also clarified
that clients should send in-handshake alerts = encrypted if they
can.

I wanted to call = the WG's attention to one issue:

Currently the= extension table says that server_certificate_type goes
in the Ce= rtificate message, whereas client_certificate_type does
not. My r= easoning for the latter is that the extensions are attached
to in= dividual certificate elements, so it was non-sensical to have a
s= ituation where you might have cert A be X.509 and cert B be PGP. =C2=A0I
think we should just change server_certificate_type to go in EE, an= d
then maybe in future if people want something cleverer they can= add it
then. I didn't want to do this without WG discussion,= but I think we
should and if people don't object I'll do= it in a -22.

This version also addresses Kathleen= 's AD Review.

Other comments welcome.
-Ekr


[0] Note that this is a bit = tricky when you are also streaming
Early Data.
=C2=A0 = =C2=A0
=C2=A0 =C2=A0



=

--001a1140932addda6e05537299bc-- From nobody Mon Jul 3 18:39:18 2017 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 F1E86131614 for ; Mon, 3 Jul 2017 18:39:15 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 urI6Eurw9qle for ; Mon, 3 Jul 2017 18:39:14 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002: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 1854C1316A4 for ; Mon, 3 Jul 2017 18:39:14 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id f194so575808yba.3 for ; Mon, 03 Jul 2017 18:39:14 -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; bh=lXHcSn+9sI/pkrjN7kEiV7lC7d3yQFtwAWh0UyN6Ykg=; b=bjYg+y6rW1cQ/Ekw+yMgWvI5co9iQz4EG7Wxr2H7SLuBpzXSbTqKytD/2hSjFobhhp cNKqOsfyoVIo2TThi0+KoLk+J3RGfXnqSB+9epkt5M+Oc4TkasHtclVSz/9zdjomN5wF wmE903T91zUOFJ9IJpwMj6Z4Tbl4AZFQDOsMo0kkyQbeklX0udNsW3tWOj1v89FNtUpW 6d2fmpQpvGnCYGcq3OxyYXQzrNVLjDGtxCMrbzkEbUS1a6y8cGfdvaj0r0YdS58sUwak a08dxj2OYhKwA47ejML+odGMhqi4vR/yKUdOUK13QtqtBcyqWoBKtIDGScslftYQXZcW y6ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=lXHcSn+9sI/pkrjN7kEiV7lC7d3yQFtwAWh0UyN6Ykg=; b=f9fPQHi8g1NiJuXB60sWANXS9hCh6CocMhfM8VW8TKxykhisk8mqT2h0lAkgSeBsKy 5JKZccEj/A0PwFg0RhZtSmTY0vnQx1e627NJKccW/ydDGjIDH5M1ezxb0QUWArYBruni WSvbd7I21Nvzqsbyq8OA0a3yeocmAbVMk857JjOhsCaJzLKWcc5fQpaCz8g9cY/h4hzs q/bdnbWvWVMmtzI0TD8JjAA64erNkZ3zeRHPXZQZVZ5DB4By367koRd1kYFLfr4lDb50 57yRUda0QS9w0yQJolwGY4z0XCYxMUAo5xo32vg3gGC1zswfEMQkIIT6j8uiDIqlpOoR JjMA== X-Gm-Message-State: AKS2vOyaQCYIx9+5Sx1GynsYHzgsUqb0NvdmD8Z6xAAz9k8BaYbC3kOT bp/9UAOCpySk1AJWGsZdv2qeAjDp+E60vf3v9w== X-Received: by 10.37.162.104 with SMTP id b95mr30143525ybi.29.1499132352982; Mon, 03 Jul 2017 18:39:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Mon, 3 Jul 2017 18:38:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 3 Jul 2017 18:38:32 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19fcf85f11f4055373f33b" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 01:39:16 -0000 --94eb2c19fcf85f11f4055373f33b Content-Type: text/plain; charset="UTF-8" One more thing I wanted to note. The section about when you could receive prior to Finished was a bit confused. I rewrote it as follows. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection. There are two settings in which it is permitted to send data prior to receiving the peer's Finished: 1. Clients ending 0-RTT data as described in Section 4.2.9. 2. Servers MAY send data after sending their first flight, but because the handshake is not yet complete, they have no assurance of either the peer's identity or of it's liveness (i.e., the ClientHello might have been replayed). This is not intended to be a normative change but just to capture the current state, so if people think I messed it up, or have proposed better wording, please send PRs -Ekr On Mon, Jul 3, 2017 at 5:01 PM, Eric Rescorla wrote: > Hi folks, > > I just published draft-21, which incorporates the discussions we've > been having about 0-RTT replay. This lead to two changes: > > - Modifying the key derivation for PSKs so that each session ticket > is associated with a distinct PSK. > > - Adding a very extensive description of 0-RTT nti-replay and > a SHOULD-level recommendation that servers use some anti- > replay mechanism that doesn't allow replay within a given > zone. > > In addition, I have followed Richard Barnes's lead and added > key transition events to the state machine. This also clarified > that clients should send in-handshake alerts encrypted if they > can. > > I wanted to call the WG's attention to one issue: > > Currently the extension table says that server_certificate_type goes > in the Certificate message, whereas client_certificate_type does > not. My reasoning for the latter is that the extensions are attached > to individual certificate elements, so it was non-sensical to have a > situation where you might have cert A be X.509 and cert B be PGP. I > think we should just change server_certificate_type to go in EE, and > then maybe in future if people want something cleverer they can add it > then. I didn't want to do this without WG discussion, but I think we > should and if people don't object I'll do it in a -22. > > This version also addresses Kathleen's AD Review. > > Other comments welcome. > -Ekr > > > [0] Note that this is a bit tricky when you are also streaming > Early Data. > > > > > > > --94eb2c19fcf85f11f4055373f33b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One more thing I wanted to note. The section about when yo= u could receive
prior to Finished was a bit confused. I rewrote it as f= ollows.

=C2=A0 =C2=A0Once a side has sent its F= inished message and received and validated
=C2=A0 =C2=A0the Finis= hed message from its peer, it may begin to send and receive
=C2= =A0 =C2=A0application data over the connection.=C2=A0 There are two setting= s in
=C2=A0 =C2=A0which it is permitted to send data prior to rec= eiving the peer's
=C2=A0 =C2=A0Finished:

=
=C2=A0 =C2=A01.=C2=A0 Clients ending 0-RTT data as described in Sectio= n 4.2.9.

=C2=A0 =C2=A02.=C2=A0 Servers MAY send da= ta after sending their first flight, but
=C2=A0 =C2=A0 =C2=A0 =C2= =A0because the handshake is not yet complete, they have no assurance
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0of either the peer's identity or of it&#= 39;s liveness (i.e., the
=C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHello m= ight have been replayed).

This is not = intended to be a normative change but just to capture the current
state, so if people think I messed it up, or have proposed better wording,=
please send PRs

-Ekr


On Mon, J= ul 3, 2017 at 5:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

<= /div>
I just published draft-21, which incorporates the discussions we&= #39;ve
been having about 0-RTT replay. This lead to two changes:<= /div>

- Modifying the key derivation for PSKs so that ea= ch session ticket
=C2=A0 is associated with a distinct PSK.
=

- Adding a very extensive description of 0-RTT nti-repl= ay and
=C2=A0 a SHOULD-level recommendation that servers use some= anti-
=C2=A0 replay mechanism that doesn't allow replay with= in a given
=C2=A0 zone.

In addition, I h= ave followed Richard Barnes's lead and added
key transition e= vents to the state machine. This also clarified
that clients shou= ld send in-handshake alerts encrypted if they
can.

=
I wanted to call the WG's attention to one issue:
=
Currently the extension table says that server_certificate_t= ype goes
in the Certificate message, whereas client_certificate_t= ype does
not. My reasoning for the latter is that the extensions = are attached
to individual certificate elements, so it was non-se= nsical to have a
situation where you might have cert A be X.509 a= nd cert B be PGP. =C2=A0I
think we should just change server_cert= ificate_type to go in EE, and
then maybe in future if people want= something cleverer they can add it
then. I didn't want to do= this without WG discussion, but I think we
should and if people = don't object I'll do it in a -22.

This ver= sion also addresses Kathleen's AD Review.

Othe= r comments welcome.
-Ekr


= [0] Note that this is a bit tricky when you are also streaming
Ea= rly Data.
=C2=A0 =C2=A0
=C2=A0 =C2=A0





--94eb2c19fcf85f11f4055373f33b-- From nobody Mon Jul 3 18:57:51 2017 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 737B7131716 for ; Mon, 3 Jul 2017 18:57:49 -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 QPbTkFXPDs-G for ; Mon, 3 Jul 2017 18:57:47 -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 6E89A1316EC for ; Mon, 3 Jul 2017 18:57:47 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id z78so69366203lff.0 for ; Mon, 03 Jul 2017 18:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+ZmBYLb1tLvFlVEWHZ+hXu6gF/blVKOktXrLHRXUY1s=; b=OSqyX20Wyun/Q25vRQqLhk2guxIDriFyDzGMvWJ8l7GqMRubKfwp5tdEtT7RN6ARc6 1DqfWpViKS/n3JkC/ZgNNXU6iEdFQVM5xn1bT+JWJknqoGdC7kpIk2gw+b/+z7Qhp7a8 Rq8T0hhKQqhNHcXKx9XjrTG/KXo8IlULkfoxnAHg+71IsjKok2oYoN2DOoVqg7eCpBor SDEGYnL0XXm/6ZhEvMlzMeUbBVTfS9lMYXw0r++QjKWHC6u5GP3o7qTZnIdo2CFZg9vP f8OVDgEkPH/SMDYzYiqCotO0K8XQhcT22R6CucyTAgZ2Ae4XHnKHcb8mx1Z9MYGyhRGT 8btA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+ZmBYLb1tLvFlVEWHZ+hXu6gF/blVKOktXrLHRXUY1s=; b=N4sJf1Jlez/Ipq8hSNR8IB5TY4Dq/PuaubruMd92CA2T6QlQ0MeAbkfkwKEOjjJ7cY aazMTkBlqK+Og6bMC5CiDHzN3FQFNRdZyF/wRRmdfDTI3w2I7GvyDjNK5c4HTA1/l9aq CHHgek61A5SGrO5cEcJXr0qgJlJnblF25/5LlugqKd/VBrXWbcu2Wc5Q4GxSMHdHamLQ 3IX62GhtT54GrwIbQu+B9Ux86f6zAXIAsMRL95z3YPHa3mSYT+kG3Yj/4+tISf4hyrYG uU34H6U8/tZAwgkGg+e9ybgGopdi/DwOgrQh5tHF3GDos12RQyRSVBYyAZIv2YZ9iT/F 16pw== X-Gm-Message-State: AIVw113vutW5+BuzFVgq1I5pTf/SgcjjXtxBkXR17JRdgpG7CAikTc9A AHaGyCI08e87utPd6io8J8V8hbCKm7iH X-Received: by 10.46.83.7 with SMTP id h7mr1959806ljb.22.1499133465712; Mon, 03 Jul 2017 18:57:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Mon, 3 Jul 2017 18:57:45 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 4 Jul 2017 11:57:45 +1000 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 01:57:49 -0000 On 4 July 2017 at 11:38, Eric Rescorla wrote: > 1. Clients ending 0-RTT data as described in Section 4.2.9. Typo: ending. Otherwise, this matches my understanding nicely. From nobody Mon Jul 3 20:54:08 2017 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 6090B124C27 for ; Mon, 3 Jul 2017 20:54:06 -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 p-d6fDGuCUSb for ; Mon, 3 Jul 2017 20:54:03 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 9F760120726 for ; Mon, 3 Jul 2017 20:54:03 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id m84so65475072ita.0 for ; Mon, 03 Jul 2017 20:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=7nZMG753/t8Msi190QsutTxh6x7p35KhfW5dtPP6kj4=; b=NQF4RQ+4yMcZosRqilU8lRwBE0ipsJCUA1TzVhbHWyMVHE4dhIYMOyf9Hl2ASHWWDb z4u5p1vxI0U6TOmyHiY5Z+oDonY7RDkPdDaTlslFzA6LFAImZlsCrXUx+GNLL9Pcibjf 63CIKWBAd0o24l7HdnxpQfTfbwD2L0Fk32TXI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=7nZMG753/t8Msi190QsutTxh6x7p35KhfW5dtPP6kj4=; b=oM2R/osSkgyqsnAyFqcGTqoD7IYukL1hmNk9jmdQxaUdn4/v+2MNF7Ptj9uDLoL9te UviSEfjVmza34JYdasIvClp+p1RZUCQNlGMh/T4xPAvzK1eCntUI3zwJFf/0xO7SdVSb +mVxU0Vt+ZMO0GUyyoy297Mfta/XS1qHEC1RUOkMqTWy2Rq+trP6X8zGyb20Ek3RZeal 3FntxOPagMaBkcUWMeRgxNM7giXvzofgZZ5G00+/ooOxoqOs75RuxAO0+yeYY6N7CHG/ WnXBsWmcvEBu63hMmYNNQd3r6e4i/DXBphrjJyry6sTFRbSaGkuhNRYHxQvh3i3/uorf FsDw== X-Gm-Message-State: AIVw1127YJOeC3c4Gs1/Fprn9q8+6pOdjPNmUMDjaeAFGXMC4XOW92Rc 82CovXblrdNpmbp8FxrOPw== X-Received: by 10.36.71.79 with SMTP id t76mr11500465itb.118.1499140442290; Mon, 03 Jul 2017 20:54:02 -0700 (PDT) Received: from [5.5.33.37] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id g198sm7116426itb.3.2017.07.03.20.54.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 20:54:01 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com> Date: Mon, 3 Jul 2017 23:53:53 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] 2nd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 03:54:06 -0000 All, This is the 2nd working group last call (WGLC) announcement for = draft-ietf-tls-tls13 to run through July 18th. This time the WGLC is = for version -21 = (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/). Note that = this WGLC ends before the Wednesday TLS WG session @ IETF 99. Also note that this WGLC is a targeted WGLC that only address changes = introduced since the 1st WGLC on version -18, i.e., changes introduced = in versions -19 through -21. Note that the editor has kindly included a = change log in s1.2 and the datatracker can also produce diffs (for some = reason it=E2=80=99s not working for me right now). In general, we are = considering all other material to have WG consensus, so only critical = issues should be raised about that material at this time. Cheers, spt= From nobody Mon Jul 3 22:21:56 2017 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 2B284129B28 for ; Mon, 3 Jul 2017 22:21: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 bEmZIyedHXUs for ; Mon, 3 Jul 2017 22:21:53 -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 DADEE1200C5 for ; Mon, 3 Jul 2017 22:21:52 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id z78so70889381lff.0 for ; Mon, 03 Jul 2017 22:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eWEZQN7Kr7yMDrPZcnpxJ/PdrqU/2ShVJ/LdRCGeAFU=; b=pGfJxb8Vq9NQAx7ost1eENUkYDsxlqf3AVNBrR4y3ygl9v3vBGndf1nWP1WWZOM7QR nHYyD3+fldr1yvjpfqgzIbsVAtMxM6G/7gOst87pdvPJAno7VfEVfoEUpB/LawgxILs3 z/FLni78jF7m4Aa8i8gISbteAetyPyGTtj1FPdaJ+XShK6dNbgcqVKHRWHPd2v1lFwUR ChehiNyhCnUDSNRyFtBLiT45CvVOFSQpuXmpi3lDpicONkvs1qBgv1aGrk9IbiESRd8b UHS00J6I9fuNcivP6oQmfmWQzQXhFsiCnhp5cN4E77HSenbHA/s4JLmdvJsICMgoCYhX rtCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eWEZQN7Kr7yMDrPZcnpxJ/PdrqU/2ShVJ/LdRCGeAFU=; b=VZPmUvHy8Mit2yyhKJx/cExel0Blq2dFisWTeshOvtE/WMg7OyB2MWn/b6gitAHOz6 LGku6+hdDhpz3I9M3dY8bBNfDl+8Ppme5oKns/L9xnKmJYkxJaTJYS2zD5B74yVfeaXO oBdkq1rgO95O3UQeNtVPR6seWgYoiVqY5fBqdMC58CjLkfbTMMOSd3ktkF514f9Xk040 yIezqhD33EoL6T2n1RlSih7aQsIRJ4eZC0Z/y35WccpxLr3iMWHKCnsHO/S7TDMs+aU6 EKHWGgVP9E8JSWp6tv6g1ncwqy+6CJKV74i0B2XJIY2lGoCbIA63/1/4se9hkRg5mzAb +zhg== X-Gm-Message-State: AIVw112P0d2AKTNe/ind9t+LIsoRW17/XSAO+CTlhi98ou2SpITntuXa vfdnL8YoQ+fD7rs6TKRN7Y6sulFEb/agrRU= X-Received: by 10.25.206.203 with SMTP id e194mr4424345lfg.43.1499145711084; Mon, 03 Jul 2017 22:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Mon, 3 Jul 2017 22:21:50 -0700 (PDT) In-Reply-To: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com> References: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com> From: Martin Thomson Date: Tue, 4 Jul 2017 15:21:50 +1000 Message-ID: To: Sean Turner Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 05:21:55 -0000 I think that everything IETF is a little bit slow today, which I'm sure has nothing at all to do with the draft submission deadline. https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf-= tls-tls13-18.txt&url2=3Dhttps://tools.ietf.org/id/draft-ietf-tls-tls13-21.t= xt I have reviewed the diff and found a few extremely minor nits that I'll send in a PR. On 4 July 2017 at 13:53, Sean Turner wrote: > All, > > This is the 2nd working group last call (WGLC) announcement for draft-iet= f-tls-tls13 to run through July 18th. This time the WGLC is for version -2= 1 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/). Note that this= WGLC ends before the Wednesday TLS WG session @ IETF 99. > > Also note that this WGLC is a targeted WGLC that only address changes int= roduced since the 1st WGLC on version -18, i.e., changes introduced in vers= ions -19 through -21. Note that the editor has kindly included a change lo= g in s1.2 and the datatracker can also produce diffs (for some reason it=E2= =80=99s not working for me right now). In general, we are considering all = other material to have WG consensus, so only critical issues should be rais= ed about that material at this time. > > Cheers, > > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 3 22:24:04 2017 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 B46FC131817 for ; Mon, 3 Jul 2017 22:24:02 -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 LggAX7ZxQY6n for ; Mon, 3 Jul 2017 22:24:00 -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 59B4C1200C5 for ; Mon, 3 Jul 2017 22:24:00 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id z78so70907845lff.0 for ; Mon, 03 Jul 2017 22:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xHcOFXR26tPgErQy4Y9JTe1QbZTp5kCCsl9vqAMO/Ug=; b=Hdmd+s8fa/XLU2ra/F7mNwRZeURHvMqjcX937TD52yOb9oUaVv77AWHT/treOeF/BV n4urZjtH/GhXU4Ak4OHw3AaDgkLSXFwltMzPh6fu1g4wN81ABgVmbT+GzM3w4ioBqTaW gcHmW9jAt9pCH4qTUPfz6k69LyB2w3Dr1KgH/53xHzRUUIMqsFcT6U/VAFzwvfPy42PO sqCl0dVjG1jCKtL/u5Z8dmWhzDs39OPhzElxy35demKAGPhDfHzcpu9gz001A3MYygpY Hxk4tiUSWt6lwe8e158WiQQi/kDZ8PXllfdwEqbIRxY82q1te/5DqacLm0wg41H27ztg lfoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xHcOFXR26tPgErQy4Y9JTe1QbZTp5kCCsl9vqAMO/Ug=; b=FVKrPdi2jI6mpANb09/uls6H1YmScly4egJt82JL+GQpjRwmh0zoeCNRjuMbg62R4e GilOflw0uD1QCHjxtKXyISzq4jNpIcfgvFRR53BTAvwuT76iueXpV3Io/Mq5YCToMVaW +0R8V8VQtG56UBRiF1kUVHWq8wMptAj52ktzShT1ELkR0i9hM4rGHs3XqzrK4X/4FWDk C2OuOBToHuKcw2AyBBzbx/JOrTRXAsYNLNT+zjga6Wr2GOYC3d9XVMOJF2kHh5sb6Rpm ZL+wwwG8H9hmvLWXfb0b8YfyxpBxbZ5RmJIdM77D3gelyZaaXdOBS8MJF/YSHPMMLXRs /a8w== X-Gm-Message-State: AKS2vOw42k4uvOlOtBsh/49p/qQp1zkZod9RbE/Xb3yt04IhxuzUkgbt BntLqs/ALODo6x0mrAQp0oYnDtESMb7U X-Received: by 10.25.148.81 with SMTP id w78mr12349526lfd.169.1499145838449; Mon, 03 Jul 2017 22:23:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Mon, 3 Jul 2017 22:23:57 -0700 (PDT) In-Reply-To: References: <149887161558.430.6454612018892579370@ietfa.amsl.com> From: Martin Thomson Date: Tue, 4 Jul 2017 15:23:57 +1000 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 05:24:03 -0000 One thing that we discovered is that NSS doesn't correctly pickle the hash after HelloRetryRequest. Obviously that makes the corresponding example incorrect. On 2 July 2017 at 14:01, Martin Thomson wrote: > Just a bump to -20. Not quite enough time to land a -21 version with the > changes to tickets. That might happen during the hackathon. > > On 30 Jun. 2017 6:14 pm, wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Transport Layer Security of the IETF. >> >> Title : Example Handshake Traces for TLS 1.3 >> Author : Martin Thomson >> Filename : draft-ietf-tls-tls13-vectors-01.txt >> Pages : 36 >> Date : 2017-06-30 >> >> Abstract: >> Examples of TLS 1.3 handshakes are shown. Private keys and inputs >> are provided so that these handshakes might be reproduced. >> Intermediate values, including secrets, traffic keys and ivs are >> shown so that implementations might be checked incrementally against >> these values. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-01 >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 4 01:47:29 2017 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 B1C99131B70 for ; Tue, 4 Jul 2017 01:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-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 FYPByP783AxR for ; Tue, 4 Jul 2017 01:47:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A910E131B66 for ; Tue, 4 Jul 2017 01:47:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJS02662; Tue, 04 Jul 2017 08:47:23 +0000 (GMT) Received: from SINEML706-CAH.china.huawei.com (10.223.161.56) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 4 Jul 2017 09:47:22 +0100 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.175]) by SINEML706-CAH.china.huawei.com ([10.223.161.56]) with mapi id 14.03.0301.000; Tue, 4 Jul 2017 16:47:16 +0800 From: Wang Haiguang To: "tls@ietf.org" Thread-Topic: An IETF draft on TLS based on ECCSI public key (RFC 6507) Thread-Index: AQHS9KIjbGMCVggeCEW+lkbi2Qxg8g== Date: Tue, 4 Jul 2017 08:47:16 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> In-Reply-To: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> Accept-Language: en-SG, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.22.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.595B561C.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: def147589017ff67dd362d235dec1828 Archived-At: Subject: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 08:47:27 -0000 RGVhciBhbGwsDQoNClRoaXMgSGFpZ3VhbmcgV2FuZyBmcm9tIEh1YXdlaSBUZWNobm9sb2d5LiAN Cg0KSSBoYXZlIHN1Ym1pdHRlZCBhbiBJRVRGIGRyYWZ0IG9uIHVzaW5nIEVDQ1NJIHB1YmxpYyBr ZXkgZm9yIGF1dGhlbnRpY2F0aW9uIG92ZXIgVExTIHByb3RvY29scy4gSXQgaXMgdGhlIGZpcnN0 IHZlcnNpb24sIHNvIHRoZSBkcmFmdCBzdGlsbCBoYXZlIGEgbG90IG9mIHNwYWNlcyB0byBpbXBy b3ZlLiANCg0KRUNDU0kgaXMgYW4gaWRlbnRpdHktYmFzZWQgY2VydGlmaWNhdGVsZXNzIHNpZ25h dHVyZSBhbGdvcml0aG0gYmFzZWQgb24gRWxsaXB0aWMgQ3VydmUuIEl0IGlzIHNwZWNpZmllZCBp biBSRkMgNjUwNy4gIEl0IGhhcyBncmVhdCBwb3RlbnRpYWwgZm9yIElPVCBkZXZpY2UgYXV0aGVu dGljYXRpb24uIA0KDQpUaGUgYWR2YW50YWdlcyBvZiB1c2luZyBFQ0NTSSBzaWduYXR1cmUgYWxn b3JpdGhtIGlzIHRoYXQsIGNvbXBhcmluZyB0byBQS0lYIGNlcnRpZmljYXRlLCBFQ0NTSSBwdWJs aWMga2V5IGlzIGxlc3MgY29tcGxpY2F0ZTsgYW5kIGNvbXBhcmluZyB0byByYXcgcHVibGljIHNj aGVtZSwgaXQgcHJvdmlkZXMgdGhlIGluLWJhbmQgaWRlbnRpdHkgYW5kIHB1YmxpYyBrZXkgYmlu ZGluZy4gDQoNClRoZSBwcm9wb3NlIGRyYWZ0IGhhcyBiZWVuIHN1Ym1pdHRlZCB5ZXN0ZXJkYXkg YW5kIHBsZWFzZSBmaW5kIHRoZSByZWxhdGl2ZSBkb2N1bWVudCBmcm9tIHRoZSBsaW5rcyBiZWxv dy4gDQoNClBsZWFzZSBraW5kbHkgbGV0IG1lIGtub3cgeW91ciBjb21tZW50cyBmb3IgdGhlIGRy YWZ0Lg0KDQpCZXN0IHJlZ2FyZHMNCg0KSGFpZ3VhbmcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgMyBKdWx5LCAyMDE3IDY6NTMgUE0NClRv OiBXYW5nIEhhaWd1YW5nOyBXYW5nIEhhaWd1YW5nOyBZYW5nIFlhbmppYW5nDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctdGxzLWVjY3NpLTAwLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YW5nLXRscy1lY2NzaS0wMC50eHQgaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIYWlndWFuZyBXYW5nIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXdhbmctdGxzLWVjY3NpDQpS ZXZpc2lvbjoJMDANClRpdGxlOgkJVXNpbmcgRUNDU0kgUHVibGljIEtleXMgaW4gVHJhbnNwb3J0 IExheWVyIFNlY3VyaXR5IChUTFMpDQpEb2N1bWVudCBkYXRlOgkyMDE3LTA3LTAzDQpHcm91cDoJ CUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13YW5nLXRscy1lY2NzaS0wMC50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC13YW5nLXRscy1lY2NzaS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtd2FuZy10bHMtZWNjc2ktMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdhbmctdGxzLWVjY3NpLTAwDQoNCg0K QWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG5ldyBjZXJ0aWZpY2F0ZSB0 eXBlIGFuZCBhIFRMUyBleHRlbnNpb24NCiAgIGZvciBhdXRoZW50aWNhdGlvbiB3aXRoIEVDQ1NJ IHB1YmxpYyBrZXlzIGluIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eQ0KICAgKFRMUykuICBUaGUg bmV3IGNlcnRpZmljYXRlIHR5cGUgYWxsb3dzIEVDQ1NJIHB1YmxpYyBrZXlzIHRvIGJlIHVzZWQN CiAgIGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24gb3ZlciBUTFMgcHJvdG9jb2wuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Jul 4 03:25:42 2017 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 8211D131DCD for ; Tue, 4 Jul 2017 03:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 SdtrVPPMfI4a for ; Tue, 4 Jul 2017 03:25:39 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3205131DC8 for ; Tue, 4 Jul 2017 03:25:39 -0700 (PDT) Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 5BC831B74 for ; Tue, 4 Jul 2017 11:25:37 +0100 (BST) Received: by mail-it0-f46.google.com with SMTP id v202so98880586itb.0 for ; Tue, 04 Jul 2017 03:25:37 -0700 (PDT) X-Gm-Message-State: AIVw110BUsMDmBv13tHmzR3RDqP8VI2AZb8x/YWp3/WeHvBPxJ3eF4lB far9NlY6TzXTv7zfGxiyKdF/4cUQoA== X-Received: by 10.36.139.197 with SMTP id g188mr10768897ite.108.1499163935736; Tue, 04 Jul 2017 03:25:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.33.66 with HTTP; Tue, 4 Jul 2017 03:25:35 -0700 (PDT) In-Reply-To: References: From: Matt Caswell Date: Tue, 4 Jul 2017 11:25:35 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 10:25:41 -0000 On 4 July 2017 at 01:01, Eric Rescorla wrote: > - Modifying the key derivation for PSKs so that each session ticket > is associated with a distinct PSK. Draft-21 says this about the ticket nonce: opaque ticket_nonce<1..255>; ... ticket_nonce A unique per-ticket value. Within what context is "uniqueness" required? I am assuming that uniqueness within the context of a single TLS connection is all that is needed? The nonce can be anything between 1 and 255 bytes long. There is no guidance on a suitable length, so I am assuming I can choose anything I like as long as the uniqueness constraint is met. OpenSSL (currently) only ever issues a single ticket per TLS connection so is a single 0 byte sufficient? Thanks Matt From nobody Tue Jul 4 03:50:59 2017 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 674B2131E4C for ; Tue, 4 Jul 2017 03:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 taqSZ8_qIbDp for ; Tue, 4 Jul 2017 03:50:55 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 21F8B131E44 for ; Tue, 4 Jul 2017 03:50:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 03DAA65093; Tue, 4 Jul 2017 13:50:53 +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 Z03LtE4t2QhQ; Tue, 4 Jul 2017 13:50:52 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 91FDD2315; Tue, 4 Jul 2017 13:50:50 +0300 (EEST) Date: Tue, 4 Jul 2017 13:50:50 +0300 From: Ilari Liusvaara To: Matt Caswell Cc: "tls@ietf.org" Message-ID: <20170704105050.zqclbfje2rvly5dm@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 10:50:57 -0000 On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote: > On 4 July 2017 at 01:01, Eric Rescorla wrote: > > - Modifying the key derivation for PSKs so that each session ticket > > is associated with a distinct PSK. > > Draft-21 says this about the ticket nonce: > > opaque ticket_nonce<1..255>; > ... > ticket_nonce A unique per-ticket value. > > > Within what context is "uniqueness" required? I am assuming that > uniqueness within the context of a single TLS connection is all that > is needed? Yes, It has to be unique within a connection. > The nonce can be anything between 1 and 255 bytes long. There is no > guidance on a suitable length, so I am assuming I can choose anything > I like as long as the uniqueness constraint is met. OpenSSL > (currently) only ever issues a single ticket per TLS connection so is > a single 0 byte sufficient? Yes, if you only have one ticket per connection, then any legal fixed value is acceptable. -Ilari From nobody Tue Jul 4 04:21:52 2017 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 94503131F06 for ; Tue, 4 Jul 2017 04:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 qCV8cuDZK0z0 for ; Tue, 4 Jul 2017 04:21:49 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id F0942131DEE for ; Tue, 4 Jul 2017 04:21:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 18EDB33876; Tue, 4 Jul 2017 14:21:47 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 8VqLrp6QCfWX; Tue, 4 Jul 2017 14:21:46 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id BABD8C4; Tue, 4 Jul 2017 14:21:44 +0300 (EEST) Date: Tue, 4 Jul 2017 14:21:44 +0300 From: Ilari Liusvaara To: Wang Haiguang Cc: "tls@ietf.org" Message-ID: <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 11:21:51 -0000 On Tue, Jul 04, 2017 at 08:47:16AM +0000, Wang Haiguang wrote: > Dear all, > > This Haiguang Wang from Huawei Technology. > > I have submitted an IETF draft on using ECCSI public key for > authentication over TLS protocols. It is the first version, so the > draft still have a lot of spaces to improve. Some feedback: - I see the certificate message has single opaque field. This is the same as RPK, but isn't trivially mappable to TLS 1.3. See TLS 1.3 draft section 4.4.2 on how TLS 1.3 handles RPK. - I think you shouldn't duplicate existing arms in TLS structures. See RFC 4279, section 4 for one example on omitting such arms. - I think you shouldn't duplicate definitions of ClientCertificateType and ServerCertificateType. Leave that to RFC 7250 and TLS 1.3 RFC. You just need the certificate type value. - I think you shouldn't define a new key exchange algorithm, but use ECDHE_ECDSA instead (like EdDSA does). Then get a new TLS 1.3 signatureScheme value, which decomposes to the corresponding TLS 1.2 values (see RFC4492bis for an example). However, this requires TLS 1.2 or newer, but that should not be a problem. - The proposed ciphersuites are really bad. No new blockmode or stream- mode ciphers should be defined (especially blockmode, those are almost impossible to implement in secure way). If ECDHE_ECDSA is used, one avoids allocating any new ciphersuites. - Security considerations missing. - IANA considerations missing, should ask for allocation of all new codepoints (and that one OID). - References section is duplicated. -Ilari From nobody Tue Jul 4 06:09:43 2017 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 7FE27132073 for ; Tue, 4 Jul 2017 06:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 O1-OtUnWyFlw for ; Tue, 4 Jul 2017 06:09:38 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7891013206C for ; Tue, 4 Jul 2017 06:09:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 905E933E0C; Tue, 4 Jul 2017 16:09:35 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 9-nfN_PdVKio; Tue, 4 Jul 2017 16:09:35 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4174227B; Tue, 4 Jul 2017 16:09:33 +0300 (EEST) Date: Tue, 4 Jul 2017 16:09:33 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170704130933.t5easxgqaunbnzee@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 13:09:40 -0000 On Mon, Jul 03, 2017 at 05:01:55PM -0700, Eric Rescorla wrote: > I wanted to call the WG's attention to one issue: > > Currently the extension table says that server_certificate_type goes > in the Certificate message, whereas client_certificate_type does > not. My reasoning for the latter is that the extensions are attached > to individual certificate elements, so it was non-sensical to have a > situation where you might have cert A be X.509 and cert B be PGP. I > think we should just change server_certificate_type to go in EE, and > then maybe in future if people want something cleverer they can add it > then. I didn't want to do this without WG discussion, but I think we > should and if people don't object I'll do it in a -22. The certificate type is certainly associated with the certificate chain. However, it only makes sense for server certificate and there can only be one such thing[1] and the data is small, so one could stick the type in EE. [1] Exported authenticators do not count, since the way those work is rather different from usual TLS certificate authentication. -Ilari From nobody Tue Jul 4 06:36:55 2017 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 66F8413160B for ; Tue, 4 Jul 2017 06:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 XA_85_vYIY_B for ; Tue, 4 Jul 2017 06:36:51 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2D03113160A for ; Tue, 4 Jul 2017 06:36:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id B786A650C2; Tue, 4 Jul 2017 16:36:49 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id OrnZqTRj_d5h; Tue, 4 Jul 2017 16:36:49 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 48C42286; Tue, 4 Jul 2017 16:36:47 +0300 (EEST) Date: Tue, 4 Jul 2017 16:36:47 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170704133647.w2qv5cljssdzrlth@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> <20170701170103.htwyfrheq52pmm6l@LK-Perkele-VII> <20170701210000.ppewrje6jcpy5w2b@LK-Perkele-VII> <20170702075416.7ozflgnxdo5k7gcd@LK-Perkele-VII> <20170702201324.dhfybncpih3neuo6@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 13:36:53 -0000 On Sun, Jul 02, 2017 at 02:00:51PM -0700, Eric Rescorla wrote: > On Sun, Jul 2, 2017 at 1:13 PM, Ilari Liusvaara > wrote: > > > There can also be interactions with giving up on fragment transmissions > > (in order to limit memory usage). > > > > Suppose similar case as before, but 2:1 gets lost instead of disappearing, > > and is found after 2:5 is received by the client. > > > > The client will then generate second ACK, which ACKs 2:1. The server then > > receives the ACK and has no idea what the client is talking about, since > > server has dropped the state. But presumably fast-retransmits 2:4 and 2:5, > > now as 2:6 and 2:7 (3rd transmission for both). > > > > It's not clear to me it's useful for implementations to delete state in > this case. As said, this would be to limit memory usage. I suppose real cheap implementation could check for the first missing fragment and retransmit from that point onwards, regardless if any subsequent fragment was ACKed. I suppose if one really wants to scrimp on state, one combine the fragments of small messages (basically, everything except Certificate) in fixed way (ClientHello, HelloRetryRequest and ServerHello likely fit into one fragment, EncryptedExtensions and CertificateRequest likely jointly fit into one record, the same for CertificateVerify and Finished). And then assign RSNs for retrasmissions with fixed base (which impiles that RSN sequence might have gaps). -Ilari From nobody Tue Jul 4 07:43:35 2017 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 835F1131453 for ; Tue, 4 Jul 2017 07:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 3fvQNwWmuGPT for ; Tue, 4 Jul 2017 07:43:32 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07AA131635 for ; Tue, 4 Jul 2017 07:43:31 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id i127so140731742wma.0 for ; Tue, 04 Jul 2017 07:43:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:mime-version :content-transfer-encoding; bh=EN5SX2nYuPlOY6/WW5BjfsKZ/uhrcr0LIq1/2ZGbId8=; b=ZWJtMw3G8k1DAcOOoxPkzwgj1e84ymP3kOf1h4EMgiOxf/fiA/y4yEgjDULmYedhW3 qdYxB1M2eF94wmas7DEutJkjWImlim/0im+IAt3W+P8RSdFoPmDW++aA8tOlmCXwYTyH Q8O0ASC4D8R1fWUp9Qc43yam2C2UuuMsvv00coIOj957jjQKKUjhvFNfj9JY+0SoXhBR t2LFK++zkz36V4KKcJQIgqlLhn3ZALhXNnPUrZArlHOPfNPlY0ItfYFhcaXR3SZiZtWU KgA8M/qUeKCP7CTeVSlbQep0E3BvYIkgCZkazbhukC7/QXLVcd24SlFaMcNCWUu2aiym kW+w== X-Gm-Message-State: AKS2vOxPo2SJT2xM5NA9qhE2nZOGEhA+gsr8nU/+vyheBUNmKWyyofXK 3ivpnX1HVYsrDu0yCPjI4A== X-Received: by 10.28.167.207 with SMTP id q198mr19784586wme.36.1499179409906; Tue, 04 Jul 2017 07:43:29 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id m188sm26363170wmg.34.2017.07.04.07.43.29 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 04 Jul 2017 07:43:29 -0700 (PDT) Message-ID: <1499179408.2892.13.camel@redhat.com> From: Nikos Mavrogiannopoulos To: tls@ietf.org Date: Tue, 04 Jul 2017 16:43:28 +0200 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] signature algorithm ID re-use X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 14:43:33 -0000 Hi,  The latest TLS 1.3 draft re-uses the sha256(4), sha384(5), sha512(6) with ecdsa(3) signature algorithms IDs for the following signature algorithms:     /* ECDSA algorithms */     ecdsa_secp256r1_sha256(0x0403),     ecdsa_secp384r1_sha384(0x0503),     ecdsa_secp521r1_sha512(0x0603), These are similar but have different semantics; as indicated by their name they can be used with a single curve. That makes the handshake conversation something like: Client: Use ecdsa_secp256r1_sha256 under TLS 1.3 or ecdsa with whichever curve and sha256 if under TLS 1.2. That apart from being confusing, means that a client which is willing to fallback to TLS 1.2 cannot restrict its options to ecdsa_secp256r1_sha256 (i.e., require the secp256r1 curve for signatures). One could work-around it, by utilizing the elliptic curves extension, but that has also different semantics under TLS 1.3. So my question is why not go for the simpler approach and create new identifiers for the new signature algorithms? (similarly to RSA-PSS). Is there an advantage of re-using the ECDSA signature algorithm identifiers to mean something different in TLS 1.3? Was there some discussion on the topic on the list? [0]. https://github.com/tlswg/tls13-spec/issues/1035 From nobody Tue Jul 4 08:33:53 2017 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 0726E13195E for ; Tue, 4 Jul 2017 08:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lRzURWTf94Oc for ; Tue, 4 Jul 2017 08:33:48 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 96CA01320D0 for ; Tue, 4 Jul 2017 08:33:46 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id g40so128745682uaa.3 for ; Tue, 04 Jul 2017 08:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=etKlyZUIgwPCW78oK686D1fg6yCHzuZ+yaZhBwgAv3M=; b=c9viecMrp0Vz7b1jSyoimKuV13yzaHjmsK+TRZtQB55FcHLxCopFPlAW1Zf0oFe8ri oZO8W9z+zraG5jSy5p6PNwvW6FjFv6aM+lYlExENbamibjXM25bWILhFXpIa8bDP+ewX fTu1VVswaFQ2d1ZORTQ9XH07DSszxZ+yhdmiHvC+k8uGUM3AQ1qgt397z/mr8r25o7be agkLN4M01lEuTqkG4dlzGd2whUjwSRkeo+YM8HiH6EGnBfqCreRO5D6aX7epSsbameAY S/pgeaio7tGSNLOJKOIpxHKEAgg7f2/pCvNohKSD0TXBzER+K7q7LpyizuWDqUC8XGR7 jDyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=etKlyZUIgwPCW78oK686D1fg6yCHzuZ+yaZhBwgAv3M=; b=fjP/sJ92hxYoZUY6OaPQTXQqixh8AstRO1u1TUBt1OtDVSimCcwjIAnTQiv7SwbnXe Zm5WqcxRkuGVG6RiOHXZLjDumJZ/jqPgnRK1jGDOmI9/Aze8LLfURFswoU2JLBJOEhA4 ZTBo8pCpO2zIL5eBAPF6x3HFJQO6jq7goLAwgS1OcszvgnoTNkAngeajmFVmXbg6Od51 +y2eEu1/FgkkusNFr14/6hYJKhv6tweWpd1VaoC/gTzWALJPb+tOQkSdWCAqpzpDq9DH ZZgOX9Y2sT0uBrBR/h/MWmfWZgpzVShyHcF+fVbznsI1uvZ/og/k7AzDwiEpvhEtPDEC 6pbw== X-Gm-Message-State: AKS2vOzZjfPZprAbTGt+EuBrrU791di7RCN7QW+/aKb6JlFlmy/stfqJ Oln1cdHPNFZhPb+Igp0miXuc12DlbA== X-Received: by 10.159.40.200 with SMTP id d66mr23194379uad.48.1499182425642; Tue, 04 Jul 2017 08:33:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Tue, 4 Jul 2017 08:33:45 -0700 (PDT) In-Reply-To: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> From: Shumon Huque Date: Tue, 4 Jul 2017 11:33:45 -0400 Message-ID: To: Ilari Liusvaara Cc: TLS WG Content-Type: multipart/alternative; boundary="94eb2c122bdcef19f305537f9b8a" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 15:33:52 -0000 --94eb2c122bdcef19f305537f9b8a Content-Type: text/plain; charset="UTF-8" On Sun, Jul 2, 2017 at 10:03 AM, Ilari Liusvaara wrote: > On Wed, Jun 28, 2017 at 02:15:45PM -0700, Joseph Salowey wrote: > > This is the working group last call for > > draft-ietf-tls-dnssec-chain-extension-04. > > Please send you comments to the list by July 12, 2017. > > Some comments: > > 1) Section 3.2. Protocol, TLS 1.3: > > > The authentication chain will be an extension to the certificate_list > > to which the certificate being authenticated belongs. > > Extension blocks are per-certificate. I presume the extension goes to > the extension block of EE certificate? > Yes, in fact the previous sentence to the one you quoted did say this more or less: " ... return a serialized authentication chain in the Certificate message associated with the end entity certificate being validated ". I would propose rewording that a bit and removing the last quoted sentence entirely: Servers receiving a "dnssec_chain" extension in the ClientHello, and which are capable of being authenticated via DANE, SHOULD return a serialized authentication chain in the extension block of the Certificate message containing the end entity certificate being validated, using the format described below. > 2) Section 3.2. Protocol, TLS 1.3: > > I think if one refers to TLS 1.2 section, one should just call out the > differences (i.e., where the server extension goes), and not duplicate > parts of TLS 1.2 processing. > I agree. 3) Section 3.4. DNSSEC Authentication Chain Data: > > > The resource records SHOULD be presented in the canonical form and > > ordering as described in RFC 4034 [RFC4034]. > > What is the expected _receiver_ (i.e., client) behavior? Is the client > supposed to run a canonicalization and sorting pass on the records? > If the client does not do this, and the server sends noncanonical or > unsorted RRset, the validation is going to fail. > Since the ordering is a SHOULD on the server side, the client has to check and perform canonical re-ordering if necessary anyway, before computing and validating the signature. If this were a MUST, a stronger case could be made that this recommendation saves the client some work. Personally, I would be fine with taking out the recommendation for the server to canonically order the records. DNSSEC validators (the client end) are required to reconstruct the canonical form and ordering of the RRset (see RFC 4035, Section 5.3) before validation, so unless there is a compelling rationale for deviating from this, we shouldn't. Section 6 ("Verification") essentially says to do validation according to RFC 4035, which covers all of this, and we were planning on leaving it at that -- rather than replicating text that just restates DNSSEC validation logic that is normatively defined elsewhere. (Perhaps RFC 5155 should also be mentioned now that this spec accommodates negative proofs associated with wildcards and thus has to deal with NSEC3). > 4) Section 3.4. DNSSEC Authentication Chain Data: > > > Each RRset in the sequence is followed by its associated RRsig > > record. The RRsig record is in DNS wire format as described in RFC > > 4034 [RFC4034], Section 3.1. The signature portion of the RDATA, as > > described in the same section, is the following: > > This seems to imply that all RRs that make RRSet need to be adjacent in > the serialization. However, I don't see this explicitly stated > anywhere. > Yes, we can state that more explicitly. > > Also, 'RRsig record' or 'RRsig records'? IIRC, if ZSK is being rolled > (and for DNSKEY, if KSK is being rolled), there will be two RRsig > records for one RRtype. > Good catch. RRsig records (or maybe RRsig RRset). I think we say "DNSKEY RRsets" throughout, so that covers additional keys/rollovers etc. > 5) Section 3.4. DNSSEC Authentication Chain Data: > > > The first RRset in the chain MUST contain the TLSA record set being > > presented. However, if the owner name of the TLSA record set is an > > alias (CNAME or DNAME), then it MUST be preceded by the chain of > > alias records needed to resolve it. > > Is there a requirement to order the aliases in order those aliases are > followed? > Strictly speaking, DNS protocol specs don't require it. In practice, some DNS clients balk or fail if they are presented aliases out of order. So almost all DNS responders order aliases. This is a green field application though, so we don't need to impose such a requirement, but I'm also okay with stating that the aliases are ordered. > 6) Section 3.4. DNSSEC Authentication Chain Data: > > > The final DNSKEY RRset in the authentication chain corresponds to the > > trust anchor (typically the DNS root). This trust anchor is also > > preconfigured in the TLS client, but including it in the response > > from the server permits TLS clients to use the automated trust anchor > > rollover mechanism defined in RFC 5011 [RFC5011] to update their > > configured trust anchor. > > I think this is wrong. The final DNSKEY RRSet does contain the the > preconfigured root key. However, it also contains other keys that > are used to sign the DS records. > Ok, yes, the rationale provided for including the trust anchor DNSKEY RRset is incomplete. As you say, it is also needed to authenticate the ZSKs which sign delegations. We'll update this text. > The client needs those keys in order to validate the chain, and those > keys are rotated every few months for root, instead of every N years. > Correct, and that's why the entire DNSKEY RRset is always delivered. > Furthermore, frequently the trust anchor is provisioned as a fake DS > record for the root. Validating with such anchor requires sending the > root DNSKEY. > Also true, and hence the entire DNSKEY RRset is always delivered. > Real-world zone data (omitted the cryptographic line noise, and added > some hilights): > > $ dig +dnssec -t DNSKEY . > [ stuff omitted ] 7) Section 4. Construction of Serialized Authentication Chains > > > The transport is "tcp" for TLS servers, and "udp" for DTLS servers. > > The port number label is the left-most label, followed by the > > transport, followed by the base domain name. > > So if this would be used with IETF-QUIC, the labels would be > _443._tcp, which is the same as one used by HTTPS, right? > I hadn't yet thought of this use case, but wouldn't it be _443._udp since QUIC runs over UDP? Perhaps a server operator that supports both TLS and QUIC, wants to have separate server credentials for each. And if not, they could alias one of the TLSA records to the other. -- Shumon Huque --94eb2c122bdcef19f305537f9b8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jul 2, 2017 at 10:03 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
On Wed, Jun 28, 2017 at 02:15:45PM -0700, Josep= h Salowey wrote:
> This is the working group last call for
> draft-ietf-tls-dnssec-chain-extension-04.
> Please send you comments to the list by July 12, 2017.

Some comments:

1) Section 3.2.=C2=A0 Protocol, TLS 1.3:

> The authentication chain will be an extension to the certificate_list<= br> > to which the certificate being authenticated=C2=A0 belongs.

Extension blocks are per-certificate. I presume the extension goes to
the extension block of EE certificate?

= Yes, in fact the previous sentence to the one you quoted did say this more = or less: " ... return a serialized authentication chain in the Certifi= cate message associated with the end entity certificate being validated &qu= ot;. I would propose rewording that a bit and removing the last quoted sent= ence entirely:

=C2=A0 =C2=A0Servers receiving= a "dnssec_chain" extension in the ClientHello, and
=C2= =A0 =C2=A0which are capable of being authenticated via DANE, SHOULD return = a
=C2=A0 =C2=A0serialized authentication chain in the extension b= lock of the Certificate=C2=A0
=C2=A0 =C2=A0message containing the= end entity certificate being validated, using the=C2=A0
=C2=A0 = =C2=A0format described below.
=C2=A0
2) Section 3.2.=C2=A0 Protocol, TLS 1.3:

I think if one refers to TLS 1.2 section, one should just call out the
differences (i.e., where the server extension goes), and not duplicate
parts of TLS 1.2 processing.

I agree.

3) Section 3.4.=C2=A0 DNSSEC Authentication Chain Data:

> The resource records SHOULD be presented in the canonical form and
> ordering as described in RFC 4034 [RFC4034].

What is the expected _receiver_ (i.e., client) behavior? Is the client
supposed to run a canonicalization and sorting pass on the records?

If the client does not do this, and the server sends noncanonical or
unsorted RRset, the validation is going to fail.

<= /div>
Since the ordering is a SHOULD on the server side, the client has= to check and perform canonical re-ordering if necessary anyway, before com= puting and validating the signature. If this were a MUST, a stronger case c= ould be made that this recommendation saves the client some work.

Personally, I would be fine with taking out the recommendat= ion for the server to canonically order the records. DNSSEC validators (the= client end) are required to reconstruct the canonical form and ordering of= the RRset (see RFC 4035, Section 5.3) before validation, so unless there i= s a compelling rationale for deviating from this, we shouldn't.

Section 6 ("Verification") essentially says to = do validation according to RFC 4035, which covers all of this, and we were = planning on leaving it at that -- rather than replicating text that just re= states DNSSEC validation logic that is normatively defined elsewhere.
=

(Perhaps RFC 5155 should also be mentioned now that thi= s spec accommodates negative proofs associated with wildcards and thus has = to deal with NSEC3).
=C2=A0
4) Section 3.4.=C2=A0 DNSSEC Authentication Chain Data:

> Each RRset in the sequence is followed by its associated RRsig
> record.=C2=A0 The RRsig record is in DNS wire format as described in R= FC
> 4034 [RFC4034], Section 3.1.=C2=A0 The signature portion of the RDATA,= as
> described in the same section, is the following:

This seems to imply that all RRs that make RRSet need to be adjacent in
the serialization. However, I don't see this explicitly stated
anywhere.

Yes, we can state that more e= xplicitly.
=C2=A0

Also, 'RRsig record' or 'RRsig records'? IIRC, if ZSK is be= ing rolled
(and for DNSKEY, if KSK is being rolled), there will be two RRsig
records for one RRtype.

Good catch. RRs= ig records (or maybe RRsig RRset).

I think we say = "DNSKEY RRsets" throughout, so that covers additional keys/rollov= ers etc.

=C2=A0
5) Section 3.4.=C2=A0 DNSSEC Authentication Chain Data:

> The first RRset in the chain MUST contain the TLSA record set being > presented.=C2=A0 However, if the owner name of the TLSA record set is = an
> alias (CNAME or DNAME), then it MUST be preceded by the chain of
> alias records needed to resolve it.

Is there a requirement to order the aliases in order those aliases are
followed?

Strictly speaking, DNS protoc= ol specs don't require it. In practice, some DNS clients balk or fail i= f they are presented aliases out of order. So almost all DNS responders ord= er aliases. This is a green field application though, so we don't need = to impose such a requirement, but I'm also okay with stating that the a= liases are ordered.


6) Section 3.4.=C2=A0 DNSSEC Authentication Chain Data:

> The final DNSKEY RRset in the authentication chain corresponds to the<= br> > trust anchor (typically the DNS root).=C2=A0 This trust anchor is also=
> preconfigured in the TLS client, but including it in the response
> from the server permits TLS clients to use the automated trust anchor<= br> > rollover mechanism defined in RFC 5011 [RFC5011] to update their
> configured trust anchor.

I think this is wrong. The final DNSKEY RRSet does contain the the
preconfigured root key. However, it also contains other keys that
are used to sign the DS records.

Ok, ye= s, the rationale provided for including the trust anchor DNSKEY RRset is in= complete. As you say, it is also needed to authenticate the ZSKs which sign= delegations. We'll update this text.
=C2=A0
The client needs those keys in order to validate the chain, and those
keys are rotated every few months for root, instead of every N years.

Correct, and that's why the entire DNSKE= Y RRset is always delivered.
=C2=A0
Furthermore, frequently the trust anchor is provisioned as a fake DS
record for the root. Validating with such anchor requires sending the
root DNSKEY.

Also true, and hence the e= ntire DNSKEY RRset is always delivered.
=C2=A0
Real-world zone data (omitted the cryptographic line noise, and added
some hilights):

$ dig +dnssec -t DNSKEY .

[ stuff omitt= ed ]

7) Section 4.=C2=A0 Construction of Serialized Authentication Chains

> The transport is "tcp" for TLS servers, and "udp" = for DTLS servers.
> The port number label is the left-most label, followed by the
> transport, followed by the base domain name.

So if this would be used with IETF-QUIC, the labels would be
_443._tcp, which is the same as one used by HTTPS, right?
<= div>
I hadn't yet thought of this use case, but wouldn= 9;t it be _443._udp since QUIC runs over UDP? Perhaps a server operator tha= t supports both TLS and QUIC, wants to have separate server credentials for= each. And if not, they could alias one of the TLSA records to the other.

--=C2=A0
Shumon Huque

--94eb2c122bdcef19f305537f9b8a-- From nobody Tue Jul 4 09:14:49 2017 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 6F313132207 for ; Tue, 4 Jul 2017 09:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 l3WNQb6INkHP for ; Tue, 4 Jul 2017 09:14:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4AC132209 for ; Tue, 4 Jul 2017 09:14:43 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 304C87A32F1 for ; Tue, 4 Jul 2017 16:14:42 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 4 Jul 2017 12:14:42 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org> References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 16:14:47 -0000 > On Jul 4, 2017, at 11:33 AM, Shumon Huque wrote: >=20 > Yes, in fact the previous sentence to the one you quoted did say this = more or less: " ... return a serialized authentication chain in the = Certificate message associated with the end entity certificate being = validated ". I would propose rewording that a bit and removing the last = quoted sentence entirely: >=20 > Servers receiving a "dnssec_chain" extension in the ClientHello, = and > which are capable of being authenticated via DANE, SHOULD return a > serialized authentication chain in the extension block of the = Certificate=20 > message containing the end entity certificate being validated, = using the=20 > format described below. Why the end-entity certificate, and not the final certificate sent by the server? With anything but DANE-EE(3) the TLSA records can't be processed against the server's certificate message until *all* the server certificates have been received. So instead of squirreling away the DNS data while waiting for all the server certificates to arrive, it may make more sense to receive the TLSA records (and associated signatures, CNAMEs, DNAMEs, ...) once all the server certificates have been received. Of course either way one still buffers all the server certificates, so buffering the TLSA records is not a major issue. It's just that I don't see a compelling argument for sending the TLSA records with the EE certificate. Perhaps send them with any of the server certificates, it probably makes no difference which... --=20 Viktor. From nobody Tue Jul 4 09:19:28 2017 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 C9088132268 for ; Tue, 4 Jul 2017 09:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 RBrfHDTQv3_h for ; Tue, 4 Jul 2017 09:19:24 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEF013225D for ; Tue, 4 Jul 2017 09:19:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 5B598339FE; Tue, 4 Jul 2017 19:19:21 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id DNA_STpLMpv9; Tue, 4 Jul 2017 19:19:20 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C9B3C21C; Tue, 4 Jul 2017 19:19:18 +0300 (EEST) Date: Tue, 4 Jul 2017 19:19:18 +0300 From: Ilari Liusvaara To: Shumon Huque Cc: TLS WG Message-ID: <20170704161918.2voi3uinjv65w3j5@LK-Perkele-VII> References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 16:19:27 -0000 On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote: > On Sun, Jul 2, 2017 at 10:03 AM, Ilari Liusvaara > wrote: > > > On Wed, Jun 28, 2017 at 02:15:45PM -0700, Joseph Salowey wrote: > > > This is the working group last call for > > > draft-ietf-tls-dnssec-chain-extension-04. > > > Please send you comments to the list by July 12, 2017. > > > > Some comments: > > 3) Section 3.4. DNSSEC Authentication Chain Data: > > > > > The resource records SHOULD be presented in the canonical form and > > > ordering as described in RFC 4034 [RFC4034]. > > > > What is the expected _receiver_ (i.e., client) behavior? Is the client > > supposed to run a canonicalization and sorting pass on the records? > > > > If the client does not do this, and the server sends noncanonical or > > unsorted RRset, the validation is going to fail. > > > > Since the ordering is a SHOULD on the server side, the client has to check > and perform canonical re-ordering if necessary anyway, before computing and > validating the signature. If this were a MUST, a stronger case could be > made that this recommendation saves the client some work. > > Personally, I would be fine with taking out the recommendation for the > server to canonically order the records. DNSSEC validators (the client end) > are required to reconstruct the canonical form and ordering of the RRset > (see RFC 4035, Section 5.3) before validation, so unless there is a > compelling rationale for deviating from this, we shouldn't. > > Section 6 ("Verification") essentially says to do validation according to > RFC 4035, which covers all of this, and we were planning on leaving it at > that -- rather than replicating text that just restates DNSSEC validation > logic that is normatively defined elsewhere. I think either this should be strengthened or taken out entierely. Right now it is "the worst of both worlds". > (Perhaps RFC 5155 should also be mentioned now that this spec accommodates > negative proofs associated with wildcards and thus has to deal with NSEC3). Oh yes. AFAICT (since there is always data): - If the record is not a wildcard, then no NSEC nor NSEC3 records are needed. - If the record is a wildcard, then one NSEC or NSEC3 record that denies the sibling of source that is the ancestor of the QNAME. But this might very well be wrong! > > Also, 'RRsig record' or 'RRsig records'? IIRC, if ZSK is being rolled > > (and for DNSKEY, if KSK is being rolled), there will be two RRsig > > records for one RRtype. > > > > Good catch. RRsig records (or maybe RRsig RRset). Maybe I'm just unfamilier with DNS, but I think RRsig RRset might be interpretted as set of RRsig records in some name (which is very much wrong interpretation here). > 7) Section 4. Construction of Serialized Authentication Chains > > > > > The transport is "tcp" for TLS servers, and "udp" for DTLS servers. > > > The port number label is the left-most label, followed by the > > > transport, followed by the base domain name. > > > > So if this would be used with IETF-QUIC, the labels would be > > _443._tcp, which is the same as one used by HTTPS, right? > > > > I hadn't yet thought of this use case, but wouldn't it be _443._udp since > QUIC runs over UDP? Perhaps a server operator that supports both TLS and > QUIC, wants to have separate server credentials for each. And if not, they > could alias one of the TLSA records to the other. Yes, QUIC runs over UDP. However, IETF-QUIC will be TLS 1.3, not DTLS. -Ilari From nobody Tue Jul 4 09:27:24 2017 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 095E31322D4 for ; Tue, 4 Jul 2017 09:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 sdqMraTAxFev for ; Tue, 4 Jul 2017 09:27:20 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3F78D1322D1 for ; Tue, 4 Jul 2017 09:27:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 780A92E88C for ; Tue, 4 Jul 2017 19:27:18 +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 7JBt_JBblEaL for ; Tue, 4 Jul 2017 19:27:18 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3054221C for ; Tue, 4 Jul 2017 19:27:17 +0300 (EEST) Date: Tue, 4 Jul 2017 19:27:17 +0300 From: Ilari Liusvaara To: TLS WG Message-ID: <20170704162717.lb6pqfsm3debgucq@LK-Perkele-VII> References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 16:27:22 -0000 On Tue, Jul 04, 2017 at 12:14:42PM -0400, Viktor Dukhovni wrote: > > > On Jul 4, 2017, at 11:33 AM, Shumon Huque wrote: > > > > Yes, in fact the previous sentence to the one you quoted did say this more or less: " ... return a serialized authentication chain in the Certificate message associated with the end entity certificate being validated ". I would propose rewording that a bit and removing the last quoted sentence entirely: > > > > Servers receiving a "dnssec_chain" extension in the ClientHello, and > > which are capable of being authenticated via DANE, SHOULD return a > > serialized authentication chain in the extension block of the Certificate > > message containing the end entity certificate being validated, using the > > format described below. > > Why the end-entity certificate, and not the final certificate > sent by the server? With anything but DANE-EE(3) the TLSA > records can't be processed against the server's certificate > message until *all* the server certificates have been received. Well, the optimal would be the certficiate record pertrains to. However, since RRsets are atomic, this is not possible. > So instead of squirreling away the DNS data while waiting for > all the server certificates to arrive, it may make more sense > to receive the TLSA records (and associated signatures, CNAMEs, > DNAMEs, ...) once all the server certificates have been received. > > Of course either way one still buffers all the server certificates, > so buffering the TLSA records is not a major issue. It's just that > I don't see a compelling argument for sending the TLSA records with > the EE certificate. Perhaps send them with any of the server > certificates, it probably makes no difference which... The entiere Certificate message should be loaded into memory anyway. And one definitely does not want to merge records. -Ilari From nobody Tue Jul 4 09:36:03 2017 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 04C56132346 for ; Tue, 4 Jul 2017 09:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gotR52ukTUQS for ; Tue, 4 Jul 2017 09:36:00 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 C94C913234A for ; Tue, 4 Jul 2017 09:35:55 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id g40so129615241uaa.3 for ; Tue, 04 Jul 2017 09:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=lESfSVOFkHUmt2BfnHrRlR8ig2Bfl677MZOITijYWfk=; b=iY/+8mgLNuSeGgzS4Cx3l7PjgcO8IBDrl8LT/JgIZanYetIOE4p5W8Gj+weI7Gzd4c 1SyxYjxsVo1LPEryMKLhxtIwaHZFs0Dt/J9NNR4ihoQdpbClJZ7/m8MBF6FZjzqaoVjP PSOb6IHy5Dcwdk8/H5QSF9ChJwZlrHYoa6mKs6v19EqtDHmjc++EWKwGzFOG+/h86s5M hv3996ZQzOCrc9cEJlLnvpCffMQaVDSGkhq7Q/hc5s2FG4+LgvDrhwxHTGZmO6T4AAno Sl0JuPFv9+fLKfaTxb6tO1C5V+p3walOoQ28e+gJj/iaf/HWa1mBP80p89exQ4eJPYyi gSxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=lESfSVOFkHUmt2BfnHrRlR8ig2Bfl677MZOITijYWfk=; b=CE62nPK8R6BzsVOX71g8FIBuKvkRDx3SADdci6UyVy1y7Iaryp9LTKHCqKixCljYnC kEzVUTHmgZ3RqReC2WblhdNvu2HS93FskSvoKb/1KfMNyACrLIdeBJ31EiSK3/j1O0NQ CHgPw2aho/JMwZYL6e5HDQ7iUi5OzQZWSse7Fwd1/BeVSmTAcsYRLW9F9XzW3G559KS8 aGybygWFqJSGfNW2K2u9nO8MUcq5mfHtexdT77AfW8GsU9OenXNDiUVgYNVP0bQQX3MC vSW+WYxEkFkLJqpIW8hzLegAoeH9dV1XjqD43dTgpZOx7RkRVk1rz8Sf35+Jj6FcPp+V eHrw== X-Gm-Message-State: AKS2vOyyU+Ciyc3wLKPIFcrEdDi4+pDZ5QmhZJxLpIWF0ehOPgcII+Jx kw/9727fj6PyeQQn0prC+1nN/rD7nQUu X-Received: by 10.159.35.169 with SMTP id 38mr21137718uao.20.1499186154789; Tue, 04 Jul 2017 09:35:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Tue, 4 Jul 2017 09:35:54 -0700 (PDT) In-Reply-To: <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org> References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org> From: Shumon Huque Date: Tue, 4 Jul 2017 12:35:54 -0400 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="94eb2c0402ea355eef0553807a5f" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 16:36:02 -0000 --94eb2c0402ea355eef0553807a5f Content-Type: text/plain; charset="UTF-8" On Tue, Jul 4, 2017 at 12:14 PM, Viktor Dukhovni wrote: > > > On Jul 4, 2017, at 11:33 AM, Shumon Huque wrote: > > > > Yes, in fact the previous sentence to the one you quoted did say this > more or less: " ... return a serialized authentication chain in the > Certificate message associated with the end entity certificate being > validated ". I would propose rewording that a bit and removing the last > quoted sentence entirely: > > > > Servers receiving a "dnssec_chain" extension in the ClientHello, and > > which are capable of being authenticated via DANE, SHOULD return a > > serialized authentication chain in the extension block of the > Certificate > > message containing the end entity certificate being validated, using > the > > format described below. > > Why the end-entity certificate, and not the final certificate > sent by the server? With anything but DANE-EE(3) the TLSA > records can't be processed against the server's certificate > message until *all* the server certificates have been received. > I'm not in principle opposed, but intuitively it makes most sense to associate the DNSSEC chain with the certificate being validated. The other logical place this might have been placed is Encrypted Extensions. But that again precedes the Certificate message, so doesn't address your buffering up concern. Also if DANE-EE turned out to be the common use case, it helps right? Cause the validator doesn't care about the rest of the certificate chain, and can authenticate the EE cert right away. > So instead of squirreling away the DNS data while waiting for > all the server certificates to arrive, it may make more sense > to receive the TLSA records (and associated signatures, CNAMEs, > DNAMEs, ...) once all the server certificates have been received. > > Of course either way one still buffers all the server certificates, > so buffering the TLSA records is not a major issue. It's just that > I don't see a compelling argument for sending the TLSA records with > the EE certificate. Perhaps send them with any of the server > certificates, it probably makes no difference which... > Ok. Let's see if anyone else chimes in with opinions on this .. -- Shumon Huque --94eb2c0402ea355eef0553807a5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 4, 2017 at 12:14 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
<= br> > On Jul 4, 2017, at 11:33 AM, Shumon Huque <shuque@gmail.com> wrote:
>
> Yes, in fact the previous sentence to the one you quoted did say this = more or less: " ... return a serialized authentication chain in the Ce= rtificate message associated with the end entity certificate being validate= d ". I would propose rewording that a bit and removing the last quoted= sentence entirely:
>
>=C2=A0 =C2=A0 Servers receiving a "dnssec_chain" extension in= the ClientHello, and
>=C2=A0 =C2=A0 which are capable of being authenticated via DANE, SHOULD= return a
>=C2=A0 =C2=A0 serialized authentication chain in the extension block of= the Certificate
>=C2=A0 =C2=A0 message containing the end entity certificate being valid= ated, using the
>=C2=A0 =C2=A0 format described below.

Why the end-entity certificate, and not the final certificate
sent by the server?=C2=A0 With anything but DANE-EE(3) the TLSA
records can't be processed against the server's certificate
message until *all* the server certificates have been received.

I'm not in principle opposed, but intuitively = it makes most sense to associate the DNSSEC chain with the certificate bein= g validated.

The other logical place this might ha= ve been placed is =C2=A0Encrypted Extensions. But that again precedes the C= ertificate message, so doesn't address your buffering up concern.
=

Also if DANE-EE turned out to be the common use case, i= t helps right? Cause the validator doesn't care about the rest of the c= ertificate chain, and can authenticate the EE cert right away.
= =C2=A0
So instead of squirreling away the DNS data while waiting for
all the server certificates to arrive, it may make more sense
to receive the TLSA records (and associated signatures, CNAMEs,
DNAMEs, ...) once all the server certificates have been received.

Of course either way one still buffers all the server certificates,
so buffering the TLSA records is not a major issue.=C2=A0 It's just tha= t
I don't see a compelling argument for sending the TLSA records with
the EE certificate.=C2=A0 Perhaps send them with any of the server
certificates, it probably makes no difference which...

Ok. Let's see if anyone else chimes in with opinions on= this ..

--=C2=A0
Shumon Huque

--94eb2c0402ea355eef0553807a5f-- From nobody Tue Jul 4 10:18:42 2017 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 B75441324DE for ; Tue, 4 Jul 2017 10:18:40 -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 B-nIw1wX0OT0 for ; Tue, 4 Jul 2017 10:18:38 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E4212ECB6 for ; Tue, 4 Jul 2017 10:18:07 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id r126so114067068vkg.0 for ; Tue, 04 Jul 2017 10:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mn2sm5zhJx3YiljdIYMcfr6E3gSLEuAOKFvPom18Svk=; b=F0Gy9f/upbSYrL1oM3hmLngdqr+dpWodhxOETAyFx2joWaJN2s/GVbhN8JErkXaXPy kq57jJ4QwZzSk9Wt2K12/9ngBYrNvVajf+ikGr0BKp2BmrJvEDrfSaxnmKaJ6fxUKtqG I2F5Uzw49qe0IGmuwFioWrhckVcW8dyvCMPv/IGdYt8dlU2t3hL/V6j0dpm1TwYMgEGI dNyCx7qjqbOaXHhAmLeziyAWcqWv/WQDSXHJUIJKWGEH0X3QFNWmyMf7RZCbCIQfabdg LgbLqc4/J+Oq2xYOd9Kt4veUFumiDQxYCyUiIqHCbUQvejUohmLOrbAsAh+2gvJjop4P O5yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mn2sm5zhJx3YiljdIYMcfr6E3gSLEuAOKFvPom18Svk=; b=fxkzDAmAyYr7zzBtFR3D2zA7DNPlMKXMjDIuVWiydQF8SefE762FiWtycsQrLDyMNF L9G09BLhyY7Oz9ZgSakkpQPbX+WkHVauVM4BxjC4SlYbCbshLwZZqhvs8LAImOcdjLlF bHsiW8L6RtemJWow0DNvu28TJec/2WmdxnyhXCInKqK2jd2sQ99lI2jAuGoJibkgt4GA J2SgmIPSl01wUIvJf8chEnlB+2sKE+zPykpCN+VzRU+ujwkp3VDvkO1GAkgO6oUFYrF6 codrcwdLDGX14AXT0lXRvtHzDNvq4lGLRBjJUSRVDnZUYhaxe0m7Jb7SfNfevFVYHzij OgPA== X-Gm-Message-State: AKS2vOyeiwyRgAQMWocraJqwu1jYcPYWmXJoBHHa2Viv1kkJTFiBuJ43 BwimvKPVuvctEpM6SqrINpR6TdVPMA== X-Received: by 10.31.170.22 with SMTP id t22mr23157176vke.100.1499188686401; Tue, 04 Jul 2017 10:18:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Tue, 4 Jul 2017 10:18:05 -0700 (PDT) In-Reply-To: <20170704161918.2voi3uinjv65w3j5@LK-Perkele-VII> References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <20170704161918.2voi3uinjv65w3j5@LK-Perkele-VII> From: Shumon Huque Date: Tue, 4 Jul 2017 13:18:05 -0400 Message-ID: To: Ilari Liusvaara Cc: TLS WG Content-Type: multipart/alternative; boundary="001a11415c3e1ab51a0553811116" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 17:18:41 -0000 --001a11415c3e1ab51a0553811116 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara wrote: > On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote: > > > > > Since the ordering is a SHOULD on the server side, the client has to > check > > and perform canonical re-ordering if necessary anyway, before computing > and > > validating the signature. If this were a MUST, a stronger case could be > > made that this recommendation saves the client some work. > > > > Personally, I would be fine with taking out the recommendation for the > > server to canonically order the records. DNSSEC validators (the client > end) > > are required to reconstruct the canonical form and ordering of the RRset > > (see RFC 4035, Section 5.3) before validation, so unless there is a > > compelling rationale for deviating from this, we shouldn't. > > > > Section 6 ("Verification") essentially says to do validation according to > > RFC 4035, which covers all of this, and we were planning on leaving it at > > that -- rather than replicating text that just restates DNSSEC validation > > logic that is normatively defined elsewhere. > > I think either this should be strengthened or taken out entierely. > Right now it is "the worst of both worlds". > My proposal is to remove the recommendation that the server SHOULD order records in an RRset. And refer to the normative DNSSEC validation algorithm for the client. That should take care of this. > > > (Perhaps RFC 5155 should also be mentioned now that this spec > accommodates > > negative proofs associated with wildcards and thus has to deal with > NSEC3). > > Oh yes. AFAICT (since there is always data): > > - If the record is not a wildcard, then no NSEC nor NSEC3 records are > needed. > Correct. > - If the record is a wildcard, then one NSEC or NSEC3 record that > denies the sibling of source that is the ancestor of the QNAME. > The client first needs to determine that a wildcard DNS record was matched - this can be deduced from the the label count field in the RRSIG record being less than the label count in the QNAME. It then needs to authenticate NSEC/NSEC3 records that prove the following facts: (1) that there is no exact match of the QNAME and (2) that no closer wildcard could have matched. Often the same NSEC/NSEC3 record can prove both facts. > > > Also, 'RRsig record' or 'RRsig records'? IIRC, if ZSK is being rolled > > > (and for DNSKEY, if KSK is being rolled), there will be two RRsig > > > records for one RRtype. > > > > > > > Good catch. RRsig records (or maybe RRsig RRset). > > Maybe I'm just unfamilier with DNS, but I think RRsig RRset might be > interpretted as set of RRsig records in some name (which is very much > wrong interpretation here). > An RRset is defined as the set of records that share the same name, type, and class. So an RRsig RRset should cover signatures produced by different keys for the same RRset. But if this sounds confusing, I'm okay with "RRsig records". > > 7) Section 4. Construction of Serialized Authentication Chains > > > > > > > The transport is "tcp" for TLS servers, and "udp" for DTLS servers. > > > > The port number label is the left-most label, followed by the > > > > transport, followed by the base domain name. > > > > > > So if this would be used with IETF-QUIC, the labels would be > > > _443._tcp, which is the same as one used by HTTPS, right? > > > > > > > I hadn't yet thought of this use case, but wouldn't it be _443._udp since > > QUIC runs over UDP? Perhaps a server operator that supports both TLS and > > QUIC, wants to have separate server credentials for each. And if not, > they > > could alias one of the TLSA records to the other. > > Yes, QUIC runs over UDP. However, IETF-QUIC will be TLS 1.3, not DTLS. > You mean IETF QUIC will reuse the TLS 1.3 handshake mechanism right? But it's still a distinct transport from TLS 1.3 I assume. (I'm a QUIC newbie - feel free to correct me). The statement in the draft that the "_udp" label is for DTLS servers might be too restrictive, and perhaps it should be expanded to include other secure transports that run over UDP. The TLSA spec (RFC 6698) today only defines 3 transport labels _tcp, _udp, and _sctp. I'm wondering whether that needs to be expanded to include things like tls/dtls/quic, and whether it needs an IANA maintained registry for extensibility. -- Shumon Huque --001a11415c3e1ab51a0553811116 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote:
=
>
> Since the ordering is a SHOULD on the server side, the client has to c= heck
> and perform canonical re-ordering if necessary anyway, before computin= g and
> validating the signature. If this were a MUST, a stronger case could b= e
> made that this recommendation saves the client some work.
>
> Personally, I would be fine with taking out the recommendation for the=
> server to canonically order the records. DNSSEC validators (the client= end)
> are required to reconstruct the canonical form and ordering of the RRs= et
> (see RFC 4035, Section 5.3) before validation, so unless there is a > compelling rationale for deviating from this, we shouldn't.
>
> Section 6 ("Verification") essentially says to do validation= according to
> RFC 4035, which covers all of this, and we were planning on leaving it= at
> that -- rather than replicating text that just restates DNSSEC validat= ion
> logic that is normatively defined elsewhere.

I think either this should be strengthened or taken out entierely. Right now it is "the worst of both worlds".
=
My proposal is to remove the recommendation that the server = SHOULD order records in an RRset. And refer to the normative DNSSEC validat= ion algorithm for the client. That should take care of this.
=C2= =A0

> (Perhaps RFC 5155 should also be mentioned now that this spec accommod= ates
> negative proofs associated with wildcards and thus has to deal with NS= EC3).

Oh yes. AFAICT (since there is always data):

- If the record is not a wildcard, then no NSEC nor NSEC3 records are
=C2=A0 needed.

Correct.
=C2= =A0
- If the record is a wildcard, then one NSEC or NSEC3 record that
=C2=A0 denies the sibling of source that is the ancestor of the QNAME.
<= /blockquote>

The client first needs to determine that a = wildcard DNS record was matched - this can be deduced from the the label co= unt field in the RRSIG record being less than the label count in the QNAME.= It then needs to authenticate NSEC/NSEC3 records that prove the following = facts: =C2=A0(1) that there is no exact match of the QNAME and (2) that no = closer wildcard could have matched. Often the same NSEC/NSEC3 record can pr= ove both facts.
=C2=A0
> > Also, 'RRsig record' or 'RRsig records'? IIRC, if= ZSK is being rolled
> > (and for DNSKEY, if KSK is being rolled), there will be two RRsig=
> > records for one RRtype.
> >
>
> Good catch. RRsig records (or maybe RRsig RRset).

Maybe I'm just unfamilier with DNS, but I think RRsig RRset migh= t be
interpretted as set of RRsig records in some name (which is very much
wrong interpretation here).

An RRset is= defined as the set of records that share the same name, type, and class. S= o an RRsig RRset should cover signatures produced by different keys for the= same RRset. But if this sounds confusing, I'm okay with "RRsig re= cords".
=C2=A0
> 7) Section 4.=C2=A0 Construction of Serialized Authentication Chains > >
> > > The transport is "tcp" for TLS servers, and "= udp" for DTLS servers.
> > > The port number label is the left-most label, followed by th= e
> > > transport, followed by the base domain name.
> >
> > So if this would be used with IETF-QUIC, the labels would be
> > _443._tcp, which is the same as one used by HTTPS, right?
> >
>
> I hadn't yet thought of this use case, but wouldn't it be _443= ._udp since
> QUIC runs over UDP? Perhaps a server operator that supports both TLS a= nd
> QUIC, wants to have separate server credentials for each. And if not, = they
> could alias one of the TLSA records to the other.

Yes, QUIC runs over UDP. However, IETF-QUIC will be TLS 1.3, not DTL= S.

You mean IETF QUIC will reuse the TL= S 1.3 handshake mechanism right? But it's still a distinct transport fr= om TLS 1.3 I assume. (I'm a QUIC newbie - feel free to correct me).

The statement in the draft that the "_udp" = label is for DTLS servers might be too restrictive, and perhaps it should b= e expanded to include other secure transports that run over UDP. The TLSA s= pec (RFC 6698) today only defines 3 transport labels _tcp, _udp, and _sctp.= I'm wondering whether that needs to be expanded to include things like= tls/dtls/quic, and whether it needs an IANA maintained registry for extens= ibility.

--=C2=A0
Shumon Huque

--001a11415c3e1ab51a0553811116-- From nobody Tue Jul 4 13:50:44 2017 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 DB0EA131A13 for ; Tue, 4 Jul 2017 13:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 XZE_oS52irA4 for ; Tue, 4 Jul 2017 13:50:37 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 90023131755 for ; Tue, 4 Jul 2017 13:50:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 727C9652CF; Tue, 4 Jul 2017 23:50:35 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id W10cF4tn63Rw; Tue, 4 Jul 2017 23:50:35 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 1BE0827F; Tue, 4 Jul 2017 23:50:33 +0300 (EEST) Date: Tue, 4 Jul 2017 23:50:32 +0300 From: Ilari Liusvaara To: Shumon Huque Cc: TLS WG Message-ID: <20170704205032.zjpwduybg2hp6gcn@LK-Perkele-VII> References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <20170704161918.2voi3uinjv65w3j5@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 20:50:42 -0000 On Tue, Jul 04, 2017 at 01:18:05PM -0400, Shumon Huque wrote: > On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara > wrote: > > > On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote: > > > > > > - If the record is a wildcard, then one NSEC or NSEC3 record that > > denies the sibling of source that is the ancestor of the QNAME. > > > > The client first needs to determine that a wildcard DNS record was matched > - this can be deduced from the the label count field in the RRSIG record > being less than the label count in the QNAME. It then needs to authenticate > NSEC/NSEC3 records that prove the following facts: (1) that there is no > exact match of the QNAME and (2) that no closer wildcard could have > matched. Often the same NSEC/NSEC3 record can prove both facts. When is one NSEC/NSEC3 record (covering the sibling of source that is the parent) together with the wildcard RRsig records not enough to prove correctness of wildcard expansion? (I know it takes 3 NSEC3 records to prove that something does not exist, but here only cases where something exists are interesting). > > > > Also, 'RRsig record' or 'RRsig records'? IIRC, if ZSK is being rolled > > > > (and for DNSKEY, if KSK is being rolled), there will be two RRsig > > > > records for one RRtype. > > > > > > > > > > Good catch. RRsig records (or maybe RRsig RRset). > > > > Maybe I'm just unfamilier with DNS, but I think RRsig RRset might be > > interpretted as set of RRsig records in some name (which is very much > > wrong interpretation here). > > > > An RRset is defined as the set of records that share the same name, type, > and class. So an RRsig RRset should cover signatures produced by different > keys for the same RRset. But if this sounds confusing, I'm okay with "RRsig > records". RRsig is special in that it is subtyped in RRdata. I don't know if concept of "RRset" is redefined for RRsig to take that into account. I.e., does RRsig RRset include RRsig's for any possible A records (which are very much not interesting here)? > > > 7) Section 4. Construction of Serialized Authentication Chains > > > > > > > > > The transport is "tcp" for TLS servers, and "udp" for DTLS servers. > > > > > The port number label is the left-most label, followed by the > > > > > transport, followed by the base domain name. > > > > > > > > So if this would be used with IETF-QUIC, the labels would be > > > > _443._tcp, which is the same as one used by HTTPS, right? > > > > > > > > > > I hadn't yet thought of this use case, but wouldn't it be _443._udp since > > > QUIC runs over UDP? Perhaps a server operator that supports both TLS and > > > QUIC, wants to have separate server credentials for each. And if not, > > they > > > could alias one of the TLSA records to the other. > > > > Yes, QUIC runs over UDP. However, IETF-QUIC will be TLS 1.3, not DTLS. > > > > You mean IETF QUIC will reuse the TLS 1.3 handshake mechanism right? But > it's still a distinct transport from TLS 1.3 I assume. (I'm a QUIC newbie - > feel free to correct me). Pretty much. -Ilari From nobody Tue Jul 4 14:13:42 2017 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 8FCBF1270AC for ; Tue, 4 Jul 2017 14:13: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, 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 MbildVZfbWlt for ; Tue, 4 Jul 2017 14:13:40 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 084E8129B61 for ; Tue, 4 Jul 2017 14:13:40 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id 191so115515332vko.2 for ; Tue, 04 Jul 2017 14:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+aRyjEXErUG819CaStPksSfGilV14KVjeGQccF15hmQ=; b=JHoqraoSg7eU3/1T1QPnT5aq3Fex3ijK4HC2I+mMFs3pouSmtOxWgY91KY0qR/pahe 6s/lGCrmZJ+0MqDRVXLIEzlHsOK0pdwDTXPg2DE9G++lVb1yBLhvHiaQEi1bB2UwiA2e EKKzQ3cN/jDErtFUVmNGX4+jVRS4CNvZ3pH34WSpgsCZAnatiKFWGqrF2AfzNQd1/sBi 97OrpXJQCAA4SSoR1yAiin36ZFE0SydaDJCxFu2ie8tgZKbI6YeDBJaR/5o5PVZuB9yI OsCCcnHcY/kpSGdtmFhWf6HkjyWKP+xYnQRmiojtzdN137BczkT4NnnvXYPg9SXeIJrr g1ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+aRyjEXErUG819CaStPksSfGilV14KVjeGQccF15hmQ=; b=cYH2OAm7d76H+/PiO+5FGMNHFCfBpEM+Q+t0tIE+Lr2McGoPdEofplgaCj3Vu0kkKZ we0eT9XrQlHdXlx7p6UN46Nuv0/wys8ZKTrqGko9zRS+aXkatsYGKd8iuOPaed7il+JW VyPTViSszIzTVN+ZGPN3a3e2nbKH95LetXywkbSvUI8fWTlwEFXGhmXdCiVX3A6hEFsO KJ3AH4hA9wIk/qJ2dyx/xNSy84kr73QAJ+GFtmVT12TKiyEfA8II4ElJF1rXKlcR9UZP xNS8Sa8+CW5hUBVEaM727a7vnoQLg34rIb8+pkw+a9G2oS82vtNOtQPQhJtOILbUtIe2 o3jA== X-Gm-Message-State: AKS2vOzjVxiejN5ejZCAaP/0qfbWtksC/Ds2tteMPgeJLGjh34V0YnaB 2nzNNSJR7YlNkh+13fogMnTlAAhjyw== X-Received: by 10.31.188.71 with SMTP id m68mr23992911vkf.13.1499202819082; Tue, 04 Jul 2017 14:13:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Tue, 4 Jul 2017 14:13:38 -0700 (PDT) In-Reply-To: <20170704205032.zjpwduybg2hp6gcn@LK-Perkele-VII> References: <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <20170704161918.2voi3uinjv65w3j5@LK-Perkele-VII> <20170704205032.zjpwduybg2hp6gcn@LK-Perkele-VII> From: Shumon Huque Date: Tue, 4 Jul 2017 17:13:38 -0400 Message-ID: To: Ilari Liusvaara Cc: TLS WG Content-Type: multipart/alternative; boundary="001a1143aa4a7a4f9e0553845b61" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 21:13:41 -0000 --001a1143aa4a7a4f9e0553845b61 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 4, 2017 at 4:50 PM, Ilari Liusvaara wrote: > On Tue, Jul 04, 2017 at 01:18:05PM -0400, Shumon Huque wrote: > > On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote: > > > > > > > > > An RRset is defined as the set of records that share the same name, type, > > and class. So an RRsig RRset should cover signatures produced by > different > > keys for the same RRset. But if this sounds confusing, I'm okay with > "RRsig > > records". > > RRsig is special in that it is subtyped in RRdata. I don't know if > concept of "RRset" is redefined for RRsig to take that into account. > > I.e., does RRsig RRset include RRsig's for any possible A records (which > are very much not interesting here)? > I think we need to say the set of RRsig records that "cover" the type in question." Shumon. --001a1143aa4a7a4f9e0553845b61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 4, 2017 at 4:50 PM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
On Tue, Jul 04, 2017 at 01:18:05PM -0400, Shumon Huque wrote:
> On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote:
>
> >
>
> An RRset is defined as the set of records that share the same name, ty= pe,
> and class. So an RRsig RRset should cover signatures produced by diffe= rent
> keys for the same RRset. But if this sounds confusing, I'm okay wi= th "RRsig
> records".

RRsig is special in that it is subtyped in RRdata. I don't know = if
concept of "RRset" is redefined for RRsig to take that into accou= nt.

I.e., does RRsig RRset include RRsig's for any possible A records (whic= h
are very much not interesting here)?

I = think we need to say the set of RRsig records that "cover" the ty= pe in question."

Shumon.

=
--001a1143aa4a7a4f9e0553845b61-- From nobody Tue Jul 4 15:50:33 2017 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 A8600129AAD for ; Tue, 4 Jul 2017 15:50: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, 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 CVSavK7tnGzc for ; Tue, 4 Jul 2017 15:50:31 -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 DFDA81292FD for ; Tue, 4 Jul 2017 15:50:30 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id z78so83484619lff.0 for ; Tue, 04 Jul 2017 15:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lozLP4r1fAta7wurg2zprTtN/6HRnqj+bayJvnbdlhM=; b=ikGvVAHhSoW5eLW8cupVV9fNEKbuNqI3y5jBdGnHlDEL53SKjaOvq0OACxZKww5Ll0 c9X0mLNqhbqcMV5V2R7twfcKZIIS97redClIWW528+Yb2F7YbCs3PyagBk3LdT2OlqUB CTTpqG4zbHuUuHdSxloSLr9z85d13aZKvmiuqNIVezRpNP+s0JRjSPhl3trkYL0MT4yq 6LR6lvuZmGd/bQM69ZV7ZxfT/lldKO9GMDE/nGAY3sIV+h/xzs7DTFiFClHbZETR8Yp4 VGz4jIRN8u1MH3Elc5PGGOL3sjgAjS4xh8cCXg4EDKEHxa1u/YslQ0fMQuwqJCALxYnT jhBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lozLP4r1fAta7wurg2zprTtN/6HRnqj+bayJvnbdlhM=; b=DkRTVQvdt06uNul+TmQXnJ71k5ZbJzuRZ7p8GDRegwIWYijUvHOgFV1VkKmJ1C+Sbb S5AkD4+lJ2dDWZikfpCeY4t2dx0iY/BcjH0p1SokOyrf94bKt6WSSpIgLFWvZRf2yv+l NZmmulgt54xNH0BwmaqlOKI7HgZU16UiiMIiM0rW/Egd/zl9ajevfwUxKqBvTz1XlCtI nfxelaMliErVnEJBvU8Aky8Iot0qpenAfKBW5qfkMrLLuia2mH5bAV4U+PnUK2PoQq02 PWO87zuUZZDdVkDC1Vo5zSfYIq0nw6Zt4tntFqUhOBNTtp8J05V+5wJq7uX1ayesRjo7 Wxdg== X-Gm-Message-State: AKS2vOzskhK6L5sqXOsWKcZDtxgjNxpr3mBR+QmiGtO9Dz3/tkBjPMqy zhMnZRf8lVCVQp2ve7fRa3RagyDclA== X-Received: by 10.25.148.81 with SMTP id w78mr13854270lfd.169.1499208629211; Tue, 04 Jul 2017 15:50:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Tue, 4 Jul 2017 15:50:28 -0700 (PDT) In-Reply-To: <1499179408.2892.13.camel@redhat.com> References: <1499179408.2892.13.camel@redhat.com> From: Martin Thomson Date: Tue, 4 Jul 2017 15:50:28 -0700 Message-ID: To: Nikos Mavrogiannopoulos Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] signature algorithm ID re-use X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2017 22:50:33 -0000 On 4 July 2017 at 07:43, Nikos Mavrogiannopoulos wrote: > So my question is why not go for the simpler approach and create new > identifiers for the new signature algorithms? (similarly to RSA-PSS). > Is there an advantage of re-using the ECDSA signature algorithm > identifiers to mean something different in TLS 1.3? Was there some > discussion on the topic on the list? This was fairly extensively litigated. I remember Hannes asking exactly the same question, but I forget which in-person meeting it was. It might have been IETF 97. Unfortunately, any search I do on this subject turns up the hundreds of emails on using signature algorithms for selecting certificates. What I've found is that this isn't that difficult to implement correctly, even across versions. As David Benjamin suggested in earlier emails, you can change to using a 16-bit codepoint in your code. Then you add a curve-matching restriction if the selected version is TLS 1.3 (or greater). The only issues we had was with the functions it uses to configure the stack, but those are internal issues. From nobody Wed Jul 5 01:18:34 2017 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 5EB19131B06 for ; Wed, 5 Jul 2017 01:18:33 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 p2ThTCAjkOjO for ; Wed, 5 Jul 2017 01:18:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D737131826 for ; Wed, 5 Jul 2017 01:18:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJT85766; Wed, 05 Jul 2017 08:18:29 +0000 (GMT) Received: from SINEML702-CAH.china.huawei.com (10.223.161.52) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 5 Jul 2017 09:18:27 +0100 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.175]) by SINEML702-CAH.china.huawei.com ([169.254.255.221]) with mapi id 14.03.0301.000; Wed, 5 Jul 2017 16:18:24 +0800 From: Wang Haiguang To: "tls@ietf.org" Thread-Topic: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) Thread-Index: AQHS9KIjbGMCVggeCEW+lkbi2Qxg8qJDAA4AgAHj4KA= Date: Wed, 5 Jul 2017 08:18:23 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309DF6A581@SINEML521-MBX.china.huawei.com> References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> In-Reply-To: <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> Accept-Language: en-SG, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.22.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.595CA0D5.00D0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 41fd2983f8fc3b7cf0364e5067d75698 Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 08:18:33 -0000 RGVhciBJbGFyaQ0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB0aGUgZmVlZGJhY2suIA0KDQpXZSBh cmUgbm93IHdvcmtpbmcgb24gdGhlIGNvbW1lbnRzIHlvdSBwcm92aWRlZCBpbiB0aGUgZWFybGll ciBlbWFpbCBhbmQgd2lsbCB1cGRhdGUgb3VyIHByb3Bvc2FsIGFjY29yZGluZ2x5LiANCg0KV2Ug d2lsbCByZXBseSB0byB5b3VyIGNvbW1lbnRzIGFzIHNvb24gYXMgcG9zc2libGUuIA0KDQpUaGFu a3MgdmVyeSBtdWNoLg0KDQpCZXN0IHJlZ2FyZHMuDQoNCkhhaWd1YW5nDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20gW21haWx0bzpp bGFyaWxpdXN2YWFyYUB3ZWxoby5jb21dIA0KU2VudDogVHVlc2RheSwgNCBKdWx5LCAyMDE3IDc6 MjIgUE0NClRvOiBXYW5nIEhhaWd1YW5nDQpDYzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W1RMU10gQW4gSUVURiBkcmFmdCBvbiBUTFMgYmFzZWQgb24gRUNDU0kgcHVibGljIGtleSAoUkZD IDY1MDcpDQoNCk9uIFR1ZSwgSnVsIDA0LCAyMDE3IGF0IDA4OjQ3OjE2QU0gKzAwMDAsIFdhbmcg SGFpZ3Vhbmcgd3JvdGU6DQo+IERlYXIgYWxsLA0KPiANCj4gVGhpcyBIYWlndWFuZyBXYW5nIGZy b20gSHVhd2VpIFRlY2hub2xvZ3kuIA0KPiANCj4gSSBoYXZlIHN1Ym1pdHRlZCBhbiBJRVRGIGRy YWZ0IG9uIHVzaW5nIEVDQ1NJIHB1YmxpYyBrZXkgZm9yIA0KPiBhdXRoZW50aWNhdGlvbiBvdmVy IFRMUyBwcm90b2NvbHMuIEl0IGlzIHRoZSBmaXJzdCB2ZXJzaW9uLCBzbyB0aGUgDQo+IGRyYWZ0 IHN0aWxsIGhhdmUgYSBsb3Qgb2Ygc3BhY2VzIHRvIGltcHJvdmUuDQoNClNvbWUgZmVlZGJhY2s6 DQoNCi0gSSBzZWUgdGhlIGNlcnRpZmljYXRlIG1lc3NhZ2UgaGFzIHNpbmdsZSBvcGFxdWUgZmll bGQuIFRoaXMgaXMgdGhlDQogIHNhbWUgYXMgUlBLLCBidXQgaXNuJ3QgdHJpdmlhbGx5IG1hcHBh YmxlIHRvIFRMUyAxLjMuIFNlZSBUTFMgMS4zDQogIGRyYWZ0IHNlY3Rpb24gNC40LjIgb24gaG93 IFRMUyAxLjMgaGFuZGxlcyBSUEsuDQoNCi0gSSB0aGluayB5b3Ugc2hvdWxkbid0IGR1cGxpY2F0 ZSBleGlzdGluZyBhcm1zIGluIFRMUyBzdHJ1Y3R1cmVzLg0KICBTZWUgUkZDIDQyNzksIHNlY3Rp b24gNCBmb3Igb25lIGV4YW1wbGUgb24gb21pdHRpbmcgc3VjaCBhcm1zLg0KDQotIEkgdGhpbmsg eW91IHNob3VsZG4ndCBkdXBsaWNhdGUgZGVmaW5pdGlvbnMgb2YgQ2xpZW50Q2VydGlmaWNhdGVU eXBlDQogIGFuZCBTZXJ2ZXJDZXJ0aWZpY2F0ZVR5cGUuIExlYXZlIHRoYXQgdG8gUkZDIDcyNTAg YW5kIFRMUyAxLjMgUkZDLg0KICBZb3UganVzdCBuZWVkIHRoZSBjZXJ0aWZpY2F0ZSB0eXBlIHZh bHVlLg0KDQotIEkgdGhpbmsgeW91IHNob3VsZG4ndCBkZWZpbmUgYSBuZXcga2V5IGV4Y2hhbmdl IGFsZ29yaXRobSwgYnV0DQogIHVzZSBFQ0RIRV9FQ0RTQSBpbnN0ZWFkIChsaWtlIEVkRFNBIGRv ZXMpLiBUaGVuIGdldCBhIG5ldyBUTFMgMS4zDQogIHNpZ25hdHVyZVNjaGVtZSB2YWx1ZSwgd2hp Y2ggZGVjb21wb3NlcyB0byB0aGUgY29ycmVzcG9uZGluZyBUTFMNCiAgMS4yIHZhbHVlcyAoc2Vl IFJGQzQ0OTJiaXMgZm9yIGFuIGV4YW1wbGUpLiBIb3dldmVyLCB0aGlzIHJlcXVpcmVzDQogIFRM UyAxLjIgb3IgbmV3ZXIsIGJ1dCB0aGF0IHNob3VsZCBub3QgYmUgYSBwcm9ibGVtLg0KDQotIFRo ZSBwcm9wb3NlZCBjaXBoZXJzdWl0ZXMgYXJlIHJlYWxseSBiYWQuIE5vIG5ldyBibG9ja21vZGUg b3Igc3RyZWFtLQ0KICBtb2RlIGNpcGhlcnMgc2hvdWxkIGJlIGRlZmluZWQgKGVzcGVjaWFsbHkg YmxvY2ttb2RlLCB0aG9zZSBhcmUgYWxtb3N0DQogIGltcG9zc2libGUgdG8gaW1wbGVtZW50IGlu IHNlY3VyZSB3YXkpLiBJZiBFQ0RIRV9FQ0RTQSBpcyB1c2VkLCBvbmUNCiAgYXZvaWRzIGFsbG9j YXRpbmcgYW55IG5ldyBjaXBoZXJzdWl0ZXMuDQoNCi0gU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg bWlzc2luZy4NCg0KLSBJQU5BIGNvbnNpZGVyYXRpb25zIG1pc3NpbmcsIHNob3VsZCBhc2sgZm9y IGFsbG9jYXRpb24gb2YgYWxsDQogIG5ldyBjb2RlcG9pbnRzIChhbmQgdGhhdCBvbmUgT0lEKS4N Cg0KLSBSZWZlcmVuY2VzIHNlY3Rpb24gaXMgZHVwbGljYXRlZC4NCg0KDQoNCi1JbGFyaQ0K From nobody Wed Jul 5 01:40:29 2017 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 D7953131B7A for ; Wed, 5 Jul 2017 01:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=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 7QbCVnojFU9R for ; Wed, 5 Jul 2017 01:40:25 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAAA131B8D for ; Wed, 5 Jul 2017 01:40:21 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 3BDA75C3 for ; Wed, 5 Jul 2017 09:40:15 +0100 (BST) Received: by mail-io0-f178.google.com with SMTP id h64so81979251iod.0 for ; Wed, 05 Jul 2017 01:40:15 -0700 (PDT) X-Gm-Message-State: AIVw111aR0XEi+iH2kb+ievZb+AMFCA8KwYkS+cpkQI6KnC/8rlbDLZu fxKSjulbNXK0s4dBUAU33AU7k1zFHQ== X-Received: by 10.107.166.129 with SMTP id p123mr19811446ioe.15.1499244014317; Wed, 05 Jul 2017 01:40:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.33.66 with HTTP; Wed, 5 Jul 2017 01:40:13 -0700 (PDT) In-Reply-To: <20170704105050.zqclbfje2rvly5dm@LK-Perkele-VII> References: <20170704105050.zqclbfje2rvly5dm@LK-Perkele-VII> From: Matt Caswell Date: Wed, 5 Jul 2017 09:40:13 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 08:40:28 -0000 On 4 July 2017 at 11:50, Ilari Liusvaara wrote: > On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote: >> On 4 July 2017 at 01:01, Eric Rescorla wrote: >> > - Modifying the key derivation for PSKs so that each session ticket >> > is associated with a distinct PSK. >> >> Draft-21 says this about the ticket nonce: >> >> opaque ticket_nonce<1..255>; >> ... >> ticket_nonce A unique per-ticket value. >> >> >> Within what context is "uniqueness" required? I am assuming that >> uniqueness within the context of a single TLS connection is all that >> is needed? > > Yes, It has to be unique within a connection. > >> The nonce can be anything between 1 and 255 bytes long. There is no >> guidance on a suitable length, so I am assuming I can choose anything >> I like as long as the uniqueness constraint is met. OpenSSL >> (currently) only ever issues a single ticket per TLS connection so is >> a single 0 byte sufficient? > > Yes, if you only have one ticket per connection, then any legal fixed > value is acceptable. Thanks. Another slightly confusing thing about the way this is currently specified: The spec says: The PSK associated with the ticket is computed as: HKDF-Expand-Label(resumption_master_secret, "resumption", ticket_nonce, Hash.length) Where HKDF-Expand-Label is defined as: HKDF-Expand-Label(Secret, Label, HashValue, Length) = HKDF-Expand(Secret, HkdfLabel, Length) ... Note that in some cases a zero- length HashValue (indicated by "") is passed to HKDF-Expand-Label. Note that the third parameter here is explicitly expected to be either a hash or "" (i.e. zero length). But in the ticket_nonce case this is NOT a hash value. AFAICT this is the only time in the spec that something other than a hash or "" is used for this parameter. I'm assuming this is intentional and we are supposed to pass the nonce through "as is" (i.e. there is no implicit requirement to hash it first). Probably the definition of HKDF-Expand-Label needs to be updated to allow for this usage. Matt From nobody Wed Jul 5 03:35:46 2017 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 37FD2131C6C for ; Wed, 5 Jul 2017 03:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=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 oT2VfnKjePTd for ; Wed, 5 Jul 2017 03:35:41 -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 8DD94131C29 for ; Wed, 5 Jul 2017 03:35:41 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 63so90836489ywr.0 for ; Wed, 05 Jul 2017 03:35:41 -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=9UVdPD6/Pf7U7Z50gDpyB5+epfMeHxzfOxhMgbsFdn0=; b=RntZx0ifcINztFjWZuIVPsuj9vbj5wxZoMyWenBeYmNsTuDM47mjV8UTarQGFin1pa pSWNw3Y79ADQYJuObprZ62kHwLtUp4VM4rts+vmWYzd5/+YiwbkkhvuRqdTJrz/EzowK wXd6Ci9jJzz6l+ttbIMM1mJXCZhHoy6Me+4T1tCh/62aiGL+3hQYUsQMVzvtfAVuDjjF LnGewuXDsoHtvAabiR5OYG7aOrySVCmYD0r0qx8+VX/SWcm2eGCp5t9OVPyHOVFI1g29 lkOKSx1ZAW9XgnOr8rtsltFi0EUjRWQQYdaWWtAaYW4zq+SRORgGB5Jc0HPxdTIEAFhU w8Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9UVdPD6/Pf7U7Z50gDpyB5+epfMeHxzfOxhMgbsFdn0=; b=jar/9woKwpfYpzkaoO/R/R2eeIWHA0Q2nu5DW465KwgWkJKdtr0tiNUIFWzuW7bxa2 fKS4FnsTNa7uyx5uENDynxCm86rfVIr3555QzpWg7JAtTGpTUW3k3uOydA+RKQzphoY8 kDsL3DnoINMteX5xDFpX7KVDzSEffkv5I7jGZmpfe9PfxAGomaA2mIoKQjBvkNNPDHHL dYAcTkzfgTJoAOrHoTnJXKIjVNkGoZHWAF8R2X/oGy+hKzhln1cgfxqpn+W/3wL90Vpa LIKIqNbsGBUxv1UrF4zmzZpgpadd4KcsYBA7HurxfSNEVnZF/cKNUTVDB1z7sorYw/O5 kHPQ== X-Gm-Message-State: AIVw113iDvH0ySxnYU1gYD4XEEc6s7uxpIs54VpU5cOXzuBeFAsdZCka ihyeOnpwg9EkAKH5Zzo8Ikp5X+fxDkA7sWk= X-Received: by 10.129.118.66 with SMTP id j2mr16744432ywk.85.1499250940743; Wed, 05 Jul 2017 03:35:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Wed, 5 Jul 2017 03:35:00 -0700 (PDT) In-Reply-To: References: <20170704105050.zqclbfje2rvly5dm@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 5 Jul 2017 03:35:00 -0700 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045eed8ac0a9de05538f8fc5" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 10:35:44 -0000 --f403045eed8ac0a9de05538f8fc5 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 1:40 AM, Matt Caswell wrote: > On 4 July 2017 at 11:50, Ilari Liusvaara wrote: > > On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote: > >> On 4 July 2017 at 01:01, Eric Rescorla wrote: > >> > - Modifying the key derivation for PSKs so that each session ticket > >> > is associated with a distinct PSK. > >> > >> Draft-21 says this about the ticket nonce: > >> > >> opaque ticket_nonce<1..255>; > >> ... > >> ticket_nonce A unique per-ticket value. > >> > >> > >> Within what context is "uniqueness" required? I am assuming that > >> uniqueness within the context of a single TLS connection is all that > >> is needed? > > > > Yes, It has to be unique within a connection. > > > >> The nonce can be anything between 1 and 255 bytes long. There is no > >> guidance on a suitable length, so I am assuming I can choose anything > >> I like as long as the uniqueness constraint is met. OpenSSL > >> (currently) only ever issues a single ticket per TLS connection so is > >> a single 0 byte sufficient? > > > > Yes, if you only have one ticket per connection, then any legal fixed > > value is acceptable. > > Thanks. Another slightly confusing thing about the way this is > currently specified: > > The spec says: > > The PSK associated with the ticket is computed as: > > HKDF-Expand-Label(resumption_master_secret, > "resumption", ticket_nonce, Hash.length) > > Where HKDF-Expand-Label is defined as: > > HKDF-Expand-Label(Secret, Label, HashValue, Length) = > HKDF-Expand(Secret, HkdfLabel, Length) > ... > Note that in some cases a zero- length HashValue (indicated by > "") is passed to HKDF-Expand-Label. > > Note that the third parameter here is explicitly expected to be either > a hash or "" (i.e. zero length). But in the ticket_nonce case this is > NOT a hash value. AFAICT this is the only time in the spec that > something other than a hash or "" is used for this parameter. I'm > assuming this is intentional and we are supposed to pass the nonce > through "as is" (i.e. there is no implicit requirement to hash it > first). Probably the definition of HKDF-Expand-Label needs to be > updated to allow for this usage. > Yes, that might not be a terrible idea. I'd also be open to replacing the hashes of 0 with an n-byte length 0 string. It's a tiny paper cut (and a wire format change), but would make things slightly simpler . -Ekr > Matt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403045eed8ac0a9de05538f8fc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 5, 2017 at 1:40 AM, Matt Caswell <frodo@baggins.org>= ; wrote:
On 4 Jul= y 2017 at 11:50, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote:
>> On 4 July 2017 at 01:01, Eric Rescorla <ekr@rtfm.com> wrote:
>> > - Modifying the key derivation for PSKs so that each session = ticket
>> >=C2=A0 =C2=A0is associated with a distinct PSK.
>>
>> Draft-21 says this about the ticket nonce:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque ticket_nonce<1..= 255>;
>> ...
>>=C2=A0 =C2=A0 ticket_nonce=C2=A0 A unique per-ticket value.
>>
>>
>> Within what context is "uniqueness" required? I am assum= ing that
>> uniqueness within the context of a single TLS connection is all th= at
>> is needed?
>
> Yes, It has to be unique within a connection.
>
>> The nonce can be anything between 1 and 255 bytes long. There is n= o
>> guidance on a suitable length, so I am assuming I can choose anyth= ing
>> I like as long as the uniqueness constraint is met. OpenSSL
>> (currently) only ever issues a single ticket per TLS connection so= is
>> a single 0 byte sufficient?
>
> Yes, if you only have one ticket per connection, then any legal fixed<= br> > value is acceptable.

Thanks. Another slightly confusing thing about the way this is
currently specified:

The spec says:

=C2=A0 =C2=A0The PSK associated with the ticket is computed as:

=C2=A0 =C2=A0 =C2=A0 =C2=A0HKDF-Expand-Label(resumption_master_secret,=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "resumption", ticket_nonce, Hash.length)

Where HKDF-Expand-Label is defined as:

=C2=A0 =C2=A0 =C2=A0 =C2=A0HKDF-Expand-Label(Secret, Label, HashValue, Leng= th) =3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HKDF-Expand(Secret, HkdfLabel, Le= ngth)
...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that in some cases a zero- length HashValu= e (indicated by
"") is passed to HKDF-Expand-Label.

Note that the third parameter here is explicitly expected to be either
a hash or "" (i.e. zero length). But in the ticket_nonce case thi= s is
NOT a hash value. AFAICT this is the only time in the spec that
something other than a hash or "" is used for this parameter. I&#= 39;m
assuming this is intentional and we are supposed to pass the nonce
through "as is" (i.e. there is no implicit requirement to hash it=
first). Probably the definition of HKDF-Expand-Label needs to be
updated to allow for this usage.

Yes, t= hat might not be a terrible idea. I'd also be open to replacing
the hashes of 0 with an n-byte length 0 string. It's a tiny paper
cut (and a wire format change), but would make things slightly simp= ler .

-Ekr


Matt

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

--f403045eed8ac0a9de05538f8fc5-- From nobody Wed Jul 5 08:20:08 2017 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 E939F13192B for ; Wed, 5 Jul 2017 08:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 GIvY0zNKTDul for ; Wed, 5 Jul 2017 08:20:04 -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 3595513162F for ; Wed, 5 Jul 2017 08:20:04 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m84so88095703ita.0 for ; Wed, 05 Jul 2017 08:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4YwpuLjLB2IMF0/4cbn2RV+CzluySwyMea0xiglrWgw=; b=nCOE7OKldyJP0juZwyRIR6Ngb2p2U/dalWmma96SvzxDS4IDJv023kHgDZ39Boy7ve IkD7Q1Za0OfhF+owa3p6vcoi0zqTChC1nkFJf1wMsNWeqs+8T+8dJiKBaLcjwcFANJj5 pZ5G7AMkVv7Y0pAE3SDgyeL1Psh6ETN3P5J4NcQNW6mOIMN53enq1/l/cZiJmK3dk/nm bh8X6JNtY3FpzSV023WUwHF6dGCpYCjXzMZgD/MKrMjTfK/3FMMTIZhpc6bQjcuE4s6f 5bTReu55+1PBRsgvifRQ18RyRKzl1uUx8VFT71cWizKyWTJhEkAVQwnSzXDPAZPNwiAG itVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4YwpuLjLB2IMF0/4cbn2RV+CzluySwyMea0xiglrWgw=; b=dNGVC/i2LTfeCiu06nwGR60a8dg46IP7TfSCB578kjZwmZbvECPtxN22Q4Q+tl/7iI nlo3E6R3GgpNrp6ZD+HZ6QQeP4PCQgHMGqJF6fZ7U3shQ+IHF4bvQ2Fg2f6603uvcG5R Fyw8rIWHkAWltl/F5d0KzpxHfmCttTK3MOVimYX+2Wx48Rfak7QLUY8bFuMurxgJH59U RpvHzOSP//qzZ+0JhCrWNb4ZOoRIMeDClLwQzf/NgBeQbR8h27B/gadEe9SAbPpkS4TJ aOSL8cPQVdUGq5N+nV/oXLVUR8bTHtsBFUGYIjXBdX8cQkA5zm5dtxWyTVUkfm5BeTo/ FulA== X-Gm-Message-State: AIVw113dtLRwKo867EIyk9U3+dsXAsSYVc+ISxjwpe97MlUQd7hG84UO GYi7w/qhIK/yo+tpfuVk2Ro70vKAzTit X-Received: by 10.36.44.136 with SMTP id i130mr19284640iti.42.1499268002128; Wed, 05 Jul 2017 08:20:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.69 with HTTP; Wed, 5 Jul 2017 08:20:01 -0700 (PDT) From: Philip Lafrance Date: Wed, 5 Jul 2017 11:20:01 -0400 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="001a113fa266b0b58105539388dd" Archived-At: Subject: [TLS] Regarding multiple signature algorithms in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 15:20:06 -0000 --001a113fa266b0b58105539388dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, I am not certain whether the issue of multiple signature algorithms has previously come up in the TLS 1.3 discussion and was wondering if this is something we need to consider. As many of you know, updating roots of trust to support quantum-resistant algorithms in various devices may be a fairly urgent issue. Fortunately, we can use hash-based algorithms for that soon. Hash-base algorithms can even be used in end-entity certificates for code signing. Now, I am wondering if we will ever have a situation where we will need to support certificate chains in TLS where CA certificates use hash-based algorithms and end-entity certificates use some new stateless signature algorithm. If that is the case, we will need to support multiple digital signatures in one certificate chain. Does TLS 1.3 currently permit negotiating multiple signature algorithms? Admittedly I don=E2=80=99t quite have the current draft memorized, but a cu= rsory reading of v21 seems to suggest that it does not allow for multiple algorithms; simply that the client sends an ordered list of preferred algorithms and the server selects one of them. If not, then does anyone think it is worthwhile to add this functionality to TLS 1.3? Thanks in advance, Philip Lafrance --001a113fa266b0b58105539388dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello all,


I am not certain whether= the issue of multiple signature algorithms has previously come up in the TLS 1.3 discussion and was wonderi= ng if this is something we need to consider.

=C2=A0

As many of you know, updating roots of trust = to support quantum-resistant algorithms in various devices may be a fairly urgent issue.=C2=A0 Fortunately, we can use hash-based algorithms for that soon.=C2=A0 Hash-base algorithms can even be used in end-entity certificates for code signing.

=C2=A0

Now, I am wondering if we will ever have a si= tuation where we will need to support certificate chains in TLS where CA certificates use hash-based algorithms and end-entity certificates use some new stateless signature algorithm.=C2=A0 If that is the case, we will need to support multiple digital signatures in one certificat= e chain.

=C2=A0

Does TLS 1.3 currently permit negotiating mul= tiple signature algorithms?=C2=A0 Admittedly I don=E2=80=99t quite have the current draft memorized, but a cursory reading of v21 seems to sug= gest that it does not allow for multiple algorithms; simply that the client send= s an ordered list of preferred algorithms and the server selects one of them.=C2= =A0 If not, then does anyone think it is worthwhile to add this functionality to TLS 1.3?


Tha= nks in advance,

Philip Lafrance

--001a113fa266b0b58105539388dd-- From nobody Wed Jul 5 09:30:58 2017 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 34B36131D74 for ; Wed, 5 Jul 2017 09:30:56 -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, RP_MATCHES_RCVD=-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 XgRnAguuQIGj for ; Wed, 5 Jul 2017 09:30:55 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7EC5131D4E for ; Wed, 5 Jul 2017 09:30:54 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id E08852421529 for ; Wed, 5 Jul 2017 16:30:49 +0000 (UTC) From: Jim Reid Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> Date: Wed, 5 Jul 2017 17:30:49 +0100 To: TLS WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 16:30:56 -0000 I=E2=80=99ve got a few concerns/issues with the document. 1) There probably needs to be clearer guidance about the use cases for = this extension and the trade-offs between TLS clients doing DNSSEC = validation for themselves instead of sending DNS lookups to a validating = resolver server. How does an application developer decide which approach = would or wouldn=E2=80=99t be appropriate? 2) I=E2=80=99m not sure there is much of an "associated latency = penalty=E2=80=9D from DNS lookups. Something=E2=80=99s going to = esxperience this one way or another. Either the TLS client takes that = hit or the TLS server does it for them before it sends back the = requested DNS data. And in both cases, whatever is making the DNS = lookups should be benefitting from what=E2=80=99s in the resolver=E2=80=99= s cache. That cached data may even have been validated too. 3) Something should be said about algorithm agility. We can be = reasonably sure web browsers, DNS servers, smart phones and so on will = generally have up-to-date DNSSEC validators and/or TLS code. Some TLS = clients -- fire and forget embedded systems, IoT devices, etc -- might = never get updated once they=E2=80=99re deployed. If these clients use = their own DNSSEC validators, they will be screwed when/if DNSSEC drops = SHA1 signatures (say) or adds a new flavour of ECC or even an all-new = signing protocol. 4) It=E2=80=99s not clear if TLS clients can or should cache the DNS = data (and the resulting validations?) returned though this extension. = Suppose a jabber client validates foo.com, does it have to start at the = root and work all the way down to validate bar.com? Could it start that = validation at the previously validated and new cached trust anchor for = .com? Can/should negative answers -- NOHOST/NXDOMAIN responses -- be = cached? 5) How does a TLS client behave when its DNSSEC validation of a TLSA = record or whatever fails? Can/should it give up or fall back to = conventional validation of the certificate via a CA? 6) The draft doesn't seem to take account of key rollovers when DNS data = will be signed by two or more keys. Zone signing keys are missing from = the examples too. These might well have been omitted for cosmetic = reasons. IMO they need to be included in the final document to = illustrate what implementers can expect to find when the DNS returns = signed data. From nobody Wed Jul 5 10:05:28 2017 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 90C0D13167C for ; Wed, 5 Jul 2017 10:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 d8FZgC9XMeHH for ; Wed, 5 Jul 2017 10:05:24 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 D0F8F129B3A for ; Wed, 5 Jul 2017 10:05:24 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v65H2GdC020647 for ; Wed, 5 Jul 2017 18:05:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=RZ/PU8Z1nFexAoc+ayHCbt/WRImQXtCvQ4a98ajzJWM=; b=KvJKjzfSp97AhfaCdibjn2/TXB3ZKSOzAYnJcs379m4RJFEgPIyZX+B6U3xnNlIYIxf0 VdVl1y3jiFF1AiIaZ927EjaJXxKTYjGab5sGKFz8djc2ridBTLzNy4viHb3hK6jaqFNX bXzTYQ9h6pAystvN0uFD9Isk1u9HjmbxzbvYcPm2rO0NoX4pjKF/7GXIscCGf+ApaH2C 744ltjtxFHdiaejh46dJKSpt17WGno4IOkfvFnZD/kr1F5LVwsOWkeIUcM0DHV7CORfJ 2pvDUhV0kabgbzk1ZgG3hNAyWvGHoJDVy23gSQrk27SNVm/SYIo8/t6BffxC4hmEiZAv Pw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bgsdjb72u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 05 Jul 2017 18:05:24 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v65H177Z014430 for ; Wed, 5 Jul 2017 13:05:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72ua9ce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 05 Jul 2017 13:05:22 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 5 Jul 2017 13:05:22 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 5 Jul 2017 13:05:22 -0400 From: "Short, Todd" To: "" Thread-Topic: draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy Thread-Index: AQHS9bDiNeqe7vo/FE2E7FM1ghBmpw== Date: Wed, 5 Jul 2017 17:05:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.117] Content-Type: multipart/alternative; boundary="_000_B57C337271DF4A4EAE80DAEB308C6EB7akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707050286 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707050287 Archived-At: Subject: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 17:05:27 -0000 --_000_B57C337271DF4A4EAE80DAEB308C6EB7akamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 4.2.3 the definitions oaf the signature scheme are thus: enum { ... /* Reserved Code Points */ private_use(0xFE00..0xFFFF), (0xFFFF) } SignatureScheme; This indicates that if the first byte is 254 (0xFE) or 255 (0xFF), that is = is for private use. However, in section 11, a new registry is defined for s= ignature schemes: - TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required [RFC5226]. Values with the first b= yte 255 (decimal) are reserved for Private Use [RFC5226]. Indicates that values with the first byte of 254 are reserved/assigned, and= that private use is for values with a first byte of 255. In addition, the value of 0xFFFF is listed twice in the SignatureScheme enu= meration. I can do a PR, but it needs to be decided wether 0xFE is reserved/assigned = or private_use, and whether 0xFFFF has any special value. -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." --_000_B57C337271DF4A4EAE80DAEB308C6EB7akamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5DB49FF307115E4BAC35DB0242948266@akamai.com> Content-Transfer-Encoding: quoted-printable In section 4.2.3 the definitions oaf the signature scheme are thus: 

enu=
m {
   =
 ...
    /* Reserved Code Points */
    private_use(0xFE00..0xFFFF),
    (0xFFFF)
} S=
ignatureScheme;
This indicates that if the first byte is 254 (0xFE) or 255 = (0xFF), that is is for private use. However, in section 11, a new registry = is defined for signature schemes:

-  =
TLS SignatureScheme Registry: Values with the first byte in the
   range 0-254 (decimal) are assigned via Specification Required
   [RFC=
5226].  Values with the first byte 255 (decimal) are reserved
   for Private Use [RFC5226].

Indicates that values with the first byte of 254 are reserv= ed/assigned, and that private use is for values with a first byte of 255.
In addition, the value of 0xFFFF is listed twice in the Sig= natureScheme enumeration.

I can do a PR, but it needs to be decided wether 0xFE is re= served/assigned or private_use, and whether 0xFFFF has any special value.

--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

--_000_B57C337271DF4A4EAE80DAEB308C6EB7akamaicom_-- From nobody Wed Jul 5 10:12:16 2017 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 A4946131D50 for ; Wed, 5 Jul 2017 10:12: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 VzYnQlYFbRGU for ; Wed, 5 Jul 2017 10:12:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F36129B3A for ; Wed, 5 Jul 2017 10:12:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DD5C17A3309; Wed, 5 Jul 2017 17:12:11 +0000 (UTC) Date: Wed, 5 Jul 2017 17:12:11 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20170705171211.GM5673@mournblade.imrryr.org> Reply-To: tls@ietf.org References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 17:12:14 -0000 On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote: > 1) There probably needs to be clearer guidance about the use cases for > this extension and the trade-offs between TLS clients doing DNSSEC > validation for themselves instead of sending DNS lookups to a validating > resolver server. How does an application developer decide which approach > would or wouldn't be appropriate? On today's Internet, DNSSEC is not generally available to end-user devices. There are too many "last mile" problems. Thus, while direct acquisition of DANE TLSA records works for (e.g.) dedicated SMTP servers, any end-user application that wants to do DANE TLS needs to use the proposed extension. Perhaps you're asking whether once the relevant records are obtained, their validation should be via library calls to a suitable API, or via a suitable protocol to the local resolver? The latter would just be another "suitable API". So I think this issue falls outside proper subject matter for the IETF. Whatever the validation method is, it must avoid using untrusted oracles or leaking the records in the clear. > 2) I'm not sure there is much of an "associated latency penalty" from DNS > lookups. Something's going to experience this one way or another. Either > the TLS client takes that hit or the TLS server does it for them before > it sends back the requested DNS data. Except that the records will be warm in the server's cache, since many clients will be asking it for the *same* data. The same is not as likely to be true at the client. So there is indeed a likely latency reduction in farming out the lookups to the server. > 3) Something should be said about algorithm agility. We can be reasonably > sure web browsers, DNS servers, smart phones and so on will generally have > up-to-date DNSSEC validators and/or TLS code. Some TLS clients -- fire > and forget embedded systems, IoT devices, etc -- might never get updated > once they're deployed. If these clients use their own DNSSEC validators, > they will be screwed when/if DNSSEC drops SHA1 signatures (say) or adds > a new flavour of ECC or even an all-new signing protocol. SHA2 is already defined and widely used for DS records. The X25519 and X448 EC algorithms are already defined (or will be by the time this draft becomes an RFC). So there's not much churn on the immediate horizon. Devices doing all the validation locally will need software updates roughly once a decade (DNS parameters change slowly). A secure channel to a *trusted* resolver would avoid the problem, but trustworthy off-device resolvers are very unlikely to be ubiquitous. > 4) It's not clear if TLS clients can or should cache the DNS data (and > the resulting validations?) returned though this extension. The server will return TTLs, and caching per those TTLs is no less appropriate than it is in DNS generally. > Suppose a > jabber client validates foo.com, does it have to start at the root and > work all the way down to validate bar.com? Could it start that validation > at the previously validated and new cached trust anchor for .com? Can/should > negative answers -- NOHOST/NXDOMAIN responses -- be cached? Negative answers will not generally appear in this protocol, since the server is just returning its TLSA records and associated signatures. The only "negative" answers are NSEC/NSEC3 records that validate wildcard responses. There's little need to cache these, it suffices to just cache the TLSA records associated with the server, and forget the supporting validation RRs. > 5) How does a TLS client behave when its DNSSEC validation of a TLSA record > or whatever fails? Can/should it give up or fall back to conventional > validation of the certificate via a CA? This is application/configuration dependent. -- Viktor. From nobody Wed Jul 5 10:13:35 2017 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 A7F8F131621 for ; Wed, 5 Jul 2017 10:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 D36XZaymWGXX for ; Wed, 5 Jul 2017 10:13:32 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 99FBB129B3A for ; Wed, 5 Jul 2017 10:13:32 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id 84so74315870ybe.0 for ; Wed, 05 Jul 2017 10:13:32 -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=cBd2fflAV9iYKEnlCJaAqi6BzwhB1iB1lOQsu6KlAZo=; b=qFkmd4Vai3Sw1cTW6db8DTv0CVdttXDg5AtISsrHV4DpECfRqVIJ6WgoaKvjb8Ru71 UzFo3YxSKRN3Lzqs8nbQdnWZFrQK/UUVvb3p1FpckOV7lJFPpFv9O7umW9gVe6RofccG GngNJYOkd5Ev7CdhVISICgNN4fAUpVakHiFUGkP3pTZervU5cYYwrAGmLr4EylCw3ZRb W+nnoGKIYTpOsq0Ca+JOjba08JbpdVksMkwy+2rEfGZTJDJaMHGvL3WegxLjUnZrOIiE clAlJpj2NxqftRFF4qPn1DTD2+qyxPwVDjjUtMsSvyP7fdngRybIlwoOhCARFnFxp1Ar yAsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cBd2fflAV9iYKEnlCJaAqi6BzwhB1iB1lOQsu6KlAZo=; b=VXTeEOxcc9m/2VFc9A41h0nQ01ipUzVA3ap5740kwWSFGoWY3QQg9GdfVHuP4pYvoZ UbjvPcI2M6a7HTcF7HpOFYPBrm/R910Wn9Twl+pOwmAvD+yGjr26yBgb1AgmwDihOWvI gpR9TEQGdNhRkiUX49j0mNv0XETx2QSwvxCN8Kopfj1ITo1kvLJXysDiH0a+cvz7YWI4 uAwZr1lpQ3pftrMHBBwihJhbg20CPHu8ShtLdujYmQaqhrSlSgrGjHropW1+5hNl6lw7 AgUAtJ/Qa+mXXtcK8podru7+PkO/qphFzVhR/p8bYEaWhaju9Qy49UluZvQ1nregA4QG bGRg== X-Gm-Message-State: AKS2vOxWegdCKveni2+zh/bCfLEJFhEH53xEIeUS39gg5OIj1kC997f6 rNx83n1xD9Mrf4O75ySlJ3MOY6y0gDHBDgQ= X-Received: by 10.37.118.210 with SMTP id r201mr37438938ybc.15.1499274811637; Wed, 05 Jul 2017 10:13:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Wed, 5 Jul 2017 10:12:51 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 5 Jul 2017 10:12:51 -0700 Message-ID: To: Philip Lafrance Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114bd4c891e52c0553951ef2" Archived-At: Subject: Re: [TLS] Regarding multiple signature algorithms in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 17:13:34 -0000 --001a114bd4c891e52c0553951ef2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, it does not. The way to do that presently would be to have combined algoithms. -Ekr On Wed, Jul 5, 2017 at 8:20 AM, Philip Lafrance wrote: > Hello all, > > > I am not certain whether the issue of multiple signature algorithms has > previously come up in the TLS 1.3 discussion and was wondering if this is > something we need to consider. > > > > As many of you know, updating roots of trust to support quantum-resistant > algorithms in various devices may be a fairly urgent issue. Fortunately, > we can use hash-based algorithms for that soon. Hash-base algorithms can > even be used in end-entity certificates for code signing. > > > > Now, I am wondering if we will ever have a situation where we will need t= o > support certificate chains in TLS where CA certificates use hash-based > algorithms and end-entity certificates use some new stateless signature > algorithm. If that is the case, we will need to support multiple digital > signatures in one certificate chain. > > > > Does TLS 1.3 currently permit negotiating multiple signature algorithms? > Admittedly I don=E2=80=99t quite have the current draft memorized, but a = cursory > reading of v21 seems to suggest that it does not allow for multiple > algorithms; simply that the client sends an ordered list of preferred > algorithms and the server selects one of them. If not, then does anyone > think it is worthwhile to add this functionality to TLS 1.3? > > > Thanks in advance, > > Philip Lafrance > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114bd4c891e52c0553951ef2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, it does not. The way to do that presently would be to = have combined algoithms.

-Ekr

=

On Wed, Jul 5, 20= 17 at 8:20 AM, Philip Lafrance <philip.lafrance92@gmail.com&= gt; wrote:

Hello all,


I am not certain whether= the issue of multiple signature algorithms has previously come up in the TLS 1.3 discussion and was wonderi= ng if this is something we need to consider.

=C2=A0

As many of you know, updating roots of trust = to support quantum-resistant algorithms in various devices may be a fairly urgent issue.=C2=A0 Fortunately, we can use hash-based algorithms for that soon.=C2=A0 Hash-base algorithms can even be used in end-entity certificates for code signing.

=C2=A0

Now, I am wondering if we will ever have a si= tuation where we will need to support certificate chains in TLS where CA certificates use hash-based algorithms and end-entity certificates use some new stateless signature algorithm.=C2=A0 If that is the case, we will need to support multiple digital signatures in one certificat= e chain.

=C2=A0

Does TLS 1.3 currently permit negotiating mul= tiple signature algorithms?=C2=A0 Admittedly I don=E2=80=99t quite have the current draft memorized, but a cursory reading of v21 seems to sug= gest that it does not allow for multiple algorithms; simply that the client send= s an ordered list of preferred algorithms and the server selects one of them.=C2= =A0 If not, then does anyone think it is worthwhile to add this functionality to TLS 1.3?


Tha= nks in advance,

Philip Lafrance


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


--001a114bd4c891e52c0553951ef2-- From nobody Wed Jul 5 10:22:40 2017 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 78B37131D94 for ; Wed, 5 Jul 2017 10:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4H2IQI6T8AJW for ; Wed, 5 Jul 2017 10:22:36 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEAD131D93 for ; Wed, 5 Jul 2017 10:22:35 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id t186so128059664pgb.1 for ; Wed, 05 Jul 2017 10:22: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; bh=N+Fn8q+C1uTiV13Z27GXaP97yyFPAPtYDTXFPaFdRoI=; b=j+OCl4/sf3OgSouN7ujlL7eKii98Uo3tcXP4U/BAOuNtWwfbTtA5IYC4yhg5/KWo/C K675Hhw4U8uH9LoAAK6cIGgfd7EMYP13ifG2XdJULSSzd20ro5lT9AiuhcWtSyFGUzgk PhOEPIZ9iSkCNkB+kTL30MC67eUOvBT8uYgv4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=N+Fn8q+C1uTiV13Z27GXaP97yyFPAPtYDTXFPaFdRoI=; b=Q8vXl8bDHHdJdHpxRvcw8FgzEsMk4uNLEnTqpsApyEp5cJ7Fylnm1cPsGUfKO9dthR Kxy8h1ib6c5lu6oJcdFSvAEYOOVJ35PNZ7AX5T7hrNpGh+D1nevHKfxLVGv/7064mhGl CwRTd+hxV/rFn2mIRBFtDr5kkiIu0ujAZs57T5ghTo6dyXrRbSQ0C8DBkou8W/yybb8V y9WfC9TpIqDJtxJ9rE+dgv+MlhMivRe0idM2y0WyWNhCjf0ZUuM16LTSkUbUBTft8rOQ 5DfZHMbD+k8J159EEwB3RYwVf41UIdwopf/4lk4PtELR73FmjXauLjNmyADiI/MD2VeQ ROQw== X-Gm-Message-State: AIVw110WUImB2bhFTvT1Sy4eOAq3yNp4ArwsiDM89jo6QLCUzi44k7cJ 25H+6xPANsTZF2Fd0AVuNFWawqZMnvqW X-Received: by 10.101.70.137 with SMTP id h9mr22258852pgr.50.1499275354947; Wed, 05 Jul 2017 10:22:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 05 Jul 2017 17:22:23 +0000 Message-ID: To: "Short, Todd" , "" Content-Type: multipart/alternative; boundary="089e08237174f44b140553953e71" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 17:22:38 -0000 --089e08237174f44b140553953e71 Content-Type: text/plain; charset="UTF-8" 0xFFFF is just the syntax for the maximum value in the enum. The intent was to match the HashAlgorithm registry which makes 0xFE and 0xFF the private use values, so I would say the enum is correct and the IANA considerations text is wrong. This ensures we don't collide with any existing TLS 1.2 private use allocations. On Wed, Jul 5, 2017 at 1:05 PM Short, Todd wrote: > In section 4.2.3 the definitions oaf the signature scheme are thus: > > enum { > > ... > /* Reserved Code Points */ > private_use(0xFE00..0xFFFF), > (0xFFFF) > > } SignatureScheme; > > > This indicates that if the first byte is 254 (0xFE) or 255 (0xFF), that is > is for private use. However, in section 11, a new registry is defined for > signature schemes: > > - TLS SignatureScheme Registry: Values with the first byte in the > range 0-254 (decimal) are assigned via Specification Required > [RFC5226 ]. Values with the first byte 255 (decimal) are reserved > for Private Use [RFC5226 ]. > > > Indicates that values with the first byte of 254 are reserved/assigned, > and that private use is for values with a first byte of 255. > In addition, the value of 0xFFFF is listed twice in the SignatureScheme > enumeration. > > I can do a PR, but it needs to be decided wether 0xFE is reserved/assigned > or private_use, and whether 0xFFFF has any special value. > > -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e08237174f44b140553953e71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
0xFFFF is just the syntax for the maximum value in the enu= m.

The intent was to match the HashAlgorithm registry wh= ich makes 0xFE and 0xFF the private use values, so I would say the enum is = correct and the IANA considerations text is wrong. This ensures we don'= t collide with any existing TLS 1.2 private use allocations.

On Wed, Jul 5= , 2017 at 1:05 PM Short, Todd <tshort@akamai.com> wrote:
In section 4.2.3 the definitions oaf the signature scheme are thus: 

enum {
    ...
    /* Reserved Code Points */
    private_use(0xFE00..0xFFFF),
    (0xFFFF)
} SignatureScheme;

This indicates that if the first byte is 254 (0xFE) or 255 (0xFF), tha= t is is for private use. However, in section 11, a new registry is defined = for signature schemes:

-  TLS SignatureScheme Registry: Values with the first byte in the
   range 0-254 (decimal) are assigned via Specification Required
   [RFC5226].  Values with the first byte 255 (decimal) are reserved
   for Private Use [RFC5226].

Indicates that values with the first byte of 254 are reserved/assigned= , and that private use is for values with a first byte of 255.
In addition, the value of 0xFFFF is listed twice in the SignatureSchem= e enumeration.

I can do a PR, but it needs to be decided wether 0xFE is reserved/assi= gned or private_use, and whether 0xFFFF has any special value.

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--089e08237174f44b140553953e71-- From nobody Wed Jul 5 10:23:43 2017 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 7E463131D8B for ; Wed, 5 Jul 2017 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 aqeuMPzCXzhc for ; Wed, 5 Jul 2017 10:23:35 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 99752131D84 for ; Wed, 5 Jul 2017 10:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 2284F28CC5; Wed, 5 Jul 2017 20:23:34 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id cApk5jgwhyB1; Wed, 5 Jul 2017 20:23:33 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C4FF621C; Wed, 5 Jul 2017 20:23:31 +0300 (EEST) Date: Wed, 5 Jul 2017 20:23:31 +0300 From: Ilari Liusvaara To: Philip Lafrance Cc: tls@ietf.org Message-ID: <20170705172331.lwxzacn34nmyacnc@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Regarding multiple signature algorithms in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 17:23:39 -0000 On Wed, Jul 05, 2017 at 11:20:01AM -0400, Philip Lafrance wrote: > Now, I am wondering if we will ever have a situation where we will need to > support certificate chains in TLS where CA certificates use hash-based > algorithms and end-entity certificates use some new stateless signature > algorithm. If that is the case, we will need to support multiple digital > signatures in one certificate chain. You can already mix-and-match algorithms across the chain (by the spec in TLS 1.2 and 1.3, and in practice in earlier versions). However, to use an algorithm for signing key exchange, you need: - TLS SignatureScheme value for it. - PKIX SPKI key OID for it. And to use algorithm for certificate signing: - PKIX SPKI key OID for it. - PKIX signature OID for it. - Preferably TLS SignatureScheme value for it. (The last is not absolute requirement, but doing without is an interop hazard) -Ilari From nobody Wed Jul 5 10:46:27 2017 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 D1F74131560 for ; Wed, 5 Jul 2017 10:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 h7m9fV3R0lpk for ; Wed, 5 Jul 2017 10:46:23 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 129E0131C82 for ; Wed, 5 Jul 2017 10:46:23 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v65Hk8MD024137; Wed, 5 Jul 2017 18:46:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=gwqs1YeX9dQ6GWVY4HecDc8n/6tP+AGPyivMu3pP2aA=; b=gecffBjP00dGmGy9YimPcWTpm+I12r5lmcAq+TIzVgIvcov+lt0YhNXm7VWPS+xAXWv/ wuCNIQAhtoL9XvQm5syXvfjIchJ01eX1jK8xvd9ZbgMrpCNYq5LbPhAbLbbLYlXmngGE 5lZgq7UmwB/Ac87WEh28Fkqckzqfx9vhrHwbCVpp/iZ73d/smkEohPIlgkUJODcq/g3g Kb5/QhFJvUrV15jyQMM1d3VIQs9X+X77wWok5hGfoWiGu7yl0kIJAFQBZ7uQ6Bo5TAGB 3aaE8lFVD3fxJ+YMPi6Yz/+RAMFBUgdIdv6hLzZNVfV4obVnkLtI4qGcvkJW42HCCjOj vQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2bgsdjbdur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2017 18:46:14 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v65HfpQi025457; Wed, 5 Jul 2017 13:45:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2be72vdax9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2017 13:45:07 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 5 Jul 2017 10:45:05 -0700 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 5 Jul 2017 13:45:05 -0400 From: "Short, Todd" To: David Benjamin CC: "" Thread-Topic: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy Thread-Index: AQHS9bDj0lkJXZ4/9kWdg6uG2Gs8UaJFvjOAgAAGVwA= Date: Wed, 5 Jul 2017 17:45:04 +0000 Message-ID: <97CEA734-8BDF-42F2-A465-BC271B9F8DC2@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.117] Content-Type: multipart/alternative; boundary="_000_97CEA7348BDF42F2A465BC271B9F8DC2akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707050296 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707050296 Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 17:46:25 -0000 --_000_97CEA7348BDF42F2A465BC271B9F8DC2akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnV0IHRoZSBtYXhpbXVtIHZhbHVlIGRvZXNu4oCZdCBoYXZlIHRvIGJlIGxpc3RlZCB0d2ljZSBp ZiBpdOKAmXMgYWxyZWFkeSBwYXJ0IG9mIGEgdmFsdWUuDQoNClNvIHNlY3Rpb24gMTEgbmVlZHMg dG8gY2hhbmdlLi4uDQotLQ0KLVRvZGQgU2hvcnQNCi8vIHRzaG9ydEBha2FtYWkuY29tPG1haWx0 bzp0c2hvcnRAYWthbWFpLmNvbT4NCi8vICJPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwg dGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiINCg0KT24gSnVsIDUsIDIwMTcsIGF0IDE6MjIgUE0s IERhdmlkIEJlbmphbWluIDxkYXZpZGJlbkBjaHJvbWl1bS5vcmc8bWFpbHRvOmRhdmlkYmVuQGNo cm9taXVtLm9yZz4+IHdyb3RlOg0KDQoweEZGRkYgaXMganVzdCB0aGUgc3ludGF4IGZvciB0aGUg bWF4aW11bSB2YWx1ZSBpbiB0aGUgZW51bS4NCg0KVGhlIGludGVudCB3YXMgdG8gbWF0Y2ggdGhl IEhhc2hBbGdvcml0aG0gcmVnaXN0cnkgd2hpY2ggbWFrZXMgMHhGRSBhbmQgMHhGRiB0aGUgcHJp dmF0ZSB1c2UgdmFsdWVzLCBzbyBJIHdvdWxkIHNheSB0aGUgZW51bSBpcyBjb3JyZWN0IGFuZCB0 aGUgSUFOQSBjb25zaWRlcmF0aW9ucyB0ZXh0IGlzIHdyb25nLiBUaGlzIGVuc3VyZXMgd2UgZG9u J3QgY29sbGlkZSB3aXRoIGFueSBleGlzdGluZyBUTFMgMS4yIHByaXZhdGUgdXNlIGFsbG9jYXRp b25zLg0KDQpPbiBXZWQsIEp1bCA1LCAyMDE3IGF0IDE6MDUgUE0gU2hvcnQsIFRvZGQgPHRzaG9y dEBha2FtYWkuY29tPG1haWx0bzp0c2hvcnRAYWthbWFpLmNvbT4+IHdyb3RlOg0KSW4gc2VjdGlv biA0LjIuMyB0aGUgZGVmaW5pdGlvbnMgb2FmIHRoZSBzaWduYXR1cmUgc2NoZW1lIGFyZSB0aHVz Og0KDQoNCmVudW0gew0KDQogICAgLi4uDQogICAgLyogUmVzZXJ2ZWQgQ29kZSBQb2ludHMgKi8N CiAgICBwcml2YXRlX3VzZSgweEZFMDAuLjB4RkZGRiksDQogICAgKDB4RkZGRikNCg0KfSBTaWdu YXR1cmVTY2hlbWU7DQoNCg0KVGhpcyBpbmRpY2F0ZXMgdGhhdCBpZiB0aGUgZmlyc3QgYnl0ZSBp cyAyNTQgKDB4RkUpIG9yIDI1NSAoMHhGRiksIHRoYXQgaXMgaXMgZm9yIHByaXZhdGUgdXNlLiBI b3dldmVyLCBpbiBzZWN0aW9uIDExLCBhIG5ldyByZWdpc3RyeSBpcyBkZWZpbmVkIGZvciBzaWdu YXR1cmUgc2NoZW1lczoNCg0KDQotICBUTFMgU2lnbmF0dXJlU2NoZW1lIFJlZ2lzdHJ5OiBWYWx1 ZXMgd2l0aCB0aGUgZmlyc3QgYnl0ZSBpbiB0aGUNCiAgIHJhbmdlIDAtMjU0IChkZWNpbWFsKSBh cmUgYXNzaWduZWQgdmlhIFNwZWNpZmljYXRpb24gUmVxdWlyZWQNCiAgIFtSRkM1MjI2PGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0 Zi5vcmdfaHRtbF9yZmM1MjI2JmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPVFC RWNRc3FvVURkazFRMjZDemx6TlBQVWtLWVdJaDFMWXNpSEF3bXRSaWsmbT1sMTA5X04wX08yamZR aHJUTW1EWEJWY0Vmam5uU19jTmp0Wi1RVXpOdFRZJnM9NXNrX2IzLXZJZWttRkVyajByUmk1R3Bt LWpQWGRxZGxnR0k3eFlBSUxoNCZlPT5dLiAgVmFsdWVzIHdpdGggdGhlIGZpcnN0IGJ5dGUgMjU1 IChkZWNpbWFsKSBhcmUgcmVzZXJ2ZWQNCiAgIGZvciBQcml2YXRlIFVzZSBbUkZDNTIyNjxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmll dGYub3JnX2h0bWxfcmZjNTIyNiZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1R QkVjUXNxb1VEZGsxUTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210UmlrJm09bDEwOV9OMF9PMmpm UWhyVE1tRFhCVmNFZmpublNfY05qdFotUVV6TnRUWSZzPTVza19iMy12SWVrbUZFcmowclJpNUdw bS1qUFhkcWRsZ0dJN3hZQUlMaDQmZT0+XS4NCg0KSW5kaWNhdGVzIHRoYXQgdmFsdWVzIHdpdGgg dGhlIGZpcnN0IGJ5dGUgb2YgMjU0IGFyZSByZXNlcnZlZC9hc3NpZ25lZCwgYW5kIHRoYXQgcHJp dmF0ZSB1c2UgaXMgZm9yIHZhbHVlcyB3aXRoIGEgZmlyc3QgYnl0ZSBvZiAyNTUuDQpJbiBhZGRp dGlvbiwgdGhlIHZhbHVlIG9mIDB4RkZGRiBpcyBsaXN0ZWQgdHdpY2UgaW4gdGhlIFNpZ25hdHVy ZVNjaGVtZSBlbnVtZXJhdGlvbi4NCg0KSSBjYW4gZG8gYSBQUiwgYnV0IGl0IG5lZWRzIHRvIGJl IGRlY2lkZWQgd2V0aGVyIDB4RkUgaXMgcmVzZXJ2ZWQvYXNzaWduZWQgb3IgcHJpdmF0ZV91c2Us IGFuZCB3aGV0aGVyIDB4RkZGRiBoYXMgYW55IHNwZWNpYWwgdmFsdWUuDQoNCi0tDQotVG9kZCBT aG9ydA0KLy8gdHNob3J0QGFrYW1haS5jb208bWFpbHRvOnRzaG9ydEBha2FtYWkuY29tPg0KLy8g Ik9uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQu Ig0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExT IG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX3RscyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1RQkVjUXNxb1VEZGsx UTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210UmlrJm09bDEwOV9OMF9PMmpmUWhyVE1tRFhCVmNF ZmpublNfY05qdFotUVV6TnRUWSZzPUVBV3FEaE1DbzMyUzZjNGRlNlJQRWRwajdwLXRpZjFXei1a YndIUVJSYVkmZT0+DQoNCg== --_000_97CEA7348BDF42F2A465BC271B9F8DC2akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8A2E03ADABCF644781D92B98C197E321@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQnV0IHRoZSBtYXhpbXVtIHZhbHVl IGRvZXNu4oCZdCBoYXZlIHRvIGJlIGxpc3RlZCB0d2ljZSBpZiBpdOKAmXMgYWxyZWFkeSBwYXJ0 IG9mIGEgdmFsdWUuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5TbyBzZWN0aW9uIDExIG5lZWRzIHRvIGNoYW5nZS4uLjxiciBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4tLTwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4tVG9kZCBTaG9ydDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4vLyA8YSBocmVmPSJtYWlsdG86dHNo b3J0QGFrYW1haS5jb20iIGNsYXNzPSIiPnRzaG9ydEBha2FtYWkuY29tPC9hPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4vLyAmcXVvdDtPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhyZWUg aWYgYnkgdGhlIEludGVybmV0LiZxdW90OzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5PbiBKdWwgNSwgMjAxNywgYXQgMToyMiBQTSwgRGF2aWQgQmVuamFtaW4g Jmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZGJlbkBjaHJvbWl1bS5vcmciIGNsYXNzPSIiPmRhdmlk YmVuQGNocm9taXVtLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj4weEZGRkYgaXMganVzdCB0aGUgc3ludGF4IGZvciB0aGUgbWF4aW11bSB2YWx1ZSBpbiB0 aGUgZW51bS4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoZSBpbnRlbnQgd2FzIHRvIG1hdGNoIHRoZSBIYXNoQWxnb3JpdGhtIHJlZ2lzdHJ5IHdo aWNoIG1ha2VzIDB4RkUgYW5kIDB4RkYgdGhlIHByaXZhdGUgdXNlIHZhbHVlcywgc28gSSB3b3Vs ZCBzYXkgdGhlIGVudW0gaXMgY29ycmVjdCBhbmQgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgdGV4 dCBpcyB3cm9uZy4gVGhpcyBlbnN1cmVzIHdlIGRvbid0IGNvbGxpZGUgd2l0aCBhbnkgZXhpc3Rp bmcgVExTIDEuMiBwcml2YXRlDQogdXNlIGFsbG9jYXRpb25zLjwvZGl2Pg0KPGRpdiBkaXI9Imx0 ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPk9uIFdlZCwgSnVsIDUsIDIwMTcg YXQgMTowNSBQTSBTaG9ydCwgVG9kZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRzaG9ydEBha2FtYWku Y29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+dHNob3J0QGFrYW1haS5jb208L2E+Jmd0OyB3 cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiIGNsYXNz PSIiPkluIHNlY3Rpb24gNC4yLjMgdGhlIGRlZmluaXRpb25zIG9hZiB0aGUgc2lnbmF0dXJlIHNj aGVtZSBhcmUgdGh1czoNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibV80OTc5OTc0NzIwODkwNDAyMDA2bV83MTUyNjQxMzUw MTk2Mzk2MzU5bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDow cHg7bWFyZ2luLWJvdHRvbTowcHg7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWwiPmVudW0g ezwvcHJlPg0KPHByZSBjbGFzcz0ibV80OTc5OTc0NzIwODkwNDAyMDA2bV83MTUyNjQxMzUwMTk2 Mzk2MzU5bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7 bWFyZ2luLWJvdHRvbTowcHg7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWwiPiAgICAuLi4N CiAgICAvKiBSZXNlcnZlZCBDb2RlIFBvaW50cyAqLw0KICAgIHByaXZhdGVfdXNlKDB4RkUwMC4u MHhGRkZGKSwNCiAgICAoMHhGRkZGKTwvcHJlPg0KPHByZSBjbGFzcz0ibV80OTc5OTc0NzIwODkw NDAyMDA2bV83MTUyNjQxMzUwMTk2Mzk2MzU5bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4z MzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Zm9udC12YXJpYW50LWxpZ2F0 dXJlczpub3JtYWwiPn0gU2lnbmF0dXJlU2NoZW1lOzwvcHJlPg0KPHByZSBjbGFzcz0ibV80OTc5 OTc0NzIwODkwNDAyMDA2bV83MTUyNjQxMzUwMTk2Mzk2MzU5bmV3cGFnZSIgc3R5bGU9ImZvbnQt c2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Zm9udC12YXJp YW50LWxpZ2F0dXJlczpub3JtYWwiPjxiciBjbGFzcz0iIj48L3ByZT4NCjxkaXYgY2xhc3M9IiI+ VGhpcyBpbmRpY2F0ZXMgdGhhdCBpZiB0aGUgZmlyc3QgYnl0ZSBpcyAyNTQgKDB4RkUpIG9yIDI1 NSAoMHhGRiksIHRoYXQgaXMgaXMgZm9yIHByaXZhdGUgdXNlLiBIb3dldmVyLCBpbiBzZWN0aW9u IDExLCBhIG5ldyByZWdpc3RyeSBpcyBkZWZpbmVkIGZvciBzaWduYXR1cmUgc2NoZW1lczo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PHByZSBjbGFzcz0ibV80OTc5OTc0NzIwODkwNDAyMDA2bV83MTUyNjQxMzUwMTk2Mzk2MzU5bmV3 cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJv dHRvbTowcHg7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWwiPi0gIFRMUyBTaWduYXR1cmVT Y2hlbWUgUmVnaXN0cnk6IFZhbHVlcyB3aXRoIHRoZSBmaXJzdCBieXRlIGluIHRoZQ0KICAgcmFu Z2UgMC0yNTQgKGRlY2ltYWwpIGFyZSBhc3NpZ25lZCB2aWEgU3BlY2lmaWNhdGlvbiBSZXF1aXJl ZA0KICAgWzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1MjI2JmFtcDtkPUR3TUZhUSZhbXA7 Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPVFCRWNRc3FvVURkazFRMjZDemx6TlBQVWtL WVdJaDFMWXNpSEF3bXRSaWsmYW1wO209bDEwOV9OMF9PMmpmUWhyVE1tRFhCVmNFZmpublNfY05q dFotUVV6TnRUWSZhbXA7cz01c2tfYjMtdklla21GRXJqMHJSaTVHcG0talBYZHFkbGdHSTd4WUFJ TGg0JmFtcDtlPSIgdGl0bGU9IiZxdW90O0d1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4gSUFOQSBD b25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MmcXVvdDsiIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5SRkM1MjI2PC9hPl0uICBWYWx1ZXMgd2l0aCB0aGUgZmlyc3QgYnl0ZSAyNTUgKGRlY2lt YWwpIGFyZSByZXNlcnZlZA0KICAgZm9yIFByaXZhdGUgVXNlIFs8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3Jn X2h0bWxfcmZjNTIyNiZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZh bXA7cj1RQkVjUXNxb1VEZGsxUTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210UmlrJmFtcDttPWwx MDlfTjBfTzJqZlFoclRNbURYQlZjRWZqbm5TX2NOanRaLVFVek50VFkmYW1wO3M9NXNrX2IzLXZJ ZWttRkVyajByUmk1R3BtLWpQWGRxZGxnR0k3eFlBSUxoNCZhbXA7ZT0iIHRpdGxlPSImcXVvdDtH dWlkZWxpbmVzIGZvciBXcml0aW5nIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBS RkNzJnF1b3Q7IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+UkZDNTIyNjwvYT5dLjwvcHJlPg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5JbmRpY2F0ZXMgdGhhdCB2YWx1ZXMgd2l0aCB0aGUgZmlyc3QgYnl0ZSBvZiAyNTQgYXJlIHJl c2VydmVkL2Fzc2lnbmVkLCBhbmQgdGhhdCBwcml2YXRlIHVzZSBpcyBmb3IgdmFsdWVzIHdpdGgg YSBmaXJzdCBieXRlIG9mIDI1NS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gYWRkaXRpb24sIHRo ZSB2YWx1ZSBvZiAweEZGRkYgaXMgbGlzdGVkIHR3aWNlIGluIHRoZSBTaWduYXR1cmVTY2hlbWUg ZW51bWVyYXRpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SSBjYW4gZG8gYSBQUiwgYnV0IGl0IG5lZWRz IHRvIGJlIGRlY2lkZWQgd2V0aGVyIDB4RkUgaXMgcmVzZXJ2ZWQvYXNzaWduZWQgb3IgcHJpdmF0 ZV91c2UsIGFuZCB3aGV0aGVyIDB4RkZGRiBoYXMgYW55IHNwZWNpYWwgdmFsdWUuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Imxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4t LTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tVG9kZCBTaG9ydDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4v LyA8YSBocmVmPSJtYWlsdG86dHNob3J0QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj50c2hvcnRAYWthbWFpLmNvbTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ly8gJnF1b3Q7 T25lIGlmIGJ5IGxhbmQsIHR3byBpZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4m cXVvdDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpUTFMgbWFpbGluZyBsaXN0PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPlRMU0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX3RscyZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxa ZyZhbXA7cj1RQkVjUXNxb1VEZGsxUTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210UmlrJmFtcDtt PWwxMDlfTjBfTzJqZlFoclRNbURYQlZjRWZqbm5TX2NOanRaLVFVek50VFkmYW1wO3M9RUFXcURo TUNvMzJTNmM0ZGU2UlBFZHBqN3AtdGlmMVd6LVpid0hRUlJhWSZhbXA7ZT0iIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_97CEA7348BDF42F2A465BC271B9F8DC2akamaicom_-- From nobody Wed Jul 5 10:53:52 2017 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 E64D4131558 for ; Wed, 5 Jul 2017 10:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0humu0hGii74 for ; Wed, 5 Jul 2017 10:53:48 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E13131555 for ; Wed, 5 Jul 2017 10:53:48 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id j186so127783919pge.2 for ; Wed, 05 Jul 2017 10:53:48 -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=oQMOnrXdALuKFSxXDlXBy0wQm+AgWQHkPd08Nw4vluo=; b=DQZfa7jx5aIwh6Nh2/F+ZO4id+FYXcWMyxJEkEYCT4UKCr6lMO2U/rYmasxzcQP4Iq qHLEUISDmHHxOQDgxbWACTkQ1V1LyGKHRhPw3EluIlkvDJz/QTb4vHabN8XUspcgw1PH Xg0UGIV+8wjd4YvwymGiF+rvPxfqCDhtlz8+Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oQMOnrXdALuKFSxXDlXBy0wQm+AgWQHkPd08Nw4vluo=; b=PeB7y/EjUCik+GfEsMDya10JUbJHSIBq8BtVNgNdCCFDLsrRrwNNDF3t2oJpFRIzk6 O6dQFy1Bgg96vleWbLfQe25IDteGXYWT3kPWoOcKRpVk8IyIffjGsnJBaJtqVhxHIlKl Ewhb0VsAL+xCPnFIPKTy0Ac151zb9p0VBb+4Q7Q6aQzE3U5lMs53+BK//TA9ffyRtrW+ UAoU2+OaBpPoFcB+KldMIPFpG7IUj4i6rUKvcVrQaeX/WqE4oJbg2btwl5nuVUyOKZMR trhXr63sNqWgapenB+mgpPWQdUPHP/c150nD2AYHPK0W7LnGmwDyMfwfFADdCbMHMRbv TI9A== X-Gm-Message-State: AIVw110bYkZDQYDrF3PnckcVt83B7aAXDuCGoPFIacZGvQ9A81cTEiza kksjWVsM59NVkHgE+7f9Ex2J76lB2kZL08o= X-Received: by 10.98.210.199 with SMTP id c190mr21466168pfg.161.1499277228223; Wed, 05 Jul 2017 10:53:48 -0700 (PDT) MIME-Version: 1.0 References: <97CEA734-8BDF-42F2-A465-BC271B9F8DC2@akamai.com> In-Reply-To: <97CEA734-8BDF-42F2-A465-BC271B9F8DC2@akamai.com> From: David Benjamin Date: Wed, 05 Jul 2017 17:53:36 +0000 Message-ID: To: "Short, Todd" Cc: "" Content-Type: multipart/alternative; boundary="001a11467c069c2917055395ae4c" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 17:53:51 -0000 --001a11467c069c2917055395ae4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 1:46 PM Short, Todd wrote: > But the maximum value doesn=E2=80=99t have to be listed twice if it=E2=80= =99s already part > of a value. > Ah yes, you're right. My bad. I agree that line should not be there either. > So section 11 needs to change... > > -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Jul 5, 2017, at 1:22 PM, David Benjamin wrote: > > 0xFFFF is just the syntax for the maximum value in the enum. > > The intent was to match the HashAlgorithm registry which makes 0xFE and > 0xFF the private use values, so I would say the enum is correct and the > IANA considerations text is wrong. This ensures we don't collide with any > existing TLS 1.2 private use allocations. > > On Wed, Jul 5, 2017 at 1:05 PM Short, Todd wrote: > >> In section 4.2.3 the definitions oaf the signature scheme are thus: >> >> enum { >> >> ... >> /* Reserved Code Points */ >> private_use(0xFE00..0xFFFF), >> (0xFFFF) >> >> } SignatureScheme; >> >> >> This indicates that if the first byte is 254 (0xFE) or 255 (0xFF), that >> is is for private use. However, in section 11, a new registry is defined >> for signature schemes: >> >> - TLS SignatureScheme Registry: Values with the first byte in the >> range 0-254 (decimal) are assigned via Specification Required >> [RFC5226 ]. Values wit= h the first byte 255 (decimal) are reserved >> for Private Use [RFC5226 ]. >> >> >> Indicates that values with the first byte of 254 are reserved/assigned, >> and that private use is for values with a first byte of 255. >> In addition, the value of 0xFFFF is listed twice in the SignatureScheme >> enumeration. >> >> I can do a PR, but it needs to be decided wether 0xFE is >> reserved/assigned or private_use, and whether 0xFFFF has any special val= ue. >> >> -- >> -Todd Short >> // tshort@akamai.com >> // "One if by land, two if by sea, three if by the Internet." >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > --001a11467c069c2917055395ae4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 5,= 2017 at 1:46 PM Short, Todd <tshor= t@akamai.com> wrote:
But the maximum value doesn=E2=80=99t have to be listed twice if it=E2=80= =99s already part of a value.

Ah yes,= you're right. My bad. I agree that line should not be there either.
=C2=A0
So section 11 needs to change...

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

On Jul 5, 2017, at 1:22 PM, David Benjamin <davidben@chromium.org> wrote:
0xFFFF is just the syntax for the maximum value in the enu= m.

The intent was to match the HashAlgorithm registry which makes 0xFE an= d 0xFF the private use values, so I would say the enum is correct and the I= ANA considerations text is wrong. This ensures we don't collide with an= y existing TLS 1.2 private use allocations.

On Wed, Jul 5, 2017 at 1:05 PM Short, Todd <tshort@akamai.com> wrote= :
In section 4.2.3 the definitions oaf th= e signature scheme are thus: 

enum {
    ...
    /* Reserved Code Points */
    private_use(0xFE00..0xFFFF),
    (0xFFFF)
} SignatureScheme;

This indicates that if the first byte is 254 (0xFE) or 255 (0xFF), tha= t is is for private use. However, in section 11, a new registry is defined = for signature schemes:

-  TLS SignatureScheme Registry: Values with =
the first byte in the
   range 0-254 (decimal) are assigned via Specification Required
   [RFC5226].  Values with the first =
byte 255 (decimal) are reserved
   for Private Use [RFC5226].

Indicates that values with the first byte of 254 are reserved/assigned= , and that private use is for values with a first byte of 255.
In addition, the value of 0xFFFF is listed twice in the SignatureSchem= e enumeration.

I can do a PR, but it needs to be decided wether 0xFE is reserved/assi= gned or private_use, and whether 0xFFFF has any special value.

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

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

--001a11467c069c2917055395ae4c-- From nobody Wed Jul 5 10:55:33 2017 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 E0C78131D98 for ; Wed, 5 Jul 2017 10:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 DsN1slcW9qy7 for ; Wed, 5 Jul 2017 10:55:29 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4CA03131445 for ; Wed, 5 Jul 2017 10:55:29 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v65HrYjP000751; Wed, 5 Jul 2017 18:55:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=yEc7mXBmb2dEslfoWY2Dxw3pbDzXDcijLo3NX3kaA1M=; b=GAfPZz/pjn+uHKjx/K+o/uFKZeMBGN9YdSbUdNsUFONrHJobW8bjGCeSPLQ13WoPfmlq MJhDsyv/qlcUMV005VelHteLasYQ2KIQYpAu/0xmBKer5wA4/2uBeLNF4AETKgkVP1J/ /SAKZQDWYjMvQAL3iefr4BDGcpB5pF7fdFPRqSQUNU+/e9npCSHLjj0Nybr9WsotvjmU anaT2WhEWMeU6wyTFGx6bXhwn1q1PUYXLcmaS+wjrrPMTsaKFkgq/NV/OcPZUiDHjuH6 U9+y0V2zEKD+HyBfeWsnX7G/UjeC6fwVW6MPXnpUQSGOYEYZhzVDdnAgkZvfJes8gf2x JA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2bgaw06q95-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2017 18:55:24 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v65HobAF014970; Wed, 5 Jul 2017 13:55:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2be72uad5k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2017 13:55:23 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 5 Jul 2017 13:55:22 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 5 Jul 2017 13:55:22 -0400 From: "Short, Todd" To: David Benjamin CC: "" Thread-Topic: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy Thread-Index: AQHS9bDj0lkJXZ4/9kWdg6uG2Gs8UaJFvjOAgAAGVwCAAAJiAP//vXAA Date: Wed, 5 Jul 2017 17:55:22 +0000 Message-ID: References: <97CEA734-8BDF-42F2-A465-BC271B9F8DC2@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.23.0.170610 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.117] Content-Type: multipart/alternative; boundary="_000_EB35E4784AB840BAA9DA03344DFA9616akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707050300 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707050301 Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 17:55:32 -0000 --_000_EB35E4784AB840BAA9DA03344DFA9616akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCB3YXNu4oCZdCBpbXBvcnRhbnQgZW5vdWdoIGZvciB0byBjcmVhdGUgYSBQUi4NCg0KSSBk aWQgY3JlYXRlIFBSIDEwNDQgdG8gcmVjb25jaWxlIFM0LjIuMyBhbmQgUzExLg0KDQotLQ0KLVRv ZGQgU2hvcnQNCi8vIHRzaG9ydEBha2FtYWkuY29tDQovLyAiT25lIGlmIGJ5IGxhbmQsIHR3byBp ZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4iDQoNCg0KRnJvbTogRGF2aWQgQmVu amFtaW4gPGRhdmlkYmVuQGNocm9taXVtLm9yZz4NCkRhdGU6IFdlZG5lc2RheSwgSnVseSA1LCAy MDE3IGF0IDE6NTMgUE0NClRvOiAiU2hvcnQsIFRvZGQiIDx0c2hvcnRAYWthbWFpLmNvbT4NCkNj OiAiPHRsc0BpZXRmLm9yZz4iIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gZHJh ZnQtaWV0Zi10bHMtdGxzMTMtMjE6IFNpZ25hdHVyZSBhbGdvcml0aG1zIGRlZmluaXRpb24gZGlz Y3JlcGFuY3kNCg0KT24gV2VkLCBKdWwgNSwgMjAxNyBhdCAxOjQ2IFBNIFNob3J0LCBUb2RkIDx0 c2hvcnRAYWthbWFpLmNvbTxtYWlsdG86dHNob3J0QGFrYW1haS5jb20+PiB3cm90ZToNCkJ1dCB0 aGUgbWF4aW11bSB2YWx1ZSBkb2VzbuKAmXQgaGF2ZSB0byBiZSBsaXN0ZWQgdHdpY2UgaWYgaXTi gJlzIGFscmVhZHkgcGFydCBvZiBhIHZhbHVlLg0KDQpBaCB5ZXMsIHlvdSdyZSByaWdodC4gTXkg YmFkLiBJIGFncmVlIHRoYXQgbGluZSBzaG91bGQgbm90IGJlIHRoZXJlIGVpdGhlci4NCg0KU28g c2VjdGlvbiAxMSBuZWVkcyB0byBjaGFuZ2UuLi4NCg0KLS0NCi1Ub2RkIFNob3J0DQovLyB0c2hv cnRAYWthbWFpLmNvbTxtYWlsdG86dHNob3J0QGFrYW1haS5jb20+DQovLyAiT25lIGlmIGJ5IGxh bmQsIHR3byBpZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4iDQoNCk9uIEp1bCA1 LCAyMDE3LCBhdCAxOjIyIFBNLCBEYXZpZCBCZW5qYW1pbiA8ZGF2aWRiZW5AY2hyb21pdW0ub3Jn PG1haWx0bzpkYXZpZGJlbkBjaHJvbWl1bS5vcmc+PiB3cm90ZToNCg0KMHhGRkZGIGlzIGp1c3Qg dGhlIHN5bnRheCBmb3IgdGhlIG1heGltdW0gdmFsdWUgaW4gdGhlIGVudW0uDQoNClRoZSBpbnRl bnQgd2FzIHRvIG1hdGNoIHRoZSBIYXNoQWxnb3JpdGhtIHJlZ2lzdHJ5IHdoaWNoIG1ha2VzIDB4 RkUgYW5kIDB4RkYgdGhlIHByaXZhdGUgdXNlIHZhbHVlcywgc28gSSB3b3VsZCBzYXkgdGhlIGVu dW0gaXMgY29ycmVjdCBhbmQgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgdGV4dCBpcyB3cm9uZy4g VGhpcyBlbnN1cmVzIHdlIGRvbid0IGNvbGxpZGUgd2l0aCBhbnkgZXhpc3RpbmcgVExTIDEuMiBw cml2YXRlIHVzZSBhbGxvY2F0aW9ucy4NCg0KT24gV2VkLCBKdWwgNSwgMjAxNyBhdCAxOjA1IFBN IFNob3J0LCBUb2RkIDx0c2hvcnRAYWthbWFpLmNvbTxtYWlsdG86dHNob3J0QGFrYW1haS5jb20+ PiB3cm90ZToNCkluIHNlY3Rpb24gNC4yLjMgdGhlIGRlZmluaXRpb25zIG9hZiB0aGUgc2lnbmF0 dXJlIHNjaGVtZSBhcmUgdGh1czoNCg0KDQplbnVtIHsNCg0KICAgIC4uLg0KDQogICAgLyogUmVz ZXJ2ZWQgQ29kZSBQb2ludHMgKi8NCg0KICAgIHByaXZhdGVfdXNlKDB4RkUwMC4uMHhGRkZGKSwN Cg0KICAgICgweEZGRkYpDQoNCn0gU2lnbmF0dXJlU2NoZW1lOw0KDQoNClRoaXMgaW5kaWNhdGVz IHRoYXQgaWYgdGhlIGZpcnN0IGJ5dGUgaXMgMjU0ICgweEZFKSBvciAyNTUgKDB4RkYpLCB0aGF0 IGlzIGlzIGZvciBwcml2YXRlIHVzZS4gSG93ZXZlciwgaW4gc2VjdGlvbiAxMSwgYSBuZXcgcmVn aXN0cnkgaXMgZGVmaW5lZCBmb3Igc2lnbmF0dXJlIHNjaGVtZXM6DQoNCg0KLSAgVExTIFNpZ25h dHVyZVNjaGVtZSBSZWdpc3RyeTogVmFsdWVzIHdpdGggdGhlIGZpcnN0IGJ5dGUgaW4gdGhlDQoN CiAgIHJhbmdlIDAtMjU0IChkZWNpbWFsKSBhcmUgYXNzaWduZWQgdmlhIFNwZWNpZmljYXRpb24g UmVxdWlyZWQNCg0KICAgW1JGQzUyMjY8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzUyMjYmZD1Ed01GYVEm Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9UUJFY1FzcW9VRGRrMVEyNkN6bHpOUFBVa0tZV0lo MUxZc2lIQXdtdFJpayZtPWwxMDlfTjBfTzJqZlFoclRNbURYQlZjRWZqbm5TX2NOanRaLVFVek50 VFkmcz01c2tfYjMtdklla21GRXJqMHJSaTVHcG0talBYZHFkbGdHSTd4WUFJTGg0JmU9Pl0uICBW YWx1ZXMgd2l0aCB0aGUgZmlyc3QgYnl0ZSAyNTUgKGRlY2ltYWwpIGFyZSByZXNlcnZlZA0KDQog ICBmb3IgUHJpdmF0ZSBVc2UgW1JGQzUyMjY8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzUyMjYmZD1Ed01G YVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9UUJFY1FzcW9VRGRrMVEyNkN6bHpOUFBVa0tZ V0loMUxZc2lIQXdtdFJpayZtPWwxMDlfTjBfTzJqZlFoclRNbURYQlZjRWZqbm5TX2NOanRaLVFV ek50VFkmcz01c2tfYjMtdklla21GRXJqMHJSaTVHcG0talBYZHFkbGdHSTd4WUFJTGg0JmU9Pl0u DQoNCkluZGljYXRlcyB0aGF0IHZhbHVlcyB3aXRoIHRoZSBmaXJzdCBieXRlIG9mIDI1NCBhcmUg cmVzZXJ2ZWQvYXNzaWduZWQsIGFuZCB0aGF0IHByaXZhdGUgdXNlIGlzIGZvciB2YWx1ZXMgd2l0 aCBhIGZpcnN0IGJ5dGUgb2YgMjU1Lg0KSW4gYWRkaXRpb24sIHRoZSB2YWx1ZSBvZiAweEZGRkYg aXMgbGlzdGVkIHR3aWNlIGluIHRoZSBTaWduYXR1cmVTY2hlbWUgZW51bWVyYXRpb24uDQoNCkkg Y2FuIGRvIGEgUFIsIGJ1dCBpdCBuZWVkcyB0byBiZSBkZWNpZGVkIHdldGhlciAweEZFIGlzIHJl c2VydmVkL2Fzc2lnbmVkIG9yIHByaXZhdGVfdXNlLCBhbmQgd2hldGhlciAweEZGRkYgaGFzIGFu eSBzcGVjaWFsIHZhbHVlLg0KDQotLQ0KLVRvZGQgU2hvcnQNCi8vIHRzaG9ydEBha2FtYWkuY29t PG1haWx0bzp0c2hvcnRAYWthbWFpLmNvbT4NCi8vICJPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5 IHNlYSwgdGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiINCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9y ZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90bHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMmZD1Ed01GYVEmYz05NlpiWlpj YU1GNHcwRjRqcE42TFpnJnI9UUJFY1FzcW9VRGRrMVEyNkN6bHpOUFBVa0tZV0loMUxZc2lIQXdt dFJpayZtPWwxMDlfTjBfTzJqZlFoclRNbURYQlZjRWZqbm5TX2NOanRaLVFVek50VFkmcz1FQVdx RGhNQ28zMlM2YzRkZTZSUEVkcGo3cC10aWYxV3otWmJ3SFFSUmFZJmU9Pg0KDQo= --_000_EB35E4784AB840BAA9DA03344DFA9616akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291 cmllcjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHdhc27igJl0IGltcG9ydGFu dCBlbm91Z2ggZm9yIHRvIGNyZWF0ZSBhIFBSLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRp ZCBjcmVhdGUgUFIgMTA0NCB0byByZWNvbmNpbGUgUzQuMi4zIGFuZCBTMTEuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tVG9kZCBT aG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+Ly8gdHNob3J0QGFrYW1haS5jb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi8vICZxdW90O09uZSBpZiBi eSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuJnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+RGF2aWQgQmVuamFtaW4gJmx0O2RhdmlkYmVuQGNocm9taXVtLm9yZyZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdWx5IDUsIDIwMTcgYXQgMTo1MyBQTTxicj4N CjxiPlRvOiA8L2I+JnF1b3Q7U2hvcnQsIFRvZGQmcXVvdDsgJmx0O3RzaG9ydEBha2FtYWkuY29t Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7Jmx0O3Rsc0BpZXRmLm9yZyZndDsmcXVvdDsgJmx0 O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUTFNdIGRyYWZ0LWll dGYtdGxzLXRsczEzLTIxOiBTaWduYXR1cmUgYWxnb3JpdGhtcyBkZWZpbml0aW9uIGRpc2NyZXBh bmN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+T24gV2VkLCBKdWwgNSwgMjAxNyBhdCAxOjQ2IFBNIFNob3J0LCBUb2Rk ICZsdDs8YSBocmVmPSJtYWlsdG86dHNob3J0QGFrYW1haS5jb20iPnRzaG9ydEBha2FtYWkuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkJ1dCB0aGUg bWF4aW11bSB2YWx1ZSBkb2VzbuKAmXQgaGF2ZSB0byBiZSBsaXN0ZWQgdHdpY2UgaWYgaXTigJlz IGFscmVhZHkgcGFydCBvZiBhIHZhbHVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFoIHllcywgeW91J3JlIHJpZ2h0LiBNeSBi YWQuIEkgYWdyZWUgdGhhdCBsaW5lIHNob3VsZCBub3QgYmUgdGhlcmUgZWl0aGVyLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+U28gc2VjdGlvbiAxMSBuZWVkcyB0byBjaGFuZ2UuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPi1Ub2RkIFNob3J0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ly8gPGEgaHJlZj0ibWFpbHRvOnRzaG9ydEBh a2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQp0c2hvcnRAYWthbWFpLmNvbTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4vLyAmcXVvdDtP bmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBKdWwg NSwgMjAxNywgYXQgMToyMiBQTSwgRGF2aWQgQmVuamFtaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpk YXZpZGJlbkBjaHJvbWl1bS5vcmciIHRhcmdldD0iX2JsYW5rIj5kYXZpZGJlbkBjaHJvbWl1bS5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ MHhGRkZGIGlzIGp1c3QgdGhlIHN5bnRheCBmb3IgdGhlIG1heGltdW0gdmFsdWUgaW4gdGhlIGVu dW0uDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGludGVudCB3 YXMgdG8gbWF0Y2ggdGhlIEhhc2hBbGdvcml0aG0gcmVnaXN0cnkgd2hpY2ggbWFrZXMgMHhGRSBh bmQgMHhGRiB0aGUgcHJpdmF0ZSB1c2UgdmFsdWVzLCBzbyBJIHdvdWxkIHNheSB0aGUgZW51bSBp cyBjb3JyZWN0IGFuZCB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyB0ZXh0IGlzIHdyb25nLiBUaGlz IGVuc3VyZXMgd2UgZG9uJ3QgY29sbGlkZSB3aXRoDQogYW55IGV4aXN0aW5nIFRMUyAxLjIgcHJp dmF0ZSB1c2UgYWxsb2NhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+T24gV2VkLCBKdWwgNSwgMjAxNyBhdCAxOjA1IFBNIFNob3J0LCBU b2RkICZsdDs8YSBocmVmPSJtYWlsdG86dHNob3J0QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5r Ij50c2hvcnRAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5JbiBzZWN0aW9uIDQuMi4zIHRoZSBkZWZpbml0aW9ucyBvYWYgdGhlIHNpZ25h dHVyZSBzY2hlbWUgYXJlIHRodXM6DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO2ZvbnQtdmFyaWFu dC1saWdhdHVyZXM6bm9ybWFsIj5lbnVtIHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbjtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgLyogUmVzZXJ2ZWQgQ29kZSBQb2ludHMgKi88bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IHByaXZhdGVfdXNlKDB4RkUwMC4uMHhGRkZGKSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICgweEZGRkYpPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47Zm9udC12YXJpYW50LWxp Z2F0dXJlczpub3JtYWwiPn0gU2lnbmF0dXJlU2NoZW1lOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5UaGlzIGluZGljYXRlcyB0aGF0IGlmIHRoZSBmaXJzdCBieXRl IGlzIDI1NCAoMHhGRSkgb3IgMjU1ICgweEZGKSwgdGhhdCBpcyBpcyBmb3IgcHJpdmF0ZSB1c2Uu IEhvd2V2ZXIsIGluIHNlY3Rpb24gMTEsIGEgbmV3IHJlZ2lzdHJ5IGlzIGRlZmluZWQgZm9yIHNp Z25hdHVyZSBzY2hlbWVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtmb250LXZhcmlh bnQtbGlnYXR1cmVzOm5vcm1hbCI+LSZuYnNwOyBUTFMgU2lnbmF0dXJlU2NoZW1lIFJlZ2lzdHJ5 OiBWYWx1ZXMgd2l0aCB0aGUgZmlyc3QgYnl0ZSBpbiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7IHJhbmdlIDAtMjU0IChkZWNp bWFsKSBhcmUgYXNzaWduZWQgdmlhIFNwZWNpZmljYXRpb24gUmVxdWlyZWQ8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7IFs8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rv b2xzLmlldGYub3JnX2h0bWxfcmZjNTIyNiZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3 MEY0anBONkxaZyZhbXA7cj1RQkVjUXNxb1VEZGsxUTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210 UmlrJmFtcDttPWwxMDlfTjBfTzJqZlFoclRNbURYQlZjRWZqbm5TX2NOanRaLVFVek50VFkmYW1w O3M9NXNrX2IzLXZJZWttRkVyajByUmk1R3BtLWpQWGRxZGxnR0k3eFlBSUxoNCZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7R3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJQU5B IENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyZxdW90OyI+UkZDNTIyNjwvYT5dLiZuYnNw OyBWYWx1ZXMgd2l0aCB0aGUgZmlyc3QgYnl0ZSAyNTUgKGRlY2ltYWwpIGFyZSByZXNlcnZlZDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJz cDsgZm9yIFByaXZhdGUgVXNlIFs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNTIyNiZhbXA7 ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1RQkVjUXNxb1VEZGsx UTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210UmlrJmFtcDttPWwxMDlfTjBfTzJqZlFoclRNbURY QlZjRWZqbm5TX2NOanRaLVFVek50VFkmYW1wO3M9NXNrX2IzLXZJZWttRkVyajByUmk1R3BtLWpQ WGRxZGxnR0k3eFlBSUxoNCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7R3Vp ZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZD cyZxdW90OyI+UkZDNTIyNjwvYT5dLjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+SW5kaWNhdGVzIHRoYXQgdmFsdWVzIHdpdGggdGhlIGZpcnN0IGJ5dGUg b2YgMjU0IGFyZSByZXNlcnZlZC9hc3NpZ25lZCwgYW5kIHRoYXQgcHJpdmF0ZSB1c2UgaXMgZm9y IHZhbHVlcyB3aXRoIGEgZmlyc3QgYnl0ZSBvZiAyNTUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SW4g YWRkaXRpb24sIHRoZSB2YWx1ZSBvZiAweEZGRkYgaXMgbGlzdGVkIHR3aWNlIGluIHRoZSBTaWdu YXR1cmVTY2hlbWUgZW51bWVyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgY2FuIGRvIGEgUFIsIGJ1dCBpdCBuZWVkcyB0byBiZSBk ZWNpZGVkIHdldGhlciAweEZFIGlzIHJlc2VydmVkL2Fzc2lnbmVkIG9yIHByaXZhdGVfdXNlLCBh bmQgd2hldGhlciAweEZGRkYgaGFzIGFueSBzcGVjaWFsIHZhbHVlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tLTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPi1Ub2RkIFNob3J0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Ly8gPGEgaHJlZj0ibWFp bHRvOnRzaG9ydEBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQp0c2hvcnRAYWthbWFpLmNv bTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4vLyAmcXVvdDtPbmUgaWYgYnkgbGFuZCwgdHdvIGlm IGJ5IHNlYSwgdGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiZxdW90OzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9fdGxzJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42 TFpnJmFtcDtyPVFCRWNRc3FvVURkazFRMjZDemx6TlBQVWtLWVdJaDFMWXNpSEF3bXRSaWsmYW1w O209bDEwOV9OMF9PMmpmUWhyVE1tRFhCVmNFZmpublNfY05qdFotUVV6TnRUWSZhbXA7cz1FQVdx RGhNQ28zMlM2YzRkZTZSUEVkcGo3cC10aWYxV3otWmJ3SFFSUmFZJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_EB35E4784AB840BAA9DA03344DFA9616akamaicom_-- From nobody Wed Jul 5 14:15:04 2017 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 EA395131762 for ; Wed, 5 Jul 2017 14:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xsg3HDoyPd_3 for ; Wed, 5 Jul 2017 14:15:01 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24193131A2B for ; Wed, 5 Jul 2017 14:15:01 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id z78so704324lff.0 for ; Wed, 05 Jul 2017 14:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t72mvSvVr38RwF60e/FB5sKu/ByL2GkcrN/oUM8TNRQ=; b=G/OnsgGFwmKj9xsRYUfLzUqJ27JLYM7s58ZWKf2uaSRtEhtauieU/ILIC9dnLNhM4Z biBNC+VyQHbMDK/pViKsAZo0StSw21xCOrjlS9mJ6SCRPUib20CR4fZ36vzz3S4iGBf6 WyWEuoJED0nqgdSmWDwe33cy4/+XrWBfN9xV0zX3KCj0on0qSD3/HQEKmOxxdqrta46U 3yZGYlxbPwkH6Ke97PoPtOYMZWccmcYUsm7l7wqe1CZj+A7/PBySQR18duUsQ/dwGXcU DDdcSj5yCZVejpMlGIExSQrDae3MiGjaeHl5NVoWCl1R3MYUVmRDC0t+IeXK7qu0YFGQ yh4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t72mvSvVr38RwF60e/FB5sKu/ByL2GkcrN/oUM8TNRQ=; b=Z6e+k0DCdstyBCebCRXNIsabOpK40Nc64ujrF6iuos49oyVhJjju4i14svPVePfAcL wLhqza+HdEzWvVPwbOKaSLfoeBke73cfhLFFU5RW4GZUtOgaq2XO1eQt5ut5aLGLoxpX GbPrTI0vh/tNxD6xZfARxQQhG4yDmz7B7JmHzGgh553ydbV/WfVQl3oBE73bGptlYmQD GIedvPMIstrFvdVXL0e48NjZYjtctVCiP0iRE7o6xJcSePLUjdTyv/VYuQFsRmtRdzQa UbWqQkM451ubOsSO5QbXprSI7p4+ZkmTf3o9XjrenYF0ygqqjgFa3ctFBLjvRIoojg0E 5IrQ== X-Gm-Message-State: AKS2vOzYJ992D/XwgPtfeX/ijJ9FNhrlTqHhlyMJykhO/AclOcJ2gGy3 BtY9LY28p8VAF8m2TBmdfZr4bGpX3y18 X-Received: by 10.25.28.70 with SMTP id c67mr17086078lfc.130.1499289299463; Wed, 05 Jul 2017 14:14:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Wed, 5 Jul 2017 14:14:58 -0700 (PDT) In-Reply-To: References: <20170704105050.zqclbfje2rvly5dm@LK-Perkele-VII> From: Martin Thomson Date: Thu, 6 Jul 2017 07:14:58 +1000 Message-ID: To: Eric Rescorla Cc: Matt Caswell , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 21:15:03 -0000 On 5 July 2017 at 20:35, Eric Rescorla wrote: > Yes, that might not be a terrible idea. I'd also be open to replacing > the hashes of 0 with an n-byte length 0 string. It's a tiny paper > cut (and a wire format change), but would make things slightly simpler . I think that would be best. With the change to the transcript hash, the context would then be: 1. a transcript hash (size = hash function output) 2. 0 (size = 0) 3. ticket nonce (size = 1..255) Out of interest, why not permit 0 length ticket nonces for those of us that don't issue multiple tickets? I think that we should take the hit and make the change. From nobody Wed Jul 5 14:17:31 2017 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 D22E012EA6A for ; Wed, 5 Jul 2017 14:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 Y95ocxi9EJNg for ; Wed, 5 Jul 2017 14:17:28 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002: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 85A8A1243F6 for ; Wed, 5 Jul 2017 14:17:28 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id e201so404536ybb.1 for ; Wed, 05 Jul 2017 14:17:28 -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=dOZ+IZOUitYfBATr+p+3O/ImhhfFjzXRl+Uu8fxRgFk=; b=vMUjEBfMhY6hVdMfBlWkgQqo+8I7A4TzE1UM39MQmh93Wk3SgD/1g234sR/xBH2Ntq SI8PGv8K5h/zAaPwhs7VBsqbyU4+B5HdBdPekMiH1V3eTEDhXZn5BQCkGWfG4y9jvrNH f1yOEVDYRZJrppbZ1xEHsWRGDJQ4QJvDs8NMAqvpBOm+mhAx00ogDkTGVyvreRZSqiNH N5ld3yMDwcG+fdJNixheRqtv9l9Wk8pupd8Zx6brX+EeQ/vqN/t4DbfOUpJ9UW9Jsljj G3BtiLPFQew/JMgo6chsMKCcYLE1xTe693pwroUWzCEl+qPSiguezlVbqYzWEiVpFfx7 U9TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dOZ+IZOUitYfBATr+p+3O/ImhhfFjzXRl+Uu8fxRgFk=; b=W2ow+lO4D+hm2CndKQCtlHRr0NonYinptmmjnQGhcTKEWjgw6Q9A4yduORBcg+sWPN 5xpDpa6ynz7NSEc2YTKdKfX+ULreVM9ej8/jP+By2GUm9SvV93Y1ZRSnxII/ig7uR2Fi WCdkWbVl7wYrHzUaaruVS9qujA10Cuw+Jr5Jkz4bJkPHEz2crQiy6mesQGFrzJH97Wmt qzAnKqjrJkxG0ux1gaPT32xe3y0ODPTq/rd+x+hb8MyA9k1oJrXNW4naO7wv8HPkQ9zQ F4qVIRQg8gmeyfPrjqCGAJza5+RS5ulsFmVpSKk7ei8OisqR6dEp6/fMlKAHBwSDgxV0 lckg== X-Gm-Message-State: AIVw113nA+by2zb299Pv38Z2MFqfCju2E4tR8T5c9ATr6J4PQgRtJL6v YI8bR8ezKq9YKlmKEckmTud0wMrwx59JQBA= X-Received: by 10.37.42.10 with SMTP id q10mr136512ybq.71.1499289447744; Wed, 05 Jul 2017 14:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Wed, 5 Jul 2017 14:16:47 -0700 (PDT) In-Reply-To: References: <20170704105050.zqclbfje2rvly5dm@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 5 Jul 2017 14:16:47 -0700 Message-ID: To: Martin Thomson Cc: Matt Caswell , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11440108f30974055398860f" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2017 21:17:30 -0000 --001a11440108f30974055398860f Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 2:14 PM, Martin Thomson wrote: > On 5 July 2017 at 20:35, Eric Rescorla wrote: > > Yes, that might not be a terrible idea. I'd also be open to replacing > > the hashes of 0 with an n-byte length 0 string. It's a tiny paper > > cut (and a wire format change), but would make things slightly simpler . > > I think that would be best. With the change to the transcript hash, > the context would then be: > 1. a transcript hash (size = hash function output) > 2. 0 (size = 0) > 3. ticket nonce (size = 1..255) > Yeah, I can do a PR for this. Out of interest, why not permit 0 length ticket nonces for those of us > that don't issue multiple tickets? > That seems fine too. I think that we should take the hit and make the change. > -Ekr --001a11440108f30974055398860f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 5, 2017 at 2:14 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 5 July 2017 at 20:35, Eric Rescorla <ekr@rtfm.com> wrote:
> Yes, that might not be a terrible idea. I'd also be open to replac= ing
> the hashes of 0 with an n-byte length 0 string. It's a tiny paper<= br> > cut (and a wire format change), but would make things slightly simpler= .

I think that would be best.=C2=A0 With the change to the transcript = hash,
the context would then be:
1. a transcript hash (size =3D hash function output)
2. 0 (size =3D 0)
3. ticket nonce (size =3D 1..255)

Yeah,= I can do a PR for this.


Out of interest, why not permit 0 length ticket nonces for those of us
that don't issue multiple tickets?

= That seems fine too.


I think that we should take the hit and make the change.

-Ekr
=C2=A0

--001a11440108f30974055398860f-- From nobody Wed Jul 5 19:19:31 2017 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 1CD6512EBFF for ; Wed, 5 Jul 2017 19:19:24 -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, RP_MATCHES_RCVD=-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=iij.ad.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiCY_CdIhu1a for ; Wed, 5 Jul 2017 19:19:21 -0700 (PDT) Received: from omgo.iij.ad.jp (mo900.iij.ad.jp [202.232.31.76]) (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 9FC0F12EC4D for ; Wed, 5 Jul 2017 19:19:21 -0700 (PDT) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1499307560; x=1500517160; bh=CmOh2luBPjEYESyWcPofjcuFPH9CTq5oRD03G6TMOWg=; b=vEJsBY7Rg3aNL0A1Ufzh5JKZU0d vMfW9I2v1NV1CLx2HbCNhieWoTiLul1xCvZB+ANq6zaZ9ilqR7DlnVy/88GKnYt6VAI8Ss2nHV/+b eQqflQfCm98n0f2Dtf2DJpeJ/Gg9mbp7jbhD+MZcfMB+j1OtNLA8jcGA9B12G9y/1bc98n+1XZAxX +aWpxrdlRw0ypjOU4YGZBPLs+2WVA3MkHhixIGKSeY3+S7fpWwYkFKHo+cjaonyW1Pqr4pROVEBcq RinvX5Ut3WDA+YafeJEFV7wkVFC5ddJAultmGTZ7xZLKbbv95OYGVgXcMory8BOm284KDRNdnOIuJ hsfvyIA==; Received: by omgo.iij.ad.jp (mo900) id v662JKpj016918; Thu, 6 Jul 2017 11:19:20 +0900 X-Iguazu-Qid: 33PuoJClv5lzxQ3RJI Date: Thu, 06 Jul 2017 11:19:18 +0900 (JST) Message-Id: <20170706.111918.990342802355467009.kazu@iij.ad.jp> To: tls@ietf.org From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2017 02:19:24 -0000 >> I think that would be best. With the change to the transcript hash, >> the context would then be: >> 1. a transcript hash (size = hash function output) >> 2. 0 (size = 0) >> 3. ticket nonce (size = 1..255) >> > > Yeah, I can do a PR for this. HKDF-Expand-Label(Secret, Label, HashValue, Length) = HKDF-Expand(Secret, HkdfLabel, Length) So, HashValue is not a hash value anymore. It should be "Value" or something. The definitions would be: HKDF-Expand-Label(Secret, Label, *Value*, Length) = HKDF-Expand(Secret, HkdfLabel, Length) struct { uint16 length = *Value.length*; opaque label<7..255> = "tls13 " + Label; opaque hash_value<0..255> = *Value*; } HkdfLabel; --Kazu From nobody Wed Jul 5 19:27:23 2017 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 4CC02129B2D for ; Wed, 5 Jul 2017 19:27:22 -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 aXtkC3N4_fv9 for ; Wed, 5 Jul 2017 19:27:21 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D27126E3A for ; Wed, 5 Jul 2017 19:27:20 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id z78so3448086lff.0 for ; Wed, 05 Jul 2017 19:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1wm7DABFJm7ff+E/CrWpad4SvK4BRsOIIkffXMyRU/Y=; b=MfmNkKUu0Yb9cgFuwcMqzZUxHoKWG/lg8zk7dPQdXCMES8vD+xK2D4Df2VSUOG3YX9 l07o5w/1yx3/RTHXC/eq6iw5j/jpwMnWS98Y8JxOCp2UTHqf8+r60B73VtEhXSpK1uA9 VlOjZlHS16uLuqGS6ovYYouaPKJTQ2cr4inLuxmQ8b1jm0Hy5xzZ3lBcfwYGoL1nZbrY 0hwRjxzaZeN+1FdT9GeEZU24uxL/LIKvrZ0bzonsF0XLPdGbPY+/8QHuIdmIg3I4Zg+G 1sHEMUy0ChrwHg0e/dUcCVLwMPpZS+i3f0+1FwDaV0hPSN0DUCGYo8SXy46R8w4vr7Pz +a2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1wm7DABFJm7ff+E/CrWpad4SvK4BRsOIIkffXMyRU/Y=; b=GdfQB7S0lgB9VOQw/UdNJNhIFsxcYZc5Y1ut2m4vvzMIHju54F46UsdrwHn45LVpa6 e0a/L8mnV/rS1fZEwT0hHsdlxvZ54LM7DBfW9T1kTGqDY4ImESvq+h5VZ1zOicPBwZyV Rsc+vPuL1O2W2T7WYzS7Cgcs1lbxk+Q47uc/5eFfvi//W5yeu04m7jyo3rgTrb+NEqjY f/W35Jr0pXDnz85LPTQgGhxMjOP1wcJBM67ab+NJZ5Vqb6BN1c9TDB08K2MVIp0g8/8v ewfL96uSaSVUKT95iwejwSioQWL1AwcfsTHUPKuZ4fC8w+1YLgTtHwwiFkVb8elvQPkW ckJA== X-Gm-Message-State: AKS2vOyaYrT4DOD/jy7DZMOq56xaUnMKPnjxiDPEPLGZ/geotlnTg/ES geuZY7twI2MnbTYv1rpJF/I7bR9Ajg== X-Received: by 10.46.81.26 with SMTP id f26mr14260142ljb.33.1499308038988; Wed, 05 Jul 2017 19:27:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Wed, 5 Jul 2017 19:27:18 -0700 (PDT) In-Reply-To: <20170706.111918.990342802355467009.kazu@iij.ad.jp> References: <20170706.111918.990342802355467009.kazu@iij.ad.jp> From: Martin Thomson Date: Thu, 6 Jul 2017 12:27:18 +1000 Message-ID: To: Kazu Yamamoto Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2017 02:27:22 -0000 On 6 July 2017 at 12:19, Kazu Yamamoto wrote: > The definitions would be: > > HKDF-Expand-Label(Secret, Label, *Value*, Length) = > HKDF-Expand(Secret, HkdfLabel, Length) > > struct { > uint16 length = *Value.length*; > opaque label<7..255> = "tls13 " + Label; > opaque hash_value<0..255> = *Value*; > } HkdfLabel; Length is the size of the output, so you don't want to assign Value.length to that field in the struct. Also, you forgot to rename hash_value in the struct. The name "context" strikes me as a good choice here. It shares a neat parallel with the name used in exporters. But I trust that ekr will find a reasonable way of solving this. From nobody Wed Jul 5 21:06:33 2017 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 ED5F7129AF6 for ; Wed, 5 Jul 2017 21:06:31 -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, RP_MATCHES_RCVD=-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=iij.ad.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3PxO7vIK1OL for ; Wed, 5 Jul 2017 21:06:29 -0700 (PDT) Received: from omgo.iij.ad.jp (mo900.iij.ad.jp [202.232.31.76]) (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 864511243FE for ; Wed, 5 Jul 2017 21:06:29 -0700 (PDT) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1499313988; x=1500523588; bh=0YgcHpCw5EnH83qgr3vYNOj2Qh7RryMhKYVsdY4cHc8=; b=xtausyrX9VOGtEFjDAU38kbIxH3 9jdmBP15AH+Q6a4wX5eWWHqEaVvQbM5ob3bhRAULReJgFhjbNru7r3Dgj7Rbm/9A50WFbsHKRobzD pSzs9hBZx4cc23pmB8ndyHbIi4ne0JmOOAGryPBEYURR9sCSytz2I+1u3X/m3nLl1AdaXso5f4IdE WgMUUjRQe9KcMK1v86Ge/dDFFtluzpOSkOWh3wvaOg7XOranTKmYhTv1Aivn6faGe8H23cvvLj9y/ rJdv1T5ypeRSzjBPD0TxSdGpIC2FjDdnY719NRRncedQEqKiyeG3FDzELKkMmc3B1ARa1XtrVrIj8 zqomGQQ==; Received: by omgo.iij.ad.jp (mo900) id v6646SoS024139; Thu, 6 Jul 2017 13:06:28 +0900 X-Iguazu-Qid: 33PuoJClv5tq0qEm80 Date: Thu, 06 Jul 2017 13:06:27 +0900 (JST) Message-Id: <20170706.130627.753481879086572434.kazu@iij.ad.jp> To: tls@ietf.org From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: <20170706.111918.990342802355467009.kazu@iij.ad.jp> X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2017 04:06:32 -0000 >> HKDF-Expand-Label(Secret, Label, *Value*, Length) = >> HKDF-Expand(Secret, HkdfLabel, Length) >> >> struct { >> uint16 length = *Value.length*; >> opaque label<7..255> = "tls13 " + Label; >> opaque hash_value<0..255> = *Value*; >> } HkdfLabel; > > Length is the size of the output, so you don't want to assign > Value.length to that field in the struct. Yes. I would remove the "length" field, too. > Also, you forgot to rename hash_value in the struct. You are right. --Kazu From nobody Wed Jul 5 21:11:54 2017 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 E56D8126DCA for ; Wed, 5 Jul 2017 21:11:51 -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 Ijv-WoXDRBo0 for ; Wed, 5 Jul 2017 21:11:50 -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 CE2421243FE for ; Wed, 5 Jul 2017 21:11:49 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id b207so4189187lfg.2 for ; Wed, 05 Jul 2017 21:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wvPSE+g2Z3+Y3F2nQzluyRY4cIpR2CThribs/+VE5JM=; b=o6IsHjZocRS56xKEqN5+6c+K70H1B1z570qtHgrScN9tR4SLC1Ie9fqWJ9lPMt5pXJ W9cZyXJUX/5DxWNN/bYTclu2q12yCxtY7TghSZ1t0HPhk/jj9AnWKWhnNGtsnSuKxMbr kcoA734bM0jwCacjuWqJMRBmBjEor4qdXQ47mdCPvKZosxGggXlzRSPlM5F2HG+MtpsB jRNIsLdgpLKTg9f6bBhlX77Ei+24qEyKTSf5vqVzcqCPL3IQaXbh779T+MQ0J7v6UGot 39S7Y8zZ7r09Did8bfvCgWS1IJJTzcJNhptDnXYXtgdzVuPZ+pAK6oxQDDFf4OCjjwA3 jkgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wvPSE+g2Z3+Y3F2nQzluyRY4cIpR2CThribs/+VE5JM=; b=ePo+G59svYhZn7KLSwJbxqDJ+Dn5sDWww0VlRzajkzTD3TmoFhTrysjJJQ99LRyOCQ OA4yAUp35u51xPFUYLHA9bIwfR6SirYdxxxRWKlgUDGgqTw62JraTC4BmvhSLR0kghfw YmOPG9Beh2XiacJhZIBon2riyV7ZWFrLhqAO6s3psE7vxNpS201iIFyU/SowMCTSOTkd GbsEksGrlO0LCZq74XB5SCnfgGnpDG+EFe7vi+YozOxpDK31Y3095ygKwIkgbA9BP/W6 7BhyXvgqMZU+ZrFqIWZlRj+XiUaAbQGDH8N60oridn7PZ0wsU3vWlyhPI5H0bJvvJBkR IZ6A== X-Gm-Message-State: AIVw113YViPY/3LQGYkfJ5Dj7MU6h/L1kKWvJESZ8+TpOPLEAdMcxHeQ MRQ0S0hEGdGxdXkvwtb7jkxFFGEnbojI X-Received: by 10.46.87.76 with SMTP id r12mr1411552ljd.128.1499314308124; Wed, 05 Jul 2017 21:11:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Wed, 5 Jul 2017 21:11:47 -0700 (PDT) In-Reply-To: <20170706.130627.753481879086572434.kazu@iij.ad.jp> References: <20170706.111918.990342802355467009.kazu@iij.ad.jp> <20170706.130627.753481879086572434.kazu@iij.ad.jp> From: Martin Thomson Date: Thu, 6 Jul 2017 14:11:47 +1000 Message-ID: To: Kazu Yamamoto Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2017 04:11:52 -0000 We need the length field so that calling the function with different lengths results in different outputs. Not that anyone should be doing that, of course. On 6 July 2017 at 14:06, Kazu Yamamoto wrote: >>> HKDF-Expand-Label(Secret, Label, *Value*, Length) = >>> HKDF-Expand(Secret, HkdfLabel, Length) >>> >>> struct { >>> uint16 length = *Value.length*; >>> opaque label<7..255> = "tls13 " + Label; >>> opaque hash_value<0..255> = *Value*; >>> } HkdfLabel; >> >> Length is the size of the output, so you don't want to assign >> Value.length to that field in the struct. > > Yes. I would remove the "length" field, too. > >> Also, you forgot to rename hash_value in the struct. > > You are right. > > --Kazu > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 5 21:18:48 2017 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 60A59129AF7 for ; Wed, 5 Jul 2017 21:18:46 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 uNJfTRdgjAId for ; Wed, 5 Jul 2017 21:18:44 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002: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 A38A2129ADC for ; Wed, 5 Jul 2017 21:18:44 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id 84so2433195ybe.0 for ; Wed, 05 Jul 2017 21:18:44 -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=2lCa/xNen1Wkq2+0WBQYPFJ5N4YbUrrH4eHiahJKOmc=; b=0e9d8TWVNrcyXaRSSTgtNzJX0QxDlobIJGVQZ7M6yluWjHYk9VZqDxEeAo77ky96DO aXWVTDJGgGNk+nVfAeE7s7WAZueDVxYzvlCCjFiQGoT/XNxsHmWghI22oPf+Ovoc0BaE Imoe9asZ+4L7YiuEBOdGI/dOAxcP/OamnsKiBJ4QaPHYauxtDgAVfBDwM8AoJCPRB1qC slaQd4Uo91MKO6qMP7k58mmFpWPLNCKDK2k5D2HR8CDTPE5d5DCf9/8j+wflkzp660d1 hUav8vvnSvzKROq8Dkv/5cpKihBErnCREzfiP+6OfoCGu5O9mk2LeJ9bvFWyeQno+X+F C7Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2lCa/xNen1Wkq2+0WBQYPFJ5N4YbUrrH4eHiahJKOmc=; b=Al4wnjTEuRDZkb+0qhx/j3vZB036UEUaqlNiEEkoAIzIKjtg9vQpc24M2WZXMMofwz w/Izcy0iqEgfWZhjpFww7k5HnuqQ8cGKuvhUBCtTjAl3gluI7IWbmdqC7XalwLhuUlJf itDMy1Gfo+ggsytx/9bVHMZxLPTMhuH6zJeAov36WW37ucqVUD9LA+BrYxqN1pCWTbSI znYugPNsj0SGAjxCNl8afAFb83tlpQM5ttb4uUbhlZG7HQqpnC7dQDu6spF7kXmjLOtL TwODXqsIvfu7DICSpJ2nPQpGupwFZOTdNOVvwsscT7ZHb1tr1d4wrnWA1jgJvkU//BXU dzlg== X-Gm-Message-State: AIVw110QkbGsdpjodNKlGJhlIOtylHGaKQkhHHTlSby60a24AWqU3zM+ LTFYm1raEderavzcp84NmNVUfYftpO/0 X-Received: by 10.37.162.104 with SMTP id b95mr1025080ybi.29.1499314723872; Wed, 05 Jul 2017 21:18:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Wed, 5 Jul 2017 21:18:03 -0700 (PDT) In-Reply-To: References: <20170706.111918.990342802355467009.kazu@iij.ad.jp> <20170706.130627.753481879086572434.kazu@iij.ad.jp> From: Eric Rescorla Date: Wed, 5 Jul 2017 21:18:03 -0700 Message-ID: To: Martin Thomson Cc: Kazu Yamamoto , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19fcf885f05e05539e69e6" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2017 04:18:46 -0000 --94eb2c19fcf885f05e05539e69e6 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 9:11 PM, Martin Thomson wrote: > We need the length field so that calling the function with different > lengths results in different outputs. Not that anyone should be doing > that, of course. > The reason for this is that an adversarial application might do so. Say you have the secret in an HSM that has some sort of access control capability that doesn't let you exfiltrate keys. If the application can make a key that is a prefix of another key, then you can exhaustively search the keys by first extracting a one-byte key and searching that, etc. (IIRC Mike St Johns pointed out this attack to me). Now it's not a great an attack, but it is still sort of an attack. -Ekr > On 6 July 2017 at 14:06, Kazu Yamamoto wrote: > >>> HKDF-Expand-Label(Secret, Label, *Value*, Length) = > >>> HKDF-Expand(Secret, HkdfLabel, Length) > >>> > >>> struct { > >>> uint16 length = *Value.length*; > >>> opaque label<7..255> = "tls13 " + Label; > >>> opaque hash_value<0..255> = *Value*; > >>> } HkdfLabel; > >> > >> Length is the size of the output, so you don't want to assign > >> Value.length to that field in the struct. > > > > Yes. I would remove the "length" field, too. > > > >> Also, you forgot to rename hash_value in the struct. > > > > You are right. > > > > --Kazu > > > > _______________________________________________ > > 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 > --94eb2c19fcf885f05e05539e69e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 5, 2017 at 9:11 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
We need = the length field so that calling the function with different
lengths results in different outputs.=C2=A0 Not that anyone should be doing=
that, of course.

The reason for this is= that an adversarial application might do so.

Say = you have the secret in an HSM that has some sort of access control capabili= ty
that doesn't let you exfiltrate keys. If the application c= an make a key that is a prefix=C2=A0
of another key, then you can= exhaustively search the keys by first extracting a
one-byte key = and searching that, etc. (IIRC Mike St Johns pointed out this attack to me)= .
Now it's not a great an attack, but it is still sort of an = attack.

-Ekr


On 6 July 2017 at 14:06, Kazu Yamamoto <kazu@iij.ad.jp> wrote:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 HKDF-Expand-Label(Secret, Label, *V= alue*, Length) =3D
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HKDF-Expand(Sec= ret, HkdfLabel, Length)
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint16 length =3D *Va= lue.length*;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque label<7..25= 5> =3D "tls13 " + Label;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque hash_value<= 0..255> =3D *Value*;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 } HkdfLabel;
>>
>> Length is the size of the output, so you don't want to assign<= br> >> Value.length to that field in the struct.
>
> Yes. I would remove the "length" field, too.
>
>> Also, you forgot to rename hash_value in the struct.
>
> You are right.
>
> --Kazu
>
> _______________________________________________
> 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

--94eb2c19fcf885f05e05539e69e6-- From nobody Thu Jul 6 08:37:11 2017 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 DB7071317BF for ; Thu, 6 Jul 2017 08:37:09 -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 X-U9U0Wnlw5I for ; Thu, 6 Jul 2017 08:37:08 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 5025812EC0E for ; Thu, 6 Jul 2017 08:37:08 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 188so1118946itx.0 for ; Thu, 06 Jul 2017 08:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=6TPkFyRjGV35MmH+Q4dGMSXTt/J/bnPcPExbjmgP9hI=; b=XVZzsMP7zwboPPJ6whFt62qGhJ4xd96stmilDrppQEiE8zr21zz9kssTtbRqv4UAMl FJTW1DLntcTaNXedLxtyFMQhjH7mRbJ2DAHVVi5W3s0jI0BcN7M15cHoPXqFePCUuy1Q dCKAXRLb7/tL3xek9RU1wZnzc3JKxpII1TAVE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=6TPkFyRjGV35MmH+Q4dGMSXTt/J/bnPcPExbjmgP9hI=; b=IY1IQPsF4z+encFY9WsNs/BPfUtUg1Cx9WXyrKhbyXZq+qp2LdCLu96wQBmPYvuFra z7Wx0bDqPhS7xa/tQUhS4ErDGqJIhhdJSDFtLTUTrUz0YO9kEwDiaAv5UkgTvhQtgneb /fqSPRVy4B9kpyyykxYhJlHSe6zq2U7EUWcMKRvoLZ2gDVJKH4zErsiYf3U4/H9teVjc +jNYRb89bYJ5OH+hMqbvc3x15n7lxPebEMxNVyXEVVMBViItChZuMPddmAodxMBLpa1g TYHc4U6kzOuOtR/puiQpWenAQwPHDKQmadocPsxecskuFFzcJG7n1KF+cX4V2PJN5dxA Joxw== X-Gm-Message-State: AIVw113+7ID/8JOSLvINQdvckQuLN3mXS6L7mXrVNSLRfBGlRoU0bvtP WtgUhrAXKW/wQ/BOTsvDmg== X-Received: by 10.36.92.77 with SMTP id q74mr18915457itb.24.1499355427454; Thu, 06 Jul 2017 08:37:07 -0700 (PDT) Received: from [5.5.33.50] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id y93sm300146ita.9.2017.07.06.08.37.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 08:37:06 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <6B056E0C-47F1-40D8-A278-D00F9FCB0CED@sn3rd.com> Date: Thu, 6 Jul 2017 11:37:01 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] Draft agenda: TLS@IETF99 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2017 15:37:10 -0000 A draft agenda is available at: https://www.ietf.org/proceedings/99/agenda/agenda-99-tls-00 spt From nobody Thu Jul 6 12:10:21 2017 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 CA51C131935 for ; Thu, 6 Jul 2017 12:10:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 0SeC0APA32wj for ; Thu, 6 Jul 2017 12:10:19 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 7F398131931 for ; Thu, 6 Jul 2017 12:10:19 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v66J7AQR000603; Thu, 6 Jul 2017 20:10:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : from : to : references : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=GvPMQAABjH1G2fVnvFEW1xALkC0Vedad1TYrCEMYums=; b=S5o3RsU9gE9+1gY467bQaPj4GVt+Elwc0a2ep56oWh0dShDK8yU0Ovm9rLGEFnE1uGp7 uv84pwDzTY81RIxE2jcb1dcUhLjbmDdl5gF+/F+6FsDJ02+IMH8hsr/7ubC670gRIw5i AGck9v8S9yCMT7o2p6UAjtd2Pr1EW3WGJqblxXG/Ex86M1si2Fh3UwrGIcOlfxVsZj3C S45rJ7U4DNKPH1uXJuHPhVboA8L8pAJb91cqsW1Cf2AAxRVDwnNOKxfHGWMo+TocCXWA IB8A93C6ysXNoDxB7F7/tWGVqqyYv30sk1MphzvCcac/KuQhZXbfWJJMQCgcH3CyP21R QQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2bhry20ke7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jul 2017 20:10:17 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v66J5UiQ018239; Thu, 6 Jul 2017 15:10:17 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2be72vhe9s-1; Thu, 06 Jul 2017 15:10:16 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 9200A80052; Thu, 6 Jul 2017 13:10:16 -0600 (MDT) From: Benjamin Kaduk To: Eric Rescorla , "tls@ietf.org" References: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> Message-ID: Date: Thu, 6 Jul 2017 14:10:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> Content-Type: multipart/alternative; boundary="------------421E5B6E3473D27B1DCC1803" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707060325 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707060326 Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2017 19:10:21 -0000 This is a multi-part message in MIME format. --------------421E5B6E3473D27B1DCC1803 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/30/2017 11:32 AM, Benjamin Kaduk wrote: > On 06/29/2017 03:53 PM, Eric Rescorla wrote: >> I have updated the PR to match people's comments. I would like to >> merge this soon, so please get any final comments in. > > I made a couple comments on the PR that are more appropriate for the > list, so I'll repeat them here and hopefully get replies from the > broader audience. > > > First off, I think we should MUST-level require servers to implement a > hard limit on the number of replays accepted. However, it doesn't > quite seem realistic to require "MUST use either [single-use tickets] > or [ClientHello recording]". My preference would be "MUST use either > [single-use tickets], [ClientHello recording], or equivalently strong > protection", but I don't know what level of support we have for such a > strong requirement. As an alternative, I will also put out "MUST > limit replays to at most the number of endpoints capable of accepting > connections for a given identity, and SHOULD provide even stronger > replay protections, such as [single-use tickets] or [ClientHello > recording]." I think we have general agreement that strong > anti-replay as described in the document is feasible for a > single-server deployment, and this last formulation is achievable in > multi-server environments by just giving each server its own local > per-server protection. (My main reason for wanting a MUST-level hard > cap is that I worry that millions/billions of replays will have really > nasty consequences in terms of DoS and side channel issues.) > > But, this has been quite a long thread spread out over multiple > forums/email subjects, so I've also probably forgotten some of the > arguments presented against having MUST-level strong anti-replay > requirements; I'd greatly appreciate if someone could repeat them here > for everyone's consideration. Or are there no such arguments? The only one I remember is the implementation complexity for distributed systems, but if you can implement for a single-node system my compromise proposal is trivially implementable. -Ben --------------421E5B6E3473D27B1DCC1803 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/30/2017 11:32 AM, Benjamin Kaduk wrote:
On 06/29/2017 03:53 PM, Eric Rescorla wrote:
I have updated the PR to match people's comments. I would like to merge this soon, so please get any final comments in.

I made a couple comments on the PR that are more appropriate for the list, so I'll repeat them here and hopefully get replies from the broader audience.


First off, I think we should MUST-level require servers to implement a hard limit on the number of replays accepted.  However, it doesn't quite seem realistic to require "MUST use either [single-use tickets] or [ClientHello recording]".  My preference would be "MUST use either [single-use tickets], [ClientHello recording], or equivalently strong protection", but I don't know what level of support we have for such a strong requirement.  As an alternative, I will also put out "MUST limit replays to at most the number of endpoints capable of accepting connections for a given identity, and SHOULD provide even stronger replay protections, such as [single-use tickets] or [ClientHello recording]."  I think we have general agreement that strong anti-replay as described in the document is feasible for a single-server deployment, and this last formulation is achievable in multi-server environments by just giving each server its own local per-server protection.  (My main reason for wanting a MUST-level hard cap is that I worry that millions/billions of replays will have really nasty consequences in terms of DoS and side channel issues.)

But, this has been quite a long thread spread out over multiple forums/email subjects, so I've also probably forgotten some of the arguments presented against having MUST-level strong anti-replay requirements; I'd greatly appreciate if someone could repeat them here for everyone's consideration.

Or are there no such arguments?
The only one I remember is the implementation complexity for distributed systems, but if you can implement for a single-node system my compromise proposal is trivially implementable.

-Ben
--------------421E5B6E3473D27B1DCC1803-- From nobody Thu Jul 6 18:47:09 2017 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 BD8EB131532 for ; Thu, 6 Jul 2017 18:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5aRwRGxrrXah for ; Thu, 6 Jul 2017 18:47:05 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 B12C712EBFD for ; Thu, 6 Jul 2017 18:47:05 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id w19so12257310uac.0 for ; Thu, 06 Jul 2017 18:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QnLDyzdFoHjo4Gg94jf+w49juHizkxp0jat5mjJxoqo=; b=tmLPM1+GX511pPRGc9BWYqEtFRQri/Se5MrhUqLUlNIMiN3qJEmkvD8Picsas9KTPk Lyf08KxGQWTOKLuaGj27ibk/Au7GksNKxy+v/wzkdryFEKngLP5injpt/kbQHsf9Eu0n yRS5j3rQRzKWYLCwkpPR8VG+s+gEUqh4IB0bn+Vv2zb1kuITfs33vwp8DpY/TZGnRwGS EPIpqBJ8FxPHqKaX8Do+HwtM6JPHRvlnnlao0l/VtC1j+Z04901eNpJlPn1WOO7xGKOA 7gmdMeGBR1OCNjpiFsrNW/4PuysWynFk4MM9LXgUDn7ODhR65iotTpSz+tUNq5D4qiPm d6RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QnLDyzdFoHjo4Gg94jf+w49juHizkxp0jat5mjJxoqo=; b=gqWArRm3Za7T+fUdZTZwfSBlZdkh1v0CB0fLmTjclJVDN7HbpeA2vfDg0uXIIK6Ste RMqSiaJFXmLSoEQK8rrwfqGKkegdKnEsxR09WzJ3uN2jB0GoMij5wvXnSbxutRxrgE7c K/6YD7Co+sYowjxfccVJcLj5blvGvZiiuAkm231JMfzC+9Od339st0EfD7WHzmu3CZ3y Lfb4avZj3eTGWUgwSq1D+QGYZ0AV6cTn14s+JhH8m3JpDEicI7DVQ3aSivtGJc+Polrc yPIsIEM5PorkWgjy/Y15XL/ePH+CerrLgXd08M1kptxcwMBYLi7g4a5SgxRhTnX1Mgs1 FKOA== X-Gm-Message-State: AKS2vOybHcrTgNiEYzlvRBdJH8/ND2y9CPqg16oi1Iy70UJVa8t0LDOr TAcCU8s6z/zUlEGqU/3lZuQCw1PnNdkk X-Received: by 10.176.27.141 with SMTP id k13mr27898752uai.93.1499392024858; Thu, 06 Jul 2017 18:47:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Thu, 6 Jul 2017 18:47:04 -0700 (PDT) In-Reply-To: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> From: Shumon Huque Date: Thu, 6 Jul 2017 21:47:04 -0400 Message-ID: To: Jim Reid Cc: TLS WG Content-Type: multipart/alternative; boundary="94eb2c13be6e05563f0553b069e7" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 01:47:08 -0000 --94eb2c13be6e05563f0553b069e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 12:30 PM, Jim Reid wrote: > I=E2=80=99ve got a few concerns/issues with the document. > Hi Jim, I largely agree with the responses Viktor gave in a previous message. I'll comment on the last point where he did not: > 6) The draft doesn't seem to take account of key rollovers when DNS data > will be signed by two or more keys. Zone signing keys are missing from th= e > examples too. These might well have been omitted for cosmetic reasons. IM= O > they need to be included in the final document to illustrate what > implementers can expect to find when the DNS returns signed data. > I assume you're referring to the examples in Appendix D (Test Vectors)? These are working examples that implementers can test code against. But it looks like the testbed involved in these examples uses combined signing keys (i.e. ones that are both the zone's secure entry point and the ZSK). Perhaps we should use an example with the KSK/ZSK split to make them look more like the real world. Let me discuss with Willem Toorop (co-author) who generated these ... --=20 Shumon Huque --94eb2c13be6e05563f0553b069e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 12:30 PM, Jim Reid <jim@rfc1035.com> wrote:=
I=E2=80=99ve got a few concerns/issues w= ith the document.

Hi Jim,
I largely agree with the responses Viktor gave in a previous me= ssage. I'll comment on the last point where he did not:
=C2= =A0
6) The draft doesn't seem to take account of key rollovers when DNS dat= a will be signed by two or more keys. Zone signing keys are missing from th= e examples too. These might well have been omitted for cosmetic reasons. IM= O they need to be included in the final document to illustrate what impleme= nters can expect to find when the DNS returns signed data.
=

I assume you're referring to the examples in Append= ix D (Test Vectors)?

These are working examples th= at implementers can test code against. But it looks like the testbed involv= ed in these examples uses combined signing keys (i.e. ones that are both th= e zone's secure entry point and the ZSK). Perhaps we should use an exam= ple with the KSK/ZSK split to make them look more like the real world. Let = me discuss with Willem Toorop (co-author) who generated these ...

--=C2=A0
Shumon Huque

--94eb2c13be6e05563f0553b069e7-- From nobody Thu Jul 6 18:53:32 2017 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 1C62213161E for ; Thu, 6 Jul 2017 18:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 tNMoknxz3EqB for ; Thu, 6 Jul 2017 18:53:28 -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 3F3D413161C for ; Thu, 6 Jul 2017 18:53:28 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id y70so10139615vky.3 for ; Thu, 06 Jul 2017 18:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tR0+s0mdGj/g3bFGJhpLXuZbL2SgBlcFKZqcKS2oA4I=; b=hO1HpsrEYuRcbmUNvA+ZS1EgiQ68o6EKjaFB8QmHyHmlvlV8BvtKP6SG7VsKKr5cI2 ax22duG39P37y0Wza7QMbX2B7/3VqY5czuqhYbTQjqHHh5OPrlRDZdI5eh7BFSCCWBqK dXR/+UO8ZhegBOItpSUIyqFUyY+5kN20JuDN3UH+cTe+tmi70AI36zZtqCchicutqNv/ HEWT0Sl7+5pIbOP32LPWdHAdivR1ICy1DCoLrXUp9CeeGM2gYLKiLykO1vSxU+anZqbD RwOEipoL0iuz75ByLmb5U1aZNk9UMZhb65hYdB2sj80fS5aDAXpw3iDSnnyycd9+rkfG ZuIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=tR0+s0mdGj/g3bFGJhpLXuZbL2SgBlcFKZqcKS2oA4I=; b=Ykfs9bBJYtTFp24TF09UHLTe7FogJbTpswHo9mw3iw1YnlfBqkAsODye1RCBUAZuDV pOJAFAyMDNgHSZhNeDOi6ZBVsW3RWo2vWaWX/L+QCkee5Q0/xAka9aneOH/NZgslGOaD oVchjygcEkyPLB0KvnPzYWUA72VZIYMt4xrf8gY/y+Mq/7d8EufI4WluVqLYiEnoBtRt /KZNnIVGjwnsx20rHwSvo/ylrZnQhx32eN8fW+dqHVR2S9I911dhrFQGali8U1F25S0v MuwNASvSq11zitVAKO3+OvIT/MvYi6zlLolJHf8TB3QLb2OYmjaHVddstQJVrdxEk418 hkAw== X-Gm-Message-State: AKS2vOwv5tafbPpIe2DR4uzJI/gIoN52EsX8gRL4wqDb5u440AMiW/Dq HpOzRec2WwJOOXjv+YKjiL7qZQINvJdC X-Received: by 10.31.218.196 with SMTP id r187mr28626066vkg.96.1499392407156; Thu, 06 Jul 2017 18:53:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Thu, 6 Jul 2017 18:53:26 -0700 (PDT) In-Reply-To: <20170705171211.GM5673@mournblade.imrryr.org> References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> <20170705171211.GM5673@mournblade.imrryr.org> From: Shumon Huque Date: Thu, 6 Jul 2017 21:53:26 -0400 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="94eb2c07c562cebe3b0553b07f59" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 01:53:30 -0000 --94eb2c07c562cebe3b0553b07f59 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 1:12 PM, Viktor Dukhovni wrote: > On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote: > > > 3) Something should be said about algorithm agility. We can be reasonably > > sure web browsers, DNS servers, smart phones and so on will generally > have > > up-to-date DNSSEC validators and/or TLS code. Some TLS clients -- fire > > and forget embedded systems, IoT devices, etc -- might never get updated > > once they're deployed. If these clients use their own DNSSEC validators, > > they will be screwed when/if DNSSEC drops SHA1 signatures (say) or adds > > a new flavour of ECC or even an all-new signing protocol. > > SHA2 is already defined and widely used for DS records. The X25519 > and X448 EC algorithms are already defined (or will be by the time > this draft becomes an RFC). RFC 8080, defining Ed25519 and Ed448 for DNSSEC, is already published. There are already some early implementations (PowerDNS and NLnet Labs' Unbound; maybe others). > So there's not much churn on the > immediate horizon. Devices doing all the validation locally will > need software updates roughly once a decade (DNS parameters change > slowly). A secure channel to a *trusted* resolver would avoid the > problem, but trustworthy off-device resolvers are very unlikely to > be ubiquitous. > Regarding churn, I expect we'll have several post quantum signature algorithms for DNSSEC in the 5 to 10 year horizon. -- Shumon Huque --94eb2c07c562cebe3b0553b07f59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 1:12 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
O= n Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote:

> 3) Something should be said about algorithm agility. We can be reasona= bly
> sure web browsers, DNS servers, smart phones and so on will generally = have
> up-to-date DNSSEC validators and/or TLS code. Some TLS clients -- fire=
> and forget embedded systems, IoT devices, etc -- might never get updat= ed
> once they're deployed. If these clients use their own DNSSEC valid= ators,
> they will be screwed when/if DNSSEC drops SHA1 signatures (say) or add= s
> a new flavour of ECC or even an all-new signing protocol.

SHA2 is already defined and widely used for DS records.=C2=A0 The X2= 5519
and X448 EC algorithms are already defined (or will be by the time
this draft becomes an RFC).=C2=A0

RFC 8080,= defining Ed25519 and Ed448 for DNSSEC, is already published. There are alr= eady some early implementations (PowerDNS and NLnet Labs' Unbound; mayb= e others).
=C2=A0
So there&#= 39;s not much churn on the
immediate horizon.=C2=A0 Devices doing all the validation locally will
need software updates roughly once a decade (DNS parameters change
slowly).=C2=A0 A secure channel to a *trusted* resolver would avoid the
problem, but trustworthy off-device resolvers are very unlikely to
be ubiquitous.

Regarding churn, I expec= t we'll have several post quantum signature algorithms for DNSSEC in th= e 5 to 10 year horizon.

--=C2=A0
Shumon = Huque

--94eb2c07c562cebe3b0553b07f59-- From nobody Thu Jul 6 19:01:15 2017 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 DBB19131571 for ; Thu, 6 Jul 2017 19:01:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Aar0qZU4ym0Z for ; Thu, 6 Jul 2017 19:01:11 -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 58AB4131556 for ; Thu, 6 Jul 2017 19:01:11 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id r30so17028509qtc.0 for ; Thu, 06 Jul 2017 19:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=mR7da9b3PTBe7egpRYrp18rKb95T3flBrrEEN34/BfY=; b=noAMERz0/G2qT5UAXv7+5Td/SSDGubhOlbZv2MmNVTODztnMt6pyAeUIvKvtb87wFt 2hMWIjs+6tNup8VfK8gy7dM25utO61F0MqIF9YSElMOdC75uarELrxFHNUINc5pxY8eR F+XiINI92l+cCS63Z38tmnn+5O/6ejq8NZzRybjoW9Dey0WOguNr8CyvJTvGQE0Mtqfc kmybBJ3t92ErosHEy6uzLBobHjhts50y3Nc6KS6V+cm+Gw0FsjtZ88RBctVqv1mGwSig lpzNbxR9bQQ26L9rfL79WH1pbXMiZE4ZXS0TM7GMzhoVP6oLQp7W8PGVAD5bWab1Glws 8TjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=mR7da9b3PTBe7egpRYrp18rKb95T3flBrrEEN34/BfY=; b=ZwQEzuCixqVHokvyPoaTzEAr8MG4D7U+HhAxxX6W1wXgOwbJuskRZlcG2gWBC5bpTe Vd2lCCGW+spC9S4CIey7zAGbpNN13h21Dg6+HXX+KitnpFkUpnQMmSpqQKA6GiOX5m7n MpPTGHjInSFxLAS6hs7UkC0x90pUT4mZimZfxhd8EGYEdOEFhjLTPPa5geFNVxJ1gi0P GliGSqb2myQecd7idbs0/u61evXmsU2PZa4smNBvloH9HThSwR10iwXbe3R413Or/1QL M73/6W1VBE3HvZhTgEY4MY4+c8CFUcDs71NgvG3u6bUZldrGpi6gTcXi6NppubdSlYov IU1A== X-Gm-Message-State: AKS2vOwUt+PEMqi0NOPlrwVhzaxGZjjyFTGh126AxOy4o4hT9ELlvFxl Jax/IumGO5sjo2MM X-Received: by 10.200.34.248 with SMTP id g53mr50240665qta.65.1499392870408; Thu, 06 Jul 2017 19:01:10 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id l50sm1586277qtf.35.2017.07.06.19.01.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 06 Jul 2017 19:01:09 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Wang Haiguang Date: Thu, 6 Jul 2017 22:01:08 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> In-Reply-To: <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201707062201.08455.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 02:01:13 -0000 On Tuesday, July 04, 2017 07:21:44 am Ilari Liusvaara wrote: > However, this requires > TLS 1.2 or newer, but that should not be a problem. > > - The proposed ciphersuites are really bad. Just as a clarification, all new RFCs should ideally meet all of the following criteria: * AEAD only * PFS only * TLS 1.2 and 1.3 support * no TLS 1.0 or 1.1 support (let alone SSL) * no use of broken hashes (MD5, SHA1, etc.) Dave From nobody Thu Jul 6 20:04:17 2017 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 AE78C127698 for ; Thu, 6 Jul 2017 20:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eNqQE4KdRgtO for ; Thu, 6 Jul 2017 20:04:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86B81204DA for ; Thu, 6 Jul 2017 20:04:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJW95089; Fri, 07 Jul 2017 03:04:10 +0000 (GMT) Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 7 Jul 2017 04:04:08 +0100 Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.203]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0301.000; Fri, 7 Jul 2017 11:04:06 +0800 From: yinxinxing To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 Thread-Index: AdL2zV5W/HDgxBACQSqQFOyDPszOzQ== Date: Fri, 7 Jul 2017 03:04:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022C78B070dggemi508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.595EFA2B.006F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.203, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 99c44ea4649cd3cc37f8d35cf85594ff Archived-At: Subject: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 03:04:16 -0000 --_000_DBDF9AE44733284D808F0E585E1919022C78B070dggemi508mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGUgTkFUIHRhYmxlIGV4cGlyaW5nIHByb2JsZW0gbWVudGlvbmVkIGluIHRo ZSAgZm9sbG93aW5nIGVtYWlsIHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQgaW4gRFRMUzEuMiBh cyBhbiBleHRlbnNpb24uDQoNClRoZSB2YWx1ZSBhbmQgbmVjZXNzaXR5IGFyZSBhcyBmb2xsb3dz Lg0KDQoxLiBFc3NlbnRpYWxseSwgTkFUIGV4cGlyaW5nIHByb2JsZW0gY2F1c2luZyBEVExTIHJl bmVnb3RpYXRpb24gd2l0aCBoaWdoIHBvd2VyIGNvbnN1bXB0aW9uIGlzIGV4aXN0aW5nIGluIERU TFMgMS4yLiBFdmVuIGlmIHdlIHNvbHZlIHRoaXMgaW4gRFRMUzEuMywgdGhpcyBwcm9ibGVtIHN0 aWxsIGV4aXN0IGZvciBwcm9kdWN0cyB1c2luZyBEVExTMS4yLg0KQ3VycmVudGx5LCBtYW55IElP VCBwcm9kdWN0cyB1c2luZyBEVExTIDEuMiBhcmUgZ29pbmcgdG8gYmUgZGVwbG95ZWQgY29tbWVy Y2lhbGx5LCBzdWNoIGFzIGludGVsbGlnZW50IHdhdGVyL2dhcyBtZXRlci4gVGhlc2UgbWV0ZXJz IHVzdWFsbHkgaGF2ZSBsaW1pdGVkIGJhdHRlcnkgYW5kIGxvdyBjb3N0LiBUbyBiZSBtb3JlIGFj Y3VyYXRlLCB0aGUgYmF0dGVyeSBvZiB0aGUgY2hpcCBtb2R1bGUgb2YgdGhlIGludGVsbGlnZW50 IHdhdGVyL2dhcyBtZXRlciBhcmUgcmVxdWlyZWQgdG8gbGFzdCBmb3IgMTAgeWVhcnMuIFRoZXNl IGxlYWQgdG8gYW4gZXhlcmNpc2Ugc3RyaWN0IGNvbnRyb2wgb3ZlciB0aGUgcG93ZXIgY29uc3Vt cHRpb24gb2YgdGhlIGNoaXAgbW9kdWxlLiBOQVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVzaW5nIERU TFMgcmVuZWdvdGlhdGlvbiB3aXRoIGhpZ2ggcG93ZXIgY29uc3VtcHRpb24gaXMgYSBib3R0bGVu ZWNrIG9mIHRoZXNlIElPVCBkZXZpY2VzLiBBY2NvcmRpbmcgdG8gb3VyIGV4cGVyaW1lbnRhbCBk YXRhLCB1bmRlciB0aGUgd29yc3QgY292ZXJhZ2UgbGV2ZWwgKEVDTDIpLCBwb3dlciBjb25zdW1w dGlvbiBvZiB0aGUgY2hpcCBtb2R1bGUgd2hlbiBEVExTIGlzIGVtYmVkZGVkIGluY3JlYXNlcyBi eSBuZWFybHkgNjAlLiBUaGVyZWZvcmUsIHRoZXJlIHNob3VsZCBiZSBhIHNvbHV0aW9uIHRvIHNv bHZlIHRoZSB1cmdlbnQgcHJvYmxlbSB0byBtYXRjaCB0aGUgbG93LWNvc3QgYW5kIGxvdy1iYXR0 ZXJ5IGZlYXR1cmUgb2YgdGhlIElPVCBkZXZpY2VzIGluIERUTFMgMS4yLg0KDQoyLiBEVExTIDEu MyB3aWxsIGJlIHN0YW5kYXJkaXplZCBpbiAyMDE4LCBidXQgdGhlIGNvcnJlc3BvbmRpbmcgb3Bl biBzb3VyY2UgY29kZSB3aWxsIGJlIGF2YWlsYWJsZSBhYm91dCBvbmUgeWVhciBsYXRlciBhZnRl ciB0aGUgc3RhbmRhcmRpemF0aW9uLiBBdCBwcmVzZW50LCBsYXJnZS1zY2FsZSBjb21tZXJjaWFs IElPVCBpbmR1c3RyeSBkZXBsb3ltZW50IGlzIHVyZ2VudCwgaXQgaXMgdG9vIGxhdGUgdG8gd2Fp dCBmb3IgRFRMUyAxLjMuIFRodXMsIHdlIGhvcGUgdGhhdCB0aGUgYWJvdmUgcHJvYmxlbSBjb3Vs ZCBiZSBzb2x2ZWQgaW4gRFRMUyAxLjIgYXMgc29vbiBhcyBwb3NzaWJsZS4NCg0KQW55IGNvbW1l bnQgaXMgYXBwcmVjaWF0ZWQuDQoNClJlZ2FyZHMsDQpZaW4gWGlueGluZw0KDQoNCuWPkeS7tuS6 ujogeWlueGlueGluZw0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0NuaciDI35pelIDE2OjI4DQrmlLbk u7bkuro6ICdFcmljIFJlc2NvcmxhJw0K5oqE6YCBOiB0bHNAaWV0Zi5vcmc7IFRvYmlhcyBHb25k cm9tDQrkuLvpopg6IFJlOiBbVExTXSBZaW4gWGlueGluZyBqb2lucyB0aGUgVExTIFdHDQoNClRo YW5rcyBFcmljLA0KDQpJIGhhdmUgc2VlbiB0aGUgQ0lEIHNjaGVtZSwgYW5kIHRhbGtlZCB3aXRo IEhhbm5lcyh0aGUgYXV0aG9yIG9mIHRoZSBzY2hlbWUpLg0KDQpDSUQgc2NoZW1lIGlzIGEgZ29v ZCBpZGVhIHRvIHNvbHZlIHRoZSBwcm9ibGVtIEkgbWVudGlvbmVkLg0KDQpJIHRoaW5rIHRoZSBs ZW5ndGggb2YgQ0lEIChjdXJyZW50bHksIGl0IGlzIDMyIGJpdHMpIGNhbiBiZSBsb25nZXIgc28g dGhhdCBpdCBjYW4gc3VwcG9ydCBtb3JlIERUTFMgc2Vzc2lvbnMuIEl0IGlzIGtub3duIHRoYXQg Zm9yIElPVCBzY2VuYXJpbywgMSBtaWxsaW9uIGNvbm5lY3Rpb24gaXMgbm90aGluZy4NCg0KUmVn YXJkcywNCllpbiBYaW54aW5nDQoNCuWPkeS7tuS6ujogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVr ckBydGZtLmNvbV0NCuWPkemAgeaXtumXtDogMjAxN+W5tDbmnIgyNeaXpSAyMTozMw0K5pS25Lu2 5Lq6OiB5aW54aW54aW5nDQrmioTpgIE6IHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3Jn PjsgWGlvbmd4aWFvY2h1bg0K5Li76aKYOiBSZTogW1RMU10gWWluIFhpbnhpbmcgam9pbnMgdGhl IFRMUyBXRw0KDQpIaSBZaW4sDQoNClRoZSB1c3VhbCBzb2x1dGlvbiB0byB0aGlzIGlzIHRvIGFk ZCBhIGNvbm5lY3Rpb24gaWQuIFBsZWFzZSBzZWU6DQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cv ZHRsczEzLXNwZWMvaXNzdWVzLzYNCg0KLUVrcg0KDQoNCg0KDQpPbiBTdW4sIEp1biAyNSwgMjAx NyBhdCAyOjMzIEFNLCB5aW54aW54aW5nIDx5aW54aW54aW5nQGh1YXdlaS5jb208bWFpbHRvOnlp bnhpbnhpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGVsbG8gZXZlcnlvbmUsDQoNCkkgYW0gWWlu IFhpbnhpbmcgZnJvbSBIdWF3ZWkgY29tcGFueS4gSSBhbSBnbGFkIHRvIGpvaW4gdGhlIFRMUyBX Ry4NCg0KRm9yIHRoZSBETFRTIDEuMyBkcmFmdCwgSSBhbSBpbnRlcmVzdGVkIGFuZCBoYXZlIHNv bWUgaWRlYXMgdG8gdGFsayB3aXRoIHlvdS4NCg0KRFRMUyBoYXMgYSBsb3Qgb2YgYXBwbGljYXRp b24gc2NlbmFyaW9zIGluIElPVCBmaWVsZHMsIGJ1dCBjdXJyZW50bHksIHRoZXJlIGlzIHNvbWUg ZGlmZmljdWx0eSB3aGVuIERUTFMgMS4yIGlzIGFwcGxpZWQgdG8gSU9UIGRldmljZXMsIGVzcGVj aWFsbHkgdGhlIGJhdHRlcnktY29uc3RyYWluZWQgSU9UIGRldmljZXMuDQoNCkZvciBleGFtcGxl LCB3aGVuIHRoZSBJT1QgZGV2aWNlIHdha2VzIHVwIGZyb20gc2xlZXAgbW9kZSwgdGhlIE5BVCB0 YWJsZSBtYXkgaGF2ZSBleHBpcmVkLg0KVGhlbiB0aGUgSU9UIGRldmljZSBoYXMgdG8gZXN0YWJs aXNoIGEgbmV3IERUTFMgc2Vzc2lvbiBvciBhdCBsZWFzdCBsYXVuY2hlcyBhIHJlc3VtZSBwcm9j ZXNzIHdpdGggdGhlIHNlcnZlciwgdGhlIGNvcnJlc3BvbmRpbmcgcG93ZXIgY29uc3VtcHRpb24g aXMgdG9vIGhpZ2ggZm9yIHNvbWUgcG93ZXItY29uc3RyYWluZWQgZGV2aWNlcy4NCkhvdyBjYW4g RFRMUyByZW5lZ290aWF0aW9uIGJlIGF2b2lkZWQgaW4gb3JkZXIgdG8gc2F2ZSBiYXR0ZXJ5Pw0K DQpJIGhvcGUgdGhlIGNvbnRyaWJ1dG9ycyBvZiBEVExTIDEuMyAob3IgRFRMUyAxLjIpIGNhbiBj b25zaWRlciB0aGlzIHByb2JsZW0gYW5kIGdpdmUgYSBwcm9wZXIgc29sdXRpb24uDQoNCkFueSBj b21tZW50IG9yIGlkZWEgYWJvdXQgdGhpcyBwcm9ibGVtIGlzIHdlbGNvbWUuDQoNClJlZ2FyZHMs DQpZaW4gWGlueGluZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQo= --_000_DBDF9AE44733284D808F0E585E1919022C78B070dggemi508mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlvq7ova/pm4Xpu5E7DQoJcGFub3Nl LTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDl rovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiXEDlvq7ova/pm4Xpu5EiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNO IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhlIE5BVCB0YWJsZSBleHBpcmluZyBwcm9ibGVtIG1lbnRpb25lZCBpbiB0aGUg Jm5ic3A7Zm9sbG93aW5nIGVtYWlsIHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQgaW4gRFRMUzEu MiBhcyBhbiBleHRlbnNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo ZSB2YWx1ZSBhbmQgbmVjZXNzaXR5IGFyZSBhcyBmb2xsb3dzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4xLiBFc3NlbnRpYWxseSwgTkFUIGV4cGlyaW5nIHByb2JsZW0gY2F1 c2luZyBEVExTIHJlbmVnb3RpYXRpb24gd2l0aCBoaWdoIHBvd2VyIGNvbnN1bXB0aW9uIGlzIGV4 aXN0aW5nIGluIERUTFMgMS4yLiBFdmVuIGlmIHdlIHNvbHZlIHRoaXMgaW4gRFRMUzEuMywNCiB0 aGlzIHByb2JsZW0gc3RpbGwgZXhpc3QgZm9yIHByb2R1Y3RzIHVzaW5nIERUTFMxLjIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DdXJyZW50bHksIG1hbnkgSU9U IHByb2R1Y3RzIHVzaW5nIERUTFMgMS4yIGFyZSBnb2luZyB0byBiZSBkZXBsb3llZCBjb21tZXJj aWFsbHksIHN1Y2ggYXMgaW50ZWxsaWdlbnQgd2F0ZXIvZ2FzIG1ldGVyLiBUaGVzZSBtZXRlcnMg dXN1YWxseSBoYXZlDQogbGltaXRlZCBiYXR0ZXJ5IGFuZCBsb3cgY29zdC4gVG8gYmUgbW9yZSBh Y2N1cmF0ZSwgdGhlIGJhdHRlcnkgb2YgdGhlIGNoaXAgbW9kdWxlIG9mIHRoZSBpbnRlbGxpZ2Vu dCB3YXRlci9nYXMgbWV0ZXIgYXJlIHJlcXVpcmVkIHRvIGxhc3QgZm9yIDEwIHllYXJzLiBUaGVz ZSBsZWFkIHRvIGFuIGV4ZXJjaXNlIHN0cmljdCBjb250cm9sIG92ZXIgdGhlIHBvd2VyIGNvbnN1 bXB0aW9uIG9mIHRoZSBjaGlwIG1vZHVsZS4gTkFUIGV4cGlyaW5nIHByb2JsZW0NCiBjYXVzaW5n IERUTFMgcmVuZWdvdGlhdGlvbiB3aXRoIGhpZ2ggcG93ZXIgY29uc3VtcHRpb24gaXMgYSBib3R0 bGVuZWNrIG9mIHRoZXNlIElPVCBkZXZpY2VzLiBBY2NvcmRpbmcgdG8gb3VyIGV4cGVyaW1lbnRh bCBkYXRhLCB1bmRlciB0aGUgd29yc3QgY292ZXJhZ2UgbGV2ZWwgKEVDTDIpLCBwb3dlciBjb25z dW1wdGlvbiBvZiB0aGUgY2hpcCBtb2R1bGUgd2hlbiBEVExTIGlzIGVtYmVkZGVkIGluY3JlYXNl cyBieSBuZWFybHkgNjAlLiBUaGVyZWZvcmUsDQogdGhlcmUgc2hvdWxkIGJlIGEgc29sdXRpb24g dG8gc29sdmUgdGhlIHVyZ2VudCBwcm9ibGVtIHRvIG1hdGNoIHRoZSBsb3ctY29zdCBhbmQgbG93 LWJhdHRlcnkgZmVhdHVyZSBvZiB0aGUgSU9UIGRldmljZXMgaW4gRFRMUyAxLjIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIuIERUTFMgMS4zIHdpbGwgYmUgc3RhbmRhcmRp emVkIGluIDIwMTgsIGJ1dCB0aGUgY29ycmVzcG9uZGluZyBvcGVuIHNvdXJjZSBjb2RlIHdpbGwg YmUgYXZhaWxhYmxlIGFib3V0IG9uZSB5ZWFyIGxhdGVyIGFmdGVyIHRoZSBzdGFuZGFyZGl6YXRp b24uDQogQXQgcHJlc2VudCwgbGFyZ2Utc2NhbGUgY29tbWVyY2lhbCBJT1QgaW5kdXN0cnkgZGVw bG95bWVudCBpcyB1cmdlbnQsIGl0IGlzIHRvbyBsYXRlIHRvIHdhaXQgZm9yIERUTFMgMS4zLiBU aHVzLCB3ZSBob3BlIHRoYXQgdGhlIGFib3ZlIHByb2JsZW0gY291bGQgYmUgc29sdmVkIGluIERU TFMgMS4yIGFzIHNvb24gYXMgcG9zc2libGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkFueSBjb21tZW50IGlzIGFwcHJlY2lhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+WWluIFhpbnhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHlpbnhpbnhpbmcN Cjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+5Y+R6YCB 5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiAyMDE3PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Njwvc3Bhbj7mnIg8 c3BhbiBsYW5nPSJFTi1VUyI+Mjc8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDE2OjI4 PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyI+ICdFcmljIFJlc2NvcmxhJzxicj4NCjwvc3Bhbj48Yj7mioTpgIE8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB0bHNAaWV0 Zi5vcmc7IFRvYmlhcyBHb25kcm9tPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbVExTXSBZaW4gWGlueGlu ZyBqb2lucyB0aGUgVExTIFdHPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgRXJpYyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIHNlZW4gdGhlIENJRCBzY2hl bWUsIGFuZCB0YWxrZWQgd2l0aCBIYW5uZXModGhlIGF1dGhvciBvZiB0aGUgc2NoZW1lKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q0lEIHNjaGVtZSBpcyBhIGdvb2QgaWRl YSB0byBzb2x2ZSB0aGUgcHJvYmxlbSBJIG1lbnRpb25lZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZSBsZW5ndGggb2YgQ0lEIChjdXJyZW50bHksIGl0 IGlzIDMyIGJpdHMpIGNhbiBiZSBsb25nZXIgc28gdGhhdCBpdCBjYW4gc3VwcG9ydCBtb3JlIERU TFMgc2Vzc2lvbnMuIEl0IGlzIGtub3duIHRoYXQgZm9yIElPVCBzY2VuYXJpbywNCiAxIG1pbGxp b24gY29ubmVjdGlvbiBpcyBub3RoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ WWluIFhpbnhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IEVyaWMgUmVzY29ybGEgWzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPm1h aWx0bzpla3JAcnRmbS5jb208L2E+XQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IDIwMTc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuW5tDxzcGFuIGxh bmc9IkVOLVVTIj42PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yNTwvc3Bhbj7ml6U8c3Bh biBsYW5nPSJFTi1VUyI+DQogMjE6MzM8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4geWlueGlueGluZzxicj4N Cjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiA8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj4NCnRsc0BpZXRmLm9yZzwv YT47IFhpb25neGlhb2NodW48YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtUTFNdIFlpbiBYaW54aW5nIGpv aW5zIHRoZSBUTFMgV0c8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgWWluLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSB1c3VhbCBzb2x1dGlv biB0byB0aGlzIGlzIHRvIGFkZCBhIGNvbm5lY3Rpb24gaWQuIFBsZWFzZSBzZWU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy9kdGxzMTMtc3Bl Yy9pc3N1ZXMvNiI+aHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL2R0bHMxMy1zcGVjL2lzc3Vlcy82 PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LUVr cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gU3VuLCBKdW4gMjUsIDIwMTcgYXQgMjozMyBBTSwgeWlu eGlueGluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlpbnhpbnhpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnlpbnhpbnhpbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGVsbG8gZXZlcnlvbmUsDQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5JIGFtIFlpbiBYaW54aW5nIGZyb20gSHVhd2VpIGNvbXBhbnkuIEkgYW0gZ2xhZCB0byBqb2lu IHRoZSBUTFMgV0cuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Rm9yIHRoZSBETFRTIDEuMyBkcmFmdCwgSSBhbSBpbnRl cmVzdGVkIGFuZCBoYXZlIHNvbWUgaWRlYXMgdG8gdGFsayB3aXRoIHlvdS4NCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkRUTFMgaGFzIGEgbG90IG9mIGFwcGxpY2F0aW9uIHNjZW5hcmlvcyBpbiBJT1QgZmllbGRzLCBi dXQgY3VycmVudGx5LCB0aGVyZSBpcyBzb21lIGRpZmZpY3VsdHkgd2hlbiBEVExTIDEuMiBpcyBh cHBsaWVkIHRvIElPVCBkZXZpY2VzLA0KIGVzcGVjaWFsbHkgdGhlIGJhdHRlcnktY29uc3RyYWlu ZWQgSU9UIGRldmljZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Rm9yIGV4YW1wbGUsIHdoZW4gdGhlIElPVCBkZXZp Y2Ugd2FrZXMgdXAgZnJvbSBzbGVlcCBtb2RlLCB0aGUgTkFUIHRhYmxlIG1heSBoYXZlIGV4cGly ZWQuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5UaGVuIHRoZSBJT1QgZGV2aWNlIGhhcyB0byBlc3RhYmxpc2ggYSBuZXcgRFRMUyBz ZXNzaW9uIG9yIGF0IGxlYXN0IGxhdW5jaGVzIGEgcmVzdW1lIHByb2Nlc3Mgd2l0aCB0aGUgc2Vy dmVyLCB0aGUgY29ycmVzcG9uZGluZyBwb3dlcg0KIGNvbnN1bXB0aW9uIGlzIHRvbyBoaWdoIGZv ciBzb21lIHBvd2VyLWNvbnN0cmFpbmVkIGRldmljZXMuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhvdyBjYW4gRFRMUyByZW5lZ290 aWF0aW9uIGJlIGF2b2lkZWQgaW4gb3JkZXIgdG8gc2F2ZSBiYXR0ZXJ5Pzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkg aG9wZSB0aGUgY29udHJpYnV0b3JzIG9mIERUTFMgMS4zIChvciBEVExTIDEuMikgY2FuIGNvbnNp ZGVyIHRoaXMgcHJvYmxlbSBhbmQgZ2l2ZSBhIHByb3BlciBzb2x1dGlvbi4gJm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+QW55IGNvbW1lbnQgb3IgaWRlYSBhYm91dCB0aGlzIHByb2JsZW0gaXMgd2VsY29tZS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPllpbiBYaW54aW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpU TFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DBDF9AE44733284D808F0E585E1919022C78B070dggemi508mbxchi_-- From nobody Fri Jul 7 00:02:49 2017 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 56DA5129B25 for ; Fri, 7 Jul 2017 00:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 EVghV1eJ9yFX for ; Fri, 7 Jul 2017 00:02:45 -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 3A4A1126579 for ; Fri, 7 Jul 2017 00:02:45 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id 16so20572382qkg.2 for ; Fri, 07 Jul 2017 00:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LMRyJYATXhkTZpIuh1jzPgOgRDuMvq9JfFiP7CQ3yQI=; b=ZOT9T6/q/Mn49oX4UDAYsIyM70C8iQ27b6luEnLuPCrDIFH7gMzVKYhLv/0E1FrOYw ItZ1uBOBkGHxAiEdW3avIOXhL6jaU+Z3S5W1pYzXgBf7vovb6DrOnu9uBhWKtYpZtFzc FiiX0zksh/qDV+6zO344cF2DBo2rdjPy/k212lTAGHxfESb4geeQhYB95eU4k0TBYzUE 0lgwOV++gs07Mdx0iDPoWsKHB2vmjFtQAvj59fDFAl9pyBHzAsfCQx/NzKyJUL2G3feU qlCqlfh6CA4qmdLPEHXB6FhDOb1RwWiMlGt4qnL6Sy9J70NJ7jjWP1p9sTlTc9EIqitd iKVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LMRyJYATXhkTZpIuh1jzPgOgRDuMvq9JfFiP7CQ3yQI=; b=nul+VEx0ZiXLF8dn059tKiJhRvq1cRdX6m0AbyGtEHERd+U7DDHn8xoSH8gXkoTB7C Gb76LsJtFNUeUzWnKbpqZq2v51XWzfJ5tewinZIGzhyHX6/p1Pxo/XaG6dz7c612gIxa KTI07/N0zGAuirQBxjGgmUS1YJvO0F25jk7fGMPFs4moAqDi13hQpRnoevXfED9CUmIH 3gcN46VXUSxbtk60pBa8ZvvI/R1qUYBwBuw5uZ7m5k8VDuxFHWkfQM5IuFKlgmcMRM16 73rv8jms7caNQDOy0bbSFXmbib5otpdcJ/gNvX4DJx4gyyK7+/xmqkAb/1HVk2WKA5Us O2/w== X-Gm-Message-State: AKS2vOxIc9gBu9pIA4384k8zidbUdUuEqe8lpM+fIGg3uiUPlkTh8+uB OtEwdkLshi54vr5qa4EBx8Hs2neQpDH0ldw= X-Received: by 10.55.1.140 with SMTP id u12mr66247423qkg.108.1499410964306; Fri, 07 Jul 2017 00:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.109 with HTTP; Fri, 7 Jul 2017 00:02:43 -0700 (PDT) From: Matthew Green Date: Fri, 7 Jul 2017 03:02:43 -0400 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="001a11405320e6623b0553b4d108" Archived-At: Subject: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 07:02:47 -0000 --001a11405320e6623b0553b4d108 Content-Type: text/plain; charset="UTF-8" The need for enterprise datacenters to access TLS 1.3 plaintext for security and operational requirements has been under discussion since shortly before the Seoul IETF meeting. This draft provides current thinking about the way to facilitate plain text access based on the use of static (EC)DH keys on the servers. These keys have a lifetime; they get replaced on a regular schedule. A key manager in the datacenter generates and distributes these keys. The Asymmetric Key Package [RFC5958] format is used to transfer and load the keys wherever they are authorized for use. We have asked for a few minutes to talk about this draft in the TLS WG session at the upcoming Prague IETF. Please take a look so we can have a productive discussion. Of course, we're eager to start that discussion on the mail list in advance of the meeting. The draft can be found here: https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 Thanks for your attention, Matt, Ralph, Paul, Steve, and Russ --001a11405320e6623b0553b4d108 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The need for enterprise da= tacenters to access TLS 1.3 plaintext for security and operational requirem= ents has been under discussion since shortly before the Seoul IETF meeting.= This draft provides current thinking about the way to facilitate plain tex= t access based on the use of static (EC)DH keys on the servers. These keys = have a lifetime; they get replaced on a regular schedule. A key manager in = the datacenter generates and distributes these keys.=C2=A0 The Asymmetric K= ey Package [RFC5958] format is used to transfer and load the keys wherever = they are authorized for use.

We have asked for a few minutes to talk about thi= s draft in the TLS WG session at the upcoming Prague IETF. Please take a lo= ok so we can have a productive discussion.=C2=A0 Of course, we're eager= to start that discussion on the mail list in advance of the meeting.

The draft can be found here:

=
https://tools.ie= tf.org/html/draft-green-tls-static-dh-in-tls13-01

Thanks for your attention,
Matt, Ralph, Paul, Steve, and Ru= ss
--001a11405320e6623b0553b4d108-- From nobody Fri Jul 7 01:40:25 2017 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 23B8F129B10 for ; Fri, 7 Jul 2017 01:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 Fdfx_tdZLw2Q for ; Fri, 7 Jul 2017 01:40:22 -0700 (PDT) Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE28F120726 for ; Fri, 7 Jul 2017 01:40:21 -0700 (PDT) Received: by mail-wr0-f169.google.com with SMTP id 77so36783121wrb.1 for ; Fri, 07 Jul 2017 01:40:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hqg+wFiF3BttmJ/XwYTCbai3BMR1d3sxN8OlDjM6WnI=; b=Q11p+SlOxJOudiEuZjaBB0RYESPtc1X2Cv1lS94RLPE8IHCBvj4YCGs6LNN55NaWzN KK99ArqrFkY6X5+NNI7XqIlA7ojJ+kO1ok2py+u02grKmseWslfl1aVPYRla9oE09jbF 7iGG83VLV7Je8JNZJ13KIXCDNEIwwmLx1wDzWVywt+vnzEbdTDGeppWLpBRbGFbtxNa9 AGxcKTz7N67/rOEAiolA+PrCWBuNTfpqf9T41wkcfbkIqWMz13nJwkHgKhYHsH70UA1B JpuKnMO7LGcFXN1DNoHmnAAZmC0+CNnFpdLbAXIJ6XCPlQkjAXVhmun4Y1bnxxpHZjW/ Gtbg== X-Gm-Message-State: AIVw113rzCxhJDglvUvyxIMONVEcwsfLXA0qhKlotFwete5gPrWPcVzC PCT8y9wvjzvX3BwBS45//VZrNSX1/ZAhtjw= X-Received: by 10.223.166.2 with SMTP id k2mr95930wrc.34.1499416820241; Fri, 07 Jul 2017 01:40:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.20.203 with HTTP; Fri, 7 Jul 2017 01:40:19 -0700 (PDT) In-Reply-To: References: <1499179408.2892.13.camel@redhat.com> From: Nikos Mavrogiannopoulos Date: Fri, 7 Jul 2017 10:40:19 +0200 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045cf0d2f0eca40553b62e39" Archived-At: Subject: Re: [TLS] signature algorithm ID re-use X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 08:40:24 -0000 --f403045cf0d2f0eca40553b62e39 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 12:50 AM, Martin Thomson wrote: > On 4 July 2017 at 07:43, Nikos Mavrogiannopoulos wrote: > > So my question is why not go for the simpler approach and create new > > identifiers for the new signature algorithms? (similarly to RSA-PSS). > > Is there an advantage of re-using the ECDSA signature algorithm > > identifiers to mean something different in TLS 1.3? Was there some > > discussion on the topic on the list? > > > This was fairly extensively litigated. I remember Hannes asking > exactly the same question, but I forget which in-person meeting it > was. It might have been IETF 97. > > Unfortunately, any search I do on this subject turns up the hundreds > of emails on using signature algorithms for selecting certificates. > > What I've found is that this isn't that difficult to implement > correctly, even across versions. As David Benjamin suggested in > earlier emails, you can change to using a 16-bit codepoint in your > code. Then you add a curve-matching restriction if the selected > version is TLS 1.3 (or greater). > Well, it depends on the definition of correctly :) You can certainly have interoperation following something similar to what you describe, however the question is what about semantics. How do you translate that to the user? If one is careful with semantics and would like to let the user specify a policy of allowed operations/signature algorithms, he would have to specify two different signature algorithms, one for ecdsa with any curve, and another for the restricted to secp256r1, and then make sure that what is sent over the wire will be interpreted according to the policy by a TLS 1.2 or a TLS 1.3 server (which I find it quite impossible for any policy which requires anything else than a single curve and signature algorithm). That's why my question is on what is the advantage of the code point re-use, because I see only disadvantages. regards, Nikos --f403045cf0d2f0eca40553b62e39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 12:50 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 4 July 2017 at 07:43, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> So my question is why not go for the simpler approach and create new > identifiers for the new signature algorithms? (similarly to RSA-PSS).<= br> > Is there an advantage of re-using the ECDSA signature algorithm
> identifiers to mean something different in TLS 1.3? Was there some
> discussion on the topic on the list?


This was fairly extensively litigated.=C2=A0 I remember Hannes askin= g
exactly the same question, but I forget which in-person meeting it
was.=C2=A0 It might have been IETF 97.

Unfortunately, any search I do on this subject turns up the hundreds
of emails on using signature algorithms for selecting certificates.

What I've found is that this isn't that difficult to implement
correctly, even across versions.=C2=A0 As David Benjamin suggested in
earlier emails, you can change to using a 16-bit codepoint in your
code.=C2=A0 Then you add a curve-matching restriction if the selected
version is TLS 1.3 (or greater).

Well, = it depends on the definition of correctly :) You can certainly have interop= eration following something similar to what you describe, however the quest= ion is what about semantics. How do you translate that to the user? If one = is careful with semantics and would like to let the user specify a policy o= f allowed operations/signature algorithms, he would have to specify two dif= ferent signature algorithms, one for ecdsa with any curve, and another for = the restricted to secp256r1, and then make sure that what is sent over the = wire will be interpreted according to the policy by a TLS 1.2 or a TLS 1.3 = server (which I find it quite impossible for any policy which requires anyt= hing else than a single curve and signature algorithm).

T= hat's why my question is on what is the advantage of the code point re-= use, because I see only disadvantages.

regards= ,
Nikos

--f403045cf0d2f0eca40553b62e39-- From nobody Fri Jul 7 03:27:58 2017 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 E3932129AD3 for ; Fri, 7 Jul 2017 03:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJxhwIKjacFC for ; Fri, 7 Jul 2017 03:27:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D7A12ECCE for ; Fri, 7 Jul 2017 03:27:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61705BEB0; Fri, 7 Jul 2017 11:27:51 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PR0C8Qw_fL3; Fri, 7 Jul 2017 11:27:46 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D199BE8A; Fri, 7 Jul 2017 11:27:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499423266; bh=8i32S0THDv7COYjM6CsUeF8lbLiI++tWdcf4LeKDd9c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=awhQg6/AscJ5xm7UtiNPv80W8zrH95cWzMjgEYqp1Yj191b+ACrDAQgOCRSrDDrjr 7ArSl6MaI/ip4x63Oj2Dz7pNe6cjG7u1MTi0dw972Y6buR4FCTwsAXwNB/cR1XEO9z XLLco23F/WlkfxAXLSO70xo4IaRqlDIk4PVeypxo= To: Matthew Green , tls@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <36dfe827-be6e-3205-4262-a68be066b61e@cs.tcd.ie> Date: Fri, 7 Jul 2017 11:27:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nVMjUSx1PmcAlXU1CdtSo7qhO1HdJIU4N" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 10:27:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nVMjUSx1PmcAlXU1CdtSo7qhO1HdJIU4N Content-Type: multipart/mixed; boundary="4RDMxsBPP51bObrnCRp5c8FIQ7Eub6RXb"; protected-headers="v1" From: Stephen Farrell To: Matthew Green , tls@ietf.org Message-ID: <36dfe827-be6e-3205-4262-a68be066b61e@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: In-Reply-To: --4RDMxsBPP51bObrnCRp5c8FIQ7Eub6RXb Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I don't believe the WG should adopt this as it goes against rfc2804 and encourages bad behaviour. We ought not be helping to normalise broken crypto. I'm happy to repeat that at the mic in Prague but would be even happier if this draft were not discussed there - these attempts to weaken security have IMO already taken up too much time and too many cycles. S. On 07/07/17 08:02, Matthew Green wrote: > The need for enterprise datacenters to access TLS 1.3 plaintext for > security and operational requirements has been under discussion since > shortly before the Seoul IETF meeting. This draft provides current thin= king > about the way to facilitate plain text access based on the use of stati= c > (EC)DH keys on the servers. These keys have a lifetime; they get replac= ed > on a regular schedule. A key manager in the datacenter generates and > distributes these keys. The Asymmetric Key Package [RFC5958] format is= > used to transfer and load the keys wherever they are authorized for use= =2E >=20 > We have asked for a few minutes to talk about this draft in the TLS WG > session at the upcoming Prague IETF. Please take a look so we can have = a > productive discussion. Of course, we're eager to start that discussion= on > the mail list in advance of the meeting. >=20 > The draft can be found here: >=20 > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 >=20 > Thanks for your attention, > Matt, Ralph, Paul, Steve, and Russ >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --4RDMxsBPP51bObrnCRp5c8FIQ7Eub6RXb-- --nVMjUSx1PmcAlXU1CdtSo7qhO1HdJIU4N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZX2IhAAoJEC88hzaAX42i3EQIAICkol+vuvx6MXXc92MfbypX TKb8bMm4et4CvkAxfIrZFKZAOaDWsGGjZN+f2PVEGGpu+7D11ggglaYWFw6/Rt9q FskuwTUppjG7S8Xaf2+DWKhwHHi/baFOTWEPzsxEFCBb8b04i4t63yM2Ewj3rP5i jb56CIs0Sc3g9JcCB4Oq/CHFyDmhGY/eTJfhTt7Ln39J7V5jfugfpMWbx5V3oLLr xUzSWikey3L6zc5+uGdm5v6GLFbxtqf6bp+xEFtYf+BSSiOF0g30foMLzsEVMULA 8QDcshFM1uStdvCGe8x5swXBSk2AIGb4FkoKpB4y3sTY2uwjznegY3XS2T8ZxDs= =9NXk -----END PGP SIGNATURE----- --nVMjUSx1PmcAlXU1CdtSo7qhO1HdJIU4N-- From nobody Fri Jul 7 03:42:48 2017 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 7F01312ECEF for ; Fri, 7 Jul 2017 03:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=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 0ZQbZBbpCb88 for ; Fri, 7 Jul 2017 03:42:44 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [212.227.20.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928D01270A3 for ; Fri, 7 Jul 2017 03:42:44 -0700 (PDT) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id F1A881398 for ; Fri, 7 Jul 2017 11:42:42 +0100 (BST) Received: by mail-it0-f45.google.com with SMTP id k192so31450665ith.1 for ; Fri, 07 Jul 2017 03:42:42 -0700 (PDT) X-Gm-Message-State: AIVw111cvSUb0EXgDRrqWbDffUsUUBv+NiUVwreZh9i9u1y3te9k4lNX I+WrL04ZOBowPjPm0yaeUNAia0MtYQ== X-Received: by 10.36.189.198 with SMTP id x189mr2142120ite.56.1499424161474; Fri, 07 Jul 2017 03:42:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.33.66 with HTTP; Fri, 7 Jul 2017 03:42:40 -0700 (PDT) In-Reply-To: References: <20170704105050.zqclbfje2rvly5dm@LK-Perkele-VII> From: Matt Caswell Date: Fri, 7 Jul 2017 11:42:40 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 10:42:46 -0000 On 5 July 2017 at 11:35, Eric Rescorla wrote: > > Yes, that might not be a terrible idea. I'd also be open to replacing > the hashes of 0 with an n-byte length 0 string. It's a tiny paper > cut (and a wire format change), but would make things slightly simpler . I'm not entirely sure what you mean be the "hashes of 0". Are you referring to the 0 length input passed to Derive-Secret in the various Derive-Secret(., "derived", "") instances (and also for the binder_key)? Matt From nobody Fri Jul 7 06:02:13 2017 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 40F5D131460 for ; Fri, 7 Jul 2017 06:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 cI3ISP8dpqE3 for ; Fri, 7 Jul 2017 06:02:09 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 219AE1201F8 for ; Fri, 7 Jul 2017 06:02:07 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id c11so46189109wrc.3 for ; Fri, 07 Jul 2017 06:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ISvv6U88VsKwb9R5lhHy/GQBZ5bMbyY42Hm2teeCvMQ=; b=Iygy6+35yofYAepq3rpgGfzDxf7TvwwWqLiqOREQVHLfFV+EGjdMbtY6/KR+BH0Gat RXBns1vxywR+h91dZMEZXXkDWn5LDQ+oXv4kYsCHIaOB7bFrsDMoAYs/unyYv7AIsXym /8f3rSFmujqXFAB0uCt2HF6+oLVWmuD4TOimTHApD/+Xwg7aOqLijUXTwnJA/HiswQfa N5zR6FUOkdet7uM0JkOlZLWS8QdHKMuE436gzCAFhdp3xW7fKBATIFVwfNMhn4QVSayR Ve9VZ2RuDBKvkNBsBvEuJczBoBVtr6psm7Bj94PhuehVq8E+3AOfwqnn+xmlrzLG20AC IP0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ISvv6U88VsKwb9R5lhHy/GQBZ5bMbyY42Hm2teeCvMQ=; b=ksnhzaOjfCXSZAmtW6WmpidcJ1OZH1qFo70aTQ1FBY6nxReOdRvhW5F85HAGDhh2O1 ngWHAHu5noOhud1ttMLel+SPVH2rIA4AwMjcP9/QJ9A0fsA3pimpH+GqGV6YzS2GOH3L K9iz60CshPCIK4yirAvBfSv7kyT7HjvA0WSxV0ddNH5DZ6EpPrjAHpS4N8Zf61VWOJNf OzDP9XPz3NoBZlGKjXbtlf53Sa3gZrljDHSvhx4qXLvJSag41s/rraQ2hapvoQTi3ZtC yvowTpFWBwQkQwKwHX3GSBVMd5LTcx8axi5SlWaTYa2W9Yz4MjN4mNRmGu+ldUJ7WDcl NYCg== X-Gm-Message-State: AIVw113mBQpyYvHX9Yw/ps5DTkdXyMD6AGf1o9IAQ2iI8HJux/4QpRie 8AtKjvoLseBwlEADpjUwOwov5zrjBPxx X-Received: by 10.223.153.238 with SMTP id y101mr740303wrb.168.1499432525466; Fri, 07 Jul 2017 06:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Fri, 7 Jul 2017 06:02:04 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Fri, 7 Jul 2017 09:02:04 -0400 Message-ID: To: Matthew Green Cc: "" Content-Type: multipart/alternative; boundary="f403045f4d020bb6920553b9d753" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 13:02:11 -0000 --f403045f4d020bb6920553b9d753 Content-Type: text/plain; charset="UTF-8" Without taking a position on whether this group should take on this work, a couple of questions about alternative approaches (sorry if these have been answered before): 1. It seems like the requirement here is that the DH private key be *predictable* by the monitoring box based on some static configuration. That is, it seems like you could have keys that are predictable to the monitoring device, but still vary over time, something like setting the private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom). Without having done much analysis, this seems more conservative than making things entirely static. Is there a reason to prefer the purely static approach besides simplicity? 2. You could avoid changing how the DH works altogether by simply exporting the DH private key, encrypted with a key shared with the monitoring device, in a server extension. (Not in EncryptedExtensions, obviously.) This would also have the benefit of explicitly signaling when such monitoring is in use. The only real challenge here is that the client would have to offer the extension in order for the server to be able to send it, which I expect things like browsers would be unlikely to do. However, given that the target of this draft seems to be intra-data-center TLS, perhaps this is a workable requirement? Thanks, --Richard On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green wrote: > The need for enterprise datacenters to access TLS 1.3 plaintext for > security and operational requirements has been under discussion since > shortly before the Seoul IETF meeting. This draft provides current thinking > about the way to facilitate plain text access based on the use of static > (EC)DH keys on the servers. These keys have a lifetime; they get replaced > on a regular schedule. A key manager in the datacenter generates and > distributes these keys. The Asymmetric Key Package [RFC5958] format is > used to transfer and load the keys wherever they are authorized for use. > > We have asked for a few minutes to talk about this draft in the TLS WG > session at the upcoming Prague IETF. Please take a look so we can have a > productive discussion. Of course, we're eager to start that discussion on > the mail list in advance of the meeting. > > The draft can be found here: > > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 > > Thanks for your attention, > Matt, Ralph, Paul, Steve, and Russ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f403045f4d020bb6920553b9d753 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Without taking a position on whether this group shoul= d take on this work, a couple of questions about alternative approaches (so= rry if these have been answered before):

1. It= seems like the requirement here is that the DH private key be *predictable= * by the monitoring box based on some static configuration.=C2=A0 That is, = it seems like you could have keys that are predictable to the monitoring de= vice, but still vary over time, something like setting the private key from= a KDF(SecretSharedWithMonitoringDevice, ServerRandom). Without having done= much analysis, this seems more conservative than making things entirely st= atic. Is there a reason to prefer the purely static approach besides simpli= city?

2. You could avoid changing how the DH works= altogether by simply exporting the DH private key, encrypted with a key sh= ared with the monitoring device, in a server extension.=C2=A0 (Not in Encry= ptedExtensions, obviously.)=C2=A0 This would also have the benefit of expli= citly signaling when such monitoring is in use.=C2=A0 The only real challen= ge here is that the client would have to offer the extension in order for t= he server to be able to send it, which I expect things like browsers would = be unlikely to do.=C2=A0 However, given that the target of this draft seems= to be intra-data-center TLS, perhaps this is a workable requirement?

Thanks,
--Richard


On Fri, Ju= l 7, 2017 at 3:02 AM, Matthew Green <matthewdgreen@gmail.com>= wrote:
The need for enterprise datacenters to access TLS 1.= 3 plaintext for security and operational requirements has been under discus= sion since shortly before the Seoul IETF meeting. This draft provides curre= nt thinking about the way to facilitate plain text access based on the use = of static (EC)DH keys on the servers. These keys have a lifetime; they get = replaced on a regular schedule. A key manager in the datacenter generates a= nd distributes these keys.=C2=A0 The Asymmetric Key Package [RFC5958] forma= t is used to transfer and load the keys wherever they are authorized for us= e.

= We have asked for a few minutes to talk about this draft in the TLS WG sess= ion at the upcoming Prague IETF. Please take a look so we can have a produc= tive discussion.=C2=A0 Of course, we're eager to start that discussion = on the mail list in advance of the meeting.

The draft can be found= here:

https://tools.ietf.org/html/draft-gre= en-tls-static-dh-in-tls13-01

Thanks for your attentio= n,
Matt, Ralph, Paul, Steve, and Russ

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


--f403045f4d020bb6920553b9d753-- From nobody Fri Jul 7 06:45:04 2017 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 EBFFD129B2A; Fri, 7 Jul 2017 06:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 R5n8_hR8eiRc; Fri, 7 Jul 2017 06:44:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022491201F2; Fri, 7 Jul 2017 06:44:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQP41781; Fri, 07 Jul 2017 13:44:55 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 7 Jul 2017 14:44:53 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.147]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0301.000; Fri, 7 Jul 2017 19:14:41 +0530 From: Raja ashok To: "draft-mavrogiannopoulos-tls-cid@ietf.org" , "nmav@redhat.com" , "hannes.tschofenig@arm.com" , "Fossati, Thomas (Nokia - GB)" CC: "" Thread-Topic: Suggestions in draft-mavrogiannopoulos-tls-cid Thread-Index: AdL3Jy6Gr1KoWVE3S5i3yCcIRuxQog== Date: Fri, 7 Jul 2017 13:44:41 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E22F7C99BLREML503MBXchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.595F9057.01B9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.9.147, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7c8f15771cacedc70c8b5d2acd02ef47 Archived-At: Subject: [TLS] Suggestions in draft-mavrogiannopoulos-tls-cid X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 13:45:03 -0000 --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E22F7C99BLREML503MBXchi_ Content-Type: multipart/alternative; boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E22F7C99BLREML503MBXchi_" --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E22F7C99BLREML503MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTmlrb3MsIEhhbm5lcyAmIFRob21hcywNCg0KVGhpcyBDb25uZWN0aW9uSUQgY29uY2VwdCBp cyByZWFsbHkgYSB1c2VmdWwgZmVhdHVyZSBmb3IgYSBjbGllbnQgbm9kZSB3aGljaCBmYWNlcyBh IGNoYW5nZSBpbiB0cmFuc3BvcnQgYW5kIG5ldHdvcmsgbGF5ZXIuIEkgYW0gaGF2aW5nIGZldyBz dWdnZXN0aW9ucyBpbiB0aGUgcHJvcG9zZWQgZHJhZnQsIHdoaWNoIGFyZSBsaXN0ZWQgYmVsb3cu DQoNCjEpIEluIHNlY3Rpb24gMyBvZiB0aGlzIGRyYWZ0LCBleHBsYWlucyBhYm91dCB0aGUgbW9k aWZpY2F0aW9uIGluICJEVExTQ2lwaGVydGV4dCIgc3RydWN0dXJlLiBJIGZlZWwgaW5zdGVhZCBv ZiBtb2RpZnlpbmcgZXhpc3RpbmcgRFRMUyBhbmQgVExTIHJlY29yZCBoZWFkZXIsIHdlIGNhbiBk aXJlY3RseSBpbnRyb2R1Y2UgYSBuZXcgcmVjb3JkIHR5cGUgKENvbnRlbnRUeXBlKSBmb3IgYXBw IGRhdGEgKGFwcGxpY2F0aW9uX2RhdGFfd2l0aF9jaWQoMjUpKS4gRm9yIHRoaXMgbmV3IHJlY29y ZCB0eXBlLCB3ZSBjYW4gcHJvcG9zZSBhIG1vZGlmaWVkIHJlY29yZCBoZWFkZXIgZm9yIGJvdGgg VExTIGFuZCBEVExTLg0KDQoyKSBNb3JlIG92ZXIgc2VjdGlvbiAzIHNheXMgbW9kaWZpY2F0aW9u IG9ubHkgaW4gIkRUTFNDaXBoZXJ0ZXh0Iiwgbm90IGZvciAiVExTQ2lwaGVydGV4dCIuIEkgaG9w ZSB0aGlzIENJRCBtZWNoYW5pc20gc2hvdWxkIGJlIHVzZWQgZm9yIGJvdGggVExTIGFuZCBEVExT LiBCZWNhdXNlIHRoaXMgdHJhbnNwb3J0IGxheWVyIGNoYW5nZSBwcm9ibGVtIGlzIHRoZXJlIGZv ciBUTFMgYmFzZWQgYXBwbGljYXRpb25zIChIVFRQUykgYWxzbyBpbiBTbWFydHBob25lKHdoZW4g aXQgc3dpdGNoZXMgZnJvbSBXaWZpIHRvIExURSkuIEJ1dCB0aGlzIFRMUyBhcHBsaWNhdGlvbiBw cm9ibGVtIGlzIHNvbHZlZCBieSBNUFRDUCwgYnV0IEkgZG9udCB0aGluayBhbGwgd2Vic2VydmVy cyBhcmUgc3VwcG9ydGluZyB0aGlzIE1QVENQLiBTbyBJIGZlZWwgQ0lEIGlzIHJlcXVpcmVkIGZv ciBib3RoIFRMUyBhbmQgRFRMUy4NCg0KMykgQXMgcGFydCBvZiBkZWZpbmluZyBuZXcgcmVjb3Jk IHR5cGUsIHdlIGNhbiByZW1vdmUgc29tZSB1bnVzZWQgZmllbGRzIGxpa2UgdmVyc2lvbiwgZXBv Y2guIEFmdGVyIHJlbW92aW5nIGVwb2NoIHdlIGNhbiBtYW5kYXRlIHRoYXQgIGJvdGggZW50aXR5 IHNob3VsZCBub3Qgc3RhcnQgcmVuZWdvdGlhdGlvbi4gU2FtcGxlIGRlc2lnbiBmb3IgbmV3IHJl Y29yZCBoZWFkZXIgd2l0aCBDSUQgaXMgbWVudGlvbmVkIGJlbG93DQogICAgc3RydWN0IHsNCiAg ICAgICAgdWludDhfdCBDb250ZW50VHlwZTsNCiAgICAgICAgdWludDhfdCBDSURfbGVuOw0KICAg ICAgICBDSUQgY2lkOyAgICAgICAgLyogTGVuZ3RoIHZhcmllcyBmcm9tIDQgdG8gOCAob3IgMTYp ICovDQogICAgICAgIHVpbnQ0OCBzZXF1ZW5jZV9udW1iZXI7DQogICAgICAgIHVpbnQxNl90IHJl Y29yZF9sZW5ndGg7DQogICAgfSBEVExTUmVjb3JkSGVhZGVyOw0KICAgIG9wYXF1ZSBDSUQgPDQu Ljg+Ow0KDQogICAgc3RydWN0IHsNCiAgICAgICAgdWludDhfdCBDb250ZW50VHlwZTsNCiAgICAg ICAgdWludDhfdCBDSURfbGVuOw0KICAgICAgICBDSUQgY2lkOyAgICAgICAgLyogTGVuZ3RoIHZh cmllcyBmcm9tIDQgdG8gOCAob3IgMTYpICovDQogICAgICAgIHVpbnQxNl90IHJlY29yZF9sZW5n dGg7DQogICAgfSBUTFNSZWNvcmRIZWFkZXI7DQogICAgb3BhcXVlIENJRCA8NC4uOD47DQoNCjQp IEFub3RoZXIgb3B0aW9uIGlzIHdlIGNhbiBrZWVwIENJRF9sZW4gYXMgNCBiaXQgdG8gcmVwcmVz ZW50IGEgQ0lEIG9mIHNpemUuIEFuZCB0aGlzIDQgYml0IGNhbiBiZSBwbGFjZWQgaW4gdGhlIE1T QiBvZiB0aGUgQ0lEIGZpZWxkLg0KICAgICAgICAuLi4uDQogICAgICAgIHVpbnQ4X3QgQ0lEX2xl bjo0Ow0KICAgICAgICBDSUQgY2lkOyAgICAgICAgLyogTGVuZ3RoIHZhcmllcyBmcm9tIDI4Yml0 IHRvIDYwIGJpdCAob3IgMTI0Yml0KSAqLw0KICAgICAgICAuLi4uDQoNCjUpIFNlY3Rpb24gMy4x IGFuZCAzLjIgdGFsa3MgYWJvdXQgdGhlIG5ldyBleHRlbnNpb25zIGZvciBuZWdvdGlhdGluZyB0 aGlzIGZlYXR1cmUgc3VwcG9ydC4gQnV0IEkgZmVlbCBubyBuZWVkIG9mIG5ldyBleHRlbnNpb25z IHRvIG5lZ290aWF0ZSB0aGlzLCB3ZSBjYW4gbWFrZSBjbGllbnQgdG8gYWRkIG5ldyBTQ1NWIGNp cGhlciBpbiBpdHMgY2lwaGVyIGxpc3QuIElmIHNlcnZlciBhY2NlcHRzIHRoZW4gYWZ0ZXIgaGFu ZHNoYWtlIHRoZSBmaXJzdCBhcHBsaWNhdGlvbiBkYXRhIHNlbmQgYnkgc2VydmVyIHNob3VsZCBi ZSBvZiB0eXBlIGFwcGxpY2F0aW9uX2RhdGFfd2l0aF9jaWQoMjUpLCB3aGljaCBzaG91bGQgaG9s ZCB0aGUgbmV3IHJlY29yZCBoZWFkZXIgd2l0aCBDSUQuIFRoZSBzYW1lIENJRCBzaG91bGQgYmUg dXNlZCBieSBjbGllbnQgaW4gdGhlIGZ1cnRoZXIgbWVzc2FzZ2UuIElmIGNsaWVudCBzZW5kcyB0 aGUgMXN0IGFwcGxpY2F0aW9uIGRhdGEgYWZ0ZXIgaGFuZHNoYWtlLCB0aGVuIGl0IGNhbiBzZW5k IGFwcGxpY2F0aW9uIGRhdGEgd2l0aCBkZWZhdWx0IHJlY29yZCB0eXBlIChhcHBsaWNhdGlvbl9k YXRhKDIzKSkuIElmIHRoZSBmaXJzdCBhcHBsaWNhdGlvbiBkYXRhIHJlY29yZCByZWNlaXZlZCBm cm9tIHNlcnZlciBpcyBub3Qgb2YgYXBwbGljYXRpb25fZGF0YV93aXRoX2NpZCgyNSkgbWVhbnMg Y2xpZW50IHNob3VsZCB1bmRlcnN0YW5kIHRoYXQgc2VydmVyIGhhcyBub3QgYWNjZXB0ZWQgdGhl IFNDU1YgcHJvcG9zZWQuIEFuZCBjbGllbnQgc2hvdWxkIGNvbnRpbnVlIGFwcCB0cmFuc2ZlciB3 aXRoIGRlZmF1bHQgcmVjb3JkIHR5cGUgKGFwcGxpY2F0aW9uX2RhdGEoMjMpKS4NCg0KUGxlYXNl IHByb3ZpZGUgeW91ciBjb21tZW50cyBvbiB0aGlzIHN1Z2dlc3Rpb24uDQoNClJlZ2FyZHMsDQpB c2hvaw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpbQ29tcGFueV9sb2dv XQ0KDQpSYWphIEFzaG9rIFYgSw0KSHVhd2VpIFRlY2hub2xvZ2llcw0KQmFuZ2Fsb3JlLCBJbmRp YQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Ksb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8Pm tdjWt9bQwdCz9rXEuPbIy7vyyLrX6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw /MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQq1xNDF z6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z /bG+08q8/qOhDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBm b3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFu eSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGlu Y2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJl LCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0 aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0 aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBv ciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQo= --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E22F7C99BLREML503MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Nikos, Hannes & Thomas,

 

This ConnectionID concept is really a useful feature= for a client node which faces a change in transport and network layer. I a= m having few suggestions in the proposed draft, which are listed below.

 

1) In section 3 of this draft, explains about the mo= dification in "DTLSCiphertext" structure. I feel instead of modif= ying existing DTLS and TLS record header, we can directly introduce a new r= ecord type (ContentType) for app data (application_data_with_cid(25)). For this new record type, we can propose a modified record header for both= TLS and DTLS.

 

2) More over section 3 says modification only in &qu= ot;DTLSCiphertext", not for "TLSCiphertext". I hope this CID= mechanism should be used for both TLS and DTLS. Because this transport lay= er change problem is there for TLS based applications (HTTPS) also in Smartphone(when it switches from Wifi to LTE). But this TL= S application problem is solved by MPTCP, but I dont think all webservers a= re supporting this MPTCP. So I feel CID is required for both TLS and DTLS.<= o:p>

 

3) As part of defining new record type, we can remov= e some unused fields like version, epoch. After removing epoch we can manda= te that  both entity should not start renegotiation. Sample design for= new record header with CID is mentioned below

    str= uct {

   &nbs= p;    uint8_t ContentType;

   &nbs= p;    uint8_t CID_len;

   &nbs= p;    CID cid;        /* = Length varies from 4 to 8 (or 16) */

   &nbs= p;    uint48 sequence_number;

   &nbs= p;    uint16_t record_length;

    } D= TLSRecordHeader;

    opa= que CID <4..8>;

 

    str= uct {

   &nbs= p;    uint8_t ContentType;

   &nbs= p;    uint8_t CID_len;

   &nbs= p;    CID cid;        /* = Length varies from 4 to 8 (or 16) */

   &nbs= p;    uint16_t record_length;

    } T= LSRecordHeader;

    opa= que CID <4..8>;

 

4) Another option is we can keep CID_len as 4 bit to= represent a CID of size. And this 4 bit can be placed in the MSB of the CI= D field.

   &nbs= p;    ....

   &nbs= p;    uint8_t CID_len:4; 

   &nbs= p;    CID cid;       = ; /* Length varies from 28bit to 60 bit (or 124bit) */

   &nbs= p;    ....

 

5) Section 3.1 and 3.2 talks about the new extension= s for negotiating this feature support. But I feel no need of new extension= s to negotiate this, we can make client to add new SCSV cipher in its ciphe= r list. If server accepts then after handshake the first application data send by server should be of type appl= ication_data_with_cid(25), which should hold the new record header with CID= . The same CID should be used by client in the further messasge. If client = sends the 1st application data after handshake, then it can send application data with default record type (app= lication_data(23)). If the first application data record received from serv= er is not of application_data_with_cid(25) means client should understand t= hat server has not accepted the SCSV proposed. And client should continue app transfer with default record= type (application_data(23)).

 

Please provide your comments on this suggestion.

 

Regards,

Ashok

 

 

3D"Company_logo"

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE= =BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD= =F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6= =B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0= =CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF= =BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7= =A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1= =CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA= =BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3= =A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E22F7C99BLREML503MBXchi_-- --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E22F7C99BLREML503MBXchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Fri, 07 Jul 2017 13:44:41 GMT"; modification-date="Fri, 07 Jul 2017 13:44:41 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E22F7C99BLREML503MBXchi_-- From nobody Fri Jul 7 07:10:41 2017 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 E948312ECC0 for ; Fri, 7 Jul 2017 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=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 PDANhuliaZg9 for ; Fri, 7 Jul 2017 07:10:38 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [212.227.20.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BC5129687 for ; Fri, 7 Jul 2017 07:10:37 -0700 (PDT) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id AC1B91781 for ; Fri, 7 Jul 2017 15:10:35 +0100 (BST) Received: by mail-it0-f52.google.com with SMTP id k192so36866184ith.1 for ; Fri, 07 Jul 2017 07:10:35 -0700 (PDT) X-Gm-Message-State: AKS2vOz8skNz0TDToB282njjkZaPoT7zfT1R1OU0zI627ppgfEoHT979 bdN0F7aReIHnEQQ/UWxq7PREc5bu2Q== X-Received: by 10.107.153.140 with SMTP id b134mr51630909ioe.200.1499436634086; Fri, 07 Jul 2017 07:10:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.33.66 with HTTP; Fri, 7 Jul 2017 07:10:33 -0700 (PDT) In-Reply-To: References: From: Matt Caswell Date: Fri, 7 Jul 2017 15:10:33 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 14:10:40 -0000 On 4 July 2017 at 01:01, Eric Rescorla wrote: > Hi folks, > > I just published draft-21, which incorporates the discussions we've > been having about 0-RTT replay. FYI, OpenSSL master branch is now draft-21 compliant. Matt From nobody Fri Jul 7 07:11:28 2017 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 CE55513146C for ; Fri, 7 Jul 2017 07:11:26 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 wkNWc3edZOpa for ; Fri, 7 Jul 2017 07:11:23 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E4C129687 for ; Fri, 7 Jul 2017 07:11:23 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 74D4A2421529 for ; Fri, 7 Jul 2017 14:11:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: <20170705171211.GM5673@mournblade.imrryr.org> Date: Fri, 7 Jul 2017 15:11:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F943876-91FC-4529-9B44-9F187EDA48B5@rfc1035.com> References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> <20170705171211.GM5673@mournblade.imrryr.org> To: tls@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 14:11:27 -0000 > On 5 Jul 2017, at 18:12, Viktor Dukhovni = wrote: >=20 > On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote: >=20 >> 1) There probably needs to be clearer guidance about the use cases = for >> this extension and the trade-offs between TLS clients doing DNSSEC >> validation for themselves instead of sending DNS lookups to a = validating >> resolver server. How does an application developer decide which = approach >> would or wouldn't be appropriate? >=20 > On today's Internet, DNSSEC is not generally available to end-user > devices. There are too many "last mile" problems. Thus, while > direct acquisition of DANE TLSA records works for (e.g.) dedicated > SMTP servers, any end-user application that wants to do DANE TLS > needs to use the proposed extension. I am too painfully aware of those last mile issues. =20 IMO the draft could be clearer about the fact it=E2=80=99s aimed at TLS = clients that don=E2=80=99t have access to or a trust relationship with a = validating DNS resolver. It might also be worthwhile explaining the = trade-offs between the DNSSEC lookup and TLS chaining approaches and how = an implementer or operator can choose between them when/if both are = available. Though if the spec was to say =E2=80=9Cdon=E2=80=99t bother = with DNSSEC lookups at all and just use this chaining extension=E2=80=9D, = that would be fine. > Perhaps you're asking whether once the relevant records are obtained, > their validation should be via library calls to a suitable API, or > via a suitable protocol to the local resolver? No. I couldn=E2=80=99t care less about API issues or how the RRSIGs get = validated. They=E2=80=99re implentation details for the implementation = detail. I am uneasy at the prospect of every TLS client application = include what will be essentially its own validating DNS resolver when = there could/should be one of these already running on the device itself. > Except that the records will be warm in the server's cache, since > many clients will be asking it for the *same* data. The same is > not as likely to be true at the client. So there is indeed a likely > latency reduction in farming out the lookups to the server. OK. It might be helpful to explicitly say =E2=80=9CTLS server=E2=80=9D = rather than =E2=80=9Cserver=E2=80=9D to avoid confusion or ambiguity. = Sometimes this is obvious from the context. But at other places in the = draft =E2=80=9Cserver=E2=80=9D could be read as =E2=80=9CDNS server=E2=80=9D= . >> 4) It's not clear if TLS clients can or should cache the DNS data = (and >> the resulting validations?) returned though this extension. >=20 > The server will return TTLs, and caching per those TTLs is no less > appropriate than it is in DNS generally. Is there some reason why this isn=E2=80=99t in the draft? >> 5) How does a TLS client behave when its DNSSEC validation of a TLSA = record >> or whatever fails? Can/should it give up or fall back to conventional >> validation of the certificate via a CA? >=20 > This is application/configuration dependent. That probably needs to be captured in the document too.= From nobody Fri Jul 7 07:14:58 2017 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 05E5C128CFF for ; Fri, 7 Jul 2017 07:14:57 -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, RP_MATCHES_RCVD=-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 uZkHt1NCZ5rx for ; Fri, 7 Jul 2017 07:14:55 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D061C131551 for ; Fri, 7 Jul 2017 07:14:52 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id B927F2421529; Fri, 7 Jul 2017 14:14:51 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: Date: Fri, 7 Jul 2017 15:14:51 +0100 Cc: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <31C79391-24AA-422D-8F5B-EBB4DE7DB82E@rfc1035.com> References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> To: Shumon Huque X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 14:14:57 -0000 > On 7 Jul 2017, at 02:47, Shumon Huque wrote: >=20 > I assume you're referring to the examples in Appendix D (Test = Vectors)? Yes. > These are working examples that implementers can test code against. = But it looks like the testbed involved in these examples uses combined = signing keys (i.e. ones that are both the zone's secure entry point and = the ZSK). Perhaps we should use an example with the KSK/ZSK split to = make them look more like the real world. Let me discuss with Willem = Toorop (co-author) who generated these ... Willem told me he=E2=80=99d used the KSK as the ZSK for cosmetic = reasons. Examples showing the KSK/ZSK split would show how things = generally work the real world. From nobody Fri Jul 7 07:25:39 2017 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 99372131489 for ; Fri, 7 Jul 2017 07:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-8dQHKvm8Xd for ; Fri, 7 Jul 2017 07:25:36 -0700 (PDT) Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26F112EC23 for ; Fri, 7 Jul 2017 07:25:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id CB60522C0733 for ; Fri, 7 Jul 2017 16:25:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:references:subject :subject:from:from:date:date:x-mailer:message-id:received :received:received; s=default; t=1499437533; x=1500301534; bh=ch FyCPvv4eMMDMHMZXHBSaKSqQtaAtZw7EpTWqH7Rug=; b=LK6T5GEdNDjoxPAIr+ BDlUJ7N5Ik9nWIyFNoheiSRknBrMUU3vwTnmcV3QWin2Oh+XpjAQszbOmPZJrf9X 7qS1nMs5l/25IhgDWlIfc+zyM9vKCEuzn8Ybm6VJ0MaJirBAsNXiYdNZhXw7kOYv cDZ6w40qtSxLgWHfQ48Bm5yo0= X-Virus-Scanned: amavisd-new at hs-offenburg.de Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBcgHVuRrfGu for ; Fri, 7 Jul 2017 16:25:33 +0200 (CEST) Received: from gwia2.rz.hs-offenburg.de (stud.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id 0907D22C072E for ; Fri, 7 Jul 2017 16:25:33 +0200 (CEST) Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Fri, 07 Jul 2017 16:25:32 +0200 Message-Id: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Fri, 07 Jul 2017 16:25:30 +0200 From: "Andreas Walz" To: References: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part3D0536CA.0__=" Archived-At: Subject: [TLS] Truncated HMAC: what to do with the MAC key? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 14:25:39 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part3D0536CA.0__= Content-Type: multipart/alternative; boundary="=__Part3D0536CA.1__=" --=__Part3D0536CA.1__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear all, today I encountered something that confuses me: different TLS implementations do not seem to agree on how to implement truncated HMAC. All implementations I tested truncate the HMAC output correctly, but they seem to use different MAC keys. When truncated HMAC is negotiated: -> MatrixSSL does not change the length of the MAC key but zeros all its bytes beyond index 10, -> mbedTLS truncates the MAC key to length 10, -> WolfSSL does not touch the MAC key at all. >From RFC 6066 I would infer that the MAC key should not be affected by the negotiation of the truncated HMAC extension (as WolfSSL is implementing it). Is that correct? Thank you very much! Cheers ___________________________________ Andreas Walz Email: andreas.walz@hs-offenburg.de Institute of reliable Embedded Systems and Communication Electronics (ivESK) Homepage: http://ivesk.hs-offenburg.de/ University of Applied Sciences Offenburg Offenburg University of Applied SciencesOffenburg University of Applied SciencesOffenburg University of Applied SciencesOffenburg University of Applied Sciences Badstraße 24 77652 Offenburg Germany --=__Part3D0536CA.1__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML =0Abody p =0A{ =0A margin: 0px; =0A}=0ADear all,

today I encountered something that = confuses me: different TLS implementations do not seem to agree on how to = implement truncated HMAC. All implementations I tested truncate the HMAC = output correctly, but they seem to use different MAC keys. When truncated = HMAC is negotiated:

-> MatrixSSL does not change the length of = the MAC key but zeros all its bytes beyond index 10,
-> mbedTLS = truncates the MAC key to length 10,
-> WolfSSL does not touch the = MAC key at all.

From RFC 6066 I would infer that the MAC key should = not be affected by the negotiation of the truncated HMAC extension (as = WolfSSL is implementing it). Is that correct?

Thank you very = much!
Cheers



___________________________________

And= reas Walz
Email: andreas.walz@hs-offenburg.de
Institute of reliable Embedded Systems and = Communication Electronics (ivESK)
Homepage: http://ivesk.hs-offenburg.de= /

University of Applied Sciences Offenburg
Offenburg = University of Applied Sciences
Offenburg University of Applied = Sciences
Offenburg University of Applied Sciences
Offenburg = University of Applied Sciences
Badstra=C3=9Fe 24
77652 Offenburg
Germany

--=__Part3D0536CA.1__=-- --=__Part3D0536CA.0__=-- From nobody Fri Jul 7 07:40:52 2017 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 F074E1315F0 for ; Fri, 7 Jul 2017 07:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 c1YXLVJpT9nm for ; Fri, 7 Jul 2017 07:40:47 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 8F6E9131538 for ; Fri, 7 Jul 2017 07:40:47 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id B6A2EC241B for ; Fri, 7 Jul 2017 09:40:46 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 15D31C1617; Fri, 7 Jul 2017 09:40:46 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D212992069; Fri, 7 Jul 2017 10:40:45 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9A60592053; Fri, 7 Jul 2017 10:40:45 -0400 (EDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (unknown [216.32.180.181]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Fri, 7 Jul 2017 10:40:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EmBEwGXn11yulHvYA2fFxsSiCTzPk7lflxb52z9Udcs=; b=iyvvgyipA2WzuqIyZeAsgGBS0qOW0CmIGKFyIZKJ6hjRCn8KuvpLk7mrQ8fENEJSbb3oFiH1qF4/zmTHCQcI+PzxH80EU1LZ2m4guikCGna7j1DDzbzEZntGDy+zuSzWc/4Vic4DyqDXrgGnER+VBKZPuCs+N6Diccjn1UI6iHw= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1367.namprd14.prod.outlook.com (10.172.158.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Fri, 7 Jul 2017 14:40:43 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1220.018; Fri, 7 Jul 2017 14:40:43 +0000 From: "Ackermann, Michael" To: Matthew Green , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIbvIQ Date: Fri, 7 Jul 2017 14:40:43 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.0.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1367; 20:/jU/h6Q53+6JHVutF8L1AMBF5o1Fwej4t7lmZJIVt9WrlxhJnJy+dC9NPGZkMRr4Ww7I8NvEczUbK+dquyceTJXllBsYAmK1kXQYpcdYVh994jxGxiX1a6j8+wsPhjzPhyKa441LUvqndk8edLsfyF/qBRb0RkBsQ7nfhqfl1y8= x-ms-office365-filtering-correlation-id: 9f51b637-1c15-4587-e7b9-08d4c54625cc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1367; x-ms-traffictypediagnostic: CY4PR14MB1367: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(26388249023172)(236129657087228)(192374486261705)(90097320859284)(48057245064654)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910064)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1367; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1367; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39410400002)(39400400002)(377454003)(77096006)(790700001)(102836003)(478600001)(74316002)(86362001)(3660700001)(189998001)(7696004)(2906002)(8676002)(8936002)(81166006)(5660300001)(2950100002)(3280700002)(7736002)(9686003)(14454004)(66066001)(6506006)(39060400002)(54896002)(2900100001)(33656002)(229853002)(38730400002)(25786009)(99286003)(6436002)(6246003)(55016002)(230783001)(19609705001)(6306002)(80792005)(236005)(3846002)(6116002)(606006)(2501003)(76176999)(53936002)(54356999)(72206003)(53546010)(50986999)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1367; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368937FF0CF489ABD97E2C4D7AA0CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2017 14:40:43.8330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1367 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 72d19997-c103-4824-ac63-44eec0608427 X-VPM-MSG-ID: 1013eb75-3d4b-4bcb-9ded-b79a2e9b797d X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 14:40:50 -0000 --_000_CY4PR14MB1368937FF0CF489ABD97E2C4D7AA0CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWF0dA0KVGhpcyBkb2N1bWVudCBpcyBleHRyZW1lbHkgd2VsbCB3cml0dGVuIGFuZCBkZXNj cmliZXMgdGhlIG5lZWRzIG9mIGVudGVycHJpc2VzIHdlbGwsICBJTUhPLiAgICBJIGJlbGll dmUgYW5kIGhhdmUgaGVhcmQsICB0aGVyZSBhcmUgc2ltaWxhciBuZWVkcyBiZXlvbmQgdGhl IGVudGVycHJpc2UgcmVhbG0sICBidXQgc2luY2Ugd2UgYXJlIHRoZSBvbmx5IG9uZXMgZm9y bWFsbHkgZXhwcmVzc2luZyBjb25jZXJucywgc28gYmUgaXQuDQoNClRoZSBkZXRhaWwgb24g dGhlIGltcGxlbWVudGF0aW9uLCAgYXMgd2VsbCBhcyB0aGUgZGV0YWlscyBvbiB3aHkgb3Ro ZXIgYWx0ZXJuYXRpdmUgc29sdXRpb25zIGFyZSBub3QgdmlhYmxlL3N1ZmZpY2llbnQsICBp cyB2ZXJ5IGdvb2QgYW5kIHdpbGwgaGVscCBmb2N1cyBhbnkgcmVsYXRlZCBjb252ZXJzYXRp b25zLg0KDQpJIHZlcnkgbXVjaCBob3BlIHRoaXMgY2FuIGJlIG9uIHRoZSBhZ2VuZGEgYXQg SUVURiA5OS4NClRoYW5rcyBmb3IgeW91ciB2ZXJ5IHByb2R1Y3RpdmUgZWZmb3J0cyBvbiB0 aGlzLg0KTWlrZQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1hdHRoZXcgR3JlZW4NClNlbnQ6IEZyaWRheSwgSnVseSA3LCAyMDE3 IDM6MDMgQU0NClRvOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFtUTFNdIGRyYWZ0LWdyZWVu LXRscy1zdGF0aWMtZGgtaW4tdGxzMTMtMDENCg0KVGhlIG5lZWQgZm9yIGVudGVycHJpc2Ug ZGF0YWNlbnRlcnMgdG8gYWNjZXNzIFRMUyAxLjMgcGxhaW50ZXh0IGZvciBzZWN1cml0eSBh bmQgb3BlcmF0aW9uYWwgcmVxdWlyZW1lbnRzIGhhcyBiZWVuIHVuZGVyIGRpc2N1c3Npb24g c2luY2Ugc2hvcnRseSBiZWZvcmUgdGhlIFNlb3VsIElFVEYgbWVldGluZy4gVGhpcyBkcmFm dCBwcm92aWRlcyBjdXJyZW50IHRoaW5raW5nIGFib3V0IHRoZSB3YXkgdG8gZmFjaWxpdGF0 ZSBwbGFpbiB0ZXh0IGFjY2VzcyBiYXNlZCBvbiB0aGUgdXNlIG9mIHN0YXRpYyAoRUMpREgg a2V5cyBvbiB0aGUgc2VydmVycy4gVGhlc2Uga2V5cyBoYXZlIGEgbGlmZXRpbWU7IHRoZXkg Z2V0IHJlcGxhY2VkIG9uIGEgcmVndWxhciBzY2hlZHVsZS4gQSBrZXkgbWFuYWdlciBpbiB0 aGUgZGF0YWNlbnRlciBnZW5lcmF0ZXMgYW5kIGRpc3RyaWJ1dGVzIHRoZXNlIGtleXMuICBU aGUgQXN5bW1ldHJpYyBLZXkgUGFja2FnZSBbUkZDNTk1OF0gZm9ybWF0IGlzIHVzZWQgdG8g dHJhbnNmZXIgYW5kIGxvYWQgdGhlIGtleXMgd2hlcmV2ZXIgdGhleSBhcmUgYXV0aG9yaXpl ZCBmb3IgdXNlLg0KDQpXZSBoYXZlIGFza2VkIGZvciBhIGZldyBtaW51dGVzIHRvIHRhbGsg YWJvdXQgdGhpcyBkcmFmdCBpbiB0aGUgVExTIFdHIHNlc3Npb24gYXQgdGhlIHVwY29taW5n IFByYWd1ZSBJRVRGLiBQbGVhc2UgdGFrZSBhIGxvb2sgc28gd2UgY2FuIGhhdmUgYSBwcm9k dWN0aXZlIGRpc2N1c3Npb24uICBPZiBjb3Vyc2UsIHdlJ3JlIGVhZ2VyIHRvIHN0YXJ0IHRo YXQgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbCBsaXN0IGluIGFkdmFuY2Ugb2YgdGhlIG1lZXRp bmcuDQoNClRoZSBkcmFmdCBjYW4gYmUgZm91bmQgaGVyZToNCg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWdyZWVuLXRscy1zdGF0aWMtZGgtaW4tdGxzMTMtMDENCg0K VGhhbmtzIGZvciB5b3VyIGF0dGVudGlvbiwNCk1hdHQsIFJhbHBoLCBQYXVsLCBTdGV2ZSwg YW5kIFJ1c3MNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmlj YXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0 aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBk aXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hp Yml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9y IHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBv cmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUgQ3Jv c3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1p Y2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNl bnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLgo= --_000_CY4PR14MB1368937FF0CF489ABD97E2C4D7AA0CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPk1hdHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgZG9jdW1lbnQgaXMgZXh0cmVtZWx5 IHdlbGwgd3JpdHRlbiBhbmQgZGVzY3JpYmVzIHRoZSBuZWVkcyBvZiBlbnRlcnByaXNlcyB3 ZWxsLCZuYnNwOyBJTUhPLiAmbmJzcDsmbmJzcDsmbmJzcDtJIGJlbGlldmUgYW5kIGhhdmUg aGVhcmQsICZuYnNwO3RoZXJlIGFyZSBzaW1pbGFyIG5lZWRzIGJleW9uZCB0aGUgZW50ZXJw cmlzZSByZWFsbSwmbmJzcDsNCiBidXQgc2luY2Ugd2UgYXJlIHRoZSBvbmx5IG9uZXMgZm9y bWFsbHkgZXhwcmVzc2luZyBjb25jZXJucywgc28gYmUgaXQuJm5ic3A7IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5UaGUgZGV0YWlsIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiwmbmJz cDsgYXMgd2VsbCBhcyB0aGUgZGV0YWlscyBvbiB3aHkgb3RoZXIgYWx0ZXJuYXRpdmUgc29s dXRpb25zIGFyZSBub3QgdmlhYmxlL3N1ZmZpY2llbnQsJm5ic3A7IGlzIHZlcnkgZ29vZCBh bmQgd2lsbCBoZWxwIGZvY3VzIGFueSByZWxhdGVkIGNvbnZlcnNhdGlvbnMuJm5ic3A7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB2ZXJ5IG11Y2ggaG9wZSB0aGlzIGNhbiBi ZSBvbiB0aGUgYWdlbmRhIGF0IElFVEYgOTkuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBm b3IgeW91ciB2ZXJ5IHByb2R1Y3RpdmUgZWZmb3J0cyBvbiB0aGlzLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5N aWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5k Q29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWls dG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hdHRoZXcg R3JlZW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDcsIDIwMTcgMzowMyBBTTxi cj4NCjxiPlRvOjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUTFNd IGRyYWZ0LWdyZWVuLXRscy1zdGF0aWMtZGgtaW4tdGxzMTMtMDE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdCI+VGhlIG5lZWQgZm9yIGVudGVycHJpc2UgZGF0YWNlbnRlcnMgdG8gYWNjZXNz IFRMUyAxLjMgcGxhaW50ZXh0IGZvciBzZWN1cml0eSBhbmQgb3BlcmF0aW9uYWwgcmVxdWly ZW1lbnRzIGhhcyBiZWVuIHVuZGVyIGRpc2N1c3Npb24gc2luY2Ugc2hvcnRseSBiZWZvcmUg dGhlIFNlb3VsIElFVEYgbWVldGluZy4gVGhpcyBkcmFmdCBwcm92aWRlcyBjdXJyZW50IHRo aW5raW5nDQogYWJvdXQgdGhlIHdheSB0byBmYWNpbGl0YXRlIHBsYWluIHRleHQgYWNjZXNz IGJhc2VkIG9uIHRoZSB1c2Ugb2Ygc3RhdGljIChFQylESCBrZXlzIG9uIHRoZSBzZXJ2ZXJz LiBUaGVzZSBrZXlzIGhhdmUgYSBsaWZldGltZTsgdGhleSBnZXQgcmVwbGFjZWQgb24gYSBy ZWd1bGFyIHNjaGVkdWxlLiBBIGtleSBtYW5hZ2VyIGluIHRoZSBkYXRhY2VudGVyIGdlbmVy YXRlcyBhbmQgZGlzdHJpYnV0ZXMgdGhlc2Uga2V5cy4mbmJzcDsgVGhlIEFzeW1tZXRyaWMN CiBLZXkgUGFja2FnZSBbUkZDNTk1OF0gZm9ybWF0IGlzIHVzZWQgdG8gdHJhbnNmZXIgYW5k IGxvYWQgdGhlIGtleXMgd2hlcmV2ZXIgdGhleSBhcmUgYXV0aG9yaXplZCBmb3IgdXNlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+V2UgaGF2ZSBhc2tlZCBmb3IgYSBmZXcgbWludXRl cyB0byB0YWxrIGFib3V0IHRoaXMgZHJhZnQgaW4gdGhlIFRMUyBXRyBzZXNzaW9uIGF0IHRo ZSB1cGNvbWluZyBQcmFndWUgSUVURi4gUGxlYXNlIHRha2UgYSBsb29rIHNvIHdlIGNhbiBo YXZlIGEgcHJvZHVjdGl2ZSBkaXNjdXNzaW9uLiZuYnNwOyBPZiBjb3Vyc2UsIHdlJ3JlIGVh Z2VyIHRvIHN0YXJ0IHRoYXQgZGlzY3Vzc2lvbg0KIG9uIHRoZSBtYWlsIGxpc3QgaW4gYWR2 YW5jZSBvZiB0aGUgbWVldGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlRoZSBkcmFmdCBjYW4gYmUg Zm91bmQgaGVyZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWdyZWVuLXRscy1zdGF0aWMtZGgtaW4tdGxzMTMtMDEiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3JlZW4tdGxz LXN0YXRpYy1kaC1pbi10bHMxMy0wMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlRoYW5rcyBmb3IgeW91ciBhdHRl bnRpb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+TWF0dCwgUmFscGgs IFBhdWwsIFN0ZXZlLCBhbmQgUnVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQoKCjxC Uj4KPGh0bWw+CiA8cD5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVu aWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmlj YXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcs IGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJv aGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwg b3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhl IG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGllcy48L3A+CiA8cD5C bHVlIENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hpZ2FuIGFuZCBCbHVlIENhcmUgTmV0d29y ayBvZiBNaWNoaWdhbiBhcmUgbm9ucHJvZml0IGNvcnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRl bnQgbGljZW5zZWVzIG9mIHRoZSBCbHVlIENyb3NzIGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lh dGlvbi48L3A+CiAgPC9odG1sPgoK --_000_CY4PR14MB1368937FF0CF489ABD97E2C4D7AA0CY4PR14MB1368namp_-- From nobody Fri Jul 7 07:44:23 2017 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 A130C13160C for ; Fri, 7 Jul 2017 07:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 po-rGH-ghXnA for ; Fri, 7 Jul 2017 07:44:20 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 52897129B8D for ; Fri, 7 Jul 2017 07:44:20 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id e7so18268115pfk.0 for ; Fri, 07 Jul 2017 07:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qLJ9soRP1KdrtXC/XvCA9f/69kxY/bJH3WSTCvFCE1s=; b=Ici4CMyp8YdatNE0k10nx1HV2R2Y0fFB9zNfsdPThcy4EW4fA6fgxqHSlOqlbmD1KX 1Hiy8gCOvRk/OYm9vVcHcgmmO8iP3iHMV+1ftOOzGcUkJ2kQUoGjAvo00iz3TllJiOXq F8l9AZeSduf4DBZkdIZFRMlEYTR5E00A2ptKKMLozNeK0Qz6QYBzxoWaaSF69eHwHlyq EUw5HCiy9yT15GIk3jVaWcqlKlpBOeUtty84zlnBXvP6Py8XhLyr989wL3VgPGgQUfaS Oyp9y9AB2htCjUGVwquaf5BlXLkhkCIsiGnXIusNgdYPO67bRTtzCxb2Gmv83w7oh+qS ayhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qLJ9soRP1KdrtXC/XvCA9f/69kxY/bJH3WSTCvFCE1s=; b=mlaRZiqLhL/M5u/TGYSiwQG3yCtNU1krnl6gem0kqe0eiIrmIJ4kX9LMLxsjOI3EhR BLRTNoygKaxrwue+qLN9a9fNt5Pg6uZAOUSgB6b/ARl9lxUbK6lzp8kUkHChRvQJfgnF +UVGwnVGaPDbj90YOk7NRPtBib9oIFVt1DZYP+BoYOCgO1xqOA6uIdzxiLR6vJjP8mI2 qIQg/N6b/CmZBqVGVANfKgS32RA9BRXBzsoHFlPr9iX2JfK13JigC7L9Y8r8grcOxFs3 VYXZBG4QtR2gbK7+87CkdVWD5n++FaXNyTe5XK3dkjwMkvldL686bjbvRD6Hy8tfWF29 SZ8Q== X-Gm-Message-State: AIVw110E4+5bjZNryJ0AgiziTAwx5Dv6bsLjKX5qijaBpsulBggwFvDW +CH+HFaGaX+RStf989MFvsJaj3TLWswN X-Received: by 10.84.232.3 with SMTP id h3mr3439587plk.42.1499438659878; Fri, 07 Jul 2017 07:44:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Fri, 7 Jul 2017 07:44:19 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Fri, 7 Jul 2017 07:44:19 -0700 Message-ID: To: "Ackermann, Michael" Cc: Matthew Green , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 14:44:22 -0000 On Fri, Jul 7, 2017 at 7:40 AM, Ackermann, Michael wrote: > Matt > > This document is extremely well written and describes the needs of > enterprises well, IMHO. I believe and have heard, there are similar > needs beyond the enterprise realm, but since we are the only ones formally > expressing concerns, so be it. Why does the IETF need to be involved, given this solution exists? > > > > The detail on the implementation, as well as the details on why other > alternative solutions are not viable/sufficient, is very good and will help > focus any related conversations. > > > > I very much hope this can be on the agenda at IETF 99. > > Thanks for your very productive efforts on this. > > Mike > > > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Matthew Green > Sent: Friday, July 7, 2017 3:03 AM > To: tls@ietf.org > Subject: [TLS] draft-green-tls-static-dh-in-tls13-01 > > > > The need for enterprise datacenters to access TLS 1.3 plaintext for security > and operational requirements has been under discussion since shortly before > the Seoul IETF meeting. This draft provides current thinking about the way > to facilitate plain text access based on the use of static (EC)DH keys on > the servers. These keys have a lifetime; they get replaced on a regular > schedule. A key manager in the datacenter generates and distributes these > keys. The Asymmetric Key Package [RFC5958] format is used to transfer and > load the keys wherever they are authorized for use. > > > > We have asked for a few minutes to talk about this draft in the TLS WG > session at the upcoming Prague IETF. Please take a look so we can have a > productive discussion. Of course, we're eager to start that discussion on > the mail list in advance of the meeting. > > > > The draft can be found here: > > > > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 > > > > Thanks for your attention, > > Matt, Ralph, Paul, Steve, and Russ > > > The information contained in this communication is highly confidential and > is intended solely for the use of the individual(s) to whom this > communication is directed. If you are not the intended recipient, you are > hereby notified that any viewing, copying, disclosure or distribution of > this information is prohibited. Please notify the sender, by electronic mail > or telephone, of any unintended receipt and delete the original message > without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are > nonprofit corporations and independent licensees of the Blue Cross and Blue > Shield Association. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Jul 7 08:06:50 2017 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 68DC1131561 for ; Fri, 7 Jul 2017 08:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 iXKd7KzSvtbS for ; Fri, 7 Jul 2017 08:06:47 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 F16AB127873 for ; Fri, 7 Jul 2017 08:06:46 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id 191so18944158vko.2 for ; Fri, 07 Jul 2017 08:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vpL5kIAkb4g9nvZbqNLX29JpCSBbaVUlkeZxFzV7fJg=; b=PxZaBCBOkn9b3hs73FoWZqKMJuR632/VxEN/JO+t1kbsqRwtmCzAbXiWEiD4Hgu9IU 6saRS/x3tY8D8G2sLkBApKzKcmH/Q4HA2oShaj5kWBgnBOUrjxf0NfwN/KQaP0NDgnJd A7GnB/6jUH/adrnwY68oLCQyVJ0bthC5dvxMLYizLNtWTrSREvjhu+xLxIYZKhj7GVy/ 7DxaCUIHPKzWwFYe0IosszgLjqITSSoN7WY+nvCWp5H5pLYy86dSdtzP5CoPaBiyNLbT 91Ar/s/AszqxV/4BLGYeTpYhB3hT9t9wG5OA5m42jGA1+AHqFxCQl32fSSe2AeGVLTQb cSRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vpL5kIAkb4g9nvZbqNLX29JpCSBbaVUlkeZxFzV7fJg=; b=MAPN68jYb7yC6deHfKTnrNI1voMqfkUhxrwBywu9QOtdHf8sB1DsfWw+7CJhw5B2aC OggubNYPXmJt1onzVAAVeTP7bZdUfRgV68VneJdwmiVYdBESh63fNI5fDxdeLJinoJkm aI7n+nQYKc1vo1Si+1Vjbz8yzeeA+nb7t/MGfsl5UbSnWoFD7j+37vmMzoHbcOENSqk7 lZKFnB7spd2OOcCQ6q6xiYIEn3r7XWleA5wV0AkhsoEexuvGs8tnH1UHfwtwPogShcUs Z3Mp8lk8dn0D1NMO4VbE1fAIs4M1mgKHMOay4pYXQrWBMOypwjfQiH8PtS7XXcd96XUw nk4Q== X-Gm-Message-State: AIVw111QHqRCDFeuN/lDPeKkQbwB3lOEfgv1eIesvfvqiMRBqeq5w+pY B5ITXXbOGzjKpcbN7pcquKxg9u81Ww== X-Received: by 10.31.14.73 with SMTP id 70mr741033vko.99.1499440006067; Fri, 07 Jul 2017 08:06:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Fri, 7 Jul 2017 08:06:45 -0700 (PDT) In-Reply-To: <1F943876-91FC-4529-9B44-9F187EDA48B5@rfc1035.com> References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> <20170705171211.GM5673@mournblade.imrryr.org> <1F943876-91FC-4529-9B44-9F187EDA48B5@rfc1035.com> From: Shumon Huque Date: Fri, 7 Jul 2017 11:06:45 -0400 Message-ID: To: Jim Reid Cc: TLS WG Content-Type: multipart/alternative; boundary="001a114551aaec79530553bb948a" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 15:06:49 -0000 --001a114551aaec79530553bb948a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 7, 2017 at 10:11 AM, Jim Reid wrote: > > > On 5 Jul 2017, at 18:12, Viktor Dukhovni wrote= : > > > > On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote: > > > >> 1) There probably needs to be clearer guidance about the use cases for > >> this extension and the trade-offs between TLS clients doing DNSSEC > >> validation for themselves instead of sending DNS lookups to a validati= ng > >> resolver server. How does an application developer decide which approa= ch > >> would or wouldn't be appropriate? > > > > On today's Internet, DNSSEC is not generally available to end-user > > devices. There are too many "last mile" problems. Thus, while > > direct acquisition of DANE TLSA records works for (e.g.) dedicated > > SMTP servers, any end-user application that wants to do DANE TLS > > needs to use the proposed extension. > > I am too painfully aware of those last mile issues. > > IMO the draft could be clearer about the fact it=E2=80=99s aimed at TLS c= lients > that don=E2=80=99t have access to or a trust relationship with a validati= ng DNS > resolver. It is not aimed solely at those clients. The intro mentions 3 things: (1) TLS clients don't need to do any additional DNS lookups for DANE/DNSSEC - the latency issue, (2) TLS clients don't need to deal with breakage caused by middlebox/last mile issues if they tried to do those lookups, and (3) they don't have secure access to a validating resolver. If an application has any subset of these issues, it might be candidate user of this extension. > > Perhaps you're asking whether once the relevant records are obtained, > > their validation should be via library calls to a suitable API, or > > via a suitable protocol to the local resolver? > > No. I couldn=E2=80=99t care less about API issues or how the RRSIGs get v= alidated. > They=E2=80=99re implentation details for the implementation detail. I am = uneasy at > the prospect of every TLS client application include what will be > essentially its own validating DNS resolver when there could/should be on= e > of these already running on the device itself. > Maybe some day all end user machines will have a validating resolver, but this isn't remotely close to a reality today. > > Except that the records will be warm in the server's cache, since > > many clients will be asking it for the *same* data. The same is > > not as likely to be true at the client. So there is indeed a likely > > latency reduction in farming out the lookups to the server. > > OK. > > It might be helpful to explicitly say =E2=80=9CTLS server=E2=80=9D rather= than =E2=80=9Cserver=E2=80=9D to > avoid confusion or ambiguity. Sometimes this is obvious from the context. > But at other places in the draft =E2=80=9Cserver=E2=80=9D could be read a= s =E2=80=9CDNS server=E2=80=9D. > Ok, we can look through the text and disambiguate where needed. > >> 4) It's not clear if TLS clients can or should cache the DNS data (and > >> the resulting validations?) returned though this extension. > > > > The server will return TTLs, and caching per those TTLs is no less > > appropriate than it is in DNS generally. > > Is there some reason why this isn=E2=80=99t in the draft? We've had this discussion numerous times over the life of this draft, and there was never any consensus for the client caching or not. An implementation could have the client cache the data, and only validate the portion of the chain that it needs to, without any wire protocol change. I'm okay with mentioning that possibility. IMO, the real gain from having the client cache data, is that the server could then potentially send a much smaller DNSSEC chain. But this requires the client to signal what they've cached, and makes the protocol more complex. I would prefer to leave that to a future revision of the spec, after we've gained some operational experience with the current one. --=20 Shumon Huque --001a114551aaec79530553bb948a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 10:11 AM, Jim Reid <jim@rfc1035.com> wrote:=

> On 5 Jul 2017, at 18:12, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>
> On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote:
>
>> 1) There probably needs to be clearer guidance about the use cases= for
>> this extension and the trade-offs between TLS clients doing DNSSEC=
>> validation for themselves instead of sending DNS lookups to a vali= dating
>> resolver server. How does an application developer decide which ap= proach
>> would or wouldn't be appropriate?
>
> On today's Internet, DNSSEC is not generally available to end-user=
> devices.=C2=A0 There are too many "last mile" problems.=C2= =A0 Thus, while
> direct acquisition of DANE TLSA records works for (e.g.) dedicated
> SMTP servers, any end-user application that wants to do DANE TLS
> needs to use the proposed extension.

I am too painfully aware of those last mile issues.

IMO the draft could be clearer about the fact it=E2=80=99s aimed at TLS cli= ents that don=E2=80=99t have access to or a trust relationship with a valid= ating DNS resolver.

It is not aimed solely = at those clients.=C2=A0

The intro mentions 3 thing= s: (1) TLS clients don't need to do any additional DNS lookups for DANE= /DNSSEC - the latency issue, (2) TLS clients don't need to deal with br= eakage caused by middlebox/last mile issues if they tried to do those looku= ps, and (3) they don't have secure access to a validating resolver. If = an application has any subset of these issues, it might be candidate user o= f this extension.
=C2=A0
> Perhaps you're asking whether once the relevant records are obtain= ed,
> their validation should be via library calls to a suitable API, or
> via a suitable protocol to the local resolver?

No. I couldn=E2=80=99t care less about API issues or how the RRSIGs = get validated. They=E2=80=99re implentation details for the implementation = detail. I am uneasy at the prospect of every TLS client application include= what will be essentially its own validating DNS resolver when there could/= should be one of these already running on the device itself.

Maybe some day all end user machines will have a vali= dating resolver, but this isn't remotely close to a reality today.
=C2=A0
> Except that the records will be warm in the server's cache, since<= br> > many clients will be asking it for the *same* data.=C2=A0 The same is<= br> > not as likely to be true at the client.=C2=A0 So there is indeed a lik= ely
> latency reduction in farming out the lookups to the server.

OK.

It might be helpful to explicitly say =E2=80=9CTLS server=E2=80=9D rather t= han =E2=80=9Cserver=E2=80=9D to avoid confusion or ambiguity. Sometimes thi= s is obvious from the context. But at other places in the draft =E2=80=9Cse= rver=E2=80=9D could be read as =E2=80=9CDNS server=E2=80=9D.

Ok, we can look through the text and disambiguate whe= re needed.
=C2=A0
>> 4) It's not clear if TLS clients can or should cache the DNS d= ata (and
>> the resulting validations?) returned though this extension.
>
> The server will return TTLs, and caching per those TTLs is no less
> appropriate than it is in DNS generally.

Is there some reason why this isn=E2=80=99t in the draft?

We've had this discussion numerous times over the= life of this draft, and there was never any consensus for the client cachi= ng or not. An implementation could have the client cache the data, and only= validate the portion of the chain that it needs to, without any wire proto= col change. I'm okay with mentioning that possibility.

IMO, the real gain from having the client cache data, is that the = server could then potentially send a much smaller DNSSEC chain. But this re= quires the client to signal what they've cached, and makes the protocol= more complex. I would prefer to leave that to a future revision of the spe= c, after we've gained some operational experience with the current one.=

--=C2=A0
Shumon Huque

--001a114551aaec79530553bb948a-- From nobody Fri Jul 7 08:14:43 2017 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 A5B2912F28B for ; Fri, 7 Jul 2017 08:14:41 -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=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 cZtjAZmSpe9Y for ; Fri, 7 Jul 2017 08:14:40 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 1BBB5129B4F for ; Fri, 7 Jul 2017 08:14:40 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v67FDkG5028420; Fri, 7 Jul 2017 16:14:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=51gHMsPfmeqS51cyQpDQvO+3qZ1hPbljlT0GrrrdFMc=; b=TZMqcuNaYA0jYus94hX92KpiaSPUYVSjLwN8Wjh31ct/JeqDT4PGfusln7bwCXC6KOP4 rCUdItBr7T37NLR8oiVbUfxYZG8T//dB0z5A+6pQmQefkxzSoNbnfxUJdgmzYrUduHp3 lhYRTbCfTATzEg9zdJpp/eFAwRXHRTuOKsdV1lY/yABY4I9YDrz8GKkngNe5w11TmRyl Rv1/T6LSn8l6fn3ImPSAoUEesgw3w4b7BBQpx1j0tSydDKAn8QsEdWE3nOLUIMSRwSKG SfnQx51wklsfH1/FCLgTFSMZ0EACeGiqYZ9rEv29IyvN6/zkSTmDVXs8CU5KxoqBZFIK fA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bhjxwe2g4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 16:14:12 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v67FB5BH030635; Fri, 7 Jul 2017 11:14:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bhm6e3kcb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 11:14:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Jul 2017 08:14:11 -0700 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.1263.000; Fri, 7 Jul 2017 11:14:10 -0400 From: "Salz, Rich" To: Dave Garrett , "tls@ietf.org" , "Wang Haiguang" Thread-Topic: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) Thread-Index: AQHS9KIjbGMCVggeCEW+lkbi2Qxg8qJDyTgAgAQaXQCAAJpUMA== Date: Fri, 7 Jul 2017 15:14:10 +0000 Message-ID: <5af19fe7273748579cb2537313667aba@usma1ex-dag1mb1.msg.corp.akamai.com> References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> <201707062201.08455.davemgarrett@gmail.com> In-Reply-To: <201707062201.08455.davemgarrett@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.32.247] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707070252 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070251 Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 15:14:41 -0000 > Just as a clarification, all new RFCs should ideally meet all of the foll= owing > criteria: > * AEAD only > * PFS only > * TLS 1.2 and 1.3 support > * no TLS 1.0 or 1.1 support (let alone SSL) > * no use of broken hashes (MD5, SHA1, etc.) That's a good idea. Want to throw together a quick draft for curdle or AD-sponsored SAAG? From nobody Fri Jul 7 08:35:03 2017 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 5641712EA53 for ; Fri, 7 Jul 2017 08:35:01 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 gFiU2bXqclF2 for ; Fri, 7 Jul 2017 08:35:00 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17EF012762F for ; Fri, 7 Jul 2017 08:35:00 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 3D2CF2421519; Fri, 7 Jul 2017 15:34:58 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: Date: Fri, 7 Jul 2017 16:34:57 +0100 Cc: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> <20170705171211.GM5673@mournblade.imrryr.org> <1F943876-91FC-4529-9B44-9F187EDA48B5@rfc1035.com> To: Shumon Huque X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 15:35:01 -0000 > On 7 Jul 2017, at 16:06, Shumon Huque wrote: >=20 > IMO, the real gain from having the client cache data, is that the = server could then potentially send a much smaller DNSSEC chain. But this = requires the client to signal what they've cached, and makes the = protocol more complex. I would prefer to leave that to a future revision = of the spec, after we've gained some operational experience with the = current one. Shumon, I think the biggest gain would be fewer RRSIGs for the client to = validate. Having the server send a smaller DNSSEC chain (and perhaps add = something to the protocol for a client to signal that) probably won=E2=80=99= t have the right cost/benefit optics. YMMV. It would be a Good Thing if = a TLS client didn=E2=80=99t need to revalidate everything in the chain = for tlsa.foo.com after closing and reopening a TLS session to that = end-point or it could start at the previously validated delegation for = .com when the TLS server returned the full chain for tlsa.bar.com. As you hint at, it would be good to get more data and operational = expertise.=20 From nobody Fri Jul 7 08:50:09 2017 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 AFB1813154C for ; Fri, 7 Jul 2017 08:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KN7xlTmzcKa5 for ; Fri, 7 Jul 2017 08:50:05 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 82A61127599 for ; Fri, 7 Jul 2017 08:50:05 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id z22so22571957uah.1 for ; Fri, 07 Jul 2017 08:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nNhK5c7Eum9oV6bTcls7F3/v11uKLDlc6+d9+zUOFW0=; b=LMZ1QSMbODUhQjMQCF/r6zVJ8Pwmy9WUFw7ZHh0nfn3whmPE77+EzlY05Cz4MleL7K /PUQjrUhVUg0cp6VfNyGCTDSNQN+32M1fP5PH1oW70vG5rqKeLZBwNeDuPeBjldjxZDo axAqz/mSQ3yesJLQWpIwTLiV5PO0Zu4iM75nHhzN0jsdzx3g3RhDmwyUly/wljeq80rN 15kdHEKIosRuvD7S//cUoGJe/CspVJyh4BvyWl9THXFxjDBZsIubXenXQqm0XTbbhyw1 P0Ax5Uuk09ynjThkyGYjULZ6FfAXVuChY72V/izw5M9lwfwzBlwpsOWvCMR7RVhx6vaA kCNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nNhK5c7Eum9oV6bTcls7F3/v11uKLDlc6+d9+zUOFW0=; b=J0ZSkpIz/oUVhgtDeWTJu+cJXE8/vgwMUxTfl2iLQx4Za6eiixmcwS5uQ+2BfQoVr0 Kc+M/g9cf3d9Fb9IogQ1CTo8vHw8W5ecNyMxrXFrjzYWKq75deEllZxT9uPgSkzKVwKM Vu8gTs7I/99pW2YGBXEh0mXkoWguI3xGps/CdLtA9zgSfkugOXumFZxnTTZ0IcpUrDwL Flh+eewE3ObxoBnbBBuAFg2jMFa6f/qfDUH9iIW6DKlWTP519bEFj7YXGvpS3msXdHSn 2oWmF+T31AI0OkgxQULP4HozUhWabvIUrvVNKd4bQZdd4Xu+G82MpBpokbj/xa03MzoD kQgA== X-Gm-Message-State: AIVw111+vxxb1G8AyNVKeT9rrxMlE75UF/rGuXORVI/vWdVtcT01fiAc VSKo/pER1/DDT+FaKqlfczGWGdFmoQ== X-Received: by 10.176.93.2 with SMTP id u2mr1095944uaf.109.1499442604686; Fri, 07 Jul 2017 08:50:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Fri, 7 Jul 2017 08:50:03 -0700 (PDT) In-Reply-To: References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> <20170705171211.GM5673@mournblade.imrryr.org> <1F943876-91FC-4529-9B44-9F187EDA48B5@rfc1035.com> From: Shumon Huque Date: Fri, 7 Jul 2017 11:50:03 -0400 Message-ID: To: Jim Reid Cc: TLS WG Content-Type: multipart/alternative; boundary="f40304362188d042530553bc2f11" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 15:50:08 -0000 --f40304362188d042530553bc2f11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 7, 2017 at 11:34 AM, Jim Reid wrote: > > > On 7 Jul 2017, at 16:06, Shumon Huque wrote: > > > > IMO, the real gain from having the client cache data, is that the serve= r > could then potentially send a much smaller DNSSEC chain. But this require= s > the client to signal what they've cached, and makes the protocol more > complex. I would prefer to leave that to a future revision of the spec, > after we've gained some operational experience with the current one. > > Shumon, I think the biggest gain would be fewer RRSIGs for the client to > validate. Having the server send a smaller DNSSEC chain (and perhaps add > something to the protocol for a client to signal that) probably won=E2=80= =99t have > the right cost/benefit optics. YMMV. It would be a Good Thing if a TLS > client didn=E2=80=99t need to revalidate everything in the chain for tlsa= .foo.com > after closing and reopening a TLS session to that end-point or it could > start at the previously validated delegation for .com when the TLS server > returned the full chain for tlsa.bar.com. > > As you hint at, it would be good to get more data and operational > expertise. > Okay, absent any strenuous objections, I propose that we mention that the client may cache data from the chain. For the case of a TLS client re-connecting to the same end point, most likely TLS session resumption would be used (thus dnssec_chain re-validation wouldn't be needed) so this optimization doesn't gain anything. But yes, it would help save the client some signature validation work in the case of tlsa.foo.com to tlsa.bar.com. --=20 Shumon Huque --f40304362188d042530553bc2f11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 11:34 AM, Jim Reid <jim@rfc1035.com> wrote:=

> On 7 Jul 2017, at 16:06, Shumon Huque <shuque@gmail.com> wrote:
>
> IMO, the real gain from having the client cache data, is that the serv= er could then potentially send a much smaller DNSSEC chain. But this requir= es the client to signal what they've cached, and makes the protocol mor= e complex. I would prefer to leave that to a future revision of the spec, a= fter we've gained some operational experience with the current one.

Shumon, I think the biggest gain would be fewer RRSIGs for the clien= t to validate. Having the server send a smaller DNSSEC chain (and perhaps a= dd something to the protocol for a client to signal that) probably won=E2= =80=99t have the right cost/benefit optics. YMMV. It would be a Good Thing = if a TLS client didn=E2=80=99t need to revalidate everything in the chain f= or tls= a.foo.com after closing and reopening a TLS session to that end-point o= r it could start at the previously validated delegation for .com when the T= LS server returned the full chain for tlsa.bar.com.

As you hint at, it would be good to get more data and operational expertise= .

Okay, absent any strenuous objections= , I propose that we mention that the client may cache data from the chain. = For the case of a TLS client re-connecting to the same end point, most like= ly TLS session resumption would be used (thus dnssec_chain re-validation wo= uldn't be needed) so this optimization doesn't gain anything. But y= es, it would help save the client some signature validation work in the cas= e of tlsa.foo.com to tlsa.bar.com.

--=C2=A0
Shumon Huque

--f40304362188d042530553bc2f11-- From nobody Fri Jul 7 08:59:38 2017 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 CF98D131609 for ; Fri, 7 Jul 2017 08:59:34 -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, HTML_MESSAGE=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=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 2Ma89PIpBTjr for ; Fri, 7 Jul 2017 08:59:29 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 1B9A912EC0D for ; Fri, 7 Jul 2017 08:59:29 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v67Fv4bt002691 for ; Fri, 7 Jul 2017 16:59:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=HZKRqfyYEuFUSAQ4x3GcE2SP6u44b20zwQ29GzeGs/U=; b=TZM8mP+popF9COQIqtF2V+GeU6n6NBfSuVYEN3G8IyKtAyq8RtLaMESnqODsTI/CX4iV tFXcAowbgy6uHHPrHl7eru53bzj1bK6+grN21XUOH1j5ctNUHKkUD5dVw0Vc4eiY6VJZ 9wIPNgnwren67/ARF8UGQeRm0yRS8L7hxfPQGA6W5+zLcAJWweEZZwqZPWLcdVuY3aV8 IHyRJQBBRqLcCKotBRez7938riawJq0N4QSoH1EqMBDKjOHa1KUM+G+fbxbUpPe/MgQp yxBgmlNGCZH+8o/azD0CXTo+aRJnRGAYPqBoQ8823xidURhzCMAz+qvav1TJYJ1l9uHk 6w== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bhjxwe80v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 07 Jul 2017 16:59:26 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v67Fu0RE018971 for ; Fri, 7 Jul 2017 11:59:26 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72ug697-1 for ; Fri, 07 Jul 2017 11:59:26 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id DDC501FC7B for ; Fri, 7 Jul 2017 15:59:25 +0000 (GMT) To: "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: Date: Fri, 7 Jul 2017 10:59:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0CCB580A1061DDD801708ED4" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707070265 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070266 Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 15:59:35 -0000 This is a multi-part message in MIME format. --------------0CCB580A1061DDD801708ED4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/28/2017 04:15 PM, Joseph Salowey wrote: > This is the working group last call > for draft-ietf-tls-dnssec-chain-extension-04. Please send you > comments to the list by July 12, 2017. Just a couple minor things I don't remember being mentioned already that I noticed in a quick read: When section 3.4 mentions that "this document describes the data structure in sufficient detail that implementors if they desire can write their own code to do this", it seems that this really on makes sense when the "this" is for the encoding side, not the decoding side. That is, in that we expect future DNS clients to continue to process responses in the current format, but future DNS servers might generate responses that cannot be properly decoded just following this document. (E.g., what would happen if NSEC5 became popular?) In section 8: Mandating this extension for Raw Public Key authentication (where there are no X.509 certificates) could employ configuration mechanisms external to the TLS protocol this sentence structure is a little confusing; it might be better to say something like "If needed, configuration mechanism external to the TLS protocol could be used to mandate the use of this extension for Raw Public Key authentication". -Ben --------------0CCB580A1061DDD801708ED4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/28/2017 04:15 PM, Joseph Salowey wrote:
This is the working group last call for draft-ietf-tls-dnssec-chain-extension-04.  Please send you comments to the list by July 12, 2017.  

Just a couple minor things I don't remember being mentioned already that I noticed in a quick read:

When section 3.4 mentions that "this document describes the data structure in sufficient detail that implementors if they desire can write their own code to do this", it seems that this really on makes sense when the "this" is for the encoding side, not the decoding side.  That is, in that we expect future DNS clients to continue to process responses in the current format, but future DNS servers might generate responses that cannot be properly decoded just following this document.  (E.g., what would happen if NSEC5 became popular?)

In section 8:

   Mandating this extension for Raw Public Key
   authentication (where there are no X.509 certificates) could employ
   configuration mechanisms external to the TLS protocol

this sentence structure is a little confusing; it might be better to say something like "If needed, configuration mechanism external to the TLS protocol could be used to mandate the use of this extension for Raw Public Key authentication".

-Ben
--------------0CCB580A1061DDD801708ED4-- From nobody Fri Jul 7 09:15:35 2017 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 C095612EBF4 for ; Fri, 7 Jul 2017 09:15: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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 BRaioMrxoi1V for ; Fri, 7 Jul 2017 09:15:32 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 569C91201FA for ; Fri, 7 Jul 2017 09:15:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 280312125D; Fri, 7 Jul 2017 19:15:30 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id c9a4hEv2aDSL; Fri, 7 Jul 2017 19:15:29 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id BC94FC4; Fri, 7 Jul 2017 19:15:25 +0300 (EEST) Date: Fri, 7 Jul 2017 19:15:25 +0300 From: Ilari Liusvaara To: "Salz, Rich" Cc: Dave Garrett , "tls@ietf.org" , Wang Haiguang Message-ID: <20170707161525.ayv4z4olmo4r3h73@LK-Perkele-VII> References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> <201707062201.08455.davemgarrett@gmail.com> <5af19fe7273748579cb2537313667aba@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5af19fe7273748579cb2537313667aba@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 16:15:35 -0000 On Fri, Jul 07, 2017 at 03:14:10PM +0000, Salz, Rich wrote: > > Just as a clarification, all new RFCs should ideally meet all of the following > > criteria: > > * AEAD only > > * PFS only > > * TLS 1.2 and 1.3 support > > * no TLS 1.0 or 1.1 support (let alone SSL) > > * no use of broken hashes (MD5, SHA1, etc.) > > That's a good idea. > > Want to throw together a quick draft for curdle or AD-sponsored SAAG? Well, my own view is (with explanations): - AEAD only. TLS streammode has all ciphers deprecated, and furthermore contains a design mistake. TLS blockmode padding is outside MAC, which makes implementing such modes securely very hard. This leaves just AEAD ciphers. - No use of broken, dubious, <128-bit keylength or <128-bit blocklength ciphers. These probably won't last long until becoming attack vectors (RC4 anyone, that was dubious back in late 90s, when TLS 1.0 was done). - PFS or pure-PSK only. Small things can't do PFS unforunately. - No use of l < 2^241 for key exchange. Such key exchanges provode <120 bits of security (or thereabouts). I used 2^241, since this is between the values used by methods claiming to be "128-bit secure" and "112-bit secure" (or even weaker). - Security of any key exchange method against classical attacks has to be well established. No key exchanges that are dubious against non-quantum attacks. Impiles hybrid PQC exchanges,if relevant. I have seen a dubious key exchange method just catastrophically fail. - Support TLS 1.3 (unless it is a security fix for earlier TLS, in that case it has to co-exist with TLS 1.3). The current version of TLS in the relevant timeframe will be 1.3. - No fallbacks for TLS 1.0 or 1.1. Don't waste effort on TLS 1.0 or 1.1. Use any new features in TLS 1.2 (e.g., not having to define key exchange methods for signature methods) if those make things simpler. - No use of broken, dubious, unusual (including usage mode) or <128-bit secure hashes. These probably won't last long, or will be headache to find implementations for (e.g., try finding implementation of Skein that supports any more exotic use of datatyping than the native MAC mode, the reference implementation does not). -Ilari From nobody Fri Jul 7 09:27:23 2017 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 7B45E131613 for ; Fri, 7 Jul 2017 09:27:21 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 CwqaXAYmRYYy for ; Fri, 7 Jul 2017 09:27:20 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 E8B2712EC0D for ; Fri, 7 Jul 2017 09:27:19 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v67GPwi0024560; Fri, 7 Jul 2017 17:27:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=4CyZvixhD3LCN0vpk5td6ZepE0UFuhid4VkuLSR+Aqs=; b=RiXlmn/x9ZxigkO7a+SKJPJo8EsRmEOhBleOIGnwowLLg56nzyvAQlKK5pxIhU19eIQ0 AOjcbn3c/ja4HyakVgkG+5x8QFE3mQBhau9bhQiCFoaRzWQoZi4aY0ChJBEpU8XKJodX NkGEZTKSFBUN2lkCU0BXBnaTEqgQncEzxnbftE5qhzawjoAoKmj/DaBEHsgtAqvEZzb3 EogtfmrO7gQTYbRCMDHhY8Oswcq6d+7jAPmXOyDBFE3CdMEdqTUEqhzSbnAUAMl4QjfO x8ZseXS4sF06i1PDQWjjsILdN5IfX8KGTMQ0bBw8nEUE566S5e3hide8+WZkavigRSe1 jQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bhry24gja-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 17:27:07 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v67GQ3s5015749; Fri, 7 Jul 2017 12:27:06 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bhm6e3skj-1; Fri, 07 Jul 2017 12:27:06 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id D6AD61FC7E; Fri, 7 Jul 2017 16:27:05 +0000 (GMT) To: Andreas Walz , tls@ietf.org References: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de> <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de> From: Benjamin Kaduk Message-ID: Date: Fri, 7 Jul 2017 11:27:05 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de> Content-Type: multipart/alternative; boundary="------------C8FCC341FF1354F7F68733B5" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707070274 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070273 Archived-At: Subject: Re: [TLS] Truncated HMAC: what to do with the MAC key? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 16:27:21 -0000 This is a multi-part message in MIME format. --------------C8FCC341FF1354F7F68733B5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/07/2017 09:25 AM, Andreas Walz wrote: > Dear all, > > today I encountered something that confuses me: different TLS > implementations do not seem to agree on how to implement truncated > HMAC. All implementations I tested truncate the HMAC output correctly, > but they seem to use different MAC keys. When truncated HMAC is > negotiated: > > -> MatrixSSL does not change the length of the MAC key but zeros all > its bytes beyond index 10, > -> mbedTLS truncates the MAC key to length 10, > -> WolfSSL does not touch the MAC key at all. > > From RFC 6066 I would infer that the MAC key should not be affected by > the negotiation of the truncated HMAC extension (as WolfSSL is > implementing it). Is that correct? I agree with your reading of RFC 6066 (and RFC 2104). -Ben --------------C8FCC341FF1354F7F68733B5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/07/2017 09:25 AM, Andreas Walz wrote:
Dear all,

today I encountered something that confuses me: different TLS implementations do not seem to agree on how to implement truncated HMAC. All implementations I tested truncate the HMAC output correctly, but they seem to use different MAC keys. When truncated HMAC is negotiated:

-> MatrixSSL does not change the length of the MAC key but zeros all its bytes beyond index 10,
-> mbedTLS truncates the MAC key to length 10,
-> WolfSSL does not touch the MAC key at all.

From RFC 6066 I would infer that the MAC key should not be affected by the negotiation of the truncated HMAC extension (as WolfSSL is implementing it). Is that correct?

I agree with your reading of RFC 6066 (and RFC 2104).

-Ben
--------------C8FCC341FF1354F7F68733B5-- From nobody Fri Jul 7 09:35:37 2017 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 1CBFA1316DE for ; Fri, 7 Jul 2017 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 HnX8OZwZCyi3 for ; Fri, 7 Jul 2017 09:35:23 -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 63FEF1316D9 for ; Fri, 7 Jul 2017 09:35:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B971A30053F for ; Fri, 7 Jul 2017 12:35:22 -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 0uNA7TeT19rf for ; Fri, 7 Jul 2017 12:35:19 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2642E30023A; Fri, 7 Jul 2017 12:35:19 -0400 (EDT) From: Russ Housley Message-Id: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B50A222-3C0A-41E0-AE25-0D18691EDAC0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Jul 2017 12:35:18 -0400 In-Reply-To: Cc: Matthew Green , IETF TLS To: Richard Barnes References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 16:35:26 -0000 --Apple-Mail=_8B50A222-3C0A-41E0-AE25-0D18691EDAC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Richard: > Without taking a position on whether this group should take on this = work, a couple of questions about alternative approaches (sorry if these = have been answered before): >=20 > 1. It seems like the requirement here is that the DH private key be = *predictable* by the monitoring box based on some static configuration. = That is, it seems like you could have keys that are predictable to the = monitoring device, but still vary over time, something like setting the = private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom). = Without having done much analysis, this seems more conservative than = making things entirely static. Is there a reason to prefer the purely = static approach besides simplicity? Please see Section 6 of the draft. The non-ephemeral DH keys MUST have = a validity period. The keys are expected to change over time. > 2. You could avoid changing how the DH works altogether by simply = exporting the DH private key, encrypted with a key shared with the = monitoring device, in a server extension. (Not in EncryptedExtensions, = obviously.) This would also have the benefit of explicitly signaling = when such monitoring is in use. The only real challenge here is that = the client would have to offer the extension in order for the server to = be able to send it, which I expect things like browsers would be = unlikely to do. However, given that the target of this draft seems to = be intra-data-center TLS, perhaps this is a workable requirement? In most common deployment case, the load balancer at the edge of the = enterprise datacenter will terminate the TLS session and start a new = one. The TLS session that protects the traffic on the public Internet = works exactly as described in draft-ietf-tls-tls13. The non-ephemeral = DH keys are associated only with sessions that are inside the enterprise = datacenter. So, you are right, no browser will be at either end of any = of these TLS sessions. There is no change to the way that the protocol = makes use of the DH key. The drft-green, the server need to look in a = table to choose a valid non-ephemeral DH key. In your proposal, the = server need to wrap the ephemeral DH private key in a key-enceyption = key. Both solutions require the distribution of some key (either the = non-ephemenral DH key or the key-encryption key) to the parties that are = authorized to see the traffic. Stephen: > I don't believe the WG should adopt this as it goes > against rfc2804 and encourages bad behaviour. We > ought not be helping to normalise broken crypto. I'm > happy to repeat that at the mic in Prague but would > be even happier if this draft were not discussed > there - these attempts to weaken security have IMO > already taken up too much time and too many cycles. Repeating from above, the non-ephemeral DH keys are associated only with = sessions that are inside the enterprise datacenter. In some industries, = there are regulatory requirements that cannot be met without access to = the plaintext. Without some authorized access mechanism, the enterprise = will be forced to use plaintext within the datacenter. That seems like = a worse alternative to me. Russ > On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green > wrote: > The need for enterprise datacenters to access TLS 1.3 plaintext for = security and operational requirements has been under discussion since = shortly before the Seoul IETF meeting. This draft provides current = thinking about the way to facilitate plain text access based on the use = of static (EC)DH keys on the servers. These keys have a lifetime; they = get replaced on a regular schedule. A key manager in the datacenter = generates and distributes these keys. The Asymmetric Key Package = [RFC5958] format is used to transfer and load the keys wherever they are = authorized for use. >=20 > We have asked for a few minutes to talk about this draft in the TLS WG = session at the upcoming Prague IETF. Please take a look so we can have a = productive discussion. Of course, we're eager to start that discussion = on the mail list in advance of the meeting. >=20 > The draft can be found here: >=20 > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 = >=20 > Thanks for your attention, > Matt, Ralph, Paul, Steve, and Russ --Apple-Mail=_8B50A222-3C0A-41E0-AE25-0D18691EDAC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Richard:

Without taking a position on = whether this group should take on this work, a couple of questions about = alternative approaches (sorry if these have been answered = before):

1. It seems like the = requirement here is that the DH private key be *predictable* by the = monitoring box based on some static configuration.  That is, it = seems like you could have keys that are predictable to the monitoring = device, but still vary over time, something like setting the private key = from a KDF(SecretSharedWithMonitoringDevice, ServerRandom). Without = having done much analysis, this seems more conservative than making = things entirely static. Is there a reason to prefer the purely static = approach besides simplicity?

Please see Section 6 of the draft.  The = non-ephemeral DH keys MUST have a validity period.  The keys are = expected to change over time.

2. You could avoid changing how the DH works altogether by = simply exporting the DH private key, encrypted with a key shared with = the monitoring device, in a server extension.  (Not in = EncryptedExtensions, obviously.)  This would also have the benefit = of explicitly signaling when such monitoring is in use.  The only = real challenge here is that the client would have to offer the extension = in order for the server to be able to send it, which I expect things = like browsers would be unlikely to do.  However, given that the = target of this draft seems to be intra-data-center TLS, perhaps this is = a workable requirement?

In most common deployment case, the load balancer at = the edge of the enterprise datacenter will terminate the TLS session and = start a new one.  The TLS session that protects the traffic on the = public Internet works exactly as described in draft-ietf-tls-tls13. =  The non-ephemeral DH keys are associated only with sessions that = are inside the enterprise datacenter.  So, you are right, no = browser will be at either end of any of these TLS sessions.  There = is no change to the way that the protocol makes use of the DH key. =  The drft-green, the server need to look in a table to choose a = valid non-ephemeral DH key.  In your proposal, the server need to = wrap the ephemeral DH private key in a key-enceyption key.  Both = solutions require the distribution of some key (either the = non-ephemenral DH key or the key-encryption key) to the parties that are = authorized to see the traffic.


Stephen:

I don't = believe the WG should adopt this as it goes
against = rfc2804 and encourages bad behaviour. We
ought not be = helping to normalise broken crypto. I'm
happy to repeat = that at the mic in Prague but would
be even happier if = this draft were not discussed
there - these attempts to = weaken security have IMO
already taken up too much time = and too many cycles.

Repeating from above, the non-ephemeral DH keys = are associated only with sessions that are inside the enterprise = datacenter.  In some industries, there are regulatory requirements = that cannot be met without access to the plaintext.  Without some = authorized access mechanism, the enterprise will be forced to use = plaintext within the datacenter.  That seems like a worse = alternative to me.

Russ


On = Fri, Jul 7, 2017 at 3:02 AM, Matthew Green <matthewdgreen@gmail.com> = wrote:
The need for = enterprise datacenters to access TLS 1.3 plaintext for security and = operational requirements has been under discussion since shortly before = the Seoul IETF meeting. This draft provides current thinking about the = way to facilitate plain text access based on the use of static (EC)DH = keys on the servers. These keys have a lifetime; they get replaced on a = regular schedule. A key manager in the datacenter generates and = distributes these keys.  The Asymmetric Key Package [RFC5958] = format is used to transfer and load the keys wherever they are = authorized for use.

We have asked for = a few minutes to talk about this draft in the TLS WG session at the = upcoming Prague IETF. Please take a look so we can have a productive = discussion.  Of course, we're eager to start that discussion on the = mail list in advance of the meeting.

The draft can be found = here:

https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01

Thanks for your attention,
Matt, Ralph, Paul, Steve, and = Russ

= --Apple-Mail=_8B50A222-3C0A-41E0-AE25-0D18691EDAC0-- From nobody Fri Jul 7 09:40:31 2017 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 D1D2B13170C for ; Fri, 7 Jul 2017 09:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 kaxQuxD48Unh for ; Fri, 7 Jul 2017 09:40:27 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 5C0DE1316FB for ; Fri, 7 Jul 2017 09:40:26 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v67Gc0UA028825; Fri, 7 Jul 2017 17:40:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=P7NbvI6LqmVKtOn5rFI+LLv+xSPrtw/7Qe1bu+MHG7k=; b=cYAUPp5MLBjT3za+nxRxuQJFlWWeBR5+yv/ufWLD75EJcc6J3S0Y6dUa5kpZzLfTR8V6 ZppL7UbnnmAq41z34/+9pm3+bdtAlqwBYEZJOsBtRR+u45Exc0RLMWUP2y+K/FeZIqG8 S4bn8sFcJ9BbtqFCUccwuPnduJR/Ep4Ogv59TN34c8nkfaFL2vmUv0/EJP56QCHQVw6R BbC9a9M3AqPC1b3jlbD+8RflgSTT6xqdQQ2Ie0XUYCucF14fWumtt9Yz4G05K79HT1ov Q5yho56wMSakCqwoU7ja65bBT+9+lKEHBUlpk/KZqTYeahP8snmg+0GlWzX6bUmJ1tZN 4w== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2bj21kahj9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 17:40:24 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v67Gaj8q013831; Fri, 7 Jul 2017 12:40:23 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2be72vmtp6-1; Fri, 07 Jul 2017 12:40:23 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 6BDD720064; Fri, 7 Jul 2017 10:40:23 -0600 (MDT) To: Eric Rescorla , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <2987d9d7-b08a-d3ee-3607-d7e6d0bbbda6@akamai.com> Date: Fri, 7 Jul 2017 11:40:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0462D8056A694CDFD51EEC41" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707070276 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070277 Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 16:40:30 -0000 This is a multi-part message in MIME format. --------------0462D8056A694CDFD51EEC41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/03/2017 07:01 PM, Eric Rescorla wrote: > Currently the extension table says that server_certificate_type goes > in the Certificate message, whereas client_certificate_type does > not. My reasoning for the latter is that the extensions are attached > to individual certificate elements, so it was non-sensical to have a > situation where you might have cert A be X.509 and cert B be PGP. I > think we should just change server_certificate_type to go in EE, and > then maybe in future if people want something cleverer they can add it > then. I didn't want to do this without WG discussion, but I think we > should and if people don't object I'll do it in a -22. > Seems worth doing. [snip] > > [0] Note that this is a bit tricky when you are also streaming > Early Data. I'm not sure what this footnote was supposed to refer to. -Ben --------------0462D8056A694CDFD51EEC41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/03/2017 07:01 PM, Eric Rescorla wrote:
Currently the extension table says that server_certificate_type goes
in the Certificate message, whereas client_certificate_type does
not. My reasoning for the latter is that the extensions are attached
to individual certificate elements, so it was non-sensical to have a
situation where you might have cert A be X.509 and cert B be PGP.  I
think we should just change server_certificate_type to go in EE, and
then maybe in future if people want something cleverer they can add it
then. I didn't want to do this without WG discussion, but I think we
should and if people don't object I'll do it in a -22.


Seems worth doing.


[snip]


[0] Note that this is a bit tricky when you are also streaming
Early Data.

I'm not sure what this footnote was supposed to refer to.

-Ben
--------------0462D8056A694CDFD51EEC41-- From nobody Fri Jul 7 09:48:53 2017 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 59A8313177E for ; Fri, 7 Jul 2017 09:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 YSSkjIbqYhBy for ; Fri, 7 Jul 2017 09:48: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 00A8C131781 for ; Fri, 7 Jul 2017 09:48:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id EFA022045E; Fri, 7 Jul 2017 19:48:43 +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 PjGQLfnxuHdl; Fri, 7 Jul 2017 19:48:43 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id AD85421C; Fri, 7 Jul 2017 19:48:41 +0300 (EEST) Date: Fri, 7 Jul 2017 19:48:41 +0300 From: Ilari Liusvaara To: Raja ashok Cc: "" Message-ID: <20170707164841.nihgzf3tdr7vut5a@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Suggestions in draft-mavrogiannopoulos-tls-cid X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 16:48:51 -0000 On Fri, Jul 07, 2017 at 01:44:41PM +0000, Raja ashok wrote: > Hi Nikos, Hannes & Thomas, > > This ConnectionID concept is really a useful feature for a client > node which faces a change in transport and network layer. I am > having few suggestions in the proposed draft, which are listed below. > > 1) In section 3 of this draft, explains about the modification in > "DTLSCiphertext" structure. I feel instead of modifying existing > DTLS and TLS record header, we can directly introduce a new record > type (ContentType) for app data (application_data_with_cid(25)). > For this new record type, we can propose a modified record header > for both TLS and DTLS. IMO, it is property of connection if CID is used, and what CID to use (including any possible backup CID or two). > 2) More over section 3 says modification only in "DTLSCiphertext", > not for "TLSCiphertext". I hope this CID mechanism should be used > for both TLS and DTLS. Because this transport layer change problem > is there for TLS based applications (HTTPS) also in Smartphone( > when it switches from Wifi to LTE). But this TLS application problem > is solved by MPTCP, but I dont think all webservers are supporting > this MPTCP. So I feel CID is required for both TLS and DTLS. Deploying CID with TLS over TCP is bit nontrivial. The following factors need to be considered: - TLS assumes only single stream of application data. - DoS by invalid address change. - Datastream integerity in dirty switch. The last one is pretty nasty. > 3) As part of defining new record type, we can remove some unused > fields like version, epoch. After removing epoch we can mandate that > both entity should not start renegotiation. Sample design for new > record header with CID is mentioned below DTLS 1.3 uses epoch field for rekeying. It is however uncler if it needs 2 octets for epoch, or if just sending the lowest octet of the epoch would be OK. > 5) Section 3.1 and 3.2 talks about the new extensions for > negotiating this feature support. But I feel no need of new >extensions to negotiate this, we can make client to add new SCSV > cipher in its cipher list. Ugh, no SCSVs. This isn't some critical security fix that has to work even with bad TLS stacks that don't support extensions. -Ilari From nobody Fri Jul 7 10:13:13 2017 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 0A3D6131743 for ; Fri, 7 Jul 2017 10:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 0YSHfsuuYRtY for ; Fri, 7 Jul 2017 10:13:09 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 64ABE13173B for ; Fri, 7 Jul 2017 10:13:09 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id r103so55518249wrb.0 for ; Fri, 07 Jul 2017 10:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Aog63/Wq7zd1NuG4SyfzeVDpbzGcsO9/CIkEPcVK26E=; b=qQz7K4E7mwWu6ZrDZWVctglpHHvBeSKBD3uic3SPKpF88FvQS8lFZopVHTfYZT8GsE cZgPGJWqCOHRZKpC8zBFYbQKFhqnHazmiAsg80LdHAZyq5mC9BMP/sfRHldVcR11ImBa MQcQAUQCPBSjBOnbDjHuWHw9tQS4gfebLMTuAc/WclSHdJCjspbrJd4buA7Bu6VuTLxa 2VcO3WnPkhRZhdD7CnlJpNLzmAxYQ78h09BAxfTTUTdWFntDAdHQxUqFZdGE51t8vVNX CMKF8Bio6H1juq65SWlP8rp5FBeiR09mkiQPNz4wN/X7mwN+IlJF9yjUcJHx+BNje6Gm CfKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Aog63/Wq7zd1NuG4SyfzeVDpbzGcsO9/CIkEPcVK26E=; b=kU/qbg4anuw17TJuE3wS9n0EHvwnqCMah9FXF3Eh2hPmeCeFbd81fF5q8zJSrDTT50 zyxPBDj8LmLqwGYFUJeVfcDTxoHQKKLXjKITE8jNhUEmINuwFF7q/zSkdMlFKwKolasY svqlIaqSi7I4cSvt8K4JCXn40StQQ+sDnly5DGev2c2tGpwLKAMP+SJfLfoou0l43r+K RwiQSC8VC3VFevi8wqz79bTImzMvaCJsQPtXZhMX5fEzmzxdfN4JexgO8fL1Y9iDY6KE GkSB7Gyhf+tjddeVsWhN5AN3NeE2gO+GQdtc7tav+PG4M/Ika+Mr1JzQBriBloAszs2Z uBCA== X-Gm-Message-State: AIVw113fcgMOcGpi7GspGWuqSffQm3Op6DnmLY5x9sxB2u2PSHLZmNPV y1H7ex1grV/Fhwk7Sjm3KsdY7Rjzrv8S X-Received: by 10.223.153.114 with SMTP id x105mr1454916wrb.18.1499447587731; Fri, 07 Jul 2017 10:13:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Fri, 7 Jul 2017 10:13:07 -0700 (PDT) In-Reply-To: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> From: Richard Barnes Date: Fri, 7 Jul 2017 13:13:07 -0400 Message-ID: To: Russ Housley Cc: Matthew Green , IETF TLS Content-Type: multipart/alternative; boundary="f403045d5732d392550553bd584d" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 17:13:12 -0000 --f403045d5732d392550553bd584d Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 12:35 PM, Russ Housley wrote: > Richard: > > Without taking a position on whether this group should take on this work, > a couple of questions about alternative approaches (sorry if these have > been answered before): > > 1. It seems like the requirement here is that the DH private key be > *predictable* by the monitoring box based on some static configuration. > That is, it seems like you could have keys that are predictable to the > monitoring device, but still vary over time, something like setting the > private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom). > Without having done much analysis, this seems more conservative than making > things entirely static. Is there a reason to prefer the purely static > approach besides simplicity? > > > Please see Section 6 of the draft. The non-ephemeral DH keys MUST have a > validity period. The keys are expected to change over time. > OK, then why not have this happen automatically (e.g., by folding in ServerRandom) rather than doing the provisioning process over and over? > > 2. You could avoid changing how the DH works altogether by simply > exporting the DH private key, encrypted with a key shared with the > monitoring device, in a server extension. (Not in EncryptedExtensions, > obviously.) This would also have the benefit of explicitly signaling when > such monitoring is in use. The only real challenge here is that the client > would have to offer the extension in order for the server to be able to > send it, which I expect things like browsers would be unlikely to do. > However, given that the target of this draft seems to be intra-data-center > TLS, perhaps this is a workable requirement? > > > In most common deployment case, the load balancer at the edge of the > enterprise datacenter will terminate the TLS session and start a new one. > The TLS session that protects the traffic on the public Internet works > exactly as described in draft-ietf-tls-tls13. The non-ephemeral DH keys > are associated only with sessions that are inside the enterprise > datacenter. So, you are right, no browser will be at either end of any of > these TLS sessions. There is no change to the way that the protocol makes > use of the DH key. The drft-green, the server need to look in a table to > choose a valid non-ephemeral DH key. In your proposal, the server need to > wrap the ephemeral DH private key in a key-enceyption key. Both solutions > require the distribution of some key (either the non-ephemenral DH key or > the key-encryption key) to the parties that are authorized to see the > traffic. > Yes, I understand that all of the solutions in this space will require some static configuration. What I'm trying to do is minimize the degree to which that static-ness reduces the entropy in the TLS handshake. In the "fold in ServerRandom" version, the static information gets tempered with per-session random information. In the "smuggle out the private key" version, the static information doesn't even touch the base TLS handshake; it's only used for wrapping the DH private key. I agree that the "smuggle out the private key" still has a static component that you would want to refresh. However, it's minimal, in the sense that you're going to need to authenticate the monitoring box to the TLS server somehow anyway (even if just for provisioning). And it seems like a cleaner separation to have the static component as something off to the side of the main handshake, rather than having to make invasive changes to the handshake code. --Richard > > > Stephen: > > I don't believe the WG should adopt this as it goes > against rfc2804 and encourages bad behaviour. We > ought not be helping to normalise broken crypto. I'm > happy to repeat that at the mic in Prague but would > be even happier if this draft were not discussed > there - these attempts to weaken security have IMO > already taken up too much time and too many cycles. > > > Repeating from above, the non-ephemeral DH keys are associated only with > sessions that are inside the enterprise datacenter. In some industries, > there are regulatory requirements that cannot be met without access to the > plaintext. Without some authorized access mechanism, the enterprise will > be forced to use plaintext within the datacenter. That seems like a worse > alternative to me. > > Russ > > > On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green > wrote: > >> The need for enterprise datacenters to access TLS 1.3 plaintext for >> security and operational requirements has been under discussion since >> shortly before the Seoul IETF meeting. This draft provides current thinking >> about the way to facilitate plain text access based on the use of static >> (EC)DH keys on the servers. These keys have a lifetime; they get replaced >> on a regular schedule. A key manager in the datacenter generates and >> distributes these keys. The Asymmetric Key Package [RFC5958] format is >> used to transfer and load the keys wherever they are authorized for use. >> >> We have asked for a few minutes to talk about this draft in the TLS WG >> session at the upcoming Prague IETF. Please take a look so we can have a >> productive discussion. Of course, we're eager to start that discussion on >> the mail list in advance of the meeting. >> >> The draft can be found here: >> >> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 >> >> Thanks for your attention, >> Matt, Ralph, Paul, Steve, and Russ >> > > --f403045d5732d392550553bd584d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 7, 2017 at 12:35 PM, Russ Housley <housley= @vigilsec.com> wrote:
Richard:

Without taking a position on whether th= is group should take on this work, a couple of questions about alternative = approaches (sorry if these have been answered before):

1. It seems like the requirement here is that = the DH private key be *predictable* by the monitoring box based on some sta= tic configuration.=C2=A0 That is, it seems like you could have keys that ar= e predictable to the monitoring device, but still vary over time, something= like setting the private key from a KDF(SecretSharedWithMonitoringDev= ice, ServerRandom). Without having done much analysis, this seems more= conservative than making things entirely static. Is there a reason to pref= er the purely static approach besides simplicity?

Please see Section 6 of the draft.=C2=A0 The non= -ephemeral DH keys MUST have a validity period.=C2=A0 The keys are expected= to change over time.

OK,= then why not have this happen automatically (e.g., by folding in ServerRan= dom) rather than doing the provisioning process over and over?

=C2=A0

2. You could a= void changing how the DH works altogether by simply exporting the DH privat= e key, encrypted with a key shared with the monitoring device, in a server = extension.=C2=A0 (Not in EncryptedExtensions, obviously.)=C2=A0 This would = also have the benefit of explicitly signaling when such monitoring is in us= e.=C2=A0 The only real challenge here is that the client would have to offe= r the extension in order for the server to be able to send it, which I expe= ct things like browsers would be unlikely to do.=C2=A0 However, given that = the target of this draft seems to be intra-data-center TLS, perhaps this is= a workable requirement?

In most common deployment case, the load balancer at the edge of the ente= rprise datacenter will terminate the TLS session and start a new one.=C2=A0= The TLS session that protects the traffic on the public Internet works exa= ctly as described in draft-ietf-tls-tls13.=C2=A0 The non-ephemeral DH keys = are associated only with sessions that are inside the=C2=A0enterprise datac= enter.=C2=A0 So, you are right, no browser will be at either end of any of = these TLS sessions.=C2=A0 There is no change to the way that the protocol m= akes use of the DH key.=C2=A0 The drft-green, the server need to look in a = table to choose a valid non-ephemeral DH key.=C2=A0 In your proposal, the s= erver need to wrap the ephemeral DH private key in a key-enceyption key.=C2= =A0 Both solutions require the distribution of some key (either the non-eph= emenral DH key or the key-encryption key) to the parties that are authorize= d to see the traffic.

Yes= , I understand that all of the solutions in this space will require some st= atic configuration.=C2=A0 What I'm trying to do is minimize the degree = to which that static-ness reduces the entropy in the TLS handshake.

In the "fold in ServerRandom" version, the = static information gets tempered with per-session random information.=C2=A0= In the "smuggle out the private key" version, the static informa= tion doesn't even touch the base TLS handshake; it's only used for = wrapping the DH private key.

I agree that the = "smuggle out the private key" still has a static component that y= ou would want to refresh.=C2=A0 However, it's minimal, in the sense tha= t you're going to need to authenticate the monitoring box to the TLS se= rver somehow anyway (even if just for provisioning).=C2=A0 And it seems lik= e a cleaner separation to have the static component as something off to the= side of the main handshake, rather than having to make invasive changes to= the handshake code.

--Richard
=

=C2=A0


Stephen:

I don't believe the WG should adopt thi= s as it goes
against rfc2804 and encourages bad behaviour. We
ought n= ot be helping to normalise broken crypto. I'm
happy to repeat that a= t the mic in Prague but would
be even happier if this draft were not dis= cussed
there - these attempts to weaken security have IMO
already tak= en up too much time and too many cycles.

Repeating from above, the non-ephemeral DH keys are associat= ed only with sessions that are inside the=C2=A0enterprise datacenter.=C2=A0= In some industries, there are regulatory requirements that cannot be met w= ithout access to the plaintext.=C2=A0 Without some authorized access mechan= ism, the enterprise will be forced to use plaintext within the datacenter.= =C2=A0 That seems like a worse alternative to me.

Russ


On Fri, Jul 7, 2017 at 3:02 AM, Matth= ew Green <matthewdgreen@gmail.com> wrote:
<= div class=3D"gmail_extra">
The need for enterprise datacenters to access TLS 1.3 plaintext for secur= ity and operational requirements has been under discussion since shortly be= fore the Seoul IETF meeting. This draft provides current thinking about the= way to facilitate plain text access based on the use of static (EC)DH keys= on the servers. These keys have a lifetime; they get replaced on a regular= schedule. A key manager in the datacenter generates and distributes these = keys.=C2=A0 The Asymmetric Key Package [RFC5958] format is used to transfer= and load the keys wherever they are authorized for use.

We have asked for a f= ew minutes to talk about this draft in the TLS WG session at the upcoming P= rague IETF. Please take a look so we can have a productive discussion.=C2= =A0 Of course, we're eager to start that discussion on the mail list in= advance of the meeting.

The draft can be found here:

https://tools.ietf.org/html/draft-green-tls-static-dh-in= -tls13-01

Thanks for your attention,
Ma= tt, Ralph, Paul, Steve, and Russ


--f403045d5732d392550553bd584d-- From nobody Fri Jul 7 10:17:05 2017 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 1E783131726 for ; Fri, 7 Jul 2017 10:17:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 jKuTVYyFbcMv for ; Fri, 7 Jul 2017 10:17:01 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 A1A7D13164A for ; Fri, 7 Jul 2017 10:17:01 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v67HCA6G023210; Fri, 7 Jul 2017 18:16:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=RdwjWV1ZULMsOlgGQ5BQTahT5kTV0JnhDXItzkB40ZA=; b=OfloilLLJ14SPe8rdpOkr1pxvtcyKpo+6zsZloJN33UZulXDT60T1NrmaSogJ2Qf3n8n iXpSALAnFySLAHa589YMvjRskKqAvEJ2FP7RTLelt5Zc0iweVxGM7QlhLMn2H4VQgMfY RsNl+U1nYdRuT7AmgJ+8qPaxx/+uGJk6rU8oOb92ZWHW8sdxNWE1EycCHUjgzDtVnoka 5oxydbb/O1BfcTzTmgzvkfuiCH0zRho1vCrI6QK+cTRPOGz4FZyXRds9WDq5tg15AGjD 1UTY+mwPVOni6jYBAe3eoBXAn7wj7IIUGo6RTahagHR2NS8IqdC2TTuOWk+WiDOh3GuJ yg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bj21kanqn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 18:16:59 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v67HFrsj015804; Fri, 7 Jul 2017 13:16:58 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bhm6e3wbu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 13:16:58 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Jul 2017 10:16:57 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Jul 2017 13:16:57 -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.1263.000; Fri, 7 Jul 2017 13:16:57 -0400 From: "Salz, Rich" To: Russ Housley , Richard Barnes CC: IETF TLS , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJIl6UAgAA7lAD//8diAA== Date: Fri, 7 Jul 2017 17:16:56 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> In-Reply-To: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.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.32.247] Content-Type: multipart/alternative; boundary="_000_e25f75b11312481ab0441e2d129803f1usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707070287 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070286 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 17:17:03 -0000 --_000_e25f75b11312481ab0441e2d129803f1usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think there is little doubt that the draft is technically sound. The question is, should the IETF =93endorse=94 this by saying it is a produ= ct of the TLS working group? That will certainly send a mixed message to s= ome. As we heard around around Seoul, not adopting might send a message to= some industries that we are not interested in helping to solve their probl= ems. It is a fraught issue. --_000_e25f75b11312481ab0441e2d129803f1usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I think there is little doubt that the draft is tec= hnically sound.

 

The question is, should the IETF =93endorse=94 this= by saying it is a product of the TLS working group?  That will certai= nly send a mixed message to some.  As we heard around around Seoul, not adopting might send a message to some industries that we are no= t interested in helping to solve their problems.

 

It is a fraught issue.

--_000_e25f75b11312481ab0441e2d129803f1usma1exdag1mb1msgcorpak_-- From nobody Fri Jul 7 10:19:59 2017 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 0CAE4131749 for ; Fri, 7 Jul 2017 10:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Lm9RphuuXrN1 for ; Fri, 7 Jul 2017 10:19:55 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0104.outbound.protection.outlook.com [104.47.37.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88513131747 for ; Fri, 7 Jul 2017 10:19:55 -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=TCZcYY5Jl5k+A6T2s8V46qa5svdyDpJzMar930HjRqo=; b=adGTDp3zrTqH7mGNBXwWgzJJv7T82O0HakzvQzWYDWaUvZo1BRSlxIwPEqcU06dow/WYR4XLFrl2RgcvaWNibYiCBttH8/AZaYJcSZ37SNKpwCKNqCfaAQnmy369Ka3EnUQI85I8Tpwl/Aa24KsD69JYy4RwhORz0Pmt+2RHgV0= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0011.namprd21.prod.outlook.com (10.161.140.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.3; Fri, 7 Jul 2017 17:19:53 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::5001:5681:2188:eed6]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::5001:5681:2188:eed6%18]) with mapi id 15.01.1240.007; Fri, 7 Jul 2017 17:19:53 +0000 From: Andrei Popov To: "Salz, Rich" , Russ Housley , Richard Barnes CC: IETF TLS , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8Rp3NE5QR80U6Cdwl/o72b4qJIVJcAgAA7lACAAAuhAIAAAHFw Date: Fri, 7 Jul 2017 17:19:53 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0011; 7:Mii4Dy3IaOFozfKP+6khFYq5r8aGvnvY/Wh08t3IqvlsTopSnagN5rWvSUUBgnUfYvCts6hh+MTVwje5EQE1lzDzb/Zu5KG32uqicwsNBYP+N/0ASC4/gOWSm8F2WPEtmWYrWArkPvlCXaNABndHNxw2+vWGkWDd+tuQmLy+PenkUfvqqUwrXIBo18+/eLKSotr5ZzBcvfFzJe2Fp55k/8TDtu2TMSph10i4NHGm7MdZHwIzXgRIa+iuapR1NsZngaNGOAb4nWt4vqeB78ZhuekK9nkLWSRiw6SmmShxR/V8PnlS1bb1tDa0tDPp0fgWQWHuelw59EakUPSidFPwfaIzGB7oeAJjQJDWKy+KUix7qjSX9eZftoKNKjCuP9pkocmcsISBXOs24w9McU+IIpnk99QOOZwkl3A+Ll+Tyvqzd03J2yUAoyHibERVeoZ20q/ABwicNEW38cHqhH78IH+SYDSRRi9P+6vOrvrdmyOY/jI2kYjFokyJcSjND1ZWr+m6y7LsvMviviEQfnqnfZRIy1zrVjO1X9d80cynJ+3WbmqIZei98AQSyw6RaW4Lw64upjYRdA1+8EY2kIAoF1yS8KI7Usjy+UgvoFOMVH92VvE562G188xyO5BOOyE+fXGzXrQ8Coz/+TDKDRgs7A7sYWXGXb1qVugLZ11DqKCOv2pumNvYr2UyijlkjvU6NQX58EZYuC9+q6j/EIVeeaYyQTmvw6pR0Wk3sNi85OlXXLIb68ZC4pJdpKu/MEWwEePp5RMsYN4877fuR7NqJV36NgPtFxYMrDcvra2oH8zJLvW7rhBRgK7Bq6j6Fjbn x-ms-office365-filtering-correlation-id: 0654266d-b569-4843-5c27-08d4c55c6206 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR21MB0011; x-ms-traffictypediagnostic: DM2PR21MB0011: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(2017060910066)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0011; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0011; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39450400003)(39410400002)(39860400002)(39850400002)(39840400002)(377454003)(81166006)(53936002)(33656002)(25786009)(478600001)(93886004)(72206003)(5660300001)(6246003)(38730400002)(2950100002)(4326008)(230783001)(14454004)(8676002)(54356999)(50986999)(76176999)(2900100001)(10090500001)(2906002)(39060400002)(3660700001)(19609705001)(189998001)(10290500003)(3280700002)(74316002)(5005710100001)(229853002)(7736002)(54906002)(6306002)(7696004)(9686003)(8936002)(6436002)(99286003)(55016002)(6116002)(6506006)(5250100002)(102836003)(54896002)(790700001)(8990500004)(86612001)(53546010)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0011; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR21MB0091CF646D313D120FA0A00A8CAA0DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2017 17:19:53.6923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0011 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 17:19:58 -0000 --_000_DM2PR21MB0091CF646D313D120FA0A00A8CAA0DM2PR21MB0091namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would the Informational track be an acceptable compromise? This does not ha= ve to be a product of the TLS working group. Cheers, Andrei From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Salz, Rich Sent: Friday, July 7, 2017 10:17 AM To: Russ Housley ; Richard Barnes Cc: IETF TLS ; Matthew Green Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 I think there is little doubt that the draft is technically sound. The question is, should the IETF "endorse" this by saying it is a product o= f the TLS working group? That will certainly send a mixed message to some.= As we heard around around Seoul, not adopting might send a message to som= e industries that we are not interested in helping to solve their problems. It is a fraught issue. --_000_DM2PR21MB0091CF646D313D120FA0A00A8CAA0DM2PR21MB0091namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would the Informational track be an acceptable comp= romise? This does not have to be a product of the TLS working group.

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-bounces@ietf.o= rg] On Behalf Of Salz, Rich
Sent: Friday, July 7, 2017 10:17 AM
To: Russ Housley <housley@vigilsec.com>; Richard Barnes <rl= b@ipv.sx>
Cc: IETF TLS <tls@ietf.org>; Matthew Green <matthewdgreen@g= mail.com>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01<= /span>

 

I think there is little doubt that the draft is tec= hnically sound.

 

The question is, should the IETF “endorseR= 21; this by saying it is a product of the TLS working group?  That wil= l certainly send a mixed message to some.  As we heard around around Seoul, not adopting might send a message to some industries that we are no= t interested in helping to solve their problems.

 

It is a fraught issue.

--_000_DM2PR21MB0091CF646D313D120FA0A00A8CAA0DM2PR21MB0091namp_-- From nobody Fri Jul 7 10:39:49 2017 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 09D6D1317A9 for ; Fri, 7 Jul 2017 10:39:48 -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 uXaIPb5MqQhV for ; Fri, 7 Jul 2017 10:39:46 -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 6DEE512700F for ; Fri, 7 Jul 2017 10:39:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B6D82300563 for ; Fri, 7 Jul 2017 13:39:45 -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 5Ayu2AAAf2LE for ; Fri, 7 Jul 2017 13:39:44 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 85760300250; Fri, 7 Jul 2017 13:39:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Fri, 7 Jul 2017 13:39:43 -0400 Cc: IETF TLS , Matthew Green Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Watson Ladd X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 17:39:48 -0000 Watson: >> This document is extremely well written and describes the needs of >> enterprises well, IMHO. I believe and have heard, there are = similar >> needs beyond the enterprise realm, but since we are the only ones = formally >> expressing concerns, so be it. >=20 > Why does the IETF need to be involved, given this solution exists? I would like there to be one way for the key manager to load the = non-ephemeral key into the server and the authorized decrypt parties. = Without an RFC, I fear there will be many ways that this is handled, = with varying levels of security. Russ From nobody Fri Jul 7 11:06:30 2017 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 4146C12EC47 for ; Fri, 7 Jul 2017 11:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpkZTERT70J9 for ; Fri, 7 Jul 2017 11:06:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE9A131621 for ; Fri, 7 Jul 2017 11:06:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5DE5EBE39; Fri, 7 Jul 2017 19:06:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLJXtoo4cEJT; Fri, 7 Jul 2017 19:06:15 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9A7F9BE38; Fri, 7 Jul 2017 19:06:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499450775; bh=4VMxu0yQ2uQLf6A2joY2IEtYiC9J1h7a6cqvlDZfmYI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WffLL2LChOTsSM3jDdD1TFc7Mb4NJL/fV+z0Y1L12a88gooi67z2eta1w3Z2DT9p2 eNihB0T/4+P/0zw/ykh0ZfAEBbJZi7Xg4DJemsatSaA34SqBC6Rd063A9OK7+Phibq JUy9VWW7IIEnY2B2/uG157GX5bGR02FVsCF0gB40= To: Andrei Popov , "Salz, Rich" , Russ Housley , Richard Barnes Cc: IETF TLS , Matthew Green References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 7 Jul 2017 19:06:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EN6aWj2GgRbroipUpnvMnLiPxATfOkM3U" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 18:06:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EN6aWj2GgRbroipUpnvMnLiPxATfOkM3U Content-Type: multipart/mixed; boundary="0DTLS1bc3Bscvm6s0OJKvawWpBPFtD6fx"; protected-headers="v1" From: Stephen Farrell To: Andrei Popov , "Salz, Rich" , Russ Housley , Richard Barnes Cc: IETF TLS , Matthew Green Message-ID: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> In-Reply-To: --0DTLS1bc3Bscvm6s0OJKvawWpBPFtD6fx Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 07/07/17 18:19, Andrei Popov wrote: > Would the Informational track be an acceptable compromise? This does no= t have to be a product of the TLS working group. IMO, no, and seeking compromise is not necessarily the right approach anyway - if we did that here, then why not "compromise" and say RC4 is better than nothing? Or md5? Isn't a compromise due to this kind of broken system far far more likely than one due to rc4 or md5? S. >=20 > Cheers, >=20 > Andrei >=20 > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Salz, Rich > Sent: Friday, July 7, 2017 10:17 AM > To: Russ Housley ; Richard Barnes > Cc: IETF TLS ; Matthew Green > Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 >=20 > I think there is little doubt that the draft is technically sound. >=20 > The question is, should the IETF "endorse" this by saying it is a produ= ct of the TLS working group? That will certainly send a mixed message to= some. As we heard around around Seoul, not adopting might send a messag= e to some industries that we are not interested in helping to solve their= problems. >=20 > It is a fraught issue. >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --0DTLS1bc3Bscvm6s0OJKvawWpBPFtD6fx-- --EN6aWj2GgRbroipUpnvMnLiPxATfOkM3U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZX82WAAoJEC88hzaAX42iPgQH/iSBbrJnd+oWZR0l+bv1g6LU oYexqQMBnOJEy0mXj4YezESquk0cjxKCJ8TWffEg5StS3yClhCQ4eGlY24NlEbze 1blokhOPQmhnlgKY3W48Mp9ycYkEqKoPH2Ve1VuPGw/VAi84Qvi+uyZ+ss0xJruT CrBo9kz/yfiVGcNfLlsVogowmZlxV185vQCttnPeUt0oCSR2Kl2lLybVxGPuiqvg 854sWEwIMosktDhyYiPLkHle9UW/2FDS7i08fNjOA/WMxc9OgMEVS8/dzD0fNRQZ GpSPcGhRG6M+ze28u/FFhZFxYFRQTfofBOoF3blTS1v70Z03ID95wfsZAGGA+F8= =lRCg -----END PGP SIGNATURE----- --EN6aWj2GgRbroipUpnvMnLiPxATfOkM3U-- From nobody Fri Jul 7 11:21:33 2017 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 77A49129B36 for ; Fri, 7 Jul 2017 11:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb2344UnB15a for ; Fri, 7 Jul 2017 11:21:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2A51317D1 for ; Fri, 7 Jul 2017 11:21:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E9FBABE50; Fri, 7 Jul 2017 19:21:10 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNPrNoGeptC5; Fri, 7 Jul 2017 19:21:09 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B67F4BE39; Fri, 7 Jul 2017 19:21:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499451669; bh=CtIm/vhg/+yDNOVIQq50hSXbhDAlj5kj3yfosaSYusg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Xt4vzhwCz9q0aZ2es0maIaRjKmaS+QjsnvgnElJWDyXR1ud3OKMqmz24444JEnTdR +EO1a8CQgZn8wne6XtTcK1Xe8a9+8SrQjmClKjC7tzZqHDwSjyPCIctuL21+WU8MZh 6Uz368K4fecGZe9fXKzZv0vnaA+yHPt3RoY9DCx8= To: Russ Housley , Richard Barnes Cc: IETF TLS , Matthew Green References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> Date: Fri, 7 Jul 2017 19:21:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4KJ17GcsBBFHCLPwAeNMWWDbpOxXVqMJp" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 18:21:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4KJ17GcsBBFHCLPwAeNMWWDbpOxXVqMJp Content-Type: multipart/mixed; boundary="vm31FcAxBqQr0ELaFLFxpaeixWrqAORBL"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , Richard Barnes Cc: IETF TLS , Matthew Green Message-ID: <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> In-Reply-To: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> --vm31FcAxBqQr0ELaFLFxpaeixWrqAORBL Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Russ, On 07/07/17 17:35, Russ Housley wrote: > Repeating from above, the non-ephemeral DH keys are associated only > with sessions that are inside the enterprise datacenter. I find it really hard to believe anyone is convinced of that. Yes, one could chose to use this proposed wiretapping scheme like that but figure 3 in the draft makes if fully clear that this colluding or coerced wiretapping device can be anywhere on the Internet. 2804 says "no" here - are you proposing to obsolete that? If so, being up-front about that is IMO a pre-requisite and talk of "datacentres" avoided as the misdirection that it is. Again, I hope the chairs do not devote/waste more time on this until there is a demonstrated IETF consensus to obsolete 2804. We cannot honestly have both this and that. S. --vm31FcAxBqQr0ELaFLFxpaeixWrqAORBL-- --4KJ17GcsBBFHCLPwAeNMWWDbpOxXVqMJp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZX9EVAAoJEC88hzaAX42iAM8H/A3oqsDtRpF6jzjdwmClfyK1 WaWo+W7rsWGX+1oRYce7Cqtvg90jvIdCfn5tL6faodZdnJzE9l3EQw5FcMi+v/K2 EbawOTHidJcIius32xqeVScJSY73pJ78Swmp6tE8GvCIYFFyFsHJXiyq5MG2NbnN Di/1C1WY/AAHXj896qNkl+J5ZibNqYbGuI/AU2WL7UuufePZtrKMOgtAhnRLEOYd 4fZFHcKfsl+v1/iuOX3RK85nx5NAEhEskVZKgNf4hD4eEYfVH05snkY2ogkhPXXA 9I37NLiVkuA9rG3g5ryqZcO/M1ZjkcLIa8X6XH7Z/Lh3VgUiZcDQpQao7VdKRAs= =hJqM -----END PGP SIGNATURE----- --4KJ17GcsBBFHCLPwAeNMWWDbpOxXVqMJp-- From nobody Fri Jul 7 11:31:15 2017 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 410471317CE for ; Fri, 7 Jul 2017 11:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UpwxgDn62A-b for ; Fri, 7 Jul 2017 11:31:11 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 BB8D5131698 for ; Fri, 7 Jul 2017 11:31:10 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id g40so25109257uaa.3 for ; Fri, 07 Jul 2017 11:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SSD6KJav+ubG+ocfaqpzYidggTY1aEAbz5vvdZmQnxY=; b=pHCvkfsrFPEuZ2iGVIXesOUB8dymOHbqRjnZe37Q7kAzLCDmDxTqKCEo7uMxc/cLvR G3CM2NSRtbkJyX+Lv1eYvH5zdw9i5uGaheBYerU1VvaGADZFXA6EW+f5be0MxKToc9sO KFrMZHLBPpKr3B6UIms/gxwMH8iMRIyymiQv0eBRoE5YokDqFC91PdSb9EzlLwkYzUix MlzPnhYB00oNVlUApd4ckKJqB3CVxqvDvjS463I0Wrqjx7zrY+R9Acb2qfZutIvrvVhr ZWx78KUmY6xhPNu3M9SDkWehZJ/rRnbmDZ5OOtgLvwQQjMe51+1I3zoxWWE9Gc9TNNS0 lhuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SSD6KJav+ubG+ocfaqpzYidggTY1aEAbz5vvdZmQnxY=; b=TnSVidME2J64AhOd+NkYS2cD0PynpNBo0FsJ5Apy29hdYCqSJ/Frv/61xA46g1RF45 b+HD9gsrwqZhWPU8Zj3Y/K/HSPxHtr01xkbj03ofK4FjzlkeNw+D40NHn+pNqnFyCfOm zQ52SGceAY6u5DVo/jErnBvhUeLdjh8c5ol4TWF7XCjh9WMwaZ2yhizYsI/oYATm1sLZ uFHL9TqbJ46W626LfmVYnePdPbTWuBW4EWWD9GDMdANJFMzO07RoBPWNbHVGNjWk3iyh YJ4wyBawbD3wyU3Lo6zler0Sy5/Y9U+9a95CffpVOGalJ8eRXkyrkIg1K1srXCvc51y1 8BkA== X-Gm-Message-State: AIVw110etVrkrJN955LEO8RqxKulabJBqwx2jK+CBxqqgAOv4oTQOL+h w6nsO8V/TnqMex64sXOeNjyag/AsPg== X-Received: by 10.176.86.21 with SMTP id y21mr1341967uaa.72.1499452269875; Fri, 07 Jul 2017 11:31:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Fri, 7 Jul 2017 11:31:09 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Fri, 7 Jul 2017 14:31:09 -0400 Message-ID: To: Benjamin Kaduk Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045dd5b0e755b20553be6f44" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 18:31:13 -0000 --f403045dd5b0e755b20553be6f44 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 11:59 AM, Benjamin Kaduk wrote: > On 06/28/2017 04:15 PM, Joseph Salowey wrote: > > This is the working group last call for draft-ietf-tls-dnssec-chain-extension-04. > Please send you comments to the list by July 12, 2017. > > > Just a couple minor things I don't remember being mentioned already that I > noticed in a quick read: > > When section 3.4 mentions that "this document describes the data structure > in sufficient detail that implementors if they desire can write their own > code to do this", it seems that this really on makes sense when the "this" > is for the encoding side, not the decoding side. That is, in that we > expect future DNS clients to continue to process responses in the current > format, but future DNS servers might generate responses that cannot be > properly decoded just following this document. (E.g., what would happen if > NSEC5 became popular?) > I think it's best to take that sentence out. It's a remnant of much earlier versions of the draft where we did describe the decoding (and validation) side in more detail, whereas now a lot of the client side processing is being referred to DNSSEC specs. Regarding future DNSSEC protocol enhancements that may necessitate format and protocol processing changes, maybe it's best to defer those to future revisions of the spec. But feel free to propose any specific wording on this topic for inclusion. (NSEC5 adoption in DNSOP is still very much an open question. The other possible enhancement that might need to be considered in the future is records related to key transparency - "CT for DNSSEC", which could happen someday.) > In section 8: > > Mandating this extension for Raw Public Key > authentication (where there are no X.509 certificates) could employ > configuration mechanisms external to the TLS protocol > > this sentence structure is a little confusing; it might be better to say something like "If needed, configuration mechanism external to the TLS protocol could be used to mandate the use of this extension for Raw Public Key authentication". > > -Ben > > Yes, your suggested text sounds much better. We can incorporate that. However, there is larger concern that I have with section 8 that probably deserves working group discussion. This section might imply that there is a (protocol resident) way to mandate the use of this extension, but I don't think there is an easy way. Even in the case of X.509 certificates, the TLS feature extension can only dictate the delivery of this extension when the client has connected to the right server presenting that certificate. A TLS client misdirected to a rogue TLS server (e.g. via DNS spoofing, a routing attack, or other means) that has fraudulently acquired a public CA issued certificate for the legitimate server name, could be induced to establish a (PKIX) verified connection to that rogue server that precludes DANE authentication, when in fact it was available. Some TLS applications may desire to mandate DANE authentication where available, and protect themselves against malicious or tricked CAs. What is the best way to accommodate them? TLS clients could keep a whitelist of DANE servers, which doesn't scale very far; they could use TOFU/HPKP like methods: add DANE supporting sites to a whitelist dynamically as they are seen, etc. Some other applications use the presence of an authenticated TLSA record to enforce DANE authentication (RFC 7672 for SMTP STARTTLS). The last time this was discussed in the context of tls-dnssec-chain, it was argued that this "mandatory use" was not a semantic that the generic TLSA record provides, so only specific applications should specify that behavior. But if a specific TLS application using this extension did want to specify this behavior, how could it happen? In a hypothetical world where all TLS clients & servers understood this extension, we could have required the TLS server to either (1) present the dnssec_chain for their TLSA record, or (2) present a dnssec_chain that demonstrates that there is no secure TLSA record, or that there is no secure delegation to the zone. I think this would solve the problem, but this isn't practical any time soon (or perhaps ever). I'm not suggesting that we need to come up with a solution for this, but I believe the issue probably needs some sort of mention somewhere (in Security Considerations?). -- Shumon Huque --f403045dd5b0e755b20553be6f44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 11:59 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20
On 06/28/2017 04:15 PM, Joseph Salowey wrote:
=20
This is the working group last call for=C2=A0draft-ietf-tls-dnssec-chain-extension-04.=C2=A0 Please send you comments to the list by July 12, 2017. =C2=A0

 Just a couple minor things I don't remember being mentioned already that I noticed in a quick read:

When section 3.4 mentions that "this document describes the data structure in sufficient detail that implementors if they desire can write their own code to do this", it seems that this really on mak= es sense when the "this" is for the encoding side, not the decod= ing side.=C2=A0 That is, in that we expect future DNS clients to continue t= o process responses in the current format, but future DNS servers might generate responses that cannot be properly decoded just following this document.=C2=A0 (E.g., what would happen if NSEC5 became popular?)

I think it's be= st to take that sentence out. It's a remnant of much earlier versions o= f the draft where we did describe the decoding (and validation) side in mor= e detail, whereas now a lot of the client side processing is being referred= to DNSSEC specs.

Regarding future DNSSEC protocol= enhancements that may necessitate format and protocol processing changes, = maybe it's best to defer those to future revisions of the spec. But fee= l free to propose any specific wording on this topic for inclusion.

(NSEC5 adoption in DNSOP is still very much an open quest= ion. The other possible enhancement that might need to be considered in the= future is records related to key transparency - "CT for DNSSEC",= which could happen someday.)


In section 8:

   Mandating this ext=
ension for Raw Public Key
   authentication (where there are no X.509 certificates) could employ
   configuration mechanisms external to the TLS protocol

this sentence structure is a little confusing; it might be better to say so=
mething like "If needed, configuration mechanism external to the TLS p=
rotocol could be used to mandate the use of this extension for Raw Public K=
ey authentication".

-Ben

Yes, your suggested text s= ounds much better. We can incorporate that.

Howeve= r, there is larger concern that I have with section 8 that probably deserve= s working group discussion. This section might imply that there is a (proto= col resident) way to mandate the use of this extension, but I don't thi= nk there is an easy way. Even in the case of X.509 certificates, the TLS fe= ature extension can only dictate the delivery of this extension when the cl= ient has connected to the right server presenting that certificate.

A TLS client misdirected to a rogue TLS server (e.g.= via DNS spoofing, a routing attack, or other means) that has fraudulently = acquired a public CA issued certificate for the legitimate server name, cou= ld be induced to establish a (PKIX) verified connection to that rogue serve= r that precludes DANE authentication, when in fact it was available.=C2=A0<= /div>

Some TLS applications may desire to mandate DANE a= uthentication where available, and protect themselves against malicious or = tricked CAs. What is the best way to accommodate them? TLS clients could ke= ep a whitelist of DANE servers, which doesn't scale very far; they coul= d use TOFU/HPKP like methods: add DANE supporting sites to a whitelist dyna= mically as they are seen, etc.

Some other applicat= ions use the presence of an authenticated TLSA record to enforce DANE authe= ntication (RFC 7672 for SMTP STARTTLS). The last time this was discussed in= the context of tls-dnssec-chain, it was argued that this "mandatory u= se" was not a semantic that the generic TLSA record provides, so only = specific applications should specify that behavior. But if a specific TLS a= pplication using this extension did want to specify this behavior, how coul= d it happen?=C2=A0

In a hypothetical world where a= ll TLS clients & servers understood this extension, we could have requi= red the TLS server to either (1) present the dnssec_chain for their TLSA re= cord, or (2) present a dnssec_chain that demonstrates that there is no secu= re TLSA record, or that there is no secure delegation to the zone. I think = this would solve the problem, but this isn't practical any time soon (o= r perhaps ever).

I'm not suggesting that we ne= ed to come up with a solution for this, but I believe the issue probably ne= eds some sort of mention somewhere (in Security Considerations?).

--=C2=A0
Shumon Huque

<= /div>
--f403045dd5b0e755b20553be6f44-- From nobody Fri Jul 7 11:40:42 2017 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 AC3771317CF for ; Fri, 7 Jul 2017 11:40:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 37coSQivwRJk for ; Fri, 7 Jul 2017 11:40:38 -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 6BB00128DE5 for ; Fri, 7 Jul 2017 11:40:38 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id v143so34534273qkb.0 for ; Fri, 07 Jul 2017 11:40:38 -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=FJyAhCRFXKVfeqBuWjlN+/ntv5aizMqFz8qjBTGGRVE=; b=dlpXq2RvKA11dHZZVDOWEVXm9fDUzoUNyz43v2dk+L7B8BPQdsI5bKMNw7iYDUJ+pG zKOjZv6iUQbxBaY+OaLaQw8YmrzKEfCYW6xdoqA038W2a89/SHNUH8A/dKSw5nwvsyeu v+I5qoItb4P3FJhZz/8VSeH5aSgkDTXtPNVLU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FJyAhCRFXKVfeqBuWjlN+/ntv5aizMqFz8qjBTGGRVE=; b=W66/MrVnfNNKFCouwuKs1J2lToqLVEBi3fe/u9edOsTRGFuhpviqdNDPVySBRjBag3 BHCun+/u1jUXmG2xo5BzA1aPo+tsNMIRyrqacKBTP8r6PhDVSHPKK8NkFS9P2+Oa7Hzs PGXHMG01/nvwEdngSxh//yx2npU/po56IUtJ4L+PaIlMtSRJTx9Pe6btSQLDHlMjyTaF 44WVQAiv9llLfwKXuKB+4PtnoOzEgbrMBo1Ti0yMvKG00pKZpZDrldMXBHXiqN8XGTXH izbV3UdtTBruG6bILpWjwMudpviuEn1SHSUyG+dy2i1iv0xViE+G7nkzCRkaeMTF11aL GcaA== X-Gm-Message-State: AKS2vOzYHJrPPc2Cr39waj9exgaebnzil1GALdr7J1745k8+fiizLG6d VkOQtCCulx+34jaejTcOrsQDqwYNLAP5 X-Received: by 10.55.140.71 with SMTP id o68mr71578331qkd.18.1499452837437; Fri, 07 Jul 2017 11:40:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Fri, 7 Jul 2017 11:40:36 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> From: Kyle Rose Date: Fri, 7 Jul 2017 14:40:36 -0400 Message-ID: To: Stephen Farrell Cc: Russ Housley , Richard Barnes , IETF TLS , Matthew Green Content-Type: multipart/alternative; boundary="001a114f885cbbb7820553be912e" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 18:40:41 -0000 --001a114f885cbbb7820553be912e Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 2:21 PM, Stephen Farrell wrote: > I find it really hard to believe anyone is convinced of that. > > Yes, one could chose to use this proposed wiretapping scheme > like that but figure 3 in the draft makes if fully clear that > this colluding or coerced wiretapping device can be anywhere > on the Internet. > > 2804 says "no" here - are you proposing to obsolete that? I don't think 2804 says any such thing. In fact, it explicitly states that: q( On the other hand, the IETF believes that mechanisms designed to facilitate or enable wiretapping, or methods of using other facilities for such purposes, should be openly described, so as to ensure the maximum review of the mechanisms and ensure that they adhere as closely as possible to their design constraints. The IETF believes that the publication of such mechanisms, and the publication of known weaknesses in such mechanisms, is a Good Thing. ) My reading of 2804 is that the IETF takes no moral position on wiretapping; recommends against it on technical grounds; and encourages documentation of proposed or in-use mechanisms for wiretapping for the express purpose of publicizing the flaws inherent in any such approach. IMO, an informational draft submitted via the ISE seems completely appropriate for something like this. I'll add that we've already gotten good input toward better alternatives on this very thread, which suggests that having these discussions out in the open is likely to result in better practical outcomes for user populations that are, one way or the other, going to be subject to systems like this. Discussing something does not presuppose or imply agreement on the objectives. Kyle --001a114f885cbbb7820553be912e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 2:21 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
I find it really hard to believe anyone is convinced of that.

Yes, one could chose to use this proposed wiretapping scheme
like that but figure 3 in the draft makes if fully clear that
this colluding or coerced wiretapping device can be anywhere
on the Internet.

2804 says "no" here - are you proposing to obsolete that?

I don't think 2804 says any such thing. In fac= t, it explicitly states that:

q( On the other hand, the I= ETF believes that mechanisms designed to
=C2=A0=C2=A0=C2=A0=C2=A0 facili= tate or enable wiretapping, or methods of using other
=C2=A0=C2=A0=C2=A0= =C2=A0 facilities for such purposes, should be openly described, so as to=C2=A0=C2=A0=C2=A0=C2=A0 ensure the maximum review of the mechanisms and = ensure that they
=C2=A0=C2=A0=C2=A0=C2=A0 adhere as closely as possible = to their design constraints. The IETF
=C2=A0=C2=A0=C2=A0=C2=A0 believes = that the publication of such mechanisms, and the
=C2=A0=C2=A0=C2=A0=C2= =A0 publication of known weaknesses in such mechanisms, is a Good
=C2=A0= =C2=A0=C2=A0=C2=A0 Thing. )

M= y reading of 2804 is that the IETF takes no moral position on wiretapping; = recommends against it on technical grounds; and encourages documentation of= proposed or in-use mechanisms for wiretapping for the express purpose of p= ublicizing the flaws inherent in any such approach.

IMO, an informational draft submitted via the ISE seems co= mpletely appropriate for something like this. I'll add that we've a= lready gotten good input toward better alternatives on this very thread, wh= ich suggests that having these discussions out in the open is likely to res= ult in better practical outcomes for user populations that are, one way or = the other, going to be subject to systems like this. Discussing something d= oes not presuppose or imply agreement on the objectives.

Kyle

--001a114f885cbbb7820553be912e-- From nobody Fri Jul 7 11:44:29 2017 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 E32E71317E3 for ; Fri, 7 Jul 2017 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi-O0SnvD_yE for ; Fri, 7 Jul 2017 11:44:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D97129A92 for ; Fri, 7 Jul 2017 11:44:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0233DBE2F; Fri, 7 Jul 2017 19:44:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsXNhJ_N55cK; Fri, 7 Jul 2017 19:44:22 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BD9FABDCC; Fri, 7 Jul 2017 19:44:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499453062; bh=s1tQ2OrRfS17J+TzMCAUKHGfr9XM5+/+GCMX1J5a6HU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GoiyxRyWs13GwOUzSA9uGZkBcBMd/Y3/YP1KK0ZZCgP0rqTVEMMur94+rDhDUWNHk 6XZimBeAeU/vWOcsvzzrX11bgfBnIyi4ya1RuwVJTaDb+bFPKalVDBVh6/boka8stB 2YoVJp46m+TgWMCiS5Dpo9dUouA80EWLb+2N0Dtc= To: Kyle Rose Cc: Russ Housley , Richard Barnes , IETF TLS , Matthew Green References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 7 Jul 2017 19:44:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BsGNh49JUqX6VfwHjlt8sKt48vaA5rb5Q" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 18:44:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BsGNh49JUqX6VfwHjlt8sKt48vaA5rb5Q Content-Type: multipart/mixed; boundary="X9APMxlwWbr8m3uoBuOtEhiND060CX7ss"; protected-headers="v1" From: Stephen Farrell To: Kyle Rose Cc: Russ Housley , Richard Barnes , IETF TLS , Matthew Green Message-ID: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> In-Reply-To: --X9APMxlwWbr8m3uoBuOtEhiND060CX7ss Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 07/07/17 19:40, Kyle Rose wrote: > an informational draft submitted via the ISE =2E..has nothing to to with this WG and ought consume no cycles on this list or in meetings. Yes, the ISE is the route 2804 envisages for documenting wiretapping schemes such as this. The authors of this draft however chose to put "standards track" in the header and some of those authors are very very well aware of all the nuances here so that was not a mistake is my conclusion. So I stand by my statement that 2804 says no to this. S. --X9APMxlwWbr8m3uoBuOtEhiND060CX7ss-- --BsGNh49JUqX6VfwHjlt8sKt48vaA5rb5Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZX9aGAAoJEC88hzaAX42iMsoH/jTjFiZkVFVsTgYowumuqzOJ 9WoNT9zgPYSAljuB4Ku1NYqw5zQFicBdl/kHkIo+UuuoBteXe6XzQSqDXQTNc4Uo MSIJI2EiyQziMR7vdyh102Jz30C4J9UCqzjmVvs2B2wRMGQnd6G2UrsntqyJL50U CmbNHMHjLuBBHCYgUkQ8BdH3kwrT9Ovch2r28RCwHvBhDtxCshsUXSgciFEigGbw MQ4riyfgZTY7553lvWqmKxpOCaGu9JkkVQGNp5Ppg4cwX2lxAG3XGQKJnjeg8t/c osK4tbXDic3wnAnGB00IhIBVggcJmNagCSOGDTl1kzucquuSMdKqSLySiix2cEA= =PVrb -----END PGP SIGNATURE----- --BsGNh49JUqX6VfwHjlt8sKt48vaA5rb5Q-- From nobody Fri Jul 7 11:51:11 2017 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 8AF1512EC05 for ; Fri, 7 Jul 2017 11:51:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 y-lNm78QlNYm for ; Fri, 7 Jul 2017 11:51:08 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 5D576126C83 for ; Fri, 7 Jul 2017 11:51:08 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v67IktTp032396; Fri, 7 Jul 2017 19:51:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=CMS0wCk+nOMihL6iuVFbUCQDIP9BRtcqgfn2v91kn/0=; b=oauoPpHiQtNDCNSjWhO5fCz+lS4pAxhXGeSBPbnSqrnb6JnCaVdGzQphF5spU3dxILV9 2fWItdo1RbvHCg25irUeFizyzmSOyFQtPyRWxUXrZ3DTzihj8eJ3V1jHaZ8DnzO2Bhlm dzHitUWMeA1M3odVsg2lwz835madFcuTYZEtnX21fJLA+vhDBzWGAhqZXpatGwT6A5O2 M2g1K+YxjRwSNV3lL0HVH1VdMGEg3h7lw922OcM9RZpNERsipLh+kCXdI+hcauVaQ7pf arWaXFxt4/xEKag5x26pKn2UBFc8bfS4HdWKyvMCSOz6gQvtQ1rRwYZQmb7CAA9rFY6O Hg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bj21kayqa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 19:51:06 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v67IofRM001826; Fri, 7 Jul 2017 14:51:04 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72ugk2u-1; Fri, 07 Jul 2017 14:51:04 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 3CA6C1FC86; Fri, 7 Jul 2017 18:51:04 +0000 (GMT) To: Shumon Huque Cc: "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: Date: Fri, 7 Jul 2017 13:51:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1C4B8BB6721EAD0AC46E0D6C" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707070312 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070311 Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 18:51:09 -0000 This is a multi-part message in MIME format. --------------1C4B8BB6721EAD0AC46E0D6C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/07/2017 01:31 PM, Shumon Huque wrote: > I'm not suggesting that we need to come up with a solution for this, > but I believe the issue probably needs some sort of mention somewhere > (in Security Considerations?). Sounds good to me. -Ben --------------1C4B8BB6721EAD0AC46E0D6C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/07/2017 01:31 PM, Shumon Huque wrote:
I'm not suggesting that we need to come up with a solution for this, but I believe the issue probably needs some sort of mention somewhere (in Security Considerations?).

Sounds good to me.

-Ben
--------------1C4B8BB6721EAD0AC46E0D6C-- From nobody Fri Jul 7 12:02:02 2017 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 A501D1317CD; Fri, 7 Jul 2017 12:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 5rnAewFvf36S; Fri, 7 Jul 2017 12:01:56 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0114.outbound.protection.outlook.com [104.47.0.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C5312009C; Fri, 7 Jul 2017 12:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jYOnPzlJjp2exX3SFfgwRTjG8SzistYkVN70oas2E2I=; b=OtKjbO2Xdf9JZOSq5y96BEztr9ee5xBTHY6bTe+ydjdG7I083YQk2R5ZoGflJrbfRpWMqHCkgA6RueBvXHrlYRmuBa8VDi5isyHhII0+lHtpYr5oPow7dbbLSLboP+fgaz/8xoz88A76zJHVBRAaaY0FXOe34k5MWy3YT0MNkOY= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1072.eurprd07.prod.outlook.com (10.163.168.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Fri, 7 Jul 2017 19:01:49 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::f53a:50dc:dcfe:9845]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::f53a:50dc:dcfe:9845%13]) with mapi id 15.01.1240.013; Fri, 7 Jul 2017 19:01:48 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Raja ashok , "draft-mavrogiannopoulos-tls-cid@ietf.org" , "nmav@redhat.com" , "hannes.tschofenig@arm.com" CC: "" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: Suggestions in draft-mavrogiannopoulos-tls-cid Thread-Index: AdL3Jy6Gr1KoWVE3S5i3yCcIRuxQogANK+6A Date: Fri, 7 Jul 2017 19:01:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.20.230.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1072; 7:t/4Fi6h7na1rg809fY+OurJJEybRA7A6KTg8rKRfH7vQGGP9BrQhCvFD6umKJHV5heYMZ/86VrZDzWT718JYTgtOkihaWCpr41cG/IDOzk2crMAHSngshXC+xnzlN+4GkxDuB1GUzZtzSu8jmdWNtqhg6WXwPD/teIu7nYXh3FDimb6dH3yAugRxSOiT8thU7dbSmA4R/O3XL79uwEwMAFaIsRLtb1yjA3w65hRmc9cpEh/GRCCW7QZ4n+HQD5EBp/fXar+inGNmtEQP/a3xZuUBa5El+QAV7OQxyArIWOMPFhKp9sAF34+4OJqYT6vFU8NoqC1s6b+v25GwnrqWkOjDyvuLgg6E/hFQkaPFq/XO3eC0DhlL9I9C9dvT3EZ6y+YcMIG85MpqmdY+Jb3gYY316uLHYVtPD7k6my07z6DMnGQ75s9SXZHRoX8A972hongMLZqPpsWmG+Q2XumE7rGNgjzGlowhC9uWRD8b8871Bfv9ebZXhCe2kdpe4xPh7F6ILUxqxJmSxtjQJc6NMEBpl7F5qGS8cr3AbBJFuu4NoU+DB5R8/51Ta9dDYOn2OG1wM2ufj5uH9GpO6LTqRa7ldZ0pbhmCtWebJoelwFalHgbstdr5RkJsBWLYVhdym0K3kLLNXdyswYaNj7sl2+HRnKPT/SIn1GKA4rAZvij6pC30bFa0kswq0Uc2WvLo91UNNQSGy/WzoIlw3sUnKq1R2h7Bn9KBb1/rF5qzOmGrWZfDHkwndhgiBSRhMLuaVsxmcb5SFAbCeppOswjHmU+D0uGNR5uQSXLLTxe02gQ= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39840400002)(39850400002)(39400400002)(39410400002)(24454002)(53546010)(76176999)(107886003)(8936002)(561944003)(33656002)(2201001)(36756003)(230783001)(66066001)(9326002)(6506006)(4001350100001)(966005)(38730400002)(3660700001)(53386004)(81166006)(189998001)(236005)(8676002)(2906002)(53936002)(733005)(6512007)(54896002)(3280700002)(4326008)(99286003)(6246003)(54356999)(25786009)(6306002)(54556002)(6436002)(478600001)(14454004)(7736002)(6116002)(102836003)(2950100002)(5250100002)(2501003)(5890100001)(5660300001)(3846002)(6486002)(229853002)(2900100001)(50986999)(82746002)(83716003)(83506001)(86362001)(99936001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1072; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 3777d179-31ef-4aed-a02d-08d4c56a9ed7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR07MB1072; x-ms-traffictypediagnostic: VI1PR07MB1072: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(158342451672863)(278428928389397)(26388249023172)(236129657087228)(50582790962513)(48057245064654)(148574349560750)(88738726483465)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(2017060910067)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1072; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1072; x-forefront-prvs: 0361212EA8 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_AD171715BB734B9DA85F70499C961415nokiacom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2017 19:01:48.6969 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1072 Archived-At: Subject: Re: [TLS] Suggestions in draft-mavrogiannopoulos-tls-cid X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 19:02:00 -0000 --_004_AD171715BB734B9DA85F70499C961415nokiacom_ Content-Type: multipart/alternative; boundary="_000_AD171715BB734B9DA85F70499C961415nokiacom_" --_000_AD171715BB734B9DA85F70499C961415nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQXNob2ssDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMuDQoNClNlZSBp bmxpbmUuDQoNCkNoZWVycywgdA0KDQpPbiAwNy8wNy8yMDE3LCAxNDo0NCwgIlJhamEgYXNob2si IDxyYWphLmFzaG9rQGh1YXdlaS5jb208bWFpbHRvOnJhamEuYXNob2tAaHVhd2VpLmNvbT4+IHdy b3RlOg0KDQpIaSBOaWtvcywgSGFubmVzICYgVGhvbWFzLA0KDQpUaGlzIENvbm5lY3Rpb25JRCBj b25jZXB0IGlzIHJlYWxseSBhIHVzZWZ1bCBmZWF0dXJlIGZvciBhIGNsaWVudCBub2RlIHdoaWNo IGZhY2VzIGEgY2hhbmdlIGluIHRyYW5zcG9ydCBhbmQgbmV0d29yayBsYXllci4gSSBhbSBoYXZp bmcgZmV3IHN1Z2dlc3Rpb25zIGluIHRoZSBwcm9wb3NlZCBkcmFmdCwgd2hpY2ggYXJlIGxpc3Rl ZCBiZWxvdy4NCg0KMSkgSW4gc2VjdGlvbiAzIG9mIHRoaXMgZHJhZnQsIGV4cGxhaW5zIGFib3V0 IHRoZSBtb2RpZmljYXRpb24gaW4gIkRUTFNDaXBoZXJ0ZXh0IiBzdHJ1Y3R1cmUuIEkgZmVlbCBp bnN0ZWFkIG9mIG1vZGlmeWluZyBleGlzdGluZyBEVExTIGFuZCBUTFMgcmVjb3JkIGhlYWRlciwg d2UgY2FuIGRpcmVjdGx5IGludHJvZHVjZSBhIG5ldyByZWNvcmQgdHlwZSAoQ29udGVudFR5cGUp IGZvciBhcHAgZGF0YSAoYXBwbGljYXRpb25fZGF0YV93aXRoX2NpZCgyNSkpLg0KDQpbdGZdIFdo eSBkbyB5b3UgdGhpbmsgYSBuZXcgcmVjb3JkIHR5cGUgd291bGQgYmUgYmV0dGVyIHRoYW4gdGhl IHByZXNlbnQgY29uc3RydWN0aW9uPyAgKEJUVywgd2Ugd291bGQgYWxzbyBuZWVkIGEgbmV3IGFs ZXJ0X3dpdGhfY2lkLCBJIGd1ZXNzLikNCg0KRm9yIHRoaXMgbmV3IHJlY29yZCB0eXBlLCB3ZSBj YW4gcHJvcG9zZSBhIG1vZGlmaWVkIHJlY29yZCBoZWFkZXIgZm9yIGJvdGggVExTIGFuZCBEVExT Lg0KDQpbdGZdIElmIHlvdSBhcmUgYWxyZWFkeSBtb2RpZnlpbmcgdGhlIHJlY29yZCBoZWFkZXIs IEkgYW0gbm90IHN1cmUgd2h5IHlvdSBhbHNvIG5lZWQgdG8gYWRkIG5ldyBjb250ZW50IHR5cGUo cyk/DQoNCjIpIE1vcmUgb3ZlciBzZWN0aW9uIDMgc2F5cyBtb2RpZmljYXRpb24gb25seSBpbiAi RFRMU0NpcGhlcnRleHQiLCBub3QgZm9yICJUTFNDaXBoZXJ0ZXh0Ii4gSSBob3BlIHRoaXMgQ0lE IG1lY2hhbmlzbSBzaG91bGQgYmUgdXNlZCBmb3IgYm90aCBUTFMgYW5kIERUTFMuIEJlY2F1c2Ug dGhpcyB0cmFuc3BvcnQgbGF5ZXIgY2hhbmdlIHByb2JsZW0gaXMgdGhlcmUgZm9yIFRMUyBiYXNl ZCBhcHBsaWNhdGlvbnMgKEhUVFBTKSBhbHNvIGluIFNtYXJ0cGhvbmUod2hlbiBpdCBzd2l0Y2hl cyBmcm9tIFdpZmkgdG8gTFRFKS4gQnV0IHRoaXMgVExTIGFwcGxpY2F0aW9uIHByb2JsZW0gaXMg c29sdmVkIGJ5IE1QVENQLCBidXQgSSBkb250IHRoaW5rIGFsbCB3ZWJzZXJ2ZXJzIGFyZSBzdXBw b3J0aW5nIHRoaXMgTVBUQ1AuIFNvIEkgZmVlbCBDSUQgaXMgcmVxdWlyZWQgZm9yIGJvdGggVExT IGFuZCBEVExTLg0KDQpbdGZdIEluIHByaW5jaXBsZSBJ4oCZbSBub3Qgb3Bwb3NlZCB0byBvcGVu IHRoZSBzb2x1dGlvbiBzcGFjZSB0byBUTFMsIGJ1dCB3ZSBuZWVkIHRvIHdvcmsgb3V0IHRoZSBp bXBsaWNhdGlvbnMuDQoNCjMpIEFzIHBhcnQgb2YgZGVmaW5pbmcgbmV3IHJlY29yZCB0eXBlLCB3 ZSBjYW4gcmVtb3ZlIHNvbWUgdW51c2VkIGZpZWxkcyBsaWtlIHZlcnNpb24sIGVwb2NoLiBBZnRl ciByZW1vdmluZyBlcG9jaCB3ZSBjYW4gbWFuZGF0ZSB0aGF0ICBib3RoIGVudGl0eSBzaG91bGQg bm90IHN0YXJ0IHJlbmVnb3RpYXRpb24uIFNhbXBsZSBkZXNpZ24gZm9yIG5ldyByZWNvcmQgaGVh ZGVyIHdpdGggQ0lEIGlzIG1lbnRpb25lZCBiZWxvdw0KICAgIHN0cnVjdCB7DQogICAgICAgIHVp bnQ4X3QgQ29udGVudFR5cGU7DQogICAgICAgIHVpbnQ4X3QgQ0lEX2xlbjsNCiAgICAgICAgQ0lE IGNpZDsgICAgICAgIC8qIExlbmd0aCB2YXJpZXMgZnJvbSA0IHRvIDggKG9yIDE2KSAqLw0KICAg ICAgICB1aW50NDggc2VxdWVuY2VfbnVtYmVyOw0KICAgICAgICB1aW50MTZfdCByZWNvcmRfbGVu Z3RoOw0KICAgIH0gRFRMU1JlY29yZEhlYWRlcjsNCiAgICBvcGFxdWUgQ0lEIDw0Li44PjsNCg0K ICAgIHN0cnVjdCB7DQogICAgICAgIHVpbnQ4X3QgQ29udGVudFR5cGU7DQogICAgICAgIHVpbnQ4 X3QgQ0lEX2xlbjsNCiAgICAgICAgQ0lEIGNpZDsgICAgICAgIC8qIExlbmd0aCB2YXJpZXMgZnJv bSA0IHRvIDggKG9yIDE2KSAqLw0KICAgICAgICB1aW50MTZfdCByZWNvcmRfbGVuZ3RoOw0KICAg IH0gVExTUmVjb3JkSGVhZGVyOw0KICAgIG9wYXF1ZSBDSUQgPDQuLjg+Ow0KDQo0KSBBbm90aGVy IG9wdGlvbiBpcyB3ZSBjYW4ga2VlcCBDSURfbGVuIGFzIDQgYml0IHRvIHJlcHJlc2VudCBhIENJ RCBvZiBzaXplLiBBbmQgdGhpcyA0IGJpdCBjYW4gYmUgcGxhY2VkIGluIHRoZSBNU0Igb2YgdGhl IENJRCBmaWVsZC4NCiAgICAgICAgLi4uLg0KICAgICAgICB1aW50OF90IENJRF9sZW46NDsNCiAg ICAgICAgQ0lEIGNpZDsgICAgICAgIC8qIExlbmd0aCB2YXJpZXMgZnJvbSAyOGJpdCB0byA2MCBi aXQgKG9yIDEyNGJpdCkgKi8NCiAgICAgICAgLi4uLg0KDQo1KSBTZWN0aW9uIDMuMSBhbmQgMy4y IHRhbGtzIGFib3V0IHRoZSBuZXcgZXh0ZW5zaW9ucyBmb3IgbmVnb3RpYXRpbmcgdGhpcyBmZWF0 dXJlIHN1cHBvcnQuIEJ1dCBJIGZlZWwgbm8gbmVlZCBvZiBuZXcgZXh0ZW5zaW9ucyB0byBuZWdv dGlhdGUgdGhpcywgd2UgY2FuIG1ha2UgY2xpZW50IHRvIGFkZCBuZXcgU0NTViBjaXBoZXIgaW4g aXRzIGNpcGhlciBsaXN0LiBJZiBzZXJ2ZXIgYWNjZXB0cyB0aGVuIGFmdGVyIGhhbmRzaGFrZSB0 aGUgZmlyc3QgYXBwbGljYXRpb24gZGF0YSBzZW5kIGJ5IHNlcnZlciBzaG91bGQgYmUgb2YgdHlw ZSBhcHBsaWNhdGlvbl9kYXRhX3dpdGhfY2lkKDI1KSwgd2hpY2ggc2hvdWxkIGhvbGQgdGhlIG5l dyByZWNvcmQgaGVhZGVyIHdpdGggQ0lELiBUaGUgc2FtZSBDSUQgc2hvdWxkIGJlIHVzZWQgYnkg Y2xpZW50IGluIHRoZSBmdXJ0aGVyIG1lc3Nhc2dlLiBJZiBjbGllbnQgc2VuZHMgdGhlIDFzdCBh cHBsaWNhdGlvbiBkYXRhIGFmdGVyIGhhbmRzaGFrZSwgdGhlbiBpdCBjYW4gc2VuZCBhcHBsaWNh dGlvbiBkYXRhIHdpdGggZGVmYXVsdCByZWNvcmQgdHlwZSAoYXBwbGljYXRpb25fZGF0YSgyMykp LiBJZiB0aGUgZmlyc3QgYXBwbGljYXRpb24gZGF0YSByZWNvcmQgcmVjZWl2ZWQgZnJvbSBzZXJ2 ZXIgaXMgbm90IG9mIGFwcGxpY2F0aW9uX2RhdGFfd2l0aF9jaWQoMjUpIG1lYW5zIGNsaWVudCBz aG91bGQgdW5kZXJzdGFuZCB0aGF0IHNlcnZlciBoYXMgbm90IGFjY2VwdGVkIHRoZSBTQ1NWIHBy b3Bvc2VkLiBBbmQgY2xpZW50IHNob3VsZCBjb250aW51ZSBhcHAgdHJhbnNmZXIgd2l0aCBkZWZh dWx0IHJlY29yZCB0eXBlIChhcHBsaWNhdGlvbl9kYXRhKDIzKSkuDQoNClt0Zl0gV2hhdCBpcyB0 aGUgcHJvYmxlbSB3aXRoIHVzaW5nIGEgbmV3IGV4dGVuc2lvbj8gIEhvdyB3b3VsZCBuZWdvdGlh dGluZyBwYXJhbWV0ZXJzIChlLmcuLCBDSUQgdHlwZSwgQ0lEIGxlbmd0aCkgd29yayBpbiB5b3Vy IHByb3Bvc2FsPw0KDQpQbGVhc2UgcHJvdmlkZSB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgc3VnZ2Vz dGlvbi4NCg0KUmVnYXJkcywNCkFzaG9rDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCltvbXBhbnlfbG9nb10NCg0KUmFqYSBBc2hvayBWIEsNCkh1YXdlaSBUZWNobm9sb2dp ZXMNCkJhbmdhbG9yZSwgSW5kaWENCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWF rOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWI l+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgQ0K5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V 5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy 44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu25LitDQrnmoTkv6Hmga/jgILlpoLmnpzm gqjplJnmlLbkuobmnKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xl j5Hku7bkurrlubbliKDpmaTmnKzpgq7ku7bvvIENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNo bWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNo DQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNz IGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBo ZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9y IHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkg cGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0 ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoN Cg== --_000_AD171715BB734B9DA85F70499C961415nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFn cmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 Q2FsaWJyaTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjgiLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEFzaG9rLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgdmVyeSBtdWNoIGZv ciB5b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVlcnMsIHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ T24gMDcvMDcvMjAxNywgMTQ6NDQsICZxdW90O1JhamEgYXNob2smcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpyYWphLmFzaG9rQGh1YXdlaS5jb20iPnJhamEuYXNob2tAaHVhd2VpLmNvbTwvYT4m Z3Q7IHdyb3RlOjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSBOaWtvcywgSGFu bmVzICZhbXA7IFRob21hcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhpcyBDb25uZWN0aW9uSUQg Y29uY2VwdCBpcyByZWFsbHkgYSB1c2VmdWwgZmVhdHVyZSBmb3IgYSBjbGllbnQgbm9kZSB3aGlj aCBmYWNlcyBhIGNoYW5nZSBpbiB0cmFuc3BvcnQgYW5kIG5ldHdvcmsgbGF5ZXIuIEkgYW0gaGF2 aW5nIGZldyBzdWdnZXN0aW9ucyBpbiB0aGUgcHJvcG9zZWQgZHJhZnQsIHdoaWNoIGFyZSBsaXN0 ZWQgYmVsb3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjEpIEluIHNlY3Rpb24gMyBvZiB0aGlzIGRy YWZ0LCBleHBsYWlucyBhYm91dCB0aGUgbW9kaWZpY2F0aW9uIGluICZxdW90O0RUTFNDaXBoZXJ0 ZXh0JnF1b3Q7IHN0cnVjdHVyZS4gSSBmZWVsIGluc3RlYWQgb2YgbW9kaWZ5aW5nIGV4aXN0aW5n IERUTFMgYW5kIFRMUyByZWNvcmQgaGVhZGVyLCB3ZSBjYW4gZGlyZWN0bHkgaW50cm9kdWNlIGEg bmV3IHJlY29yZCB0eXBlIChDb250ZW50VHlwZSkNCiBmb3IgYXBwIGRhdGEgKGFwcGxpY2F0aW9u X2RhdGFfd2l0aF9jaWQoMjUpKS4gPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bdGZdIFdoeSBkbyB5b3UgdGhpbmsg YSBuZXcgcmVjb3JkIHR5cGUgd291bGQgYmUgYmV0dGVyIHRoYW4gdGhlIHByZXNlbnQgY29uc3Ry dWN0aW9uPyZuYnNwOyAoQlRXLCB3ZSB3b3VsZCBhbHNvIG5lZWQgYSBuZXcgYWxlcnRfd2l0aF9j aWQsIEkgZ3Vlc3MuKTwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Rm9y IHRoaXMgbmV3IHJlY29yZCB0eXBlLCB3ZSBjYW4gcHJvcG9zZSBhIG1vZGlmaWVkIHJlY29yZCBo ZWFkZXIgZm9yIGJvdGggVExTIGFuZCBEVExTLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3RmXSBJZiB5b3UgYXJl IGFscmVhZHkgbW9kaWZ5aW5nIHRoZSByZWNvcmQgaGVhZGVyLCBJIGFtIG5vdCBzdXJlIHdoeSB5 b3UgYWxzbyBuZWVkIHRvIGFkZCBuZXcgY29udGVudCB0eXBlKHMpPzwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+MikgTW9yZSBvdmVyIHNlY3Rpb24gMyBzYXlzIG1vZGlm aWNhdGlvbiBvbmx5IGluICZxdW90O0RUTFNDaXBoZXJ0ZXh0JnF1b3Q7LCBub3QgZm9yICZxdW90 O1RMU0NpcGhlcnRleHQmcXVvdDsuIEkgaG9wZSB0aGlzIENJRCBtZWNoYW5pc20gc2hvdWxkIGJl IHVzZWQgZm9yIGJvdGggVExTIGFuZCBEVExTLiBCZWNhdXNlIHRoaXMgdHJhbnNwb3J0IGxheWVy IGNoYW5nZSBwcm9ibGVtIGlzIHRoZXJlDQogZm9yIFRMUyBiYXNlZCBhcHBsaWNhdGlvbnMgKEhU VFBTKSBhbHNvIGluIFNtYXJ0cGhvbmUod2hlbiBpdCBzd2l0Y2hlcyBmcm9tIFdpZmkgdG8gTFRF KS4gQnV0IHRoaXMgVExTIGFwcGxpY2F0aW9uIHByb2JsZW0gaXMgc29sdmVkIGJ5IE1QVENQLCBi dXQgSSBkb250IHRoaW5rIGFsbCB3ZWJzZXJ2ZXJzIGFyZSBzdXBwb3J0aW5nIHRoaXMgTVBUQ1Au IFNvIEkgZmVlbCBDSUQgaXMgcmVxdWlyZWQgZm9yIGJvdGggVExTIGFuZCBEVExTLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bdGZdIEluIHByaW5jaXBsZSBJ4oCZbSBub3Qgb3Bwb3NlZCB0byBv cGVuIHRoZSBzb2x1dGlvbiBzcGFjZSB0byBUTFMsIGJ1dCB3ZSBuZWVkIHRvIHdvcmsgb3V0IHRo ZSBpbXBsaWNhdGlvbnMuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4z KSBBcyBwYXJ0IG9mIGRlZmluaW5nIG5ldyByZWNvcmQgdHlwZSwgd2UgY2FuIHJlbW92ZSBzb21l IHVudXNlZCBmaWVsZHMgbGlrZSB2ZXJzaW9uLCBlcG9jaC4gQWZ0ZXIgcmVtb3ZpbmcgZXBvY2gg d2UgY2FuIG1hbmRhdGUgdGhhdCAmbmJzcDtib3RoIGVudGl0eSBzaG91bGQgbm90IHN0YXJ0IHJl bmVnb3RpYXRpb24uIFNhbXBsZSBkZXNpZ24gZm9yIG5ldyByZWNvcmQNCiBoZWFkZXIgd2l0aCBD SUQgaXMgbWVudGlvbmVkIGJlbG93PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cnVjdCB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1 aW50OF90IENvbnRlbnRUeXBlOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDhfdCBD SURfbGVuOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0lEIGNpZDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyogTGVuZ3RoIHZhcmllcyBmcm9tIDQgdG8g OCAob3IgMTYpICovPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50NDggc2VxdWVuY2Vf bnVtYmVyOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDE2X3QgcmVjb3JkX2xlbmd0 aDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IH0gRFRMU1JlY29yZEhlYWRlcjs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wYXF1ZSBDSUQgJmx0OzQuLjgmZ3Q7Ozwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyBzdHJ1Y3Qgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWlu dDhfdCBDb250ZW50VHlwZTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4X3QgQ0lE X2xlbjs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENJRCBjaWQ7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8qIExlbmd0aCB2YXJpZXMgZnJvbSA0IHRvIDgg KG9yIDE2KSAqLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDE2X3QgcmVjb3JkX2xl bmd0aDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IH0gVExTUmVjb3JkSGVhZGVyOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgb3BhcXVlIENJRCAmbHQ7NC4uOCZndDs7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij40KSBBbm90aGVyIG9wdGlvbiBpcyB3ZSBjYW4g a2VlcCBDSURfbGVuIGFzIDQgYml0IHRvIHJlcHJlc2VudCBhIENJRCBvZiBzaXplLiBBbmQgdGhp cyA0IGJpdCBjYW4gYmUgcGxhY2VkIGluIHRoZSBNU0Igb2YgdGhlIENJRCBmaWVsZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLi4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDhfdCBD SURfbGVuOjQ7Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q0lEIGNp ZDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyogTGVuZ3RoIHZh cmllcyBmcm9tIDI4Yml0IHRvIDYwIGJpdCAob3IgMTI0Yml0KSAqLzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLi4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+NSkgU2VjdGlvbiAz LjEgYW5kIDMuMiB0YWxrcyBhYm91dCB0aGUgbmV3IGV4dGVuc2lvbnMgZm9yIG5lZ290aWF0aW5n IHRoaXMgZmVhdHVyZSBzdXBwb3J0LiBCdXQgSSBmZWVsIG5vIG5lZWQgb2YgbmV3IGV4dGVuc2lv bnMgdG8gbmVnb3RpYXRlIHRoaXMsIHdlIGNhbiBtYWtlIGNsaWVudCB0byBhZGQgbmV3IFNDU1Yg Y2lwaGVyIGluIGl0cyBjaXBoZXIgbGlzdC4NCiBJZiBzZXJ2ZXIgYWNjZXB0cyB0aGVuIGFmdGVy IGhhbmRzaGFrZSB0aGUgZmlyc3QgYXBwbGljYXRpb24gZGF0YSBzZW5kIGJ5IHNlcnZlciBzaG91 bGQgYmUgb2YgdHlwZSBhcHBsaWNhdGlvbl9kYXRhX3dpdGhfY2lkKDI1KSwgd2hpY2ggc2hvdWxk IGhvbGQgdGhlIG5ldyByZWNvcmQgaGVhZGVyIHdpdGggQ0lELiBUaGUgc2FtZSBDSUQgc2hvdWxk IGJlIHVzZWQgYnkgY2xpZW50IGluIHRoZSBmdXJ0aGVyIG1lc3Nhc2dlLiBJZiBjbGllbnQgc2Vu ZHMNCiB0aGUgMXN0IGFwcGxpY2F0aW9uIGRhdGEgYWZ0ZXIgaGFuZHNoYWtlLCB0aGVuIGl0IGNh biBzZW5kIGFwcGxpY2F0aW9uIGRhdGEgd2l0aCBkZWZhdWx0IHJlY29yZCB0eXBlIChhcHBsaWNh dGlvbl9kYXRhKDIzKSkuIElmIHRoZSBmaXJzdCBhcHBsaWNhdGlvbiBkYXRhIHJlY29yZCByZWNl aXZlZCBmcm9tIHNlcnZlciBpcyBub3Qgb2YgYXBwbGljYXRpb25fZGF0YV93aXRoX2NpZCgyNSkg bWVhbnMgY2xpZW50IHNob3VsZCB1bmRlcnN0YW5kIHRoYXQNCiBzZXJ2ZXIgaGFzIG5vdCBhY2Nl cHRlZCB0aGUgU0NTViBwcm9wb3NlZC4gQW5kIGNsaWVudCBzaG91bGQgY29udGludWUgYXBwIHRy YW5zZmVyIHdpdGggZGVmYXVsdCByZWNvcmQgdHlwZSAoYXBwbGljYXRpb25fZGF0YSgyMykpLjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3RmXSBXaGF0IGlzIHRoZSBw cm9ibGVtIHdpdGggdXNpbmcgYSBuZXcgZXh0ZW5zaW9uPyZuYnNwOyBIb3cgd291bGQgbmVnb3Rp YXRpbmcgcGFyYW1ldGVycyAoZS5nLiwgQ0lEIHR5cGUsIENJRCBsZW5ndGgpIHdvcmsgaW4geW91 ciBwcm9wb3NhbD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+UGxlYXNlIHByb3ZpZGUgeW91ciBjb21t ZW50cyBvbiB0aGlzIHN1Z2dlc3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJlZ2FyZHMsPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5Bc2hvazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWdu PSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGV0eXBlIGlkPSJfeDAwMDBfdDc1 IiBjb29yZHNpemU9IjIxNjAwLDIxNjAwIiBvOnNwdD0iNzUiIG86cHJlZmVycmVsYXRpdmU9InQi IHBhdGg9Im1ANEA1bEA0QDExQDlAMTFAOUA1eGUiIGZpbGxlZD0iZiIgc3Ryb2tlZD0iZiI+DQo8 djpzdHJva2Ugam9pbnN0eWxlPSJtaXRlciIvPg0KPHY6Zm9ybXVsYXM+DQo8djpmIGVxbj0iaWYg bGluZURyYXduIHBpeGVsTGluZVdpZHRoIDAiLz4NCjx2OmYgZXFuPSJzdW0gQDAgMSAwIi8+DQo8 djpmIGVxbj0ic3VtIDAgMCBAMSIvPg0KPHY6ZiBlcW49InByb2QgQDIgMSAyIi8+DQo8djpmIGVx bj0icHJvZCBAMyAyMTYwMCBwaXhlbFdpZHRoIi8+DQo8djpmIGVxbj0icHJvZCBAMyAyMTYwMCBw aXhlbEhlaWdodCIvPg0KPHY6ZiBlcW49InN1bSBAMCAwIDEiLz4NCjx2OmYgZXFuPSJwcm9kIEA2 IDEgMiIvPg0KPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxXaWR0aCIvPg0KPHY6ZiBlcW49 InN1bSBAOCAyMTYwMCAwIi8+DQo8djpmIGVxbj0icHJvZCBANyAyMTYwMCBwaXhlbEhlaWdodCIv Pg0KPHY6ZiBlcW49InN1bSBAMTAgMjE2MDAgMCIvPg0KPC92OmZvcm11bGFzPg0KPHY6cGF0aCBv OmV4dHJ1c2lvbm9rPSJmIiBncmFkaWVudHNoYXBlb2s9InQiIG86Y29ubmVjdHR5cGU9InJlY3Qi Lz4NCjxvOmxvY2sgdjpleHQ9ImVkaXQiIGFzcGVjdHJhdGlvPSJ0Ii8+DQo8L3Y6c2hhcGV0eXBl Pjx2OnNoYXBlIGlkPSJfeDAwMDBfczEwMjYiIHR5cGU9IiNfeDAwMDBfdDc1IiBhbHQ9Im9tcGFu eV9sb2dvIiBzdHlsZT0ncG9zaXRpb246YWJzb2x1dGU7bGVmdDowO3RleHQtYWxpZ246bGVmdDtt YXJnaW4tbGVmdDowO21hcmdpbi10b3A6MDt3aWR0aDo3Ni41cHQ7aGVpZ2h0OjI0cHQ7ei1pbmRl eDoyNTE2NTgyNDA7bXNvLXdyYXAtZGlzdGFuY2UtbGVmdDowO21zby13cmFwLWRpc3RhbmNlLXRv cDowO21zby13cmFwLWRpc3RhbmNlLXJpZ2h0OjA7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7 bXNvLXBvc2l0aW9uLWhvcml6b250YWw6bGVmdDttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxh dGl2ZTp0ZXh0O21zby1wb3NpdGlvbi12ZXJ0aWNhbC1yZWxhdGl2ZTpsaW5lJyBvOmFsbG93b3Zl cmxhcD0iZiI+DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDJGNzVCLkRF Njg1NUYwIiBvOnRpdGxlPSJpbWFnZTAwMS5qcGdAMDFEMkY3NTUuNDgzQjkxQjAiLz4NCjx3Ondy YXAgdHlwZT0ic3F1YXJlIi8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYgIXZtbF0+PGlt ZyB3aWR0aD0iMTAyIiBoZWlnaHQ9IjMyIiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEMkY3NUIu REU2ODU1RjAiIGFsaWduPSJsZWZ0IiBhbHQ9Im9tcGFueV9sb2dvIiB2OnNoYXBlcz0iX3gwMDAw X3MxMDI2Ij48IVtlbmRpZl0+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM1OTU5NTki PlJhamEgQXNob2sgViBLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OiM1OTU5NTkiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzU5NTk1OSI+SHVhd2Vp IFRlY2hub2xvZ2llczxicj4NCkJhbmdhbG9yZSwgSW5kaWE8YnI+DQpodHRwOi8vd3d3Lmh1YXdl aS5jb20gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtYWxpZ246Y2VudGVyIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+DQo8aHIg c2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i WkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmdy YXk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+ac ieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWc sOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij48YnI+ DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk65a6L5L2TO2NvbG9yOmdyYXk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuatouS7 u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8iOWMheaLrOS9huS4jemZkOS6juWF qOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaIluaVo+WPke+8ieacrOmCruS7tuS4 rTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7 hum7kTtjb2xvcjpncmF5Ij48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmdyYXk7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPueahOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8 jOivt+aCqOeri+WNs+eUteivneaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmC ruS7tu+8gTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWN juaWh+e7hum7kTtjb2xvcjpncmF5Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpncmF5Ij5UaGlzIGUtbWFpbCBhbmQgaXRz IGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJ LCB3aGljaA0KPGJyPg0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkg d2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQo8YnI+DQppbmZv cm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBs aW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQo8YnI+DQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rp b24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQg PGJyPg0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1t YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCjxicj4NCnBob25lIG9y IGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AD171715BB734B9DA85F70499C961415nokiacom_-- --_004_AD171715BB734B9DA85F70499C961415nokiacom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6738; creation-date="Fri, 07 Jul 2017 19:01:48 GMT"; modification-date="Fri, 07 Jul 2017 19:01:48 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9kA --_004_AD171715BB734B9DA85F70499C961415nokiacom_-- From nobody Fri Jul 7 12:13:53 2017 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 6C1DD12ECBF for ; Fri, 7 Jul 2017 12:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-YKvLnlRmFj for ; Fri, 7 Jul 2017 12:13:50 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 51E8412EB8C for ; Fri, 7 Jul 2017 12:13:50 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 32so34793439qtv.1 for ; Fri, 07 Jul 2017 12:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BCCrdpxRDwRnDSFYDkAMfIOJlNRVPqHoLSce5/wkR1s=; b=bQz04A7H98pp8/64rX9O48LybEcMrf4mLTKBiCfFWOmcOcIKM3hBhGycwqugrqmGbR oYwhjqpCBIcuubo6XACARUDeFeLZfGCwV4rb1m6Wl7jz15EKEDm3u94BzlxXT/pRK8js 64LofM3ZQjrdgx58M0STpgq8Tt58+8I1mMyt0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BCCrdpxRDwRnDSFYDkAMfIOJlNRVPqHoLSce5/wkR1s=; b=EUlGlKTf/yxAJZq7Y2Adc8SJq9XapPbZ9/LUZz3BAptF/H38gO/KJkCpWKa+ZwheIZ aPLIpJpGHwCk9ZvceWwkfpO7/WzGNLO5uy0IcAqCCGTOj5M3eCnfY+kljqPn3uDBWkbc sIVSgMhJ3wvaaX2zNZYpXaABwqwQIu9AXdRiJ4wUOkVTmCoGMPMsyfOfam5c71gPHLox 1Bi1kMX+OjshPNwEv2VhO7SdDK8K1sclfBGEKv7pYg4Xfa377NmCRgMFNrG/xpnSk+xS Z2m9+YzafoIacugPUu+K0OhZGP0DxGxFKLu9aOJKe2HvdHsESPG/UrDguuUQOoAJ9Rzj KNEA== X-Gm-Message-State: AIVw1124cparNqVnryMFj7gbcYbq5RNC5QC3HbWG48g6ZT0Y2Lof+yZ5 CSLHMCMi2e53ARxs0kndPOqaTtZETXJ9JbUjCA== X-Received: by 10.237.46.166 with SMTP id k35mr9765034qtd.21.1499454829293; Fri, 07 Jul 2017 12:13:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.84.229 with HTTP; Fri, 7 Jul 2017 12:13:28 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Fri, 7 Jul 2017 14:13:28 -0500 Message-ID: To: Joseph Salowey Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 19:13:52 -0000 As a note, I didn't see anything in this draft (from a quick read) that precludes any of DANE's Certificate Usage, Selector, or Matching Type fields. If that's not the case, perhaps someone can correct me. A client must not be able to force a server to perform lookups on arbitrary domain names using this mechanism. Therefore, a server MUST NOT construct chains for domain names other than its own. What about the reverse? Do we care about a server tricking a client into priming its DNS cache? -tom On 28 June 2017 at 16:15, Joseph Salowey wrote: > This is the working group last call for > draft-ietf-tls-dnssec-chain-extension-04. Please send you comments to the > list by July 12, 2017. > > Thanks, > > J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Jul 7 12:40:09 2017 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 279841300CF for ; Fri, 7 Jul 2017 12:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 YI6z7YF1jvBX for ; Fri, 7 Jul 2017 12:40:06 -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 53E55127337 for ; Fri, 7 Jul 2017 12:40:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8EF2D300563 for ; Fri, 7 Jul 2017 15:40:05 -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 ES1qjDLqp8wc for ; Fri, 7 Jul 2017 15:40:04 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 740B6300466; Fri, 7 Jul 2017 15:40:04 -0400 (EDT) From: Russ Housley Message-Id: <6F5C1F62-2A47-4BE7-AEA6-A8BAE56EDA08@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1D5D866F-1942-4BE8-AD80-5B59C8C26A3F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Jul 2017 15:40:03 -0400 In-Reply-To: <20170707161525.ayv4z4olmo4r3h73@LK-Perkele-VII> Cc: IETF TLS To: Ilari Liusvaara , Rich Salz References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> <201707062201.08455.davemgarrett@gmail.com> <5af19fe7273748579cb2537313667aba@usma1ex-dag1mb1.msg.corp.akamai.com> <20170707161525.ayv4z4olmo4r3h73@LK-Perkele-VII> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 19:40:08 -0000 --Apple-Mail=_1D5D866F-1942-4BE8-AD80-5B59C8C26A3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > - PFS or pure-PSK only. >=20 > Small things can't do PFS unfortunately. The TLS WG wants to work on a a way to combine a PSK with (EC)DH after = the current specification is finished for quantum protection. Of = course, that PSK must be distributed without any public-key crypto or it = will not provide any quantum protection. Russ --Apple-Mail=_1D5D866F-1942-4BE8-AD80-5B59C8C26A3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
- PFS or pure-PSK = only.

Small things can't do PFS = unfortunately.

The TLS WG wants to work on a a way to combine a = PSK with (EC)DH after the current specification is finished for quantum = protection.  Of course, that PSK must be distributed without any = public-key crypto or it will not provide any quantum = protection.

Russ

= --Apple-Mail=_1D5D866F-1942-4BE8-AD80-5B59C8C26A3F-- From nobody Fri Jul 7 12:52:07 2017 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 3C3B9131552 for ; Fri, 7 Jul 2017 12:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Dn4AWf_KkPVj for ; Fri, 7 Jul 2017 12:52:02 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6242A12EBF9 for ; Fri, 7 Jul 2017 12:52:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 034E420B14; Fri, 7 Jul 2017 22:52:00 +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 i8sorZYXz0yw; Fri, 7 Jul 2017 22:51:59 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id A35F22315; Fri, 7 Jul 2017 22:51:56 +0300 (EEST) Date: Fri, 7 Jul 2017 22:51:55 +0300 From: Ilari Liusvaara To: Russ Housley Cc: Rich Salz , IETF TLS Message-ID: <20170707195155.ks4ntmolvph77iy3@LK-Perkele-VII> References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> <201707062201.08455.davemgarrett@gmail.com> <5af19fe7273748579cb2537313667aba@usma1ex-dag1mb1.msg.corp.akamai.com> <20170707161525.ayv4z4olmo4r3h73@LK-Perkele-VII> <6F5C1F62-2A47-4BE7-AEA6-A8BAE56EDA08@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6F5C1F62-2A47-4BE7-AEA6-A8BAE56EDA08@vigilsec.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 19:52:05 -0000 On Fri, Jul 07, 2017 at 03:40:03PM -0400, Russ Housley wrote: > > - PFS or pure-PSK only. > > > > Small things can't do PFS unfortunately. > > The TLS WG wants to work on a a way to combine a PSK with (EC)DH > after the current specification is finished for quantum protection. Well, PSK with DH does provode classical PFS. And did you perhaps mean using PSK with DH and certificates? Because both TLS 1.2 and TLS 1.3 can combine PSK with DH, but not all three of PSK, DH and certificate all at once. -Ilari From nobody Fri Jul 7 13:01:56 2017 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 8DED512EC49 for ; Fri, 7 Jul 2017 13:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6SmhERhEGIsZ for ; Fri, 7 Jul 2017 13:01:54 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 144E612EC1B for ; Fri, 7 Jul 2017 13:01:54 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id g40so26387182uaa.3 for ; Fri, 07 Jul 2017 13:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DlwQ3UoOxg7stl+Ra0pb3JoxKgy2pDPHvFFISsoAZrw=; b=AF6x/nzfJEZPdBBwo/vsuex0uJkkVXBnE8Q0itMjSiaGY0nh4KcsmM1uCJ4D30vyhZ cOv5Y+s7pUekV5TRbBapGI8lZkPXsxg6nHuYh2i59MHPENwN6mLYxTqyX3mx7dlYQId1 pc1Q2J2qbeBHvXzbPdDnatlTDb6bH+hUq5RshDeQD9phOhoxOeKVOPblZXuI6J+smpR3 GfHzklJVhM4mm3ZM/AUF8xP/0iXJ95DK8JiFe6sj2ZfQNclAXCtNy/QVVKmfabr+cD4u qd9f4ErS//90tj0qUBgSZbcoD+L5MR5NSc3IDN0BucE1apA/90XdEtpXrMTolVsuo6Vp W0hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DlwQ3UoOxg7stl+Ra0pb3JoxKgy2pDPHvFFISsoAZrw=; b=LYVajCuffmBKtZxoje/S3namxcsSYpv22vV77ET6qUwDcQ741pfh/xfOBTkqdh4MZy gjHJ1JXbVagtkboUqf6NK87L6DN2dyoCQ4AMZhdIM6c2/lg+SYgVVRhf+HeT3chuuwX+ lhVP7FsSJ4E08AhsHG1QsbJurO3L0/Hg+GjZaTN5UO8DIU509Wd1sZIhT8fiCm3dtBxR B153wJmYvv4uRwgxXEcIS0ZHxMZMMzrR6aY7KkrvddWHGHmArjdwp5YTBTOM+4NfhUQV wwAe9uafkuzRkLeB59rjHuBrNPbVAJJVwJ7iLIi7GmeBH1b7Wh59ZYyQ1d/7hMvmXb/E J8kw== X-Gm-Message-State: AIVw111TyyM8ekUkcIQ8+fwlwccrdGQtFvtKSVkoZI6pyIB3rMXhQiJr DbvjbxoTtEcwB9OkjIFLGqa2QEkjcxuk X-Received: by 10.176.93.2 with SMTP id u2mr1756785uaf.109.1499457713084; Fri, 07 Jul 2017 13:01:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Fri, 7 Jul 2017 13:01:52 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Fri, 7 Jul 2017 16:01:52 -0400 Message-ID: To: Tom Ritter Cc: Joseph Salowey , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f40304362188581d600553bfb459" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 20:01:56 -0000 --f40304362188581d600553bfb459 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 3:13 PM, Tom Ritter wrote: > As a note, I didn't see anything in this draft (from a quick read) > that precludes any of DANE's Certificate Usage, Selector, or Matching > Type fields. If that's not the case, perhaps someone can correct me. > Yes, that's correct. Is there any reason it should? TLS applications are free to preclude the use of DANE parameters, but a more general purpose protocol I feel probably should not. The draft does refer several times to RFC 7671 (DANE updates and operational guidelines), which has some recommendations which ought to be followed. > A client must not be able to force a server to perform lookups on > arbitrary domain names using this mechanism. Therefore, a server > MUST NOT construct chains for domain names other than its own. > > What about the reverse? Do we care about a server tricking a client > into priming its DNS cache? > -tom > Yes, we want to avoid that, but I would expect that any sane client implementation, as a basic precaution, would only accept a DNSSEC chain corresponding to the TLSA name that it expected to see. If the server presented anything else, it would not be considered invalid. Similarly, if the chain included embedded unexpected extraneous records, I would expect the client implementation to ignore those (or even invalidate the whole chain if it wanted to be more draconian). If necessary, we could have explicit text about this. -- Shumon Huque --f40304362188581d600553bfb459 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 3:13 PM, Tom Ritter <tom@ritter.vg> wrote:
As a note, I didn't see anything in thi= s draft (from a quick read)
that precludes any of DANE's Certificate Usage, Selector, or Matching Type fields. If that's not the case, perhaps someone can correct me.

Yes, that's correct. Is there any rea= son it should?=C2=A0

TLS applications are free to = preclude the use of DANE parameters, but a more general purpose protocol I = feel probably should not. The draft does refer several times to RFC 7671 (D= ANE updates and operational guidelines), which has some recommendations whi= ch ought to be followed.
=C2=A0
=C2=A0 =C2=A0A client must not be able to force a server to perform lookups= on
=C2=A0 =C2=A0arbitrary domain names using this mechanism.=C2=A0 Therefore, = a server
=C2=A0 =C2=A0MUST NOT construct chains for domain names other than its own.=

What about the reverse? Do we care about a server tricking a client
into priming its DNS cache?=C2=A0

-tom

Yes, we want to avoi= d that, but I would expect that any sane client implementation, as a basic = precaution, would only accept a DNSSEC chain corresponding to the TLSA name= that it expected to see. If the server presented anything else, it would n= ot be considered invalid. Similarly, if the chain included embedded unexpec= ted extraneous records, I would expect the client implementation to ignore = those (or even invalidate the whole chain if it wanted to be more draconian= ). If necessary, we could have explicit text about this.

--=C2=A0
Shumon Huque

--f40304362188581d600553bfb459-- From nobody Fri Jul 7 13:04:27 2017 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 58560131780 for ; Fri, 7 Jul 2017 13:04:26 -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 BA31mRC2Z71g for ; Fri, 7 Jul 2017 13:04:24 -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 70B4013176E for ; Fri, 7 Jul 2017 13:04:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8476530053F for ; Fri, 7 Jul 2017 16:04:23 -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 FDMO8mvamdD4 for ; Fri, 7 Jul 2017 16:04:21 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A943D300268; Fri, 7 Jul 2017 16:04:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Fri, 7 Jul 2017 16:04:20 -0400 Cc: IETF TLS , Matthew Green Content-Transfer-Encoding: quoted-printable Message-Id: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 20:04:26 -0000 Stephen: > On 07/07/17 19:40, Kyle Rose wrote: >> an informational draft submitted via the ISE >=20 > ...has nothing to to with this WG and ought consume > no cycles on this list or in meetings. >=20 > Yes, the ISE is the route 2804 envisages for documenting > wiretapping schemes such as this. >=20 > The authors of this draft however chose to put "standards > track" in the header and some of those authors are very > very well aware of all the nuances here so that was not > a mistake is my conclusion. So I stand by my statement > that 2804 says no to this. As Kyle quoted, RFC 2804 says that we should be talking about the = design. It seems to me the only way to make this proposal more secure = is to talk about it. And, the TLS WG has the people with the proper = expertise for that discussion. The enterprise wants forward secrecy on the public Internet. Terminating = the TLS session at the load balancer preserves forward secrecy on the = public Internet. We already had a discussion on this list about requiring a fresh = ephemeral DH key for every session. The consensus was not to require = it. I understand that there are already servers that use the same = "ephemeral" DH key for more than one session. I gather that this is = done for performance reasons. =20 The conventions described in draft-green-tls-static-dh-in-tls13-01 for = using non-ephemeral DH keys has no impact on interoperability. = Discussion of that topic could easily go in an Informational RFC. Many = Informational RFCs describe crypto algorithms. On the other hand, the = protocol between the key manager and the server for installing the = non-ephemeral DH key has an impact on interoperability, so it could be = in a standards-track document. In your response, you ignored a fairly significant point in my previous = post. In some industries, there are regulatory requirements that = cannot be met without access to the plaintext. Without some authorized = access mechanism, the enterprise will be forced to use plaintext within = the datacenter. That seems like a worse alternative to me. =46rom my perspective, draft-green-tls-static-dh-in-tls13 is not = advocating outdated crypto, like RC4 or MD5. Instead, it is using = exactly the same crypto algorithms and key sizes as = draft-ietf-tls-tls13. Again, this seems like a much better way forward = than plaintext throughout the datacenter. Russ= From nobody Fri Jul 7 13:18:52 2017 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 A31EB131678 for ; Fri, 7 Jul 2017 13:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxfBaoPO58e1 for ; Fri, 7 Jul 2017 13:18:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A12B124217 for ; Fri, 7 Jul 2017 13:18:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 157CCBDF9; Fri, 7 Jul 2017 21:18:46 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlKf3nkrbrus; Fri, 7 Jul 2017 21:18:44 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AF67DBDD8; Fri, 7 Jul 2017 21:18:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499458724; bh=tmvQ33bSBPGaPaaiSa6V/mC7EcMqneTrJvlR/u3RpvU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=W7qL74k9WJ+BtMQroIRrMiyRwkvkedaa5qNBhrgN8aIl43tZlguErEiR6oscU4GiS lcLrXOUNJ5SO1gwABMpHYIOcYjhZXdeURYplDQSs6ctl2YzjujIaatxTy2WfdoIXJT NunJaq46DtRnv/NlI7ZhOvYnR3NapuyGbSAPwSMc= To: Russ Housley Cc: IETF TLS , Matthew Green References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> Date: Fri, 7 Jul 2017 21:18:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IPKjRPDAT2S3KB3Oh2HWVVadVWeSclrrN" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 20:18:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IPKjRPDAT2S3KB3Oh2HWVVadVWeSclrrN Content-Type: multipart/mixed; boundary="JpDkS5V5H1EpHQeDwuffmOB0C0aCHvtAo"; protected-headers="v1" From: Stephen Farrell To: Russ Housley Cc: IETF TLS , Matthew Green Message-ID: <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> In-Reply-To: --JpDkS5V5H1EpHQeDwuffmOB0C0aCHvtAo Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Russ, You didn't refer to 2804 and the standards track. As an author do you really think this can be on the standards track and yet not obsolete 2804? If you do, then I don't understand that. (And would argue you are holding a counter-factual opinion.) If you do not, then why does the draft say "standards track"? S. PS: I disagree with other assertions below but the above has to come first as we need to know if the authors are or are not asking the IETF to change a major policy. On 07/07/17 21:04, Russ Housley wrote: > Stephen: >=20 >> On 07/07/17 19:40, Kyle Rose wrote: >>> an informational draft submitted via the ISE >> >> ...has nothing to to with this WG and ought consume >> no cycles on this list or in meetings. >> >> Yes, the ISE is the route 2804 envisages for documenting >> wiretapping schemes such as this. >> >> The authors of this draft however chose to put "standards >> track" in the header and some of those authors are very >> very well aware of all the nuances here so that was not >> a mistake is my conclusion. So I stand by my statement >> that 2804 says no to this. >=20 > As Kyle quoted, RFC 2804 says that we should be talking about the desig= n. It seems to me the only way to make this proposal more secure is to t= alk about it. And, the TLS WG has the people with the proper expertise f= or that discussion. >=20 > The enterprise wants forward secrecy on the public Internet. Terminatin= g the TLS session at the load balancer preserves forward secrecy on the p= ublic Internet. >=20 > We already had a discussion on this list about requiring a fresh epheme= ral DH key for every session. The consensus was not to require it. I un= derstand that there are already servers that use the same "ephemeral" DH = key for more than one session. I gather that this is done for performanc= e reasons. =20 >=20 > The conventions described in draft-green-tls-static-dh-in-tls13-01 for = using non-ephemeral DH keys has no impact on interoperability. Discussio= n of that topic could easily go in an Informational RFC. Many Informatio= nal RFCs describe crypto algorithms. On the other hand, the protocol bet= ween the key manager and the server for installing the non-ephemeral DH k= ey has an impact on interoperability, so it could be in a standards-track= document. >=20 > In your response, you ignored a fairly significant point in my previous= post. >=20 > In some industries, there are regulatory requirements that cannot be > met without access to the plaintext. Without some authorized access > mechanism, the enterprise will be forced to use plaintext within the > datacenter. That seems like a worse alternative to me. >=20 > From my perspective, draft-green-tls-static-dh-in-tls13 is not advocati= ng outdated crypto, like RC4 or MD5. Instead, it is using exactly the sa= me crypto algorithms and key sizes as draft-ietf-tls-tls13. Again, this = seems like a much better way forward than plaintext throughout the datace= nter. >=20 > Russ >=20 --JpDkS5V5H1EpHQeDwuffmOB0C0aCHvtAo-- --IPKjRPDAT2S3KB3Oh2HWVVadVWeSclrrN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZX+ykAAoJEC88hzaAX42iNHkH/3h48O5rYbzwCNTGiHHXXJ+X +7/g3mpd4vCMfJy6QtVjeXdQT0yYDZ25JLDbS+o3CwZTRhkioRnFKEb3s4MsQI+p lfnb1+lyVtbsahlDfoczpees7fjhHamGv0O1tcT1CkjuDeIJASXUZ12+WoJeIlcB IH4v/Hqp9v2C5XbCTeI27RRnAlNo/J4vsMTzfkOAPAbBnTbWFcBwP/cAWi25a04R RvPAvGR9hvmghmCkR5oFduqbtCJPsW+AnFeE4ROhfmBRxrJoaxlVyiqMSKpXvwwK pptC/GwWNpJdcquGuueXTuw3eO8knyb3lYxs5tiHc+0UIugrfGxmGe7Vggv6TZ4= =KhxD -----END PGP SIGNATURE----- --IPKjRPDAT2S3KB3Oh2HWVVadVWeSclrrN-- From nobody Fri Jul 7 14:12:43 2017 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 3487D12EC55 for ; Fri, 7 Jul 2017 14:12:42 -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 UebpxIzaQjvg for ; Fri, 7 Jul 2017 14:12:40 -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 BF01A126DC2 for ; Fri, 7 Jul 2017 14:12:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 324DC30043A for ; Fri, 7 Jul 2017 17:12:40 -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 EEAIhTclvOYh for ; Fri, 7 Jul 2017 17:12:39 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0B90C300250; Fri, 7 Jul 2017 17:12:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> Date: Fri, 7 Jul 2017 17:12:38 -0400 Cc: IETF TLS , Matthew Green Content-Transfer-Encoding: quoted-printable Message-Id: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 21:12:42 -0000 Stephen: > You didn't refer to 2804 and the standards track. As an > author do you really think this can be on the standards > track and yet not obsolete 2804? Yes. Section 3 of RFC 2804 offers pretty clear definition of = wiretapping, and that is not what is going on here. In this situation, = all of the parties are part of the same organization, under common key = management. The server must explicitly accept and use the centrally = managed (EC)DH key, so that party is completely aware and, in fact, = enabling the other parties to decrypt the traffic. Russ From nobody Fri Jul 7 14:14:00 2017 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 EC0C6131723 for ; Fri, 7 Jul 2017 14:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=r6Qzb3vs; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=GroJ2apu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqT-0_HbwLvO for ; Fri, 7 Jul 2017 14:13:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217CC1316B4 for ; Fri, 7 Jul 2017 14:13:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 59585923E5 for ; Fri, 7 Jul 2017 17:13:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=dWZcqealD3asHJSgr+rz8ilMK4s=; b=r6Qzb3 vsr8agfec5YHSdj8OdPzX0fRhaXpI+i+OyJJ9arVW0sHbfUJVgg6X1qWTlrDcr6U Bn/BX3ULgV3V5b98e1Mf88Az5Xz/dVTD7vcgo1Ap/9eftI5edXNJtO1bMdptYUR/ 64ksW24T+dBqGZCPfRDvB8GXgFt/iH06//hQg= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5115C923E4 for ; Fri, 7 Jul 2017 17:13:54 -0400 (EDT) Received: from mail-yb0-f177.google.com (unknown [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id D2C42923E3 for ; Fri, 7 Jul 2017 17:13:53 -0400 (EDT) Received: by mail-yb0-f177.google.com with SMTP id f194so14449171yba.3 for ; Fri, 07 Jul 2017 14:13:53 -0700 (PDT) X-Gm-Message-State: AIVw110RdmzzRDeABh4b11nAKTRHMOo2god4r3059HlpJCKR3mccT1c8 +G+Msh+5OY7L62g79cSo6rj0FSdZnA== X-Received: by 10.37.246.18 with SMTP id t18mr6184835ybd.211.1499462033139; Fri, 07 Jul 2017 14:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.60.199 with HTTP; Fri, 7 Jul 2017 14:13:12 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> From: Eric Mill Date: Fri, 7 Jul 2017 17:13:12 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: Stephen Farrell , IETF TLS , Matthew Green Content-Type: multipart/alternative; boundary="f403045da836d6f8ca0553c0b518" X-Pobox-Relay-ID: 2E56198A-6359-11E7-8F0C-61520C78B957-82875391!pb-smtp2.pobox.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=konklone.com; h=mime-version:in-reply-to:references:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=dWZcqealD3asHJSgr+rz8ilMK4s=; b=GroJ2apulm4DQ7sqiVDpHCQCgHaF/WMUvJ2wpboqXMuSA1lm03PZp0vfPZcS8fm+Qp664q5dbhqRoGmypA2IIsHMXxu1cUEUjDNCxwllqUCh5koxB6kf7SLSS6yoruchVFcedveUlOeiGxcLOoLJtnXvdzyHNMeMwwMuBdIjeiY= Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 21:14:00 -0000 --f403045da836d6f8ca0553c0b518 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 4:04 PM, Russ Housley wrote: > > The enterprise wants forward secrecy on the public Internet. Terminating > the TLS session at the load balancer preserves forward secrecy on the > public Internet. > > In your response, you ignored a fairly significant point in my previous > post. > > In some industries, there are regulatory requirements that cannot > be > met without access to the plaintext. Without some authorized > access > mechanism, the enterprise will be forced to use plaintext within > the > datacenter. That seems like a worse alternative to me. > > From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating > outdated crypto, like RC4 or MD5. Instead, it is using exactly the same > crypto algorithms and key sizes as draft-ietf-tls-tls13. Again, this seems > like a much better way forward than plaintext throughout the datacenter. > Your response is also failing to address a very important point, by presenting the choice as either static-key TLS or plaintext. That's clearly not the case -- you can maintain traffic visibility at endpoints within your data center, by forcing traffic through terminating trusted proxies which log the same network traffic data you would get from passive monitoring. You can do that with forward secret TLS today. I'm sure it's not as easy to change your designs to incorporate proxies as it is to just rely on the network monitoring infrastructure you already have in place, but that's not a good enough reason to insist that the TLS WG standardize an RFC which can plainly be used for wiretapping. It's also passing up an opportunity to gain the benefits of forward secret connections within your data center, which should really be a best practice and requirement for any organization managing data that merits strict regulatory oversight. This comes across as asking the IETF to contort itself around its own stated goals so that the enterprise doesn't have to do any heavy lifting to keep up with security trends. As explained so far, this seems like something the TLS WG should reject. -- Eric > > Russ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- konklone.com | @konklone --f403045da836d6f8ca0553c0b518 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 7, 2017 at 4:04 PM, Russ Housley <housley@vigilsec.com<= /a>> wrote:
The enterprise wants forward secrecy on the public Internet. Terminating th= e TLS session at the load balancer preserves forward secrecy on the public = Internet.


In your response, you ignored a fairly significant point in my previous pos= t.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In some industries, there are regulatory requir= ements that cannot be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 met without access to the plaintext.=C2=A0 With= out some authorized access
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanism, the enterprise will be forced to use= plaintext within the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 datacenter.=C2=A0 That seems like a worse alter= native to me.

From my perspective, draft-green-tls-static-dh-in-tls13 is not = advocating outdated crypto, like RC4 or MD5.=C2=A0 Instead, it is using exa= ctly the same crypto algorithms and key sizes as draft-ietf-tls-tls13.=C2= =A0 Again, this seems like a much better way forward than plaintext through= out the datacenter.

Your response is al= so failing to address a very important point, by presenting the choice as e= ither static-key TLS or plaintext. That's clearly not the case -- you c= an maintain traffic visibility at endpoints within your data center, by for= cing traffic through terminating trusted proxies which log the same network= traffic data you would get from passive monitoring. You can do that with f= orward secret TLS today.

I'm sure it's not= as easy to change your designs to incorporate proxies as it is to just rel= y on the network monitoring infrastructure you already have in place, but t= hat's not a good enough reason to insist that the TLS WG standardize an= RFC which can plainly be used for wiretapping.=C2=A0

<= div>It's also passing up an opportunity to gain the benefits of forward= secret connections within your data center, which should really be a best = practice and requirement for any organization managing data that merits str= ict regulatory oversight.


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

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



--
=
--f403045da836d6f8ca0553c0b518-- From nobody Fri Jul 7 14:16:22 2017 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 145E113174C for ; Fri, 7 Jul 2017 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQKZgIPSJadG for ; Fri, 7 Jul 2017 14:16:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998A0131752 for ; Fri, 7 Jul 2017 14:16:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7288ABE2F; Fri, 7 Jul 2017 22:16:16 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_VBGGhUIThL; Fri, 7 Jul 2017 22:16:15 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 431D0BE2C; Fri, 7 Jul 2017 22:16:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499462175; bh=lGp6q7UYed7vvH/L5cukukylqromv0fKbeRHKS9IgzI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=V8NDzeBRHJYPrwORWzF20FqKwyuuOijahjvpDpmt/J2RaUHeQ7ibpVDiZX/8d2/uX LJRJnZySr3PJ+dPCeBFerx+mR1YsZHe7eO3/lm+/ZPVoH3UIDMryvDgu7CVtCCZ64j xEQVvTJkNZgKSknsTDtnPKpJDtrvAIqcAU6tL9U0= To: Russ Housley Cc: IETF TLS , Matthew Green References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> Date: Fri, 7 Jul 2017 22:16:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="64n1VWuT1hGGmQCWB8hoLcuSfVTHhUkh6" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 21:16:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --64n1VWuT1hGGmQCWB8hoLcuSfVTHhUkh6 Content-Type: multipart/mixed; boundary="nVWocohwGuwGbouhCoDOR4SOBFk59fJ08"; protected-headers="v1" From: Stephen Farrell To: Russ Housley Cc: IETF TLS , Matthew Green Message-ID: <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> In-Reply-To: --nVWocohwGuwGbouhCoDOR4SOBFk59fJ08 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 07/07/17 22:12, Russ Housley wrote: > Stephen: >=20 >> You didn't refer to 2804 and the standards track. As an author do >> you really think this can be on the standards track and yet not >> obsolete 2804? >=20 > Yes.=20 We disagree. > Section 3 of RFC 2804 offers pretty clear definition of > wiretapping, and that is not what is going on here. In this > situation, all of the parties are part of the same organization, > under common key management. =20 That is one possible deployment. There is nothing in this proposal that limits it's use to that. > The server must explicitly accept and > use the centrally managed (EC)DH key, so that party is completely > aware and, in fact, enabling the other parties to decrypt the > traffic. Yes, and the server could equally be compelled to do that, in which case this technology would clearly be a standard form of wiretapping. Claiming that is not the case would be incredible so I have no idea how you maintain that this isn't in conflict with 2804. S. >=20 > Russ >=20 >=20 --nVWocohwGuwGbouhCoDOR4SOBFk59fJ08-- --64n1VWuT1hGGmQCWB8hoLcuSfVTHhUkh6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZX/oeAAoJEC88hzaAX42iWnUIAKpHMCvIjWJnD8FW8owiyfo2 u5NcDEGwcsWbhsCSVfFhixKhjoYfeNixKrOZkBlDu0zrlIf+qoTickqLD3YSSjti +VszbaKaF8NmZri3DkNvjHob+Il45CoyblGbROaibuopZPssh20Hn7WqOKJXh74w itm3P1oaHGbi0qcf9x0l02LTrMIuOMQiuI2gS5epLVlvSHRE6jcP6PVPZoOIsdde VN/q8qIbnVjPfbjOddNV/P8nbSR1lpprdJZ2KVhNhJkDOzQVUZNp3+FDGJBur0yO MGyFdnDQHazwjamUc02quirt6oTz9+4ic2IhPP27dbqq78hmR5VoNgVgnnUPbyM= =l9ww -----END PGP SIGNATURE----- --64n1VWuT1hGGmQCWB8hoLcuSfVTHhUkh6-- From nobody Fri Jul 7 14:38:42 2017 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 9B30813163D for ; Fri, 7 Jul 2017 14:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Nysx5icId2je for ; Fri, 7 Jul 2017 14:38:39 -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 01AA412EB8E for ; Fri, 7 Jul 2017 14:38:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5F4F0300563 for ; Fri, 7 Jul 2017 17:38:38 -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 Es_-gKaia8dd for ; Fri, 7 Jul 2017 17:38:37 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D8DC2300250; Fri, 7 Jul 2017 17:38:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> Date: Fri, 7 Jul 2017 17:38:36 -0400 Cc: IETF TLS , Matthew Green Content-Transfer-Encoding: quoted-printable Message-Id: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 21:38:40 -0000 Stephen: >>> You didn't refer to 2804 and the standards track. As an author do >>> you really think this can be on the standards track and yet not >>> obsolete 2804? >>=20 >> Yes.=20 >=20 > We disagree. >=20 >> Section 3 of RFC 2804 offers pretty clear definition of >> wiretapping, and that is not what is going on here. In this >> situation, all of the parties are part of the same organization, >> under common key management. =20 >=20 > That is one possible deployment. There is nothing in this > proposal that limits it's use to that. >=20 >> The server must explicitly accept and >> use the centrally managed (EC)DH key, so that party is completely >> aware and, in fact, enabling the other parties to decrypt the >> traffic. >=20 > Yes, and the server could equally be compelled to do that, > in which case this technology would clearly be a standard > form of wiretapping. >=20 > Claiming that is not the case would be incredible so I have > no idea how you maintain that this isn't in conflict with > 2804. That does not follow the definition in Section 3 of RFC 2804. If one of = the parties is "compelled" to install the centrally managed (EC)DH key, = then the server is aware. If you consider the server to be the sending = party, then this situation does not meet number 1 in the definition. If = you consider the server to be the receiving party, then this situation = does not meet number 2 in the definition. To save everyone from looking it up, RFC 2804 says: Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a third party: 1. Without the sending party knowing about the third party 2. Without any of the recipient parties knowing about the delivery to the third party 3. When the normal expectation of the sender is that the transmitted information will only be seen by the recipient parties or parties obliged to keep the information in confidence 4. When the third party acts deliberately to target the transmission of the first party, either because he is of interest, or because the second party's reception is of interest. The term "party", as used here, can refer to one person, a group of persons, or equipment acting on behalf of persons; the term "party" is used for brevity. Of course, many wiretaps will be bidirectional, monitoring traffic sent by two or more parties to each other. Thus, for instance, monitoring public newsgroups is not wiretapping (condition 3 violated), random monitoring of a large population is not wiretapping (condition 4 violated), a recipient passing on private email is not wiretapping (condition 2 violated). Russ= From nobody Fri Jul 7 14:41:07 2017 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 A2BCC1316A9 for ; Fri, 7 Jul 2017 14:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoCrf3Oo9qPT for ; Fri, 7 Jul 2017 14:41:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D11131699 for ; Fri, 7 Jul 2017 14:41:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 295C1BE39; Fri, 7 Jul 2017 22:41:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ktrj72IkCyeB; Fri, 7 Jul 2017 22:40:59 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A0EDEBE2C; Fri, 7 Jul 2017 22:40:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499463659; bh=FivSL836a4xY6n5e2LQmocdhpnmkiH4QpGEcyT+R1/o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TF70JOV4LQVgLz7mAbKsogUb2RSB4f0nvtliSrArmR02xeBhDMR0uh0qULesjF71y vNeXyrOQzd5dns1Z+2cjBiVZ39b7723S2zMOHxbid9fjQT4FnVYNBQF3qcLDdTopPr 0ksD0HHNvgpSoZbcoEel7frTBP0FHJYeJg8wkCh4= To: Russ Housley Cc: IETF TLS , Matthew Green References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <298f70b5-afb8-0298-c678-1bd3d506264a@cs.tcd.ie> Date: Fri, 7 Jul 2017 22:40:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wB4HXhOw8r7OXeDuRR5i8THKtdrIm04WK" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 21:41:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wB4HXhOw8r7OXeDuRR5i8THKtdrIm04WK Content-Type: multipart/mixed; boundary="wpRPuqrHboHtFrchg5uE8ESw4I8XA2PJ5"; protected-headers="v1" From: Stephen Farrell To: Russ Housley Cc: IETF TLS , Matthew Green Message-ID: <298f70b5-afb8-0298-c678-1bd3d506264a@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> In-Reply-To: --wpRPuqrHboHtFrchg5uE8ESw4I8XA2PJ5 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 07/07/17 22:38, Russ Housley wrote: > Stephen: >=20 >>>> You didn't refer to 2804 and the standards track. As an author >>>> do you really think this can be on the standards track and yet >>>> not obsolete 2804? >>>=20 >>> Yes. >>=20 >> We disagree. >>=20 >>> Section 3 of RFC 2804 offers pretty clear definition of=20 >>> wiretapping, and that is not what is going on here. In this=20 >>> situation, all of the parties are part of the same organization,=20 >>> under common key management. >>=20 >> That is one possible deployment. There is nothing in this proposal >> that limits it's use to that. >>=20 >>> The server must explicitly accept and use the centrally managed >>> (EC)DH key, so that party is completely aware and, in fact, >>> enabling the other parties to decrypt the traffic. >>=20 >> Yes, and the server could equally be compelled to do that, in which >> case this technology would clearly be a standard form of >> wiretapping. >>=20 >> Claiming that is not the case would be incredible so I have no idea >> how you maintain that this isn't in conflict with 2804. >=20 > That does not follow the definition in Section 3 of RFC 2804. If one > of the parties is "compelled" to install the centrally managed (EC)DH > key, then the server is aware.=20 CDNs. Cheers, S. ? If you consider the server to be the > sending party, then this situation does not meet number 1 in the > definition. If you consider the server to be the receiving party, > then this situation does not meet number 2 in the definition. >=20 > To save everyone from looking it up, RFC 2804 says: >=20 > Wiretapping is what occurs when information passed across the=20 > Internet from one party to one or more other parties is delivered to=20 > a third party: >=20 > 1. Without the sending party knowing about the third party >=20 > 2. Without any of the recipient parties knowing about the delivery > to the third party >=20 > 3. When the normal expectation of the sender is that the transmitted=20 > information will only be seen by the recipient parties or parties=20 > obliged to keep the information in confidence >=20 > 4. When the third party acts deliberately to target the transmission=20 > of the first party, either because he is of interest, or because the > second party's reception is of interest. >=20 > The term "party", as used here, can refer to one person, a group of=20 > persons, or equipment acting on behalf of persons; the term "party"=20 > is used for brevity. >=20 > Of course, many wiretaps will be bidirectional, monitoring traffic=20 > sent by two or more parties to each other. >=20 > Thus, for instance, monitoring public newsgroups is not wiretapping=20 > (condition 3 violated), random monitoring of a large population is=20 > not wiretapping (condition 4 violated), a recipient passing on=20 > private email is not wiretapping (condition 2 violated). >=20 > Russ >=20 --wpRPuqrHboHtFrchg5uE8ESw4I8XA2PJ5-- --wB4HXhOw8r7OXeDuRR5i8THKtdrIm04WK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZX//rAAoJEC88hzaAX42iAUoH/2CO7dr3SpVaRV5lFV1jlu+I jqkKklAhrnzl7HymDccKLBDHmi0wT67o0ctl/8qteHlE3AE5eqAQD9xS4xov22dx +UnzhH96+3lLhQva42RjRvG3PoJ4gwloNy8H05Rhyoe0g7UzE9f/NcVdGZF/7SVG +1tCAMxafY/5fwyXshGUoh8AQmWdeeOZ5UxAIUHMld8sfukuqCU6JOh5GE1bEcsK c5DPc1vkMOE2VmyiOGFB9Z0IXpDBk5M3LfINapNCn52fdlHGlPzueKQSfBzHEiua QjdWW8Io56kN5GzaJPZ0w9Dtc80mSYk7BZoswP5Lm2x2RyUOh+KKPUSdVK/6osE= =Tm5/ -----END PGP SIGNATURE----- --wB4HXhOw8r7OXeDuRR5i8THKtdrIm04WK-- From nobody Fri Jul 7 14:48:45 2017 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 606B41316AE for ; Fri, 7 Jul 2017 14:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVL5KE-AAvEK for ; Fri, 7 Jul 2017 14:48:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5149612EB9B for ; Fri, 7 Jul 2017 14:48:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76EE2BE39; Fri, 7 Jul 2017 22:48:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpSGsHVpb7_9; Fri, 7 Jul 2017 22:48:39 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0CA4EBE2C; Fri, 7 Jul 2017 22:48:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499464119; bh=dObdltMJ/+wlJjY28XWcItLFYPv6vwMszM12EQrBmrA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=t2yGpeLMtfWJGF0nsGH9GyXNTJrA/xRxGkU9pFhDPnlppLBa69rxzko+EMqhsUIDA 4zicOjbpLUUm0zI9JHK2LSLxf7MUhOE1sN37r67/vFUvsmvyrVuySzij3BRqkQD7Nc OSZEdKQk1gHdmTPEXNDI+U4XmkdnzxkmugptR/XQ= To: Russ Housley Cc: IETF TLS , Matthew Green References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 7 Jul 2017 22:48:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B8K6igiqppAGrenAl6sCCu2pTIKrvmfsq" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 21:48:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B8K6igiqppAGrenAl6sCCu2pTIKrvmfsq Content-Type: multipart/mixed; boundary="OVLsqM9XKsl92tGBJs0xovUTk56A3q89a"; protected-headers="v1" From: Stephen Farrell To: Russ Housley Cc: IETF TLS , Matthew Green Message-ID: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> In-Reply-To: --OVLsqM9XKsl92tGBJs0xovUTk56A3q89a Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 07/07/17 22:38, Russ Housley wrote: > Stephen: >=20 >>>> You didn't refer to 2804 and the standards track. As an author >>>> do you really think this can be on the standards track and yet >>>> not obsolete 2804? >>>=20 >>> Yes. >>=20 >> We disagree. >>=20 >>> Section 3 of RFC 2804 offers pretty clear definition of=20 >>> wiretapping, and that is not what is going on here. In this=20 >>> situation, all of the parties are part of the same organization,=20 >>> under common key management. >>=20 >> That is one possible deployment. There is nothing in this proposal >> that limits it's use to that. >>=20 >>> The server must explicitly accept and use the centrally managed >>> (EC)DH key, so that party is completely aware and, in fact, >>> enabling the other parties to decrypt the traffic. >>=20 >> Yes, and the server could equally be compelled to do that, in which >> case this technology would clearly be a standard form of >> wiretapping. >>=20 >> Claiming that is not the case would be incredible so I have no idea >> how you maintain that this isn't in conflict with 2804. >=20 > That does not follow the definition in Section 3 of RFC 2804. =20 And also: I'm sorry to have to say it, but I consider that attempted weasel wording around the clear intent of 2804. The clear and real effect if your wiretapping proposal were standardised by the IETF would be that we'd be standardising ways in which TLS servers can be compelled into breaking TLS - it'd be a standard wiretapping API that'd be insisted upon in many places and would mean significantly degrading TLS (only *the* most important security protocol we maintain) and the community's perception of the IETF. It's all a shockingly bad idea. S PS: You might say that purely static DH can be detected by the TLS client, but once we give in on this it'll be inevitable that variants are derived that aren't detectable by the TLS client. > If one > of the parties is "compelled" to install the centrally managed (EC)DH > key, then the server is aware. If you consider the server to be the > sending party, then this situation does not meet number 1 in the > definition. If you consider the server to be the receiving party, > then this situation does not meet number 2 in the definition. >=20 > To save everyone from looking it up, RFC 2804 says: >=20 > Wiretapping is what occurs when information passed across the=20 > Internet from one party to one or more other parties is delivered to=20 > a third party: >=20 > 1. Without the sending party knowing about the third party >=20 > 2. Without any of the recipient parties knowing about the delivery > to the third party >=20 > 3. When the normal expectation of the sender is that the transmitted=20 > information will only be seen by the recipient parties or parties=20 > obliged to keep the information in confidence >=20 > 4. When the third party acts deliberately to target the transmission=20 > of the first party, either because he is of interest, or because the > second party's reception is of interest. >=20 > The term "party", as used here, can refer to one person, a group of=20 > persons, or equipment acting on behalf of persons; the term "party"=20 > is used for brevity. >=20 > Of course, many wiretaps will be bidirectional, monitoring traffic=20 > sent by two or more parties to each other. >=20 > Thus, for instance, monitoring public newsgroups is not wiretapping=20 > (condition 3 violated), random monitoring of a large population is=20 > not wiretapping (condition 4 violated), a recipient passing on=20 > private email is not wiretapping (condition 2 violated). >=20 > Russ >=20 --OVLsqM9XKsl92tGBJs0xovUTk56A3q89a-- --B8K6igiqppAGrenAl6sCCu2pTIKrvmfsq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYAG2AAoJEC88hzaAX42iN8sIAJxIOhbXsC7f3mRXYUMr31D2 870Z835Zeml7jSm0O2DWOFuekTv+pV2pf8SrF/jigiRUIm6K7zmfd5tRWYmdW5gi 0ZCnWlgoY+MIxZgfoouNgagl3djC2RM+xeINcMWpTkQ6VQINNzy+hrkBoesXVWIf fA93gI19nVwXHpi6oJAAKeOdHpD5Nhf+/kJaE+mhdG+d7z9pESB8kSKQvKmUqVDf yIOQruyRrFmiOePFn+xl5klk1lDcFtYa9HlIKFtl4fhieNCa2pHOQWB/QXc+fMl7 7S00GBiGbdYxIOaFHOd/zdU9l+GSuwdLZUdV7yxIofLx4jcGCsTLOGJVwbIanQg= =5dHT -----END PGP SIGNATURE----- --B8K6igiqppAGrenAl6sCCu2pTIKrvmfsq-- From nobody Fri Jul 7 14:54:07 2017 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 23F3F129A96 for ; Fri, 7 Jul 2017 14:54:06 -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 0hOIgw1aMxB2 for ; Fri, 7 Jul 2017 14:54:05 -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 E0EF7129462 for ; Fri, 7 Jul 2017 14:54:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4339A300563 for ; Fri, 7 Jul 2017 17:54:04 -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 W7hYCTeGureX for ; Fri, 7 Jul 2017 17:54:03 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id EFE7A300250; Fri, 7 Jul 2017 17:54:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Fri, 7 Jul 2017 17:54:02 -0400 Cc: IETF TLS , Matthew Green Content-Transfer-Encoding: 7bit Message-Id: <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 21:54:06 -0000 Stephen: >>>>> You didn't refer to 2804 and the standards track. As an author >>>>> do you really think this can be on the standards track and yet >>>>> not obsolete 2804? >>>> >>>> Yes. >>> >>> We disagree. >>> >>>> Section 3 of RFC 2804 offers pretty clear definition of >>>> wiretapping, and that is not what is going on here. In this >>>> situation, all of the parties are part of the same organization, >>>> under common key management. >>> >>> That is one possible deployment. There is nothing in this proposal >>> that limits it's use to that. >>> >>>> The server must explicitly accept and use the centrally managed >>>> (EC)DH key, so that party is completely aware and, in fact, >>>> enabling the other parties to decrypt the traffic. >>> >>> Yes, and the server could equally be compelled to do that, in which >>> case this technology would clearly be a standard form of >>> wiretapping. >>> >>> Claiming that is not the case would be incredible so I have no idea >>> how you maintain that this isn't in conflict with 2804. >> >> That does not follow the definition in Section 3 of RFC 2804. > > And also: I'm sorry to have to say it, but I consider that > attempted weasel wording around the clear intent of 2804. The > clear and real effect if your wiretapping proposal were standardised > by the IETF would be that we'd be standardising ways in which > TLS servers can be compelled into breaking TLS - it'd be a standard > wiretapping API that'd be insisted upon in many places and would > mean significantly degrading TLS (only *the* most important > security protocol we maintain) and the community's perception > of the IETF. It's all a shockingly bad idea. I clearly disagree. Otherwise, I would not have put any work into the draft. Russ From nobody Fri Jul 7 14:55:37 2017 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 737AB1316DE for ; Fri, 7 Jul 2017 14:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KITqBc3X6n2 for ; Fri, 7 Jul 2017 14:55:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C30813168C for ; Fri, 7 Jul 2017 14:55:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 03286BE49; Fri, 7 Jul 2017 22:55:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L9ZeTxBAW6E; Fri, 7 Jul 2017 22:55:32 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AD388BE39; Fri, 7 Jul 2017 22:55:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499464531; bh=FCLX5gx8xifRaNXzxBixQFWIo9x0mTsGsRIbmt6sB6o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=13wqXQjJDTiF+tmTnkosybNqJmTXycCvhjONuNjjGGrWKKBnlg4wf6ldmdZb5LzY3 pYnMMEpEN2ilP0Rv6NuZlstV8csSmvCUQYfXfXqgg35IhOUMQsEPIQF9OMHeFND1Q9 ehNFjQCqZ11FHdRwkd+f/7SdnbV1SpBLn0CfmItM= To: Russ Housley Cc: IETF TLS , Matthew Green References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <22ee4279-a644-22bf-f04e-f61ed6f3852d@cs.tcd.ie> Date: Fri, 7 Jul 2017 22:55:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="POUTudk8QpCDcr6nEQ5cp1MWQoqFX5HPq" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 21:55:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --POUTudk8QpCDcr6nEQ5cp1MWQoqFX5HPq Content-Type: multipart/mixed; boundary="mNX6Nihq7brwEnun3ehh3dNTAsOjJPH0R"; protected-headers="v1" From: Stephen Farrell To: Russ Housley Cc: IETF TLS , Matthew Green Message-ID: <22ee4279-a644-22bf-f04e-f61ed6f3852d@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> In-Reply-To: <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> --mNX6Nihq7brwEnun3ehh3dNTAsOjJPH0R Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 07/07/17 22:54, Russ Housley wrote: > I clearly disagree. Otherwise, I would not have put any work into the = draft. I accept that. But I think you and your co-authors are utterly wrong in this case. S. --mNX6Nihq7brwEnun3ehh3dNTAsOjJPH0R-- --POUTudk8QpCDcr6nEQ5cp1MWQoqFX5HPq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYANTAAoJEC88hzaAX42iPLcH/jHLloGBN+3cd6IRaVstQJfP vIWAjBrcQEJGufj1PY9WsCpMiJTFoVmjyrFF6clRjgrgqP1nDJG9psmt9ezbJflJ VDiZNiQ2w1SEiem1Tyiuxqoc0SIlsfDK1wOO3uu6D7NajY9AUcZmz28QQaSta61+ Brp6g8M0OBn7Dir7R/56oo2pRhyYK9TfKjL52eX+gn8yaTjRZc74Cmo71W3yi7Xo +CFCU00NRwjxXrClcGRQV9oJOXsOuzMq14u6Z5BaK9dhA9oFzHqF74wiN1pmMpGf Km2NCtJs3bjB2dD9qB5/OrA1ksuBwIcZxgpE2M4k6ToTYPOXI5bPjpFS4jWxpAU= =AXxO -----END PGP SIGNATURE----- --POUTudk8QpCDcr6nEQ5cp1MWQoqFX5HPq-- From nobody Fri Jul 7 16:05:08 2017 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 25635129B61 for ; Fri, 7 Jul 2017 16:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 0W0g-oDtvztV for ; Fri, 7 Jul 2017 16:05:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B721271DF for ; Fri, 7 Jul 2017 16:05:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7DA1D7A330D; Fri, 7 Jul 2017 23:05:05 +0000 (UTC) Date: Fri, 7 Jul 2017 23:05:05 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20170707230505.GB1755@mournblade.imrryr.org> Reply-To: tls@ietf.org References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> <20170705171211.GM5673@mournblade.imrryr.org> <1F943876-91FC-4529-9B44-9F187EDA48B5@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2017 23:05:08 -0000 On Fri, Jul 07, 2017 at 11:06:45AM -0400, Shumon Huque wrote: > We've had this discussion numerous times over the life of this draft, and > there was never any consensus for the client caching or not. An > implementation could have the client cache the data, and only validate the > portion of the chain that it needs to, without any wire protocol change. > I'm okay with mentioning that possibility. > > IMO, the real gain from having the client cache data, is that the server > could then potentially send a much smaller DNSSEC chain. But this requires > the client to signal what they've cached, and makes the protocol more > complex. I would prefer to leave that to a future revision of the spec, > after we've gained some operational experience with the current one. Once the client obtains a validated TLSA RRset for the service endpoint, it may (up to the TTLs of the provided records, validated to conform to the max ttl of the RRSIGs and not exceed the RRSIG expiration) simply not omit the extension in subsequent requests, and validate the server certificate per the cached TLSA RRs. This requires no complex protocoll machinery, just caching of the validated TLSA RRset. This is essentially the same as obtaining validated TLSA records via DNS, where they are cached in the client's resolver up to the relevant TTL. Only here the client can choose to cap the TTL to a lower value, and ask the server again sooner. The client cannot as easily cap the maximum cache TTL of its iterative resolver. So, indeed I would not try to engineer partial caching, with the client soliciting a portion of the complete set of validation RRsets. However, simple caching of the given server's validated TLSA RRset for repeat visits is not unreasonable, if the client implementation chooses to do that. Servers may wish to cap their TLSA record TTLs knowing that they may be cached by clients. Clients might also save some CPU by not revalidating previously validated RRsets, but they will not avoid the overhead of receiving the full set of records from the server. -- Viktor. From nobody Fri Jul 7 18:03:08 2017 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 E094F12EC33 for ; Fri, 7 Jul 2017 18:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 R5lA3hFIoAFn for ; Fri, 7 Jul 2017 18:03:05 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 11391127F0E for ; Fri, 7 Jul 2017 18:03:05 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id w19so29509911uac.0 for ; Fri, 07 Jul 2017 18:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=yRzmZm3W8cWzlFBjedQBEpHRPZd5Gp8R4t1XINnvp0c=; b=mqaGGqnFyZ0keKqTaO3bkFJjJEc4pqruYKLZ4Mxc14NptSJVB1EqT2gU5Xbc3u3wuo 19YtJPseTXsE29X83wuPR7ndvI0RPS0cc14dXPMHsi/Q0f6DaEuuXV4tRl/Y48PwbMMT pAKg6eLWIzhfHe4TXvDxbiGkzjsKsOqHaAcxpvsi2BbdNcV9hHKV7lFyN5Yg+M3354A3 46E0lxw1Je2elDHQxk6+1+hcq8N4t9gemn3NAgaitmDB1pOSWXJcRAekk8zXFFe4/DFF 96sXPbFYRIOpPQKI4gjFIRunZ9xX1m4i47q0/fxPuaU28G2yi3/bdiF1uBRiY9e7eoXl QjWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=yRzmZm3W8cWzlFBjedQBEpHRPZd5Gp8R4t1XINnvp0c=; b=ataSgDVqVcxnLlONwKO4ufsdzsVCZ97vYsngriTQJEqRDbG+hpMi6VXJt9c9PbF/4S rW3S3Az0ZR428hRYsJTrA+69rZpbn6AWIgjBo30A+2AjhV/DJ4QPqD8RE2d2rJrPbkTP 0CvPBkT3UhHzeLNF2d/ncW7rU+qzViBJ5EANlSUwNTwZ0pwHLvC6qMOy3uLIXa8Xd7h4 gfteszwlUsFhq2OqMRi+Wsb6vY8WmS60mBPMUwTLm9ELe8+J/ELmkSdikgXG+xs7vMDJ ysUp19jicBsMBRN50F2dv9zF1DLpB5N47KLSgXOIrPSdSA+EvFLPhUik53yw0F2oe4RH cUpw== X-Gm-Message-State: AIVw113GgEf3BllNe6Z4KzYTtj4+qXTErHO1K7xdV4NRqmfZ3iH968Qc yBcl/Q1hrcNmA9SM7xoQv4fm+2H/l3Wp X-Received: by 10.159.51.97 with SMTP id a33mr2486337uac.44.1499475784099; Fri, 07 Jul 2017 18:03:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Fri, 7 Jul 2017 18:03:03 -0700 (PDT) In-Reply-To: <20170707230505.GB1755@mournblade.imrryr.org> References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> <20170705171211.GM5673@mournblade.imrryr.org> <1F943876-91FC-4529-9B44-9F187EDA48B5@rfc1035.com> <20170707230505.GB1755@mournblade.imrryr.org> From: Shumon Huque Date: Fri, 7 Jul 2017 21:03:03 -0400 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="f403043ebcac75ecb50553c3e986" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 01:03:07 -0000 --f403043ebcac75ecb50553c3e986 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 7:05 PM, Viktor Dukhovni wrote: > > Once the client obtains a validated TLSA RRset for the service > endpoint, it may (up to the TTLs of the provided records, validated > to conform to the max ttl of the RRSIGs and not exceed the RRSIG > expiration) simply not omit the extension in subsequent requests, > and validate the server certificate per the cached TLSA RRs. > ( assumed typo: s/not omit/omit/ ) This is quite a reasonable and simple optimization, and I think we should document it in the draft. It may often be short circuited by TLS session resumption, but it's so simple that it's probably worth doing. Thanks! -- Shumon Huque --f403043ebcac75ecb50553c3e986 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 7:05 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
<= br> Once the client obtains a validated TLSA RRset for the service
endpoint, it may (up to the TTLs of the provided records, validated
to conform to the max ttl of the RRSIGs and not exceed the RRSIG
expiration) simply not omit the extension in subsequent requests,
and validate the server certificate per the cached TLSA RRs.

( assumed typo: s/not omit/omit/ )

This is quite a reasonable and simple optimization, and I think we s= hould document it in the draft. It may often be short circuited by TLS sess= ion resumption, but it's so simple that it's probably worth doing.<= /div>

Thanks!
--
Shumon Huque
<= div>
--f403043ebcac75ecb50553c3e986-- From nobody Fri Jul 7 18:10:52 2017 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 B712612EE46 for ; Fri, 7 Jul 2017 18:10:50 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 t-7M68rR5xNY for ; Fri, 7 Jul 2017 18:10:43 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 3053912EC5E for ; Fri, 7 Jul 2017 18:10:43 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dTeGe-0003RS-VS for tls@ietf.org; Sat, 08 Jul 2017 03:10:41 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dTeGc-0007Se-8Z for tls@ietf.org; Fri, 07 Jul 2017 21:10:38 -0400 Received: (qmail 1799 invoked from network); 8 Jul 2017 01:10:37 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.115]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Jul 2017 01:10:37 -0000 To: tls@ietf.org References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> From: Christian Huitema Message-ID: <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> Date: Fri, 7 Jul 2017 18:10:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.18) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23u6J+Z9hqIoPjJH40xpGRy05SvzZFcn5J62ab Al4JpFZULpykAH11MUosJ7hV0GynYOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRP6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyVOTTUVzCsLfQnTzNoxDUI/eNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj234Kahp30YSTh5OL3yMqjF0jNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxiSsoNTiR/GmpPv4QzJ0uLs078I0y+3uS4dN KiUgYTBU+vlTZScf+pV+dKgRvtLQS4AbiteDwjw8P7mx/NBHSRWxZaHLvUGmD7PXY2RS8idsz7fr MHsNPRylYAkPvY1HttQOF909qtkcRbvucYBIc/TGQ1pzMEqsBEjp552RX8brr8hUVhe7ugL65f2h l2QLng== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 01:10:51 -0000 On 7/7/2017 2:54 PM, Russ Housley wrote: > Stephen: > ... >> And also: I'm sorry to have to say it, but I consider that >> attempted weasel wording around the clear intent of 2804. The >> clear and real effect if your wiretapping proposal were standardised >> by the IETF would be that we'd be standardising ways in which >> TLS servers can be compelled into breaking TLS - it'd be a standard >> wiretapping API that'd be insisted upon in many places and would >> mean significantly degrading TLS (only *the* most important >> security protocol we maintain) and the community's perception >> of the IETF. It's all a shockingly bad idea. > I clearly disagree. Otherwise, I would not have put any work into the = draft. Russ, What are the specific mechanisms that would allow this technique to be used where you intend it, i.e. within a data center, and not where Stephen fears it would be, i.e., on the broad Internet? For example, what mechanism could a client use to guarantee that this sort of "static DH" intercept could NOT be used against them? --=20 Christian Huitema From nobody Fri Jul 7 18:39:48 2017 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 1A3B512EC26 for ; Fri, 7 Jul 2017 18:39: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BLsDuIYi-Iin for ; Fri, 7 Jul 2017 18:39:43 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 4703112EB27 for ; Fri, 7 Jul 2017 18:39:43 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id k14so24703289pgr.0 for ; Fri, 07 Jul 2017 18:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ix6YxyOCOqE5RNnT7143Cds8VMI4dwTNo4ynb6V8hmI=; b=Rmiz0kkG2bzYz1MQyV0FqTgZqDM1n51HXIJC/UyFbrt7f2Y8MMCu9La58MAdjZnd/Q 4OAQzHDx33ijpVWWaW84Fuwlxk1lSYrnPG55Cbh/oG4bhL1PhVky8XrXw7uEauiySzzl bL2lcU4MOSihuXRnBzLhIpWe6Ur1OiuKtqKPCTlCX1CKebiAUQXS6PYioGo8x/K0ns3N F5Fb0c/odHm2Ink/gB6RnglCaN8Mt0qpJ48nMO0nrlImaWU3j6ZYoZZgDMBt4TB95rBx 11mqc2r7hN+nwE5Itnp0RXMD9KF/DFgcNGZ6GE/4UWqYyEWm1T3/2Gmjy5AVKQNue3U4 ghaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ix6YxyOCOqE5RNnT7143Cds8VMI4dwTNo4ynb6V8hmI=; b=tz+CvdT2H9jM2Ggel3JhJ31jEhXDBJmB356ecu3DUAKoL4QprHyzO6jENM1W9FXuTB JgJzJK5hmPms9eo2WhVgkj2K52W0plXLwL/LJs561NF5ts/HfCEfn3mU4G9GRQ5UtODg J6wNHV9FsYVFKrD/iUZ9s5AtUFeJfdYMuQSK1raVquD2HHi1GA1xHJGtmfSpCL/dlLqd NEKehpgWKkZLm6n9db/kkKiyo2+7bt6L795ika2GUbTI4ZbNGFnuhOqrFrMHlPNinxn3 WIyQs+eBPqiGPfIyxUHOpjX7XGoT/CWXq3AyJuwYAcXedp9fbxSxfKrXvyDX0XLrTIRj q+PQ== X-Gm-Message-State: AIVw1129kfz08M9MoOeAXzq0Trm7DgpJ9YkeK5wMae86Hg8Eew/4eduG v546HHdZYFGtQcLWzWZ+V+xKGtJrNYEr X-Received: by 10.84.229.79 with SMTP id d15mr6175062pln.4.1499477982863; Fri, 07 Jul 2017 18:39:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Fri, 7 Jul 2017 18:39:42 -0700 (PDT) In-Reply-To: <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> From: Watson Ladd Date: Fri, 7 Jul 2017 18:39:42 -0700 Message-ID: To: Christian Huitema Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 01:39:45 -0000 On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema wrote: > > > On 7/7/2017 2:54 PM, Russ Housley wrote: >> Stephen: >> ... >>> And also: I'm sorry to have to say it, but I consider that >>> attempted weasel wording around the clear intent of 2804. The >>> clear and real effect if your wiretapping proposal were standardised >>> by the IETF would be that we'd be standardising ways in which >>> TLS servers can be compelled into breaking TLS - it'd be a standard >>> wiretapping API that'd be insisted upon in many places and would >>> mean significantly degrading TLS (only *the* most important >>> security protocol we maintain) and the community's perception >>> of the IETF. It's all a shockingly bad idea. >> I clearly disagree. Otherwise, I would not have put any work into the draft. > Russ, > > What are the specific mechanisms that would allow this technique to be > used where you > intend it, i.e. within a data center, and not where Stephen fears it > would be, i.e., on > the broad Internet? For example, what mechanism could a client use to > guarantee > that this sort of "static DH" intercept could NOT be used against them? The server can send the plaintext to whomever it likes. This is the solution enterprises can use today. Nothing can stop that from happening. So I don't see why static DH is a) so essentially necessary and b) so controversial. >From a technical point I prefer using DH shares derived from ServerRandom as this avoids certain bugs I've been known to exploit from time to time. > > -- > Christian Huitema > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Jul 7 19:06:41 2017 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 A3F31131548 for ; Fri, 7 Jul 2017 19:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 3ykNevhMcab3 for ; Fri, 7 Jul 2017 19:06:37 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 03AFD12EC16 for ; Fri, 7 Jul 2017 19:06:36 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 0E7BE1C1930 for ; Fri, 7 Jul 2017 21:06:36 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 413731C178A; Fri, 7 Jul 2017 21:06:35 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 14D48FE04E; Fri, 7 Jul 2017 22:06:35 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C98C6FE048; Fri, 7 Jul 2017 22:06:34 -0400 (EDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (unknown [216.32.180.24]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Fri, 7 Jul 2017 22:06:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fw/s1zMJOTcilGxbtnqbKMyhWutNQ5YlcdhWz9ynmF0=; b=tS9jKrt7z2O1+ZQxyLoehsQ7XyC1bKXdU15oX60NzeHStetqbkc1M8DwHHa/azbPmOdcURlIBiN0slCdkHqXoS6/uyQUFewgxPs6GnVKIx+fQR6iCEDr7UP9f/OoGpBSCAypMF3OZUWxh4P2lc2zZp3CNl3r8zhGALVUGbMpUzc= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Sat, 8 Jul 2017 02:06:32 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1220.018; Sat, 8 Jul 2017 02:06:32 +0000 From: "Ackermann, Michael" To: Watson Ladd , Christian Huitema CC: "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIAABAWAgAAPEACAAAECAIAABj8AgAACzgCAAAGCAIAANuiAgAAIJQCAAASV8A== Date: Sat, 8 Jul 2017 02:06:31 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.0.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 20:B6NIWiVnw2bLYP/6//ldAgmRCNgDHds3ti1VXv38hPZ2fqfiwTIqxhDIoECalA5KnhiKI8UWqdMaDdC/bTIMNc/RYjddxr9HGOcXkjM/mwGrGzXVfQFs3capFpetamdGOmVamfe0kx7gWmgHBKP6fcp6gNYyAMir/xBn9o10N1s= x-ms-office365-filtering-correlation-id: e65c3737-2b9d-419f-6a53-08d4c5a5f406 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1365; x-ms-traffictypediagnostic: CY4PR14MB1365: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(236129657087228)(192374486261705)(48057245064654)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910072)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1365; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39840400002)(39410400002)(39400400002)(39450400003)(24454002)(377454003)(13464003)(25786009)(6116002)(93886004)(2950100002)(189998001)(4326008)(2900100001)(230783001)(3280700002)(77096006)(81166006)(229853002)(8676002)(80792005)(7696004)(33656002)(5660300001)(53546010)(55016002)(72206003)(478600001)(53936002)(6246003)(99286003)(9686003)(966005)(561944003)(54356999)(3660700001)(6436002)(66066001)(2906002)(305945005)(6306002)(6506006)(7736002)(3846002)(38730400002)(14454004)(39060400002)(102836003)(86362001)(50986999)(74316002)(76176999)(8936002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2017 02:06:31.8697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: da592977-808e-4a5e-9ba6-dc4f26f5a7fa X-VPM-MSG-ID: 80e8aa25-512e-41d8-ba40-5dc240b48617 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 02:06:40 -0000 Converting all session traffic to clear text is not a viable alternative = for ANY enterprises or industries that I am aware of. In particular those = in financial sectors. =20 Security policies, legislation and in many cases just good practice would = not allow for this.=20 We are compelled by these factors to encrypt all data in motion. But we = still need to manage our applications, networks, servers and clients. = Hence the need to decrypt traffic as outlined in this draft. =20 -----Original Message----- From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Watson Ladd Sent: Friday, July 7, 2017 9:40 PM To: Christian Huitema Cc: tls=40ietf.org Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema = wrote: > > > On 7/7/2017 2:54 PM, Russ Housley wrote: >> Stephen: >> ... >>> And also: I'm sorry to have to say it, but I consider that attempted=20 >>> weasel wording around the clear intent of 2804. The clear and real=20 >>> effect if your wiretapping proposal were standardised by the IETF=20 >>> would be that we'd be standardising ways in which TLS servers can be=20 >>> compelled into breaking TLS - it'd be a standard wiretapping API=20 >>> that'd be insisted upon in many places and would mean significantly=20 >>> degrading TLS (only *the* most important security protocol we=20 >>> maintain) and the community's perception of the IETF. It's all a=20 >>> shockingly bad idea. >> I clearly disagree. Otherwise, I would not have put any work into the = draft. > Russ, > > What are the specific mechanisms that would allow this technique to be=20 > used where you intend it, i.e. within a data center, and not where=20 > Stephen fears it would be, i.e., on the broad Internet? For example,=20 > what mechanism could a client use to guarantee that this sort of=20 > =22static DH=22 intercept could NOT be used against them? The server can send the plaintext to whomever it likes. This is the solution enterprises can use today. Nothing can stop that from = happening. So I don't see why static DH is a) so essentially necessary and = b) so controversial. >From a technical point I prefer using DH shares derived from ServerRandom as this avoids certain bugs I've been known to exploit from = time to time. > > -- > Christian Huitema > > > _______________________________________________ > TLS mailing list > TLS=40ietf.org > https://www.ietf.org/mailman/listinfo/tls -- =22Man is born free, but everywhere he is in chains=22. --Rousseau. _______________________________________________ TLS mailing list TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Fri Jul 7 20:18:56 2017 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 F395D128ACA for ; Fri, 7 Jul 2017 20:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobileironinc.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 ygMHC_CAXrs6 for ; Fri, 7 Jul 2017 20:18:50 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0061.outbound.protection.outlook.com [104.47.38.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B36120454 for ; Fri, 7 Jul 2017 20:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KizmNfLYaQilL7mufZfzOF9QY/aJDQqi5snVPjMsqTo=; b=0Z/SF1+DEM2Fsnbj9JdP8SwWwWdbXyaFZ4j8gL4DYD+NQVxIiPj7FVDIA+/pVmd0t6ubnO673CwBp34kGeoeNSk7qg2NVdSM1IVlqKhLAjtCijufWIsUL+NmVnJxPALnEm8Uax9t+RhrL8QheeSPspaamX63hck++W/B21Uibgo= Received: from MWHPR10MB1742.namprd10.prod.outlook.com (10.172.52.148) by MWHPR10MB1742.namprd10.prod.outlook.com (10.172.52.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 8 Jul 2017 03:18:45 +0000 Received: from MWHPR10MB1742.namprd10.prod.outlook.com ([10.172.52.148]) by MWHPR10MB1742.namprd10.prod.outlook.com ([10.172.52.148]) with mapi id 15.01.1240.013; Sat, 8 Jul 2017 03:18:45 +0000 From: Timothy Jackson To: "Ackermann, Michael" , Watson Ladd , Christian Huitema CC: "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RdtX0DOX4bkiByIOBXHxVJKJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIAABAWAgAAPEACAAAECAIAABj8AgAACzgCAAAGCAIAANuiAgAAIJQCAAAd+gIAAFC/C Date: Sat, 8 Jul 2017 03:18:45 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bcbsm.com; dkim=none (message not signed) header.d=none;bcbsm.com; dmarc=none action=none header.from=mobileiron.com; x-originating-ip: [204.8.168.222] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR10MB1742; 7:SuSzIDhy/hMFnGxSR55hDnd5TOsX/QqUtnNoJIpqr07mlmPjPMaHuk2Gl7WK1lrgtbfy6VsGqWoXgL7lbgXhjhcIJA+rxy2OqL1Rd8Z/N5+1Jsia+1y5+FSTCiqpe/9mpaeEx0YTE0YWxVv9xZfYO4H9VD7HD6AgV5cthjTgVBzecltTVV4blcotAo+H1UPdyTw1drtZZSDvHJzDWp/YJ4cxdFQH9z5U3LV+HJ/cJ1zkBEjsvvYIEGRgPdza7IobaQmTQjxTUGtWMDghs7FnA7jIuaZyst62J/c4wi9YSSkpwKbNyoQZCC21t03aTQn/oFBZl21Vy13p7SOKVZd2RVcAsFxZW8pgKSQlk/5a8g/5PleAsVOCkKpqllE5I2jJCSYjzENWWVYs2HRLS/0n+iwKtTR/g+b7L5XjYQP6skJHXF/l8/mejsItoTq23X8l94WDaa/pxM06DAsi4eo54vWy0P3VRsZ2cax26tDotLmNihb30eBmOZbvxyHKO41IVR8hBa/Ic+ezIsQuicMOl6Y+QQXJO4wKIljAd2ly2DtzZBVgGyLpj/q6cSBTnIkUzt1bUnKp6MrOM7sAnEu4h8WZV+Awa29x2W+oNlq78MD9sGh5IptdwbTaHoeJTyKoucsg94noA+6tkCoMNepUQP73AYcUc8Pwsq0KETFpzv4tgEt5sJ5mHgwIc+igU6Ky2Dl6q96rMZoKVELCOB0Y2fvjMvOTI7jWvhRgvLmzyM/SNU4MLXECvmmB116103dhdyr32TreNvmaoOegSZsdatBBb1wmjIArKbrEb101MKU= x-ms-office365-filtering-correlation-id: 1120ce1a-e7d7-4042-cd1f-08d4c5b00b2d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR10MB1742; x-ms-traffictypediagnostic: MWHPR10MB1742: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(26388249023172)(236129657087228)(192374486261705)(90097320859284)(48057245064654)(148574349560750)(86572411397741)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910072)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR10MB1742; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR10MB1742; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39450400003)(39400400002)(39850400002)(39410400002)(377454003)(24454002)(85714005)(13464003)(2906002)(2950100002)(6116002)(102836003)(606006)(4326008)(229853002)(3280700002)(3660700001)(966005)(53936002)(39060400002)(38730400002)(99286003)(54896002)(478600001)(6512007)(53546010)(14454004)(6306002)(6246003)(236005)(86362001)(6436002)(51650200002)(77096006)(81166006)(8676002)(33646002)(8936002)(6506006)(76176999)(5660300001)(561944003)(54356999)(50986999)(6486002)(189998001)(66066001)(93886004)(2900100001)(3846002)(25786009)(7736002)(230783001)(95246002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR10MB1742; H:MWHPR10MB1742.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_kokbii6v34dsk060vpa2if7u1499483924916emailplusmobileiro_" MIME-Version: 1.0 X-OriginatorOrg: mobileiron.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2017 03:18:45.6137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1742 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 03:18:55 -0000 --_000_kokbii6v34dsk060vpa2if7u1499483924916emailplusmobileiro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As an earlier poster asked, what advantage does this approach have over TLS= -inspecting proxies? Every IPS/IDS/next gen firewall with which I am famili= ar is able to terminate at TLS connection, inspect/copy/filter, and then en= crypt on a new TLS sessions. For high performance customers, the SSL accelerators can be sandwiched arou= nd the filter so all the crypto is done in hardware. The ways to prevent TLS inspection are cert pinning and client cert auth. I= f this is only within one's data center, then those features can be disable= d if necessary, no? What use case am I missing that can't be achieved better by other means tha= n static keys? Thanks, Tim Sent from Email+ secured by MobileIron ________________________________ From: "Ackermann, Michael" > Date: Friday, July 7, 2017 at 7:06:55 PM To: "Watson Ladd" >, "C= hristian Huitema" > Cc: "tls@ietf.org" > Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Converting all session traffic to clear text is not a viable alternative fo= r ANY enterprises or industries that I am aware of. In particular those in= financial sectors. Security policies, legislation and in many cases just good practice would n= ot allow for this. We are compelled by these factors to encrypt all data in motion. But we = still need to manage our applications, networks, servers and clients. He= nce the need to decrypt traffic as outlined in this draft. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd Sent: Friday, July 7, 2017 9:40 PM To: Christian Huitema Cc: tls@ietf.org Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema wro= te: > > > On 7/7/2017 2:54 PM, Russ Housley wrote: >> Stephen: >> ... >>> And also: I'm sorry to have to say it, but I consider that attempted >>> weasel wording around the clear intent of 2804. The clear and real >>> effect if your wiretapping proposal were standardised by the IETF >>> would be that we'd be standardising ways in which TLS servers can be >>> compelled into breaking TLS - it'd be a standard wiretapping API >>> that'd be insisted upon in many places and would mean significantly >>> degrading TLS (only *the* most important security protocol we >>> maintain) and the community's perception of the IETF. It's all a >>> shockingly bad idea. >> I clearly disagree. Otherwise, I would not have put any work into the d= raft. > Russ, > > What are the specific mechanisms that would allow this technique to be > used where you intend it, i.e. within a data center, and not where > Stephen fears it would be, i.e., on the broad Internet? For example, > what mechanism could a client use to guarantee that this sort of > "static DH" intercept could NOT be used against them? The server can send the plaintext to whomever it likes. This is the solution enterprises can use today. Nothing can stop that from = happening. So I don't see why static DH is a) so essentially necessary and = b) so controversial. >From a technical point I prefer using DH shares derived from ServerRandom as this avoids certain bugs I've been known to exploit from ti= me to time. > > -- > Christian Huitema > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this communicat= ion is directed. If you are not the intended recipient, you are hereby noti= fied that any viewing, copying, disclosure or distribution of this informat= ion is prohibited. Please notify the sender, by electronic mail or telephon= e, of any unintended receipt and delete the original message without making= any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are n= onprofit corporations and independent licensees of the Blue Cross and Blue = Shield Association. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_kokbii6v34dsk060vpa2if7u1499483924916emailplusmobileiro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As an earlier poster asked, what advantage does this approach have over TL= S-inspecting proxies? Every IPS/IDS/next gen firewall with which I am famil= iar is able to terminate at TLS connection, inspect/copy/filter, and then encrypt on a new TLS sessions.

For high performance customers, the SSL accelerators can be sandwiched arou= nd the filter so all the crypto is done in hardware.

The ways to prevent TLS inspection are cert pinning and client cert auth. I= f this is only within one's data center, then those features can be disable= d if necessary, no?

What use case am I missing that can't be achieved better by other means tha= n static keys?

Thanks,

Tim

Sent from Emai= l+ secured by MobileIron


From: "Ackermann, Michael" <MAckermann@bcbsm.com>
Date: Friday, July 7, 2017 at 7:06:55 PM
To: "Watson Ladd" <watsonbladd@gmail.com>, "Christian Huitema" <huitema@huitema.net>
Cc: "tls@ietf.org" <tls= @ietf.org>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Converting all session traffic to clear text is no= t a viable alternative for ANY enterprises or industries that I am aware of= .  In particular those in financial sectors. 
Security policies, legislation and in many cases just good practice would n= ot allow for this.
We are compelled by these factors to encrypt all data in motion.  = ;  But we still need to manage our applications, networks, servers and= clients.    Hence the need to decrypt traffic as outlined i= n this draft.  

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.= org] On Behalf Of Watson Ladd
Sent: Friday, July 7, 2017 9:40 PM
To: Christian Huitema <huitema@huitema.net>
Cc: tls@ietf.org
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema <huitema@huitema.net&g= t; wrote:
>
>
> On 7/7/2017 2:54 PM, Russ Housley wrote:
>> Stephen:
>> ...
>>> And also: I'm sorry to have to say it, but I consider that att= empted
>>> weasel wording around the clear intent of 2804. The clear and = real
>>> effect if your wiretapping proposal were standardised by the I= ETF
>>> would be that we'd be standardising ways in which TLS servers = can be
>>> compelled into breaking TLS - it'd be a standard wiretapping A= PI
>>> that'd be insisted upon in many places and would mean signific= antly
>>> degrading TLS (only *the* most important security protocol we =
>>> maintain) and the community's perception of the IETF. It's all= a
>>> shockingly bad idea.
>> I clearly disagree.  Otherwise, I would not have put any work= into the draft.
> Russ,
>
> What are the specific mechanisms that would allow this technique to be=
> used where you intend it, i.e. within a data center, and not where > Stephen fears it would be, i.e., on the broad Internet? For example, <= br> > what mechanism could a client use to guarantee that this sort of
> "static DH" intercept could NOT be used against them?

The server can send the plaintext to whomever it likes.

This is the solution enterprises can use today. Nothing can stop that from = happening. So I don't see why static DH is a) so essentially necessary and = b) so controversial.

>From a technical point I prefer using DH shares derived from
ServerRandom as this avoids certain bugs I've been known to exploit from ti= me to time.

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



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

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


The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this communicat= ion is directed. If you are not the intended recipient, you are hereby noti= fied that any viewing, copying, disclosure or distribution of this information is prohibited. Please notif= y the sender, by electronic mail or telephone, of any unintended receipt an= d delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
 --_000_kokbii6v34dsk060vpa2if7u1499483924916emailplusmobileiro_-- From nobody Fri Jul 7 21:38:28 2017 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 EDBB9128854 for ; Fri, 7 Jul 2017 21:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 AnDkbxitD8T4 for ; Fri, 7 Jul 2017 21:38:25 -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 0ADEB126B72 for ; Fri, 7 Jul 2017 21:38:24 -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=1499488705; x=1531024705; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mvHpeE+aF8CWLBWp31vOFd0ZWrLhLTjoEjrULSmsDw0=; b=zY0MYDmTzyxgVgS9zuJl5A3rudtQ0uYF4YpgqNaLtZGtVPzMaQYk+3FL XhJWvvegaPifnuaQLKpp1E7UGB0GzMhWlTXToPWtnsdhq7xgebduHijXw TuriM3pHYajnqyN7Y82jhmpKDCoE1kemGVf7zBmhBnDPmXf1J49CKsAaK AhIKv34QOjG7uE7Yb4G+lt47QDhLzPBJJnomqSD4EzR1l0eT7W2SpwdO/ z+NE3djMX1ulXz9pr4CA589BMJvl7FEYC/0abl5gPX+zlbNU9AU6PN2Hd ecxvrZ3O6x75V1mBBkK0Lhd6h8CfQJw2QdZrD0SLwEt76Sdqz913NFmBT A==; X-IronPort-AV: E=Sophos;i="5.40,326,1496059200"; d="scan'208";a="163881733" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Jul 2017 16:38:18 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 8 Jul 2017 16:38:18 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sat, 8 Jul 2017 16:38:18 +1200 From: Peter Gutmann To: Andreas Walz , "tls@ietf.org" Thread-Topic: [TLS] Truncated HMAC: what to do with the MAC key? Thread-Index: AQHS9yzumysdIWt+ckS1NsP2viyIy6JJWS1y Date: Sat, 8 Jul 2017 04:38:18 +0000 Message-ID: <1499488687918.75643@cs.auckland.ac.nz> References: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de>, <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de> In-Reply-To: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Truncated HMAC: what to do with the MAC key? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 04:38:27 -0000 Andreas Walz writes:=0A= =0A= >different TLS implementations do not seem to agree on how to implement=0A= >truncated HMAC=0A= =0A= It also says something about the status of this capability if three of the= =0A= four known implementations can't interoperate. If it's taken fourteen year= s=0A= (RFC 3546 was 2003) for someone to notice that the implementations don't=0A= work/interoperate then maybe the capability should be marked as deprecated = or=0A= obsolete or unused or something.=0A= =0A= Just out of interest Andreas, why were you checking this? In other words h= ow=0A= did it get noticed?=0A= =0A= Peter.=0A= From nobody Fri Jul 7 22:15:23 2017 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 23B32128D64 for ; Fri, 7 Jul 2017 22:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VRqBx2sOhFnx for ; Fri, 7 Jul 2017 22:15:20 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 B8FB7128768 for ; Fri, 7 Jul 2017 22:15:20 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id b40so41578482qtb.2 for ; Fri, 07 Jul 2017 22:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=kPBoxUxgeCl8xQ0CKM/7ndPinU4CMGf+9L1q6do+PvY=; b=FZhEDVGcDMhHhlcsWmJNMCopZXefv9x16Ou/q7GCCkMFq5BiI2Z9II04WtkrCqw7bn 8fqrSMmf/3JyhijngycvTmTwy3eAcNZQfboZH4x3E8aFq7WktvDfxl0v58JHNe/jCnbf tQv2vS7Mienx713tp7tdYAAtJsQ3/ChFeUy2mevEcRNVdWiS9LhD412bWwrSaVBlrfhD /hAqZhLaXwOgCFWgxe4HadCKfknJM/osLuBpDE6iBatDXRWxosIN04tGH3ogPrgMdGGh IoM4bK2TLzXUb/Y0mHBC0lyz610b1LFKM6XXTADG8YfZTDy5lgjOslSWqiMRrEFAeq2A Esng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=kPBoxUxgeCl8xQ0CKM/7ndPinU4CMGf+9L1q6do+PvY=; b=SXw0tfjY6Es5eje7JJp727ZcLnHpyd2CR/k9LUSoAsYyA5m9mHiyuRiaq4oi3jvlkt 1oSkDKEWZTatW5rLPDQouK7q+X2k80klrFmhUMiMuTa4TalyFSQPE/y3qF3Am7ifeMMj kf05QK1YqRsVojUosyQ+qXFkz9z34vvkVP83OMD2VQAa5xJ/BD+fMXQy5lOzLb7NdfSu wi11EaJQXrq9/CC0XGNjoYnhU3KMnWlClu6xxBmuLEPaCTgKUh2ANBzGkWVFUKc8bGfV UUGDfIoUhHntUDxCuMQHi8wodOHbZG0LVte0XUU9Qugy9xWjefLPxsXrC3q/pPCcYSko 7nrw== X-Gm-Message-State: AKS2vOzrigNPeWcLnnbaz7wXwIJNdc69/7fujE9E+w1674oFdSes63Pw e7QPeUBSOErMCgro X-Received: by 10.200.2.75 with SMTP id o11mr56008502qtg.26.1499490919765; Fri, 07 Jul 2017 22:15:19 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id b13sm4212443qta.25.2017.07.07.22.15.18 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 07 Jul 2017 22:15:19 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 8 Jul 2017 01:15:17 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de> <1499488687918.75643@cs.auckland.ac.nz> In-Reply-To: <1499488687918.75643@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201707080115.17663.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Truncated HMAC: what to do with the MAC key? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 05:15:22 -0000 On Saturday, July 08, 2017 12:38:18 am Peter Gutmann wrote: > Andreas Walz writes: > >different TLS implementations do not seem to agree on how to implement > >truncated HMAC > > It also says something about the status of this capability if three of the > four known implementations can't interoperate. If it's taken fourteen years > (RFC 3546 was 2003) for someone to notice that the implementations don't > work/interoperate then maybe the capability should be marked as deprecated or > obsolete or unused or something. In progress; the Truncated HMAC TLS extension is prohibited in implementations that support TLS 1.3+ as of the current draft. https://tools.ietf.org/html/draft-ietf-tls-tls13-21#page-127 Dave From nobody Fri Jul 7 22:26:45 2017 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 8051B128B4E for ; Fri, 7 Jul 2017 22:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[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 lgoHOXXG_Djt for ; Fri, 7 Jul 2017 22:26:43 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F66E12741D for ; Fri, 7 Jul 2017 22:26:43 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id 16so42279805qkg.2 for ; Fri, 07 Jul 2017 22:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=MbV9I2f2FHu7d/Yy2lBpw6QMWWzfHgJgGUBfAK1V3Ak=; b=KAoMAgIMlLxTHb/Blk+GkV98hXnab/6kmVk0tvPlw1oq1LxgRkDd7ZHQIUrMNFE/9G nM/2WetSqdYyU78FHRytJ/hjdJWLnfw4GI5wslF8XZUW6bevaiR7IMxjmJr4UblO42dB 0mKXF2ABnYlZmDNV6sXmEu72WchfajzmQHtveyqRQDBL800x898GLEQ6iUjafp3w62/A Trc54wlKF1evGaP7224A+npi4DE3HApxjb34dUtuOfb/kpjichvYGyr8HUuUYdLbwOZQ 8EeX1Ah0AyXY0D/r4m5q0l5tCXE9ZyU5uc1q3riB8iv82P3L+JIe78gq/bj6t3guliiL MClQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=MbV9I2f2FHu7d/Yy2lBpw6QMWWzfHgJgGUBfAK1V3Ak=; b=StAfy7QGzJid5a2iEJaFNJw8t2wB8b9Zm80iNQguaDULT1MgGSsaCF3qGHnz7Tqz/3 V9fvXfZm0lUmN4as+c6/1ieLPSJeQor9Smz7wre8esyLMLzy6G9oo6ReGS7X0WDw4VU7 X+TO5IGC/d/D6k1g9S6PpR5IrMv3UfDerBOtk/aHHmdOiiSSNS7pJhXH4NhQwBzLo7e6 cAaoljOrdxdf7D/19tOvjwqXNtqNIUHCeDATVfNWmeuoauIT5dNmr62lOPkBi9Q+u5Bh kn11N6Xl5mOHGuYkYfi2rO4yBPvZRTocUGxDKORRWVwqrKFoLvDi2EPcXDUM6BWqL7yI zbVg== X-Gm-Message-State: AIVw1112o/xN533QX7coMe18a/N3iS7aMg+K9fzqDk5GZ4h2AKLO7LKf vyaeEkgKqC7k7s9B X-Received: by 10.55.17.77 with SMTP id b74mr161552qkh.257.1499491602482; Fri, 07 Jul 2017 22:26:42 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id m49sm4345480qtf.32.2017.07.07.22.26.41 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 07 Jul 2017 22:26:41 -0700 (PDT) From: Dave Garrett To: "Salz, Rich" Date: Sat, 8 Jul 2017 01:26:40 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) Cc: "tls@ietf.org" , "Wang Haiguang" References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <201707062201.08455.davemgarrett@gmail.com> <5af19fe7273748579cb2537313667aba@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <5af19fe7273748579cb2537313667aba@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201707080126.40787.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 05:26:44 -0000 On Friday, July 07, 2017 11:14:10 am Salz, Rich wrote: > On Thursday, July 06, 2017 10:01:08 pm Dave Garrett wrote: > > Just as a clarification, all new RFCs should ideally meet all of the following > > criteria: > > * AEAD only > > * PFS only > > * TLS 1.2 and 1.3 support > > * no TLS 1.0 or 1.1 support (let alone SSL) > > * no use of broken hashes (MD5, SHA1, etc.) > > That's a good idea. > > Want to throw together a quick draft for curdle or AD-sponsored SAAG? I was just enumerating the points that seem to have a general consensus in this WG and come up each time a new doc is discussed. I was going for FAQ, not RFC. ;) That said, if we think there could be an actual benefit to formalizing this, probably with more detail (such as in Ilari's follow-up), that would be something I'd support. Dave From nobody Sat Jul 8 02:09:24 2017 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 B2C6013145A for ; Sat, 8 Jul 2017 02:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgD0bykkW5PA for ; Sat, 8 Jul 2017 02:09:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC8212EA7F for ; Sat, 8 Jul 2017 02:09:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E749ABE2F; Sat, 8 Jul 2017 10:09:16 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyG0TTD91Is4; Sat, 8 Jul 2017 10:09:15 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F9F4BE2C; Sat, 8 Jul 2017 10:09:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499504954; bh=pv9n3weNgePUlR7iNBrwD7yt5l+8PSPoCLMj3SCjwG4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=x93br1Pgpc4eRb4eugSqLchU+xGChPddi72C/1BkAI2pC33KsoHM9QF6sFyn5/f7B vG6opVrQSklGcvyKDOhI/GLLiTdc3RsC/vme57oWHxnt/Wz/D9RzQjdC8FRKzAA0Ly nDzByIazgo/5+Cwp2HNSLxuJ/TcMTmDSDBnBSCmw= To: "Ackermann, Michael" , Watson Ladd , Christian Huitema Cc: "tls@ietf.org" References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1ab70d05-235e-5a4f-a44b-8b4eadd9ddd8@cs.tcd.ie> Date: Sat, 8 Jul 2017 10:09:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QExRDGkt8eQ86aWvBVfDQVAPKXbn7UJ7C" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 09:09:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QExRDGkt8eQ86aWvBVfDQVAPKXbn7UJ7C Content-Type: multipart/mixed; boundary="Ulb4MmEXpRfpph8Vj3qNb4eFuQAahAo0C"; protected-headers="v1" From: Stephen Farrell To: "Ackermann, Michael" , Watson Ladd , Christian Huitema Cc: "tls@ietf.org" Message-ID: <1ab70d05-235e-5a4f-a44b-8b4eadd9ddd8@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> In-Reply-To: --Ulb4MmEXpRfpph8Vj3qNb4eFuQAahAo0C Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/07/17 03:06, Ackermann, Michael wrote: > Converting all session traffic to clear text is not a viable > alternative for ANY enterprises or industries that I am aware of. In > particular those in financial sectors. Security policies, legislation > and in many cases just good practice would not allow for this. We are > compelled by these factors to encrypt all data in motion. But we > still need to manage our applications, networks, servers and clients. > Hence the need to decrypt traffic as outlined in this draft. That assertion of necessity is blatantly false. It is entirely feasible to decrypt and re-encrypt in many cases and for that to be efficient and to meet regulatory needs. If some systems are so badly designed that doing that while updating to tls1.3 is a showstopper then that's down to bad design or other bad practices. Fixing those is the place to spend effort instead of spending effort on breaking TLS. Other users of TLS ought not suffer on the basis of such bad reasoning. S. >=20 > -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On > Behalf Of Watson Ladd Sent: Friday, July 7, 2017 9:40 PM To: > Christian Huitema Cc: tls@ietf.org Subject: Re: > [TLS] draft-green-tls-static-dh-in-tls13-01 >=20 > On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema > wrote: >>=20 >>=20 >> On 7/7/2017 2:54 PM, Russ Housley wrote: >>> Stephen: ... >>>> And also: I'm sorry to have to say it, but I consider that >>>> attempted weasel wording around the clear intent of 2804. The >>>> clear and real effect if your wiretapping proposal were >>>> standardised by the IETF would be that we'd be standardising >>>> ways in which TLS servers can be compelled into breaking TLS - >>>> it'd be a standard wiretapping API that'd be insisted upon in >>>> many places and would mean significantly degrading TLS (only >>>> *the* most important security protocol we maintain) and the >>>> community's perception of the IETF. It's all a shockingly bad >>>> idea. >>> I clearly disagree. Otherwise, I would not have put any work >>> into the draft. >> Russ, >>=20 >> What are the specific mechanisms that would allow this technique to >> be used where you intend it, i.e. within a data center, and not >> where Stephen fears it would be, i.e., on the broad Internet? For >> example, what mechanism could a client use to guarantee that this >> sort of "static DH" intercept could NOT be used against them? >=20 > The server can send the plaintext to whomever it likes. >=20 > This is the solution enterprises can use today. Nothing can stop that > from happening. So I don't see why static DH is a) so essentially > necessary and b) so controversial. >=20 >> From a technical point I prefer using DH shares derived from > ServerRandom as this avoids certain bugs I've been known to exploit > from time to time. >=20 >>=20 >> -- Christian Huitema >>=20 >>=20 >> _______________________________________________ TLS mailing list=20 >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 > -- "Man is born free, but everywhere he is in chains". --Rousseau. >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > The information contained in this communication is highly > confidential and is intended solely for the use of the individual(s) > to whom this communication is directed. If you are not the intended > recipient, you are hereby notified that any viewing, copying, > disclosure or distribution of this information is prohibited. Please > notify the sender, by electronic mail or telephone, of any unintended > receipt and delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan > are nonprofit corporations and independent licensees of the Blue > Cross and Blue Shield Association. >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --Ulb4MmEXpRfpph8Vj3qNb4eFuQAahAo0C-- --QExRDGkt8eQ86aWvBVfDQVAPKXbn7UJ7C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYKE4AAoJEC88hzaAX42iQgIH/02Alhf6bNAeCctN+4oI7qcR BSb9R3e5/n3EBOecOYnutek1Ms62+h2ocGaFd/PfGDNwB7QRpDhW3HfzejgR+RFB qClZKeOpe8idk86TV8mprWQ/gX1Bn5oStMoG49KBYpE9oi4uTDMbjIkwP3NzJXGV fSfbO7qFjp+JcYGhLXLnZu7d/YQ5Wy4WLaeY8EcHyEQK0xzc+LFsimvgfTqsYY+1 L8+4GRYkRuWA+hxC9GFv2o5EdvUWTI9z5xhKN2bYDpuI2AHVs6s/CWm3Yz4iniak 5FDxM8HNH6vjEj5HQZLhpprdG6zU9mYWiWk39D5NBpJOPBUu/BMXNna7ztwaLhk= =0qEw -----END PGP SIGNATURE----- --QExRDGkt8eQ86aWvBVfDQVAPKXbn7UJ7C-- From nobody Sat Jul 8 02:17:29 2017 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 3773112F26C for ; Sat, 8 Jul 2017 02:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KikCt1m0D1CA for ; Sat, 8 Jul 2017 02:17:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9069312EB1B for ; Sat, 8 Jul 2017 02:17:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 37BD2BE2F; Sat, 8 Jul 2017 10:17:25 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHDV5nqPrgT7; Sat, 8 Jul 2017 10:17:24 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 96656BE2C; Sat, 8 Jul 2017 10:17:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499505444; bh=IGri1MlQCP83ylFFqQxT2edQtkTbx2cfVZFQgYmclD8=; h=To:Cc:From:Subject:Date:From; b=fZZJml+4mABZ090rWqYstpZhfFoLBfEJpRUa9XUJihnkDbHvW9M6ZRdrJcNN9tW2R 7N9eZ/PJFYGYHsJNJBiuFvRE/F7w+jHA2vs17EPdl0/3JA6t2xiX5LIAgMDWAYCLYe WLsp2tI+j/6zSHXYvJBA9ES/3ov+eESLbZO5MvUE= To: tls chair Cc: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sat, 8 Jul 2017 10:17:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aQtVkLdCPvsLsCPA7QiXkNX9fsNU1uEhk" Archived-At: Subject: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 09:17:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aQtVkLdCPvsLsCPA7QiXkNX9fsNU1uEhk Content-Type: multipart/mixed; boundary="5fMHtNImcAATqfGMwB6N01lBibR4GSJ91"; protected-headers="v1" From: Stephen Farrell To: tls chair Cc: "tls@ietf.org" Message-ID: Subject: chairs - please shutdown wiretapping discussion... --5fMHtNImcAATqfGMwB6N01lBibR4GSJ91 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Sean/Joe, This is a request that you, as chairs, shut down the distracting wiretapping discussion, at least until DTLS1.3 is done. I have planned to spend time reading draft 21 and DTLS, but that won't happen if we keep having to fight off the latest attempts to break TLS. I'd not be surprised if I weren't the only one finding that distraction an irritating waste of time. Finishing TLS1.3 and getting DTLS1.3 on the way surely needs to not be constantly de-railed by these attempts to break TLS. Therefore I'd ask that you declare this discussion closed for at least that long (i.e until DTLS1.3 is done). I'd also ask that you not allocate agenda time for wiretapping in Prague. Thanks, S. --5fMHtNImcAATqfGMwB6N01lBibR4GSJ91-- --aQtVkLdCPvsLsCPA7QiXkNX9fsNU1uEhk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYKMhAAoJEC88hzaAX42i8UYH/0XqKaF/c14mMPUnmufq99Qc 76sVG6wya8NLxM0ecEHT55OLCCWEcRGKorPu0100EDPsckz1ElaVEIAZJKd+0a6S VNds0SveCMP7apchUjHpvirLbmdzloyteDjpjdiIEzYCqMIqIh26EKst1ZZunZg6 X3l0gUpC7SwHQf3A0AlDCIL+gI/sRqf7LLe2Aer83APmKrTpkjz8JQcm7iORDT9+ QpLh+9IZTRGaVW8cISouuBTzzdwsC4bBB6v0hszu+g3TWVGaWfXjZwKsppWjc+H0 yXkWqxTCdZ3gtX8eiNERRszzvA7aZ6Lr00EVXexrzI8Gvs9iGf1LHZ6kMBshz1k= =nS1+ -----END PGP SIGNATURE----- --aQtVkLdCPvsLsCPA7QiXkNX9fsNU1uEhk-- From nobody Sat Jul 8 04:11:16 2017 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 5E153129B50 for ; Sat, 8 Jul 2017 04:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[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 Huv8qWzRYVzy for ; Sat, 8 Jul 2017 04:11:13 -0700 (PDT) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA56C1270AC for ; Sat, 8 Jul 2017 04:11:12 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 68CF9203A59 for ; Sat, 8 Jul 2017 11:11:09 +0000 (UTC) Received: from [192.168.0.65] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Sat, 8 Jul 2017 13:11:10 +0200 References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> To: From: Marco Tiloca X-Forwarded-Message-Id: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> Message-ID: Date: Sat, 8 Jul 2017 13:10:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="igwMnNMNbNqpcFw0hIGgi55Wcuq6j2s8h" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=aq3CMWRV c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=G3gG6ho9WtcA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=uTM5gQLEAAAA:8 a=hirsTDsGu0qzsSCDrqwA:9 a=6zdyQuB4AaFM9xdL:21 a=ZR3JJYYAym9mUYpd:21 a=QEXdDO2ut3YA:10 a=_lrG7hgxGQ5wgcGW:21 a=X0zvtOVx-MSbVPgO:21 a=PuQgeVrl5JICoyxd:21 a=_W_S_7VecoQA:10 a=RTfph-VxEUFQ3jqlRvoA:9 a=ONNS8QRKHyMA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=X0a8wEfk66sNBbu13Lvv:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 11:11:15 -0000 --igwMnNMNbNqpcFw0hIGgi55Wcuq6j2s8h Content-Type: multipart/mixed; boundary="WXTNHhrctB54UDIVsaRI2PgAirsg0e9jU"; protected-headers="v1" From: Marco Tiloca To: tls@ietf.org Message-ID: Subject: Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> In-Reply-To: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> --WXTNHhrctB54UDIVsaRI2PgAirsg0e9jU Content-Type: multipart/alternative; boundary="------------A5B22619DC5F4D6DFA2CB6D5" Content-Language: en-US This is a multi-part message in MIME format. --------------A5B22619DC5F4D6DFA2CB6D5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, FYI, we have recently submitted a new draft proposing an extension for (D)TLS 1.2/1.3. The solution described in the draft addresses Denial of Service attacks against the handshake protocol, allowing servers to promptly abort invalid session set ups. Feedback and comments are of course very welcome. Thanks a lot! Best regards, /Marco -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt Date: Wed, 28 Jun 2017 07:40:45 -0700 From: internet-drafts@ietf.org To: Marco Tiloca , Ludwig Seitz , Maarten Hoeve A new version of I-D, draft-tiloca-tls-dos-handshake-00.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-tls-dos-handshake Revision: 00 Title: Extension for protecting (D)TLS handshakes against Denial of Serv= ice Document date: 2017-06-28 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-tiloca-tls-dos= -handshake-00.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-han= dshake/ Htmlized: https://tools.ietf.org/html/draft-tiloca-tls-dos-handshak= e-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-tls-do= s-handshake-00 Abstract: This document describes an extension for TLS and DTLS to protect the server from Denial of Service attacks against the handshake protocol. The extension includes a Message Authentication Code (MAC) over the ClientHello message, computed by the Client through key material obtained from a Trust Anchor entity. The server registered at the Trust Anchor derives the same key material and checks the MAC to determine whether continuing or aborting the handshake. = =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------A5B22619DC5F4D6DFA2CB6D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,

FYI, we have recently submitted a new draft proposing an extension for (D)TLS 1.2/1.3.

The solution described in the draft addresses Denial of Service attacks against the handshake protocol, allowing servers to promptly abort invalid session set ups.

Feedback and comments are of course very welcome. Thanks a lot!

Best regards,
/Marco

-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
Dat= e: Wed, 28 Jun 2017 07:40:45 -0700
Fro= m: internet-drafts@ietf.org
To:= Marco Tiloca <marco.tiloca@ri.se>, Ludwig Seitz <ludwig.seitz@ri.se>, Maarten Hoeve <maarten.hoeve@encs.eu> 


A new version of I-D, draft-tiloca-tls-dos-handshake-00.txt
has been successfully submitted by Marco Tiloca and posted to the
IETF repository.

Name:		draft-tiloca-tls-dos-handshake
Revision:	00
Title:		Extension for protecting (D)TLS handshakes against Denial of Serv=
ice
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www=
=2Eietf.org/internet-drafts/draft-tiloca-tls-dos-handshake-00.txt
Status:         https://datatracker.i=
etf.org/doc/draft-tiloca-tls-dos-handshake/
Htmlized:       https://tools.ietf.org/h=
tml/draft-tiloca-tls-dos-handshake-00
Htmlized:       https://datatr=
acker.ietf.org/doc/html/draft-tiloca-tls-dos-handshake-00


Abstract:
   This document describes an extension for TLS and DTLS to protect the
   server from Denial of Service attacks against the handshake protocol.
   The extension includes a Message Authentication Code (MAC) over the
   ClientHello message, computed by the Client through key material
   obtained from a Trust Anchor entity.  The server registered at the
   Trust Anchor derives the same key material and checks the MAC to
   determine whether continuing or aborting the handshake.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------A5B22619DC5F4D6DFA2CB6D5-- --WXTNHhrctB54UDIVsaRI2PgAirsg0e9jU-- --igwMnNMNbNqpcFw0hIGgi55Wcuq6j2s8h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYL3NAAoJEO4mZLQOWNpDeCIH/1aJbdfCcrvFIno+kKHu3l8X R3xioBtJtsmhY8xIObVHX+xXgYcC2NUQEmvDMSQ3IAh9IqszTtb5kbhYeRCJqfer pu8uV80uHA25UVLf8LGzu7pShi/O/vQa0pmsSfNO8JDM4NqvDfKRZGFiCPrTnhAo WOX06eNZreDcSX/w+BcXclgsAq0ZS83G6fkP1uqGFhy2two42cGP8txYm8WQcGVN eWmeUFn9KFp8hupVXCL3w87zLjzYcAW2jbqr4RwWTgft9Rz0eyMd36wMWmv1DKAu Vo/xR/01jF97PQn+Cvlr+QIYcU7YKkoV2hJ4mlmGQIlgGF92hNdnlDix8CwRJW4= =ZcMJ -----END PGP SIGNATURE----- --igwMnNMNbNqpcFw0hIGgi55Wcuq6j2s8h-- From nobody Sat Jul 8 05:36:34 2017 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 82925126BFD for ; Sat, 8 Jul 2017 05:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NSlO8FFZGbTy for ; Sat, 8 Jul 2017 05:36:32 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F9C124D37 for ; Sat, 8 Jul 2017 05:36:31 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id z45so13665474wrb.2 for ; Sat, 08 Jul 2017 05:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zQOEyOJzE9INz2fO1taB/EpunV9WJ22g2A27Dx6lEsc=; b=VpcrNzffYutys7cBHbPVA6WzMnZx0i6jSDo3ALE9oNTNGi5SgisVtH9mT3AdpK5f4g T4/91N5ZsrKWsNXH2jzHHCHLNXsniG3z9uviEp8xTn3DDR7cQK261b2nHMmDurmBaHrJ wKRIis307d+L4iBRX44+mcGft+NQxrsTd04ol64XZJTRyrG+9ntLgKEsZaB4arNOEmGT Nrg2bnWrarANKd8YB/AafJtOB+GQEx8RqLbEznzi1a0VW39XTh+zTNYzOFvhRbf7Nrso vOzgvrZdHfTe58oJEasEB6WCr38nwQGQqM+GtwbFiHuESmymfHwImuBgsUFvXDGmQ//9 ug3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zQOEyOJzE9INz2fO1taB/EpunV9WJ22g2A27Dx6lEsc=; b=dqgpgsK0NH5BpcfOhXDvrHB1sFtxRxkLqDTTU7HUwCMMIMI3UHMgKJxjM8JZXUWwpl C7C1W7xHgY0qSeOhs/fdeY7h6PxtioQ2T49Wp6Rjef3EHAuaTKzrFvEznFKwg2q4FXIR d0M5LhlLOP0e9eb9mBdW6tmAV2HFR1+dzz3whhy4C/6oImaKdSqb6GRnHIdEob/bV8yC deCbl5gWV2pbvNqzkdVu+qJJAjLfCBLabQa0E3wHHkzSzM2RZu3Q+N3BYi13HLaAjtzU tdP7ERq02QrlsGD0azyzSMdX3MmuIyYbwqdviK7QGXM2/NDmtekHE7pgDbOLzQMnD2Je FWTw== X-Gm-Message-State: AIVw113UZI+LlSV7KUfOsNC0xABWf20wvYtfNrN10vn3XA7+6hWAT1fy lDgpMuz7lRt1DA== X-Received: by 10.80.152.194 with SMTP id j60mr5263745edb.98.1499517390411; Sat, 08 Jul 2017 05:36:30 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id c11sm3774087eda.0.2017.07.08.05.36.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 05:36:29 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E151E9D5-4C9D-4AA6-8E86-28C6BEAE23CB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 8 Jul 2017 15:36:26 +0300 In-Reply-To: Cc: "Ackermann, Michael" , Watson Ladd , Christian Huitema , "tls@ietf.org" To: Timothy Jackson References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 12:36:33 -0000 --Apple-Mail=_E151E9D5-4C9D-4AA6-8E86-28C6BEAE23CB Content-Type: multipart/alternative; boundary="Apple-Mail=_06E86950-45A0-4EDF-854A-A29E8309CEC9" --Apple-Mail=_06E86950-45A0-4EDF-854A-A29E8309CEC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Jul 2017, at 6:18, Timothy Jackson = wrote: >=20 > As an earlier poster asked, what advantage does this approach have = over TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which = I am familiar is able to terminate at TLS connection, = inspect/copy/filter, and then encrypt on a new TLS sessions. >=20 > For high performance customers, the SSL accelerators can be sandwiched = around the filter so all the crypto is done in hardware. >=20 > The ways to prevent TLS inspection are cert pinning and client cert = auth. If this is only within one's data center, then those features can = be disabled if necessary, no? >=20 > What use case am I missing that can't be achieved better by other = means than static keys? They would like to store traffic captures encrypted and be able to = decrypt them a little later if that is necessary. Storing plaintext is = something that auditors (rightfully!) don=E2=80=99t like. They also don=E2=80=99t want to install TLS proxies all over the place. = That=E2=80=99s a large extra expense for them. Yoav --Apple-Mail=_06E86950-45A0-4EDF-854A-A29E8309CEC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 8 Jul 2017, at 6:18, Timothy Jackson <tjackson@mobileiron.com> wrote:

As an earlier poster asked, what advantage = does this approach have over TLS-inspecting proxies? Every IPS/IDS/next = gen firewall with which I am familiar is able to terminate at TLS = connection, inspect/copy/filter, and then encrypt on a new TLS = sessions. 

For high performance customers, the SSL = accelerators can be sandwiched around the filter so all the crypto is = done in hardware.

The ways to prevent TLS = inspection are cert pinning and client cert auth. If this is only within = one's data center, then those features can be disabled if necessary, = no?

What use case am I missing that can't = be achieved better by other means than static keys?

They would like to store traffic captures = encrypted and be able to decrypt them a little later if that is = necessary. Storing plaintext is something that auditors (rightfully!) = don=E2=80=99t like.

They also don=E2=80=99t want to install TLS proxies all over = the place.  That=E2=80=99s a large extra expense for = them.

Yoav

= --Apple-Mail=_06E86950-45A0-4EDF-854A-A29E8309CEC9-- --Apple-Mail=_E151E9D5-4C9D-4AA6-8E86-28C6BEAE23CB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZYNHKAAoJELhJCxUKWMyZUCoIALqgq29sNn4DuWxeBS6RtNCE 0ewEaoyYL5vIp4JIvEE9TOgInd/3AUTX15txB6pZDsa89d6O4SApuZeibOigoeKy v6JwDMu6/qg+tQyrJCKJ4/G9x7HPvgxcIClrxz90nZgMOd8hj3f1OIZzLYOtfo3q T99iVjqRZS3sQQQLH9Xd22MtE7zcRcHzIUvZqvtpoUOR6MiUVm2zJaJYpFwRZ53B njBWWjsQi3BQ/wWj9Ntk2UbRoiOARuMpbOKcgr0z4dbJbLzzAhjRpxotWt6Swidc YpKpMDGNoqeOu/VbujBokQ3Iw/KQSk5szj8WXDRL2426NhpoeJLXbKsMo3FRs4Y= =Z84j -----END PGP SIGNATURE----- --Apple-Mail=_E151E9D5-4C9D-4AA6-8E86-28C6BEAE23CB-- From nobody Sat Jul 8 06:55:11 2017 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 04CF4127286 for ; Sat, 8 Jul 2017 06:55:10 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU8goDYVVZvM for ; Sat, 8 Jul 2017 06:55:07 -0700 (PDT) Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [IPv6:2001:7c0:1300:500b::11:25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0271129459 for ; Sat, 8 Jul 2017 06:54:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id 9FC5622C7B08 for ; Sat, 8 Jul 2017 15:54:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1499522083; x= 1500386084; bh=pRlr/HfR15eoG2vJzESvxzuVbfes14jOgqMRrGuv8Ro=; b=g qBmNc3JQAsHTNrjfZDgt20cm/lE3iMUGgrZ2Cpwwh71+brhFbLMmORPen4wXRqpb ZaH9GXMIw3ST9cBxw6fN3g1FfVGX7KajZ5S2a++rR4IojAtF6b8TuTOyGmQagans C1ILe4weDgey0/rjKLnSw/1vVH45CjEdE3NU82eUME= X-Virus-Scanned: amavisd-new at hs-offenburg.de Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YM3NbpFPrMn for ; Sat, 8 Jul 2017 15:54:43 +0200 (CEST) Received: from gwia2.rz.hs-offenburg.de (stud.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id 1897122C7AF6 for ; Sat, 8 Jul 2017 15:54:42 +0200 (CEST) Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Sat, 08 Jul 2017 15:54:41 +0200 Message-Id: <5960E420020000AC0013692B@gwia2.rz.hs-offenburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Sat, 08 Jul 2017 15:54:40 +0200 From: "Andreas Walz" To: References: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de> <1499488687918.75643@cs.auckland.ac.nz> <201707080115.17663.davemgarrett@gmail.com> In-Reply-To: <201707080115.17663.davemgarrett@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part85BDB130.4__=" Archived-At: Subject: [TLS] Antw: Re: Truncated HMAC: what to do with the MAC key? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 13:55:10 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part85BDB130.4__= Content-Type: multipart/alternative; boundary="=__Part85BDB130.5__=" --=__Part85BDB130.5__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks for your feedback. One other thing I could image is that truncated_hmac is mostly used in = closed systems where one and the same implementation is used on both = sides.=20 @Peter: We are developing software for Smart Metering in Germany where TLS = is used over the (wireless) Metering Bus. The corresponding specification = [1] says about truncated_hmac: "servers shall support...". Cheers, Andi [1] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Techn= ischeRichtlinien/TR03109/TR-03109-1_Anlage_Feinspezifikation_Drahtlose_LMN-= Schnittstelle-Teil2.pdf?__blob=3DpublicationFile&v=3D1 >>> Dave Garrett 08.07.17 7.15 Uhr >>> On Saturday, July 08, 2017 12:38:18 am Peter Gutmann wrote: > Andreas Walz writes: > >different TLS implementations do not seem to agree on how to implement > >truncated HMAC >=20 > It also says something about the status of this capability if three of = the > four known implementations can't interoperate. If it's taken fourteen = years > (RFC 3546 was 2003) for someone to notice that the implementations don't > work/interoperate then maybe the capability should be marked as = deprecated or > obsolete or unused or something. In progress; the Truncated HMAC TLS extension is prohibited in implementati= ons that support TLS 1.3+ as of the current draft. https://tools.ietf.org/html/draft-ietf-tls-tls13-21#page-127 Dave --=__Part85BDB130.5__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML =0Abody p =0A{ =0A margin: 0px; =0A}=0A
Thanks for your feedback.

One other thing I could = image is that truncated_hmac is mostly used in closed systems where one = and the same implementation is used on both sides. 

@Pet= er: We are developing software for Smart Metering in Germany where TLS is = used over the (wireless) Metering Bus. The corresponding specification [1] = says about truncated_hmac: "servers shall support...".

Cheers,
Andi


>>> Dave Garrett <davemgarrett@gmail= .com> 08.07.17 7.15 Uhr >>>
On Saturday, July 08, = 2017 12:38:18 am Peter Gutmann wrote:
> Andreas Walz <andreas.walz= @hs-offenburg.de> writes:
> >different TLS implementations do = not seem to agree on how to implement
> >truncated HMAC
> =
> It also says something about the status of this capability if = three of the
> four known implementations can't interoperate. If = it's taken fourteen years
> (RFC 3546 was 2003) for someone to = notice that the implementations don't
> work/interoperate then maybe = the capability should be marked as deprecated or
> obsolete or = unused or something.

In progress; the Truncated HMAC TLS extension = is prohibited in implementations that support TLS 1.3+ as of the current = draft.

https://tools.ietf.org/html/draft-ietf-tls-tls13-21#page-127<= br>

Dave

--=__Part85BDB130.5__=-- --=__Part85BDB130.4__=-- From nobody Sat Jul 8 07:27:23 2017 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 C02A6129AF4 for ; Sat, 8 Jul 2017 07:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 46AjJZDxAZT3 for ; Sat, 8 Jul 2017 07:27:20 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 BA9A6129AF1 for ; Sat, 8 Jul 2017 07:27:19 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id c11so82360073wrc.3 for ; Sat, 08 Jul 2017 07:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=1BL6zeZFEfZqVSl+IhixR7E0o+YYd1VPAt6HLCchzw8=; b=ZFVDdY3pPAM9pkvCQCOVomj16nDkwz3U0a+VgORptwsiFqD7/gZYeF7C+NKR9hNQRj +N7FJ++pqcnednbWg+C4H7gMuK7KuFBSSgQ17pgeyLbYSswcONlzd+xN3+QbSmhTmkEb h68hX2q+RTAXyWncR5gtATY6wWI2VkMsd2EZCPgn91wn9YNlt0pYGZypkn8kyCd0VuPF 3YZWCp/j1yW2ZuB+NPdTzS+v8SCXv1VX5sB1vPz5g/NYSg7RBoOHxpW/PLosKWoI1bi8 j1tmEjqJXcTtt905QP2sVhtUfWETCKgkFCopghQIWlxRgKlPlvTE6tY2S9ZFr6WAzZnP 85tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=1BL6zeZFEfZqVSl+IhixR7E0o+YYd1VPAt6HLCchzw8=; b=jjvV/eDpA5E4IcxN7OU6476l7mEP84vT7xj61IkHYCIjMPf8cgiJYmTbSlNTPlKAJe rHP3vRRLsKlpOkV/oMdAVGWie839LLnKcrNqcCLPL4PjsIj6hYoIRA+zdR4oZ0NUO/I6 ZfT8gq34rTpyeyoqoRvPp+kWq2GAm+cLMiujdUKauAR8VvvhOYUX7BA4aSe7oTMwm3fJ f7qCIqgctnMDT4IG0zQv/TJmb3NWUycxdwQuX2Rv6G8iLCFVQJu+0lj+1+xb961X37EA 6k2iYxg9e2vJ2m/6hWgtIu+Ad399yNZ3/OhYg4bxGgLiCsFxzCzDCLydBr9MJpT3ln/s mBgw== X-Gm-Message-State: AIVw113iIq6aVqxBcyfCuWH2ViJ65Yq1k/N0uQA2DI9AI61mRsMZds5f Oj90a34zxxkYGamhx5E= X-Received: by 10.223.142.80 with SMTP id n74mr3550078wrb.131.1499524037975; Sat, 08 Jul 2017 07:27:17 -0700 (PDT) Received: from [10.0.0.9] (bzq-79-182-49-113.red.bezeqint.net. [79.182.49.113]) by smtp.gmail.com with ESMTPSA id p140sm3341112wmb.28.2017.07.08.07.27.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 07:27:17 -0700 (PDT) To: Stephen Farrell , tls chair Cc: "tls@ietf.org" References: From: Yaron Sheffer Message-ID: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> Date: Sat, 8 Jul 2017 17:27:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E62BAAB4BD264B58F7ED5865" Content-Language: en-US Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 14:27:22 -0000 This is a multi-part message in MIME format. --------------E62BAAB4BD264B58F7ED5865 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Stephen, Like you, I am very unhappy with this draft, and would not support its adoption as a WG draft. However I think that open discussion is in general good, and that the best venue for discussion of this draft is this mailing list. Even if some of this discussion devolves into generic "are we pro or against wiretapping" questions. I don't think this is a significant distraction that could derail (D)TLS, moreover, you will recall that in Chicago several new drafts were adopted to the working group. So the WG does feel that TLS is in good enough shape that we can spend some bandwidth on other things. Thanks, Yaron On 08/07/17 12:17, Stephen Farrell wrote: > Sean/Joe, > > This is a request that you, as chairs, shut down the distracting > wiretapping discussion, at least until DTLS1.3 is done. > > I have planned to spend time reading draft 21 and DTLS, but that > won't happen if we keep having to fight off the latest attempts > to break TLS. I'd not be surprised if I weren't the only one > finding that distraction an irritating waste of time. Finishing > TLS1.3 and getting DTLS1.3 on the way surely needs to not be > constantly de-railed by these attempts to break TLS. > > Therefore I'd ask that you declare this discussion closed for at > least that long (i.e until DTLS1.3 is done). > > I'd also ask that you not allocate agenda time for wiretapping > in Prague. > > Thanks, > S. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------E62BAAB4BD264B58F7ED5865 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Stephen,

Like you, I am very unhappy with this draft, and would not support its adoption as a WG draft. However I think that open discussion is in general good, and that the best venue for discussion of this draft is this mailing list. Even if some of this discussion devolves into generic "are we pro or against wiretapping" questions.

I don't think this is a significant distraction that could derail (D)TLS, moreover, you will recall that in Chicago several new drafts were adopted to the working group. So the WG does feel that TLS is in good enough shape that we can spend some bandwidth on other things.

Thanks,

    Yaron


On 08/07/17 12:17, Stephen Farrell wrote:
Sean/Joe,

This is a request that you, as chairs, shut down the distracting
wiretapping discussion, at least until DTLS1.3 is done.

I have planned to spend time reading draft 21 and DTLS, but that
won't happen if we keep having to fight off the latest attempts
to break TLS. I'd not be surprised if I weren't the only one
finding that distraction an irritating waste of time. Finishing
TLS1.3 and getting DTLS1.3 on the way surely needs to not be
constantly de-railed by these attempts to break TLS.

Therefore I'd ask that you declare this discussion closed for at
least that long (i.e until DTLS1.3 is done).

I'd also ask that you not allocate agenda time for wiretapping
in Prague.

Thanks,
S.




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

--------------E62BAAB4BD264B58F7ED5865-- From nobody Sat Jul 8 07:33:23 2017 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 93511129AF4 for ; Sat, 8 Jul 2017 07:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qco9x5oUkSbf for ; Sat, 8 Jul 2017 07:33:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204521201F2 for ; Sat, 8 Jul 2017 07:33:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 986C4BE2F; Sat, 8 Jul 2017 15:33:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JJCJw8qi5lw; Sat, 8 Jul 2017 15:33:15 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2EE29BE2C; Sat, 8 Jul 2017 15:33:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499524395; bh=MFtj7gUG4fvFpZ5vEYrGsWADCrHDl0vy/qvo0i7DQpM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=V/H9LVtNHE89D9zRbdVTNperGjCspKrrZGDFMOWMWa2FofheJGaCfyzczQBB3MZyB twqeIOZScmsNyMf785zn9ZyAZ5JRKXVA/Y2LH3wVr6jUprQrkiGr7n4OQtaWunZuXI /vrVe2MX0RkVJtZ/UzqGzKMB8BDv6DjKVRt03Vps= To: Yaron Sheffer , tls chair Cc: "tls@ietf.org" References: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> Date: Sat, 8 Jul 2017 15:33:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QpNkfEX5utLIEd129HlKf0vRGn3mXRItw" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 14:33:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QpNkfEX5utLIEd129HlKf0vRGn3mXRItw Content-Type: multipart/mixed; boundary="C5RJpKRkpC53rTXgjfqq2abAMDeFX7hWv"; protected-headers="v1" From: Stephen Farrell To: Yaron Sheffer , tls chair Cc: "tls@ietf.org" Message-ID: <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> In-Reply-To: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> --C5RJpKRkpC53rTXgjfqq2abAMDeFX7hWv Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/07/17 15:27, Yaron Sheffer wrote: > Hi Stephen, >=20 > Like you, I am very unhappy with this draft, and would not support its > adoption as a WG draft. However I think that open discussion is in > general good, and that the best venue for discussion of this draft is > this mailing list. Even if some of this discussion devolves into generi= c > "are we pro or against wiretapping" questions. FWIW I believe that we have had that discussion about breaking tls over and over on this and other lists. I see no value in doing it yet again, even if the proximate cause is a new variation of the "here's a way to break tls" class of drafts. (Someday we should find someone who'd document all the broken break-tls ideas that have been rightly rejected over the years.) >=20 > I don't think this is a significant distraction that could derail > (D)TLS, moreover, you will recall that in Chicago several new drafts > were adopted to the working group. So the WG does feel that TLS is in > good enough shape that we can spend some bandwidth on other things. Maybe I'm more easily distracted, at least by this topic;-) Anyway, I'm fine that it's for the chairs to figure that out. S. > Thanks, >=20 > Yaron >=20 >=20 > On 08/07/17 12:17, Stephen Farrell wrote: >> Sean/Joe, >> >> This is a request that you, as chairs, shut down the distracting >> wiretapping discussion, at least until DTLS1.3 is done. >> >> I have planned to spend time reading draft 21 and DTLS, but that >> won't happen if we keep having to fight off the latest attempts >> to break TLS. I'd not be surprised if I weren't the only one >> finding that distraction an irritating waste of time. Finishing >> TLS1.3 and getting DTLS1.3 on the way surely needs to not be >> constantly de-railed by these attempts to break TLS. >> >> Therefore I'd ask that you declare this discussion closed for at >> least that long (i.e until DTLS1.3 is done). >> >> I'd also ask that you not allocate agenda time for wiretapping >> in Prague. >> >> Thanks, >> S. >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 --C5RJpKRkpC53rTXgjfqq2abAMDeFX7hWv-- --QpNkfEX5utLIEd129HlKf0vRGn3mXRItw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYO0nAAoJEC88hzaAX42iNagH+wYhOVyEfduQzjC80lfYBmi3 ofGmm03Y+WA7Nd2hYnxaZdU0d6Hxg76ODECZsS9i+6bUBh/E2HJ0ymprjzDbdLVs Z+4jG8+v2Gac9nwQFiq8a9hzcZzQqBw7+AqI7st+pJu8r1BuXL9DNO/k3chYARzf DULO5f+mfbJYdtkUzGtjB1n0xBngdUU0E/N91OGWLtQeV6rQ3OoB6iNayOT8a04F 7GIZYA+9GFkoLikQC19A0gAeUZcZ/TVb6ScscBCjH/gnolk0GPOk8rVtS5vMD8gQ vhDxUeF2YIOAN8IpT4PXy+LEXGybLBjHNtRJASFJNVs/AHPiJS20qEd8K9wFptQ= =Exz7 -----END PGP SIGNATURE----- --QpNkfEX5utLIEd129HlKf0vRGn3mXRItw-- From nobody Sat Jul 8 07:46:29 2017 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 0BD78129B2A for ; Sat, 8 Jul 2017 07:46:28 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 so6u52jMwcmy for ; Sat, 8 Jul 2017 07:46:26 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002: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 22688129B01 for ; Sat, 8 Jul 2017 07:46:26 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id f194so17961005yba.3 for ; Sat, 08 Jul 2017 07:46:26 -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=wHjMcCY5LI7nv43R60cKfDKgzW3eQ+gkpBjGXKj82jo=; b=LyDXq2Mkqbo5CTNt42gqvQr8hYPACs8PTOzP0qxtDzlnOoYOxa164QCI2Lr02lJCys bKc92BaFy60SEC+Ozc7yEEBX46Yf+dquKy+fjSnJkD5mNU73VYWi87SP+4Hjx4cnfHiD gOAjxqnoNIvwEGGEubN9P+gnHvmNnsp1W5L/8grrqWtPq4xB4mICD2LRma7+r7PyjXcU PErHiqM5EPIp2mIRBlHQNwN0HHBI6DJ7N/rSb/sYVA2L4zvk0K3KV3UCFEIJZHc7zCj0 OydrYJU+m0R3yr2HdM9wYywIkRi7Exsf67VzsWMflE2pTB+3HjBPTmGzXo0GCNTBKbMF m3gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wHjMcCY5LI7nv43R60cKfDKgzW3eQ+gkpBjGXKj82jo=; b=TLhpwe7m7Ao7LXytpNMVPjAXmOU06A4LjNSSZB8vOnX8P4Y8j3d8BMmTUoUsDV9Mw6 xZqYDClM2qMhi1hmya75/UMok/KGuv36iqf7cgx2RyQsNOM6h3wbeaUvRUeKNizXyVFZ Vc5Stfa1xUDkTThKLh3TFclUwU/M75w8RB+LW++led8jTjIm+7FQH1D3WaPz+4i/b0RI tmp/VSonfO1Om3De7br8IzZafKNqsEQJh+r8MbCcVkQi+VK6+9vSh9M9RAM2kvPUDNOb u9+buidyoC4JF+2fZTHEuCrOuYB8q8S9ggw2/gPRunUnvpCGwe6y09w0o47FkwWg14tA 9Z+w== X-Gm-Message-State: AIVw112lq1jbm3c7N4WvbX4rmYAZFsc2ul6vvRxNsqfyan8/sAjQIuo3 ENvksoVpIFJM4WmOdCaVgMeZIOzkHIsv/puKMw== X-Received: by 10.37.68.87 with SMTP id r84mr8532508yba.229.1499525185172; Sat, 08 Jul 2017 07:46:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 8 Jul 2017 07:45:44 -0700 (PDT) In-Reply-To: References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Sat, 8 Jul 2017 07:45:44 -0700 Message-ID: To: Marco Tiloca Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113f5f3efe91630553cf69ed" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 14:46:28 -0000 --001a113f5f3efe91630553cf69ed Content-Type: text/plain; charset="UTF-8" Document: draft-tiloca-tls-dos-handshake-00.txt I'm trying to understand the threat model and operating model this is designed for. Let's start with the threat model. The anti-DoS mechanisms in DTLS are specifically oriented towards attackers who are not on-path, because on-path attackers can, as you say, obtain the HRR/HVR. You say: DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optional Cookie exchange as possible solution to mitigate this Denial of Service attack. While this makes the attack more complicated to mount, a well determined and resourceful adversary able to spoof valid IP addresses can still successfully perform it, by intercepting the possible server response including the Cookie and then echoing it in the second ClientHello. This is particularly doable in case the handshake is not based on Pre-Shared Key exchange modes. I take from this that your assumed threat model is an attacker who is minimally a man-on-the-side (i.e., able to read traffic and inject his own but not block) and maximally a full active attacker able to block data. Is that correct? Depending on the specific protocol version and the key establishment mode used in the handshake, the attack impact can range from single replies triggered by invalid ClientHello messages, to the server performing advanced handshake steps with consequent setup of invalid half-open sessions. Especially if performed in a large-scale and distributed manner, this attack can thwart performance and service availability of (D)TLS servers. Moreover, it can be particularly effective in application scenarios where servers are resource- constrained devices running DTLS over low-power, low bandwidth and lossy networks. It seems like the attack you are considering is one in which the attacker generates DTLS handshakes and then forces the DTLS server to either perform computations or hold state open (e.g., by doing a handshake or a partial handshake and then stopping) Is that correct? Assuming I am correct, the design you describe here seems much more complicated than necessary [0]. Consider the simpler design: - The client contacts the TA - TA generates a new value C = HMAC(k_M, N) and sends that to the client - the client inserts C in the ClientHello. The major downside is that this allows an on-path attacker to steal C and put it in their own CH, but so what? The attacker is still rate limited by the number of valid clients, and (at least) a fully active attacker doesn't need to substitute their own handshake messages for the valid clients because they can force the server to perform computations by playing the client messages and leave the server in a half-open state by blocking some client messages. I suppose you could argue that they could negotiate cipher suites that are more expensive to the server, but that seems like a fairly weak attack. Just to touch briefly on resumption: why do you need this mechanism at all for that? The client and server already have an assocation so the server knows that it has a valid client without any new assertion from the TA. -Ekr [0] It also, won't work. In particular, having the client send a MAC over the CH leads to having to zero out portions of the CH, which is going to create implementation problems in two ways. First, it creates a circular dependency with the TLS 1.3 PSK binder, so you'll need to have an exception there. Second, the zero-ing out trick you use is actually quite annoying to implement in many TLS stacks (it would be so in NSS). On Sat, Jul 8, 2017 at 4:10 AM, Marco Tiloca wrote: > Dear all, > > FYI, we have recently submitted a new draft proposing an extension for > (D)TLS 1.2/1.3. > > The solution described in the draft addresses Denial of Service attacks > against the handshake protocol, allowing servers to promptly abort invalid > session set ups. > > Feedback and comments are of course very welcome. Thanks a lot! > > Best regards, > /Marco > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-tiloca-tls-dos- > handshake-00.txt > Date: Wed, 28 Jun 2017 07:40:45 -0700 > From: internet-drafts@ietf.org > To: Marco Tiloca , Ludwig Seitz > , Maarten Hoeve > > > A new version of I-D, draft-tiloca-tls-dos-handshake-00.txt > has been successfully submitted by Marco Tiloca and posted to the > IETF repository. > > Name: draft-tiloca-tls-dos-handshake > Revision: 00 > Title: Extension for protecting (D)TLS handshakes against Denial of Service > Document date: 2017-06-28 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-tiloca-tls-dos-handshake-00.txt > Status: https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-handshake/ > Htmlized: https://tools.ietf.org/html/draft-tiloca-tls-dos-handshake-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-tls-dos-handshake-00 > > > Abstract: > This document describes an extension for TLS and DTLS to protect the > server from Denial of Service attacks against the handshake protocol. > The extension includes a Message Authentication Code (MAC) over the > ClientHello message, computed by the Client through key material > obtained from a Trust Anchor entity. The server registered at the > Trust Anchor derives the same key material and checks the MAC to > determine whether continuing or aborting the handshake. > > > > > 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. > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113f5f3efe91630553cf69ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-tiloca-tls-dos-handshake-00.txt
=

I'm trying to understand the threat model and opera= ting model this
is designed for. Let's start with the threat = model. The anti-DoS
mechanisms in DTLS are specifically oriented = towards attackers
who are not on-path, because on-path attackers = can, as you
say, obtain the HRR/HVR.

You= say:

=C2=A0 =C2=A0DTLS 1.2 as well as both TLS 1.= 3 and DTLS 1.3 provide the optional
=C2=A0 =C2=A0Cookie exchange = as possible solution to mitigate this Denial of
=C2=A0 =C2=A0Serv= ice attack.=C2=A0 While this makes the attack more complicated to
=C2=A0 =C2=A0mount, a well determined and resourceful adversary able to sp= oof
=C2=A0 =C2=A0valid IP addresses can still successfully perfor= m it, by intercepting
=C2=A0 =C2=A0the possible server response i= ncluding the Cookie and then echoing it
=C2=A0 =C2=A0in the secon= d ClientHello.=C2=A0 This is particularly doable in case the
=C2= =A0 =C2=A0handshake is not based on Pre-Shared Key exchange modes.

I take from this that your assumed threat model is an atta= cker who is
minimally a man-on-the-side (i.e., able to read traff= ic and inject his
own but not block) and maximally a full active = attacker able to block
data. Is that correct?


=C2=A0 =C2=A0Depending on the specific protocol versio= n and the key establishment
=C2=A0 =C2=A0mode used in the handsha= ke, the attack impact can range from single
=C2=A0 =C2=A0replies = triggered by invalid ClientHello messages, to the server
=C2=A0 = =C2=A0performing advanced handshake steps with consequent setup of invalid<= /div>
=C2=A0 =C2=A0half-open sessions.=C2=A0 Especially if performed in= a large-scale and
=C2=A0 =C2=A0distributed manner, this attack c= an thwart performance and service
=C2=A0 =C2=A0availability of (D= )TLS servers.=C2=A0 Moreover, it can be particularly
=C2=A0 =C2= =A0effective in application scenarios where servers are resource-
=C2=A0 =C2=A0constrained devices running DTLS over low-power, low bandwidt= h and
=C2=A0 =C2=A0lossy networks.

It se= ems like the attack you are considering is one in which the
attac= ker generates DTLS handshakes and then forces the DTLS server to
= either perform computations or hold state open (e.g., by doing a
= handshake or a partial handshake and then stopping) Is that correct?
<= div>
Assuming I am correct, the design you describe here seem= s much more
complicated than necessary [0]. Consider the simpler = design:

- The client contacts the TA
- T= A generates a new value C =3D HMAC(k_M, N) and sends that to the
= =C2=A0 client
- the client inserts C in the ClientHello.

The major downside is that this allows an on-path attacker= to steal C and
put it in their own CH, but so what? The attacker= is still rate limited
by the number of valid clients, and (at le= ast) a fully active attacker
doesn't need to substitute their= own handshake messages for the valid
clients because they can fo= rce the server to perform computations
by playing the client mess= ages and leave the server in a half-open
state by blocking some c= lient messages. I suppose you could argue
that they could negotia= te cipher suites that are more expensive to
the server, but that = seems like a fairly weak attack.

Just to touch bri= efly on resumption: why do you need this mechanism
at all for tha= t? The client and server already have an assocation
so the server= knows that it has a valid client without any new
assertion from = the TA.

-Ekr

[0] It also,= won't work. In particular, having the client send a
MAC over= the CH leads to having to zero out portions of the CH, which
is = going to create implementation problems in two ways. First, it
cr= eates a circular dependency with the TLS 1.3 PSK binder, so you'll
need to have an exception there. Second, the zero-ing out trick you
use is actually quite annoying to implement in many TLS stacks (it=
would be so in NSS).



On Sat, Jul 8, 2017= at 4:10 AM, Marco Tiloca <marco.tiloca@ri.se> wrote:
=20 =20 =20
Dear all,

FYI, we have recently submitted a new draft proposing an extension for (D)TLS 1.2/1.3.

The solution described in the draft addresses Denial of Service attacks against the handshake protocol, allowing servers to promptly abort invalid session set ups.

Feedback and comments are of course very welcome. Thanks a lot!

Best regards,
/Marco

-------- Forwarded Message --------
Subject: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
Date: Wed, 28 Jun 2017 07:40:45 -0700
From: internet-drafts@= ietf.org
To: Marco Tiloca <marco.ti= loca@ri.se>, Ludwig Seitz <ludwig.seitz@ri.se>= , Maarten Hoeve <maarten.hoeve@encs.= eu> 


A new version of I-D, draft-tiloca-tls-dos-handshake-00.txt
has been successfully submitted by Marco Tiloca and posted to the
IETF repository.

Name:		draft-tiloca-tls-dos-handshake
Revision:	00
Title:		Extension for protecting (D)TLS handshakes against Denial of Servic=
e
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-til=
oca-tls-dos-handshake-00.txt
Status:         https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-handshake/
Htmlized:       https://tools.ietf.org/html/draft-tiloca-tls-dos-hand=
shake-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-tiloc=
a-tls-dos-handshake-00


Abstract:
   This document describes an extension for TLS and DTLS to protect the
   server from Denial of Service attacks against the handshake protocol.
   The extension includes a Message Authentication Code (MAC) over the
   ClientHello message, computed by the Client through key material
   obtained from a Trust Anchor entity.  The server registered at the
   Trust Anchor derives the same key material and checks the MAC to
   determine whether continuing or aborting the handshake.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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


--001a113f5f3efe91630553cf69ed-- From nobody Sat Jul 8 08:31:50 2017 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 D971C129432 for ; Sat, 8 Jul 2017 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 02T-k7sbB0ou for ; Sat, 8 Jul 2017 08:31:47 -0700 (PDT) Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D776127ABE for ; Sat, 8 Jul 2017 08:31:46 -0700 (PDT) Received: from AWS-EXG01.res.venafi.com (10.50.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Sat, 8 Jul 2017 09:31:40 -0600 Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Sat, 8 Jul 2017 09:31:39 -0600 Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Sat, 8 Jul 2017 09:31:38 -0600 From: Paul Turner To: Stephen Farrell , Yaron Sheffer , tls chair CC: "tls@ietf.org" Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQKGzVdykhmcFWt6zaIizuL4wYEuLgLoH+FxAU26yOigwLJm4A== Date: Sat, 8 Jul 2017 15:31:38 +0000 Message-ID: <634dbf72eee14617a2359f2792d4aee0@venafi.com> References: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> In-Reply-To: <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [96.58.78.167] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 15:31:49 -0000 U3RlcGhlbiwNCg0KWW91IGhhdmUgcmVmZXJlbmNlZCBSRkMgMjgwNCwgd2hpY2ggc3RhdGVzIHRo ZSBmb2xsb3dpbmcgaW4gc2VjdGlvbiAzOg0KDQoiRm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIG1l bW8sIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBvZiB3aXJldGFwcGluZyBpcyB1c2VkOiBXaXJl dGFwcGluZyBpcyB3aGF0IG9jY3VycyB3aGVuIGluZm9ybWF0aW9uIHBhc3NlZCBhY3Jvc3MgdGhl IEludGVybmV0IGZyb20gb25lIHBhcnR5IHRvIG9uZSBvciBtb3JlIG90aGVyIHBhcnRpZXMgaXMg ZGVsaXZlcmVkIHRvIGEgdGhpcmQgcGFydHkiDQoNClRoZSBJbnRlcm5ldCBEcmFmdCBkZXNjcmli ZXMgdGhlIHVzZSBvZiBzdGF0aWMgKEVDKURIRSBmb3IgdHJhZmZpYyBlbnRpcmVseSBpbnNpZGUg ZW50ZXJwcmlzZSBuZXR3b3JrcyBhbmQgaW50ZW5kcyB0byBjbGVhcmx5IHN0YXRlIHRoYXQgaXQg c2hvdWxkIG5vdCBiZSB1c2VkIGZvciAiaW5mb3JtYXRpb24gcGFzc2VkIGFjcm9zcyB0aGUgSW50 ZXJuZXQiLiBJZiB3ZSBoYXZlIG5vdCBiZWVuIGNsZWFyIGVub3VnaCBvbiB0aGF0IGluIHRoZSBk b2N1bWVudCwgcGxlYXNlIHRlbGwgdXMgaG93IHdlIGNhbiBiZSBtb3JlIGNsZWFyLiBBc3N1bWlu ZyB0aGF0IHRoZSBkb2N1bWVudCBpcyBjbGVhciBvbiB0aGlzIHBvaW50LCBpdCB3b3VsZCBub3Qg dGhlbiBhcHBseSB0byAid2lyZXRhcHBpbmciIGFzIGRlZmluZWQgaW4gUkZDIDI4MDQgKGFzIFJ1 c3MgbWVudGlvbmVkIGluIGFuIGVhcmxpZXIgZW1haWwpLg0KDQpJdCB3b3VsZCBhcHBlYXIgdGhl biB0aGF0IHlvdXIgY29uY2VybiBpcyB0aGF0IGFuIG9yZ2FuaXphdGlvbiAob3IgcGVyc29uKSB3 aWxsIGRpc3JlZ2FyZCB0aGVzZSB0d28gZG9jdW1lbnRzIGFuZCB1c2Ugc3RhdGljIChFQylESEUg a2V5cyBmb3IgdGhlaXIgSW50ZXJuZXQgY29ubmVjdGlvbnMuIElzIHRoYXQgY29ycmVjdD8NCg0K QXNzdW1pbmcgdGhhdCBpcyBjb3JyZWN0LCBoZXJlIGFyZSB0d28gY29uc2lkZXJhdGlvbnM6DQoN CjEuIFdoeSB3b3VsZCBhbiBvcmdhbml6YXRpb24gdGhhdCB3YW50cyB0byBkZWxpYmVyYXRlbHkg c2hhcmUgdGhlIGNvbnRlbnQgb2YgVExTIGVuY3J5cHRlZCBJbnRlcm5ldCBjb21tdW5pY2F0aW9u cyB3aXRoIGEgdGhpcmQgcGFydHkgZ28gdG8gdGhlIHRyb3VibGUgb2YgaW1wbGVtZW50aW5nIHN0 YXRpYyAoRUMpREhFIGtleXM/IFNpbmNlIHRoZXkgYXJlIGFuIGVuZCBwb2ludCBpbiB0aGUgY29t bXVuaWNhdGlvbnMsIHRoZXkgaGF2ZSBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIChkZWNyeXB0ZWQp IGFuZCBjYW4gc2hhcmUgaXQgd2l0aCB0aGUgdGhpcmQgcGFydHkgd2l0aG91dCBhbnkgbmVlZCBm b3Igc3RhdGljIChFQylESEUga2V5cyAoYXMgSSBiZWxpZXZlIFdhdHNvbiBwb2ludGVkIG91dCku IA0KDQoyLiBUaGVyZSBpcyBub3RoaW5nIGluIHRoZSBUTFMgMS4zIHByb3RvY29sIHRvZGF5IHRo YXQgd291bGQgcHJldmVudCBzb21lb25lIGZyb20gaW1wbGVtZW50aW5nIHN0YXRpYyAoRUMpREhF IGtleXMsIGV2ZW4gaWYgdGhpcyBkb2N1bWVudCBpcyBub3QgcHVibGlzaGVkIGFzIGFuIFJGQy4g IElmIHB1Ymxpc2hlZCwgdGhpcyBSRkMgd291bGQgbWFrZSBpdCBjbGVhciB0aGF0IG11c3Qgbm90 IGJlIGRvbmUgd2l0aCBUTFMgMS4zLg0KDQpZb3UgaGF2ZSBzdGF0ZWQgdGhhdCB0aGVyZSBhcmUg YWx0ZXJuYXRpdmVzIGJ5IHVzaW5nIHByb3hpZXMgYnV0IGVudGVycHJpc2Ugb3JnYW5pemF0aW9u cyBoYXZlIHN0YXRlZCB0aGlzIGlzIG5vdCB2aWFibGUgZHVlIHRvIHRoZSBjb21wbGV4aXR5IGFu ZCBzY2FsZSBvZiB0aGVpciBuZXR3b3JrIGVudmlyb25tZW50cy4gT3VyIGNvbGxlY3RpdmUgb2Jq ZWN0aXZlIGlzIHRvIGluY3JlYXNlIHRoZSBzZWN1cml0eSBvZiB0aGUgSW50ZXJuZXQgYXQgbGFy Z2UuIEFzIHN1Y2gsIHdlIGhhdmUgcHJvcG9zZWQgdGhpcyBSRkMgaW4gb3JkZXIgdG8gZW5zdXJl IHRoYXQgVExTIDEuMyBpcyBhZG9wdGVkIGFzIGJyb2FkbHkgYXMgcG9zc2libGUgaW5zaWRlIG9m IGVudGVycHJpc2VzLCB3aGljaCBpcyBhbiBpbXBvcnRhbnQgc3RlcCBpbiBpbmNyZWFzaW5nIHNl Y3VyaXR5LiANCg0KQ29uc2VxdWVudGx5LCB3ZSB3b3VsZCBhc2sgdGhhdCB0aGlzIGRpc2N1c3Np b24gbm90IGJlIHNodXQgZG93biBhcyB5b3UgcmVxdWVzdC4NCg0KUGF1bA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IFNhdHVyZGF5LCBKdWx5IDgsIDIw MTcgMTA6MzMNClRvOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb20+OyB0bHMg Y2hhaXIgPHRscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpDYzogdGxzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW1RMU10gY2hhaXJzIC0gcGxlYXNlIHNodXRkb3duIHdpcmV0YXBwaW5nIGRpc2N1 c3Npb24uLi4NCg0KDQoNCk9uIDA4LzA3LzE3IDE1OjI3LCBZYXJvbiBTaGVmZmVyIHdyb3RlOg0K PiBIaSBTdGVwaGVuLA0KPiANCj4gTGlrZSB5b3UsIEkgYW0gdmVyeSB1bmhhcHB5IHdpdGggdGhp cyBkcmFmdCwgYW5kIHdvdWxkIG5vdCBzdXBwb3J0IGl0cyANCj4gYWRvcHRpb24gYXMgYSBXRyBk cmFmdC4gSG93ZXZlciBJIHRoaW5rIHRoYXQgb3BlbiBkaXNjdXNzaW9uIGlzIGluIA0KPiBnZW5l cmFsIGdvb2QsIGFuZCB0aGF0IHRoZSBiZXN0IHZlbnVlIGZvciBkaXNjdXNzaW9uIG9mIHRoaXMg ZHJhZnQgaXMgDQo+IHRoaXMgbWFpbGluZyBsaXN0LiBFdmVuIGlmIHNvbWUgb2YgdGhpcyBkaXNj dXNzaW9uIGRldm9sdmVzIGludG8gDQo+IGdlbmVyaWMgImFyZSB3ZSBwcm8gb3IgYWdhaW5zdCB3 aXJldGFwcGluZyIgcXVlc3Rpb25zLg0KDQpGV0lXIEkgYmVsaWV2ZSB0aGF0IHdlIGhhdmUgaGFk IHRoYXQgZGlzY3Vzc2lvbiBhYm91dCBicmVha2luZyB0bHMgb3ZlciBhbmQgb3ZlciBvbiB0aGlz IGFuZCBvdGhlciBsaXN0cy4gSSBzZWUgbm8gdmFsdWUgaW4gZG9pbmcgaXQgeWV0IGFnYWluLCBl dmVuIGlmIHRoZSBwcm94aW1hdGUgY2F1c2UgaXMgYSBuZXcgdmFyaWF0aW9uIG9mIHRoZSAiaGVy ZSdzIGEgd2F5IHRvIGJyZWFrIHRscyIgY2xhc3Mgb2YgZHJhZnRzLiAoU29tZWRheSB3ZSBzaG91 bGQgZmluZCBzb21lb25lIHdobydkIGRvY3VtZW50IGFsbCB0aGUgYnJva2VuIGJyZWFrLXRscyBp ZGVhcyB0aGF0IGhhdmUgYmVlbiByaWdodGx5IHJlamVjdGVkIG92ZXIgdGhlIHllYXJzLikNCg0K PiANCj4gSSBkb24ndCB0aGluayB0aGlzIGlzIGEgc2lnbmlmaWNhbnQgZGlzdHJhY3Rpb24gdGhh dCBjb3VsZCBkZXJhaWwgDQo+IChEKVRMUywgbW9yZW92ZXIsIHlvdSB3aWxsIHJlY2FsbCB0aGF0 IGluIENoaWNhZ28gc2V2ZXJhbCBuZXcgZHJhZnRzIA0KPiB3ZXJlIGFkb3B0ZWQgdG8gdGhlIHdv cmtpbmcgZ3JvdXAuIFNvIHRoZSBXRyBkb2VzIGZlZWwgdGhhdCBUTFMgaXMgaW4gDQo+IGdvb2Qg ZW5vdWdoIHNoYXBlIHRoYXQgd2UgY2FuIHNwZW5kIHNvbWUgYmFuZHdpZHRoIG9uIG90aGVyIHRo aW5ncy4NCg0KTWF5YmUgSSdtIG1vcmUgZWFzaWx5IGRpc3RyYWN0ZWQsIGF0IGxlYXN0IGJ5IHRo aXMgdG9waWM7LSkNCg0KQW55d2F5LCBJJ20gZmluZSB0aGF0IGl0J3MgZm9yIHRoZSBjaGFpcnMg dG8gZmlndXJlIHRoYXQgb3V0Lg0KDQpTLg0KDQoNCj4gVGhhbmtzLA0KPiANCj4gICAgIFlhcm9u DQo+IA0KPiANCj4gT24gMDgvMDcvMTcgMTI6MTcsIFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCj4+ IFNlYW4vSm9lLA0KPj4NCj4+IFRoaXMgaXMgYSByZXF1ZXN0IHRoYXQgeW91LCBhcyBjaGFpcnMs IHNodXQgZG93biB0aGUgZGlzdHJhY3RpbmcgDQo+PiB3aXJldGFwcGluZyBkaXNjdXNzaW9uLCBh dCBsZWFzdCB1bnRpbCBEVExTMS4zIGlzIGRvbmUuDQo+Pg0KPj4gSSBoYXZlIHBsYW5uZWQgdG8g c3BlbmQgdGltZSByZWFkaW5nIGRyYWZ0IDIxIGFuZCBEVExTLCBidXQgdGhhdCANCj4+IHdvbid0 IGhhcHBlbiBpZiB3ZSBrZWVwIGhhdmluZyB0byBmaWdodCBvZmYgdGhlIGxhdGVzdCBhdHRlbXB0 cyB0byANCj4+IGJyZWFrIFRMUy4gSSdkIG5vdCBiZSBzdXJwcmlzZWQgaWYgSSB3ZXJlbid0IHRo ZSBvbmx5IG9uZSBmaW5kaW5nIA0KPj4gdGhhdCBkaXN0cmFjdGlvbiBhbiBpcnJpdGF0aW5nIHdh c3RlIG9mIHRpbWUuIEZpbmlzaGluZw0KPj4gVExTMS4zIGFuZCBnZXR0aW5nIERUTFMxLjMgb24g dGhlIHdheSBzdXJlbHkgbmVlZHMgdG8gbm90IGJlIA0KPj4gY29uc3RhbnRseSBkZS1yYWlsZWQg YnkgdGhlc2UgYXR0ZW1wdHMgdG8gYnJlYWsgVExTLg0KPj4NCj4+IFRoZXJlZm9yZSBJJ2QgYXNr IHRoYXQgeW91IGRlY2xhcmUgdGhpcyBkaXNjdXNzaW9uIGNsb3NlZCBmb3IgYXQgDQo+PiBsZWFz dCB0aGF0IGxvbmcgKGkuZSB1bnRpbCBEVExTMS4zIGlzIGRvbmUpLg0KPj4NCj4+IEknZCBhbHNv IGFzayB0aGF0IHlvdSBub3QgYWxsb2NhdGUgYWdlbmRhIHRpbWUgZm9yIHdpcmV0YXBwaW5nIGlu IA0KPj4gUHJhZ3VlLg0KPj4NCj4+IFRoYW5rcywNCj4+IFMuDQo+Pg0KPj4NCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gVExTIG1haWxp bmcgbGlzdA0KPj4gVExTQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Rscw0KPiANCj4gDQoNCg== From nobody Sat Jul 8 08:40:20 2017 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 88B88129687 for ; Sat, 8 Jul 2017 08:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fQ9sloqtvtjb for ; Sat, 8 Jul 2017 08:40:16 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002: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 706E6124E15 for ; Sat, 8 Jul 2017 08:40:16 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id p207so18163859yba.2 for ; Sat, 08 Jul 2017 08:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JkhmvSIhmCivdecbu4c5ZdhQXXIiNPvb2HFPa83vzVE=; b=tB5nV667P/tB8ylKLEsS+09wfjv3zoaTlsok7dxjJyRoO4764yA0VKDMquLYUwYrbh UIRlkzqwPf4fv7ioKmvLzrvxr16mM1jBlpKT5mR2fz5fRD0qP7M3RdVOKMZH/R3lDFIO 8AbSZrDQ8uTBpjsfyzEpcbaHG1pMMycBh0TQ1mM6CHg+qg5zfWUeQlSFpT1hx9CGWSP8 CdI9JVlD9mYGdtzJXAV200OOIzNGF05wrjt75BQtBLhgq6p8orsrlzt9oIgKCh3dqohQ oVXxJxI0goYDpUj0gEhxPJAjqUhMe5qTpxumMSN1sx/ul+YY41ONvupJxp46Wfvi2/KO 6wFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JkhmvSIhmCivdecbu4c5ZdhQXXIiNPvb2HFPa83vzVE=; b=jI2Eoz6+z7fAZ6oAwQ3jGgqL+ZzDHfzSBqzgbjsTXSsQCsYAEMOoOZfewurU/ix0pD sXNWN84fC8MFldLmvsuWCg7bbd9ziBmkElSIMev3jv0Z8BrgOVdeXdSDwdif3YbsddjP cZLzgaFIe/KBs4d5a+3793sZVddYvOL3RSBv6DmfaBIbnHBCMZF0nyIpcr2HjXnz6w1t glnRtSnTush843sH/pBDb7SJM0v8AbuUPr9vavjBjcmz9qQDDVSb4sv73KLrfm/jQyyM uOr7ZnZ6JJADWdzmKkANBcm+6GBj9GXLRzEthC3RD8b05CP63HlwbC2hrcFTZ1ZPJu7g yIUA== X-Gm-Message-State: AIVw110u69mFBuoVp+hp6tOZMSRiiFGSJqM7uWcBcoNhMK3vZkjs5TVs Ir237IwBxMhghhbaJhHiFoIzSoQ82A== X-Received: by 10.37.221.196 with SMTP id u187mr8590771ybg.173.1499528415563; Sat, 08 Jul 2017 08:40:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.192.216 with HTTP; Sat, 8 Jul 2017 08:39:55 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Sat, 8 Jul 2017 08:39:55 -0700 Message-ID: To: Stephen Farrell Cc: tls chair , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114bc35a8a76a50553d02ab4" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 15:40:18 -0000 --001a114bc35a8a76a50553d02ab4 Content-Type: text/plain; charset="UTF-8" I was one of the people arguing my hardest against the BITS Security proposal to continue to (ab)use RSA static keys to allow passive MitM, even though TLS 1.3 had already moved forward on what I would call a more modern protocol design of the sort I believe payments companies should embrace to improve their security. That said, if people do want to MitM themselves, I would rather there be a single, easily detectable and very explicit way of doing so, as opposed to sketchy, incompatible, ad hoc mechanisms. Furthermore, it would be nice to have a clear answer for these users, less they continue to make (bad) arguments that there is something fundamentally wrong with the design of TLS 1.3 that makes it incompatible with "industry requirements". Clearly there are echoes of the scary protocols of yesteryear, i.e. Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the image header you will discover he is quite familiar with these things, and my personal presumption would be he is not displaying this image to show his undying love of the Clipper chip, although perhaps he's an especially crafty and duplicitous NSA sleeper agent. --001a114bc35a8a76a50553d02ab4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was one of the people arguing my hardest against the BIT= S Security proposal to continue to (ab)use RSA static keys to allow passive= MitM, even though TLS 1.3 had already moved forward on what I would call a= more modern protocol design of the sort I believe payments companies shoul= d embrace to improve their security.

That said, if peopl= e do want to MitM themselves, I would rather there be a single, easily dete= ctable and very explicit way of doing so, as opposed to sketchy, incompatib= le, ad hoc mechanisms. Furthermore, it would be nice to have a clear answer= for these users, less they continue to make (bad) arguments that there is = something fundamentally wrong with the design of TLS 1.3 that makes it inco= mpatible with "industry requirements".

C= learly there are echoes of the scary protocols of yesteryear, i.e. Clipper/= LEAP. I think if you visit Matt Green's Twitter page and check the imag= e header you will discover he is quite familiar with these things, and my p= ersonal presumption would be he is not displaying this image to show his un= dying love of the Clipper chip, although perhaps he's an especially cra= fty and duplicitous NSA sleeper agent.
--001a114bc35a8a76a50553d02ab4-- From nobody Sat Jul 8 08:45:04 2017 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 BC9E9129B1A for ; Sat, 8 Jul 2017 08:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYHzNC9-yq8P for ; Sat, 8 Jul 2017 08:45:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBECF129AA0 for ; Sat, 8 Jul 2017 08:45:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 89077BE4C; Sat, 8 Jul 2017 16:44:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPcFq2aXpN17; Sat, 8 Jul 2017 16:44:57 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 371CEBE39; Sat, 8 Jul 2017 16:44:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499528697; bh=6d7qAMu6FApp86uAgCbCJ1pjzHWmzHrnx7gsRX2V4Xs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VTWEYOlBKY+J3W2y6pV+o4NU4LMelD3EksqmYUyi4/Y+DW5iqJidDaQm5VNPWTZWG dWECahRA9Uws3KTtsezF9OalxRaAnv7A70Y3ePnSpahYVSfUMVODIW0RauCQdx4peh hoKwxBre5xtAt99ciiIE8Z6uX0sbk+JhJ6Y1iS7k= To: Tony Arcieri Cc: tls chair , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <98676127-5d46-55fe-b8ef-30948f78c15d@cs.tcd.ie> Date: Sat, 8 Jul 2017 16:44:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B7LH6059xJeENS10Bu1IUkp4bTlq8PwRF" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 15:45:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B7LH6059xJeENS10Bu1IUkp4bTlq8PwRF Content-Type: multipart/mixed; boundary="ExceKG6lfW7h3G9mlprBn5nooXHEa2blV"; protected-headers="v1" From: Stephen Farrell To: Tony Arcieri Cc: tls chair , "tls@ietf.org" Message-ID: <98676127-5d46-55fe-b8ef-30948f78c15d@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: In-Reply-To: --ExceKG6lfW7h3G9mlprBn5nooXHEa2blV Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/07/17 16:39, Tony Arcieri wrote: > Clearly there are echoes of the scary protocols of yesteryear, i.e. > Clipper/LEAP. I think if you visit Matt Green's Twitter page and check = the > image header you will discover he is quite familiar with these things, = and > my personal presumption would be he is not displaying this image to sho= w > his undying love of the Clipper chip, although perhaps he's an especial= ly > crafty and duplicitous NSA sleeper agent. >=20 Reputations are irrelevant to how we evaluate this, though I guess can be affected by the drafts one co-authors. The relevant draft is proposing a wiretapping API for TLS. That's inconsistent with RFC2804 no matter who proposes it. S. --ExceKG6lfW7h3G9mlprBn5nooXHEa2blV-- --B7LH6059xJeENS10Bu1IUkp4bTlq8PwRF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYP34AAoJEC88hzaAX42iaQsH/2FTwXeBbABRPHfZN+j8ACPP GA9F9CbigDV51wyK1R0aa3clCiBXkfyqW0vW7TAfZyqBzo84IEb631pZXl3+e6EY gB2X3b4Tzt8E7i/1v0QHXET6gMdIJ+k7KtmwHaHfgJu8aZ65S3i91e0DYLX1Dt2t t/iscplcq9MfLt/XqJbp2vEJhqYdrAMX5H2y1Pj/k1VGL/dnOA1E7/1qAZpBNX+J Ayr5HRKBl3Q7TRUVFJ6gR2U4o2O8gDLAckJqItM+CmBtYnE386PY4SOdlB+yBuIA SooE3dCbTSVCZ6Qx7qJgdNHZq5HsGeabeGpphZEU5ZTVCXNynhaArXqCFnxCBMs= =Kfci -----END PGP SIGNATURE----- --B7LH6059xJeENS10Bu1IUkp4bTlq8PwRF-- From nobody Sat Jul 8 08:46:38 2017 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 95D22129AA0 for ; Sat, 8 Jul 2017 08:46:37 -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 wlitvGC-eLg1 for ; Sat, 8 Jul 2017 08:46:35 -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 11047129B04 for ; Sat, 8 Jul 2017 08:46:35 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id x125so22994415ywa.0 for ; Sat, 08 Jul 2017 08:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NSAxJU5YGcxL/O/9YX6PxHhY+TVNDpnQkM4ou3V5mNM=; b=nnyiyry0Wqr7sIaPVgZ7i6UPTEt80bN9sOtFsqI2r9J7ACqB9AL0xRWCB3/lFlD4tu MGMAP+ONwiP4OoLO8sVlWScGKUfvB9qbg202I+1sONa4v2qZnQqjplV23qk7g6KH6yzJ tRvRQosdgRqxPtbXLf2FDSlPOswOrgzZjRSdJJuSXnw9DeKObd/tquQ/OHEaxi//XfDy EEjFChCZcDvNXyc0lXIP4MhZvh+O/3QfoahATeP5zn1Q1iSnjyB02/TOJ8Y2QJfnCAY3 pPm1nYxIhnNyjemqPa44OU357pxDRx0kAjPRMR0g/SfYi8+xL9IbeNuqwfbMDW5HLDVB VxMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NSAxJU5YGcxL/O/9YX6PxHhY+TVNDpnQkM4ou3V5mNM=; b=LOLiNILBLvKXgriFkpsBt5mvY/2S5KnJMmpuPtB6KtK3oG6HPcwEGXuGmsqzS2LsaG yTAzgWNNxT1+plzvshCIZ1AnO5s26XIBuKjTmIyoZhxRtn6npzqOv9Lk0Qhv6gx+EQvq YW4syrISp5ZPpQlc7CHpR3Y0MsP5Fh8tvMJY3aa/wFXskM3BupspFjWAyS/k4j0FnvTR 1fqalvVKdR9iQ0XnmjXAmkDBkswUPKJb/iD1+VZXEYrvUIYfKjo70MM/OabDHmyU/7ry 7ykInWVebHrCgL1eTuYoT1OqSJ1vEfGMdnHC8n722HrvtqUpIyDcZEWlKrNjTK2V/Iph mFdw== X-Gm-Message-State: AIVw1134BKckAvNRNlqnru46EMyu5TWTmsWqpi9ZRT6RjIcGRMYUBKNu T3Yw9Ncz02m/sM/3JDJbwP45806qog== X-Received: by 10.129.112.148 with SMTP id l142mr6124378ywc.221.1499528794108; Sat, 08 Jul 2017 08:46:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.192.216 with HTTP; Sat, 8 Jul 2017 08:46:13 -0700 (PDT) In-Reply-To: <98676127-5d46-55fe-b8ef-30948f78c15d@cs.tcd.ie> References: <98676127-5d46-55fe-b8ef-30948f78c15d@cs.tcd.ie> From: Tony Arcieri Date: Sat, 8 Jul 2017 08:46:13 -0700 Message-ID: To: Stephen Farrell Cc: tls chair , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0b1e521a93ae0553d04104" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 15:46:38 -0000 --94eb2c0b1e521a93ae0553d04104 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 8:44 AM, Stephen Farrell wrote: > On 08/07/17 16:39, Tony Arcieri wrote: > > Clearly there are echoes of the scary protocols of yesteryear, i.e. > > Clipper/LEAP. I think if you visit Matt Green's Twitter page and check > the > > image header you will discover he is quite familiar with these things, > and > > my personal presumption would be he is not displaying this image to show > > his undying love of the Clipper chip, although perhaps he's an especially > > crafty and duplicitous NSA sleeper agent. > > > > Reputations are irrelevant to how we evaluate this, though > I guess can be affected by the drafts one co-authors. > > The relevant draft is proposing a wiretapping API for TLS. > > That's inconsistent with RFC2804 no matter who proposes it. Perhaps you should respond to the other two paragraphs in my message? --94eb2c0b1e521a93ae0553d04104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 8, 2017 at 8:44 AM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
On 08/07/17 16:39, Tony Arcieri wrote:
> Clearly there are echoes of the scary protocols of yesteryear, i.e. > Clipper/LEAP. I think if you visit Matt Green's Twitter page and c= heck the
> image header you will discover he is quite familiar with these things,= and
> my personal presumption would be he is not displaying this image to sh= ow
> his undying love of the Clipper chip, although perhaps he's an esp= ecially
> crafty and duplicitous NSA sleeper agent.
>

Reputations are irrelevant to how we evaluate this, though
I guess can be affected by the drafts one co-authors.

The relevant draft is proposing a wiretapping API for TLS.

That's inconsistent with RFC2804 no matter who proposes it.

Perhaps you should respond to the other two paragraphs= in my message?
--94eb2c0b1e521a93ae0553d04104-- From nobody Sat Jul 8 08:59:58 2017 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 E5C8C129B4F for ; Sat, 8 Jul 2017 08:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpwJPipbWLG1 for ; Sat, 8 Jul 2017 08:59:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286F3129B08 for ; Sat, 8 Jul 2017 08:59:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC7E5BE49; Sat, 8 Jul 2017 16:59:52 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwYsoJLpt5Lr; Sat, 8 Jul 2017 16:59:50 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B1E68BE39; Sat, 8 Jul 2017 16:59:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499529590; bh=80fzNtGNvzftDu0M1gL83zD44wJiRLqau+9h0NRGlgw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=0vjB4AijGOg7XabZxDQlEwfHJWYR+9+TpIBIYsBjO3QdsqphxxPtYzxSf2M0296Bb ZHRqMisi/GfATolmlZ53s6e1y8pC7clLB7Mg8awG9aaEcmFJHHixptRcO9nmxLg4TV M9HqhuHNTrTIAAXjW6wjGswZZ/CdM1/P93Pk/y7c= To: Paul Turner , Yaron Sheffer , tls chair Cc: "tls@ietf.org" References: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> <634dbf72eee14617a2359f2792d4aee0@venafi.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sat, 8 Jul 2017 16:59:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <634dbf72eee14617a2359f2792d4aee0@venafi.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cXwxIpckquBE0JR4mmRTJfN6NX6elL7RJ" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 15:59:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cXwxIpckquBE0JR4mmRTJfN6NX6elL7RJ Content-Type: multipart/mixed; boundary="4LQko5FCOOgthotXAPbTBGm2rJpueL7oA"; protected-headers="v1" From: Stephen Farrell To: Paul Turner , Yaron Sheffer , tls chair Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> <634dbf72eee14617a2359f2792d4aee0@venafi.com> In-Reply-To: <634dbf72eee14617a2359f2792d4aee0@venafi.com> --4LQko5FCOOgthotXAPbTBGm2rJpueL7oA Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/07/17 16:31, Paul Turner wrote: > Stephen, >=20 > You have referenced RFC 2804, which states the following in section > 3: >=20 > "For the purposes of this memo, the following definition of > wiretapping is used: Wiretapping is what occurs when information > passed across the Internet from one party to one or more other > parties is delivered to a third party" The draft matches 2804 for many uses of TLS. E.g. anyone with a hosted web service without access to the underlying http server config. That's millions of people I believe. I do not believe that is fixable. >=20 > The Internet Draft describes the use of static (EC)DHE for traffic > entirely inside enterprise networks=20 No it doesn't. There is no definition of enterprise network not any mechanism for constraining deployment to such. Nor can there be, other than pretense and pixie-dust. > and intends to clearly state that > it should not be used for "information passed across the Internet". Yes, you may intend to say something like that but it's nonsense. TLS is used in far too many contexts for that to be a reasonable approach. > If we have not been clear enough on that in the document, please tell > us how we can be more clear.=20 Remove the "standards track" header and go elsewhere is IMO the only sensible outcome. It is not possible, nor useful, to attempt to fix the draft as-is. > Assuming that the document is clear on > this point, it would not then apply to "wiretapping" as defined in > RFC 2804 (as Russ mentioned in an earlier email). Yes, you are both incorrect there. >=20 > It would appear then that your concern is that an organization (or > person) will disregard these two documents and use static (EC)DHE > keys for their Internet connections. Is that correct? >=20 > Assuming that is correct, here are two considerations: >=20 > 1. Why would an organization that wants to deliberately share the Coercion. Eg. a NSL in the US. The proposed method is nice and simple for the web site and from the point of a wiretapper puts the packet capture burden nicely where it's wanted in the middle of the network. > content of TLS encrypted Internet communications with a third party > go to the trouble of implementing static (EC)DHE keys? Since they are > an end point in the communications, they have all of the information > (decrypted) and can share it with the third party without any need > for static (EC)DHE keys (as I believe Watson pointed out). >=20 > 2. There is nothing in the TLS 1.3 protocol today that would prevent > someone from implementing static (EC)DHE keys, even if this document > is not published as an RFC. If published, this RFC would make it > clear that must not be done with TLS 1.3. I would prefer that we impose more strict requirements on the use of non-static public DH values and forget about this draft entirely. I will strongly object to every attempt to do this on the standards-track with the IETF. >=20 > You have stated that there are alternatives by using proxies but > enterprise organizations have stated this is not viable due to the> com= plexity and scale of their network environments. And others disagreed with that and don't find any problems with dropping rsa key transport. Assertions that this is necessary are therefore false. It clearly is not needed for lots of deployments. > Our collective > objective is to increase the security of the Internet at large.=20 If so, you are going about it wrong - there BITS-related efforts all seem to me to be in the direction of weakening security. S. > As > such, we have proposed this RFC in order to ensure that TLS 1.3 is > adopted as broadly as possible inside of enterprises, which is an > important step in increasing security. >=20 > Consequently, we would ask that this discussion not be shut down as > you request. >=20 > Paul >=20 > -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On > Behalf Of Stephen Farrell Sent: Saturday, July 8, 2017 10:33 To: > Yaron Sheffer ; tls chair > Cc: tls@ietf.org Subject: Re: [TLS] > chairs - please shutdown wiretapping discussion... >=20 >=20 >=20 > On 08/07/17 15:27, Yaron Sheffer wrote: >> Hi Stephen, >>=20 >> Like you, I am very unhappy with this draft, and would not support >> its adoption as a WG draft. However I think that open discussion is >> in general good, and that the best venue for discussion of this >> draft is this mailing list. Even if some of this discussion >> devolves into generic "are we pro or against wiretapping" >> questions. >=20 > FWIW I believe that we have had that discussion about breaking tls > over and over on this and other lists. I see no value in doing it yet > again, even if the proximate cause is a new variation of the "here's > a way to break tls" class of drafts. (Someday we should find someone > who'd document all the broken break-tls ideas that have been rightly > rejected over the years.) >=20 >>=20 >> I don't think this is a significant distraction that could derail=20 >> (D)TLS, moreover, you will recall that in Chicago several new >> drafts were adopted to the working group. So the WG does feel that >> TLS is in good enough shape that we can spend some bandwidth on >> other things. >=20 > Maybe I'm more easily distracted, at least by this topic;-) >=20 > Anyway, I'm fine that it's for the chairs to figure that out. >=20 > S. >=20 >=20 >> Thanks, >>=20 >> Yaron >>=20 >>=20 >> On 08/07/17 12:17, Stephen Farrell wrote: >>> Sean/Joe, >>>=20 >>> This is a request that you, as chairs, shut down the distracting >>> wiretapping discussion, at least until DTLS1.3 is done. >>>=20 >>> I have planned to spend time reading draft 21 and DTLS, but that >>> won't happen if we keep having to fight off the latest attempts >>> to break TLS. I'd not be surprised if I weren't the only one >>> finding that distraction an irritating waste of time. Finishing=20 >>> TLS1.3 and getting DTLS1.3 on the way surely needs to not be=20 >>> constantly de-railed by these attempts to break TLS. >>>=20 >>> Therefore I'd ask that you declare this discussion closed for at >>> least that long (i.e until DTLS1.3 is done). >>>=20 >>> I'd also ask that you not allocate agenda time for wiretapping in >>> Prague. >>>=20 >>> Thanks, S. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ TLS mailing list=20 >>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >=20 --4LQko5FCOOgthotXAPbTBGm2rJpueL7oA-- --cXwxIpckquBE0JR4mmRTJfN6NX6elL7RJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYQF2AAoJEC88hzaAX42iLBEH/2DW9Mj1OGvvKE+Grn2oYr32 gD6IatnM0smmXtEJ32OzishruGRl/uAXAChdjCEc+bn5DX4bDVXu5eKew9auBKG/ a/Cnq834l2Ry0ycxZok29LKIFDV+Fz9k7aQK9CUQRWJvYNCXYMWfkjMgGoI1S1jU OdYb4Fi9LV2q6sG3PjgcbEvqfCuoEznrxhDH2GQrlinJG53U1sJm+KG5W4YwFqHV erzrlON7T96QdgWbzObEaVYSxqHIIoj0eEublc1upHtdzqPseyLmaJA31MawtxHi nfYmP/zHaSagqhFoc19gWc2o2KRuRvTjqj/nFtcHQHvy69dxUXe0oWJ/D77nzHQ= =CUfq -----END PGP SIGNATURE----- --cXwxIpckquBE0JR4mmRTJfN6NX6elL7RJ-- From nobody Sat Jul 8 09:01:15 2017 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 EA702129B72 for ; Sat, 8 Jul 2017 09:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 H0cdp00LhPBs for ; Sat, 8 Jul 2017 09:01:12 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 52925129B4F for ; Sat, 8 Jul 2017 09:01:12 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id B50F31C18D9 for ; Sat, 8 Jul 2017 11:01:11 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id D39B41C1832; Sat, 8 Jul 2017 11:01:10 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9299CFE055; Sat, 8 Jul 2017 12:01:10 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 43AAAFE048; Sat, 8 Jul 2017 12:01:10 -0400 (EDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (unknown [216.32.180.49]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Sat, 8 Jul 2017 12:01:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C2qkOdJKrFwmmlDpD+uPp3cXaiApOIAoGmsI5K+AW3E=; b=zGtPK1CLGguT4H/2VYTqCxk+ECwdZZPVT0Uzm+fN70LxVqixp+sH1mFcOlHxR/TnLElGOgo/OlbwbWhbLlWPuTAYwUaYMSOjmxxfkdb5g8dSAB0v1GZ3ckT0fOwybmKo2KSU+2AKDGbj0WfvZR94K46FQQxZwxx6axAG+9Egnug= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 8 Jul 2017 16:01:07 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.013; Sat, 8 Jul 2017 16:01:07 +0000 From: "Ackermann, Michael" To: Timothy Jackson , Watson Ladd , Christian Huitema CC: "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIAABAWAgAAPEACAAAECAIAABj8AgAACzgCAAAGCAIAANuiAgAAIJQCAAASV8IAAFxiAgADCxsA= Date: Sat, 8 Jul 2017 16:00:43 +0000 Deferred-Delivery: Sat, 8 Jul 2017 16:00:00 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mobileiron.com; dkim=none (message not signed) header.d=none;mobileiron.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.0.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 20:pXVncGmXEBB/P8SaP5Fam7RwL4/NMjDFnZK4HK0IPQ0+GcOE9v+wYMu8tsgMtipCJen4WddfCM4/DRvzS1AX7zXBZypBTHTKfsbHyeUQQz1hJEQITeDNrKKsQQVGVbLfxFm7hmiw/WituZ7A1sksuGPPntbRHbSbuPSftzPJ8vo= x-ms-office365-filtering-correlation-id: 946dc1cf-f9e7-49ef-29a4-08d4c61a8b7a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1368; x-ms-traffictypediagnostic: CY4PR14MB1368: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(158342451672863)(278428928389397)(26388249023172)(236129657087228)(192374486261705)(90097320859284)(48057245064654)(148574349560750)(142563422833929); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(2017060910075)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1368; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39400400002)(39840400002)(39450400003)(377454003)(85714005)(13464003)(24454002)(606006)(19609705001)(6506006)(2950100002)(966005)(33656002)(8936002)(25786009)(77096006)(7736002)(81166006)(2900100001)(6116002)(3280700002)(3846002)(102836003)(74316002)(790700001)(3660700001)(86362001)(478600001)(189998001)(72206003)(8676002)(6666003)(14454004)(54896002)(9686003)(76176999)(54356999)(236005)(53936002)(50986999)(6246003)(230783001)(4326008)(39060400002)(38730400002)(5660300001)(55016002)(6436002)(99286003)(53546010)(229853002)(2906002)(93886004)(6306002)(7696004)(80792005)(561944003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368A816B5511F11837C9815D7AB0CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2017 16:01:07.5695 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 4be79311-648e-47f1-8d8f-b82f2df3aff4 X-VPM-MSG-ID: 756c5272-d880-499f-9753-ab428149b559 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 16:01:15 -0000 --_000_CY4PR14MB1368A816B5511F11837C9815D7AB0CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regards to using proxies, I believe this is covered in the draft. But at a high level, most enterprises have tried this approach. It can = work in some situations, but in most cases there are utilization, = performance and management issues that prevent this solution from being = effective or affordable. Not to mention the introduction of manifold new = potential points of failure. From: Timothy Jackson =5Bmailto:tjackson=40mobileiron.com=5D Sent: Friday, July 7, 2017 11:19 PM To: Ackermann, Michael ; Watson Ladd = ; Christian Huitema Cc: tls=40ietf.org Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 As an earlier poster asked, what advantage does this approach have over = TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am = familiar is able to terminate at TLS connection, inspect/copy/filter, and = then encrypt on a new TLS sessions. For high performance customers, the SSL accelerators can be sandwiched = around the filter so all the crypto is done in hardware. The ways to prevent TLS inspection are cert pinning and client cert auth. = If this is only within one's data center, then those features can be = disabled if necessary, no? What use case am I missing that can't be achieved better by other means = than static keys? Thanks, Tim Sent from Email+ secured by MobileIron ________________________________ From: =22Ackermann, Michael=22 = > Date: Friday, July 7, 2017 at 7:06:55 PM To: =22Watson Ladd=22 = >, =22Christian = Huitema=22 > Cc: =22tls=40ietf.org=22 = > Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 Converting all session traffic to clear text is not a viable alternative = for ANY enterprises or industries that I am aware of. In particular those = in financial sectors. Security policies, legislation and in many cases just good practice would = not allow for this. We are compelled by these factors to encrypt all data in motion. But we = still need to manage our applications, networks, servers and clients. = Hence the need to decrypt traffic as outlined in this draft. -----Original Message----- From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Watson Ladd Sent: Friday, July 7, 2017 9:40 PM To: Christian Huitema > Cc: tls=40ietf.org Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema = > wrote: > > > On 7/7/2017 2:54 PM, Russ Housley wrote: >> Stephen: >> ... >>> And also: I'm sorry to have to say it, but I consider that attempted >>> weasel wording around the clear intent of 2804. The clear and real >>> effect if your wiretapping proposal were standardised by the IETF >>> would be that we'd be standardising ways in which TLS servers can be >>> compelled into breaking TLS - it'd be a standard wiretapping API >>> that'd be insisted upon in many places and would mean significantly >>> degrading TLS (only *the* most important security protocol we >>> maintain) and the community's perception of the IETF. It's all a >>> shockingly bad idea. >> I clearly disagree. Otherwise, I would not have put any work into the = draft. > Russ, > > What are the specific mechanisms that would allow this technique to be > used where you intend it, i.e. within a data center, and not where > Stephen fears it would be, i.e., on the broad Internet? For example, > what mechanism could a client use to guarantee that this sort of > =22static DH=22 intercept could NOT be used against them? The server can send the plaintext to whomever it likes. This is the solution enterprises can use today. Nothing can stop that from = happening. So I don't see why static DH is a) so essentially necessary and = b) so controversial. >From a technical point I prefer using DH shares derived from ServerRandom as this avoids certain bugs I've been known to exploit from = time to time. > > -- > Christian Huitema > > > _______________________________________________ > TLS mailing list > TLS=40ietf.org > https://www.ietf.org/mailman/listinfo/tls -- =22Man is born free, but everywhere he is in chains=22. --Rousseau. _______________________________________________ TLS mailing list TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. _______________________________________________ TLS mailing list TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB1368A816B5511F11837C9815D7AB0CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif =21mso=5D><=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

R= egards to using proxies,  I believe this is covered in the draft. 

B= ut at a high level, most enterprises have tried this approach.   = It can work in some  situations,  but in most cases there are = utilization, performance and management issues that prevent this solution from being effective or affordable.  =  Not to mention the introduction of manifold new potential points of = failure. 

<= o:p> 

F= rom: = Timothy Jackson =5Bmailto:tjackson=40mobileiron.com=5D
Sent: Friday, July 7, 2017 11:19 PM
To: Ackermann, Michael <MAckermann=40bcbsm.com>; Watson Ladd = <watsonbladd=40gmail.com>; Christian Huitema = <huitema=40huitema.net>
Cc: tls=40ietf.org
Subject: Re: =5BTLS=5D = draft-green-tls-static-dh-in-tls13-01

 

As an = earlier poster asked, what advantage does this approach have over = TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am = familiar is able to terminate at TLS connection, inspect/copy/filter, and then encrypt on a new TLS sessions.

For high performance customers, the SSL accelerators can be sandwiched = around the filter so all the crypto is done in hardware.

The ways to prevent TLS inspection are cert pinning and client cert auth. = If this is only within one's data center, then those features can be = disabled if necessary, no?

What use case am I missing that can't be achieved better by other means = than static keys?

Thanks,

Tim

Sent from Email&=2343; secured by MobileIron


From: "Ackermann, Michael" <MAckermann=40bcbsm.com> Date: Friday, July 7, 2017 at 7:06:55 PM
To: "Watson Ladd" <watsonbladd=40gmail.com>= , "Christian Huitema" <huitema=40huitema.net>
Cc: "tls=40ietf.org" <tls=40ietf.org>
Subject: Re: =5BTLS=5D = draft-green-tls-static-dh-in-tls13-01

Converting = all session traffic to clear text is not a viable alternative for ANY = enterprises or industries that I am aware of.  In particular those in = financial sectors. 
Security policies, legislation and in many cases just good practice would = not allow for this.
We are compelled by these factors to encrypt all data in = motion.    But we still need to manage our applications, = networks, servers and clients.    Hence the need to decrypt = traffic as outlined in this draft.  

-----Original Message-----
From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Watson Ladd
Sent: Friday, July 7, 2017 9:40 PM
To: Christian Huitema <huitema=40huitema.net>
Cc: tls=40ietf.org
Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01

On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema <huitema=40huitema.net> = wrote:
>
>
> On 7/7/2017 2:54 PM, Russ Housley wrote:
>> Stephen:
>> ...
>>> And also: I'm sorry to have to say it, but I consider that = attempted
>>> weasel wording around the clear intent of 2804. The clear and = real
>>> effect if your wiretapping proposal were standardised by the = IETF
>>> would be that we'd be standardising ways in which TLS servers = can be
>>> compelled into breaking TLS - it'd be a standard wiretapping = API
>>> that'd be insisted upon in many places and would mean = significantly
>>> degrading TLS (only *the* most important security protocol we =
>>> maintain) and the community's perception of the IETF. It's = all a
>>> shockingly bad idea.
>> I clearly disagree.  Otherwise, I would not have put any = work into the draft.
> Russ,
>
> What are the specific mechanisms that would allow this technique to = be
> used where you intend it, i.e. within a data center, and not where
> Stephen fears it would be, i.e., on the broad Internet? For example, =
> what mechanism could a client use to guarantee that this sort of
> "static DH" intercept could NOT be used against them?

The server can send the plaintext to whomever it likes.

This is the solution enterprises can use today. Nothing can stop that from = happening. So I don't see why static DH is a) so essentially necessary and = b) so controversial.

>From a technical point I prefer using DH shares derived from
ServerRandom as this avoids certain bugs I've been known to exploit from = time to time.

>
> --
> Christian Huitema
>
>
> _______________________________________________
> TLS mailing list
> TLS=40ietf.org
> https://www.ietf.org= /mailman/listinfo/tls



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

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


The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please = notify the sender, by electronic mail or telephone, of any unintended = receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

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


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB1368A816B5511F11837C9815D7AB0CY4PR14MB1368namp_-- From nobody Sat Jul 8 09:08:46 2017 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 B844212EB4E for ; Sat, 8 Jul 2017 09:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 M0bX4M4Jpl7r for ; Sat, 8 Jul 2017 09:08:42 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 8CFDA12EB4B for ; Sat, 8 Jul 2017 09:08:42 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id F19681C18BD for ; Sat, 8 Jul 2017 11:08:41 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id C21D21C1832; Sat, 8 Jul 2017 11:08:40 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8C49CFE054; Sat, 8 Jul 2017 12:08:40 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 470CEFE04E; Sat, 8 Jul 2017 12:08:40 -0400 (EDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (unknown [216.32.181.182]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Sat, 8 Jul 2017 12:08:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q02Tk5StDCCEC9wsVRQ5kptOOFHl2AjZqxWgDE4SbL4=; b=OdPQSuSb45UjMj71WYClyt6PYr13KVG53aEen6uuFjCr3QDTNbUthg73vJ6vSgmvK02yxc68lq1m1qXFalqmGWB1H0T+QjVUx39C9/jxkkRVuSc0qeh823baCzDfR+2dpVnVP8hoKAdSEsoO19q4h/uy1V8AymExs6fZrVTgCcc= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1366.namprd14.prod.outlook.com (10.172.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 8 Jul 2017 16:08:37 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.013; Sat, 8 Jul 2017 16:08:37 +0000 From: "Ackermann, Michael" To: Stephen Farrell , Watson Ladd , Christian Huitema CC: "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIAABAWAgAAPEACAAAECAIAABj8AgAACzgCAAAGCAIAANuiAgAAIJQCAAASV8IAAeQIAgABkHQA= Date: Sat, 8 Jul 2017 16:08:08 +0000 Deferred-Delivery: Sat, 8 Jul 2017 16:07:00 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> <1ab70d05-235e-5a4f-a44b-8b4eadd9ddd8@cs.tcd.ie> In-Reply-To: <1ab70d05-235e-5a4f-a44b-8b4eadd9ddd8@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.0.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1366; 20:QSRG2+TsedK4neRB5tncr9D7KS4Y+mWh2xeMRwEt7B7bj2wj7oCLjq/ENQ0rlk8sHWVehyRD7alFesfTPa2XeZgxu0MbS/eqeqtjZkmmowhbobrhcx0mTToEAL6QRKicA6qd7zgBP8VtSNoO0s+nKOKC+A552fdZ5yHsETP/PTo= x-ms-office365-filtering-correlation-id: 8a1e32a2-15c0-45f3-8afb-08d4c61b97b7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1366; x-ms-traffictypediagnostic: CY4PR14MB1366: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(278428928389397)(236129657087228)(192374486261705)(90097320859284)(48057245064654)(86572411397741)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1366; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39840400002)(39450400003)(377454003)(13464003)(24454002)(80792005)(966005)(72206003)(6436002)(14454004)(77096006)(39060400002)(6306002)(33656002)(478600001)(3846002)(53546010)(2900100001)(102836003)(6116002)(7696004)(5660300001)(55016002)(99286003)(6506006)(4326008)(2950100002)(6666003)(81166006)(8936002)(3280700002)(74316002)(53936002)(9686003)(38730400002)(2906002)(86362001)(6246003)(25786009)(50986999)(54356999)(7736002)(76176999)(229853002)(561944003)(93886004)(8676002)(189998001)(66066001)(305945005)(3660700001)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1366; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2017 16:08:37.6481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1366 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 1c690628-90d7-4967-85f0-a820bd36b0a3 X-VPM-MSG-ID: 2969b38e-687f-4e9f-87a9-be2b887902e2 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 16:08:45 -0000 Not sure what you are saying in regards to systems being badly designed or = bad reasoning or what our blatantly false assertions are? =20 I suspect this is not a productive path to pursue, so I will not. =20 But in an effort to keep this discourse on track with the issue at hand, = I will repeat my statement that converting everything to clear text is not = viable in my world(s). =20 =09 -----Original Message----- From: Stephen Farrell =5Bmailto:stephen.farrell=40cs.tcd.ie=5D=20 Sent: Saturday, July 8, 2017 5:09 AM To: Ackermann, Michael ; Watson Ladd = ; Christian Huitema Cc: tls=40ietf.org Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 On 08/07/17 03:06, Ackermann, Michael wrote: > Converting all session traffic to clear text is not a viable=20 > alternative for ANY enterprises or industries that I am aware of. In=20 > particular those in financial sectors. Security policies, legislation=20 > and in many cases just good practice would not allow for this. We are > compelled by these factors to encrypt all data in motion. But we > still need to manage our applications, networks, servers and clients. > Hence the need to decrypt traffic as outlined in this draft. That assertion of necessity is blatantly false. It is entirely feasible to decrypt and re-encrypt in many cases and for = that to be efficient and to meet regulatory needs. If some systems are so badly designed that doing that while updating to = tls1.3 is a showstopper then that's down to bad design or other bad = practices. Fixing those is the place to spend effort instead of spending = effort on breaking TLS. Other users of TLS ought not suffer on the basis of such bad reasoning. S. >=20 > -----Original Message----- From: TLS =5Bmailto:tls-bounces=40ietf.org=5D = On=20 > Behalf Of Watson Ladd Sent: Friday, July 7, 2017 9:40 PM To: > Christian Huitema Cc: tls=40ietf.org Subject: Re: > =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 >=20 > On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema=20 > wrote: >>=20 >>=20 >> On 7/7/2017 2:54 PM, Russ Housley wrote: >>> Stephen: ... >>>> And also: I'm sorry to have to say it, but I consider that=20 >>>> attempted weasel wording around the clear intent of 2804. The clear=20 >>>> and real effect if your wiretapping proposal were standardised by=20 >>>> the IETF would be that we'd be standardising ways in which TLS=20 >>>> servers can be compelled into breaking TLS - it'd be a standard=20 >>>> wiretapping API that'd be insisted upon in many places and would=20 >>>> mean significantly degrading TLS (only >>>> *the* most important security protocol we maintain) and the=20 >>>> community's perception of the IETF. It's all a shockingly bad idea. >>> I clearly disagree. Otherwise, I would not have put any work into=20 >>> the draft. >> Russ, >>=20 >> What are the specific mechanisms that would allow this technique to=20 >> be used where you intend it, i.e. within a data center, and not where=20 >> Stephen fears it would be, i.e., on the broad Internet? For example,=20 >> what mechanism could a client use to guarantee that this sort of=20 >> =22static DH=22 intercept could NOT be used against them? >=20 > The server can send the plaintext to whomever it likes. >=20 > This is the solution enterprises can use today. Nothing can stop that=20 > from happening. So I don't see why static DH is a) so essentially=20 > necessary and b) so controversial. >=20 >> From a technical point I prefer using DH shares derived from > ServerRandom as this avoids certain bugs I've been known to exploit=20 > from time to time. >=20 >>=20 >> -- Christian Huitema >>=20 >>=20 >> _______________________________________________ TLS mailing list=20 >> TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 > -- =22Man is born free, but everywhere he is in chains=22. --Rousseau. >=20 > _______________________________________________ TLS mailing list=20 > TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > The information contained in this communication is highly confidential=20 > and is intended solely for the use of the individual(s) to whom this=20 > communication is directed. If you are not the intended recipient, you=20 > are hereby notified that any viewing, copying, disclosure or=20 > distribution of this information is prohibited. Please notify the=20 > sender, by electronic mail or telephone, of any unintended receipt and=20 > delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan=20 > are nonprofit corporations and independent licensees of the Blue Cross=20 > and Blue Shield Association. >=20 > _______________________________________________ TLS mailing list=20 > TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Sat Jul 8 09:11:51 2017 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 B2CA1129B72 for ; Sat, 8 Jul 2017 09:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pVhTS_crsc05 for ; Sat, 8 Jul 2017 09:11:48 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002: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 246E412EB5D for ; Sat, 8 Jul 2017 09:11:48 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id 84so18336488ybe.0 for ; Sat, 08 Jul 2017 09:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X1PKBr3Xw5iH/AaVtFrPYBWzUZVCgkSFIFuQbLIc7yc=; b=mxWkPFzI2OXOLAaSOb/mr7Fwsy6n/vfID1D/+9Yrjrm6MPrsVIbKBHbRxmUbzZCUXP 5rO8CV+cQAvZzke+aYuGV4DMfJXZeBJit5qCg++EvQ1xLfdEsplIMEjtc/DXq/YVxCWW 09KWWiRWPglQqCjBVdQ7PpK5eE21DCIak6x3omD+O+tLYtIKP3eb2woLIsz7FC26nREa wOy3FBDfbM/GnFDCN+TJ4h7Y2Hh8LzEFHWSEdfdcJG4oWs4kGdYXHlFUFL4KX1JlbdsE s/hT+QvfSpoxhxFsw253+Id77B53/4ALGgtPWQvdp7+0IlcUF8H0ZUw1MlHGuAlJxytB gltQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X1PKBr3Xw5iH/AaVtFrPYBWzUZVCgkSFIFuQbLIc7yc=; b=p5PaSk4KlIhxLpuWJjHosHo5GUPMG0tNiKNu1DjeXjdY/3dq+pO90ARc0MBV6kn9Cg l9jvrlFeXvsM8xpEdHkMTpqYRMRDEvtHbCJIqxGdjCgsZ0SK1JnrX/6wPOTeLLXg0F4e cNC0zcv1FlwNZBR6ifi/msHnFz9XK6JfQKh72JvFyv+A+tu6zSCstG6n7fD0WkBseiLI tgT8UaBX1+Z//sXfHfP417iGS4cpJ0fCNK6ul+bxVzvj/SaPs69Rj7ImH+HzD2fZhfIg 7n0KcvOpOXyJziALE7mjC2/HBilwLyYVFE9iRldJWIQ89CBaF78euM8q/MM+Zr/i0C8x zWgA== X-Gm-Message-State: AIVw110LdKRvYdrhqJJZdMFOoDGmcXui2BtPzdWUuY0WA7PYIB25I68D 8mqt9fnNaKhz17ZnzBiVCOnoQKJb1A== X-Received: by 10.37.160.100 with SMTP id x91mr8300087ybh.140.1499530307236; Sat, 08 Jul 2017 09:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.192.216 with HTTP; Sat, 8 Jul 2017 09:11:26 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Sat, 8 Jul 2017 09:11:26 -0700 Message-ID: To: Richard Barnes Cc: Matthew Green , "" Content-Type: multipart/alternative; boundary="94eb2c1991b84b14e80553d09b7b" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 16:11:50 -0000 --94eb2c1991b84b14e80553d09b7b Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes wrote: > You could avoid changing how the DH works altogether by simply exporting > the DH private key, encrypted with a key shared with the monitoring device, > in a server extension. (Not in EncryptedExtensions, obviously.) This > would also have the benefit of explicitly signaling when such monitoring is > in use. The only real challenge here is that the client would have to > offer the extension in order for the server to be able to send it, which I > expect things like browsers would be unlikely to do. However, given that > the target of this draft seems to be intra-data-center TLS, perhaps this is > a workable requirement? > I very much like the property that by using an extension, the client must consent to being MitMed. But in this case, why not just keywrap the session master secret with a preshared KEK as opposed to exfiltrating the DH private key? -- Tony Arcieri --94eb2c1991b84b14e80553d09b7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 6:02 AM, Richard Barnes <rlb@ipv.sx> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
You could avoid changin= g how the DH works altogether by simply exporting the DH private key, encry= pted with a key shared with the monitoring device, in a server extension.= =C2=A0 (Not in EncryptedExtensions, obviously.)=C2=A0 This would also have = the benefit of explicitly signaling when such monitoring is in use.=C2=A0 T= he only real challenge here is that the client would have to offer the exte= nsion in order for the server to be able to send it, which I expect things = like browsers would be unlikely to do.=C2=A0 However, given that the target= of this draft seems to be intra-data-center TLS, perhaps this is a workabl= e requirement?

I very much like= the property that by using an extension, the client must consent to being = MitMed.

But in this case, why not just keywrap the= session master secret with a preshared KEK as opposed to exfiltrating the = DH private key?

--
Tony Arcieri
--94eb2c1991b84b14e80553d09b7b-- From nobody Sat Jul 8 09:14:14 2017 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 E53EB129B94 for ; Sat, 8 Jul 2017 09:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 evPNTAk-_wCU for ; Sat, 8 Jul 2017 09:14:12 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 DB30F129B37 for ; Sat, 8 Jul 2017 09:14:11 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 46598C15B9 for ; Sat, 8 Jul 2017 11:14:11 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 2CEECC15B3; Sat, 8 Jul 2017 11:14:10 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E013092069; Sat, 8 Jul 2017 12:14:09 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9709492053; Sat, 8 Jul 2017 12:14:09 -0400 (EDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (unknown [216.32.180.50]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Sat, 8 Jul 2017 12:14:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ArCepNYRIZuh1okYkGy8aiJ9qIL+/FaIelawHHzTnKo=; b=dWbawZNvNkrSTKLckhqNj4jfN1f+vC1b2O+2Lu9VgVY1ZLQtxpKBjy2MTHSXUhn38qz5NxbxQ39XoPWO/tGX+vSWLvpEshzpNbtvI0D1W38Mzw3lDjJEM2UdEGrS5k1zynpx7Z/ndqUGLtB/0kH1TEpYx4+4VV8+hqM39yc9NLo= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1367.namprd14.prod.outlook.com (10.172.158.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 8 Jul 2017 16:14:07 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.013; Sat, 8 Jul 2017 16:14:07 +0000 From: "Ackermann, Michael" To: Yoav Nir , Timothy Jackson CC: Watson Ladd , Christian Huitema , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIAABAWAgAAPEACAAAECAIAABj8AgAACzgCAAAGCAIAANuiAgAAIJQCAAASV8IAAFxiAgACb0ACAACyt8A== Date: Sat, 8 Jul 2017 16:13:47 +0000 Deferred-Delivery: Sat, 8 Jul 2017 16:12:00 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.0.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1367; 20:8w+sW7/eyZXttIvrjO9OMM4IAYVLdpehEyt3133jlDH2cHRWJFc6jMC6MPE44Hn1y9MZw64KIYwcJ6Kem9+6XPUe9HlRJQBQ8IgV/9U+S1RwAEwnZyxW5Fv+O8J93Cpm7jjSQ5IiLW6/DBI5AeCtA6dHk9mP1j/UBj17WCZXQ20= x-ms-office365-filtering-correlation-id: c924784b-ca9b-43f3-f545-08d4c61c5c68 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1367; x-ms-traffictypediagnostic: CY4PR14MB1367: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(148574349560750)(142563422833929)(21748063052155)(86572411397741)(266576461109395)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(2017060910075)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1367; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1367; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(377454003)(6506006)(80792005)(33656002)(7696004)(74316002)(53546010)(6666003)(6436002)(2950100002)(230783001)(19609705001)(93886004)(2906002)(4326008)(77096006)(229853002)(76176999)(54356999)(50986999)(5660300001)(3280700002)(72206003)(99286003)(66066001)(189998001)(3660700001)(55016002)(8936002)(54906002)(236005)(102836003)(6116002)(790700001)(53936002)(6246003)(3846002)(14454004)(81166006)(8676002)(478600001)(38730400002)(2900100001)(25786009)(7736002)(39060400002)(86362001)(6306002)(54896002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1367; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB13680AE2D7AED629EDBA6B5AD7AB0CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2017 16:14:07.6755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1367 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: c448b08b-441e-4281-b7f4-aff44167a944 X-VPM-MSG-ID: 8d86788a-3dd1-420b-a039-69305758bb8c X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 16:14:14 -0000 --_000_CY4PR14MB13680AE2D7AED629EDBA6B5AD7AB0CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: Yoav Nir =5Bmailto:ynir.ietf=40gmail.com=5D Sent: Saturday, July 8, 2017 8:36 AM To: Timothy Jackson Cc: Ackermann, Michael ; Watson Ladd = ; Christian Huitema ; = tls=40ietf.org Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 On 8 Jul 2017, at 6:18, Timothy Jackson = > wrote: As an earlier poster asked, what advantage does this approach have over = TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am = familiar is able to terminate at TLS connection, inspect/copy/filter, and = then encrypt on a new TLS sessions. For high performance customers, the SSL accelerators can be sandwiched = around the filter so all the crypto is done in hardware. The ways to prevent TLS inspection are cert pinning and client cert auth. = If this is only within one's data center, then those features can be = disabled if necessary, no? What use case am I missing that can't be achieved better by other means = than static keys? They would like to store traffic captures encrypted and be able to decrypt = them a little later if that is necessary. Storing plaintext is something = that auditors (rightfully=21) don't like. They also don't want to install TLS proxies all over the place. That's a = large extra expense for them. Yoav The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB13680AE2D7AED629EDBA6B5AD7AB0CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

&= =2343;1

<= o:p> 

F= rom: = Yoav Nir =5Bmailto:ynir.ietf=40gmail.com=5D
Sent: Saturday, July 8, 2017 8:36 AM
To: Timothy Jackson <tjackson=40mobileiron.com>
Cc: Ackermann, Michael <MAckermann=40bcbsm.com>; Watson Ladd = <watsonbladd=40gmail.com>; Christian Huitema = <huitema=40huitema.net>; tls=40ietf.org
Subject: Re: =5BTLS=5D = draft-green-tls-static-dh-in-tls13-01

 

 

On 8 Jul 2017, at 6:18, Timothy Jackson <tjackson=40mobileiron.com= > wrote:

 

= As an earlier poster asked, what advantage does this approach have over = TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am = familiar is able to terminate at TLS connection, inspect/copy/filter, and then encrypt on a new TLS = sessions. 

For high performance customers, the SSL accelerators can be sandwiched = around the filter so all the crypto is done in hardware.

The ways to prevent TLS inspection are cert pinning and client cert auth. = If this is only within one's data center, then those features can be = disabled if necessary, no?

What use case am I missing that can't be achieved better by other means = than static keys?

 

They would like to store traffic captures = encrypted and be able to decrypt them a little later if that is necessary. = Storing plaintext is something that auditors (rightfully=21) don&=238217;t = like.

 

They also don&=238217;t want to install TLS = proxies all over the place.  That&=238217;s a large extra expense for = them.

 

Yoav

 


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB13680AE2D7AED629EDBA6B5AD7AB0CY4PR14MB1368namp_-- From nobody Sat Jul 8 09:27:37 2017 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 BCD1312EB43 for ; Sat, 8 Jul 2017 09:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3gjY02y2Gexp for ; Sat, 8 Jul 2017 09:27:34 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e: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 4AB82129B94 for ; Sat, 8 Jul 2017 09:27:34 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id j186so30435568pge.2 for ; Sat, 08 Jul 2017 09:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NpIuz2TnLDMlBbEnN00N5POfhDdahkzutHx76ieDfmE=; b=KTuq6JLuXl0DyWvVALAfdmFdMFMnNTRCc8qsSpGtrCpA6n1LnNkpK9+p0OEXp68FNa Ug36BUL6WvJ6jxxDJsKU5/+1ZVFlbHx2sNtqLB12pLMcbbU32WZ255ByR2TVv0Nz01R3 OeN0AiL5ePAF+XaXGwIWlyd3PYBQSY0Xdq+hofhjX6ZlhlAfMEI18fx+TRnCqt5G0SFn Z4mpC6wjKnRrL3zMO8Sc9Qe4TcpB4T/afiXQzQSefcK5o6JPTJMY1OWPLxOm6CnqH9Z+ bs4+4aOjEtpCS7xeUzmCABJXadtqhOxsTZuoKA1uHFj83/LLfIQfKCHmHly6RnYEfRNt fbpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NpIuz2TnLDMlBbEnN00N5POfhDdahkzutHx76ieDfmE=; b=L/evTxz6rif6otTzXVp+fsc+d+5gVl3a+2ZsEFY5weB5TboA7LKYB86MpsTz3rYR02 1LXFkXCaO3Y21G2C2UeMVscCZl+erU5TotDVNIcsUGXUg/jNfi8NhD5JI76+FxX0bZVn GxWJOg8e8FmZhZJVck+xl68rSlhcGaXLMUzv8yt9nv3vT9u7vFj9tVBnB0jufxkq9phf VtzV3u0cWGHDcvcmcEnSckMNCVtKoD8PoT9+ZPSgQh9i2J6RxYOUDLRJKJaagrxFg3BJ BfmdetuBfJV6KqLXUBJoHtz9wl8oZxD5mgKEd6UMKMv6aoM6ucssTt7x9a5nFwF2DtPR SnJQ== X-Gm-Message-State: AIVw113Kpa0NDg0Rn2WWT37PaO63I34/OPawg7bybg5BHl4M5tqf87T8 FwFgNg29NxvQF+vDZ60EfvaQL7211Q== X-Received: by 10.99.94.70 with SMTP id s67mr6978636pgb.82.1499531253896; Sat, 08 Jul 2017 09:27:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Sat, 8 Jul 2017 09:27:32 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> From: Watson Ladd Date: Sat, 8 Jul 2017 09:27:32 -0700 Message-ID: To: Yoav Nir Cc: Timothy Jackson , "Ackermann, Michael" , Christian Huitema , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 16:27:36 -0000 On Sat, Jul 8, 2017 at 5:36 AM, Yoav Nir wrote: > > On 8 Jul 2017, at 6:18, Timothy Jackson wrote: > > As an earlier poster asked, what advantage does this approach have over > TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am > familiar is able to terminate at TLS connection, inspect/copy/filter, and > then encrypt on a new TLS sessions. > > For high performance customers, the SSL accelerators can be sandwiched > around the filter so all the crypto is done in hardware. > > The ways to prevent TLS inspection are cert pinning and client cert auth.= If > this is only within one's data center, then those features can be disable= d > if necessary, no? > > What use case am I missing that can't be achieved better by other means t= han > static keys? > > > They would like to store traffic captures encrypted and be able to decryp= t > them a little later if that is necessary. Storing plaintext is something > that auditors (rightfully!) don=E2=80=99t like. Then renencrypt the data on the storage device. > > They also don=E2=80=99t want to install TLS proxies all over the place. = That=E2=80=99s a > large extra expense for them. Nginx exists. What's the blocker? > > Yoav > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Jul 8 09:31:09 2017 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 2D28D12EBF6 for ; Sat, 8 Jul 2017 09:31:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BYUwLqiGt54U for ; Sat, 8 Jul 2017 09:31:05 -0700 (PDT) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::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 F10A412EB43 for ; Sat, 8 Jul 2017 09:31:04 -0700 (PDT) Received: by mail-wr0-x244.google.com with SMTP id 77so14602388wrb.3 for ; Sat, 08 Jul 2017 09:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nqAfTkQUb4IkwtXHpOLIxi2BvKYh/usqnf0VFBJl24I=; b=Osw1fugy69vgp2N+VKUyPHkHzzOxNMW2aFP4Cplsb5URLO2D9U4wMrKpON6dxtozRS HGHuqYD11YR9lPQbgTa1/Q8NO5XKfJLAyaQWqlXoMvtLNwL8oYA0aSoGn0JVaK8A+Hdl Up8BsOAoZu00E6A6ZI5gh82b1VxYI7KVxUVA0zVVeCZjW0msI9x1C1+RDHYOaui4uvDF gGgDFR6Jx+MloSSr/Kh54GL76Fl9MtIR5fbaC/LsndTzBleFDT1EZzjsYGJSYw3YygCv OKk4IDixGK+RHurSGrQvVK5CLGyj2Ii7pQMlgRgQEyWt1ipsUdHkYGvjS+pd3+EHytXu ZR6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nqAfTkQUb4IkwtXHpOLIxi2BvKYh/usqnf0VFBJl24I=; b=f7t7SH0Vj24c6NhnSNBze5x3NHJhekvwA+7UT7wmK3xWSHNYVvGHvC7a1HZR1qy9D3 mSBOaV1mYpSAvc31Muuwb6eI+S6U1jYr603TIyYixHkKzlCERfB7uYH7jy1vTAqQrjiJ tmanTNSRFF7wlwPV10OjQNa9FGFPINUJ278fyLtownfbw0lt/S1a1oee8mC/x2hZx9LG 7xE2kJotqNQGNgGXUoBFJoQWGtmj6MBjlyaXy3GZ0sCKi0e4/pPTUwEvy+DTi91Kwfiw xiR5LGK01q79CN3kIiDAI7Do1YThkGmKjmDriKJHD1CD6Dhu7FIivvdChGvCriqP6gHI 7jog== X-Gm-Message-State: AIVw110Fj2u9vJw78hFU8bqhW3FuB5k4WV1jXXfryS9RxfzYakNGIyA7 hWRRrm2uhNsRRliyCYY= X-Received: by 10.80.240.141 with SMTP id v13mr3585936edl.36.1499531463439; Sat, 08 Jul 2017 09:31:03 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p49sm5483426edc.47.2017.07.08.09.31.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 09:31:02 -0700 (PDT) From: Yoav Nir Message-Id: <9B6D1269-BFC1-42BC-80DD-4F440FEEB9C4@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_21B1F608-226E-49AC-B331-4D671DF18DBF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 8 Jul 2017 19:31:00 +0300 In-Reply-To: Cc: Stephen Farrell , "tls@ietf.org" , tls chair To: Tony Arcieri References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 16:31:07 -0000 --Apple-Mail=_21B1F608-226E-49AC-B331-4D671DF18DBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Jul 2017, at 18:39, Tony Arcieri wrote: >=20 > I was one of the people arguing my hardest against the BITS Security = proposal to continue to (ab)use RSA static keys to allow passive MitM, = even though TLS 1.3 had already moved forward on what I would call a = more modern protocol design of the sort I believe payments companies = should embrace to improve their security. >=20 > That said, if people do want to MitM themselves, I would rather there = be a single, easily detectable and very explicit way of doing so, as = opposed to sketchy, incompatible, ad hoc mechanisms. But all the MITM solutions, whether proxies or static DH are not easily = detectable. Client-side proxies - the kind deployed by enterprises - are = visible to clients (by the CA signing the proxy certificates) but not to = the servers. This is implemented on the server, but is invisible to the = client. Even if the client rapid-fires several handshakes to see if the = public key does not change, this is indistinguishable from the = optimization of using the same key-pair for several seconds (without = saving the private key). > Furthermore, it would be nice to have a clear answer for these users, = less they continue to make (bad) arguments that there is something = fundamentally wrong with the design of TLS 1.3 that makes it = incompatible with "industry requirements". >=20 > Clearly there are echoes of the scary protocols of yesteryear, i.e. = Clipper/LEAP. I think if you visit Matt Green's Twitter page and check = the image header you will discover he is quite familiar with these = things, and my personal presumption would be he is not displaying this = image to show his undying love of the Clipper chip, although perhaps = he's an especially crafty and duplicitous NSA sleeper agent. It=E2=80=99s not about the reputations or motivations of the impressive = list of authors. It=E2=80=99s about having the capability built into = widely used products and libraries. Suppose you have an Internet-facing server with TLS 1.2 and an ECDSA = certificate and all supported ciphersuites are ECDHE-ECDSA.Suppose = further that your server is using the ever popular Apache/modssl/openssl = stack. If you want to disable forward secrecy you have to either replace the = certificate with an RSA certificate and move to all static RSA = ciphersuites, or you need to replace your stack with something that does = what this draft describes. With this draft widely implemented it=E2=80=99s just a matter of turning = the capability on. We can=E2=80=99t really stop people implementing it, It=E2=80=99s not = detectable by the client and an implementation would seem to be fully = compliant with TLS 1.3. And I don=E2=80=99t know how to implement this = in such a way that it would work for =E2=80=9Cgood=E2=80=9D purposes but = not for =E2=80=9Cbad=E2=80=9D purposes, however one defines good and bad = here. --Apple-Mail=_21B1F608-226E-49AC-B331-4D671DF18DBF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZYQjFAAoJELhJCxUKWMyZwb8IAJyeWOHcuFnd4RJyPyId7feh D73Xhk+RDcG5XmgChevv/WjCShFCe1f4qkGER6YoAsex3NS12JDrfpuBO7Hs2fkC RA8sNFDI6TP2AaeO5Wa5NajFh3aZg0xWlHk/ISF3vvBnAXBXfMrlRXAXceEKJbQB NTtDVWCK6cZ9hTmzD4tRwpnWjnmwW9rTKISiXEmzcxPwuS1RLDyiDZXZ30yF69PK 98DHK5uSw9sm+TU/HjRSoPTOqWHtIBYY3sSzIEn3TytZezb9h/wqx/80ZOhDjSMr buMRI11b074hbkRB0haGHxPMGiN3L8QQZMmbYVXkOIz6t396SzRbqUAG3pCA88w= =sMx+ -----END PGP SIGNATURE----- --Apple-Mail=_21B1F608-226E-49AC-B331-4D671DF18DBF-- From nobody Sat Jul 8 09:38:50 2017 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 BA9C412EC0C for ; Sat, 8 Jul 2017 09:38:48 -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, RP_MATCHES_RCVD=-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 aqmgW37WDwoC for ; Sat, 8 Jul 2017 09:38:47 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 5E080129AFC for ; Sat, 8 Jul 2017 09:38:46 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89.108) id 1dTskl-0002fZ-Td for tls@ietf.org (return-path ); Sat, 08 Jul 2017 16:38:44 +0000 To: tls@ietf.org References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> From: Jeremy Harris Message-ID: <4f68417d-e4cf-4642-9c63-b2ccf379e553@wizmail.org> Date: Sat, 8 Jul 2017 17:38:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 16:38:49 -0000 On 08/07/17 13:36, Yoav Nir wrote: > They also don’t want to install TLS proxies all over the place. That’s a large extra expense for them. The predicated architecture - tappable inside, non-tappable outside the enterprise - requires exactly that. -- Jeremy From nobody Sat Jul 8 09:41:22 2017 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 9159012EC0C for ; Sat, 8 Jul 2017 09:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeGUYR3PZwD8 for ; Sat, 8 Jul 2017 09:41:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED351200F3 for ; Sat, 8 Jul 2017 09:41:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1147DBE49; Sat, 8 Jul 2017 17:41:18 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAm44pvno9QG; Sat, 8 Jul 2017 17:41:17 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EB7EEBE39; Sat, 8 Jul 2017 17:41:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499532077; bh=ZpzLYANt1xyp7Tkf1U4TlJ0umrkFt/VUVZQoOiw+O14=; h=Subject:To:References:From:Date:In-Reply-To:From; b=4VyNV2bOGr+MsqMJm5eNNVjJEODCWtgwiP9ysodcfWtpwMKc1SIzWJ8necb6kaQSl QpmYTCCk6mNpgVSoNAg+sJTmyDb1OPORfRl0Xj4fubzc0Ufb1To3GLrfKfM4Mc9+ay be/K3Uod+f8QXdKpzLyXDj6zxhogy6N3bgmnM+8Y= To: Jeremy Harris , tls@ietf.org References: <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> <4f68417d-e4cf-4642-9c63-b2ccf379e553@wizmail.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2ed4f60c-a7ab-111a-e90a-46b24531b41e@cs.tcd.ie> Date: Sat, 8 Jul 2017 17:41:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4f68417d-e4cf-4642-9c63-b2ccf379e553@wizmail.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dqKk04vUXssmq0QSCH8BNlJIKpOPpSbCe" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 16:41:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dqKk04vUXssmq0QSCH8BNlJIKpOPpSbCe Content-Type: multipart/mixed; boundary="o8OCQ63JvlQ50k5saerFFlH8wEAhaaD4f"; protected-headers="v1" From: Stephen Farrell To: Jeremy Harris , tls@ietf.org Message-ID: <2ed4f60c-a7ab-111a-e90a-46b24531b41e@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> <4f68417d-e4cf-4642-9c63-b2ccf379e553@wizmail.org> In-Reply-To: <4f68417d-e4cf-4642-9c63-b2ccf379e553@wizmail.org> --o8OCQ63JvlQ50k5saerFFlH8wEAhaaD4f Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/07/17 17:38, Jeremy Harris wrote: > The predicated architecture - tappable inside, non-tappable outside the= > enterprise=20 That's fiction. S --o8OCQ63JvlQ50k5saerFFlH8wEAhaaD4f-- --dqKk04vUXssmq0QSCH8BNlJIKpOPpSbCe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYQssAAoJEC88hzaAX42ijmoIAILJyw1qcOHNLXHCznY8WCoP UpMpmCeTDPWsOmFjsh60K+b8FA04mnS31G2C6NIgpMaZgnAaV5JfSrGhsTzYoYiB 55jMyWI7N5P5+bpL1HeXMX0uP6Oxk6ZVAPKW68uD+FY6s1hojitWk7cXBKRTiCZg u1Dh8SDqa8DOPut47DpUSAj4/yfYS4kevBvbiVZLltAxlZB2zCxWsQYCv7G6tvsj x9PkJZehXJ4DeLghuCJYDkHc+78VLoTzmXjfsLT3M21MQs7D02zJawD6O8vo43u/ HkKwsO88enPQH18rNJShqsf6OV/t4WYwpt6K9c2IjuKc4S3YOlZMC8lOpPugaNA= =SWwA -----END PGP SIGNATURE----- --dqKk04vUXssmq0QSCH8BNlJIKpOPpSbCe-- From nobody Sat Jul 8 10:05:10 2017 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 6DA3712EC36 for ; Sat, 8 Jul 2017 10:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 HkhYNE_dNP7i for ; Sat, 8 Jul 2017 10:05:07 -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 1EEEE1201FA for ; Sat, 8 Jul 2017 10:05:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 681E23004D7 for ; Sat, 8 Jul 2017 13:05:06 -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 mSc9fDUKF6LV for ; Sat, 8 Jul 2017 13:05:05 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 3C742300429; Sat, 8 Jul 2017 13:05:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> Date: Sat, 8 Jul 2017 13:05:03 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <98EB3DAA-DEC7-4D5A-96C4-872A345C7B34@vigilsec.com> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 17:05:08 -0000 >>> And also: I'm sorry to have to say it, but I consider that >>> attempted weasel wording around the clear intent of 2804. The >>> clear and real effect if your wiretapping proposal were standardised >>> by the IETF would be that we'd be standardising ways in which >>> TLS servers can be compelled into breaking TLS - it'd be a standard >>> wiretapping API that'd be insisted upon in many places and would >>> mean significantly degrading TLS (only *the* most important >>> security protocol we maintain) and the community's perception >>> of the IETF. It's all a shockingly bad idea. >> I clearly disagree. Otherwise, I would not have put any work into = the draft. >=20 > What are the specific mechanisms that would allow this technique to be > used where you > intend it, i.e. within a data center, and not where Stephen fears it > would be, i.e., on > the broad Internet? For example, what mechanism could a client use to > guarantee > that this sort of "static DH" intercept could NOT be used against = them? >=20 Christian: In draft-green-tls-static-dh-in-tls13, there is not one. I have not = thought about it in these terms. The server, if acting in bad faith, = can always release the client's traffic. Russ From nobody Sat Jul 8 10:17:29 2017 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 A63DB126C83 for ; Sat, 8 Jul 2017 10:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0tID2sCYtY1 for ; Sat, 8 Jul 2017 10:17:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB3412EC4E for ; Sat, 8 Jul 2017 10:17:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F0EB1BE53; Sat, 8 Jul 2017 18:17:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOtht54OyFv9; Sat, 8 Jul 2017 18:17:22 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C2DB9BE24; Sat, 8 Jul 2017 18:17:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499534242; bh=9XcRI3qiVNzmzxhahRmL+99kKmGCLWT3qOtMH0+FFSM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pK5S7OxUt1Gu/2WskwXd2ssCUUIM+pqkc/7vCiDpKpOHSFDAEGI2uavRrhFqiiV+z Mt3nOpgyoB53DhgofwZvoDVCRjZzegvCWN7j9z2Yh+e5E8BjnliR14ao10UyuTGDVJ k+yV7qhsw1mOXHu5GJdRt+khE04XZ3MBN8ERgxK0= To: Russ Housley , Christian Huitema Cc: IETF TLS References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> <98EB3DAA-DEC7-4D5A-96C4-872A345C7B34@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9b3c3630-cba9-661b-a9de-a5a51e39ff8e@cs.tcd.ie> Date: Sat, 8 Jul 2017 18:17:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <98EB3DAA-DEC7-4D5A-96C4-872A345C7B34@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="20PIFE1LF6gxWJQuAGU6Bhwhgbjp7u3pK" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 17:17:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --20PIFE1LF6gxWJQuAGU6Bhwhgbjp7u3pK Content-Type: multipart/mixed; boundary="X6Ct03DMQPuWhCrmUeplA6CX2ik7dBmPH"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , Christian Huitema Cc: IETF TLS Message-ID: <9b3c3630-cba9-661b-a9de-a5a51e39ff8e@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> <98EB3DAA-DEC7-4D5A-96C4-872A345C7B34@vigilsec.com> In-Reply-To: <98EB3DAA-DEC7-4D5A-96C4-872A345C7B34@vigilsec.com> --X6Ct03DMQPuWhCrmUeplA6CX2ik7dBmPH Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/07/17 18:05, Russ Housley wrote: > In draft-green-tls-static-dh-in-tls13, there is not one. I have not > thought about it in these terms. The server, if acting in bad faith, > can always release the client's traffic. Is it bad faith if the server is compelled to enable this wiretap interface? For a wiretapper this is a great scheme, as they only need to force it to be turned on and accept a tiny bit of data and then they can pick up those packets from anywhere without having to deal with problems at the web server end. So no need to even re-imburse the web server for the intercepted access anymore. Honestly, doesn't that clearly mean a conflict with 2804? And one that cannot afaics be avoided. S. --X6Ct03DMQPuWhCrmUeplA6CX2ik7dBmPH-- --20PIFE1LF6gxWJQuAGU6Bhwhgbjp7u3pK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYROiAAoJEC88hzaAX42iqggIAJaIpjGnSmJttDsAgDgspNAn e+6govuOAHKWcrF8dTM6i7ZAXFhjP6JRaGjMKO1K6p/uck9h04enIaLXipFtG9PO WiZ0kDjI3KD+8kp2Av4BLWExf9GG77I3S69dztzoxNyJXaBzUNkb/On9YEtMkDI8 Akr8eJX0asEDFTqPS853p9Eh2q7EnKs+LLtHY+VTFlU82KUMCLsnuiU2qOn4TAnO IICSyawOBybFDztvd+3nCxzWMytzcB/Cu6wIDJ+9JDrlW/XWKPtS+Jhv2uRvguEQ npohDXa4hiNac6aqU6yIltUAfHUcu/Fjrf82Zihvawy3NkefpGw9klI2EIoYolU= =2p9m -----END PGP SIGNATURE----- --20PIFE1LF6gxWJQuAGU6Bhwhgbjp7u3pK-- From nobody Sat Jul 8 10:17:44 2017 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 11C7F12ECB6 for ; Sat, 8 Jul 2017 10:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=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 A3fjDR1hLJOZ for ; Sat, 8 Jul 2017 10:17:40 -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 72B9712ECB3 for ; Sat, 8 Jul 2017 10:17:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 971ED3004C3 for ; Sat, 8 Jul 2017 13:17:39 -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 P757spVA-aX7 for ; Sat, 8 Jul 2017 13:17:38 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 10FD930043A; Sat, 8 Jul 2017 13:17:37 -0400 (EDT) From: Russ Housley Message-Id: <9F15A30E-92B1-4143-8285-8A652E914F50@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4A7BDC70-A3CA-465C-8ABC-2E5C071C7054" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 8 Jul 2017 13:17:36 -0400 In-Reply-To: Cc: IETF TLS To: Tony Arcieri References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 17:17:42 -0000 --Apple-Mail=_4A7BDC70-A3CA-465C-8ABC-2E5C071C7054 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tony: I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not = enable MitM. The server does not share the signing private key, so no = other party can perform a valid handshake. Further, the server is = choosing to use a (EC)DH key that was generated by the key manager, so = it is quite different than the mandatory key escrow used in the Clipper = Chip. Russ > On Jul 8, 2017, at 11:39 AM, Tony Arcieri wrote: >=20 > I was one of the people arguing my hardest against the BITS Security = proposal to continue to (ab)use RSA static keys to allow passive MitM, = even though TLS 1.3 had already moved forward on what I would call a = more modern protocol design of the sort I believe payments companies = should embrace to improve their security. >=20 > That said, if people do want to MitM themselves, I would rather there = be a single, easily detectable and very explicit way of doing so, as = opposed to sketchy, incompatible, ad hoc mechanisms. Furthermore, it = would be nice to have a clear answer for these users, less they continue = to make (bad) arguments that there is something fundamentally wrong with = the design of TLS 1.3 that makes it incompatible with "industry = requirements". >=20 > Clearly there are echoes of the scary protocols of yesteryear, i.e. = Clipper/LEAP. I think if you visit Matt Green's Twitter page and check = the image header you will discover he is quite familiar with these = things, and my personal presumption would be he is not displaying this = image to show his undying love of the Clipper chip, although perhaps = he's an especially crafty and duplicitous NSA sleeper agent. --Apple-Mail=_4A7BDC70-A3CA-465C-8ABC-2E5C071C7054 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Tony:

I = want to highlight that draft-green-tls-static-dh-in-tls13-01 does not enable MitM. =  The server does not share the signing private key, so no other = party can perform a valid handshake.  Further, the server = is choosing to use a (EC)DH key that was generated by the key manager, = so it is quite different than the mandatory key escrow used in the Clipper = Chip.

Russ


On Jul 8, 2017, at 11:39 AM, = Tony Arcieri <bascule@gmail.com> wrote:

I was one of the people arguing my hardest against the BITS = Security proposal to continue to (ab)use RSA static keys to allow = passive MitM, even though TLS 1.3 had already moved forward on what I = would call a more modern protocol design of the sort I believe payments = companies should embrace to improve their security.

That said, if people do want to MitM = themselves, I would rather there be a single, easily detectable and very = explicit way of doing so, as opposed to sketchy, incompatible, ad hoc = mechanisms. Furthermore, it would be nice to have a clear answer for = these users, less they continue to make (bad) arguments that there is = something fundamentally wrong with the design of TLS 1.3 that makes it = incompatible with "industry requirements".

Clearly there are echoes of the scary = protocols of yesteryear, i.e. Clipper/LEAP. I think if you visit Matt = Green's Twitter page and check the image header you will discover he is = quite familiar with these things, and my personal presumption would be = he is not displaying this image to show his undying love of the Clipper = chip, although perhaps he's an especially crafty and duplicitous NSA = sleeper agent.

= --Apple-Mail=_4A7BDC70-A3CA-465C-8ABC-2E5C071C7054-- From nobody Sat Jul 8 10:30:42 2017 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 9D53D126C83 for ; Sat, 8 Jul 2017 10:30:40 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 y3qlnVCBDjop for ; Sat, 8 Jul 2017 10:30:38 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 C3766129B04 for ; Sat, 8 Jul 2017 10:30:37 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id c11so86055879wrc.3 for ; Sat, 08 Jul 2017 10:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VbfXo/G2fHxKT6Oi7WT5KLm06Wd8cfKp7F1rPk5BIho=; b=QYUdR1OKMmMwA74zoLxizIGw8u9xMCdyMjKQepY5Grj2iVhZkRIij/G116pBithn0H r+zphZcQMxu6/aV78gfBnGpsClIKXEnqCDewL0PrspzJI6kEGAjW3v5qhA64l/5fGzAs ihTeo26VJm+VJOFAjQSsGPd4dyOv6G2rVYrmmSedbt8NQ2K3cy5J8JY10vFhHOlXMfQv 153S4WBPGIxmZ1tRtc34Wx/wPEy1qjQT6D7ubYMm1gWruApjvcEWyMkJBsu0JBNmeROE 8DeWSAeySNpZP9XDiWBnWMAl/w/vObvMmPsMs+KVlpeimud5CsukV9l7yjLU16J6VhwV NpBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VbfXo/G2fHxKT6Oi7WT5KLm06Wd8cfKp7F1rPk5BIho=; b=lnmmrWGeW3fUUl4tS0sAhqy7Tx6b9T0FqexSZahZECYxI1ipWZ4PYIipwNhUbMlI53 GH5EnsxSQjzRBrC81ZAe0QczwyOtDW952d7Jg6aMzcnU3k3/+2psey3rtT8G19R3WAvv Mjyf6gvo5pCjMcsX7qXpYBg1r1TrMYzY52OjmhKZ3TKO3LOW4QSGSiztBsI34Ch/u15b XG/vOv5Z+QVAFxtbWE/CbZwfz/QpIC8t8W8WJh9PT1m7WuWiJi1s9T8UeGtor7pIhgJi 5V82yXMn001tZYWfra68bi/iXrDqhw15vI3ncsH2Ww1Qf2kgkVrRpLxXiw9v67E/ckPF Y8lg== X-Gm-Message-State: AIVw110z3Y3gqOHxgTZgicRmG5DVYu5ifOKQ5fAeQUeU55fXZPNO3td2 h5L70DlmW2IcqzWBRN8bCF+KYkZgxRUA X-Received: by 10.223.153.114 with SMTP id x105mr3716739wrb.18.1499535036061; Sat, 08 Jul 2017 10:30:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Sat, 8 Jul 2017 10:30:35 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Sat, 8 Jul 2017 13:30:35 -0400 Message-ID: To: Tony Arcieri Cc: Matthew Green , "" Content-Type: multipart/alternative; boundary="f403045d573227303e0553d1b5d9" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 17:30:41 -0000 --f403045d573227303e0553d1b5d9 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 12:11 PM, Tony Arcieri wrote: > On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes wrote: > >> You could avoid changing how the DH works altogether by simply exporting >> the DH private key, encrypted with a key shared with the monitoring device, >> in a server extension. (Not in EncryptedExtensions, obviously.) This >> would also have the benefit of explicitly signaling when such monitoring is >> in use. The only real challenge here is that the client would have to >> offer the extension in order for the server to be able to send it, which I >> expect things like browsers would be unlikely to do. However, given that >> the target of this draft seems to be intra-data-center TLS, perhaps this is >> a workable requirement? >> > > I very much like the property that by using an extension, the client must > consent to being MitMed. > > But in this case, why not just keywrap the session master secret with a > preshared KEK as opposed to exfiltrating the DH private key? > Actually, now that you mention it, something like that is probably necessary -- I expect that there are unstated requirements here to support for resumption (without having to find the previous session) and probably 0xRTT, and those modes use in a shared secret in addition to the DH secret. So you would need to exfiltrate the PSK as well. Looking at the key schedule [1], it looks like it would not be sufficient to send the master secret, since that wouldn't get you early data or handshake messages, but it would be enough to exfiltrate the DH and PSK secrets. Nonetheless, I don't think this significantly changes the proposed design. The interesting question is still whether opt-in is an acceptable requirement for the folks looking for a mechanism here. --Richard [1] https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.7.1 --f403045d573227303e0553d1b5d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 8, 2017 at 12:11 PM, Tony Arcieri <bascule@gmail.com&g= t; wrote:
On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes <rlb@ipv.sx><= /span> wrote:
You could avoid changing how the DH works altogether by simpl= y exporting the DH private key, encrypted with a key shared with the monito= ring device, in a server extension.=C2=A0 (Not in EncryptedExtensions, obvi= ously.)=C2=A0 This would also have the benefit of explicitly signaling when= such monitoring is in use.=C2=A0 The only real challenge here is that the = client would have to offer the extension in order for the server to be able= to send it, which I expect things like browsers would be unlikely to do.= =C2=A0 However, given that the target of this draft seems to be intra-data-= center TLS, perhaps this is a workable requirement?

I very much like the property that by using an = extension, the client must consent to being MitMed.

But in this case, why not just keywrap the session master secret with a p= reshared KEK as opposed to exfiltrating the DH private key?

Actually, now that you mention it,= something like that is probably necessary -- I expect that there are unsta= ted requirements here to support for resumption (without having to find the= previous session) and probably 0xRTT, and those modes use in a shared secr= et in addition to the DH secret.=C2=A0 So you would need to exfiltrate the = PSK as well.

Looking at the key schedule [1], = it looks like it would not be sufficient to send the master secret, since t= hat wouldn't get you early data or handshake messages, but it would be = enough to exfiltrate the DH and PSK secrets.

N= onetheless, I don't think this significantly changes the proposed desig= n.=C2=A0 The interesting question is still whether opt-in is an acceptable = requirement for the folks looking for a mechanism here.
--f403045d573227303e0553d1b5d9-- From nobody Sat Jul 8 10:34:14 2017 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 3043312EB97 for ; Sat, 8 Jul 2017 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, 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=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 cZKe7CZ2p2gp for ; Sat, 8 Jul 2017 10:34:12 -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 800E5129B04 for ; Sat, 8 Jul 2017 10:34:12 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l21so23323117ywb.1 for ; Sat, 08 Jul 2017 10:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FC9oYzysq5KL8yqgpyC6pmE/h8XTYFPq+FX4PeLoovk=; b=GIWD34m7dKMTBX00t84mKYPZjjOujtGcrNBl08/euX5Ld6t9XZpH7bJY7opOfqO3Ui ImSx/bE2L3go+b1qRZiDicAsbNWf3a54ms0K5cyV71nEQ2QpSXlIfg/yPBJwmNWzltHS Kw/v+ISHpUMddAsqHvKsmNDy8ZcE74MSU3XZEa5gYFo8xr3uVU+kz0SYBOZaIcy+yRmg rTaQj8fWJdYIE/INjcZ6MLxANTf2WxKOMIPLpVs7gzj5RSp5MmzBXEW5RmIhIPYYj75Q gGtgi3d8c7g2rLqzNwHhWUAqY7eOVZaBmONA98lxEg+X+5pzFvOSi1KsAbxiCF0XB7tT c4Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FC9oYzysq5KL8yqgpyC6pmE/h8XTYFPq+FX4PeLoovk=; b=Yl8lcICdSXbukGWKvbYtOUEkgsbqlzbfG228rojruK2UMpnR8Pl70k0hctSzwVoWFk NQ55PvQl3+8swhH+SWYBSs4xoJQDCjAyC4wCT8+Ivi+lP/vyW/xq+EsRiVoYak0hZzj6 pwe/ba/pbLLqI9vyF6iRsIebkD0QFhTl4TjI/DkeVjm6AoOszGJ59sIqBXoW0Z16zz2O 89qVS2dwT5415U4g8lh+jqv/ODX94rEWfFE2uXqGQExVzJLwLfQGfXMVZvD1bmAOl6yL MIwY9D/HgTC4wYLhW1w/7C9g5cnCc0cHaaAv+dyUlAcGqteqTcHiBKg/RbPiEGFLb42k UyKA== X-Gm-Message-State: AIVw111jmul+hsCUUh4yn84OEbjdjjCMDnq+clvJmsha9r+Q+NlfAZsh ydm278OV3XLeQ6ut7QoqHI191oYmBg== X-Received: by 10.129.163.130 with SMTP id a124mr5927672ywh.138.1499535251681; Sat, 08 Jul 2017 10:34:11 -0700 (PDT) MIME-Version: 1.0 References: <9F15A30E-92B1-4143-8285-8A652E914F50@vigilsec.com> In-Reply-To: <9F15A30E-92B1-4143-8285-8A652E914F50@vigilsec.com> From: Tony Arcieri Date: Sat, 08 Jul 2017 17:34:00 +0000 Message-ID: To: Russ Housley Cc: IETF TLS Content-Type: multipart/alternative; boundary="94eb2c115e340138cd0553d1c2d5" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 17:34:14 -0000 --94eb2c115e340138cd0553d1c2d5 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 11:17 AM Russ Housley wrote: > I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not > enable MitM. The server does not share the signing private key, so no > other party can perform a valid handshake. > This method allows a middlebox to recover the plaintext of a TLS session. While I took issue with Stephen's attempts to shut down conversations this line of inquiry, I have a much, much stronger objection to downplay the fact that this is still a self-inflicted MitM attack. Let me be very clear: full plaintext recovery by a passive middlebox absolutely is "MitM". Just because it does not allow full impersonation of the server does not make it MitM. It is MitM, and we should be very clear it is MitM. Further, the server is choosing to use a (EC)DH key that was generated by > the key manager, so it is quite different than the mandatory key escrow used > in the Clipper Chip. > It enables the same ends: recovery of session plaintexts, and as I stated on other threads I would personally prefer a more explicit key escrow mechanism implemented as a TLS extension, which to some degree would actually look a bit more like LEAP. > -- Tony Arcieri --94eb2c115e340138cd0553d1c2d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 8, 2017 at 11:17 AM Russ Housley <housley@vigilsec.com> wrote:
I want to highlight that=C2=A0draft-green-tls-static-dh-in-tls13-01 does not = enable MitM.=C2=A0 The server does not share the signing private key, so no= other party can perform a valid handshake.

This method allows a middle= box to recover the plaintext of a TLS session. While I took issue with Step= hen's attempts to shut down conversations this line of inquiry, I have = a much, much stronger objection to downplay the fact that this is still a s= elf-inflicted MitM attack.

Let me be very clear: full plaintext recovery by a passive middlebox abs= olutely is "MitM". Just because it does not allow full impersonat= ion of the server does not make it MitM. It is MitM, and we should be very = clear it is MitM.

Further,=C2=A0the=C2=A0server is choos= ing to use a (EC)DH key that was generated by the key manager, so it is qui= te different than the mandatory key=C2=A0esc= row=C2=A0used in the Clipper = Chip.

It enables the same ends: recovery of session plaintexts, and as = I stated on other threads I would personally prefer a more explicit key esc= row mechanism implemented as a TLS extension, which to some degree would ac= tually look a bit more like LEAP.
--
Tony Arcie= ri
--94eb2c115e340138cd0553d1c2d5-- From nobody Sat Jul 8 10:39:48 2017 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 D46FC12ECB3 for ; Sat, 8 Jul 2017 10:39:46 -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 6IGWDNNixaWY for ; Sat, 8 Jul 2017 10:39:45 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 10C2512EB97 for ; Sat, 8 Jul 2017 10:39:45 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id u62so30854846pgb.3 for ; Sat, 08 Jul 2017 10:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=30hUTBzN5U79NL0cCOgmYvkn6fqUIJSb8JXO26ipZyM=; b=F2EUlAJwr607zXDQqkYaI4hmrAMEV0wWulB3njNfWcoCW/f+n6uGz5mILz53N9EoU6 /rwFR0648eVOuQXP28V9Hnbp4Tvk8NVU3gTMAeqKryLNHyMwk4E4eiYxebGtthmc7Llh 1wAfkq8JG9NnXgKXI1ingSat+eRGzaajot8wwKNqwyeXXKE7g7BXjqJU5lQiOsGiP83R qcnAeJcJSYqwFdPSgL1RRVpoIgc/7/iEw1t6uc6qcAWjUGRAobuQGQ/IpPRvTLm4klFs 65kNc/sBDOfGRX5/gPpWxN0DXpxY1m3RxoRo29RhTxXIytbrOVUI+2ovIpZVK3tkXwVq 9WWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=30hUTBzN5U79NL0cCOgmYvkn6fqUIJSb8JXO26ipZyM=; b=kbalsKCBoqC9rRQ05/he/O2l7LJ1qS1rUjhy2oTrcmZ3+YHHfX22XtkNHerPt/6aSp znqM1IyaUKKDTn/CSqEQIWhER+keO2pfw8hJ3cnD/Kl85EP+OFtEC2/5PfoPTT/mOWt8 4uSRQJVu9xPcKn3Fe2GjkGbySVhS2qw80krQMb4lJnTXvNknRQiVYUv5EllL4xk0lK8i h87KpKg9sAebNJRhT+Ur1VotRTvlE5KvcqIOlQduiCM04ItLGW/iPX2wgz5h95h9LOSM 2dByG279TeAErHADv5JJ/LM2H8SjXQEOAteFcrSOZkCwj1pHdzNSJPgGH+uIC0CKX+LU O9Ow== X-Gm-Message-State: AIVw113i8vvwAbUhTVzBa6TB0zdTQF91hLuyGFKYuuazfOGZOK3lspQ5 f5sHRnH6WROwCQfjiRiQlUYoJ26TIw== X-Received: by 10.98.9.19 with SMTP id e19mr37915607pfd.177.1499535584431; Sat, 08 Jul 2017 10:39:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Sat, 8 Jul 2017 10:39:43 -0700 (PDT) In-Reply-To: <9b3c3630-cba9-661b-a9de-a5a51e39ff8e@cs.tcd.ie> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> <98EB3DAA-DEC7-4D5A-96C4-872A345C7B34@vigilsec.com> <9b3c3630-cba9-661b-a9de-a5a51e39ff8e@cs.tcd.ie> From: Watson Ladd Date: Sat, 8 Jul 2017 10:39:43 -0700 Message-ID: To: Stephen Farrell Cc: Russ Housley , Christian Huitema , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 17:39:47 -0000 On Sat, Jul 8, 2017 at 10:17 AM, Stephen Farrell wrote: > > > On 08/07/17 18:05, Russ Housley wrote: >> In draft-green-tls-static-dh-in-tls13, there is not one. I have not >> thought about it in these terms. The server, if acting in bad faith, >> can always release the client's traffic. > Is it bad faith if the server is compelled to enable this > wiretap interface? For a wiretapper this is a great scheme, > as they only need to force it to be turned on and accept a > tiny bit of data and then they can pick up those packets > from anywhere without having to deal with problems at the > web server end. So no need to even re-imburse the web server > for the intercepted access anymore. The same applies to static RSA ciphersuites. I understand your desire to move on with TLS 1.3, but we did burn what seemed to be a somewhat important usecase to some people, and this draft demonstrates that TLS 1.3 can be deployed in datacenters without hurting that usecase. As much as I think enterprise networks are suffering from bad design decisions that solve problems with boxes and not endpoint changes, this is a problem people are claiming to face, and there are some security implications. Servers already use static DH, in some cases by accident. > > Honestly, doesn't that clearly mean a conflict with 2804? > And one that cannot afaics be avoided. Why did static RSA not imply that? > > S. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Jul 8 10:42:09 2017 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 81CB112ECC4 for ; Sat, 8 Jul 2017 10:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z9N-5mot7Vu for ; Sat, 8 Jul 2017 10:42:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6C112ECC1 for ; Sat, 8 Jul 2017 10:42:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F2232BE50; Sat, 8 Jul 2017 18:42:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fb_ACqOyZiD; Sat, 8 Jul 2017 18:42:03 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9337CBE49; Sat, 8 Jul 2017 18:42:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499535723; bh=RfTrcJfzl6GLb1qwPg+h3P2h5ezhGCh0egvKQRw4QlY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=v+MjY29mB+ibap6GVJ/G0UkRYAXCX4rcOakPNH64FSymdNV2z3czHcR4Q3qRu2rOX bT8oYLS+J0RWqdbpmqOj5MTtLS7ub/urQ6GmALcRcZ3sfNs6+PO85t0G5yom+04f6U gLAKBS8u6A0+i6y9npGX4gyaeh6ay5FFA3r+a4VM= To: Watson Ladd Cc: Russ Housley , Christian Huitema , IETF TLS References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> <98EB3DAA-DEC7-4D5A-96C4-872A345C7B34@vigilsec.com> <9b3c3630-cba9-661b-a9de-a5a51e39ff8e@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <17e81bc5-9df7-15c1-5e72-31ce19e01d53@cs.tcd.ie> Date: Sat, 8 Jul 2017 18:42:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QDPp3Dd3ODS2OQTvK1QwFjRa1GWpmjXBW" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 17:42:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QDPp3Dd3ODS2OQTvK1QwFjRa1GWpmjXBW Content-Type: multipart/mixed; boundary="TR8k5pxeV2TJF7OX60JnavftPaIQpJtkt"; protected-headers="v1" From: Stephen Farrell To: Watson Ladd Cc: Russ Housley , Christian Huitema , IETF TLS Message-ID: <17e81bc5-9df7-15c1-5e72-31ce19e01d53@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> <98EB3DAA-DEC7-4D5A-96C4-872A345C7B34@vigilsec.com> <9b3c3630-cba9-661b-a9de-a5a51e39ff8e@cs.tcd.ie> In-Reply-To: --TR8k5pxeV2TJF7OX60JnavftPaIQpJtkt Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/07/17 18:39, Watson Ladd wrote: > Why did static RSA not imply that? We never defined a standards track API for handing over the RSA private key. This draft proposes to do exactly the equivalent, hence the conflict with 2804. S. --TR8k5pxeV2TJF7OX60JnavftPaIQpJtkt-- --QDPp3Dd3ODS2OQTvK1QwFjRa1GWpmjXBW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYRlqAAoJEC88hzaAX42iOOUH/0fomJ7Zhkq7JmqbSWWjqM8Y PBYMpelNhEZyXdQ4GoWmsvsgZoLpCMeqSFvoN+pYPqmAaU6A15xboqy2gHj1zWoG ksdVrPTIlQp1MZBLmpKtkMOqEnxZ+m09sfEfI+mONMNRzlml8nns+nkCj3QkLAco 3I3yU/kLUgz3tOJ0trfvPQ0oiXkdkNz+NHwzQqPp5+OHTRiPyCi7+E6V5I1tDwV/ WtghMTfk+DKZ+vUED0pQ7crTka8IybROIijc5CyWSiHCLU06Jl8D6ssloQVTIy4+ H1cs6Mj7uegIU7RzhCtBDkTxb3D8WHD3tuoePwgwOz3TVXvmf5n28IAEkIYwR3U= =7DsJ -----END PGP SIGNATURE----- --QDPp3Dd3ODS2OQTvK1QwFjRa1GWpmjXBW-- From nobody Sat Jul 8 14:16:16 2017 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 90DB5126C3D for ; Sat, 8 Jul 2017 14:16:13 -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 RpHZDEkTdi80 for ; Sat, 8 Jul 2017 14:16:12 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE91124217 for ; Sat, 8 Jul 2017 14:16:11 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id p188so50744369oia.0 for ; Sat, 08 Jul 2017 14:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OJDFUxMKj0rDFg5pPPFGxxUl6AA/d+sRffCx6xAsopY=; b=Jnxbu6erICeAi9HtGnamr0Up/a6NAYu+vteRMDrMPvavPsLlPnqoyY6cvmZhSdAV0M h0T7mYR19vSaOyb0liqoASsbQIKP4PTVOPRE5TnTXVQGlZDDUclTlwrm4NsR6tNdT37S x5CRAGHydBdI3p2qG5pIoK6LQjrrhm5yeFwCtZqcuNyMVBrIT/13VOZ9djX9q1HfQO3M W6IO+JQ7oykaWwQeXjAWh7oOqcuzoey2CGdOC5hoDMODJn7pbMpQW+nuYmwjcxOOHbY6 BnVivOLi/Vcv+6xoynP9NlufsgEDZizhzpuLKkaDkpm0zNOsCK919rly6yIJaDmK4REP 2vPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OJDFUxMKj0rDFg5pPPFGxxUl6AA/d+sRffCx6xAsopY=; b=qn2CuE/boRTfWzc3RIgqsHH4FCyndpRwUqRXnxkgDFsp6E4BzkYT1ThdjnSmyOXJLX etnwH/tNsl4YJ6xdmNjxzA//t8oU6CsvC0Wavq9P4JZzD5np9eoR4ZZLgzqnv15/ajaD QEtSiiRTT4APwN9RSRIxVjCXcOuIDJBBxUmBFJGDWDNpgCeAuNP9sSQnv+1cvhWYmeDH iAVBaCY9nLPUg9MtOnxZmehEKz6BnaygfcUGqSI7A5UtxlHndqxHa1f3+T2fMNXJzQMB LFDiM5uuTknXMpBVTNE3seZr0CMymJKnxN1t7fHsuENvHbCY27iT15frKs3+WXi4Xty2 TFgw== X-Gm-Message-State: AIVw110/gG/5c24/qECsUN9gA4zZqD2Ab7GuWYuzXcXgTJ0Lw88qPIHC jP1AHZDJsikvhPmUwR5MdQSwWOmXzA== X-Received: by 10.202.213.2 with SMTP id m2mr4828442oig.17.1499548571161; Sat, 08 Jul 2017 14:16:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Sat, 08 Jul 2017 21:16:00 +0000 Message-ID: To: Matthew Green , tls@ietf.org Content-Type: multipart/alternative; boundary="001a113de526e85a140553d4dbc2" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 21:16:13 -0000 --001a113de526e85a140553d4dbc2 Content-Type: text/plain; charset="UTF-8" Putting questions of whether or not this belongs as a working group document, I think there are some necessary requirements for intra-datacenter passive decryption schemes that are not met by this draft. Specifically, any passive decryption scheme should the following two properties: 1) Both server and client must explicitly opt-in 2) A third party should be able to tell whether or not this feature is enabled by observing the stream These two requirements protect services on the wider Internet from being accidentally (or surreptitiously forced to be) subject to unauthorized decryption. The static DH proposal satisfies neither of the above requirements. What you likely want is something similar to TLS 1.2 session tickets with centrally managed session ticket keys. The client would advertise support for "passive session decryption" in an extension and the server would return an unencrypted extension containing the session keys encrypted by a server "passive decryption key". The passive decryption key would be managed in the same way as the static DH key in this draft: rotated frequently and synchronized centrally. A TLS 1.2 session ticket-like scheme provides the same semantics as this static DH but provides more safeguards against accidental use outside the datacenter. Both client and server need to opt in, it's visible from the network, and limits the data visible to the inspection service to the session (rather than exposing the master secret which can be used to compute exporters and other things outside of the scope of session inspection). Furthermore, in the session ticket-like scheme, a *public key *could be used to encrypt the session keys, removing the need for a secure distribution scheme for the endpoints. The passive decryption private key could me managed in a secure location and only the public key distributed to the endpoints. Session ticket-like scheme advantages vs this static DH proposal: 1) Mandatory client opt-in 2) Passive indication that scheme is being used 3) Decryption service only gets session keys, not master secret 4) No need for private distribution system for static keys to endpoints In summary, even if this was to be considered as a working group document, I think this is the wrong solution to problem. Nick On Fri, Jul 7, 2017 at 8:03 AM Matthew Green wrote: > The need for enterprise datacenters to access TLS 1.3 plaintext for > security and operational requirements has been under discussion since > shortly before the Seoul IETF meeting. This draft provides current thinking > about the way to facilitate plain text access based on the use of static > (EC)DH keys on the servers. These keys have a lifetime; they get replaced > on a regular schedule. A key manager in the datacenter generates and > distributes these keys. The Asymmetric Key Package [RFC5958] format is > used to transfer and load the keys wherever they are authorized for use. > > We have asked for a few minutes to talk about this draft in the TLS WG > session at the upcoming Prague IETF. Please take a look so we can have a > productive discussion. Of course, we're eager to start that discussion on > the mail list in advance of the meeting. > > The draft can be found here: > > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 > > Thanks for your attention, > Matt, Ralph, Paul, Steve, and Russ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113de526e85a140553d4dbc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Putting questions of whether or not this be= longs as a working group document, I think there are some necessary require= ments for intra-datacenter passive decryption schemes that are not met by t= his draft.

Specifically, any passive decryption scheme sh= ould the following two properties:
1) Both server and client must = explicitly opt-in
2) A third party should be able to tell whether = or not this feature is enabled by observing the stream

Th= ese two requirements protect services on the wider Internet from being acci= dentally (or surreptitiously forced to be) subject to unauthorized decrypti= on. The static DH proposal satisfies neither of the above requirements.
=
What you likely want is someth= ing similar to TLS 1.2 session tickets with centrally managed session ticke= t keys. The client would advertise support for "passive session decryp= tion" in an extension and the server would return an unencrypted exten= sion containing the session keys encrypted by a server "passive decryp= tion key". The passive decryption key would be managed in the same way= as the static DH key in this draft: rotated frequently and synchronized ce= ntrally.

A TLS 1.2 session ticket-like scheme provides the same sema= ntics as this static DH but provides more safeguards against accidental use= outside the datacenter. Both client and server need to opt in, it's vi= sible from the network, and limits the data visible to the inspection servi= ce to the session (rather than exposing the master secret which can be used= to compute exporters and other things outside of the scope of session insp= ection). Furthermore, in the session ticket-like scheme, a public key= could be used to encrypt the session keys, removing the need for a= secure distribution scheme for the endpoints. The passive decryption priva= te key could me managed in a secure location and only the public key distri= buted to the endpoints.

Session ticket-like scheme advant= ages vs this static DH proposal:
1) Mandatory client opt-in
2) Passive indication that scheme is being used
= 3) Decryption service only gets session keys, not master secret
4) No need for private distribution system for static keys to endpoints<= br>

In summary, even if this was to be considered = as a working group document, I think this is the wrong solution to problem.=

Nick

On Fri, Jul 7, 2017 at 8:03 AM Matthew Green <matthewdgreen@gmail.com> wrote:
The need for enterprise datacenters to access TLS 1.3 plaintext for s= ecurity and operational requirements has been under discussion since shortl= y before the Seoul IETF meeting. This draft provides current thinking about= the way to facilitate plain text access based on the use of static (EC)DH = keys on the servers. These keys have a lifetime; they get replaced on a reg= ular schedule. A key manager in the datacenter generates and distributes th= ese keys.=C2=A0 The Asymmetric Key Package [RFC5958] format is used to tran= sfer and load the keys wherever they are authorized for use.

We have asked for= a few minutes to talk about this draft in the TLS WG session at the upcomi= ng Prague IETF. Please take a look so we can have a productive discussion.= =C2=A0 Of course, we're eager to start that discussion on the mail list= in advance of the meeting.

The draft can be found here:
https://tools.ietf.org/html/draft-green-tls-static-dh-in-t= ls13-01

Thanks for your attention,
Matt, Ral= ph, Paul, Steve, and Russ
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113de526e85a140553d4dbc2-- From nobody Sat Jul 8 15:08:13 2017 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 DC907126E64 for ; Sat, 8 Jul 2017 15:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, RP_MATCHES_RCVD=-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=eff.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 vWd6UC9Z4TRz for ; Sat, 8 Jul 2017 15:08:10 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340D6126C3D for ; Sat, 8 Jul 2017 15:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:To:From:References:Subject; bh=6LPHU5MUQARf2oXu/BQtzagdNeBe7dEEFXsazeH9b14=; b=IV2OMiNYj5GY5Aj5kMevgsOfRFZk2D7AzFPKnycFq5fDBO0Wa5tUGarMHiFwGvLzx+ggZOKHurrSEKERktwE9ypaaP5lxAjCLgnXQ7esLmvOHi9TcitumasYo5ONCZnVu8A6iMPhEidZ2g76FrGJffmB1ue7JLXXLm4uceP+SfI=; Received: ; Sat, 08 Jul 2017 15:08:08 -0700 References: From: Jacob Hoffman-Andrews To: Matthew Green , tls@ietf.org Message-ID: Date: Sat, 8 Jul 2017 15:08:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 22:08:12 -0000 With all respect to the authors for a well-written paper, this draft should not be adopted by TLS WG, because it would weaken the security of TLS as deployed in practice. If the TLS WG were to adopt this draft, one of the likely outcomes would be implementation in a variety of popular TLS libraries, like OpenSSL and SChannel. Unfortunately, including interception capability in off-the-shelf software is like keeping your plutonium next to your potato chips; something is bound to go wrong. For instance, performance advocates may suggest turning on the interception capability in order to save cycles. If such advice is broadly adopted, we will effectively have reintroduced non-forward secret sessions to TLS. In TLS 1.3 there are no NULL cipher suites. Why should there be a commonly implemented mode that breaks forward secrecy? The "Weaknesses of Alternative Solutions" section nicely sums up the tradeoffs of various techniques. Under "Export of ephemeral keys," it say= s: > The complexity of the solution is a problem that adds risk. This is absolutely true, but doesn't mention the bearer. The enterprise that requires the interception bears the risk (or, more likely, the vendors who sell interception software). I think when balancing the monetary risk to the enterprise against the privacy risk to billions of consumer Internet users, the consumers should win. I would also point out that retrospectively decrypting pcaps asks TLS to do double duty: as at-rest encryption in addition to transit encryption. If, instead, each TLS server shares a copy of its plaintext via a TLS connection to an encrypted storage service, the enterprise gets much better security properties. Not only does it retain forward secrecy for in-datacenter traffic, it can control the keys for at-rest data much more tightly. Instead of every TLS frontend having the keys for retrospective decryption, those keys can be limited to auditors or security team members. From nobody Sat Jul 8 15:11:48 2017 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 72618126E64 for ; Sat, 8 Jul 2017 15:11:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 X5nNeXNQm7X7 for ; Sat, 8 Jul 2017 15:11:44 -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 48A15126DC2 for ; Sat, 8 Jul 2017 15:11:44 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id b40so49994747qtb.2 for ; Sat, 08 Jul 2017 15:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-transfer-encoding:message-id; bh=+CGb0T81EoZEy0ykvXPAhEygP/30uwuxpqaL0Hh8sSw=; b=KqHsCKvMTfmX7Xf0yw4nqeoCZqnL/AHAMV0gR4KeZuB8K+6LVP0eqdKwWnbio1lkp/ aa8PBviGDCYRSphbUJoGH+jwklZec7lkVkKrlhkRQpGuREISpQ4/nDrXcWdZ0tvseli2 oxTqmI5e41XEFfQKRBUmoH5DDNOpzyhh0KuILA71n6kSd/LMd/6mnCrR2G2gxX5Nyup4 +2k/2zTten9FRBwQ5QygM4l1/mt9AOnP3R3iQyxy/jWMaO3jB87nLEQx20cc+12wcnGJ m6xcVRuc0QR7oLk20k2+L4OFrm90hO9ZjtZ8meVFOdgbxd1c6pzUTmIDRa9BPM1kvtiw +omA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=+CGb0T81EoZEy0ykvXPAhEygP/30uwuxpqaL0Hh8sSw=; b=RD7YEzRKkcg8aG5nvvFwnrKRMDgG8dnKYouRMeQCM3iLxP56UQHyBP+8S3Zu9tflyF 00lxotbMzmsL/iUnGzEzHiSMIgzMK9+gYt+gIgfC3JcdFV6aHBmrQZjN3t5YksNWiE3E WWerAk7n46WcL9fFwilKXtgYy4OkZcj1/DhuqmaaVpbSFWoiLrobcGC7oWNlzpDNSKqx q19gqq7MGYaKTqHlPNMYDKMN7q4ek9RtAVYhy4xZIFTYqP/vHMtn/MZkiic3NwJK41+v 1QXB0xFlYB6XjiUgNoJoMTjFAJJQKiXVWVvvWKUXqtoSnbQWXwGItx/0W400nrDaMVDW 6xbw== X-Gm-Message-State: AIVw113rdpmvsdFZdtX1v4/LttmTeB/lzvR+tKBxVQphk5TRy+QXsVkv kU3p/xYic+Mms1V4 X-Received: by 10.237.48.174 with SMTP id 43mr44492015qtf.201.1499551903314; Sat, 08 Jul 2017 15:11:43 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id q40sm5882831qtf.42.2017.07.08.15.11.42 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 08 Jul 2017 15:11:42 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Matthew Green Date: Sat, 8 Jul 2017 18:11: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="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <201707081811.41908.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 22:11:46 -0000 On Friday, July 07, 2017 03:02:43 am Matthew Green wrote: > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 This document uses the terms: "Ephemeral (EC)DHE" & "Static (EC)DHE" The 'E' stands for ephemeral. Regardless of the technical, security, political, logistical, ethical, and whatever merits of this document, could you please make the terminology not hurt my brain? The former is the standard ATM machine silliness, and the later is contradictory and only vaguely viable by fiat of explicitly writing out the silliness: https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01#section-1.1 > This document introduces the term "static (elliptic curve) Diffie- > Hellman ephemeral", generally written as "static (EC)DHE", to refer > to long-lived finite field or elliptic curve Diffie-Hellman keys or > key pairs that will be used with the TLS 1.3 ephemeral ciphersuites > to negotiate traffic keys for multiple TLS sessions. > > For clarity, this document also introduces the term "ephemeral > (elliptic curve) Diffie-Hellman ephemeral", generally written as > "ephemeral (EC)DHE", to denote finite field or elliptic curve Diffie- > Hellman keys or key pairs that will be used with the TLS 1.3 > ephemeral ciphersuites to negotiate traffic keys for a single TLS > sessions. It should be simply: "Ephemeral (EC)DH" & "Static (EC)DH" Or just: "(EC)DHE" & "Static (EC)DH" (or even "(EC)DHS" if you want to use a similar scheme for both) My argument is that you've got to be able to come up with better terminology than "ephemeral (elliptic curve) Diffie-Hellman ephemeral". Using the same word twice in the same term with slightly different implications is... messy and confusing. Dave PS Response on the merits of the spec to follow in another post. From nobody Sat Jul 8 15:14:51 2017 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 2A0D0129AAA for ; Sat, 8 Jul 2017 15:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 S_bbg07qpAGf for ; Sat, 8 Jul 2017 15:14:48 -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 AF90C126E64 for ; Sat, 8 Jul 2017 15:14:48 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id r126so32666864vkg.0 for ; Sat, 08 Jul 2017 15:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4HYJpwia55WFLHfs4tsSpvjPxAAZ1Elu4zHSLCRj3/w=; b=VA6wTnc73lG/ouxMFdS+p/ojcMqVBpTj1Lf8Y2ncEHir2zGJkWqP3+UtYjvPSQTLuD m9w8JGsTSSHSZ8rnBBdDA/EofbglhIV066W7ik3tv79CwTNO9N1Sk1L+5XIuafISPgiR UGe5engXlRxdLylZ8Oq7750i7LXjx8wawz60EED3XSwzjqupUWQoEZhcHMRJ//W4OCIi EBVzY07vzAPuSRPJqYTqgnPM6wWRUwSNVHGLNI9Rn4f8UDUiOzRwMQiV+wIYmvHUWP1+ eiD+/xKvWNQNnWay8gleq1GwdDEh3MrVXZcwcNA8HQoxYtrJHNQpDEm4KdpNeqsXpwyD JUYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4HYJpwia55WFLHfs4tsSpvjPxAAZ1Elu4zHSLCRj3/w=; b=KZREX6yna80FPSheToPCoDsnKeb5DxZw6PPbyPf4edN1eMqGFhYoUpnBl+5TdqQ8Mu T/G+cIxBdnDFW4GojnMPoC/MY5wEEJriYkTrp8ZA3/9fci1IXxay0zo4rnQi42O9uU05 jHBh92Bkl7yVe8o1yiFFX9c2psrEiz3HNAwfO1Gknmd8GdQZQFvqV9GceT8JoT58xvC5 ZjK4oib+3+9OaUhTQDvj1JiuAd/BzwOPHw8F+ZE+gMf8J33obqV1tKQBuMaxEP7ihi+q C/d5hCXkBJOJSMl5KQ0jPJM/wvkJQvMiRtzgij7ptk5VGWPguKr8kJ3mY3qD4ys0GL+f hdHQ== X-Gm-Message-State: AIVw113Y5+5Y5Gm/ab4dsWnW1Wp3gn44WX/QijRDQxEDEQitXDLMFbjG JHYxGk0eWZIVro/l2CsfNcZdSKgoHw== X-Received: by 10.31.233.3 with SMTP id g3mr4080593vkh.91.1499552087793; Sat, 08 Jul 2017 15:14:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.79.231 with HTTP; Sat, 8 Jul 2017 15:14:46 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Sat, 8 Jul 2017 18:14:46 -0400 Message-ID: To: Nick Sullivan Cc: Matthew Green , TLS WG Content-Type: multipart/alternative; boundary="94eb2c0949e883e8850553d5ad60" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 22:14:50 -0000 --94eb2c0949e883e8850553d5ad60 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 5:16 PM, Nick Sullivan wrote: > Putting questions of whether or not this belongs as a working group > document, I think there are some necessary requirements for > intra-datacenter passive decryption schemes that are not met by this draft. > > Specifically, any passive decryption scheme should the following two > properties: > 1) Both server and client must explicitly opt-in > 2) A third party should be able to tell whether or not this feature is > enabled by observing the stream > > These two requirements protect services on the wider Internet from being > accidentally (or surreptitiously forced to be) subject to unauthorized > decryption. > I absolutely agree. What you likely want is something similar to TLS 1.2 session tickets with > centrally managed session ticket keys. The client would advertise support > for "passive session decryption" in an extension and the server would > return an unencrypted extension containing the session keys encrypted by a > server "passive decryption key". The passive decryption key would be > managed in the same way as the static DH key in this draft: rotated > frequently and synchronized centrally. > This is the best proposal I've seen so far. What is the problem of publishing a scheme like this as an Informational RFC? After all, we can cite many examples of protocols described in Informational RFCs that are widely deployed by industry. If the proponents of this draft think it critical that this needs formal IETF endorsement as a standard, then I believe they ought to be also working on persuading the IETF to withdraw or at least backtrack on some of our previous statements (such as RFC 7258, which declared that IETF protocols need to have technical countermeasures to prevent pervasive monitoring). I doubt that we will be able to get consensus on IETF endorsement. Speaking only for myself, I am against the IETF/TLS wg endorsing a protocol that degrades the security of the TLS protocol. But I am perfectly fine with publishing it as Informational document. -- Shumon Huque --94eb2c0949e883e8850553d5ad60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 8, 2017 at 5:16 PM, Nick Sullivan <nicholas.sullivan@gma= il.com> wrote:
Putting questions of whether or not this belongs as a w= orking group document, I think there are some necessary requirements for in= tra-datacenter passive decryption schemes that are not met by this draft.
Specifically, any passive decryption scheme should the fol= lowing two properties:
1) Both server and client must explicitly o= pt-in
2) A third party should be able to tell whether or not this = feature is enabled by observing the stream

These two requ= irements protect services on the wider Internet from being accidentally (or= surreptitiously forced to be) subject to unauthorized decryption.

I absolutely agree.

<= /div>
What you likely want is something similar to TLS 1.2 session t= ickets with centrally managed session ticket keys. The client would adverti= se support for "passive session decryption" in an extension and t= he server would return an unencrypted extension containing the session keys= encrypted by a server "passive decryption key". The passive decr= yption key would be managed in the same way as the static DH key in this dr= aft: rotated frequently and synchronized centrally.

This is the be= st proposal I've seen so far.

What is the prob= lem of publishing a scheme like this as an Informational RFC? After all, we= can cite many examples of protocols described in Informational RFCs that a= re widely deployed by industry. If the proponents of this draft think it cr= itical that this needs formal IETF endorsement as a standard, then I believ= e they ought to be also working on persuading the IETF to withdraw or at le= ast backtrack on some of our previous statements (such as RFC 7258, which d= eclared that IETF protocols need to have technical countermeasures to preve= nt pervasive monitoring).

I doubt that we will be = able to get consensus on IETF endorsement. Speaking only for myself, I am a= gainst the IETF/TLS wg endorsing a protocol that degrades the security of t= he TLS protocol. But I am perfectly fine with publishing it as Informationa= l document.

--=C2=A0
Shumon Huque
<= div>
--94eb2c0949e883e8850553d5ad60-- From nobody Sat Jul 8 15:16:56 2017 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 53AF212EB01 for ; Sat, 8 Jul 2017 15:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yPP3GqbjHvu3 for ; Sat, 8 Jul 2017 15:16:53 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 8F772129AAA for ; Sat, 8 Jul 2017 15:16:53 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id b40so50029970qtb.2 for ; Sat, 08 Jul 2017 15:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=8LuM3W35y8olrmG9HvA/xmftJP6qaPy+Q6Oc4vdcKaI=; b=NN5D4V8lHPCuXJMfw7UMUXyBYK4PkBV5N+RSg5k96XyxoQa6ZTbwI2QrBESCv0d2O+ znaJ71h56M+om5lk3kwU8Lp3eNnh07j2zaqAqGXBNAFzvF230pPHcTKjTBM3iH4SwbFP Z7mNmrcpfBPIVP1zDH8iSxvk/z7QpAzb2l5SReTJyOqITrI0hBXL1rqlXT52N1NQfYUl xjwZfJV+/HF0NT0djfqpVYR0mTi9U3/zZHG7mDPso4ZiXjK+q2qghh0lqHgnuUyNpptr /r5p9qaYSiPWEOi+1mdUGh9afVJowsli1YauCgLaoDFzHIRRic8IYxhxp3PCPKPy2jnb f+AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=8LuM3W35y8olrmG9HvA/xmftJP6qaPy+Q6Oc4vdcKaI=; b=QZZgtV3s11xmw6MKYi4K43b8x616KDDcqrUveSQlD6A/kHrmM6ZySqP02UkxJM+mQH KX2y/GHOCA0PbZH0rAGaQD4tjJ5wRJQghBNVMSFxb2rMPYAOin/9/v0IRR1HrS9waUCa 9WhvNXrGNwFbcTLfFlavCnZsErkCT9JdZ93N+mdCBAFa8N0x3NFGfljWQZisERBHjzXP MT4lvftpDgdG7DGA4mDya0kfb1WL4fIhTsRaCfaXIPhJo/xDov7ecFihPXXLgTC5kPaR UCia9X8WGtwSKo0cvwHwYHsIyag7/pFvLlN4NgdKJSBcofAXnbCgSPZtQMFZrhWOxj71 rESg== X-Gm-Message-State: AIVw113mzUPXjnNXV1mOAfor7lOhe6BQFFrCnMWFRYuYQK3tDCHhbEUP TiKGBbrpbMWBkqdrg8k= X-Received: by 10.200.59.74 with SMTP id r10mr32502091qtf.162.1499552212526; Sat, 08 Jul 2017 15:16:52 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id v63sm5366425qkv.46.2017.07.08.15.16.51 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 08 Jul 2017 15:16:52 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 8 Jul 2017 18:16:50 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <1ab70d05-235e-5a4f-a44b-8b4eadd9ddd8@cs.tcd.ie> In-Reply-To: <1ab70d05-235e-5a4f-a44b-8b4eadd9ddd8@cs.tcd.ie> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201707081816.51077.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 22:16:55 -0000 This thread blew up rather quickly. Replying on a topic with quotes from va= rious posts, below: On Saturday, July 08, 2017 05:09:12 am Stephen Farrell wrote: > On 08/07/17 03:06, Ackermann, Michael wrote: > > Converting all session traffic to clear text is not a viable > > alternative for ANY enterprises or industries that I am aware of. Could we please drop the plaintext straw man here? The alternative is build= ing a system that doesn't rely on outdated methods, rather than shoe-hornin= g them into TLS 1.3, not ditching encryption. > > In > > particular those in financial sectors. Security policies, legislation > > and in many cases just good practice would not allow for this. We are > > compelled by these factors to encrypt all data in motion. But we > > still need to manage our applications, networks, servers and clients. > > Hence the need to decrypt traffic as outlined in this draft. >=20 > That assertion of necessity is blatantly false. >=20 > It is entirely feasible to decrypt and re-encrypt in many > cases and for that to be efficient and to meet regulatory > needs. >=20 > If some systems are so badly designed that doing that while > updating to tls1.3 is a showstopper then that's down to bad > design or other bad practices. Fixing those is the place to > spend effort instead of spending effort on breaking TLS. >=20 > Other users of TLS ought not suffer on the basis of such > bad reasoning. +1 It is not the job of the TLS WG to make handling internal requirements of o= rganizations easier with their existing systems in spite of the obvious ris= ks that can be avoided. A drop-in replacement for a theoretically legitimate usecase is also a drop= =2Din replacement for very much illegitimate usecases. Making this a standa= rd is not the way to go here. An argument could be made for informational R= =46C status rather than standards track, but even then, it's dangerous. On Saturday, July 08, 2017 01:39:43 pm Watson Ladd wrote: > On Sat, Jul 8, 2017 at 10:17 AM, Stephen Farrell > wrote: > > Is it bad faith if the server is compelled to enable this > > wiretap interface? For a wiretapper this is a great scheme, > > as they only need to force it to be turned on and accept a > > tiny bit of data and then they can pick up those packets > > from anywhere without having to deal with problems at the > > web server end. So no need to even re-imburse the web server > > for the intercepted access anymore. >=20 > The same applies to static RSA ciphersuites. I understand your desire > to move on with TLS 1.3, but we did burn what seemed to be a somewhat > important usecase to some people, and this draft demonstrates that TLS > 1.3 can be deployed in datacenters without hurting that usecase. As > much as I think enterprise networks are suffering from bad design > decisions that solve problems with boxes and not endpoint changes, > this is a problem people are claiming to face, and there are some > security implications. The organizations that took the easy way at the time now are being told to = take a harder way that is more secure. (and are consistently posting to thi= s list with amnesia, acting like we told them to use plaintext) They don't = like that; we shouldn't care. We should consider standardizing better solut= ions for this problem, without regard to how much old systems will have to = adapt their design. This has come up on this list MANY times, and each time= the end result of discussion was to not revert security decisions made to = improve TLS. Releasing a standards track (or even informational) RFC on how= to do exactly that using all the old methods, with some tweaks, defeats th= e purpose of making those security decisions. I'm getting a bit of d=E9j=E0 vu from this thread, and think the same answe= r should come as from previous threads on the topic: no, please come up wit= h something new. I don't see the proposed document being anywhere close to = getting consensus for adoption by the TLS WG. For the stubborn, an (indepen= dent) informational RFC would get far less (but nontrivial) opposition. Dave PS Please avoid the "but they'll do whatever they want anyway" comebacks. If t= he response to not accommodating static keys anymore is to stay with TLS 1.= 2 forever, then at least they'll be open in their desire to avoid change at= all costs. We should not treat this like a hostage scenario. From nobody Sat Jul 8 15:21:22 2017 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 6F7C812EB01 for ; Sat, 8 Jul 2017 15:21:19 -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=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 53gIOdAd56UX for ; Sat, 8 Jul 2017 15:21:17 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 11E0312EB8E for ; Sat, 8 Jul 2017 15:21:16 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v68MHLnJ012891; Sat, 8 Jul 2017 23:21:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=y2JkOpQ+bIG8phVreELSpKUgxcBEdDcGruZbZ0EcfJA=; b=Xr9mFC5NX6c4WnaZdZU4UDsqs9Vkse/qA6rUviQjCvf2/81+/o0wdH0nLjYtyaE1yDqi ZSuf2jK/ooWcJEqlDL+tFJ/51koxnGU9/1qxEomEqHXTIymPvQinwMioh3klExUb1uqv i3WbTQ9M9Cn0hKzNqUhG6q+gKNrQ+hI/IQZuuoqtP5dpI5iy+5D0K8Gn1kvTy3NJx/I+ /ZpfZdyXWogPiS5pHO1rl1bGu2R9EDReCdZLFHFSrvhLzLBkyQJc8q8CYfB1RWJjNplv kaWx8RFqIsSR/2MpgoIm/zkD+VbgiQsAXINhD0SIv64Qx7a/GBbUHDXSfPZ6/Rivu2hO OA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bju4bt064-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 08 Jul 2017 23:21:13 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v68MKlgW019485; Sat, 8 Jul 2017 18:21:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bjtqu138r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 08 Jul 2017 18:21:12 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 8 Jul 2017 18:21:11 -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.1263.000; Sat, 8 Jul 2017 18:21:11 -0400 From: "Salz, Rich" To: Nick Sullivan , Matthew Green , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sA///O2BA= Date: Sat, 8 Jul 2017 22:21:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707080400 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707080399 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 22:21:19 -0000 PiAxKSBCb3RoIHNlcnZlciBhbmQgY2xpZW50IG11c3QgZXhwbGljaXRseSBvcHQtaW4NCg0KV2h5 IGNhbid0IGl0IGJlIGltcGxpY2l0IHN1Y2ggYXMgd2hlbiB5b3UgY2xpY2stdGhyb3VnaCBvbiB0 aGUgd2Vic2l0ZSdzIHRlcm1zIG9mIHNlcnZpY2U/DQoNCj4gMikgQSB0aGlyZCBwYXJ0eSBzaG91 bGQgYmUgYWJsZSB0byB0ZWxsIHdoZXRoZXIgb3Igbm90IHRoaXMgZmVhdHVyZSBpcyBlbmFibGVk IGJ5IG9ic2VydmluZyB0aGUgc3RyZWFtDQoNCldoeT8gIEJlY2F1c2Ugd2Ugd2FudCB0byB3YXRj aCB3aG8ncyBkb2luZyBpdD8gIERvIHdlIHdhdGNoIHdobyBpcyBsZWFraW5nIHBsYWludGV4dD8N Cg== From nobody Sat Jul 8 15:53:30 2017 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 9DF6D12F28B for ; Sat, 8 Jul 2017 15:53:28 -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, HTML_MESSAGE=0.001, 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=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHEm0k5-gQS7 for ; Sat, 8 Jul 2017 15:53:25 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (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 5D96A12EB8E for ; Sat, 8 Jul 2017 15:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1499554402; l=12022; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=2cD3Ja28nYbgwhlFbK2m0wrC5bhOP03Y1VY/kGqHIO4=; b=NLaZBtamK5ghyoiugZ2cakPmLqNiUV04/iSjmNc8LSfRXrgJS+TRwp02RPF54j8a+Y OYLhJTWie2ogRTk+aMs2AE3KmJWJCS3SOYhU3iWenC9+tvsD3NjnfkCPZVD0KdrftN1k hs0qdYTGSjAVHplMsAvDofaIxpYAwf9BmctdQ= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JVmITQqKA== X-RZG-CLASS-ID: mo00 Received: from [10.10.10.91] (p5DCF4224.dip0.t-ipconnect.de [93.207.66.36]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id R0566ct68MrMfuK (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sun, 9 Jul 2017 00:53:22 +0200 (CEST) To: tls@ietf.org References: From: Roland Zink Message-ID: <27e3a03a-f8bf-2eae-775c-33d29b77a2f7@zinks.de> Date: Sun, 9 Jul 2017 00:53:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------615BE5578BCBAF02FC7FE3D6" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2017 22:53:29 -0000 This is a multi-part message in MIME format. --------------615BE5578BCBAF02FC7FE3D6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Nice requirements. Will those be applied to all protocols around TLS? For example HTML/HTTP/QUIC tend to send data to third parties through additional connections and the HTTP referer header tells all those 3rd parties the URL used. This is a breach of the users privacy. For surveillance no wiretapping is necessary. A secret service just needs to infiltrate a few big companies and will get a pretty good overview who browse what. The user didn't explicitly opt-in into this although you may argue the client software (browser) does. A third party can't tell if this feature is enabled or not by observing the stream. So should the usage of HTTP/HTTP2/QUIC over (D)TLS in the current form be forbidden? The referer header not allowed when TLS is used? As a server (and client) can always silently forward the unencrypted data neither 1) nor 2) can be enforced so I guess those are only should requirements. Roland Am 08.07.2017 um 23:16 schrieb Nick Sullivan: > Putting questions of whether or not this belongs as a working group > document, I think there are some necessary requirements for > intra-datacenter passive decryption schemes that are not met by this > draft. > > Specifically, any passive decryption scheme should the following two > properties: > 1) Both server and client must explicitly opt-in > 2) A third party should be able to tell whether or not this feature is > enabled by observing the stream > > These two requirements protect services on the wider Internet from > being accidentally (or surreptitiously forced to be) subject to > unauthorized decryption. The static DH proposal satisfies neither of > the above requirements. > > What you likely want is something similar to TLS 1.2 session tickets > with centrally managed session ticket keys. The client would advertise > support for "passive session decryption" in an extension and the > server would return an unencrypted extension containing the session > keys encrypted by a server "passive decryption key". The passive > decryption key would be managed in the same way as the static DH key > in this draft: rotated frequently and synchronized centrally. > > A TLS 1.2 session ticket-like scheme provides the same semantics as > this static DH but provides more safeguards against accidental use > outside the datacenter. Both client and server need to opt in, it's > visible from the network, and limits the data visible to the > inspection service to the session (rather than exposing the master > secret which can be used to compute exporters and other things outside > of the scope of session inspection). Furthermore, in the session > ticket-like scheme, a */public key /*could be used to encrypt the > session keys, removing the need for a secure distribution scheme for > the endpoints. The passive decryption private key could me managed in > a secure location and only the public key distributed to the endpoints. > > Session ticket-like scheme advantages vs this static DH proposal: > 1) Mandatory client opt-in > 2) Passive indication that scheme is being used > 3) Decryption service only gets session keys, not master secret > 4) No need for private distribution system for static keys to endpoints > > In summary, even if this was to be considered as a working group > document, I think this is the wrong solution to problem. > > Nick > > On Fri, Jul 7, 2017 at 8:03 AM Matthew Green > wrote: > > The need for enterprise datacenters to access TLS 1.3 plaintext > for security and operational requirements has been under > discussion since shortly before the Seoul IETF meeting. This draft > provides current thinking about the way to facilitate plain text > access based on the use of static (EC)DH keys on the servers. > These keys have a lifetime; they get replaced on a regular > schedule. A key manager in the datacenter generates and > distributes these keys. The Asymmetric Key Package [RFC5958] > format is used to transfer and load the keys wherever they are > authorized for use. > > We have asked for a few minutes to talk about this draft in the > TLS WG session at the upcoming Prague IETF. Please take a look so > we can have a productive discussion. Of course, we're eager to > start that discussion on the mail list in advance of the meeting. > > The draft can be found here: > > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 > > Thanks for your attention, > Matt, Ralph, Paul, Steve, and Russ > _______________________________________________ > 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 --------------615BE5578BCBAF02FC7FE3D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Nice requirements. Will those be applied to all protocols around TLS? For example HTML/HTTP/QUIC tend to send data to third parties through additional connections and the HTTP referer header tells all those 3rd parties the URL used. This is a breach of the users privacy. For surveillance no wiretapping is necessary. A secret service just needs to infiltrate a few big companies and will get a pretty good overview who browse what. The user didn't explicitly opt-in into this although you may argue the client software (browser) does. A third party can't tell if this feature is enabled or not by observing the stream. So should the usage of HTTP/HTTP2/QUIC over (D)TLS in the current form be forbidden? The referer header not allowed when TLS is used?

As a server (and client) can always silently forward the unencrypted data neither 1) nor 2) can be enforced so I guess those are only should requirements.

Roland


Am 08.07.2017 um 23:16 schrieb Nick Sullivan:
Putting questions of whether or not this belongs as a working group document, I think there are some necessary requirements for intra-datacenter passive decryption schemes that are not met by this draft.

Specifically, any passive decryption scheme should the following two properties:
1) Both server and client must explicitly opt-in
2) A third party should be able to tell whether or not this feature is enabled by observing the stream

These two requirements protect services on the wider Internet from being accidentally (or surreptitiously forced to be) subject to unauthorized decryption. The static DH proposal satisfies neither of the above requirements.

What you likely want is something similar to TLS 1.2 session tickets with centrally managed session ticket keys. The client would advertise support for "passive session decryption" in an extension and the server would return an unencrypted extension containing the session keys encrypted by a server "passive decryption key". The passive decryption key would be managed in the same way as the static DH key in this draft: rotated frequently and synchronized centrally.

A TLS 1.2 session ticket-like scheme provides the same semantics as this static DH but provides more safeguards against accidental use outside the datacenter. Both client and server need to opt in, it's visible from the network, and limits the data visible to the inspection service to the session (rather than exposing the master secret which can be used to compute exporters and other things outside of the scope of session inspection). Furthermore, in the session ticket-like scheme, a public key could be used to encrypt the session keys, removing the need for a secure distribution scheme for the endpoints. The passive decryption private key could me managed in a secure location and only the public key distributed to the endpoints.

Session ticket-like scheme advantages vs this static DH proposal:
1) Mandatory client opt-in
2) Passive indication that scheme is being used
3) Decryption service only gets session keys, not master secret
4) No need for private distribution system for static keys to endpoints

In summary, even if this was to be considered as a working group document, I think this is the wrong solution to problem.

Nick

On Fri, Jul 7, 2017 at 8:03 AM Matthew Green <matthewdgreen@gmail.com> wrote:
The need for enterprise datacenters to access TLS 1.3 plaintext for security and operational requirements has been under discussion since shortly before the Seoul IETF meeting. This draft provides current thinking about the way to facilitate plain text access based on the use of static (EC)DH keys on the servers. These keys have a lifetime; they get replaced on a regular schedule. A key manager in the datacenter generates and distributes these keys.  The Asymmetric Key Package [RFC5958] format is used to transfer and load the keys wherever they are authorized for use.

We have asked for a few minutes to talk about this draft in the TLS WG session at the upcoming Prague IETF. Please take a look so we can have a productive discussion.  Of course, we're eager to start that discussion on the mail list in advance of the meeting.

The draft can be found here:

https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01

Thanks for your attention,
Matt, Ralph, Paul, Steve, and Russ
_______________________________________________
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

--------------615BE5578BCBAF02FC7FE3D6-- From nobody Sat Jul 8 18:05:26 2017 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 0243A12F28C for ; Sat, 8 Jul 2017 18:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=PtjBLGWz; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=ij0ThdI9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UfbhMuDocuJ for ; Sat, 8 Jul 2017 18:05:24 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CF212ECC4 for ; Sat, 8 Jul 2017 18:05:23 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 1B165A0801 for ; Sat, 8 Jul 2017 21:05:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=9VySzX6Rhr42sEtmV98ftNqmc+4=; b=PtjBLG Wz+LKAqOlNcKVz2dIb7k87E2lUmDLyuBtZ29Im14GlPdm6KxpDxRtnBdTEPZxVmK qrDMGQF9hwu3mwVyrqCZWq7WU+5CvP9/GXye1NbNAZc3do0O6Ajs7flExtcUWjGP rEMtu7vpKxneGp7MyJxfwEg8PBIjDQzWZrmYs= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 14154A0800 for ; Sat, 8 Jul 2017 21:05:20 -0400 (EDT) Received: from mail-yb0-f169.google.com (unknown [209.85.213.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 78C51A07FF for ; Sat, 8 Jul 2017 21:05:19 -0400 (EDT) Received: by mail-yb0-f169.google.com with SMTP id f194so19708127yba.3 for ; Sat, 08 Jul 2017 18:05:19 -0700 (PDT) X-Gm-Message-State: AIVw113nsb1bCQqppDjvjCz8wMK/37COOdlKE46SBQCaPi5Ui+medA80 Qg+glPyWcxWrafngZeIzwccs5W4yGg== X-Received: by 10.37.215.72 with SMTP id o69mr663499ybg.41.1499562318728; Sat, 08 Jul 2017 18:05:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.60.199 with HTTP; Sat, 8 Jul 2017 18:04:38 -0700 (PDT) In-Reply-To: <634dbf72eee14617a2359f2792d4aee0@venafi.com> References: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> <634dbf72eee14617a2359f2792d4aee0@venafi.com> From: Eric Mill Date: Sat, 8 Jul 2017 21:04:38 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Turner Cc: Stephen Farrell , Yaron Sheffer , tls chair , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114fd37c53a3080553d80ff7" X-Pobox-Relay-ID: AD3B5F1E-6442-11E7-A680-61520C78B957-82875391!pb-smtp2.pobox.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=konklone.com; h=mime-version:in-reply-to:references:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=9VySzX6Rhr42sEtmV98ftNqmc+4=; b=ij0ThdI9vKmPsFEskpd6Zxh1NvAUllI/QaV3WP+B2pwn9l3HRDK+skcO976yFL9QHQA2cvLHqL4Sr/+uCszS/s7efQqIVJ6Wll1wPxliTo6+FVGtGirpe1MruPmHgbcKu/TOm/qOnjr4agD7YsYwOFV14dNAx03idM8W2gzZ7XA= Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 01:05:26 -0000 --001a114fd37c53a3080553d80ff7 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 11:31 AM, Paul Turner wrote: > > The Internet Draft describes the use of static (EC)DHE for traffic > entirely inside enterprise networks and intends to clearly state that it > should not be used for "information passed across the Internet". If we have > not been clear enough on that in the document, please tell us how we can be > more clear. Assuming that the document is clear on this point, it would not > then apply to "wiretapping" as defined in RFC 2804 (as Russ mentioned in an > earlier email). > The IETF's position as expressed in 2804 is on technologies that "facilitate" wiretapping. What the RFC says the protocol is "intended for" in layer 8 isn't as relevant as how the technology could easily be used, once standardized. The burden on the proposers should be to demonstrate that the technology can *only* be used in the manner of its stated intent, even if the humans involved were all hostile, or compelled to be hostile. You have stated that there are alternatives by using proxies but enterprise > organizations have stated this is not viable due to the complexity and > scale of their network environments. Not all statements are created equal. Stating that proxies can technically fulfill this function is objective, and can be backed up in clear technical detail. Stating that proxies are not viable for enterprise organizations due to the scale and complexity of their network environments is subjective, generally not well-detailed, and much more open to skepticism. The burden on the proposers should be to address this skepticism, and to justify to the working group why enterprises that are large enough and well-funded enough to have such vast and complex networks cannot invest in upgrading those networks to an approach that doesn't rely on directly weakening their own connection security and potentially the security of others' through the unintended consequences of formalizing this RFC. > Our collective objective is to increase the security of the Internet at > large. As such, we have proposed this RFC in order to ensure that TLS 1.3 > is adopted as broadly as possible inside of enterprises, which is an > important step in increasing security. So is increasing the use of forward secret connections within enterprise network environments. Why should the TLS WG accept the argument that legacy approaches to monitoring enterprise networks are worth risking the weakening of the product of years of hard work? -- Eric -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Saturday, July 8, 2017 10:33 > To: Yaron Sheffer ; tls chair < > tls-chairs@tools.ietf.org> > Cc: tls@ietf.org > Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... > > > > On 08/07/17 15:27, Yaron Sheffer wrote: > > Hi Stephen, > > > > Like you, I am very unhappy with this draft, and would not support its > > adoption as a WG draft. However I think that open discussion is in > > general good, and that the best venue for discussion of this draft is > > this mailing list. Even if some of this discussion devolves into > > generic "are we pro or against wiretapping" questions. > > FWIW I believe that we have had that discussion about breaking tls over > and over on this and other lists. I see no value in doing it yet again, > even if the proximate cause is a new variation of the "here's a way to > break tls" class of drafts. (Someday we should find someone who'd document > all the broken break-tls ideas that have been rightly rejected over the > years.) > > > > > I don't think this is a significant distraction that could derail > > (D)TLS, moreover, you will recall that in Chicago several new drafts > > were adopted to the working group. So the WG does feel that TLS is in > > good enough shape that we can spend some bandwidth on other things. > > Maybe I'm more easily distracted, at least by this topic;-) > > Anyway, I'm fine that it's for the chairs to figure that out. > > S. > > > > Thanks, > > > > Yaron > > > > > > On 08/07/17 12:17, Stephen Farrell wrote: > >> Sean/Joe, > >> > >> This is a request that you, as chairs, shut down the distracting > >> wiretapping discussion, at least until DTLS1.3 is done. > >> > >> I have planned to spend time reading draft 21 and DTLS, but that > >> won't happen if we keep having to fight off the latest attempts to > >> break TLS. I'd not be surprised if I weren't the only one finding > >> that distraction an irritating waste of time. Finishing > >> TLS1.3 and getting DTLS1.3 on the way surely needs to not be > >> constantly de-railed by these attempts to break TLS. > >> > >> Therefore I'd ask that you declare this discussion closed for at > >> least that long (i.e until DTLS1.3 is done). > >> > >> I'd also ask that you not allocate agenda time for wiretapping in > >> Prague. > >> > >> Thanks, > >> S. > >> > >> > >> > >> _______________________________________________ > >> 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 > -- konklone.com | @konklone --001a114fd37c53a3080553d80ff7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 8, 2017 at 11:31 AM, Paul Turner <PAUL.TURNER@venafi.= com> wrote:
The Internet Draft describes the use of static (EC)DHE for traffic entirely= inside enterprise networks and intends to clearly state that it should not= be used for "information passed across the Internet". If we have= not been clear enough on that in the document, please tell us how we can b= e more clear. Assuming that the document is clear on this point, it would n= ot then apply to "wiretapping" as defined in RFC 2804 (as Russ me= ntioned in an earlier email).

The IETF&= #39;s position as expressed in 2804 is on technologies that "facilitat= e" wiretapping. What the RFC says the protocol is "intended for&q= uot; in layer 8 isn't as relevant as how the technology could easily be= used, once standardized.

The burden on the propos= ers should be to demonstrate that the technology can *only* be used in the = manner of its stated intent, even if the humans involved were all hostile, = or compelled to be hostile.

You have stated that there are alternatives by using= proxies but enterprise organizations have stated this is not viable due to= the complexity and scale of their network environments.
<= br>
Not all statements are created equal. Stating that proxies ca= n technically fulfill this function is objective, and can be backed up in c= lear technical detail.=C2=A0

Stating that proxies = are not viable for enterprise organizations due to the scale and complexity= of their network environments is subjective, generally not well-detailed, = and much more open to skepticism.

The burden on th= e proposers should be to address this skepticism, and to justify to the wor= king group why enterprises that are large enough and well-funded enough to = have such vast and complex networks cannot invest in upgrading those networ= ks to an approach that doesn't rely on directly weakening their own con= nection security and potentially the security of others' through the un= intended consequences of formalizing this RFC.
=C2=A0
Our collective objective is= to increase the security of the Internet at large. As such, we have propos= ed this RFC in order to ensure that TLS 1.3 is adopted as broadly as possib= le inside of enterprises, which is an important step in increasing security= .

So is increasing the use of forward secre= t connections within enterprise network environments. Why should the TLS WG= accept the argument that legacy approaches to monitoring enterprise networ= ks are worth risking the weakening of the product of years of hard work?
=C2=A0
-- Eric


-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.= org] On Behalf Of Stephen Farrell
Sent: Saturday, July 8, 2017 10:33
To: Yaron Sheffer <yaronf.ietf@= gmail.com>; tls chair <tls-chairs@tools.ietf.org>
Cc: tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...



On 08/07/17 15:27, Yaron Sheffer wrote:
> Hi Stephen,
>
> Like you, I am very unhappy with this draft, and would not support its=
> adoption as a WG draft. However I think that open discussion is in
> general good, and that the best venue for discussion of this draft is<= br> > this mailing list. Even if some of this discussion devolves into
> generic "are we pro or against wiretapping" questions.

FWIW I believe that we have had that discussion about breaking tls over and= over on this and other lists. I see no value in doing it yet again, even i= f the proximate cause is a new variation of the "here's a way to b= reak tls" class of drafts. (Someday we should find someone who'd d= ocument all the broken break-tls ideas that have been rightly rejected over= the years.)

>
> I don't think this is a significant distraction that could derail<= br> > (D)TLS, moreover, you will recall that in Chicago several new drafts > were adopted to the working group. So the WG does feel that TLS is in<= br> > good enough shape that we can spend some bandwidth on other things.
Maybe I'm more easily distracted, at least by this topic;-)

Anyway, I'm fine that it's for the chairs to figure that out.

S.


> Thanks,
>
>=C2=A0 =C2=A0 =C2=A0Yaron
>
>
> On 08/07/17 12:17, Stephen Farrell wrote:
>> Sean/Joe,
>>
>> This is a request that you, as chairs, shut down the distracting >> wiretapping discussion, at least until DTLS1.3 is done.
>>
>> I have planned to spend time reading draft 21 and DTLS, but that >> won't happen if we keep having to fight off the latest attempt= s to
>> break TLS. I'd not be surprised if I weren't the only one = finding
>> that distraction an irritating waste of time. Finishing
>> TLS1.3 and getting DTLS1.3 on the way surely needs to not be
>> constantly de-railed by these attempts to break TLS.
>>
>> Therefore I'd ask that you declare this discussion closed for = at
>> least that long (i.e until DTLS1.3 is done).
>>
>> I'd also ask that you not allocate agenda time for wiretapping= in
>> Prague.
>>
>> Thanks,
>> S.
>>
>>
>>
>> _______________________________________________
>> 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



--
=
--001a114fd37c53a3080553d80ff7-- From nobody Sat Jul 8 23:05:01 2017 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 64B1C127369 for ; Sat, 8 Jul 2017 23:05:00 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 fKQA2aCBb3m4 for ; Sat, 8 Jul 2017 23:04:58 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 9C0F812009C for ; Sat, 8 Jul 2017 23:04:58 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id p207so20353155yba.2 for ; Sat, 08 Jul 2017 23:04:58 -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=NRA/6v32h5xy0SROXZDuf1SnH8hVNQq2MfIqtGi6D3Y=; b=tIpl4UXu8SEVyVwQmaJQMeyW++2shggsM/XhjCSOrkSIJDbnCcSQskNC/mBmMprmIJ KqsNCpHgK+UpidLivRXEGyYdXoGseHdg9S6eBPpnV4Ch4xsb75aQpmqRdjIICIe2BJ/m Kpf3XL4MqRrOvHar+PcSXV3+ADSj8gbHAJJWhMfS4WjtwmvR/pPoawBfOJebyd0ZTj+I z1tJnYFihows09wZNu65/YHF0iDpbCw8W7ZoLYEOnAZuitUJKdoF8BogkgFL0jcE6f8O LG1KHt3yHAqhxBqWQfkLsj+IzZzYxNe5qBGQiEeqVXikoXcmO5wexRoIT10TVvje3YLL fWSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NRA/6v32h5xy0SROXZDuf1SnH8hVNQq2MfIqtGi6D3Y=; b=N9/xMrMrhykdJtt/5m/v1DXkx7xljc6e9riCgQf1UXDZ2ms5gwBAaTKLAl1fuyzlVy 6LtiZz87+Z/razldhIqKQfos3lzLLb13Ii0E/eNQL2JPwIiVSsWpl1wAxwRkTrDqEkDR fwzGlUr72Rn91OO5FtM3XdDq6d+hSKvPFsEZraMCs2bx7VSnlINlTJKMVi78X/YHXRoJ YKbCjImdr0XC7SNrvpTdQyWK3vBZCfNNNiyEiGJgGhElAsh5LG0CsEzS5aQekvaJKJvS JnHNMRjJHo9yNzZ1vXIKPGDhgxXXAmbvsVzFY12NlF1lSnJkFtMUxTWRSW1mjG+CavsQ 2fEw== X-Gm-Message-State: AIVw110fh3txkH6mKqsCcVq19rw1KLk6Df3UGnV1Gbunc2AXaqyqc8Bj crWrg/8Bl5AK90WeEw4gN1YnK2kYiSgc X-Received: by 10.37.208.66 with SMTP id h63mr2025400ybg.163.1499580297726; Sat, 08 Jul 2017 23:04:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.27.4 with HTTP; Sat, 8 Jul 2017 23:04:56 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sat, 8 Jul 2017 23:04:56 -0700 Message-ID: To: Watson Ladd Cc: Yoav Nir , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0553ccf571960553dc3e94" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 06:05:00 -0000 --94eb2c0553ccf571960553dc3e94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 8, 2017 at 9:27 AM, Watson Ladd wrote: > > > They also don=E2=80=99t want to install TLS proxies all over the place.= That=E2=80=99s a > > large extra expense for them. > > Nginx exists. What's the blocker? Here's how these networks work today: * Key servers are configured to use RSA KX, no DH. * In some cases, all outbound (e.g. internet) connectivity is also proxied via such a server. Clients are made to trust a private CA for this purpose. * All data is not necessarily logged or stored somewhere, and almost certainly not in the plain, as that would increase over-all risk. * Admins use port-mirrors and tools like tcpdump to investigate/scan suspicious flows from time to time, or as part of a targeted investigation. Occasionally it might also be used for debugging. The RSA keys can be used to render the connections plain on demand. * That doesn't mean that the RSA private keys are readily available, they are often very tightly controlled. Migrating to proxies would: * Be a very big operational change. Gotta get nginx on all of the boxes, is that even possible? * Completely change the access mechanisms, invalidate almost all of the operational controls. * Probably more than double the basic compute costs associated with encryption. * Create more sensitive environments where plaintext is floating around. That doesn't mean that these vendors/operators are owed a solution, or an easy-to-insert more-or-less-compatible-with-today mechanism. But it does help assess whether they are really likely to adopt TLS1.3 to begin with. --=20 Colm --94eb2c0553ccf571960553dc3e94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 8, 2017 at 9:27 AM, Watson Ladd <watsonbladd@gmail.com= > wrote:
> They also don=E2=80=99t want to install TLS proxies all over the place= .=C2=A0 That=E2=80=99s a
> large extra expense for them.

Nginx exists. What's the blocker?

Here's how these networks work today:

* Key = servers are configured to use RSA KX, no DH.
* In some cases, all= outbound (e.g. internet) connectivity is also proxied via such a server. C= lients are made to trust a private CA for this purpose.=C2=A0
* A= ll data is not necessarily logged or stored somewhere, and almost certainly= not in the plain, as that would increase over-all risk.
* Admins= use port-mirrors and tools like tcpdump to investigate/scan suspicious flo= ws from time to time, or as part of a targeted investigation. Occasionally = it might also be used for debugging. The RSA keys can be used to render the= connections plain on demand.=C2=A0
* That doesn't mean that = the RSA private keys are readily available, they are often very tightly con= trolled.=C2=A0

Migrating to proxies would:

* Be a very big operational change. Gotta get nginx on al= l of the boxes, is that even possible?=C2=A0
* Completely change = the access mechanisms, invalidate almost all of the operational controls.= =C2=A0
* Probably more than double the basic compute costs associ= ated with encryption.
* Create more sensitive environments where = plaintext is floating around.=C2=A0


That doesn't mean that these vendors/operators are owed a solution, or= an easy-to-insert more-or-less-compatible-with-today mechanism. But it doe= s help assess whether they are really likely to adopt TLS1.3 to begin with.= =C2=A0

--
Colm
--94eb2c0553ccf571960553dc3e94-- From nobody Sat Jul 8 23:23:43 2017 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 92396127F0E for ; Sat, 8 Jul 2017 23:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 ByNnp1BRPsiE for ; Sat, 8 Jul 2017 23:23:40 -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 13FC1127977 for ; Sat, 8 Jul 2017 23:23:40 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id a12so25723396ywh.3 for ; Sat, 08 Jul 2017 23:23:39 -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=06WPUsNAnMF00duTwlbVhGj7EynnHp9N3mPJZuHNbXo=; b=1vYgJXYjOoYzb3bG5yZKMgOdWDtd6JRUWntEUxcky3sImG0f6oaTrvfHLJk2LqBBaV yyaIlqdD+CZd7nY6qdoDSEQ+1soWX22zqFTh5H5jxZ7LkJOkCRwn+a9az47jtcTIuike JqN+YoP9xX6FVLsLAsCAy2GT6eyYPur61Jp1jLKPV7MDxKHzV2wRX4Cu8FWppCBoDieK WbK+h4FkgQ6N2wDZFgXmXIEQFRw21pzfgoNDuLRxxdrToG7XEumORKhAFptr4Bi+xaA3 xsxBSAGSFtobgdOoeGPvMfMNPR+q07aYDUgpE9M4pPQeKixKMRmTiQaPlssy99rJp+jY gxKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=06WPUsNAnMF00duTwlbVhGj7EynnHp9N3mPJZuHNbXo=; b=az5IELlNVB0PSXM85naogcjWNEtzry5mmqgHZfh7NsHuun/CLlZ6GgcD7IBDcrPDrr sWGf2pJlSeGcNW7V6J1KjgbJrYo/aBtgeGbN87UmwQyvJYuY8nxNOajrDNvLgD/8P4oL pAddLmzIfdCKRCt/xq/+9TUU03O+hotQv7IS4YbBnHFgYlSUmDnkD6cSEsMQKHBAcVjS kKX8cSnRjqolmBc7dsMRI8BWlHzjGwUrmKZ4glKwI2Lj/2SEVxi2quCb10kCzWpp7Hze +3S/60hewDWgVongFJdvgf/Tg14qh9NbqH9a8JRKPBVQoQ1YdS+d6jeiC4ABY73zcycw XXCw== X-Gm-Message-State: AIVw113FPx/+HrYWaqsrgFlcDQBnfFz8kuHUZY8vbe/pyLKi8H2xlayE AApTsQmBHPJaZEuRxCJg0yFq+2ejbjwZ X-Received: by 10.129.201.66 with SMTP id c2mr8247538ywl.14.1499581419219; Sat, 08 Jul 2017 23:23:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.27.4 with HTTP; Sat, 8 Jul 2017 23:23:38 -0700 (PDT) In-Reply-To: References: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> <634dbf72eee14617a2359f2792d4aee0@venafi.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sat, 8 Jul 2017 23:23:38 -0700 Message-ID: To: Eric Mill Cc: Paul Turner , "tls@ietf.org" , tls chair Content-Type: multipart/alternative; boundary="089e08222864ce05350553dc81a5" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 06:23:41 -0000 --089e08222864ce05350553dc81a5 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 6:04 PM, Eric Mill wrote: > > Stating that proxies are not viable for enterprise organizations due to > the scale and complexity of their network environments is subjective, > generally not well-detailed, and much more open to skepticism. > > The burden on the proposers should be to address this skepticism, and to > justify to the working group why enterprises that are large enough and > well-funded enough to have such vast and complex networks cannot invest in > upgrading those networks to an approach that doesn't rely on directly > weakening their own connection security and potentially the security of > others' through the unintended consequences of formalizing this RFC. > TLS1.3 isn't a debate, or a legal argument. It's an actual thing in the world that we'd like to see succeed and be as pervasive as possible. The folks reporting saying it won't work are doing us a favor, they don't owe us anything. So when those users show up saying "This won't work for me", it is better to have a very open mind and make every attempt to understand them. If their explanations are not clear, then burrow further. Be charitable and lean as heavily towards why they may be right, search for good reasoning in /their/ favor, and state it as well as it can possibly be presented. Only on those terms try to tackle it with alternatives. If the presenters are wrong, and the skepticism is merited, that approach will still work. But if they happen to be right, it makes the alternatives or adaptations more clear, or the necessity for them more obvious. Dismissing concerns with trivial and shallow analysis can serve to diminish the success of TLS1.3, because the users don't need to adopt it, and can end up blocking it and creating a failure of "TLS 1.3 doesn't work in XXX environments". -- Colm --089e08222864ce05350553dc81a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 8, 2017 at 6:04 PM, Eric Mill <eric@konklone.com> wrote:

Stating that proxies are not viable for enterprise orga= nizations due to the scale and complexity of their network environments is = subjective, generally not well-detailed, and much more open to skepticism.<= br>

The burden on the propose= rs should be to address this skepticism, and to justify to the working grou= p why enterprises that are large enough and well-funded enough to have such= vast and complex networks cannot invest in upgrading those networks to an = approach that doesn't rely on directly weakening their own connection s= ecurity and potentially the security of others' through the unintended = consequences of formalizing this RFC.
<= div>
TLS1.3 isn't a debate, or a legal argument. It's= an actual thing in the world that we'd like to see succeed and be as p= ervasive as possible. The folks reporting saying it won't work are doin= g us a favor, they don't owe us anything.

So w= hen those users show up saying "This won't work for me", it i= s better to have a very open mind and make every attempt to understand them= . If their explanations are not clear, then burrow further. Be charitable a= nd lean as heavily towards why they may be right, search for good reasoning= in /their/ favor, and state it as well as it can possibly be presented. On= ly on those terms try to tackle it with alternatives.

If the presenters are wrong, and the skepticism is merited, that ap= proach will still work. But if they happen to be right, it makes the altern= atives or adaptations more clear, or the necessity for them more obvious. D= ismissing concerns with trivial and shallow analysis can serve to diminish = the success of TLS1.3, because the users don't need to adopt it, and ca= n end up blocking it and creating a failure of "TLS 1.3 doesn't wo= rk in XXX environments".=C2=A0

--
Colm
--089e08222864ce05350553dc81a5-- From nobody Sun Jul 9 02:44:50 2017 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 9F5DC126C23 for ; Sun, 9 Jul 2017 02:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=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 OoMoHiR9lxQQ for ; Sun, 9 Jul 2017 02:44:45 -0700 (PDT) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C615124D68 for ; Sun, 9 Jul 2017 02:44:44 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 6C09020368B; Sun, 9 Jul 2017 09:44:41 +0000 (UTC) Received: from [192.168.0.65] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Sun, 9 Jul 2017 11:44:41 +0200 To: Eric Rescorla CC: "tls@ietf.org" References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> From: Marco Tiloca Message-ID: <0ae67cbc-e96c-0a22-b97d-f9c3fdea8eda@ri.se> Date: Sun, 9 Jul 2017 11:44:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g843illcPN8r5XQhxM5CX1oLuVSxAio4t" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=aq3CMWRV c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=G3gG6ho9WtcA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=uTM5gQLEAAAA:8 a=xPT6tdSuAAAA:8 a=VbdBpaqbNeYOeNDVaQMA:9 a=gtaOcv92oST3vib0:21 a=wZBQY-2j8Y65M_5g:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=JbOb8jl0-zDOI8HELKoA:9 a=eB6ed6oelfFSIF0D:21 a=iV9moG4F5fHItXsR:21 a=o4LvZs65HfMrZQxm:21 a=_W_S_7VecoQA:10 a=DIOMxfJ4J7wpsvcsKDIA:9 a=ONNS8QRKHyMA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=X0a8wEfk66sNBbu13Lvv:22 a=80PJfYVSYmV_jLpvUEnt:22 a=6kGIvZw6iX1k4Y-7sg4_:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 09:44:48 -0000 --g843illcPN8r5XQhxM5CX1oLuVSxAio4t Content-Type: multipart/mixed; boundary="jAh4RbxdvsKaJBj7CI3KUiCs4VnGVOlQ4"; protected-headers="v1" From: Marco Tiloca To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <0ae67cbc-e96c-0a22-b97d-f9c3fdea8eda@ri.se> Subject: Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> In-Reply-To: --jAh4RbxdvsKaJBj7CI3KUiCs4VnGVOlQ4 Content-Type: multipart/alternative; boundary="------------4792663C905C583DBAA53E20" Content-Language: en-US This is a multi-part message in MIME format. --------------4792663C905C583DBAA53E20 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Eric, Thanks for your good comments! Please, see my answers inline. Best, /Marco On 2017-07-08 16:45, Eric Rescorla wrote: > Document: draft-tiloca-tls-dos-handshake-00.txt > > I'm trying to understand the threat model and operating model this > is designed for. Let's start with the threat model. The anti-DoS > mechanisms in DTLS are specifically oriented towards attackers > who are not on-path, because on-path attackers can, as you > say, obtain the HRR/HVR. > > You say: > > DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optional > Cookie exchange as possible solution to mitigate this Denial of > Service attack. While this makes the attack more complicated to > mount, a well determined and resourceful adversary able to spoof > valid IP addresses can still successfully perform it, by interceptin= g > the possible server response including the Cookie and then echoing i= t > in the second ClientHello. This is particularly doable in case the > handshake is not based on Pre-Shared Key exchange modes. > > I take from this that your assumed threat model is an attacker who is > minimally a man-on-the-side (i.e., able to read traffic and inject his > own but not block) and maximally a full active attacker able to block > data. Is that correct? > Yes, correct. > > Depending on the specific protocol version and the key establishment= > mode used in the handshake, the attack impact can range from single > replies triggered by invalid ClientHello messages, to the server > performing advanced handshake steps with consequent setup of invalid= > half-open sessions. Especially if performed in a large-scale and > distributed manner, this attack can thwart performance and service > availability of (D)TLS servers. Moreover, it can be particularly > effective in application scenarios where servers are resource- > constrained devices running DTLS over low-power, low bandwidth and > lossy networks. > > It seems like the attack you are considering is one in which the > attacker generates DTLS handshakes and then forces the DTLS server to > either perform computations or hold state open (e.g., by doing a > handshake or a partial handshake and then stopping) Is that correct? > Yes, correct. > Assuming I am correct, the design you describe here seems much more > complicated than necessary [0]. Consider the simpler design: > > - The client contacts the TA > - TA generates a new value C =3D HMAC(k_M, N) and sends that to the > client > - the client inserts C in the ClientHello. > > The major downside is that this allows an on-path attacker to steal C a= nd > put it in their own CH, but so what? The attacker is still rate limited= > by the number of valid clients, and (at least) a fully active attacker > doesn't need to substitute their own handshake messages for the valid > clients because they can force the server to perform computations > by playing the client messages and leave the server in a half-open > state by blocking some client messages. I suppose you could argue > that they could negotiate cipher suites that are more expensive to > the server, but that seems like a fairly weak attack. > This alternative is surely simpler and good to consider, and I agree with your related considerations. I would add that the TA has still to provide also N to the client, for inclusion in the extension. N is in fact required by the server for recomputing the HMAC and perform anti-replay checks on the ClientHello as suggested in the draft. The model currently described in the draft considers additional key material and related derivation, thinking also about session resumption (see also the related comment below). To this end, the design above would then additionally consider (consistently with the draft's description): - The TA deriving K_S from K_M and N; and K_MAC from K_S - The TA computing the HMAC using K_MAC - The TA sending also K_S to the client > Just to touch briefly on resumption: why do you need this mechanism > at all for that? The client and server already have an assocation > so the server knows that it has a valid client without any new > assertion from the TA. True, although in case of resumption it is not anymore a full assertion of client's validity, but it's rather about protecting from replays of valid resumption requests. Also, it considers Section 7.4.1.4 of RFC 5246, i.e. the same extensions SHOULD be included in case of request for session resumption. This also led to the design in the draft (i.e., the HMAC computed by the client and the provisioning of a session key K_S), so that the client does not require to contact the TA again in case of intended session resumption. Consistently with the alternative design proposed above, in case of resumption request, the client can compute the HMAC itself, again only over the extension-related content, like considered by the TA in the main case for new session establishment. This would also avoid the implementation issues you mentioned below [0] for the current approach in (D)TLS 1.3. > > -Ekr > > [0] It also, won't work. In particular, having the client send a > MAC over the CH leads to having to zero out portions of the CH, which > is going to create implementation problems in two ways. First, it > creates a circular dependency with the TLS 1.3 PSK binder, so you'll > need to have an exception there. Second, the zero-ing out trick you > use is actually quite annoying to implement in many TLS stacks (it > would be so in NSS). I understand your concerns as to implementation complications. We can then build on the alternative design above to avoid them by construction.= > > > > On Sat, Jul 8, 2017 at 4:10 AM, Marco Tiloca > wrote: > > Dear all, > > FYI, we have recently submitted a new draft proposing an extension > for (D)TLS 1.2/1.3. > > The solution described in the draft addresses Denial of Service > attacks against the handshake protocol, allowing servers to > promptly abort invalid session set ups. > > Feedback and comments are of course very welcome. Thanks a lot! > > Best regards, > /Marco > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-tiloca-tls-dos-handshake-00.txt > Date: Wed, 28 Jun 2017 07:40:45 -0700 > From: internet-drafts@ietf.org > To: Marco Tiloca > , Ludwig Seitz > , Maarten Hoeve > > > > > A new version of I-D, draft-tiloca-tls-dos-handshake-00.txt > has been successfully submitted by Marco Tiloca and posted to the > IETF repository. > > Name: draft-tiloca-tls-dos-handshake > Revision: 00 > Title: Extension for protecting (D)TLS handshakes against Denial o= f Service > Document date: 2017-06-28 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-tiloca-t= ls-dos-handshake-00.txt > > Status: https://datatracker.ietf.org/doc/draft-tiloca-tls-d= os-handshake/ > > Htmlized: https://tools.ietf.org/html/draft-tiloca-tls-dos-ha= ndshake-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-= tls-dos-handshake-00 > > > > Abstract: > This document describes an extension for TLS and DTLS to protect= the > server from Denial of Service attacks against the handshake prot= ocol. > The extension includes a Message Authentication Code (MAC) over = the > ClientHello message, computed by the Client through key material= > obtained from a Trust Anchor entity. The server registered at t= he > Trust Anchor derives the same key material and checks the MAC to= > determine whether continuing or aborting the handshake. > > = =20 > > > Please note that it may take a couple of minutes from the time of s= ubmission > until the htmlized version and diff are available at tools.ietf.org= . > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --=20 Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se https://www.sics.se/~marco/ The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society. SICS Swedish ICT AB, has now changed name to RISE SICS AB. --------------4792663C905C583DBAA53E20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Eric,

Thanks for your good comments!

Please, see my answers inline.

Best,
/Marco

On 2017-07-08 16:45, Eric Rescorla wrote:
Document: draft-tiloca-tls-dos-handshake-00.txt

I'm trying to understand the threat model and operating model this
is designed for. Let's start with the threat model. The anti-DoS
mechanisms in DTLS are specifically oriented towards attackers
who are not on-path, because on-path attackers can, as you
say, obtain the HRR/HVR.

You say:

=C2=A0 =C2=A0DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 p= rovide the optional
=C2=A0 =C2=A0Cookie exchange as possible solution to mitigat= e this Denial of
=C2=A0 =C2=A0Service attack.=C2=A0 While this makes the atta= ck more complicated to
=C2=A0 =C2=A0mount, a well determined and resourceful advers= ary able to spoof
=C2=A0 =C2=A0valid IP addresses can still successfully perfo= rm it, by intercepting
=C2=A0 =C2=A0the possible server response including the Cook= ie and then echoing it
=C2=A0 =C2=A0in the second ClientHello.=C2=A0 This is partic= ularly doable in case the
=C2=A0 =C2=A0handshake is not based on Pre-Shared Key exchan= ge modes.

I take from this that your assumed threat model is an attacker who is
minimally a man-on-the-side (i.e., able to read traffic and inject his
own but not block) and maximally a full active attacker able to block
data. Is that correct?


Yes, correct.


=C2=A0 =C2=A0Depending on the specific protocol version and = the key establishment
=C2=A0 =C2=A0mode used in the handshake, the attack impact c= an range from single
=C2=A0 =C2=A0replies triggered by invalid ClientHello messag= es, to the server
=C2=A0 =C2=A0performing advanced handshake steps with conseq= uent setup of invalid
=C2=A0 =C2=A0half-open sessions.=C2=A0 Especially if perform= ed in a large-scale and
=C2=A0 =C2=A0distributed manner, this attack can thwart perf= ormance and service
=C2=A0 =C2=A0availability of (D)TLS servers.=C2=A0 Moreover,= it can be particularly
=C2=A0 =C2=A0effective in application scenarios where server= s are resource-
=C2=A0 =C2=A0constrained devices running DTLS over low-power= , low bandwidth and
=C2=A0 =C2=A0lossy networks.

It seems like the attack you are considering is one in which the
attacker generates DTLS handshakes and then forces the DTLS server to
either perform computations or hold state open (e.g., by doing a
handshake or a partial handshake and then stopping) Is that correct?


Yes, correct.

Assuming I am correct, the design you describe here seems much more
complicated than necessary [0]. Consider the simpler design:

- The client contacts the TA
- TA generates a new value C =3D HMAC(k_M, N) and sends that= to the
=C2=A0 client
- the client inserts C in the ClientHello.

The major downside is that this allows an on-path attacker to steal C and
put it in their own CH, but so what? The attacker is still rate limited
by the number of valid clients, and (at least) a fully active attacker
doesn't need to substitute their own handshake messages for the valid
clients because they can force the server to perform computations
by playing the client messages and leave the server in a half-open
state by blocking some client messages. I suppose you could argue
that they could negotiate cipher suites that are more expensive to
the server, but that seems like a fairly weak attack.


This alternative is surely simpler and good to consider, and I agree with your related considerations.

I would add that the TA has still to provide also N to the client, for inclusion in the extension. N is in fact required by the server for recomputing the HMAC and perform anti-replay checks on the ClientHello as suggested in the draft.


The model currently described in the draft considers additional key material and related derivation, thinking also about session resumption (see also the related comment below). To this end, the design above would then additionally consider (consistently with the draft's description):

- The TA deriving K_S from K_M and N; and K_MAC from K_S
- The TA computing the HMAC using K_MAC
- The TA sending also K_S to the client

Just to touch briefly on resumption: why do you need this mechanism
at all for that? The client and server already have an assocation
so the server knows that it has a valid client without any new
assertion from the TA.

True, although in case of resumption it is not anymore a full assertion of client's validity, but it's rather about protecting from replays of valid resumption requests.

Also, it considers Section 7.4.1.4 of RFC 5246, i.e. the same extensions SHOULD be included in case of request for session resumption.

This also led to the design in the draft (i.e., the HMAC computed by the client and the provisioning of a session key K_S), so that the client does not require to contact the TA again in case of intended session resumption.

Consistently with the alternative design proposed above, in case of resumption request, the client can compute the HMAC itself, again only over the extension-related content, like considered by the TA in the main case for new session establishment. This would also avoid the implementation issues you mentioned below [0] for the current approach in (D)TLS 1.3.



-Ekr

[0] It also, won't work. In particular, having the client send a
MAC over the CH leads to having to zero out portions of the CH, which
is going to create implementation problems in two ways. First, it
creates a circular dependency with the TLS 1.3 PSK binder, so you'll
need to have an exception there. Second, the zero-ing out trick you
use is actually quite annoying to implement in many TLS stacks (it
would be so in NSS).

I understand your concerns as to implementation complications. We can then build on the alternative design above to avoid them by construction.




On Sat, Jul 8, 2017 at 4:10 AM, Marco Tiloca <marco.tiloca@ri.se> wrote:
Dear all,

FYI, we have recently submitted a new draft proposing an extension for (D)TLS 1.2/1.3.

The solution described in the draft addresses Denial of Service attacks against the handshake protocol, allowing servers to promptly abort invalid session set ups.

Feedback and comments are of course very welcome. Thanks a lot!

Best regards,
/Marco
<= br> -------- Forwarded Message --------
Subject: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
Date: Wed, 28 Jun 2017 07:40:45 -0700
From: inte= rnet-drafts@ietf.org
To: Marco Tiloca <= marco.tiloca@ri.se>, Ludwig Seitz <= ludwig.seitz@ri.se>, Maarten Hoeve <= maarten.hoeve@encs.eu> 


A new version of I-D, draft-tiloca-tls-dos-hand=
shake-00.txt
has been successfully submitted by Marco Tiloca and posted to the
IETF repository.

Name:		draft-tiloca-tls-dos-handshake
Revision:	00
Title:		Extension for protecting (D)TLS handshakes against Denial of Serv=
ice
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org=
/internet-drafts/draft-tiloca-tls-dos-handshake-00.txt
Status:         https://datatracker.ietf.org/<=
wbr>doc/draft-tiloca-tls-dos-handshake/
Htmlized:       https://tools.ietf.org/html/=
draft-tiloca-tls-dos-handshake-00
Htmlized:       https://datatracker.iet=
f.org/doc/html/draft-tiloca-tls-dos-handshake-00


Abstract:
   This document describes an extension for TLS and DTLS to protect the
   server from Denial of Service attacks against the handshake protocol.
   The extension includes a Message Authentication Code (MAC) over the
   ClientHello message, computed by the Client through key material
   obtained from a Trust Anchor entity.  The server registered at the
   Trust Anchor derives the same key material and checks the MAC to
   determine whether continuing or aborting the handshake.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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



--=20
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://w=
ww.sics.se
h=
ttps://www.sics.se/~marco/

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.
--------------4792663C905C583DBAA53E20-- --jAh4RbxdvsKaJBj7CI3KUiCs4VnGVOlQ4-- --g843illcPN8r5XQhxM5CX1oLuVSxAio4t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYfr/AAoJEO4mZLQOWNpDDtQH/jT4SD6juRNBSdWuHQ+E+GGa MNU/p400amRDP9U4sIlu35H1uNBUcK9HefyzH2EGIq6ZRgMTVWYq41uJmglSSoYk minLHJOj0Ktj8/DBtR1F/PYsd1r7lYCcX7/s+dJfa8j1HUxojGR87zhPLZX0W8uP t4EuSYl0xTxjE9mptoUTELWdiljBkfn1IU/52lO9g6pyG8FrqBAxHjg76pMBxlfF kCYzVhirQzhOawRNSkYNg/ZXWwrvE/V9CuK6tbuQ7aJ3pGOCEGALvfKdZEUiWq5u xGVLQEeskFVK4b1EwisXqppfKuknT3nmFuS84hKeQe9PtMl78eLX2TCLKQysEJs= =5t5x -----END PGP SIGNATURE----- --g843illcPN8r5XQhxM5CX1oLuVSxAio4t-- From nobody Sun Jul 9 06:33:50 2017 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 F3DD313144E for ; Sun, 9 Jul 2017 06:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 4u0X2FRWaTYT for ; Sun, 9 Jul 2017 06:33:45 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002: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 08C9512F3D3 for ; Sun, 9 Jul 2017 06:33:45 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id 84so21563401ybe.0 for ; Sun, 09 Jul 2017 06:33:45 -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=t7Uo/c2TDDpaKux9G0fEMegzBPSQBR79+sjiFQGhcKg=; b=WHtGfy1JDqD7oaW3y3JfOc2xYrzf6EE014j7YDsFn7I5fHDWBUM/O/nexknFgQrBXn e4rq2vvU9NmevEZS3hKUMOJdziYOj40X8PkJWE/yF9NugA+ScQffLp4sX8/+NSodqWLl KJ0lgUEgyA9HKDAcN/OHKRrvolV7b05xPzgS8bctq4yS+D6JmXc4bkJJxFlMf33lBDs2 kygSpuUy/8jkRbzyW00Bf+tqQX8rN1p6t/YWIUuT9WOmaEh8d+ZV43c9Aajw6NG+T/bM SpF/te76jywhL/Nj6sduUENRYeBUlKklwU4ss39nEr58qeb4S1Q1ciSdQTcWJVu6sKDl CgGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t7Uo/c2TDDpaKux9G0fEMegzBPSQBR79+sjiFQGhcKg=; b=gh5IswWbzwN66PQq5RAX6Tk6ZnJ9J4JPhL77VcuWU5xsTD+6iBIcleETgnZKFKguxC 5D+lUgfBYmeTLWmimRCwPBev3P2zbnXxftltIxsFjCizovWYdjapc90g77WwRlFWrOdA skxjXJoiPcXC5qphPsh+hXzesm96jMF9gBD9csp4Gx8+wsUPy1PYlajgquEDC7MaICuG RgxhUO+t2GZ2eou9KnOnSwUGYWE/uJOsBtkiMoKoKA12X8Wjlla3yxmHC4Nbz/b1LPdq vIOLdYyBvCauDoRmUMXX4Mo7zgxFZ3eVXDmzqeGW/jE/f/NajxE+EkkOID4ZnsiCqZH8 JZqg== X-Gm-Message-State: AIVw113p8ED03C4OD3JeQurPHGHOSNbzJbHc0kwugmbfyXgvA9lnZTtp T/W+I83SkINEi87lN1jUVA8xLXntzVUse0A= X-Received: by 10.37.42.10 with SMTP id q10mr11870003ybq.71.1499607224161; Sun, 09 Jul 2017 06:33:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 9 Jul 2017 06:33:03 -0700 (PDT) In-Reply-To: <0ae67cbc-e96c-0a22-b97d-f9c3fdea8eda@ri.se> References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> <0ae67cbc-e96c-0a22-b97d-f9c3fdea8eda@ri.se> From: Eric Rescorla Date: Sun, 9 Jul 2017 06:33:03 -0700 Message-ID: To: Marco Tiloca Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11440108e6361a0553e283d0" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 13:33:48 -0000 --001a11440108e6361a0553e283d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 9, 2017 at 2:44 AM, Marco Tiloca wrote: > Hello Eric, > > Thanks for your good comments! > > Please, see my answers inline. > > Best, > /Marco > > On 2017-07-08 16:45, Eric Rescorla wrote: > > Document: draft-tiloca-tls-dos-handshake-00.txt > > I'm trying to understand the threat model and operating model this > is designed for. Let's start with the threat model. The anti-DoS > mechanisms in DTLS are specifically oriented towards attackers > who are not on-path, because on-path attackers can, as you > say, obtain the HRR/HVR. > > You say: > > DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optional > Cookie exchange as possible solution to mitigate this Denial of > Service attack. While this makes the attack more complicated to > mount, a well determined and resourceful adversary able to spoof > valid IP addresses can still successfully perform it, by intercepting > the possible server response including the Cookie and then echoing it > in the second ClientHello. This is particularly doable in case the > handshake is not based on Pre-Shared Key exchange modes. > > I take from this that your assumed threat model is an attacker who is > minimally a man-on-the-side (i.e., able to read traffic and inject his > own but not block) and maximally a full active attacker able to block > data. Is that correct? > > > Yes, correct. > > > Depending on the specific protocol version and the key establishment > mode used in the handshake, the attack impact can range from single > replies triggered by invalid ClientHello messages, to the server > performing advanced handshake steps with consequent setup of invalid > half-open sessions. Especially if performed in a large-scale and > distributed manner, this attack can thwart performance and service > availability of (D)TLS servers. Moreover, it can be particularly > effective in application scenarios where servers are resource- > constrained devices running DTLS over low-power, low bandwidth and > lossy networks. > > It seems like the attack you are considering is one in which the > attacker generates DTLS handshakes and then forces the DTLS server to > either perform computations or hold state open (e.g., by doing a > handshake or a partial handshake and then stopping) Is that correct? > > > Yes, correct. > > Assuming I am correct, the design you describe here seems much more > complicated than necessary [0]. Consider the simpler design: > > - The client contacts the TA > - TA generates a new value C =3D HMAC(k_M, N) and sends that to the > client > - the client inserts C in the ClientHello. > > The major downside is that this allows an on-path attacker to steal C and > put it in their own CH, but so what? The attacker is still rate limited > by the number of valid clients, and (at least) a fully active attacker > doesn't need to substitute their own handshake messages for the valid > clients because they can force the server to perform computations > by playing the client messages and leave the server in a half-open > state by blocking some client messages. I suppose you could argue > that they could negotiate cipher suites that are more expensive to > the server, but that seems like a fairly weak attack. > > > This alternative is surely simpler and good to consider, and I agree with > your related considerations. > > I would add that the TA has still to provide also N to the client, for > inclusion in the extension. N is in fact required by the server for > recomputing the HMAC and perform anti-replay checks on the ClientHello as > suggested in the draft. > Well, sort of. It needs to supply the client some opaque token. The only semantics of this token are between the TA and the server. The model currently described in the draft considers additional key > material and related derivation, thinking also about session resumption > (see also the related comment below). To this end, the design above would > then additionally consider (consistently with the draft's description): > > - The TA deriving K_S from K_M and N; and K_MAC from K_S > - The TA computing the HMAC using K_MAC > - The TA sending also K_S to the client > > Just to touch briefly on resumption: why do you need this mechanism > at all for that? The client and server already have an assocation > so the server knows that it has a valid client without any new > assertion from the TA. > > > True, although in case of resumption it is not anymore a full assertion o= f > client's validity, but it's rather about protecting from replays of valid > resumption requests. > Sure, but you already have to keep a per-client database of resumption requests (because the resumption counter is independent) and you might as well key this by the ticket and then just record clienthellos as in the guidance for TLS 1.3 0-RTT anti-replay. Also, it considers Section 7.4.1.4 of RFC 5246, i.e. the same extensions > SHOULD be included in case of request for session resumption. > > This also led to the design in the draft (i.e., the HMAC computed by the > client and the provisioning of a session key K_S), so that the client doe= s > not require to contact the TA again in case of intended session resumptio= n. > It seems like if this is really important, the TA could just give the client some small number of tokens on initial contact. -Ekr > Consistently with the alternative design proposed above, in case of > resumption request, the client can compute the HMAC itself, again only ov= er > the extension-related content, like considered by the TA in the main case > for new session establishment. This would also avoid the implementation > issues you mentioned below [0] for the current approach in (D)TLS 1.3. > > > > -Ekr > > [0] It also, won't work. In particular, having the client send a > MAC over the CH leads to having to zero out portions of the CH, which > is going to create implementation problems in two ways. First, it > creates a circular dependency with the TLS 1.3 PSK binder, so you'll > need to have an exception there. Second, the zero-ing out trick you > use is actually quite annoying to implement in many TLS stacks (it > would be so in NSS). > > > I understand your concerns as to implementation complications. We can the= n > build on the alternative design above to avoid them by construction. > > > > > > On Sat, Jul 8, 2017 at 4:10 AM, Marco Tiloca wrote: > >> Dear all, >> >> FYI, we have recently submitted a new draft proposing an extension for >> (D)TLS 1.2/1.3. >> >> The solution described in the draft addresses Denial of Service attacks >> against the handshake protocol, allowing servers to promptly abort inval= id >> session set ups. >> >> Feedback and comments are of course very welcome. Thanks a lot! >> >> Best regards, >> /Marco >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-tiloca-tls-dos-handshake >> -00.txt >> Date: Wed, 28 Jun 2017 07:40:45 -0700 >> From: internet-drafts@ietf.org >> To: Marco Tiloca , Ludwig Seitz >> , Maarten Hoeve >> >> >> A new version of I-D, draft-tiloca-tls-dos-handshake-00.txt >> has been successfully submitted by Marco Tiloca and posted to the >> IETF repository. >> >> Name: draft-tiloca-tls-dos-handshake >> Revision: 00 >> Title: Extension for protecting (D)TLS handshakes against Denial of Ser= vice >> Document date: 2017-06-28 >> Group: Individual Submission >> Pages: 12 >> URL: https://www.ietf.org/internet-drafts/draft-tiloca-tls-do= s-handshake-00.txt >> Status: https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-ha= ndshake/ >> Htmlized: https://tools.ietf.org/html/draft-tiloca-tls-dos-handsha= ke-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-tls-d= os-handshake-00 >> >> >> Abstract: >> This document describes an extension for TLS and DTLS to protect the >> server from Denial of Service attacks against the handshake protocol. >> The extension includes a Message Authentication Code (MAC) over the >> ClientHello message, computed by the Client through key material >> obtained from a Trust Anchor entity. The server registered at the >> Trust Anchor derives the same key material and checks the MAC to >> determine whether continuing or aborting the handshake. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > -- > Marco Tiloca, PhD > Research Institutes of Sweden > RISE ICT/SICS > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > Phone: +46 (0)70 60 46 501https://www.sics.sehttps://www.sics.se/~marco/ > > The RISE institutes Innventia, SP and Swedish ICT > have merged in order to become a stronger research > and innovation partner for businesses and society. > > SICS Swedish ICT AB, has now changed name to RISE SICS AB. > > --001a11440108e6361a0553e283d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 9, 2017 at 2:44 AM, Marco Tiloca <marco.tiloca@ri.se&= gt; wrote:
=20 =20 =20
Hello Eric,

Thanks for your good comments!

Please, see my answers inline.

Best,
/Marco

On 2017-07-08 16:45= , Eric Rescorla wrote:
=20
Document: draft-tiloca-tls-dos-handshake-00.txt

I'm trying to understand the threat model and operating model this
is designed for. Let's start with the threat model. The anti-DoS
mechanisms in DTLS are specifically oriented towards attackers
who are not on-path, because on-path attackers can, as you
say, obtain the HRR/HVR.

You say:

=C2=A0 =C2=A0DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 pro= vide the optional
=C2=A0 =C2=A0Cookie exchange as possible solution to mitigate = this Denial of
=C2=A0 =C2=A0Service attack.=C2=A0 While this makes the attack= more complicated to
=C2=A0 =C2=A0mount, a well determined and resourceful adversar= y able to spoof
=C2=A0 =C2=A0valid IP addresses can still successfully perform= it, by intercepting
=C2=A0 =C2=A0the possible server response including the Cookie= and then echoing it
=C2=A0 =C2=A0in the second ClientHello.=C2=A0 This is particul= arly doable in case the
=C2=A0 =C2=A0handshake is not based on Pre-Shared Key exchange= modes.

I take from this that your assumed threat model is an attacker who is
minimally a man-on-the-side (i.e., able to read traffic and inject his
own but not block) and maximally a full active attacker able to block
data. Is that correct?


 Yes, correct.


=C2=A0 =C2=A0Depending on the specific protocol version and th= e key establishment
=C2=A0 =C2=A0mode used in the handshake, the attack impact can= range from single
=C2=A0 =C2=A0replies triggered by invalid ClientHello messages= , to the server
=C2=A0 =C2=A0performing advanced handshake steps with conseque= nt setup of invalid
=C2=A0 =C2=A0half-open sessions.=C2=A0 Especially if performed= in a large-scale and
=C2=A0 =C2=A0distributed manner, this attack can thwart perfor= mance and service
=C2=A0 =C2=A0availability of (D)TLS servers.=C2=A0 Moreover, i= t can be particularly
=C2=A0 =C2=A0effective in application scenarios where servers = are resource-
=C2=A0 =C2=A0constrained devices running DTLS over low-power, = low bandwidth and
=C2=A0 =C2=A0lossy networks.

It seems like the attack you are considering is one in which the
attacker generates DTLS handshakes and then forces the DTLS server to
either perform computations or hold state open (e.g., by doing a
handshake or a partial handshake and then stopping) Is that correct?


 Yes, correct.

Assuming I am correct, the design you describe here seems much more
complicated than necessary [0]. Consider the simpler design:

- The client contacts the TA
- TA generates a new value C =3D HMAC(k_M, N) and sends that to the
=C2=A0 client
- the client inserts C in the ClientHello.

The major downside is that this allows an on-path attacker to steal C and
put it in their own CH, but so what? The attacker is still rate limited
by the number of valid clients, and (at least) a fully active attacker
doesn't need to substitute their own handshake messages fo= r the valid
clients because they can force the server to perform computations
by playing the client messages and leave the server in a half-open
state by blocking some client messages. I suppose you could argue
that they could negotiate cipher suites that are more expensive to
the server, but that seems like a fairly weak attack.


 This alternative is surely simpler and good to consider, and I agree with your related considerations.

I would add that the TA has still to provide also N to the client, for inclusion in the extension. N is in fact required by the server for recomputing the HMAC and perform anti-replay checks on the ClientHello as suggested in the draft.

<= /div>
Well, sort of. It needs to supply the client some opaque token. T= he only
semantics of this token are between the TA and the server= .=C2=A0



The model currently described in the draft considers additional key material and related derivation, thinking also about session resumption (see also the related comment below). To this end, the design above would then additionally consider (consistently with the draft's description):

- The TA deriving K_S from K_M and N; and K_MAC from K_S
- The TA computing the HMAC using K_MAC
- The TA sending also K_S to the client

Just to touch briefly on resumption: why do you need this mechanism
at all for that? The client and server already have an assocation
so the server knows that it has a valid client without any new
assertion from the TA.

 True, although in case of resumption it is not anymore a full assertion of client's validity, but it's rather about protectin= g from replays of valid resumption requests.
<= br>
Sure, but you already have to keep a per-client database of r= esumption requests
(because the resumption counter is independent= ) and you might as well key this
by the ticket and then just reco= rd clienthellos as in the guidance for TLS 1.3
0-RTT anti-replay.=



Also, it considers Section 7.4.1.4 of RFC 5246, i.e. the same extensions SHOULD be included in case of request for session resumption.

This also led to the design in the draft (i.e., the HMAC computed by the client and the provisioning of a session key K_S), so that the client does not require to contact the TA again in case of intended session resumption.

It seems like= if this is really important, the TA could just give the client some small<= /div>
number of tokens on initial contact.

-Ek= r

=C2=A0
Consistently with the alternative design proposed above, in case of resumption request, the client can compute the HMAC itself, again only over the extension-related content, like considered by the TA in the main case for new session establishment. This would also avoid the implementation issues you mentioned below [0] for the current approach in (D)TLS 1.3.



-Ekr

[0] It also, won't work. In particular, having the client send a
MAC over the CH leads to having to zero out portions of the CH, which
is going to create implementation problems in two ways. First, it
creates a circular dependency with the TLS 1.3 PSK binder, so you'll
need to have an exception there. Second, the zero-ing out trick you
use is actually quite annoying to implement in many TLS stacks (it
would be so in NSS).

 I understand your concerns as to implementation complications. We can then build on the alternative design above to avoid them by construction.





On Sat, Jul 8, 2017 at 4:10 AM, Marco Tiloca <marco.tiloca@ri.se> wrote:
Dear all,

FYI, we have recently submitted a new draft proposing an extension for (D)TLS 1.2/1.3.

The solution described in the draft addresses Denial of Service attacks against the handshake protocol, allowing servers to promptly abort invalid session set ups.

Feedback and comments are of course very welcome. Thanks a lot!

Best regards,
/Marco

-------- Forwarded Message --------
Subjec= t: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
Date: = Wed, 28 Jun 2017 07:40:45 -0700
From: = internet-drafts@ietf.org
To: Marco Tiloca <marco.tiloca@ri.se>, Ludwig Seitz <ludwig.seitz@ri.se>, Maarten Hoeve <maarten.hoeve@encs.eu> 


A new version of I-D, draft-tiloca-tls-dos-handshake-00.txt
has been successfully submitted by Marco Tiloca and posted to the
IETF repository.

Name:		draft-tiloca-tls-dos-handshake
Revision:	00
Title:		Extension for protecting (D)TLS handshakes against Denial of Servic=
e
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-=
drafts/draft-tiloca-tls-dos-handshake-00.txt
Status:         https://datatracker.ietf.org/doc/dr=
aft-tiloca-tls-dos-handshake/
Htmlized:       https://tools.ietf.org/html/draft-tilo=
ca-tls-dos-handshake-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-tiloca-tls-dos-handshake-00


Abstract:
   This document describes an extension for TLS and DTLS to protect the
   server from Denial of Service attacks against the handshake protocol.
   The extension includes a Message Authentication Code (MAC) over the
   ClientHello message, computed by the Client through key material
   obtained from a Trust Anchor entity.  The server registered at the
   Trust Anchor derives the same key material and checks the MAC to
   determine whether continuing or aborting the handshake.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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



--=20
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://www.sics.se
https://www.sics.se/~marco/

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.

--001a11440108e6361a0553e283d0-- From nobody Sun Jul 9 07:22:49 2017 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 6F48E131545 for ; Sun, 9 Jul 2017 07:22:48 -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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WondrST7uxKS for ; Sun, 9 Jul 2017 07:22:47 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC96A12ECB3 for ; Sun, 9 Jul 2017 07:22:46 -0700 (PDT) Received: from xct104cnc.rim.net ([10.65.161.204]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2017 10:22:45 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Sun, 9 Jul 2017 10:22:45 -0400 From: Dan Brown To: Stephen Farrell , tls chair CC: "tls@ietf.org" Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQHS98sS4PlNcV5PV061JS28mdQ/iqJLjhOc Date: Sun, 9 Jul 2017 14:22:44 +0000 Message-ID: <20170709142243.8597590.72781.14916@blackberry.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 14:22:48 -0000 I agree with Stephen: this ID and all its detailed discussion should move o= ver to the Intranet ETF and/or the Internet Subverting TF (wherever such a = TF may be).=FD TLS 1.3 is already a big change. Sent from my BlackBerry 10 smartphone on the Rogers network. Original Message From: Stephen Farrell Sent: Saturday, July 8, 2017 5:17 AM To: tls chair Cc: tls@ietf.org Subject: [TLS] chairs - please shutdown wiretapping discussion... Sean/Joe, This is a request that you, as chairs, shut down the distracting wiretapping discussion, at least until DTLS1.3 is done. I have planned to spend time reading draft 21 and DTLS, but that won't happen if we keep having to fight off the latest attempts to break TLS. I'd not be surprised if I weren't the only one finding that distraction an irritating waste of time. Finishing TLS1.3 and getting DTLS1.3 on the way surely needs to not be constantly de-railed by these attempts to break TLS. Therefore I'd ask that you declare this discussion closed for at least that long (i.e until DTLS1.3 is done). I'd also ask that you not allocate agenda time for wiretapping in Prague. Thanks, S. From nobody Sun Jul 9 09:34:28 2017 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 30A57126C23 for ; Sun, 9 Jul 2017 09:34:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 jpoe5vbjbYfj for ; Sun, 9 Jul 2017 09:34:26 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 F0DBC1243F3 for ; Sun, 9 Jul 2017 09:34:25 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v69GW2At006836; Sun, 9 Jul 2017 17:34:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=RL3VybQMqeQuxW/QWrZK4hAeG5wXNGp8l20prjMKXEg=; b=hCGzHGcAPH0gF9g6EvFVe97IP3WOz4ol/WnPWiqTxXx/zjuBuPBNGiXcZ5j37uIkOkT4 g+/yp6ngBf/kl+SAFRbcHarpovs3+6gyNO8YkrVwiJkG/wOep8EdMFip3ScYytuN2UVw 4rSIbtQfE/7pMYk/efL2Fi6GFWD1+azxGbs4VvE+iDCzw+kPHJAxFOOAvp6GH+U4qnJ6 uKg3ey1It+jx8WpLUwrP9CX9ofqUOzdgA3Jb7DNfInhm14AF2oD+0pRnXuEOXvwpq9Xb HJRuWfBhmjCYQLS9fJ2DNMktGZcrFqVSfewJKhukkrcihZ0leuDtd31iRVccPuYDkfGT Iw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bjvdtmg2r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 09 Jul 2017 17:34:23 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v69GUuE0017395; Sun, 9 Jul 2017 12:34:22 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bjtqu2ecn-1; Sun, 09 Jul 2017 12:34:22 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 5900F1FC74; Sun, 9 Jul 2017 16:34:22 +0000 (GMT) To: Eric Rescorla , Marco Tiloca Cc: "tls@ietf.org" References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> <0ae67cbc-e96c-0a22-b97d-f9c3fdea8eda@ri.se> From: Benjamin Kaduk Message-ID: Date: Sun, 9 Jul 2017 11:34:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8219FCF81B038E2F66E54273" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-09_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707090291 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-09_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707090291 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 16:34:27 -0000 This is a multi-part message in MIME format. --------------8219FCF81B038E2F66E54273 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/09/2017 08:33 AM, Eric Rescorla wrote: > > > > Also, it considers Section 7.4.1.4 of RFC 5246, i.e. the same > extensions SHOULD be included in case of request for session > resumption. > > This also led to the design in the draft (i.e., the HMAC computed > by the client and the provisioning of a session key K_S), so that > the client does not require to contact the TA again in case of > intended session resumption. > > > It seems like if this is really important, the TA could just give the > client some small > number of tokens on initial contact. > I wonder if the desired properties could be obtained by having the TA be a Kerberos KDC that only issues [Kerberos tickets targetting the TLS server's Kerberos principal] to [Kerberos clients that are authorized to speak TLS to the TLS server]. Then the TLS extension could just hold a Kerberos authenticator that binds to the client random and the client can reuse the kerberos ticket until it expires. -Ben --------------8219FCF81B038E2F66E54273 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/09/2017 08:33 AM, Eric Rescorla wrote:



Also, it considers Section 7.4.1.4 of RFC 5246, i.e. the same extensions SHOULD be included in case of request for session resumption.

This also led to the design in the draft (i.e., the HMAC computed by the client and the provisioning of a session key K_S), so that the client does not require to contact the TA again in case of intended session resumption.

It seems like if this is really important, the TA could just give the client some small
number of tokens on initial contact.


I wonder if the desired properties could be obtained by having the TA be a Kerberos KDC that only issues [Kerberos tickets targetting the TLS server's Kerberos principal] to [Kerberos clients that are authorized to speak TLS to the TLS server].  Then the TLS extension could just hold a Kerberos authenticator that binds to the client random and the client can reuse the kerberos ticket until it expires.

-Ben


--------------8219FCF81B038E2F66E54273-- From nobody Sun Jul 9 12:15:43 2017 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 42171129AA8 for ; Sun, 9 Jul 2017 12:15:42 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 bH9QuIFVes3a for ; Sun, 9 Jul 2017 12:15:41 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4BC129B4D for ; Sun, 9 Jul 2017 12:15:41 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 40AE3C086D04; Sun, 9 Jul 2017 12:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=kdLt2bRtGgVETr WmHzR7d1ofwdM=; b=ZLSCMRkGdBkFuWBiJm/4MdEC4XNf1ejnLX9cHL1Wqc5tbM Vj4PmuGET2DrGimqp99DJHAWYjqRxwjjVo5ecFNeB2eS9DcsL5M28tDAVENL/W7a +ODrrdRoD44jv4NNVct0LKbm40igWG9clxRmyH+JFY7jfP8ZatP5vTJ2WzUQg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id ECD69C0028B0; Sun, 9 Jul 2017 12:15:39 -0700 (PDT) Date: Sun, 9 Jul 2017 14:15:37 -0500 From: Nico Williams To: Matthew Green Cc: tls@ietf.org Message-ID: <20170709191536.GJ3393@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 19:15:42 -0000 I don't understand this proposal at all. You absolutely can build in wiretapping capabilities into TLS server implementations without any help from the TLS protocol. (E.g., your servers could send a multicast UDP datagram for each session/connection, bearing metadata and master keys encrypted to a logging facility's public key, or in a logging session key. If UDP be insufficiently reliable for your needs, then use TCP. Yes, there's overhead in this, but it's minimal, and you already need fast logging facilities anyways.) Changing the TLS protocol to aid in wiretapping risks introducing vulnerabilities in the protocol. Nico -- From nobody Sun Jul 9 12:16:52 2017 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 9A08512700F for ; Sun, 9 Jul 2017 12:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=GQnYs+K4; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=2CuajNfw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AOeFqXnLnfn for ; Sun, 9 Jul 2017 12:16:49 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F78112ECCE for ; Sun, 9 Jul 2017 12:16:48 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3E14D9F016 for ; Sun, 9 Jul 2017 15:16:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=3eNzk+av+DWg5S8ArHq3KlgVsGI=; b=GQnYs+ K4DQKY669iqBN0q9YLubZJS9W8yoHGCRFnHGKY8C4K3MPUJvH0hglz6QRQEcwxMP X6yiK72NsQuVQ11+NAHLO8SZ+uBXDhI+dM2PxGIByF1mAeBHm4fLMHxk2qzs6qkH 1QP6NoKh4+WhJn0lh+5aKUnbc3f2GxOrhjIMU= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 33B7C9F015 for ; Sun, 9 Jul 2017 15:16:45 -0400 (EDT) Received: from mail-yw0-f173.google.com (unknown [209.85.161.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 6816F9F012 for ; Sun, 9 Jul 2017 15:16:44 -0400 (EDT) Received: by mail-yw0-f173.google.com with SMTP id x125so28695634ywa.0 for ; Sun, 09 Jul 2017 12:16:44 -0700 (PDT) X-Gm-Message-State: AIVw111RIqybWhYrtvIAZS3htjCbKVm6i6qM7PYSgkvHjVDj5XFK/SAC uTCNGhe4haa1XUuyXRi9eQ3LdJ7M9g== X-Received: by 10.129.83.5 with SMTP id h5mr10073963ywb.51.1499627803727; Sun, 09 Jul 2017 12:16:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.60.199 with HTTP; Sun, 9 Jul 2017 12:16:02 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net> From: Eric Mill Date: Sun, 9 Jul 2017 15:16:02 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Watson Ladd , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114d8b388966e50553e74e7a" X-Pobox-Relay-ID: 254B31C6-64DB-11E7-8605-EFB41968708C-82875391!pb-smtp1.pobox.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=konklone.com; h=mime-version:in-reply-to:references:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=3eNzk+av+DWg5S8ArHq3KlgVsGI=; b=2CuajNfw3zLelUnc1dUJIspWBsLLYaaQCARbKAwHQ6JJ9xJLS/V+o1dUU9Iw5U1R6F90PQSzEogwTeWbQs2SGuk+fph0UbBBwwmQeNDxkJnS5+1Y3p2C5no5yrgP5blLI5RviP8qNZzXNDGecS4xXSSdo7nvBdLBxXuiK/GPse4= Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 19:16:51 -0000 --001a114d8b388966e50553e74e7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 9, 2017 at 2:04 AM, Colm MacC=C3=A1rthaigh = wrote: > > On Sat, Jul 8, 2017 at 9:27 AM, Watson Ladd wrote= : >> >> > They also don=E2=80=99t want to install TLS proxies all over the place= . That=E2=80=99s >> a >> > large extra expense for them. >> >> Nginx exists. What's the blocker? > > > Here's how these networks work today: > > * Key servers are configured to use RSA KX, no DH. > * In some cases, all outbound (e.g. internet) connectivity is also proxie= d > via such a server. Clients are made to trust a private CA for this purpos= e. > * All data is not necessarily logged or stored somewhere, and almost > certainly not in the plain, as that would increase over-all risk. > * Admins use port-mirrors and tools like tcpdump to investigate/scan > suspicious flows from time to time, or as part of a targeted investigatio= n. > Occasionally it might also be used for debugging. The RSA keys can be use= d > to render the connections plain on demand. > * That doesn't mean that the RSA private keys are readily available, they > are often very tightly controlled. > > Migrating to proxies would: > > * Be a very big operational change. Gotta get nginx on all of the boxes, > is that even possible? > That's an oversimplification - proxying traffic should require addition of points in the middle, but shouldn't (always) require modification of the source and destination points. But yes, it would be a big operational change. I don't think the folks arguing that proxies can handle this are suggesting it's trivial to migrate in this direction. > * Completely change the access mechanisms, invalidate almost all of the > operational controls. > Why wouldn't these be improvements? (More below.) > * Probably more than double the basic compute costs associated with > encryption. > Perhaps, but also probably more than doubles the cost to attackers, by granting forward secret properties to internal traffic and by removing the number of places where keys exist that are capable of decrypting this data. * Create more sensitive environments where plaintext is floating around. > I don't see how that follows. In a previous message, Jacob Hoffman-Andrews included a great description of why it should reduce the amount of access to sensitive keys that can produce plaintext: I would also point out that retrospectively decrypting pcaps asks TLS to do double duty: as at-rest encryption in addition to transit encryption. If, instead, each TLS server shares a copy of its plaintext via a TLS connection to an encrypted storage service, the enterprise gets much better security properties. Not only does it retain forward secrecy for in-datacenter traffic, it can control the keys for at-rest data much more tightly. Instead of every TLS frontend having the keys for retrospective decryption, those keys can be limited to auditors or security team members. > That doesn't mean that these vendors/operators are owed a solution, or an > easy-to-insert more-or-less-compatible-with-today mechanism. But it does > help assess whether they are really likely to adopt TLS1.3 to begin with. > That's quite fair. However, what's so far been unstated is that it's plausible for regulatory pressure to eventually build to push regulated enterprises towards TLS 1.3 and away from 1.2. It's also quite plausible that regulatory pressure could eventually build to push agencies to use encrypted traffic with forward secret properties within their data centers, for the same reasons that it's unacceptable today to send plaintext around. This WG is responsible for making the strongest protocol possible, and it's up to the rest of the world how to use it. TLS 1.3 looks likely to be extremely widely used on the public internet. If enterprises end up staying behind on TLS 1.2 inside their networks, or making their own non-standard alternative, because they can't summon the will to get away from network-based monitoring, they're likely to face costs for doing that eventually, whether regulatory or just in the ongoing overhead of creating and maintaining non-standard tools. -- Eric > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --=20 konklone.com | @konklone --001a114d8b388966e50553e74e7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jul 9, 2017 at 2:04 AM, Colm MacC=C3=A1rthaigh <colm@allcosts.net&= gt; wrote:

On Sat, Jul 8, 2017 at 9:27 AM, Watson Ladd <watson= bladd@gmail.com> wrote:
> They also don=E2=80=99t want to install TLS proxies all over the place= .=C2=A0 That=E2=80=99s a
> large extra expense for them.

Nginx exists. What's the blocker?

Here's how these networks work= today:

* Key servers are configured to use RSA KX= , no DH.
* In some cases, all outbound (e.g. internet) connectivi= ty is also proxied via such a server. Clients are made to trust a private C= A for this purpose.=C2=A0
* All data is not necessarily logged or= stored somewhere, and almost certainly not in the plain, as that would inc= rease over-all risk.
* Admins use port-mirrors and tools like tcp= dump to investigate/scan suspicious flows from time to time, or as part of = a targeted investigation. Occasionally it might also be used for debugging.= The RSA keys can be used to render the connections plain on demand.=C2=A0<= /div>
* That doesn't mean that the RSA private keys are readily ava= ilable, they are often very tightly controlled.=C2=A0

<= div>Migrating to proxies would:

* Be a very big op= erational change. Gotta get nginx on all of the boxes, is that even possibl= e?=C2=A0

That's= an oversimplification - proxying traffic should require addition of points= in the middle, but shouldn't (always) require modification of the sour= ce and destination points.

But yes, it would be a = big operational change. I don't think the folks arguing that proxies ca= n handle this are suggesting it's trivial to migrate in this direction.=
=C2=A0
*= Completely change the access mechanisms, invalidate almost all of the oper= ational controls.=C2=A0

=
Why wouldn't these be improvements? (More below.)
=C2=A0=
* Probably more th= an double the basic compute costs associated with encryption.
=C2=A0
Perhaps, but also probably mor= e than doubles the cost to attackers, by granting forward secret properties= to internal traffic and by removing the number of places where keys exist = that are capable of decrypting this data.

* Create more sensitive environments = where plaintext is floating around.=C2=A0

I don't see how that follows. In a previous mess= age, Jacob Hoffman-Andrews included a great description of why it should re= duce the amount of access to sensitive keys that can produce plaintext:

I would also point out that retrospectively decrypting pcaps asks T= LS to do double duty: as at-rest encryption in addition to transit encrypti= on. If, instead, each TLS server shares a copy of its plaintext via a TLS c= onnection to an encrypted storage service, the enterprise gets much better = security properties. Not only does it retain forward secrecy for in-datacen= ter traffic, it can control the keys for at-rest data much more tightly. In= stead of every TLS frontend having the keys for retrospective decryption, t= hose keys can be limited to auditors or security team members.
<= /div>
=C2=A0=C2=A0
That doesn't mean that these vendors/operators are owed a soluti= on, or an easy-to-insert more-or-less-compatible-with-today mechanism.= But it does help assess whether they are really likely to adopt TLS1.3 to = begin with.=C2=A0

T= hat's quite fair. However, what's so far been unstated is that it&#= 39;s plausible for regulatory pressure to eventually build to push regulate= d enterprises towards TLS 1.3 and away from 1.2.=C2=A0

=
It's also quite plausible that regulatory pressure could eventuall= y build to push agencies to use encrypted traffic with forward secret prope= rties within their data centers, for the same reasons that it's unaccep= table today to send plaintext around.

This WG is r= esponsible for making the strongest protocol possible, and it's up to t= he rest of the world how to use it. TLS 1.3 looks likely to be extremely wi= dely used on the public internet. If enterprises end up staying behind on T= LS 1.2 inside their networks, or making their own non-standard alternative,= because they can't summon the will to get away from network-based moni= toring, they're likely to face costs for doing that eventually, whether= regulatory or just in the ongoing overhead of creating and maintaining non= -standard tools.

-- Eric


-- <= br>
Colm

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




--
--001a114d8b388966e50553e74e7a-- From nobody Sun Jul 9 13:12:29 2017 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 2583C129A92 for ; Sun, 9 Jul 2017 13:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 e3zaj8fygVRI for ; Sun, 9 Jul 2017 13:12:26 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002: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 A8655128DE5 for ; Sun, 9 Jul 2017 13:12:26 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id e201so22714902ybb.1 for ; Sun, 09 Jul 2017 13:12:26 -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=56RWHXvzkP472mcbxpBkLXhIMNZ6eMh+EllzDVrWaqM=; b=hyzgiJSLJMj+e2MzjJM+HaSB+6qhjBrc7KhpYzJgUdRVgNwx00JrzFLEPE5maDhRAi tzr3Ajv8bDaDZfdhgdnJcmZ1AgmG4xUKky6h5HpQlRyK7Z/3sj+wRKWtYCl4T0mUDPIG zIgVTWjXNIGsR3h3MjVKUjhLB4iUxDIuvIrdKWiuu9RI8aEl1KriPQo1vTj6DSl9uvMc GX9K5sWdk797ChLVMb0w7OthsD4dK0t9yh8rCCv9whNS4RPQpUoZ3NWVZUfsCbCCHGtb s+YnHpxlqFh61b5+0hsJ0WrzNqfCQJbK2MNSEaZOCYrX3xrzheUOL7BAKf+TzvxmFJfq K7RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=56RWHXvzkP472mcbxpBkLXhIMNZ6eMh+EllzDVrWaqM=; b=UEcJ9H+0yiEzo98FKApZ/AmHbjAE6Ii/XIb7PplOd/yBd08dQdB/2X9wVjpT8lYk/z D7gv2GFzHy3gj9R/FV6r7FvGx4jHNrt8o+guLULzAwsoau/hrj30GxLhECIzI3XKfwlM EiFdw6nG5bGZ1MHcJif+LPR3U+U15xHp9Ncy+oe9NvZy0vHMTDNob73nMKlChO/VzKyf eMNC7K7inrXIjXvYM3JfzHh/6EuoMTypQhyhV4F+OFFhadBEurwMYLbpV4+0ZX/NK7Nx o4nFgk+SQfY/DQk6Y7htSc53E/jF4zsjSa3lquPhMq1r38AeEZt/5JEMGtH8n3kGvwcH Q0wQ== X-Gm-Message-State: AIVw112a4y/qRCYo0sILe5rMA+ZZPeYtu6HXrsEg4WN4Mk6f5vq5FgBL ZElVnwQLLUlRWxs+agZ2ZpuuVgtHTPGD X-Received: by 10.37.68.87 with SMTP id r84mr12426292yba.229.1499631145939; Sun, 09 Jul 2017 13:12:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 9 Jul 2017 13:11:45 -0700 (PDT) In-Reply-To: References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> <0ae67cbc-e96c-0a22-b97d-f9c3fdea8eda@ri.se> From: Eric Rescorla Date: Sun, 9 Jul 2017 13:11:45 -0700 Message-ID: To: Benjamin Kaduk Cc: Marco Tiloca , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113f5f3ebf94fa0553e8155a" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 20:12:28 -0000 --001a113f5f3ebf94fa0553e8155a Content-Type: text/plain; charset="UTF-8" On Sun, Jul 9, 2017 at 9:34 AM, Benjamin Kaduk wrote: > On 07/09/2017 08:33 AM, Eric Rescorla wrote: > > > > > Also, it considers Section 7.4.1.4 of RFC 5246, i.e. the same extensions >> SHOULD be included in case of request for session resumption. >> >> This also led to the design in the draft (i.e., the HMAC computed by the >> client and the provisioning of a session key K_S), so that the client does >> not require to contact the TA again in case of intended session resumption. >> > > It seems like if this is really important, the TA could just give the > client some small > number of tokens on initial contact. > > > I wonder if the desired properties could be obtained by having the TA be a > Kerberos KDC that only issues [Kerberos tickets targetting the TLS server's > Kerberos principal] to [Kerberos clients that are authorized to speak TLS > to the TLS server]. Then the TLS extension could just hold a Kerberos > authenticator that binds to the client random and the client can reuse the > kerberos ticket until it expires. > It's actually not clear to me why this needs to be bound to the CH at all, for the reasons I indicated in my review.... -Ekr > -Ben > > > --001a113f5f3ebf94fa0553e8155a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 9, 2017 at 9:34 AM, Benjamin Kaduk <bkaduk@akamai.com&= gt; wrote:
=20 =20 =20
On 07/09/2017 08:33 AM, Eric Rescorla wrote:



Also, it considers Section 7.4.1.4 of RFC 5246, i.e. the same extensions SHOULD be included in case of request for session resumption.

This also led to the design in the draft (i.e., the HMAC computed by the client and the provisioning of a session key K_S), so that the client does not require to contact the TA again in case of intended session resumption.

It seems like if this is really important, the TA could just give the client some small
number of tokens on initial contact.


 I wonder if the desired properties could be obtained by having the TA be a Kerberos KDC that only issues [Kerberos tickets targetting the TLS server's Kerberos principal] to [Kerberos clients that are authorized to speak TLS to the TLS server].=C2=A0 Then the TLS extensio= n could just hold a Kerberos authenticator that binds to the client random and the client can reuse the kerberos ticket until it expires.

It's actually no= t clear to me why this needs to be bound to the CH at all, for the reasons = I indicated in my review....

-Ekr


-Ben



--001a113f5f3ebf94fa0553e8155a-- From nobody Sun Jul 9 13:16:23 2017 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 8671F129A92 for ; Sun, 9 Jul 2017 13:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ2NeKZx60qp for ; Sun, 9 Jul 2017 13:16:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65B9128DE5 for ; Sun, 9 Jul 2017 13:16:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 549F4BE55; Sun, 9 Jul 2017 21:16:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4W99OuQsCL8; Sun, 9 Jul 2017 21:16:16 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 20EC9BE53; Sun, 9 Jul 2017 21:16:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499631376; bh=BuokRuygetT9g06l/GjG2w+BCcBopVvjtrcCWyZAjmk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=f/8xwmSUD4tzhWYh3nXvCCnOX2FHFIC4JniwWiQB/0amqWumUpgSN1Jp5++RDLgOg G7NSfkuFFZCcA+EmrwIAm2zVUOXS2PMi7K28jOr1yMU1gItv+E727gxhjGIwj59Lep 1QQGzAQMv9Cq2IN4oseZtKdyN2xBIjhhrF21m36U= To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Eric Mill Cc: Paul Turner , "tls@ietf.org" , tls chair References: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> <634dbf72eee14617a2359f2792d4aee0@venafi.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <7556d417-e643-f7e4-5b73-94f9c17e1149@cs.tcd.ie> Date: Sun, 9 Jul 2017 21:16:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iMUIIKU4xL6rFpXOttPGL2mbfne5stoCV" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 20:16:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iMUIIKU4xL6rFpXOttPGL2mbfne5stoCV Content-Type: multipart/mixed; boundary="bBQnkr6tCsejPfHsq8Xtg0KB7iD4ngPVv"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Eric Mill Cc: Paul Turner , "tls@ietf.org" , tls chair Message-ID: <7556d417-e643-f7e4-5b73-94f9c17e1149@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <12b06aa3-f7dd-ab3e-fa4b-0f8e7ed7c6df@gmail.com> <216678f0-49df-dc88-1181-64a235033819@cs.tcd.ie> <634dbf72eee14617a2359f2792d4aee0@venafi.com> In-Reply-To: --bBQnkr6tCsejPfHsq8Xtg0KB7iD4ngPVv Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 09/07/17 07:23, Colm MacC=C3=A1rthaigh wrote: > Dismissing concerns with trivial and shallow analysis can serve to dimi= nish > the success of TLS1.3, because the users don't need to adopt it, and ca= n > end up blocking it and creating a failure of "TLS 1.3 doesn't work in X= XX > environments". Over the last ~ year and a half, since these folks have started openly bemoaning the lack of rsa key transport in tls1.3, I'd guess there've been a few hundred messages on the list on that topic alone. That is not dismissal, that's having had more than a fair hearing. As you note, it is entirely ok that they do not get what they want at the end of that IMO extremely over-extended process. Again, I would ask that the chairs chime in as to whether they would like to see this distraction/discussion be continued or stopped. S. --bBQnkr6tCsejPfHsq8Xtg0KB7iD4ngPVv-- --iMUIIKU4xL6rFpXOttPGL2mbfne5stoCV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZYo8PAAoJEC88hzaAX42ispkH/iCPStviBH2Wn4HSNbXi6G2J kZKOLwFfYc9KWIMBoBmsnurZHHXhelAsS3eMjWZrOIGfkDNLjm7ZzEao+UY+O7cG 6SaaIWPVU3NHgrbIsgatBF2BNNy/U6TXnuyOQAMlqfF+AD09oubnhBy2fhq5gDdC EWST6eQT794uKaYoXAcDjBBfFGhV5et9rn+TSPiMIncDHpKW6wE43snxDpcrzCuN t5sf9N4g1DSicpgpcp67cYGhyb4WPLqJst1A9fECSppzlpBnCKZc9mtXNlHz/tLf XIyXYxLEIuRF/vLJP3LvU8HBJ+Dgt3oroatS/4F2ZFuc8hHH3Uy8JCDenHTAD2U= =apkR -----END PGP SIGNATURE----- --iMUIIKU4xL6rFpXOttPGL2mbfne5stoCV-- From nobody Sun Jul 9 16:49:02 2017 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 BAFF8130141 for ; Sun, 9 Jul 2017 16:49:00 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 DBToE90nBUVh for ; Sun, 9 Jul 2017 16:48:59 -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 6285B131441 for ; Sun, 9 Jul 2017 16:48:59 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m84so22923160ita.0 for ; Sun, 09 Jul 2017 16:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=plxW7haAsesTB/RtH1B9/iq1mZ5gyI5HjbkTigZXcIo=; b=l6BEapbH4zb/ewa0OFIl4/KgRvwV6Akvi8aTb00bm8s8x3xuNe2G/JiPiPIlP697J4 n6VqsKkxCgerLuqKjH/VOzBlUxnDezvx9fdXw66DHuO2hEIGjAaV52XB2+Wvr1dquNIP BvtwJBuw2W/Zd2AAvtZdH91uvZ9N8pOO9Sooi1jtKkeLgDEvwChRwjsqtCl/nlvAX4jE GsNlua23gTndsKpe17d0YaUr0UI56pm33JiAvaBjQodaJEzJa2p2IGzICYx73FSSP5R9 8cE9OnQ0IQ/SFcdus5zUOR7pR2Aj6A8nzW2UBgjUXYJ2rKAlKY4143nN5gZstiCrHicR YNsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=plxW7haAsesTB/RtH1B9/iq1mZ5gyI5HjbkTigZXcIo=; b=GzZ/BDgrpIhSslH1m7YsKuIdAO6Jtt3/aQKIpXMee5eq0KKx4vlKcJsD6nlQDlYEBS CbTPcOmG6OEx1x8f5OyEKnZhrPaTFMw0VDL/oJ2szJhjkH8AY8/fwvJO0avdXBRUpueu 5B568NvH4ds34DI3x5wAtSO151XXloYrqmEWnJZoWlZExOXH6Bn/HmIbOI6rtoi5IbTF VVG555ibh5tTkX4G0QXKJb9Z5r6wvywKK39eiG0GSgyGXxJvJeTLlgoI/Biyj9HLUi5V kyAVGumwMsTMfHtTuCq+tku7Fm6xYIw0P0VAfnyIY0KAEJ4oTGeNDl7cRmpdXFBepxdf L+oA== X-Gm-Message-State: AIVw113Dlh6JNulEZmPx+S18ENtlPbGTxJz00jWgDK7N7ihUEqwZJLHX G9lZWcEYZFxCZNu2+EpXcY7AifQAdQ== X-Received: by 10.107.39.205 with SMTP id n196mr906643ion.37.1499644138791; Sun, 09 Jul 2017 16:48:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Sun, 9 Jul 2017 16:48:57 -0700 (PDT) In-Reply-To: <6F5C1F62-2A47-4BE7-AEA6-A8BAE56EDA08@vigilsec.com> References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> <201707062201.08455.davemgarrett@gmail.com> <5af19fe7273748579cb2537313667aba@usma1ex-dag1mb1.msg.corp.akamai.com> <20170707161525.ayv4z4olmo4r3h73@LK-Perkele-VII> <6F5C1F62-2A47-4BE7-AEA6-A8BAE56EDA08@vigilsec.com> From: Martin Thomson Date: Mon, 10 Jul 2017 09:48:57 +1000 Message-ID: To: Russ Housley Cc: Ilari Liusvaara , Rich Salz , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2017 23:49:01 -0000 On 8 July 2017 at 05:40, Russ Housley wrote: > The TLS WG wants to work on a a way to combine a PSK with (EC)DH after the > current specification is finished for quantum protection. TLS 1.3 allows this already. The drawback being that you need to get the PSK. At the moment, this means talking to the server once before in most cases. I thought that the PQ plan was to add a new key exchange paired with ECDH, along the lines of what was proposed in draft-whyte-qsh-tls13-01 (I recall someone asking CFRG for advice on combining of the outputs, but that doesn't seem to have gone anywhere). From nobody Mon Jul 10 05:04:39 2017 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 5BE571316F6 for ; Mon, 10 Jul 2017 05:04:38 -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 kHnqJ5aE86wK for ; Mon, 10 Jul 2017 05:04:34 -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 6BE181316E2 for ; Mon, 10 Jul 2017 05:04:34 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id v202so30802095itb.0 for ; Mon, 10 Jul 2017 05:04:34 -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:cc :content-transfer-encoding:message-id:references:to; bh=21GkM46K9ixeFAYo2YXa3ZBLNrSq6lc1nLjU/oAjciA=; b=bfpAAcrkcqY1Fu4w/J4SP74ATXnyhRR8ID6ht4RBF0LlqJMOqdi57SayDKga9j5LJC 0P23HJB5vhtTpwCWtbzL1z67B6ZXMawDoPFjk8EoiGhNWh0OshQNbB3g3nslARt2TPFM ZYtL8cK5nUd4drpr9n5JMNOdA7NrO3tA1Vz7Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=21GkM46K9ixeFAYo2YXa3ZBLNrSq6lc1nLjU/oAjciA=; b=mXWBv7WiVa9iy1iI3TXu4SChWWlUHEPbfD+9YRVg0ZIzWN4wJVNI8JBiGvxmWU9Jtq teXcWPMBYOJn52FCiFpZA/AvgKtDNmxAmhwAT4U3WD4cPoKto5XNj4fB67xw4xNkcDWd 8QjeTOgEHHG+BbBFe4SBmar1CEhATQPHOUjD7WW6HkLs6iuEb3QyPuREmUdFEYOxSoaD UQ8+uMPF5A07jhXewMRILTL3nTj3JjLG3mdcM6+qYJrN+URkou3ySk01elCz0DfLinun i0XNLCVRKLlUeo8gnLfA3VNcykZRlpvZRFCyl4zf9W1HZ1OpBNukY/IQsueJ4BMqsMga RhHw== X-Gm-Message-State: AIVw111TTy6sD1T1qTgXVtn1AZuS5blb9N17f71iH2HGNT8LssyuVTdZ dUIaSO4UBh3wIYSR X-Received: by 10.107.139.85 with SMTP id n82mr2835498iod.114.1499688273753; Mon, 10 Jul 2017 05:04:33 -0700 (PDT) Received: from [5.5.33.78] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id m27sm1153435ioi.19.2017.07.10.05.04.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 05:04:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Mon, 10 Jul 2017 08:04:26 -0400 Cc: IETF WG , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 12:04:38 -0000 Message received. Expect a response in a couple of hours. spt > On Jul 8, 2017, at 05:17, Stephen Farrell = wrote: >=20 >=20 > Sean/Joe, >=20 > This is a request that you, as chairs, shut down the distracting > wiretapping discussion, at least until DTLS1.3 is done. >=20 > I have planned to spend time reading draft 21 and DTLS, but that > won't happen if we keep having to fight off the latest attempts > to break TLS. I'd not be surprised if I weren't the only one > finding that distraction an irritating waste of time. Finishing > TLS1.3 and getting DTLS1.3 on the way surely needs to not be > constantly de-railed by these attempts to break TLS. >=20 > Therefore I'd ask that you declare this discussion closed for at > least that long (i.e until DTLS1.3 is done). >=20 > I'd also ask that you not allocate agenda time for wiretapping > in Prague. >=20 > Thanks, > S. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 10 06:54:32 2017 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 ABE47130A94 for ; Mon, 10 Jul 2017 06:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=nistgov.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 1mAX80wuAtSf for ; Mon, 10 Jul 2017 06:54:28 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0099.outbound.protection.outlook.com [23.103.201.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5006131790 for ; Mon, 10 Jul 2017 06:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MTzSPOGjmtiFnqx2NQQW6vocqQ57DYHy0HhshBq0DY0=; b=G1JMdVeeEaujvDvX/p9HxReDED0eaLOOBrezxLggdoGHc9SYUHHwIORS5BP/hsPF2irFnmiNWTlLay/qMqP7lh34RkJYZ0MFqVl+wjmugVpzlDlNUcX9zDDXgV8hSiy8bahAFmeGzStOa0SfJum1Q+nXqE6/8Al7r5qzkF86coM= Received: from DM2PR09MB0778.namprd09.prod.outlook.com (10.161.145.150) by DM2PR09MB0780.namprd09.prod.outlook.com (10.161.145.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Mon, 10 Jul 2017 13:54:22 +0000 Received: from DM2PR09MB0778.namprd09.prod.outlook.com ([fe80::29fb:f7d4:8b2f:ea68]) by DM2PR09MB0778.namprd09.prod.outlook.com ([fe80::29fb:f7d4:8b2f:ea68%18]) with mapi id 15.01.1240.020; Mon, 10 Jul 2017 13:54:22 +0000 From: "Polk, Tim (Fed)" To: "tls@ietf.org" Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQHS+YQIkhmcFWt6zaIizuL4wYEuLg== Date: Mon, 10 Jul 2017 13:54:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.23.0.170610 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.226.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR09MB0780; 7:cqU4PXy9bQfVRvK5gCYO3NhIUl2eoN/EcDSjqPUWZ8vX2KeNfzd5eb56YikU95fMAoXlKqqK2kQNU1aPcLoXD7JWr3hP49oTEb+cxhElqRutWUbHKrIGYs3/KbZmtrZJeKzMPJYvHwiV0kEiBTfMTyak5Vfsf1RulbIcfXrTWAVDPsfkuzIBAftggc255W6vUsQHT+K1vkVmSuLgjqYgbRMXTqsX1L4MUqaLKRjQN4osAv9QmtS/czzAxMBUFg+oFGyJyYSY0tXFs9JF5Uk790+MYMueAxKVWvpCZWoVEBmn08ZRuOuGMjWfJv3W9oUB8OQ4/KxLX9l4NtoGwCQedyuJAIJABKNcVpqZwkysMfpMoQte9YLujIbmZxXgNdcpEHBrXwsLcIih99TWcR3A4jBpi559z0HFbtzKOsseUpdENVQNLfIVZwJd45DgnUtyrV76MCGJOoXlFjXHIqvxdNelinME8NeW/tfxhyWX+/WqOm5g3KyRgyTPu2HYvZdw0lfUo0w2KEw+vEu1J4yqAoJbE5A3b3BuEGwGRn9eDXLor6TFnlS6zsobhayoweuv0Ov0Rqvwp7YaEagU4P/1ed23v6LHhz8MSkH8Ipqq3MFC3dzxyOm3HOec520rZ5HphEIiKoZB8MTCgRmYK764Mb+GMva6uYbeLEuuvmsh7X6mXbZGiVdNeuxoF4pEp3xEpvBQqK4Xd7ICYw4cZ7cfQ7iuZi9eP67oPTO+20UPM4oG9FCfaz5RcIdTfSUS0PZRWQuTCM2L+nKtm4c9+2VADKHlM2O05JRZJMxAXWbGJbs= x-ms-office365-filtering-correlation-id: 5d283f88-3e94-4fab-bbe1-08d4c79b2b5a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR09MB0780; x-ms-traffictypediagnostic: DM2PR09MB0780: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(26388249023172)(236129657087228)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR09MB0780; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR09MB0780; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39450400003)(39840400002)(39410400002)(6246003)(14454004)(2900100001)(5640700003)(53936002)(99286003)(2501003)(38730400002)(3660700001)(2906002)(54896002)(5250100002)(6916009)(3280700002)(110136004)(6512007)(6306002)(2351001)(6436002)(66066001)(36756003)(4001350100001)(478600001)(33656002)(6486002)(102836003)(25786009)(3846002)(50986999)(5660300001)(6116002)(229853002)(189998001)(561944003)(83506001)(8676002)(6506006)(83716003)(82746002)(1730700003)(81166006)(8936002)(54356999)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0780; H:DM2PR09MB0778.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E9640B43B3AD48D7910DF284030B5466nistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2017 13:54:22.5588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0780 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 13:54:31 -0000 --_000_E9640B43B3AD48D7910DF284030B5466nistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rmlyc3QsIEkgZG8gbm90IHNlZSB0aGlzIGFzIGEg4oCcd2lyZXRhcHBpbmcgZGlzY3Vzc2lvbuKA nSBiYXNlZCBvbiBteSByZWFkaW5nIG9mIDI4MDQsIGFsdGhvdWdoIG90aGVycyBtYXkgZGlzYWdy ZWUuDQoNClNlY29uZCwgSSBiZWxpZXZlIHRoYXQgdGhpcyBkaXNjdXNzaW9uIHNob3VsZCBnbyBm b3J3YXJkIGJhc2VkIG9uIHNldmVyYWwgcG9pbnRzOg0KDQogIDEuICB0aGlzIHByb3Bvc2FsIGRv ZXMgbm90IGludm9sdmUgYW55IGNoYW5nZXMgdG8gdGhlIGJpdHMgb24gdGhlIHdpcmUgc3BlY2lm aWVkIGluIHRoZSBUTFMgMS4zIGRvY3VtZW50DQogIDIuICB0aGlzIHByb3Bvc2FsIG9mZmVycyBz aWduaWZpY2FudGx5IGJldHRlciBzZWN1cml0eSBwcm9wZXJ0aWVzIHRoYW4gY3VycmVudCBwcmFj dGljZSAoY2VudHJhbCBkaXN0cmlidXRpb24gb2Ygc3RhdGljIFJTQSBrZXlzKQ0KICAzLiAgYWx0 ZXJuYXRpdmUgc29sdXRpb25zIHdpdGggc2lnbmlmaWNhbnRseSB3b3JzZSBzZWN1cml0eSBwcm9w ZXJ0aWVzIGFyZSBhbHNvIGZlYXNpYmxlIHVuZGVyIFRMUyAxLjMsIGFuZCBJIHdvdWxkIGxpa2Ug dG8gYXZvaWQgdGhlbSENCg0KV2Ugc2hvdWxkIGJlIGluIHRoZSBidXNpbmVzcyBvZiBkZXZlbG9w aW5nIHByYWdtYXRpYywgaW50ZXJvcGVyYWJsZSBzb2x1dGlvbnMgd2l0aCBhcHByb3ByaWF0ZSBz ZWN1cml0eSBwcm9wZXJ0aWVzLiAgQmFsYW5jaW5nIGNyeXB0b2dyYXBoaWMgc2VjdXJpdHkgd2l0 aCBvdGhlciBzZWN1cml0eSByZXF1aXJlbWVudHMgdG8gYWNoaWV2ZSBzdWNoIHNvbHV0aW9ucyBz aG91bGQgYmUgYW4gYWNjZXB0YWJsZSBwYXRoLCBhbmQgcHVyc3VpbmcgdGhpcyB3b3JrIGluIHRo ZSBUTFMgd29ya2luZyBncm91cCBnaXZlcyB0aGUgSUVURiB0aGUgYmVzdCBvcHBvcnR1bml0eSB0 byBpbmZsdWVuY2UgdGhlc2Ugc29sdXRpb25zLg0KDQoNCg0K --_000_E9640B43B3AD48D7910DF284030B5466nistgov_ Content-Type: text/html; charset="utf-8" Content-ID: <78513461EE9F2A4B8EC1E915EBE0553A@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjk5NDA2NDIxMjsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjE0MjAwODA0 MiAtNjQzMTE2ODgwIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGV4dDoiXCglMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Rmlyc3QsIEkgZG8gbm90IHNlZSB0aGlzIGFzIGEg4oCcd2lyZXRhcHBpbmcg ZGlzY3Vzc2lvbuKAnSBiYXNlZCBvbiBteSByZWFkaW5nIG9mIDI4MDQsIGFsdGhvdWdoIG90aGVy cyBtYXkgZGlzYWdyZWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5TZWNvbmQsIEkgYmVsaWV2ZSB0aGF0IHRoaXMgZGlzY3Vzc2lvbiBzaG91bGQgZ28gZm9yd2Fy ZCBiYXNlZCBvbiBzZXZlcmFsIHBvaW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij50aGlzIHByb3Bvc2FsIGRvZXMgbm90 IGludm9sdmUgYW55IGNoYW5nZXMgdG8gdGhlIGJpdHMgb24gdGhlIHdpcmUgc3BlY2lmaWVkIGlu IHRoZSBUTFMgMS4zIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij50aGlzIHByb3Bvc2FsIG9mZmVy cyBzaWduaWZpY2FudGx5IGJldHRlciBzZWN1cml0eSBwcm9wZXJ0aWVzIHRoYW4gY3VycmVudCBw cmFjdGljZSAoY2VudHJhbCBkaXN0cmlidXRpb24gb2Ygc3RhdGljIFJTQSBrZXlzKTxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+YWx0ZXJuYXRpdmUgc29sdXRpb25zIHdpdGggc2lnbmlmaWNhbnRseSB3b3JzZSBz ZWN1cml0eSBwcm9wZXJ0aWVzIGFyZSBhbHNvIGZlYXNpYmxlIHVuZGVyIFRMUyAxLjMsIGFuZCBJ IHdvdWxkIGxpa2UgdG8gYXZvaWQgdGhlbSE8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPldlIHNob3VsZCBiZSBpbiB0aGUgYnVzaW5lc3Mgb2YgZGV2ZWxv cGluZyBwcmFnbWF0aWMsIGludGVyb3BlcmFibGUgc29sdXRpb25zIHdpdGggYXBwcm9wcmlhdGUg c2VjdXJpdHkgcHJvcGVydGllcy4mbmJzcDsgQmFsYW5jaW5nIGNyeXB0b2dyYXBoaWMgc2VjdXJp dHkgd2l0aCBvdGhlciBzZWN1cml0eSByZXF1aXJlbWVudHMgdG8gYWNoaWV2ZSBzdWNoIHNvbHV0 aW9ucw0KIHNob3VsZCBiZSBhbiBhY2NlcHRhYmxlIHBhdGgsIGFuZCBwdXJzdWluZyB0aGlzIHdv cmsgaW4gdGhlIFRMUyB3b3JraW5nIGdyb3VwIGdpdmVzIHRoZSBJRVRGIHRoZSBiZXN0IG9wcG9y dHVuaXR5IHRvIGluZmx1ZW5jZSB0aGVzZSBzb2x1dGlvbnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E9640B43B3AD48D7910DF284030B5466nistgov_-- From nobody Mon Jul 10 07:16:34 2017 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 3A0F1131455 for ; Mon, 10 Jul 2017 07:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqlWRtOkS0kt for ; Mon, 10 Jul 2017 07:16:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A9E13179A for ; Mon, 10 Jul 2017 07:16:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52BD7BE5C; Mon, 10 Jul 2017 15:16:22 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbkxlpzON_eh; Mon, 10 Jul 2017 15:16:22 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1AB5FBE50; Mon, 10 Jul 2017 15:16:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499696182; bh=W3gz9wTtheTsEQqbWoeALf2VqdiGXml+2VbQL8tCyaI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UosdVN2yjQeMZRbjJonNLxKS+Gi/ilpQVpSf2X/jEK3zfI8KYC1NtIymWoRD6uo9K fHm24368xqO4GhVtQPOGJ8z5VWNDLs9nmvHJifHe5UVKgfTkY0xio/mgo8bvC7pRMr XdTw4DtcswYMBFW/S/dmM6XibyVG9tUxalzKMM2w= To: "Polk, Tim (Fed)" , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1ddda2f4-147e-27a6-eb71-f945cbbee0d6@cs.tcd.ie> Date: Mon, 10 Jul 2017 15:16:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RUiENUpOUhpbK1NAa66JVWApip0HF5Kr1" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 14:16:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RUiENUpOUhpbK1NAa66JVWApip0HF5Kr1 Content-Type: multipart/mixed; boundary="lUr2QGx9h7jEite4E40iWSpuvR6So8jIO"; protected-headers="v1" From: Stephen Farrell To: "Polk, Tim (Fed)" , "tls@ietf.org" Message-ID: <1ddda2f4-147e-27a6-eb71-f945cbbee0d6@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: In-Reply-To: --lUr2QGx9h7jEite4E40iWSpuvR6So8jIO Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, While we're waiting on Sean/Joe... :-) On 10/07/17 14:54, Polk, Tim (Fed) wrote: > First, I do not see this as a =E2=80=9Cwiretapping discussion=E2=80=9D = based on my > reading of 2804, although others may disagree. s/may/do/ Figure 3 in the draft is absolutely clearly describing an architecture for wiretapping TLS connections. And I see no way in which this scheme can avoid that problem as there is no way in which the "TLS decrypter" can be assured to be in any particular place in any network. (If one did try fix that, then you end up in the mctls muck.) >=20 > Second, I believe that this discussion should go forward based on > several points: >=20 > 1. this proposal does not involve any changes to the bits on the > wire specified in the TLS 1.3 document=20 I would assert that it substantially changes the semantics of the bits emitted by standards-track TLS implementations. With this, a client cannot know if it's application PDUs are being decrypted from the middle of the network when talking to any standards-compliant server. That basically breaks one of the most important security properties of TLS. > 2. this proposal offers > significantly better security properties than current practice > (central distribution of static RSA keys)=20 I fail to see any relevant difference in security properties between those two, never mind a significant improvement. > 3. alternative solutions > with significantly worse security properties are also feasible under > TLS 1.3, and I would like to avoid them! Yes. But that is not a justification to weaken security for standards-track implementations of TLS1.3. We should not standardise ways of doing crappy crypto would be my take. > We should be in the business of developing pragmatic, interoperable > solutions with appropriate security properties. =20 Absolutely. This proposal, being inappropriate for the standards track, should go visit /dev/null. > Balancing > cryptographic security with other security requirements to achieve > such solutions should be an acceptable path, and pursuing this work > in the TLS working group gives the IETF the best opportunity to > influence these solutions. See the raven mailing list I guess. That was specifically discussed then. S. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --lUr2QGx9h7jEite4E40iWSpuvR6So8jIO-- --RUiENUpOUhpbK1NAa66JVWApip0HF5Kr1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZY4w1AAoJEC88hzaAX42ix9AIAKXxGEsH7S5ElOp/mCO1SCRX IjG8Z17wK4mRBVEBZvh6YMBq8qxrHqA20n4NSQnWf+6c8H+SVo/zyRUHqTFaK3tx XJsBasOnGisqlFLuIYtOJ6qO4UWXP0md6vmKEN+GE2w6BdIOzr/8HTrWDjGPGI0o 1xIYKSDhGGMG2nnau27ZHsWTPm8/7vYBLRwPfnKA58aRUFLMsvkWvJz0gOSqAd3T A5n1MsprZ59wuErWJv1qq4XkXHPSSq/wkv9pAdhwMUZ7OK1kWE6Pal4HgxuhwqD1 yhvpy8T8sbfV+cadHGwdN6zp/+sdhrzsw+JTclLKXFtfM+MHuWu7XqqmNibvqv0= =SvOM -----END PGP SIGNATURE----- --RUiENUpOUhpbK1NAa66JVWApip0HF5Kr1-- From nobody Mon Jul 10 08:14:50 2017 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 CC40D1317B7 for ; Mon, 10 Jul 2017 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 UDQS4q0s9ing for ; Mon, 10 Jul 2017 08:14:48 -0700 (PDT) Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33D2131532 for ; Mon, 10 Jul 2017 08:14:47 -0700 (PDT) Received: by mail-wr0-f169.google.com with SMTP id k67so142376266wrc.2 for ; Mon, 10 Jul 2017 08:14:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=YoqERY1hHKkPGHKRO15GmteLmqmPckOQsMwCvi97IrY=; b=pg/JIXs348rCPW025DWE7dPFgStL2BnPJ0fgSvYAeU7wMkqgNLaCAuWtl6ROF1HB8U IECQdjyglXj/fhG/hU+5i4x1B/7g0fuGDeaFg3DWC+m8DEvjIUEMCW0iHmqhaciiFZMB 0RO78SYSxhX0rnd1uJproQZM3umJUvZS0HHbbou9V+5CeeaEyAF3hFdxgQ7rFqT8NOQQ BP+ycyUlElEKGSh1v5KBqWUf0t2L4jju3eDUFAdJzB0eKaKkPAqrtg88U35Or+uBfY/f N3ROa/2xpkp/1pGxMgsSIapMFLM+SWBJuVMHi5AJt0JOfnD7KMDZvdlHFoHF1Bz60nO+ 0NDA== X-Gm-Message-State: AIVw1115/krfSwFo4Lj/iQGHBnJFk/mE8bVV9NU+5TiHVmE/k+btXWeH 5nKFU71893mtC1IYnIj/NQ== X-Received: by 10.223.163.202 with SMTP id m10mr8236426wrb.197.1499699686188; Mon, 10 Jul 2017 08:14:46 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id x21sm11515115wme.24.2017.07.10.08.14.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Jul 2017 08:14:45 -0700 (PDT) Message-ID: <1499699684.2933.20.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Polk, Tim (Fed)" , "tls@ietf.org" Date: Mon, 10 Jul 2017 17:14:44 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 15:14:50 -0000 On Mon, 2017-07-10 at 13:54 +0000, Polk, Tim (Fed) wrote: > First, I do not see this as a “wiretapping discussion†based on my > reading of 2804, although others may disagree. >   > Second, I believe that this discussion should go forward based on > several points: > this proposal does not involve any changes to the bits on the wire > specified in the TLS 1.3 document > this proposal offers significantly better security properties than > current practice (central distribution of static RSA keys) > alternative solutions with significantly worse security properties > are also feasible under TLS 1.3, and I would like to avoid them! >   > We should be in the business of developing pragmatic, interoperable > solutions with appropriate security properties.  Balancing > cryptographic security with other security requirements to achieve > such solutions should be an acceptable path, and pursuing this work > in the TLS working group gives the IETF the best opportunity to > influence these solutions. Certainly, but that doesn't need to happen on this working group, nor protocols which implement similar solutions need to be called TLS. regards, Nikos From nobody Mon Jul 10 08:46:34 2017 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 45FCC129AD1 for ; Mon, 10 Jul 2017 08:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 K6BzRptgjf1B for ; Mon, 10 Jul 2017 08:46:30 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 B11F612785F for ; Mon, 10 Jul 2017 08:46:30 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id D2AB9C161F for ; Mon, 10 Jul 2017 10:46:29 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 5122EC1615; Mon, 10 Jul 2017 10:46:29 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0AB1892085; Mon, 10 Jul 2017 11:46:29 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B1A64920B6; Mon, 10 Jul 2017 11:31:10 -0400 (EDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (unknown [207.46.163.82]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Mon, 10 Jul 2017 11:31:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lD6MnwKMbfC0o5FJk6cBP/cSmk9v526KfU4k79dbpdY=; b=nq47OlRUgf6q+fRpo+JrInr3zlMtdrkFQBVS74vPHJLLDMlm6ryM5PjAqmMj7Fs3JO5zFEbPW+d945hSqcF2vhLEzlzj17HjhbUzurkXWApklNCAFfqAtVNSRei7AqYVRK84UOZgAhlniAFkz4wJ8Te05XvJT8zQHrkmZHoeUSA= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Mon, 10 Jul 2017 15:31:09 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.020; Mon, 10 Jul 2017 15:31:09 +0000 From: "Ackermann, Michael" To: "Polk, Tim (Fed)" , "tls@ietf.org" Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQHS+YQI7m7fVGNOTUGFuL/08f/fM6JNIUiQ Date: Mon, 10 Jul 2017 15:30:48 +0000 Deferred-Delivery: Mon, 10 Jul 2017 15:30:00 +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: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.39.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 20:n1tq2RkO+lKrCx5WMJEoh05WWma+gKImEys7c/zedjRNlI9eFtxqEkx6E54WRSVnn3hXtBJ+IISIrV3VYO8LoL3yTLBSS0krrAdM8k+Rb9/D32+baaNdqDP2Iqc34pV6U0JoUp4ngVUBYa0KILzKOzYWm16fXFLXLqPftp9KJbA= x-ms-office365-filtering-correlation-id: 134a3e88-bf3d-4686-255e-08d4c7a8b084 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1368; x-ms-traffictypediagnostic: CY4PR14MB1368: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(278428928389397)(72170088055959)(26388249023172)(236129657087228)(192374486261705)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1368; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39450400003)(39410400002)(377454003)(189998001)(2950100002)(33656002)(6506006)(25786009)(81166006)(8936002)(2900100001)(77096006)(3846002)(3280700002)(6116002)(102836003)(86362001)(478600001)(72206003)(3660700001)(8676002)(6666003)(790700001)(38730400002)(14454004)(54896002)(74316002)(9686003)(53936002)(76176999)(54356999)(50986999)(6246003)(229853002)(55016002)(5660300001)(6436002)(99286003)(53546010)(2501003)(561944003)(80792005)(7696004)(8656002)(2906002)(66066001)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB13688370E0544C9B84BB52A3D7A90CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2017 15:31:09.4384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368 X-TM-AS-GCONF: 00 X-VPM-MSG-ID: b1ec9b9e-2d0d-44f2-8e32-7278a0180bfb X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 881697d4-ac1c-474d-9633-77c3a49fa07a X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 15:46:33 -0000 --_000_CY4PR14MB13688370E0544C9B84BB52A3D7A90CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =21=21=21 And For the enterprise situations, we typically own, operate and manage the = involved =22Facilities=22: The Servers The Applications The Networks The Keys The Data and in Many cases the clients as well Given the above scenario, I do not understand how this can be construed = as =22Wiretapping=22. 2804 seems to make this clear. What Enterprises want in this space, is the ability to continue to have = access to their aforementioned facilities, to perform diagnostics, = monitoring and security functions. (i.e. continue to effectively operate = and manage our networks). Although I believe the Matt Green draft = proposes a very good, viable and well thought out solution for TLS 1.3, I = suspect most of us are open to different or better solutions, if such = exists or can be conceived. There seems to be good discussion, requirements and ideas on both sides of = this issue, albeit in sharp disagreement in many cases. Such = critical colloquy, with significant long term impact, should not be = prematurely terminated, IMHO. Finally an editorial comment from those of us TRYING to get Enterprises = involved at IETF. We finally have some interest and engagement from = Enterprise perspectives. Killing discussion on this issue, which is = clearly important to Enterprises, will send the message that IETF did not = really want this input or feedback. I hope this is not the case. From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Polk, Tim (Fed) Sent: Monday, July 10, 2017 9:54 AM To: tls=40ietf.org Subject: Re: =5BTLS=5D chairs - please shutdown wiretapping discussion... First, I do not see this as a =22wiretapping discussion=22 based on my = reading of 2804, although others may disagree. Second, I believe that this discussion should go forward based on several = points: 1. this proposal does not involve any changes to the bits on the wire = specified in the TLS 1.3 document 2. this proposal offers significantly better security properties than = current practice (central distribution of static RSA keys) 3. alternative solutions with significantly worse security properties = are also feasible under TLS 1.3, and I would like to avoid them=21 We should be in the business of developing pragmatic, interoperable = solutions with appropriate security properties. Balancing cryptographic = security with other security requirements to achieve such solutions should = be an acceptable path, and pursuing this work in the TLS working group = gives the IETF the best opportunity to influence these solutions. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB13688370E0544C9B84BB52A3D7A90CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

&=2343;1 = =21=21=21

 

And

For the = enterprise situations,  we typically own, operate and manage the = involved &=238220;Facilities&=238221;:

The = Servers

The = Applications

The = Networks

The = Keys

The Data
and in Many cases the clients as well

 

Given the = above scenario,  I do not understand how this can be construed as = &=238220;Wiretapping&=238221;.    2804 seems to make this = clear.

 

What = Enterprises want in this space, is the ability to continue to have access = to their aforementioned facilities,  to perform diagnostics, = monitoring and security functions.   (i.e. continue to effectively operate and manage our networks).  Although I believe the Matt Green = draft proposes a very good, viable and well thought out solution for TLS = 1.3,  I suspect most of us are open to different or better = solutions,  if such exists or can be conceived.  

There = seems to be good discussion, requirements and ideas on both sides of this = issue,  albeit in sharp disagreement in many cases.  =     Such critical colloquy,  with significant = long term impact,  should not be prematurely terminated,  IMHO. 

 

 

Finally an = editorial comment from those of us TRYING to get Enterprises involved at = IETF.   We finally have some interest and engagement from = Enterprise perspectives.     Killing discussion on = this issue,  which is clearly important to Enterprises, will send the message that = IETF did not really want this input or = feedback.      I hope this is not the case. 

 

From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Polk, Tim (Fed)
Sent: Monday, July 10, 2017 9:54 AM
To: tls=40ietf.org
Subject: Re: =5BTLS=5D chairs - please shutdown wiretapping = discussion...

 

First, I = do not see this as a &=238220;wiretapping discussion&=238221; based on my = reading of 2804, although others may disagree.

 

Second, I = believe that this discussion should go forward based on several = points:

  1. this proposal does not = involve any changes to the bits on the wire specified in the TLS 1.3 = document
  2. this proposal offers significantly better = security properties than current practice (central distribution of static = RSA keys)
  3. alternative solutions with significantly = worse security properties are also feasible under TLS 1.3, and I would = like to avoid them=21

 

We should = be in the business of developing pragmatic, interoperable solutions with = appropriate security properties.  Balancing cryptographic security = with other security requirements to achieve such solutions should be an acceptable path, and pursuing this work in the TLS working = group gives the IETF the best opportunity to influence these = solutions.

 

 

 


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB13688370E0544C9B84BB52A3D7A90CY4PR14MB1368namp_-- From nobody Mon Jul 10 09:42:18 2017 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 DA8381317DA for ; Mon, 10 Jul 2017 09:42:16 -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 1V3x_tfe8zK4 for ; Mon, 10 Jul 2017 09:42:15 -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 CA29F1317D7 for ; Mon, 10 Jul 2017 09:42:15 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id v193so38148505ywg.2 for ; Mon, 10 Jul 2017 09:42:15 -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=JpCnTP4I++yxKyHC4OSIUNZL+P5qu39DdPapdwhveeM=; b=Xh9dyJ6RLpPeclzPs2Sgas0vbVMmPfGWtjmihiuxT9oZDdlRjffOOX/gcwVq6oxZNH e4iX9e66fyBmoUpN/3oV8NteYpUCnrTS4CQDVCsV64rov/xaquxdu9GzPtBtsJoxupTb 0B7ByQOER2BuKyBk378hN9Jw4JwA2abJOrYJ73sL2yOZYM2uksoKt9XywrJXUbO/G8s5 9XMRLaI295ci7oaeDKhmW8lKkTofjf2G1UXaZeAsA1cYHX//C8Uv5L5M1SsyVW6MYetH 8EwbKlF1s3Y/u/vA8FwgNtGxpH1M7G2Lxs4g5Ry2PkIqTncKohU6+CcAmzq+sCf/vXwX juog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JpCnTP4I++yxKyHC4OSIUNZL+P5qu39DdPapdwhveeM=; b=JVFe/pzlFGRQ91xza9XOQsM/gDYqgdoFG8cSn+uyjsC5dXHOAyFfH0zK2eF5uACUdj 0hV6JZfTCtYBZ/AfwBuJ1ITKjsYWnu4xpHTCC2o6QnMV/RGQ5ARbDljsbNIbbZIo4Y7J JrKs3MpeAbDuGZ5Zr+vGmM1OFuHI4JUfG2jnBzeVrjo7m4YZOMzhSztizeK6I+qE758J b3/WtwyC0L+qyfEAu1MgW/djaTMuWqdJ/tItLa5PbzzfJiYBB4wt61QxDtqMdT7G3IVV L3X2inxlICKSh7C63CgzObarbaXTrTrfD1ZJWGBjb726phjmG09VtAODVLN5mtodl0mZ 12Kg== X-Gm-Message-State: AIVw112Jc9Ltu94CNe/rqRhnnU9JpeUa9uw1gprXYjd44OA514bJ1C44 y7gYACpbrn1UhHKQjSmhRd1J4PDWyQ2c X-Received: by 10.129.189.17 with SMTP id b17mr1570339ywi.182.1499704934948; Mon, 10 Jul 2017 09:42:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.27.4 with HTTP; Mon, 10 Jul 2017 09:42:14 -0700 (PDT) In-Reply-To: <1499699684.2933.20.camel@redhat.com> References: <1499699684.2933.20.camel@redhat.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 10 Jul 2017 09:42:14 -0700 Message-ID: To: Nikos Mavrogiannopoulos Cc: "Polk, Tim (Fed)" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e08250514eacb1a0553f943cf" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 16:42:17 -0000 --089e08250514eacb1a0553f943cf Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 8:14 AM, Nikos Mavrogiannopoulos wrote: > Certainly, but that doesn't need to happen on this working group, nor > protocols which implement similar solutions need to be called TLS. > I'll belabor this point: rather than thinking about what these providers are owed, which is nothing, it is better to think about what is best for TLS overall. Selfishly, I have a strong preference to see TLS1.3 succeed and that within a matter of years, we no longer have to support TLS1.2 or earlier versions. If some networks and operators feel that they can't feasibly use TLS1.3, they're very likely to stay on the older versions. We could consider brinkmanship; and see who blinks first if we try to disable the older versions anyway, but that's a gambit that often makes hostages out of innocent users, and can end up serving to taint TLS1.3 with reliability issues and hold back its adoption. It's clear that there is a strong distaste here for the kind of MITM being talked about, and many wish not to give it any kind of stamp of approval within the standard; that that itself would also taint TLS1.3 with security concerns. Proxies are proposed as a work-around instead, as it avoids any changes to protocol. But this seems like cutting our noses off to spite our faces. Proxies tend to be always-on and render plaintext much more accessible than a tcpdump tap. Proxies are also inline, read-write, and subject to exploit in a worse way than a tcpdump tap (which can be network isolated). In real security terms, I absolutely buy that proxies would be worse for overall security and all of the properties that TLS is supposed to provide, in some environments. That would seem like a bizarre conclusion. -- Colm --089e08250514eacb1a0553f943cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 10, 2017 at 8:14 AM, Nikos Mavrogiannopoulos <= span dir=3D"ltr"><n= mav@redhat.com> wrote:
Certainly, but that doesn&#= 39;t need to happen on this working group, nor
protocols which implement similar solutions need to be called TLS.

I'll belabor this point: rather than thinki= ng about what these providers are owed, which is nothing, it is better to t= hink about what is best for TLS overall. Selfishly, I have a strong prefere= nce to see TLS1.3 succeed and that within a matter of years, we no longer h= ave to support TLS1.2 or earlier versions.=C2=A0

I= f some networks and operators feel that they can't feasibly use TLS1.3,= they're very likely to stay on the older versions. We could consider b= rinkmanship; and see who blinks first if we try to disable the older versio= ns anyway, but that's a gambit that often makes hostages out of innocen= t users, and can end up serving to taint TLS1.3 with reliability issues and= hold back its adoption.

It's clear that there= is a strong distaste here for the kind of MITM being talked about, and man= y wish not to give it any kind of stamp of approval within the standard; th= at that itself would also taint TLS1.3 with security concerns. Proxies are = proposed as a work-around instead, as it avoids any changes to protocol. Bu= t this seems like cutting our noses off to spite our faces. Proxies tend to= be always-on and render plaintext much more accessible than a tcpdump tap.= Proxies are also inline, read-write, and subject to exploit in a worse way= than a tcpdump tap (which can be network isolated). In real security terms= , I absolutely buy that proxies would be worse for overall security and all= of the properties that TLS is supposed to provide, in some environments. T= hat would seem like a bizarre conclusion.

--=C2=A0=
Colm
--089e08250514eacb1a0553f943cf-- From nobody Mon Jul 10 09:58:04 2017 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 C06501317E4 for ; Mon, 10 Jul 2017 09:58:03 -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 usVHVELjHKa1 for ; Mon, 10 Jul 2017 09:58:02 -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 EE9141317E0 for ; Mon, 10 Jul 2017 09:58:01 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m84so46149408ita.0 for ; Mon, 10 Jul 2017 09:58:01 -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:cc :content-transfer-encoding:message-id:references:to; bh=j3IFFZ/WERJOZ4Sues63XezmJJcDnqJHHUtAWBKBRD4=; b=miXt2Z90fth1+skfy0NkGFDgt+PlGBfDuqyZlCMabtvGAimtHdZZw07tf105PejQT8 0pt0WLbwbQqETY1dmu8RXyN7j53KT08hjmY4swhJK5/S1M5oWmZd5vaM5EsV4yZs6vSC nqdZif5kjQEYaZxpYIOxVSe0EaJkej4sE5R2I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j3IFFZ/WERJOZ4Sues63XezmJJcDnqJHHUtAWBKBRD4=; b=XHBXdgtW8AzAcLl6F7T7xIxjWyFnSDcIRsuVbYo/eHMI440TULfCQeR9qTYJ3Wlmi5 tXr4H/Uia2VtXoGHnCzvAnt41mWfcMdBHovxZaTewKgk5sV/SVQbDTdmppq4gvHnoI2w UJYF2PWiZFOqFFN6llriAexMOuLiuaglI2UF5SdaE5wkzStRqXfhbrhXfmGkCplj9Fwa LBO4Uz4RiCjndLjoTtcidfEsojuY6TNZQLVxF9uupO5CxL0xeVDwRAfDDkqnB5LztMUU NCDYZ2srNPHFrygJ5D2VVfVKxScbEtmouuIWVXGrmGMPNWS18ID4ZeSyfwLQbguAsO/u DMtg== X-Gm-Message-State: AIVw112hi5EbxmYO/Dn3XWcb40cqUx2jRVf1KlGRJjv3mt/BTUzQWaA/ TmdK39uebKqnxukCtG5B9g== X-Received: by 10.36.190.135 with SMTP id i129mr12243576itf.105.1499705881325; Mon, 10 Jul 2017 09:58:01 -0700 (PDT) Received: from [5.5.33.88] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id 189sm4217690itl.11.2017.07.10.09.57.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 09:58:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Mon, 10 Jul 2017 12:57:57 -0400 Cc: TLS Chairs , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <867B8F06-63F2-4EDF-9B92-CB2EF7F08D30@sn3rd.com> References: To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 16:58:04 -0000 Stephen, After some discussion amongst the chairs, we have decided to not shut = down the discussion about draft-green-tls-static-dh-in-tls13. We are = not shutting down this discussion because this topic is relevant to the = constituents on both sides of the issue in the working group and there = is a concrete proposal to discuss. Now that we know the authors are = going to ask for WG adoption, the resulting working group's consensus or = lack of consensus on this approach will be useful information for other = discussions that will happen in the broader IETF community regardless of = the outcome. Further, we intend for consensus on the issue to be called = quickly. We also do not believe that this discussion is derailing the TLS1.3 = draft, we are consistently surprised by the WG=E2=80=99s bandwidth and = the draft is out for a 2nd targeted WGLC. As far as DTLS1.3, the = specification is coming along but is not at a critical point where we = believe this discussion will greatly detract from its development. J&S > On Jul 8, 2017, at 05:17, Stephen Farrell = wrote: >=20 >=20 > Sean/Joe, >=20 > This is a request that you, as chairs, shut down the distracting > wiretapping discussion, at least until DTLS1.3 is done. >=20 > I have planned to spend time reading draft 21 and DTLS, but that > won't happen if we keep having to fight off the latest attempts > to break TLS. I'd not be surprised if I weren't the only one > finding that distraction an irritating waste of time. Finishing > TLS1.3 and getting DTLS1.3 on the way surely needs to not be > constantly de-railed by these attempts to break TLS. >=20 > Therefore I'd ask that you declare this discussion closed for at > least that long (i.e until DTLS1.3 is done). >=20 > I'd also ask that you not allocate agenda time for wiretapping > in Prague. >=20 > Thanks, > S. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 10 10:01:40 2017 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 B2D661274D2 for ; Mon, 10 Jul 2017 10:01:38 -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 WkgzfvjsLcvu for ; Mon, 10 Jul 2017 10:01:36 -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 1C5D31317D3 for ; Mon, 10 Jul 2017 10:01:36 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id h22so66993872lfk.3 for ; Mon, 10 Jul 2017 10:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GfTDIXka1nSqMyRuLyDxHEy4M6/i87iWc7m7E/DtiYI=; b=BFe9Bqp/JWE5zpRV0S7aH/uEjtGeI4PG1OoAnPdEdstErwHBms04pKfSt08fNiEc+V ye4d0mP4huDbdNj98WYogU3JE+vVJmWh2SrSEbHS+GdjFAJYtiRE4nvQuIj5C69fASPg 5p1L+9YYsDaJJW4nrh+fSEMo+KcycpR9YTblod8DdLMB9MZhy00tFEAuFBTGmb3vWq5u t+1gfZTvivzGAWlZE36RcI1PTlBCfi1/aCKbuabtz8xgj9lfRFcvNQ8TR8SBgeU17ZMl NZBq5lkbxJfOo05vb7zufqc3bCrgeZhjg3zdvQQ496/vcH2gvuAfoQ7oeIx25v0kZAys S/lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GfTDIXka1nSqMyRuLyDxHEy4M6/i87iWc7m7E/DtiYI=; b=QM+XTuepfoxsqOWoF06+1BKpJ36mXSXMxRx3gYaOjsLteQfvk7aCCeFP4cpMvsbDvb Nu5jGzj8fnZS8mLxweCMZmxhhm0PGHq0PQCNN0mvqStUL9uZf8blmqqDVxDL+m9Sl/xP +QjMHnEJN84MP+neTjmhWHpcIxHaRylZT0yx7IHIncVoIuj/P8Bn70mpGeOcaD6QJxyj ezO2hx4vn2xqOqbcVZFLLOfRBSF4zm93IywtMYprScsfrCZ7Bw77UFBaH3zdlSOmGGZe ht9SdwWaAjctmN3R/Azru7U6QUnSHSzy/1qOoTkjyJ6w2TRXWz4vjNQof60pBffAPzxr oIKA== X-Gm-Message-State: AIVw112sgelGr3YJb6Wj+jb4LsZ/5dS5PybyWafQjc/zdljObJjPMIUS eiDGN+k6Ma6GLGmjSso= X-Received: by 10.80.134.217 with SMTP id 25mr12307240edu.73.1499706094402; Mon, 10 Jul 2017 10:01:34 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g24sm5487561edh.20.2017.07.10.10.01.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 10:01:33 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_980B561B-2E0A-4BCA-B737-326C868F1DFA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Jul 2017 20:01:32 +0300 In-Reply-To: <1ddda2f4-147e-27a6-eb71-f945cbbee0d6@cs.tcd.ie> Cc: "Polk, Tim (Fed)" , "tls@ietf.org" To: Stephen Farrell References: <1ddda2f4-147e-27a6-eb71-f945cbbee0d6@cs.tcd.ie> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 17:01:39 -0000 --Apple-Mail=_980B561B-2E0A-4BCA-B737-326C868F1DFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2017, at 17:16, Stephen Farrell = wrote: >=20 >=20 >> 2. this proposal offers >> significantly better security properties than current practice >> (central distribution of static RSA keys) >=20 > I fail to see any relevant difference in security properties > between those two, never mind a significant improvement. I can see one way in which it is worse. With static RSA keys, you can configure the server to use only PFS = ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS, = you need to switch to RSA ciphersuites, and that would be obvious to any = client. In fact, I think today a server would stick out if it only = supported RSA ciphersuites. There is no way to know that a server is doing what it says in the = draft. It=E2=80=99s completely opaque to the client. However, in both cases the server does get FS. As long as the server has = not enabled RSA ciphersuites or exportable private key shares, any = recorded TLS stream is safe even if the attacker later gets the private = key. Yoav --Apple-Mail=_980B561B-2E0A-4BCA-B737-326C868F1DFA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZY7LsAAoJELhJCxUKWMyZN5cH/jg0eznf12JEl51oysO8fyCG I/NnpGmyW/D/l2HHYUczDYgnY3R2HPkcDmHjGuZ9pRRLpZ5559Vo2qsfOGHxgIkF iq4hZeG4/fp0JFQu24xUht/ZwjIW4gXWHN/QKmGYXhq8F595sqSIYbX9jxjO44/v 9OJi/JJYAjZUQj551Kk4MBrxtpoFAYVj6LHWRt0X5pQxf++Z3X+4oDGjS4A5F20d PuwHYbf56aLneG5kFFr9DIlQcfghsF+3PivuvuYaxyzj5UZA8qO4oIb3ENDhlSCM 4P77EDu6gReaPhJalh6Mm29iGS3v51tn3k1fS7lYx6py5VOjtbK5pRt91ku001U= =apdM -----END PGP SIGNATURE----- --Apple-Mail=_980B561B-2E0A-4BCA-B737-326C868F1DFA-- From nobody Mon Jul 10 11:19:41 2017 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 7D63D12EC29 for ; Mon, 10 Jul 2017 11:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 oSo16d9aBmHM for ; Mon, 10 Jul 2017 11:19:36 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49E8129B34 for ; Mon, 10 Jul 2017 11:19:35 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 0B691222137 for ; Mon, 10 Jul 2017 18:19:31 +0000 (UTC) Received: from [193.10.66.141] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 10 Jul 2017 20:19:33 +0200 Message-ID: <5963C530.8050006@ri.se> Date: Mon, 10 Jul 2017 20:19:28 +0200 From: Marco Tiloca User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> <0ae67cbc-e96c-0a22-b97d-f9c3fdea8eda@ri.se> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v0xvWCOLBJM5CjthKVJfWEL4xawsaFx6t" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=Nc2W7yL4 c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=G3gG6ho9WtcA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=uTM5gQLEAAAA:8 a=xPT6tdSuAAAA:8 a=uxq6SuWmm3nDubggvMEA:9 a=RSeV_S3H1Wjpn9iR:21 a=J40vvy4IRSSs2e0y:21 a=pILNOxqGKmIA:10 a=pGLkceISAAAA:8 a=0l6pUpVs_o8m5caASMUA:9 a=vs8Zy0KiOzwXt3uz:21 a=mFkR6ZQEfWJRebT5:21 a=vyadcpN6l_XeroTa:21 a=_W_S_7VecoQA:10 a=in1WbxyIa6XI09KtdZ0A:9 a=ONNS8QRKHyMA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=X0a8wEfk66sNBbu13Lvv:22 a=80PJfYVSYmV_jLpvUEnt:22 a=6kGIvZw6iX1k4Y-7sg4_:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 18:19:39 -0000 --v0xvWCOLBJM5CjthKVJfWEL4xawsaFx6t Content-Type: multipart/alternative; boundary="------------010807020100020309060604" This is a multi-part message in MIME format. --------------010807020100020309060604 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017-07-09 15:33, Eric Rescorla wrote: > > > On Sun, Jul 9, 2017 at 2:44 AM, Marco Tiloca > wrote: > > Hello Eric, > > Thanks for your good comments! > > Please, see my answers inline. > > Best, > /Marco > > On 2017-07-08 16:45, Eric Rescorla wrote: >> Document: draft-tiloca-tls-dos-handshake-00.txt >> >> I'm trying to understand the threat model and operating model this= >> is designed for. Let's start with the threat model. The anti-DoS >> mechanisms in DTLS are specifically oriented towards attackers >> who are not on-path, because on-path attackers can, as you >> say, obtain the HRR/HVR. >> >> You say: >> >> DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optio= nal >> Cookie exchange as possible solution to mitigate this Denial of= >> Service attack. While this makes the attack more complicated t= o >> mount, a well determined and resourceful adversary able to spoo= f >> valid IP addresses can still successfully perform it, by >> intercepting >> the possible server response including the Cookie and then >> echoing it >> in the second ClientHello. This is particularly doable in >> case the >> handshake is not based on Pre-Shared Key exchange modes. >> >> I take from this that your assumed threat model is an attacker who= is >> minimally a man-on-the-side (i.e., able to read traffic and >> inject his >> own but not block) and maximally a full active attacker able to bl= ock >> data. Is that correct? >> > > Yes, correct. > >> >> Depending on the specific protocol version and the key >> establishment >> mode used in the handshake, the attack impact can range from >> single >> replies triggered by invalid ClientHello messages, to the serve= r >> performing advanced handshake steps with consequent setup of >> invalid >> half-open sessions. Especially if performed in a large-scale a= nd >> distributed manner, this attack can thwart performance and serv= ice >> availability of (D)TLS servers. Moreover, it can be particular= ly >> effective in application scenarios where servers are resource- >> constrained devices running DTLS over low-power, low bandwidth = and >> lossy networks. >> >> It seems like the attack you are considering is one in which the >> attacker generates DTLS handshakes and then forces the DTLS server= to >> either perform computations or hold state open (e.g., by doing a >> handshake or a partial handshake and then stopping) Is that correc= t? >> > > Yes, correct. > >> Assuming I am correct, the design you describe here seems much mor= e >> complicated than necessary [0]. Consider the simpler design: >> >> - The client contacts the TA >> - TA generates a new value C =3D HMAC(k_M, N) and sends that to th= e >> client >> - the client inserts C in the ClientHello. >> >> The major downside is that this allows an on-path attacker to >> steal C and >> put it in their own CH, but so what? The attacker is still rate >> limited >> by the number of valid clients, and (at least) a fully active >> attacker >> doesn't need to substitute their own handshake messages for the va= lid >> clients because they can force the server to perform computations >> by playing the client messages and leave the server in a half-open= >> state by blocking some client messages. I suppose you could argue >> that they could negotiate cipher suites that are more expensive to= >> the server, but that seems like a fairly weak attack. >> > > This alternative is surely simpler and good to consider, and I > agree with your related considerations. > > I would add that the TA has still to provide also N to the client, > for inclusion in the extension. N is in fact required by the > server for recomputing the HMAC and perform anti-replay checks on > the ClientHello as suggested in the draft. > > > Well, sort of. It needs to supply the client some opaque token. The onl= y > semantics of this token are between the TA and the server.=20 > I agree. > > > The model currently described in the draft considers additional > key material and related derivation, thinking also about session > resumption (see also the related comment below). To this end, the > design above would then additionally consider (consistently with > the draft's description): > > - The TA deriving K_S from K_M and N; and K_MAC from K_S > - The TA computing the HMAC using K_MAC > - The TA sending also K_S to the client > >> Just to touch briefly on resumption: why do you need this mechanis= m >> at all for that? The client and server already have an assocation >> so the server knows that it has a valid client without any new >> assertion from the TA. > > True, although in case of resumption it is not anymore a full > assertion of client's validity, but it's rather about protecting > from replays of valid resumption requests. > > > Sure, but you already have to keep a per-client database of resumption > requests > (because the resumption counter is independent) and you might as well > key this > by the ticket and then just record clienthellos as in the guidance for > TLS 1.3 > 0-RTT anti-replay. > Ok, we can rather refer to the 0-RTT anti-replay guidance and then have the main design simpler. > > > Also, it considers Section 7.4.1.4 of RFC 5246, i.e. the same > extensions SHOULD be included in case of request for session > resumption. > > This also led to the design in the draft (i.e., the HMAC computed > by the client and the provisioning of a session key K_S), so that > the client does not require to contact the TA again in case of > intended session resumption. > > > It seems like if this is really important, the TA could just give the > client some small > number of tokens on initial contact. Sounds good to me. Best, /Marco > > -Ekr > > =20 > > Consistently with the alternative design proposed above, in case > of resumption request, the client can compute the HMAC itself, > again only over the extension-related content, like considered by > the TA in the main case for new session establishment. This would > also avoid the implementation issues you mentioned below [0] for > the current approach in (D)TLS 1.3. > > >> >> -Ekr >> >> [0] It also, won't work. In particular, having the client send a >> MAC over the CH leads to having to zero out portions of the CH, wh= ich >> is going to create implementation problems in two ways. First, it >> creates a circular dependency with the TLS 1.3 PSK binder, so you'= ll >> need to have an exception there. Second, the zero-ing out trick yo= u >> use is actually quite annoying to implement in many TLS stacks (it= >> would be so in NSS). > > I understand your concerns as to implementation complications. We > can then build on the alternative design above to avoid them by > construction. > > >> >> >> >> On Sat, Jul 8, 2017 at 4:10 AM, Marco Tiloca > > wrote: >> >> Dear all, >> >> FYI, we have recently submitted a new draft proposing an >> extension for (D)TLS 1.2/1.3. >> >> The solution described in the draft addresses Denial of >> Service attacks against the handshake protocol, allowing >> servers to promptly abort invalid session set ups. >> >> Feedback and comments are of course very welcome. Thanks a lot= ! >> >> Best regards, >> /Marco >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for >> draft-tiloca-tls-dos-handshake-00.txt >> Date: Wed, 28 Jun 2017 07:40:45 -0700 >> From: internet-drafts@ietf.org >> >> To: Marco Tiloca >> , Ludwig Seitz >> , Maarten >> Hoeve >> >> >> >> A new version of I-D, draft-tiloca-tls-dos-handshake-00.txt >> has been successfully submitted by Marco Tiloca and posted to = the >> IETF repository. >> >> Name: draft-tiloca-tls-dos-handshake >> Revision: 00 >> Title: Extension for protecting (D)TLS handshakes against Den= ial of Service >> Document date: 2017-06-28 >> Group: Individual Submission >> Pages: 12 >> URL: https://www.ietf.org/internet-drafts/draft-til= oca-tls-dos-handshake-00.txt >> Status: https://datatracker.ietf.org/doc/draft-tiloca-= tls-dos-handshake/ >> Htmlized: https://tools.ietf.org/html/draft-tiloca-tls-d= os-handshake-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ti= loca-tls-dos-handshake-00 >> >> >> Abstract: >> This document describes an extension for TLS and DTLS to pr= otect the >> server from Denial of Service attacks against the handshake= protocol. >> The extension includes a Message Authentication Code (MAC) = over the >> ClientHello message, computed by the Client through key mat= erial >> obtained from a Trust Anchor entity. The server registered= at the >> Trust Anchor derives the same key material and checks the M= AC to >> determine whether continuing or aborting the handshake. >> >> = =20 >> >> >> 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.iet= f.org . >> >> The IETF Secretariat >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >> > > --=20 > Marco Tiloca, PhD > Research Institutes of Sweden > RISE ICT/SICS > Isafjordsgatan 22 / Kistag=E5ngen 16 > SE-164 40 Kista (Sweden) > Phone: +46 (0)70 60 46 501 > https://www.sics.se > https://www.sics.se/~marco/ > > The RISE institutes Innventia, SP and Swedish ICT > have merged in order to become a stronger research > and innovation partner for businesses and society. > > SICS Swedish ICT AB, has now changed name to RISE SICS AB. > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistag=E5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se https://www.sics.se/~marco/ The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society. SICS Swedish ICT AB, has now changed name to RISE SICS AB. --------------010807020100020309060604 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017-07-09 15:33, Eric Rescorla wrote:


On Sun, Jul 9, 2017 at 2:44 AM, Marc= o Tiloca <marc= o.tiloca@ri.se> wrote:
Hello Eric,

Thanks for your good comments!

Please, see my answers inline.

Best,
/Marco

On 2017-07-08 16:45, Eric Rescorla wrote:
Document: draft-tiloca-tls-dos-handshake-= 00.txt

I'm trying to understand the threat model and operating model this
is designed for. Let's start with the threat model. The anti-DoS
mechanisms in DTLS are specifically oriented towards attackers
who are not on-path, because on-path attackers can, as you
say, obtain the HRR/HVR.

You say:

=A0 =A0DTLS 1.2 as well as both TLS 1.3 and DT= LS 1.3 provide the optional
=A0 =A0Cookie exchange as possible solution to= mitigate this Denial of
=A0 =A0Service attack.=A0 While this makes the= attack more complicated to
=A0 =A0mount, a well determined and resourcefu= l adversary able to spoof
=A0 =A0valid IP addresses can still successful= ly perform it, by intercepting
=A0 =A0the possible server response including = the Cookie and then echoing it
=A0 =A0in the second ClientHello.=A0 This is particularly doable in case the
=A0 =A0handshake is not based on Pre-Shared Ke= y exchange modes.

I take from this that your assumed threat model is an attacker who is
minimally a man-on-the-side (i.e., able to read traffic and inject his
own but not block) and maximally a full active attacker able to block
data. Is that correct?


 Yes, correct.


=A0 =A0Depending on the specific protocol vers= ion and the key establishment
=A0 =A0mode used in the handshake, the attack impact can range from single
=A0 =A0replies triggered by invalid ClientHell= o messages, to the server
=A0 =A0performing advanced handshake steps wit= h consequent setup of invalid
=A0 =A0half-open sessions.=A0 Especially if performed in a large-scale and
=A0 =A0distributed manner, this attack can thw= art performance and service
=A0 =A0availability of (D)TLS servers.=A0 More= over, it can be particularly
=A0 =A0effective in application scenarios wher= e servers are resource-
=A0 =A0constrained devices running DTLS over low-power, low bandwidth and
=A0 =A0lossy networks.

It seems like the attack you are considering is one in which the
attacker generates DTLS handshakes and then forces the DTLS server to
either perform computations or hold state open (e.g., by doing a
handshake or a partial handshake and then stopping) Is that correct?


 Yes, correct.

Assuming I am correct, the design you describe here seems much more
complicated than necessary [0]. Consider the simpler design:

- The client contacts the TA
- TA generates a new value C =3D HMAC(k_M, N) and sends that to the
=A0 client
- the client inserts C in the ClientHello.

The major downside is that this allows an on-path attacker to steal C and
put it in their own CH, but so what? The attacker is still rate limited
by the number of valid clients, and (at least) a fully active attacker
doesn't need to substitute their own handshake messages for the valid
clients because they can force the server to perform computations
by playing the client messages and leave the server in a half-open
state by blocking some client messages. I suppose you could argue
that they could negotiate cipher suites that are more expensive to
the server, but that seems like a fairly weak attack.


 This alternative is surely simpler and good to consider, and I agree with your related considerations.
I would add that the TA has still to provide also N to the client, for inclusion in the extension. N is in fact required by the server for recomputing the HMAC and perform anti-replay checks on the ClientHello as suggested in the draft.

Well, sort of. It needs to supply the client some opaque token. The only
semantics of this token are between the TA and the server.=A0


I agree.



The model curren= tly described in the draft considers additional key material and related derivation, thinking also about session resumption (see also the related comment below). To this end, the design above would then additionally consider (consistently with the draft's description):

- The TA deriving K_S from K_M and N; and K_MAC from K_S<= br> - The TA computing the HMAC using K_MAC
- The TA sending also K_S to the client<= br>
Just to touch briefly on resumption: why do you need this mechanism
at all for that? The client and server already have an assocation
so the server knows that it has a valid client without any new
assertion from the TA.

 True, although in case of resumption it is not anymore a full assertion of client's validity, but it's rather about protecting from replays of valid resumption requests.

Sure, but you already have to keep a per-client database of resumption requests
(because the resumption counter is independent) and you might as well key this
by the ticket and then just record clienthellos as in the guidance for TLS 1.3
0-RTT anti-replay.


Ok, we can rather refer to the 0-RTT anti-replay guidance and then have the main design simpler.



Also, it conside= rs Section 7.4.1.4 of RFC 5246, i.e. the same extensions SHOULD be included in case of request for session resumption.

This also led to the design in the draft (i.e., the HMAC computed by the client and the provisioning of a session key K_S), so that the client does not require to contact the TA again in case of intended session resumption.

It seems like if this is really important, the TA could just give the client some small
number of tokens on initial contact.

Sounds good to me.

Best,
/Marco


-Ekr

=A0
Consistently wit= h the alternative design proposed above, in case of resumption request, the client can compute the HMAC itself, again only over the extension-related content, like considered by the TA in the main case for new session establishment. This would also avoid the implementation issues you mentioned below [0] for the current approach in (D)TLS 1.3.



-Ekr

[0] It also, won't work. In particular, having the client send a
MAC over the CH leads to having to zero out portions of the CH, which
is going to create implementation problems in two ways. First, it
creates a circular dependency with the TLS 1.3 PSK binder, so you'll
need to have an exception there. Second, the zero-ing out trick you
use is actually quite annoying to implement in many TLS stacks (it
would be so in NSS).

 I understand your concerns as to implementation complications. We can then build on the alternative design above to avoid them by construction.





On Sat, Jul 8, 2017 at= 4:10 AM, Marco Tiloca <marco.tiloca@ri.se>= ; wrote:
De= ar all,

FYI, we have recently submitted a new draft proposing an extension for (D)TLS 1.2/1.3.

The solution described in the draft addresses Denial of Service attacks against the handshake protocol, allowing servers to promptly abort invalid session set ups.

Feedback and comments are of course very welcome. Thanks a lot!

Best regards,
/Marco

-------- Forwarded Message --------
Subject: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
Date: Wed, 28 Jun 2017 07:40:45 -0700
From: internet-draft= s@ietf.org
To: Marco Tiloca <marco.tiloca@ri.= se>, Ludwig Seitz <ludwig.seitz@ri.= se>, Maarten Hoeve <maarten.hoeve= @encs.eu> 


A new version of I-D, draft-tiloca-t=
ls-dos-handshake-00.txt
has been successfully submitted by Marco Tiloca and posted to the
IETF repository.

Name:		draft-tiloca-tls-dos-handshake
Revision:	00
Title:		Extension for protecting (D)TLS handshakes against Denial of Serv=
ice
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-tiloca-tls-dos-hand=
shake-00.txt
Status:         https://d=
atatracker.ietf.org/doc/draft-tiloca-tls-dos-handshake/
Htmlized:       https://tool=
s.ietf.org/html/draft-tiloca-tls-dos-handshake-00
Htmlized:       ht=
tps://datatracker.ietf.org/doc/html/draft-tiloca-tls-dos-handsh=
ake-00


Abstract:
   This document describes an extension for TLS and DTLS to protect the
   server from Denial of Service attacks against the handshake protocol.
   The extension includes a Message Authentication Code (MAC) over the
   ClientHello message, computed by the Client through key material
   obtained from a Trust Anchor entity.  The server registered at the
   Trust Anchor derives the same key material and checks the MAC to
   determine whether continuing or aborting the handshake.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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



--=20
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistag=E5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://www.sics.s=
e
https://=
www.sics.se/~marco/

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.



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


--=20
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistag=E5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://w=
ww.sics.se
h=
ttps://www.sics.se/~marco/

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.
SICS Swedish ICT AB, has now changed name to RISE SICS AB.
--------------010807020100020309060604-- --v0xvWCOLBJM5CjthKVJfWEL4xawsaFx6t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZY8UwAAoJEO4mZLQOWNpDcUQH/iYVXO22TMknWh2rFVhgQ6oU rZF6w54ui+5nD0E7Oh5Wz1g6lGZcFEhiTx/+8yhhOyUC6m43qipnY1tIVPaDlAOX WRzyuHYdiJ/z4z9u9TaMinsid5X8KnDoYWVshFw/FnQNKrGbkvBc0RZlYqInDyI/ p888xUWq49Hb9cR2VnSVaI2axGi7haoyy45jW5AsRPl+rh7xJi+YfcEzTz5Qj4SV qVo6tFacg2A30CA2ejO5hAG/iyIaaHo8OiGXauRRG9tH/F6Ph3+jPd+H/FF6DJJE olxxwn8u8VC5JQUhwyw+LdDqF7cBNdxmifZ2OchQUQE1sJGYC+l2UuwrZZZBjX8= =9SBz -----END PGP SIGNATURE----- --v0xvWCOLBJM5CjthKVJfWEL4xawsaFx6t-- From nobody Mon Jul 10 12:03:52 2017 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 0E7D9131861 for ; Mon, 10 Jul 2017 12:03:51 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 IuooOTXsx9bg for ; Mon, 10 Jul 2017 12:03:49 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F2713187A for ; Mon, 10 Jul 2017 12:03:49 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 7C035C086D41; Mon, 10 Jul 2017 12:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=jfeEGcTENRg2K8fkGetoPNMHsNo=; b=tACSzvQx7Oy px8QMCtyK1Z6zhiLmag4rboDtO99Y2bf7dI2K9kzVXZ2/v0zxHVPuJ60S/QTV93x L6lmNadQ7gZ2wA9rnN0GBVbGkFESLsVNKmjKdw4HkOk/UXxK99YpyjHKST3EAYAA Jd7jmzrUypnVXONe1T2+kI84SOGX7fU4= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id D252AC0028A9; Mon, 10 Jul 2017 12:03:47 -0700 (PDT) Date: Mon, 10 Jul 2017 14:03:44 -0500 From: Nico Williams To: Yoav Nir Cc: Stephen Farrell , "Polk, Tim (Fed)" , "tls@ietf.org" Message-ID: <20170710190343.GA16447@localhost> References: <1ddda2f4-147e-27a6-eb71-f945cbbee0d6@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 19:03:51 -0000 On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote: > > On 10 Jul 2017, at 17:16, Stephen Farrell = wrote: > >> 2. this proposal offers > >> significantly better security properties than current practice > >> (central distribution of static RSA keys) > >=20 > > I fail to see any relevant difference in security properties > > between those two, never mind a significant improvement. >=20 > I can see one way in which it is worse. >=20 > With static RSA keys, you can configure the server to use only PFS > ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS, > you need to switch to RSA ciphersuites, and that would be obvious to > any client. In fact, I think today a server would stick out if it > only supported RSA ciphersuites. >=20 > There is no way to know that a server is doing what it says in the > draft. It=E2=80=99s completely opaque to the client. >=20 > However, in both cases the server does get FS. As long as the server > has not enabled RSA ciphersuites or exportable private key shares, any > recorded TLS stream is safe even if the attacker later gets the > private key. Well, a client could observe reuse of server ECDHE public keys... And servers can always share session keys with an auditing system. There's no way a client could detect this. I don't think we need to have the client KNOW what the server is doing because... how the heck can the server prove it's not publishing the client's secrets?? The server simply cannot prove that it is adhering to any privacy policy. Brief reuse of server ECDHE public keys is an optimization. I _think_ it's a safe optimization, and it's safer the shorter the reuse period is -- and correspondingly less safe the longer the reuse period. But I would prefer that anyone wanting auditability just build that into their implementations as a proper audit capability. Yes, it's more complex to later decrypt sessions, but it also doesn't mess with the protocol in any way. That said, I wouldn't object to the proposal if it meant to be Informational. I don't see how a document that describes a possible a configuration (not protocol!) that is not relevant to the Internet should be a Standards-Track RFC, or BCP for that matter. Informational will do. Nico --=20 From nobody Mon Jul 10 12:07:33 2017 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 69DCB131861 for ; Mon, 10 Jul 2017 12:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 u42bLm0f2XYE for ; Mon, 10 Jul 2017 12:07:27 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id D63AD13187F for ; Mon, 10 Jul 2017 12:07:25 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6AJ7OcJ036449 for ; Mon, 10 Jul 2017 15:07:24 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQHS+YQIkdUXlkluJUyIYpIPJvLqsqJNXjoAgAAuKACAACIkAP//vfeA Date: Mon, 10 Jul 2017 19:07:23 +0000 Message-ID: <8C93599D-35B1-4A9B-89F9-9A8E14AB3063@ll.mit.edu> References: <1ddda2f4-147e-27a6-eb71-f945cbbee0d6@cs.tcd.ie> <20170710190343.GA16447@localhost> In-Reply-To: <20170710190343.GA16447@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.23.0.170610 x-originating-ip: [172.25.177.195] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3582544043_2080085662" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-10_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1707100333 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 19:07:32 -0000 --B_3582544043_2080085662 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable My $0.02: absolutely not on the Standards Track (for reasons already expres= sed by others), might be discussable if Informational. -- Regards, Uri Blumenthal On 7/10/17, 15:03, "TLS on behalf of Nico Williams" wrote: On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote: > > On 10 Jul 2017, at 17:16, Stephen Farrell wrote: > >> 2. this proposal offers > >> significantly better security properties than current practice > >> (central distribution of static RSA keys) > >=20 > > I fail to see any relevant difference in security properties > > between those two, never mind a significant improvement. >=20 > I can see one way in which it is worse. >=20 > With static RSA keys, you can configure the server to use only PFS > ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS, > you need to switch to RSA ciphersuites, and that would be obvious to > any client. In fact, I think today a server would stick out if it > only supported RSA ciphersuites. >=20 > There is no way to know that a server is doing what it says in the > draft. It=E2=80=99s completely opaque to the client. >=20 > However, in both cases the server does get FS. As long as the server > has not enabled RSA ciphersuites or exportable private key shares, an= y > recorded TLS stream is safe even if the attacker later gets the > private key. =20 Well, a client could observe reuse of server ECDHE public keys... =20 And servers can always share session keys with an auditing system. There's no way a client could detect this. =20 I don't think we need to have the client KNOW what the server is doing because... how the heck can the server prove it's not publishing the client's secrets?? The server simply cannot prove that it is adhering to any privacy policy. =20 Brief reuse of server ECDHE public keys is an optimization. I _think_ it's a safe optimization, and it's safer the shorter the reuse period i= s -- and correspondingly less safe the longer the reuse period. =20 But I would prefer that anyone wanting auditability just build that int= o their implementations as a proper audit capability. Yes, it's more complex to later decrypt sessions, but it also doesn't mess with the protocol in any way. =20 That said, I wouldn't object to the proposal if it meant to be Informational. I don't see how a document that describes a possible a configuration (not protocol!) that is not relevant to the Internet should be a Standards-Track RFC, or BCP for that matter. Informational will do. =20 Nico --=20 =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 --B_3582544043_2080085662 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgeiPxPmBsyvY3D05O 9gwvxDwe5RDuYqRYA0oe2iGeHi4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcwNzEwMTkwNzIzWjANBgkqhkiG9w0BAQEFAASCAQANoszD8PhKVDaGzK9m BIbI/X1Gu371au+Zi996s9YXwlpx3kiWaDh22dQiSyWGLvcRaKF19J+3eORMusyUM8msreQK sJtHOTsQ1v+xgpE2BfT81a11E0Ladmfu0lkLIzHmROGg50DlmV2+geTiGhxjYjprCTaFaelR tzQNXEdCJXzdUiOIXjvF1qo1YpHaOM4p1vu9zStg91Gz4xjSnsqVULIq9pEYRk1CxJS5cohA j/Sfrab7i1Y648CRKMY/YYoKCF38jTVlL+DkWBIQJ30nksDtv65wLokSbUE+uoc3kfG+M9QR jGGC7mQrq/VsT2d3o3DHzDO+eg7KYKJIGb8E --B_3582544043_2080085662-- From nobody Mon Jul 10 12:29:36 2017 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 EB84113188A for ; Mon, 10 Jul 2017 12:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZz7Qr-IMMep for ; Mon, 10 Jul 2017 12:29:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D57E131866 for ; Mon, 10 Jul 2017 12:29:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EABE9BE38; Mon, 10 Jul 2017 20:29:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAqliOAvuyYc; Mon, 10 Jul 2017 20:29:28 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1EB0DBDCC; Mon, 10 Jul 2017 20:29:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499714968; bh=oD67jyYpPbHLYUU5eQHCjx31rPUjzoLc1V72BGzS01A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=A6ue9Mstg2B1pkThoRYTT5qeNCJDMs7aCxDsPOdJBas6XP7cSz0xiQoz2qhuFY1iw X7X209r8swweVGJmEv7DkYgPCrQotWzC5p0lLjtF68OZ78sg/b2rG5ikA48g7j8E2G WS+4GcSrjLCoAjC3SdpPqo9jjTBelyV8FVW1uwBM= To: Sean Turner Cc: TLS Chairs , "tls@ietf.org" References: <867B8F06-63F2-4EDF-9B92-CB2EF7F08D30@sn3rd.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <660d6280-6865-3a76-fbe3-035a549fcd2c@cs.tcd.ie> Date: Mon, 10 Jul 2017 20:29:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <867B8F06-63F2-4EDF-9B92-CB2EF7F08D30@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="borphw5ls8GrlWiI8RCgCQ2OKBSoSjAhE" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 19:29:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --borphw5ls8GrlWiI8RCgCQ2OKBSoSjAhE Content-Type: multipart/mixed; boundary="eOisDGiwkJ95omaXuq6qNktRvI8U8RXxP"; protected-headers="v1" From: Stephen Farrell To: Sean Turner Cc: TLS Chairs , "tls@ietf.org" Message-ID: <660d6280-6865-3a76-fbe3-035a549fcd2c@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <867B8F06-63F2-4EDF-9B92-CB2EF7F08D30@sn3rd.com> In-Reply-To: <867B8F06-63F2-4EDF-9B92-CB2EF7F08D30@sn3rd.com> --eOisDGiwkJ95omaXuq6qNktRvI8U8RXxP Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 10/07/17 17:57, Sean Turner wrote: > Stephen, >=20 > After some discussion amongst the chairs, we have decided to not shut > down the discussion about draft-green-tls-static-dh-in-tls13. =20 Ok, that's your call. But a bad call IMO. This topic, if not the specific draft, was already the subject of significant debate during which the use of static DH values was raised. I think you are putting the WG participants through repetitive calls here for no good reason. (The fact that a -01 was emitted and new authors added is not IMO a good reason.) So I'd ask that you review the previous related threads and consider again if the basic idea behind this hasn't already been rejected by the WG in the recent past. In text below I'll assume you do that but decide to have an adoption call nonetheless (though I hope you review the mail archive and decide to reconsider). > We are > not shutting down this discussion because this topic is relevant to > the constituents on both sides of the issue in the working group and > there is a concrete proposal to discuss.=20 That seems to me to be a recipe for whack-a-mole - we have seen these break-tls proposals over and over and handling it your way seems like it'll encourage more of 'em. > Now that we know the > authors are going to ask for WG adoption, the resulting working > group's consensus or lack of consensus on this approach will be > useful information for other discussions that will happen in the > broader IETF community regardless of the outcome. =20 I have no idea of the process problems that that'll create if the WG go crazy and decide to adopt this despite it conflicting with 2804 and given all the inevitable follow up wiretapping additions that'll be proposed for quic and pretty much everything else, if the TLS wg are seen to "fold." Seems like a recipe for lots of confused process lawyering to me, but hopefully that'll not turn out to be an issue. > Further, we intend > for consensus on the issue to be called quickly. I'm against it:-) >=20 > We also do not believe that this discussion is derailing the TLS1.3 > draft, we are consistently surprised by the WG=E2=80=99s bandwidth and = the > draft is out for a 2nd targeted WGLC. As far as DTLS1.3, the > specification is coming along but is not at a critical point where we > believe this discussion will greatly detract from its development. >=20 You did not respond about the Prague agenda. I continue to ask that you not give this bad idea more f2f time. If you do give it time, then I'd ask for equal time to debunk this bad idea. But better to have zero time. S. > J&S >=20 >> On Jul 8, 2017, at 05:17, Stephen Farrell >> wrote: >>=20 >>=20 >> Sean/Joe, >>=20 >> This is a request that you, as chairs, shut down the distracting=20 >> wiretapping discussion, at least until DTLS1.3 is done. >>=20 >> I have planned to spend time reading draft 21 and DTLS, but that=20 >> won't happen if we keep having to fight off the latest attempts to >> break TLS. I'd not be surprised if I weren't the only one finding >> that distraction an irritating waste of time. Finishing TLS1.3 and >> getting DTLS1.3 on the way surely needs to not be constantly >> de-railed by these attempts to break TLS. >>=20 >> Therefore I'd ask that you declare this discussion closed for at=20 >> least that long (i.e until DTLS1.3 is done). >>=20 >> I'd also ask that you not allocate agenda time for wiretapping in >> Prague. >>=20 >> Thanks, S. >>=20 >> _______________________________________________ TLS mailing list=20 >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 >=20 --eOisDGiwkJ95omaXuq6qNktRvI8U8RXxP-- --borphw5ls8GrlWiI8RCgCQ2OKBSoSjAhE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZY9WWAAoJEC88hzaAX42izZEIAIaL6gISDzsEUvMbtsgBRFdT 7ETRyvoJmrub33nJfKESLfCDO0UKfJWoIa28ntvGgiU7DG3rHZt9BppQ4+D6rOvW 4bN1FeHic9wcL8KVkHtHlnvLbp4ZTYCapfsWRgoxiGylLcwsvUg/YUKY+nySNQn4 wVNFnrRIEHWXP+Ge6A1JbtpCKEhPAdfsiB5VX3nBvOHMBBH/Oa/bjudTefxJ6jJK X4k2bKNsMc+oNg7hBVWZZaJIIT1/TwW5qdra8OftWh9KC/9Fkxk23FziCK0jFxpr VfcoHriXmVAfrE1pECv2jqdctZIaIfOHeHjz6FvVscq2+WjkSjxo8kZ3MsoWgDE= =DLfp -----END PGP SIGNATURE----- --borphw5ls8GrlWiI8RCgCQ2OKBSoSjAhE-- From nobody Mon Jul 10 12:32:05 2017 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 502DF131897 for ; Mon, 10 Jul 2017 12:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp6dM4ILIZ5f for ; Mon, 10 Jul 2017 12:32:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C41E131866 for ; Mon, 10 Jul 2017 12:32:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EEE5BBE38; Mon, 10 Jul 2017 20:31:59 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AotrmTVnDyD2; Mon, 10 Jul 2017 20:31:58 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 29E80BDCC; Mon, 10 Jul 2017 20:31:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499715118; bh=3uumvsI7kKjJWoSWZjW2mQaT+HLfjcuva8p1A8NNZ1M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NyOcE+FCMMrXNwBRcMcc8mZY7zAM49qvoCbWBMsAu4BeYnIxBERz2B2JRW6v5oYy/ qQp3Gnm/kEssvJDPKgTZb087zKP58TBoTboX8Lsj5C9VN4yzfKmU8PUoif1OAXfg02 62Ph1NekxuC3H2R572xFpGsY7l9WBUDlKQ0D4u/w= To: "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" References: <1ddda2f4-147e-27a6-eb71-f945cbbee0d6@cs.tcd.ie> <20170710190343.GA16447@localhost> <8C93599D-35B1-4A9B-89F9-9A8E14AB3063@ll.mit.edu> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5212f6bc-a4f6-99b2-4eab-ad293c7019f1@cs.tcd.ie> Date: Mon, 10 Jul 2017 20:31:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8C93599D-35B1-4A9B-89F9-9A8E14AB3063@ll.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4D1G96Hxwm7WP8lKhPSeFN2j1rXwrHsEL" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 19:32:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4D1G96Hxwm7WP8lKhPSeFN2j1rXwrHsEL Content-Type: multipart/mixed; boundary="fQXqhwjveN15lbfHPBVHfSXspHLHmpdHh"; protected-headers="v1" From: Stephen Farrell To: "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Message-ID: <5212f6bc-a4f6-99b2-4eab-ad293c7019f1@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <1ddda2f4-147e-27a6-eb71-f945cbbee0d6@cs.tcd.ie> <20170710190343.GA16447@localhost> <8C93599D-35B1-4A9B-89F9-9A8E14AB3063@ll.mit.edu> In-Reply-To: <8C93599D-35B1-4A9B-89F9-9A8E14AB3063@ll.mit.edu> --fQXqhwjveN15lbfHPBVHfSXspHLHmpdHh Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 10/07/17 20:07, Blumenthal, Uri - 0553 - MITLL wrote: > My $0.02: absolutely not on the Standards Track (for reasons already > expressed by others), might be discussable if Informational. I haven't checked, but as far as I recall, other wiretapping RFCs inconsistent with 2804 have all been in the ISE stream (or predate it) and have all documented already deployed wiretapping schemes. I think that is consistent with 2804 and using a WG list and WG participant cycles/attention to debate/develop wiretapping methods does go against 2804 and ought not be done. S. >=20 > -- Regards, Uri Blumenthal >=20 > On 7/10/17, 15:03, "TLS on behalf of Nico Williams" > wrote: >=20 > On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote: >>> On 10 Jul 2017, at 17:16, Stephen Farrell >>> wrote: >>>> 2. this proposal offers significantly better security >>>> properties than current practice (central distribution of >>>> static RSA keys) >>>=20 >>> I fail to see any relevant difference in security properties=20 >>> between those two, never mind a significant improvement. >>=20 >> I can see one way in which it is worse. >>=20 >> With static RSA keys, you can configure the server to use only PFS=20 >> ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the >> non-FS, you need to switch to RSA ciphersuites, and that would be >> obvious to any client. In fact, I think today a server would stick >> out if it only supported RSA ciphersuites. >>=20 >> There is no way to know that a server is doing what it says in the=20 >> draft. It=E2=80=99s completely opaque to the client. >>=20 >> However, in both cases the server does get FS. As long as the >> server has not enabled RSA ciphersuites or exportable private key >> shares, any recorded TLS stream is safe even if the attacker later >> gets the private key. >=20 > Well, a client could observe reuse of server ECDHE public keys... >=20 > And servers can always share session keys with an auditing system.=20 > There's no way a client could detect this. >=20 > I don't think we need to have the client KNOW what the server is > doing because... how the heck can the server prove it's not > publishing the client's secrets?? The server simply cannot prove > that it is adhering to any privacy policy. >=20 > Brief reuse of server ECDHE public keys is an optimization. I > _think_ it's a safe optimization, and it's safer the shorter the > reuse period is -- and correspondingly less safe the longer the reuse > period. >=20 > But I would prefer that anyone wanting auditability just build that > into their implementations as a proper audit capability. Yes, it's > more complex to later decrypt sessions, but it also doesn't mess with > the protocol in any way. >=20 > That said, I wouldn't object to the proposal if it meant to be=20 > Informational. I don't see how a document that describes a possible > a configuration (not protocol!) that is not relevant to the Internet=20 > should be a Standards-Track RFC, or BCP for that matter. > Informational will do. >=20 > Nico -- >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --fQXqhwjveN15lbfHPBVHfSXspHLHmpdHh-- --4D1G96Hxwm7WP8lKhPSeFN2j1rXwrHsEL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZY9YtAAoJEC88hzaAX42iuWAH/2QT4KMDWcvJZxqX/+fFmXwO E45qTqgDq7BHsUKsD0ElJq5nE4r9EjQzPq+NJ5cH8BI/A1TIdVoCiMQ6OyfgGxn4 QGDk4r97xQEy/wCyARwJrx/v64j+k0uSyujRzjbRIfH1+kovUPuvzK9OyQ5YD6yZ 5q3U45gs5/CehBXVU6Fl87+PyxrhX2wLoMi8Jb3Flrq89qx7dDAbXYsZMZDqzSMm STcezwyWB6jggs8c3UITDd6fC197GvTI5eZR1Y6+WNPrYK0E5vP90N6yV0wmIuWy y4sSELGKmPB3r8SdDqgc+AdJDwLuiSNvIS7ZmP/v/kA5Yk8doBlZCD7vT/FzmHY= =T34D -----END PGP SIGNATURE----- --4D1G96Hxwm7WP8lKhPSeFN2j1rXwrHsEL-- From nobody Mon Jul 10 12:37:33 2017 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 6BC2313188C for ; Mon, 10 Jul 2017 12:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: 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-gT1W_Bj7l5 for ; Mon, 10 Jul 2017 12:37:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85231131897 for ; Mon, 10 Jul 2017 12:37:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 32A5CBE38; Mon, 10 Jul 2017 20:37:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdhaCPJBnj1W; Mon, 10 Jul 2017 20:37:23 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EA751BDD8; Mon, 10 Jul 2017 20:37:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499715443; bh=4SwBY59yy13h+LWs4HjpnR9DiqOABtzJTFqhu+PSkSI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HH2esgUyRtsg39dbq+2a7uYUyhDQr6QoqYPrR+xiAVZoKO1hLRRTvRS36wqagNpPg ShrgaeQJUh2vwgKDAYtnK8zQIPh+IZSjpbOQsOd9mxBjA+HOVlfIC5SgGpcC1Ee0WX Mol0YgJqg8eUztaoMZFEAQraTlCKEG72Mjsbae8c= To: "Ackermann, Michael" , "Polk, Tim (Fed)" , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> Date: Mon, 10 Jul 2017 20:37:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="99BtleWc9QJG05Pr4tUSeDoJ75TNJvoCv" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 19:37:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --99BtleWc9QJG05Pr4tUSeDoJ75TNJvoCv Content-Type: multipart/mixed; boundary="sFcJ2TNvdX7nVplhOSVrhsJ9Eg5wcM560"; protected-headers="v1" From: Stephen Farrell To: "Ackermann, Michael" , "Polk, Tim (Fed)" , "tls@ietf.org" Message-ID: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: In-Reply-To: --sFcJ2TNvdX7nVplhOSVrhsJ9Eg5wcM560 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 10/07/17 16:30, Ackermann, Michael wrote: > Given the above scenario, I do not understand how this can be construe= d as "Wiretapping". 2804 seems to make this clear. TLS is much more widely used that you seem to imagine. Please see the comments to the effect that there is no way to control to location of the wiretap/TLS-decrypter in the protocol. If that's not obvious, I don't know how to explain it further. See also text in 2804 wrt tools being used for more than initially envisaged. And if coercion of a server to comply with a wiretap scheme like this stills fanciful to you, please check out the history of lavabit - had there been a standard wiretap API as envisaged here it's pretty certain that would have been the device of choice in a case like that. While it's easy enough to envisage many other abuses that could be based on this wiretap scheme, that one is a good match and a real one. > Such critical colloquy, with significant long term > impact, should not be prematurely terminated, IMHO "Premature" is nonsense, this debate has gone on too long already. S. --sFcJ2TNvdX7nVplhOSVrhsJ9Eg5wcM560-- --99BtleWc9QJG05Pr4tUSeDoJ75TNJvoCv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZY9dyAAoJEC88hzaAX42iIq0H/Rbd3yiJXYd8VuUkO6/GBUzM qNq2x4XEG3V+LP8ziKQpkcE86AEFj7+UcSmlrs6aTl/M5HDvqQTHtA3ogbDXjPw6 INvIdLBmeN2npdWcXb4Jyd6l6QmjcWZAjtYyKyPHI5QiQiJBgupmpTA12VNiRoNj Vj5tad9uyrLHJJ9QWLFhlbX3xMvC8802HUbSL0eyhbKT7+HVFyszsiZoAQaR/gRk dUsNsHbiwWRdh9iFuP6GsVyQlwyeseH+5vRw1Pfnmasd7Z9YNtRghkxvL3iq7BEl yWXY++QCxhneyE4b/8wDqRvxO1Qd8+S2oWVKiKq2VMTst867ZL8ZLU0SV63Hsdc= =kA6J -----END PGP SIGNATURE----- --99BtleWc9QJG05Pr4tUSeDoJ75TNJvoCv-- From nobody Mon Jul 10 12:38:58 2017 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 3CB5312F253 for ; Mon, 10 Jul 2017 12:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgO0aUdUxkc0 for ; Mon, 10 Jul 2017 12:38:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DA612EC41 for ; Mon, 10 Jul 2017 12:38:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5D4A2BDD8; Mon, 10 Jul 2017 20:38:54 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6plrakZk6TSY; Mon, 10 Jul 2017 20:38:53 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0F357BE38; Mon, 10 Jul 2017 20:38:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499715533; bh=FVIWrlZEeW4uQbVBfKf1PS5vHsGUZfvGNqo/h44PNrg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BJzEyrevASQHrZHDtlf2LCKjJFuE1nmz6Q62OLSDWEzckgSsvPnEDaMIhp3VEeJbP HP4GHAo1I2OmwdvRDTusxk9l4FtdtFzvlO0/ZapBWECv946Fb0LEC65hjJmLKtMbtV 2EA19uA7xE313jkaNAgJ4iAH6P6q8sHAbDhp2eCU= To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Nikos Mavrogiannopoulos Cc: "Polk, Tim (Fed)" , "tls@ietf.org" References: <1499699684.2933.20.camel@redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <822604a1-61ca-a13c-9b6f-2cd7b57cadf9@cs.tcd.ie> Date: Mon, 10 Jul 2017 20:38:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EtB0emqHVKS91PpPR9ldMdDuR6hqK90wl" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 19:38:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EtB0emqHVKS91PpPR9ldMdDuR6hqK90wl Content-Type: multipart/mixed; boundary="FcqicoR2rqa1mPl3uRXjKIhukGLtKU5wp"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Nikos Mavrogiannopoulos Cc: "Polk, Tim (Fed)" , "tls@ietf.org" Message-ID: <822604a1-61ca-a13c-9b6f-2cd7b57cadf9@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <1499699684.2933.20.camel@redhat.com> In-Reply-To: --FcqicoR2rqa1mPl3uRXjKIhukGLtKU5wp Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 10/07/17 17:42, Colm MacC=C3=A1rthaigh wrote: > It's clear that there is a strong distaste here for the kind of MITM be= ing > talked about It is not (only) "distaste," it is IETF policy as a result of a significant debate on wiretapping. S --FcqicoR2rqa1mPl3uRXjKIhukGLtKU5wp-- --EtB0emqHVKS91PpPR9ldMdDuR6hqK90wl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZY9fMAAoJEC88hzaAX42i3HoH/39rNCj4hhBmosd3QRZs1a9r VlS87OhUnmEBzkfgruA0KM9O1VdoAlUlExk4QHkLa1Al2Lmo6lpWF8Y7VwCw1Unl k+d2JdBt31oiG3Tre/XC4TL2+tU82cpHJYxt6CnwUZuMB25Fn7cnrLZHLxXER5Ld 6CUZXQx8aCfSWjyktVNuDscQWswN5CoFWrbZZOZTGjG27RItcra+uUwhetPfHKvX tRMwEsCL1VrY0wveGMfnothne2OA1ya63y6xdHy5S9bKHf1S9ZKtCv55DthBeMRC 3pALWWcn2Qo2MCnpbUZvpBDXhzEz6stFp4JJ464AK/dzzn1Hpy6jbRT9DymKc5s= =eLMj -----END PGP SIGNATURE----- --EtB0emqHVKS91PpPR9ldMdDuR6hqK90wl-- From nobody Mon Jul 10 13:06:20 2017 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 13C3E129AE7 for ; Mon, 10 Jul 2017 13:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 DzkSUV0jVUDq for ; Mon, 10 Jul 2017 13:06:17 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DD612700F for ; Mon, 10 Jul 2017 13:06:17 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 56C82C086D47; Mon, 10 Jul 2017 13:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=RtuDpijyfyif/A xos7OeuGQ+Iko=; b=VTFwd4QWiYSwGLlpSXEaJtyhYct1hI7lGuQZ7uVPJqpEZe JHZidMLkitFYaLNV/bf1rAdcqffNYgewpw1xT+GhaFXSxSdaBd9Z3l7zXHFI4xU7 iGxPVuVMJ4HryzTAhOcihnUbRPeF6UFsNDdfVlfG/iG1CKp/D18EDvNigmi3o= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 9E448C086D46; Mon, 10 Jul 2017 13:06:15 -0700 (PDT) Date: Mon, 10 Jul 2017 15:06:12 -0500 From: Nico Williams To: Stephen Farrell Cc: Sean Turner , "tls@ietf.org" , TLS Chairs Message-ID: <20170710200611.GB16447@localhost> References: <867B8F06-63F2-4EDF-9B92-CB2EF7F08D30@sn3rd.com> <660d6280-6865-3a76-fbe3-035a549fcd2c@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <660d6280-6865-3a76-fbe3-035a549fcd2c@cs.tcd.ie> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 20:06:18 -0000 On Mon, Jul 10, 2017 at 08:29:26PM +0100, Stephen Farrell wrote: > On 10/07/17 17:57, Sean Turner wrote: > > After some discussion amongst the chairs, we have decided to not shut > > down the discussion about draft-green-tls-static-dh-in-tls13. > > Ok, that's your call. But a bad call IMO. IMO there's a trivial fix: make draft-green-tls-static-dh-in-tls13 an individual submission targeting Informational, and allow discussion on the TLS WG without making it a WG item (meaning, too, that no WG milestone should refer to it). Given that the entire text of draft-green-tls-static-dh-in-tls13 looks like it's informational ("if you want key escrow with TLS 1.3, this is how you might do it"), Informational looks right. (BCP would not be appropriate, since on the cap-I Internet we would want this deployed. And as to intranets, we don't care.) An I-D specifying a protocol for doing key auditing for escrow purposes could be Standards-Track, since it could be a protocol that many need to interop with. But it wouldn't necessarily be a TLS WG item. And we might still want it to be Informational (since we can specify protocols that way as well). Nico -- From nobody Mon Jul 10 13:11:26 2017 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 2814E12ECB5 for ; Mon, 10 Jul 2017 13:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 r67xRwEKlxqJ for ; Mon, 10 Jul 2017 13:11:22 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 724FC12ECBE for ; Mon, 10 Jul 2017 13:11:22 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id q86so55152156pfl.3 for ; Mon, 10 Jul 2017 13:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q9+BT33C11wkJx1NTxudUfAYAP6UU4gDc11+h00RU3M=; b=EvwhwGjT4HzmHWOpYwzf66GOuOSyHjxsq+PltNofBY7PR7ho0s6O5ZPFhwVjoswsac fGdKl28SRoIHZ1ccKygZ3eMQv992cpXWendDmvc946ECZJBPZG0gZpKpiIusxRBCA3tT lY88opqaSVqJuIVabsF+Oz3cXSqjUXJISeU54yEUx0p6/E9cGuHXp47ly+tGZ/YNBlC6 6bgNQp/H5V/z8NHM/qp0uu/3HA4dm2t8MLCB0QKKzCt9q8GunqlsKzhBjJQqNggWX5dv AojhkvfJiLYYg3aA1wQb8fv1YeRdB64tnJIE2FQkSQj2NVDNt/aa5fB4SE2kJqLPooNS 2LmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q9+BT33C11wkJx1NTxudUfAYAP6UU4gDc11+h00RU3M=; b=Jj98/v/jDL3VapnBVIE75vlsS184mD9L66vDNg+iOHi8Abh6gun06TSugfrbTJG1yQ 22Q/+7REJjZu+zeTS1zXiMxQsdcRKbcRV8bBom4o7f2hcyuTU2Pn30Ai8aQTJD65pCqk v04vzDt2h05pBhXKsRdeSJrkuMMRdYbAQkj/PzxLZo8Azjp1/x3unboNkzabr0qO9r/A 0TWB4OIEe8QMjndjZn22hbcesdZ4eJ96j/0qsA/BkV3KOg5K2qcQPctN1Wi5EC9+V+tN NGeKPy3Nf9r/LdgLQ1VUKxot7CDfQRRMNli/EYhm226AYR2sZ3i/7uld75LOyv4vZkMT /0/A== X-Gm-Message-State: AIVw113doYknj9yjfxbU7osOKC1U9mlAG39E7jpx7fZgB5Q6AS2NmVay IpHIcTN8o/k4CDTPiufB+qf7sTe6cLQO X-Received: by 10.98.91.71 with SMTP id p68mr40106877pfb.209.1499717482071; Mon, 10 Jul 2017 13:11:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Mon, 10 Jul 2017 13:11:21 -0700 (PDT) Received: by 10.100.187.77 with HTTP; Mon, 10 Jul 2017 13:11:21 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Mon, 10 Jul 2017 13:11:21 -0700 Message-ID: To: "Ackermann, Michael" Cc: "Polk, Tim (Fed)" , tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c03a092c84abc0553fc2ffe" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 20:11:25 -0000 --94eb2c03a092c84abc0553fc2ffe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Jul 10, 2017 8:46 AM, "Ackermann, Michael" wrote: +1 !!! And For the enterprise situations, we typically own, operate and manage the involved =E2=80=9CFacilities=E2=80=9D: The Servers The Applications The Networks The Keys The Data and in Many cases the clients as well Given the above scenario, I do not understand how this can be construed as =E2=80=9CWiretapping=E2=80=9D. 2804 seems to make this clear. What Enterprises want in this space, is the ability to continue to have access to their aforementioned facilities, to perform diagnostics, monitoring and security functions. (i.e. continue to effectively operate and manage our networks). Although I believe the Matt Green draft proposes a very good, viable and well thought out solution for TLS 1.3, I suspect most of us are open to different or better solutions, if such exists or can be conceived. There seems to be good discussion, requirements and ideas on both sides of this issue, albeit in sharp disagreement in many cases. Such critical colloquy, with significant long term impact, should not be prematurely terminated, IMHO. Finally an editorial comment from those of us TRYING to get Enterprises involved at IETF. We finally have some interest and engagement from Enterprise perspectives. Killing discussion on this issue, which is clearly important to Enterprises, will send the message that IETF did not really want this input or feedback. I hope this is not the case. One vertical is not all enterprises. Plenty of companies can trace requests via logging systems and do not need mirroring for diagnostics. Perhaps if we weren't faced with a last minute request to include static ciphersuites things would be different. But the technique exists and can be used regardless of approval. (Have you considered Dual EC+extended random?) The problem->box model has never been well-suited for the internet. There are serious policy considerations here and a long agenda for this WG. Stopping discussion is not about ignoring the problem: it's stopping a discussion going nowhere from eating up all the bandwidth. *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Polk, Tim (Fed) *Sent:* Monday, July 10, 2017 9:54 AM *To:* tls@ietf.org *Subject:* Re: [TLS] chairs - please shutdown wiretapping discussion... First, I do not see this as a =E2=80=9Cwiretapping discussion=E2=80=9D base= d on my reading of 2804, although others may disagree. Second, I believe that this discussion should go forward based on several points: 1. this proposal does not involve any changes to the bits on the wire specified in the TLS 1.3 document 2. this proposal offers significantly better security properties than current practice (central distribution of static RSA keys) 3. alternative solutions with significantly worse security properties are also feasible under TLS 1.3, and I would like to avoid them! We should be in the business of developing pragmatic, interoperable solutions with appropriate security properties. Balancing cryptographic security with other security requirements to achieve such solutions should be an acceptable path, and pursuing this work in the TLS working group gives the IETF the best opportunity to influence these solutions. The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --94eb2c03a092c84abc0553fc2ffe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jul 10, 2017 8:46 AM, "Ackermann, Michael" <MAckermann@bcbsm.com> wrote:

+1 !!!

=C2=A0

And

For the enterprise = situations,=C2=A0 we typically own, operate and manage the involved =E2=80= =9CFacilities=E2=80=9D:

The Servers<= u>

The Applications=

The Networks

The Keys<= /u>

The Data
and in Many cases the clients as well

=C2=A0

Given the above sce= nario,=C2=A0 I do not understand how this can be construed as =E2=80=9CWire= tapping=E2=80=9D.=C2=A0=C2=A0=C2=A0 2804 seems to make this clear.

=C2=A0

What Enterprises wa= nt in this space, is the ability to continue to have access to their aforem= entioned facilities,=C2=A0 to perform diagnostics, monitoring and security = functions.=C2=A0=C2=A0 (i.e. continue to effectively operate and manage our networks).=C2=A0 Although I believe the Matt Green = draft proposes a very good, viable and well thought out solution for TLS 1.= 3,=C2=A0 I suspect most of us are open to different or better solutions,=C2= =A0 if such exists or can be conceived.=C2=A0=C2=A0

There seems to be g= ood discussion, requirements and ideas on both sides of this issue,=C2=A0 a= lbeit in sharp disagreement in many cases.=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Su= ch critical colloquy,=C2=A0 with significant long term impact,=C2=A0 should not be prematurely terminated,=C2=A0 IMHO.=C2=A0

=C2=A0

=C2=A0

Finally an editoria= l comment from those of us TRYING to get Enterprises involved at IETF.=C2= =A0=C2=A0 We finally have some interest and engagement from Enterprise pers= pectives.=C2=A0=C2=A0=C2=A0 =C2=A0Killing discussion on this issue,=C2=A0 which is clearly important to Enterprises, will send the message that IETF= did not really want this input or feedback.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = I hope this is not the case.=C2=A0


One vertical is = not all enterprises. Plenty of companies can trace requests via logging sys= tems and do not need mirroring for diagnostics.

=
Perhaps if we weren't faced with a last minute = request to include static ciphersuites things would be different. But the t= echnique exists and can be used regardless of approval. (Have you considere= d Dual EC+extended random?)

The problem->box model has never been well-suited for the internet. = There are serious policy considerations here and a long agenda for this WG.= Stopping discussion is not about ignoring the problem: it's stopping a= discussion going nowhere from eating up all the bandwidth.

=C2=A0

From:= TLS [mailto:tls-bounces@ietf.org] On Behalf Of Polk, Tim (Fed)
Sent: Monday, July 10, 2017 9:54 AM
To: tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion..= .

=C2=A0

First, I do not see= this as a =E2=80=9Cwiretapping discussion=E2=80=9D based on my reading of = 2804, although others may disagree.

=C2=A0

Second, I believe t= hat this discussion should go forward based on several points:

  1. this proposal does not involve any changes to the bits on the wire = specified in the TLS 1.3 document
  2. this pro= posal offers significantly better security properties than current practice= (central distribution of static RSA keys)
  3. alternative solutions with significantly worse security properties are als= o feasible under TLS 1.3, and I would like to avoid them!

=C2=A0

We should be in the= business of developing pragmatic, interoperable solutions with appropriate= security properties.=C2=A0 Balancing cryptographic security with other sec= urity requirements to achieve such solutions should be an acceptable path, and pursuing this work in the TLS working gr= oup gives the IETF the best opportunity to influence these solutions.

=C2=A0

=C2=A0

=C2=A0


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this commun= ication is directed. If you are not the intended recipient, you are hereby = notified that any viewing, copying, disclosure or distribution of this info= rmation is prohibited. Please notify the sender, by electronic mail or tele= phone, of any unintended receipt and delete the original message without ma= king any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan ar= e nonprofit corporations and independent licensees of the Blue Cross and Bl= ue Shield Association.

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


--94eb2c03a092c84abc0553fc2ffe-- From nobody Mon Jul 10 13:21:06 2017 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 BCDD31318A3 for ; Mon, 10 Jul 2017 13:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 mGH-RXNO5jnN for ; Mon, 10 Jul 2017 13:21:01 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 4E01112F258 for ; Mon, 10 Jul 2017 13:21:01 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id BB2C11C18FB for ; Mon, 10 Jul 2017 15:21:00 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 0AC081C184F; Mon, 10 Jul 2017 15:21:00 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CACF2FE055; Mon, 10 Jul 2017 16:20:59 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 95B29FE048; Mon, 10 Jul 2017 16:20:59 -0400 (EDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (unknown [216.32.180.51]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 10 Jul 2017 16:20:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mQUItYaYpgnh7QMdy04ZOGdc8gswlJpmzaGbrQn6GFg=; b=5yBEpoVaxa7z1oVJC3O+qoXfq52lvfVoKe5+LIwy/krdzPQjBCUi5dsRR7i5JYKr6WsOxj44DKXACNtHCM+9AV9Ij9Y4Zy7nD4OWPSPUBm0g9nseMqtTKVhBYy4eD9HkxyXfuBaV6QGX45isC46GTr2kUzvSagEeHehKaCBgPys= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Mon, 10 Jul 2017 20:20:58 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.020; Mon, 10 Jul 2017 20:20:58 +0000 From: "Ackermann, Michael" To: Stephen Farrell , "Polk, Tim (Fed)" , "tls@ietf.org" Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQHS+YQI7m7fVGNOTUGFuL/08f/fM6JNIUiQgABTlgCAAAqIoA== Date: Mon, 10 Jul 2017 20:20:57 +0000 Message-ID: References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> In-Reply-To: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.39.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 20:k2+XoAX1QhNpm6GsraKdo8rs1d4GRFBxEbZcS/NLri/T0vCsgXgf+Oijds4NW9E8kHLEcjqzv+A8eomVJDbI9ZNmpcr9h8YmT5PWD8gGBRFHT7NfDGSlx2DugFKqeEuebZWGqWhi2uTGW7mM690cFok2ojniQn5EkHiJhrtDguM= x-ms-office365-filtering-correlation-id: 3a1761b8-06a1-4c1e-7836-08d4c7d12cf5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1365; x-ms-traffictypediagnostic: CY4PR14MB1365: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(65766998875637)(236129657087228)(86572411397741)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1365; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39450400003)(39400400002)(377454003)(13464003)(24454002)(86362001)(9686003)(99286003)(189998001)(55016002)(72206003)(8656002)(6246003)(8676002)(53936002)(50986999)(478600001)(6436002)(76176999)(66066001)(54356999)(2900100001)(6116002)(6506006)(8936002)(305945005)(102836003)(3846002)(74316002)(33656002)(80792005)(81166006)(77096006)(5660300001)(2501003)(2906002)(3280700002)(7736002)(38730400002)(229853002)(14454004)(3660700001)(2950100002)(7696004)(53546010)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2017 20:20:57.9937 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 1c99a0c3-2607-4e47-ba65-d32be585f9a8 X-VPM-MSG-ID: c7ad081f-25e0-4a52-b27a-c4e148248454 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 20:21:05 -0000 VGhlbiB3ZSByZWFkIDI4MDQgZGlmZmVyZW50bHkuICAgICBXaGVuIEkgcmVhZCAyODA0LCAg dGhlIGNvbnRhaW5lZCBkaXNjb3Vyc2VzIG9uIHdoYXQgaXMgYW5kIGlzIG5vdCB3aXJldGFw cGluZywgIGNsZWFybHkgc2F5cyB0byBtZSwgIHRoYXQgd2hhdCBFbnRlcnByaXNlcyBkbyB3 aXRoaW4gdGhlaXIgbmV0d29ya3MsICBpcyBOT1Qgd2lyZXRhcHBpbmcgYWNjb3JkaW5nIHRv IDI4MDQgKG9yIHRvIG1lIGZvciB0aGF0IG1hdHRlcikuICANCg0KV2UgKGFuZCBtYW55IG90 aGVycyBpbiB0aGlzIGRpc2N1c3Npb24pLCAgaGF2ZSBkaWZmZXJlbnQgcGVyc3BlY3RpdmVz LiAgIFBlcmhhcHMgdGhpcyBpcyBhIGNvbnRyaWJ1dGluZyByZWFzb24gdGhlIENoYWlycyBk ZXRlcm1pbmVkIGl0IHNob3VsZCBjb250aW51ZS4gICAgIEkgc2luY2VyZWx5IGhvcGUgdGhp cyB3aWxsIGxlYWQgdG8gc29tZSBtdXR1YWxseSBhY2NlcHRhYmxlIGRpYWxvZ3VlIGFuZCBy ZWxhdGVkIHNvbHV0aW9ucy4gIA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2Qu aWVdIA0KU2VudDogTW9uZGF5LCBKdWx5IDEwLCAyMDE3IDM6MzcgUE0NClRvOiBBY2tlcm1h bm4sIE1pY2hhZWwgPE1BY2tlcm1hbm5AYmNic20uY29tPjsgUG9saywgVGltIChGZWQpIDx3 aWxsaWFtLnBvbGtAbmlzdC5nb3Y+OyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExT XSBjaGFpcnMgLSBwbGVhc2Ugc2h1dGRvd24gd2lyZXRhcHBpbmcgZGlzY3Vzc2lvbi4uLg0K DQoNCg0KT24gMTAvMDcvMTcgMTY6MzAsIEFja2VybWFubiwgTWljaGFlbCB3cm90ZToNCj4g R2l2ZW4gdGhlIGFib3ZlIHNjZW5hcmlvLCAgSSBkbyBub3QgdW5kZXJzdGFuZCBob3cgdGhp cyBjYW4gYmUgY29uc3RydWVkIGFzICJXaXJldGFwcGluZyIuICAgIDI4MDQgc2VlbXMgdG8g bWFrZSB0aGlzIGNsZWFyLg0KDQpUTFMgaXMgbXVjaCBtb3JlIHdpZGVseSB1c2VkIHRoYXQg eW91IHNlZW0gdG8gaW1hZ2luZS4NCg0KUGxlYXNlIHNlZSB0aGUgY29tbWVudHMgdG8gdGhl IGVmZmVjdCB0aGF0IHRoZXJlIGlzIG5vIHdheSB0byBjb250cm9sIHRvIGxvY2F0aW9uIG9m IHRoZSB3aXJldGFwL1RMUy1kZWNyeXB0ZXIgaW4gdGhlIHByb3RvY29sLg0KDQpJZiB0aGF0 J3Mgbm90IG9idmlvdXMsIEkgZG9uJ3Qga25vdyBob3cgdG8gZXhwbGFpbiBpdCBmdXJ0aGVy Lg0KDQpTZWUgYWxzbyB0ZXh0IGluIDI4MDQgd3J0IHRvb2xzIGJlaW5nIHVzZWQgZm9yIG1v cmUgdGhhbiBpbml0aWFsbHkgZW52aXNhZ2VkLg0KDQpBbmQgaWYgY29lcmNpb24gb2YgYSBz ZXJ2ZXIgdG8gY29tcGx5IHdpdGggYSB3aXJldGFwIHNjaGVtZSBsaWtlIHRoaXMgc3RpbGxz IGZhbmNpZnVsIHRvIHlvdSwgcGxlYXNlIGNoZWNrIG91dCB0aGUgaGlzdG9yeSBvZiBsYXZh Yml0IC0gaGFkIHRoZXJlIGJlZW4gYSBzdGFuZGFyZCB3aXJldGFwIEFQSSBhcyBlbnZpc2Fn ZWQgaGVyZSBpdCdzIHByZXR0eSBjZXJ0YWluIHRoYXQgd291bGQgaGF2ZSBiZWVuIHRoZSBk ZXZpY2Ugb2YgY2hvaWNlIGluIGEgY2FzZSBsaWtlIHRoYXQuDQpXaGlsZSBpdCdzIGVhc3kg ZW5vdWdoIHRvIGVudmlzYWdlIG1hbnkgb3RoZXIgYWJ1c2VzIHRoYXQgY291bGQgYmUgYmFz ZWQgb24gdGhpcyB3aXJldGFwIHNjaGVtZSwgdGhhdCBvbmUgaXMgYSBnb29kIG1hdGNoIGFu ZCBhIHJlYWwgb25lLg0KDQo+IFN1Y2ggY3JpdGljYWwgY29sbG9xdXksICB3aXRoIHNpZ25p ZmljYW50IGxvbmcgdGVybSBpbXBhY3QsICBzaG91bGQgDQo+IG5vdCBiZSBwcmVtYXR1cmVs eSB0ZXJtaW5hdGVkLCAgSU1ITw0KDQoiUHJlbWF0dXJlIiBpcyBub25zZW5zZSwgdGhpcyBk ZWJhdGUgaGFzIGdvbmUgb24gdG9vIGxvbmcgYWxyZWFkeS4NCg0KUy4NCg0KDQoKClRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGhpZ2hseSBj b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBkaXJlY3RlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29weWluZywgZGlzY2xvc3VyZSBvciBkaXN0 cmlidXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFu eSB1bmludGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3 aXRob3V0IG1ha2luZyBhbnkgY29waWVzLgogCiBCbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9m IE1pY2hpZ2FuIGFuZCBCbHVlIENhcmUgTmV0d29yayBvZiBNaWNoaWdhbiBhcmUgbm9ucHJv Zml0IGNvcnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRlbnQgbGljZW5zZWVzIG9mIHRoZSBCbHVl IENyb3NzIGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lhdGlvbi4K From nobody Mon Jul 10 14:17:44 2017 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 9D264127735 for ; Mon, 10 Jul 2017 14:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz3-wW0nokjF for ; Mon, 10 Jul 2017 14:17:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637BD12EC05 for ; Mon, 10 Jul 2017 14:17:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EEB7ABE2F; Mon, 10 Jul 2017 22:17:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aixA6urwMeBx; Mon, 10 Jul 2017 22:17:37 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2D9DCBE2C; Mon, 10 Jul 2017 22:17:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499721457; bh=wMcV9F11E7wfsGe45c7ZRkUjb2luRanZlh6+xk8OVFc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wbNvVq54sAhxkKfUklD+Vb0i4ES9ZTwDmRnFom7VrB5eRqKNqz2p0/xCm9vgeJhrI AFuWvby1kO2mxYhQcIH8Mv1fhqYYSIkEvXHkMgNHc6Axz3FzeBHTYhmF2PHc2Q4xQK cz1aWyW0WMKRpp5XXqOTinQcXgtETa6KHAhbmcQ4= To: "Ackermann, Michael" , "Polk, Tim (Fed)" , "tls@ietf.org" References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 10 Jul 2017 22:17:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cciNJrR9LGLh67KX7svETKfI65QUVdCnL" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 21:17:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cciNJrR9LGLh67KX7svETKfI65QUVdCnL Content-Type: multipart/mixed; boundary="GtsXH95VCX0VUbhEBNvBEJl7PQN21uql4"; protected-headers="v1" From: Stephen Farrell To: "Ackermann, Michael" , "Polk, Tim (Fed)" , "tls@ietf.org" Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> In-Reply-To: --GtsXH95VCX0VUbhEBNvBEJl7PQN21uql4 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 10/07/17 21:20, Ackermann, Michael wrote: > Then we read 2804 differently. When I read 2804, the contained > discourses on what is and is not wiretapping, clearly says to me, > that what Enterprises do within their networks, is NOT wiretapping > according to 2804 (or to me for that matter). You're misunderstanding what 2804 says and what the IETF is about. 2804 says nothing about your, or my, network at all. You are free to define middle-endian ordering and three-valued bits if you want or to do whatever forms of wiretapping you like in your n/w. 2804 is instead about standards track protocols as specified by the IETF, which are used in many networks. In the case of TLS the changes for which you are arguing would clearly enable wiretapping in many networks and the draft is therefore clearly inconsistent with 2804 and the standards track. And to avoid a repeat of Russ' failed justification, many protocols use and depend on TLS where the entity controlling the TLS server private key materials is not the higher layer sender or receiver, so all four points in the definition in 2804 are fully met by your wiretapping scheme. If you want examples, think about STMP with STARTTLS or CDNs and the web. I'm sure there are loads of others. Bottom line: that draft is a wiretapping draft. At best, it ought be an ISE RFC, and even then I could see arguments against that if what is documented has not actually been deployed. (That last seems to me to be needed to acquire the utility of publication described in 2804 - RFCs about speculative schemes don't seem to me to offer any value at all.) S. >=20 > We (and many others in this discussion), have different > perspectives. Perhaps this is a contributing reason the Chairs > determined it should continue. I sincerely hope this will lead to > some mutually acceptable dialogue and related solutions. >=20 >=20 >=20 > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Monday, July 10, 2017 3:37 > PM To: Ackermann, Michael ; Polk, Tim (Fed) > ; tls@ietf.org Subject: Re: [TLS] chairs - > please shutdown wiretapping discussion... >=20 >=20 >=20 > On 10/07/17 16:30, Ackermann, Michael wrote: >> Given the above scenario, I do not understand how this can be >> construed as "Wiretapping". 2804 seems to make this clear. >=20 > TLS is much more widely used that you seem to imagine. >=20 > Please see the comments to the effect that there is no way to control > to location of the wiretap/TLS-decrypter in the protocol. >=20 > If that's not obvious, I don't know how to explain it further. >=20 > See also text in 2804 wrt tools being used for more than initially > envisaged. >=20 > And if coercion of a server to comply with a wiretap scheme like this > stills fanciful to you, please check out the history of lavabit - had > there been a standard wiretap API as envisaged here it's pretty > certain that would have been the device of choice in a case like > that. While it's easy enough to envisage many other abuses that could > be based on this wiretap scheme, that one is a good match and a real > one. >=20 >> Such critical colloquy, with significant long term impact, should >> not be prematurely terminated, IMHO >=20 > "Premature" is nonsense, this debate has gone on too long already. >=20 > S. >=20 >=20 >=20 >=20 > The information contained in this communication is highly > confidential and is intended solely for the use of the individual(s) > to whom this communication is directed. If you are not the intended > recipient, you are hereby notified that any viewing, copying, > disclosure or distribution of this information is prohibited. Please > notify the sender, by electronic mail or telephone, of any unintended > receipt and delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan > are nonprofit corporations and independent licensees of the Blue > Cross and Blue Shield Association. >=20 --GtsXH95VCX0VUbhEBNvBEJl7PQN21uql4-- --cciNJrR9LGLh67KX7svETKfI65QUVdCnL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEbBAEBCAAGBQJZY+7wAAoJEC88hzaAX42i4EEH+JY4zRh1EWmD2lcuN2//wKga +OcSnNGcBeQfEDE315dmD6SIO122b0K3WuCgKCRtvCzaFvyGApNsoyr0XN0FVA0v /vE5H+coSl3p65a3+6D2u3ZVC/1X6JsipuBxvRLUWwVGfn/nlR2R/Gdr6teefgdF HoFuqZtSBmDdmggeYKe4/srnunF56Kv71DemYU4lUcqUspywgtxFRj/I7WUmA3Zk k4DI/r5QU8U0nscp0H6JlE6H2DS2YB1rKclmKjSRjfZFL/A/gSa8umKTLB9yWQs9 MPMZ4f4McN8WYaYPOxcM1/lj/8Cq4u3MOz5UaIEzySbNICdctHy9p1xjRPb4Hg== =6p1C -----END PGP SIGNATURE----- --cciNJrR9LGLh67KX7svETKfI65QUVdCnL-- From nobody Mon Jul 10 14:22:21 2017 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 49DC8129482 for ; Mon, 10 Jul 2017 14:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 eAgnkR81MEQI for ; Mon, 10 Jul 2017 14:22:17 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 558BA127735 for ; Mon, 10 Jul 2017 14:22:16 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 53D941C1AC2 for ; Mon, 10 Jul 2017 16:22:16 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 998031C1AC0; Mon, 10 Jul 2017 16:22:15 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 63C4BFE04E; Mon, 10 Jul 2017 17:22:15 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 13850FE048; Mon, 10 Jul 2017 17:22:15 -0400 (EDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (unknown [216.32.181.17]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 10 Jul 2017 17:22:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Nr9IeCvamnPhFN0Y/YhaMUz68dtF2tBN/QLNC7FhYUE=; b=Tt5KOrKJuzH2F8wvWjDZ0irC7SpX4S/sffbWINHBeto8UiKnb8p/jwb2/KnmJKw6BLJoRW+I6WHD5IorwDiVGmATDuqMJbIZYarHB9Oxa/yUFjKMjTRSvvZdCPZIrLaUYYIfcjurJYE+k8t1OlRYK7sWCgkNCt/mbH5kJdr0X88= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Mon, 10 Jul 2017 21:22:12 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.020; Mon, 10 Jul 2017 21:22:12 +0000 From: "Ackermann, Michael" To: Watson Ladd CC: "Polk, Tim (Fed)" , "tls@ietf.org" Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQHS+YQI7m7fVGNOTUGFuL/08f/fM6JNIUiQgABdFICAABKOcA== Date: Mon, 10 Jul 2017 21:22:12 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [2602:304:ce75:4b0:bde0:e0f2:e07:2e6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 20:Z9+qATmb02wm90W9/igTQClrgqnCnXa4pzYf8EkaR0KioTHX6upqL0pRRMUkrm/B46AwTikk0BhRto45SNx/oHqZUTdrmWS5Zc3pw4GzDMnhONdbG9M+GAC0UJWItjHwkTJvnHHGvSFKPs5Pc/Ru6hWBp05P+fqeJQ3AaeJY50k= x-ms-office365-filtering-correlation-id: 7190aeef-0291-4707-d81f-08d4c7d9bb22 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1365; x-ms-traffictypediagnostic: CY4PR14MB1365: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(65766998875637)(278428928389397)(72170088055959)(26388249023172)(236129657087228)(192374486261705)(90097320859284)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1365; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39840400002)(39410400002)(39450400003)(377454003)(24454002)(85714005)(54906002)(68736007)(236005)(9686003)(99286003)(6306002)(86362001)(189998001)(966005)(55016002)(54896002)(72206003)(8656002)(6246003)(8676002)(53936002)(50986999)(478600001)(606006)(6436002)(76176999)(54356999)(2900100001)(6116002)(6506006)(8936002)(102836003)(74316002)(790700001)(33656002)(80792005)(81166006)(77096006)(39060400002)(5660300001)(2906002)(3280700002)(7736002)(561944003)(4326008)(19609705001)(110136004)(38730400002)(229853002)(3660700001)(6916009)(1411001)(2950100002)(7696004)(14454004)(53546010)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368742B73E68DA32261FBD6D7A90CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2017 21:22:12.6335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 66b06de3-aa58-43e2-83f7-8b57885dd7df X-VPM-MSG-ID: 7273391d-f86b-4eeb-8550-09015af78a6a X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 21:22:20 -0000 --_000_CY4PR14MB1368742B73E68DA32261FBD6D7A90CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TW9zdCBFbnRlcnByaXNlcyBkbyBoYXZlIHdlbGwgZGV2ZWxvcGVkIGxvZ2dpbmcgY29sbGVj dGlvbiBhbmQgcGFyc2luZyBpbmZyYXN0cnVjdHVyZXMgKGUuZy4gU3BsdW5rLCBldGMuKS4g ICAgIEJ1dCB0aGV5IGFyZSBvbmUgb2YgbWFueSB0b29scyBuZWVkZWQgdG8gZWZmZWN0aXZl bHkgbWFuYWdlIGNvbXBsZXggY29ycG9yYXRlIG5ldHdvcmtzIGFuZCBhcHBsaWNhdGlvbnMu ICAgIFRoZXkgY2Fubm90IGZ1bGx5IHJlcGxhY2UgbmV0d29yayBtb25pdG9yaW5nIGFueSBt b3JlIHRoYW4gbmV0d29yayBtb25pdG9yaW5nIGNhbiByZXBsYWNlIGxvZ2dpbmcsIElNSE8u DQoNCkkgZG8gYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBvcHRpbWFsIGZvciBhbGwgcGVyc3Bl Y3RpdmVzIGFuZCByZXF1aXJlbWVudHMgdG8gYmUgaW50cm9kdWNlZCBhcyBlYXJseSBpbiB0 aGUgcHJvY2VzcyBhcyBwb3NzaWJsZS4gICAgSGVuY2Ugb25lIG9mIHRoZSBtb3RpdmF0aW9u cyBmb3IgYXR0ZW1wdGluZyB0byBnZXQgRW50ZXJwcmlzZXMgbW9yZSBhY3RpdmUgaW4gSUVU RiwgIGluIGdlbmVyYWwuDQoNCg0KRnJvbTogV2F0c29uIExhZGQgW21haWx0bzp3YXRzb25i bGFkZEBnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIEp1bHkgMTAsIDIwMTcgNDoxMSBQTQ0K VG86IEFja2VybWFubiwgTWljaGFlbCA8TUFja2VybWFubkBiY2JzbS5jb20+DQpDYzogUG9s aywgVGltIChGZWQpIDx3aWxsaWFtLnBvbGtAbmlzdC5nb3Y+OyB0bHNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbVExTXSBjaGFpcnMgLSBwbGVhc2Ugc2h1dGRvd24gd2lyZXRhcHBpbmcg ZGlzY3Vzc2lvbi4uLg0KDQoNCg0KT24gSnVsIDEwLCAyMDE3IDg6NDYgQU0sICJBY2tlcm1h bm4sIE1pY2hhZWwiIDxNQWNrZXJtYW5uQGJjYnNtLmNvbTxtYWlsdG86TUFja2VybWFubkBi Y2JzbS5jb20+PiB3cm90ZToNCisxICEhIQ0KDQpBbmQNCkZvciB0aGUgZW50ZXJwcmlzZSBz aXR1YXRpb25zLCAgd2UgdHlwaWNhbGx5IG93biwgb3BlcmF0ZSBhbmQgbWFuYWdlIHRoZSBp bnZvbHZlZCDigJxGYWNpbGl0aWVz4oCdOg0KVGhlIFNlcnZlcnMNClRoZSBBcHBsaWNhdGlv bnMNClRoZSBOZXR3b3Jrcw0KVGhlIEtleXMNClRoZSBEYXRhDQphbmQgaW4gTWFueSBjYXNl cyB0aGUgY2xpZW50cyBhcyB3ZWxsDQoNCkdpdmVuIHRoZSBhYm92ZSBzY2VuYXJpbywgIEkg ZG8gbm90IHVuZGVyc3RhbmQgaG93IHRoaXMgY2FuIGJlIGNvbnN0cnVlZCBhcyDigJxXaXJl dGFwcGluZ+KAnS4gICAgMjgwNCBzZWVtcyB0byBtYWtlIHRoaXMgY2xlYXIuDQoNCldoYXQg RW50ZXJwcmlzZXMgd2FudCBpbiB0aGlzIHNwYWNlLCBpcyB0aGUgYWJpbGl0eSB0byBjb250 aW51ZSB0byBoYXZlIGFjY2VzcyB0byB0aGVpciBhZm9yZW1lbnRpb25lZCBmYWNpbGl0aWVz LCAgdG8gcGVyZm9ybSBkaWFnbm9zdGljcywgbW9uaXRvcmluZyBhbmQgc2VjdXJpdHkgZnVu Y3Rpb25zLiAgIChpLmUuIGNvbnRpbnVlIHRvIGVmZmVjdGl2ZWx5IG9wZXJhdGUgYW5kIG1h bmFnZSBvdXIgbmV0d29ya3MpLiAgQWx0aG91Z2ggSSBiZWxpZXZlIHRoZSBNYXR0IEdyZWVu IGRyYWZ0IHByb3Bvc2VzIGEgdmVyeSBnb29kLCB2aWFibGUgYW5kIHdlbGwgdGhvdWdodCBv dXQgc29sdXRpb24gZm9yIFRMUyAxLjMsICBJIHN1c3BlY3QgbW9zdCBvZiB1cyBhcmUgb3Bl biB0byBkaWZmZXJlbnQgb3IgYmV0dGVyIHNvbHV0aW9ucywgIGlmIHN1Y2ggZXhpc3RzIG9y IGNhbiBiZSBjb25jZWl2ZWQuDQpUaGVyZSBzZWVtcyB0byBiZSBnb29kIGRpc2N1c3Npb24s IHJlcXVpcmVtZW50cyBhbmQgaWRlYXMgb24gYm90aCBzaWRlcyBvZiB0aGlzIGlzc3VlLCAg YWxiZWl0IGluIHNoYXJwIGRpc2FncmVlbWVudCBpbiBtYW55IGNhc2VzLiAgICAgIFN1Y2gg Y3JpdGljYWwgY29sbG9xdXksICB3aXRoIHNpZ25pZmljYW50IGxvbmcgdGVybSBpbXBhY3Qs ICBzaG91bGQgbm90IGJlIHByZW1hdHVyZWx5IHRlcm1pbmF0ZWQsICBJTUhPLg0KDQoNCkZp bmFsbHkgYW4gZWRpdG9yaWFsIGNvbW1lbnQgZnJvbSB0aG9zZSBvZiB1cyBUUllJTkcgdG8g Z2V0IEVudGVycHJpc2VzIGludm9sdmVkIGF0IElFVEYuICAgV2UgZmluYWxseSBoYXZlIHNv bWUgaW50ZXJlc3QgYW5kIGVuZ2FnZW1lbnQgZnJvbSBFbnRlcnByaXNlIHBlcnNwZWN0aXZl cy4gICAgIEtpbGxpbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIGlzc3VlLCAgd2hpY2ggaXMgY2xl YXJseSBpbXBvcnRhbnQgdG8gRW50ZXJwcmlzZXMsIHdpbGwgc2VuZCB0aGUgbWVzc2FnZSB0 aGF0IElFVEYgZGlkIG5vdCByZWFsbHkgd2FudCB0aGlzIGlucHV0IG9yIGZlZWRiYWNrLiAg ICAgIEkgaG9wZSB0aGlzIGlzIG5vdCB0aGUgY2FzZS4NCg0KT25lIHZlcnRpY2FsIGlzIG5v dCBhbGwgZW50ZXJwcmlzZXMuIFBsZW50eSBvZiBjb21wYW5pZXMgY2FuIHRyYWNlIHJlcXVl c3RzIHZpYSBsb2dnaW5nIHN5c3RlbXMgYW5kIGRvIG5vdCBuZWVkIG1pcnJvcmluZyBmb3Ig ZGlhZ25vc3RpY3MuDQoNClBlcmhhcHMgaWYgd2Ugd2VyZW4ndCBmYWNlZCB3aXRoIGEgbGFz dCBtaW51dGUgcmVxdWVzdCB0byBpbmNsdWRlIHN0YXRpYyBjaXBoZXJzdWl0ZXMgdGhpbmdz IHdvdWxkIGJlIGRpZmZlcmVudC4gQnV0IHRoZSB0ZWNobmlxdWUgZXhpc3RzIGFuZCBjYW4g YmUgdXNlZCByZWdhcmRsZXNzIG9mIGFwcHJvdmFsLiAoSGF2ZSB5b3UgY29uc2lkZXJlZCBE dWFsIEVDK2V4dGVuZGVkIHJhbmRvbT8pDQoNClRoZSBwcm9ibGVtLT5ib3ggbW9kZWwgaGFz IG5ldmVyIGJlZW4gd2VsbC1zdWl0ZWQgZm9yIHRoZSBpbnRlcm5ldC4gVGhlcmUgYXJlIHNl cmlvdXMgcG9saWN5IGNvbnNpZGVyYXRpb25zIGhlcmUgYW5kIGEgbG9uZyBhZ2VuZGEgZm9y IHRoaXMgV0cuIFN0b3BwaW5nIGRpc2N1c3Npb24gaXMgbm90IGFib3V0IGlnbm9yaW5nIHRo ZSBwcm9ibGVtOiBpdCdzIHN0b3BwaW5nIGEgZGlzY3Vzc2lvbiBnb2luZyBub3doZXJlIGZy b20gZWF0aW5nIHVwIGFsbCB0aGUgYmFuZHdpZHRoLg0KDQpGcm9tOiBUTFMgW21haWx0bzp0 bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgUG9saywgVGltIChGZWQpDQpTZW50OiBNb25kYXksIEp1bHkgMTAsIDIwMTcg OTo1NCBBTQ0KVG86IHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtUTFNdIGNoYWlycyAtIHBsZWFzZSBzaHV0ZG93biB3aXJldGFwcGluZyBkaXNj dXNzaW9uLi4uDQoNCkZpcnN0LCBJIGRvIG5vdCBzZWUgdGhpcyBhcyBhIOKAnHdpcmV0YXBw aW5nIGRpc2N1c3Npb27igJ0gYmFzZWQgb24gbXkgcmVhZGluZyBvZiAyODA0LCBhbHRob3Vn aCBvdGhlcnMgbWF5IGRpc2FncmVlLg0KDQpTZWNvbmQsIEkgYmVsaWV2ZSB0aGF0IHRoaXMg ZGlzY3Vzc2lvbiBzaG91bGQgZ28gZm9yd2FyZCBiYXNlZCBvbiBzZXZlcmFsIHBvaW50czoN Cg0KICAxLiAgdGhpcyBwcm9wb3NhbCBkb2VzIG5vdCBpbnZvbHZlIGFueSBjaGFuZ2VzIHRv IHRoZSBiaXRzIG9uIHRoZSB3aXJlIHNwZWNpZmllZCBpbiB0aGUgVExTIDEuMyBkb2N1bWVu dA0KICAyLiAgdGhpcyBwcm9wb3NhbCBvZmZlcnMgc2lnbmlmaWNhbnRseSBiZXR0ZXIgc2Vj dXJpdHkgcHJvcGVydGllcyB0aGFuIGN1cnJlbnQgcHJhY3RpY2UgKGNlbnRyYWwgZGlzdHJp YnV0aW9uIG9mIHN0YXRpYyBSU0Ega2V5cykNCiAgMy4gIGFsdGVybmF0aXZlIHNvbHV0aW9u cyB3aXRoIHNpZ25pZmljYW50bHkgd29yc2Ugc2VjdXJpdHkgcHJvcGVydGllcyBhcmUgYWxz byBmZWFzaWJsZSB1bmRlciBUTFMgMS4zLCBhbmQgSSB3b3VsZCBsaWtlIHRvIGF2b2lkIHRo ZW0hDQoNCldlIHNob3VsZCBiZSBpbiB0aGUgYnVzaW5lc3Mgb2YgZGV2ZWxvcGluZyBwcmFn bWF0aWMsIGludGVyb3BlcmFibGUgc29sdXRpb25zIHdpdGggYXBwcm9wcmlhdGUgc2VjdXJp dHkgcHJvcGVydGllcy4gIEJhbGFuY2luZyBjcnlwdG9ncmFwaGljIHNlY3VyaXR5IHdpdGgg b3RoZXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIHRvIGFjaGlldmUgc3VjaCBzb2x1dGlvbnMg c2hvdWxkIGJlIGFuIGFjY2VwdGFibGUgcGF0aCwgYW5kIHB1cnN1aW5nIHRoaXMgd29yayBp biB0aGUgVExTIHdvcmtpbmcgZ3JvdXAgZ2l2ZXMgdGhlIElFVEYgdGhlIGJlc3Qgb3Bwb3J0 dW5pdHkgdG8gaW5mbHVlbmNlIHRoZXNlIHNvbHV0aW9ucy4NCg0KDQoNCg0KDQpUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29u ZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJp YnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkg dW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0 aG91dCBtYWtpbmcgYW55IGNvcGllcy4NCg0KQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBN aWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2Zp dCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBD cm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNA aWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGxzDQoNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhp cyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5n LCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0 aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ry b25pYyBtYWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQg ZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMu CiAKIEJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBO ZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRl cGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFz c29jaWF0aW9uLgo= --_000_CY4PR14MB1368742B73E68DA32261FBD6D7A90CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE3NzA2NjMwMzY7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjIwNDgwMzEyNDI7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+TW9zdCBFbnRlcnByaXNlcyBkbyBoYXZlIHdlbGwgZGV2ZWxvcGVkIGxvZ2dpbmcgY29s bGVjdGlvbiBhbmQgcGFyc2luZyBpbmZyYXN0cnVjdHVyZXMgKGUuZy4gU3BsdW5rLCBldGMu KS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQnV0IHRoZXkgYXJlIG9uZSBvZiBtYW55IHRv b2xzIG5lZWRlZCB0byBlZmZlY3RpdmVseSBtYW5hZ2UNCiBjb21wbGV4IGNvcnBvcmF0ZSBu ZXR3b3JrcyBhbmQgYXBwbGljYXRpb25zLiZuYnNwOyZuYnNwOyZuYnNwOyBUaGV5IGNhbm5v dCBmdWxseSByZXBsYWNlIG5ldHdvcmsgbW9uaXRvcmluZyBhbnkgbW9yZSB0aGFuIG5ldHdv cmsgbW9uaXRvcmluZyBjYW4gcmVwbGFjZSBsb2dnaW5nLCBJTUhPLiZuYnNwOw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG8gYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBvcHRp bWFsIGZvciBhbGwgcGVyc3BlY3RpdmVzIGFuZCByZXF1aXJlbWVudHMgdG8gYmUgaW50cm9k dWNlZCBhcyBlYXJseSBpbiB0aGUgcHJvY2VzcyBhcyBwb3NzaWJsZS4mbmJzcDsmbmJzcDsm bmJzcDsgSGVuY2Ugb25lIG9mIHRoZSBtb3RpdmF0aW9ucyBmb3IgYXR0ZW1wdGluZw0KIHRv IGdldCBFbnRlcnByaXNlcyBtb3JlIGFjdGl2ZSBpbiBJRVRGLCZuYnNwOyBpbiBnZW5lcmFs LiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IFdhdHNvbiBMYWRkIFttYWlsdG86d2F0c29uYmxhZGRAZ21haWwuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAxMCwgMjAxNyA0OjExIFBNPGJy Pg0KPGI+VG86PC9iPiBBY2tlcm1hbm4sIE1pY2hhZWwgJmx0O01BY2tlcm1hbm5AYmNic20u Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUG9saywgVGltIChGZWQpICZsdDt3aWxsaWFtLnBv bGtAbmlzdC5nb3YmZ3Q7OyB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtUTFNdIGNoYWlycyAtIHBsZWFzZSBzaHV0ZG93biB3aXJldGFwcGluZyBkaXNjdXNzaW9u Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAx MCwgMjAxNyA4OjQ2IEFNLCAmcXVvdDtBY2tlcm1hbm4sIE1pY2hhZWwmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpNQWNrZXJtYW5uQGJjYnNtLmNvbSI+TUFja2VybWFubkBiY2JzbS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiYjNDM7MSAhISE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbmQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5Gb3IgdGhlIGVudGVycHJpc2Ugc2l0dWF0aW9ucywmbmJzcDsgd2UgdHlwaWNh bGx5IG93biwgb3BlcmF0ZSBhbmQgbWFuYWdlIHRoZSBpbnZvbHZlZCDigJxGYWNpbGl0aWVz 4oCdOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBTZXJ2ZXJzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+VGhlIEFwcGxpY2F0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPlRoZSBOZXR3b3Jrcw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIEtleXM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgRGF0YTxicj4NCmFuZCBpbiBNYW55IGNh c2VzIHRoZSBjbGllbnRzIGFzIHdlbGw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5HaXZlbiB0aGUgYWJvdmUgc2NlbmFyaW8s Jm5ic3A7IEkgZG8gbm90IHVuZGVyc3RhbmQgaG93IHRoaXMgY2FuIGJlIGNvbnN0cnVlZCBh cyDigJxXaXJldGFwcGluZ+KAnS4mbmJzcDsmbmJzcDsmbmJzcDsgMjgwNCBzZWVtcyB0byBt YWtlIHRoaXMgY2xlYXIuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XaGF0IEVudGVycHJpc2VzIHdhbnQgaW4gdGhpcyBz cGFjZSwgaXMgdGhlIGFiaWxpdHkgdG8gY29udGludWUgdG8gaGF2ZSBhY2Nlc3MgdG8gdGhl aXIgYWZvcmVtZW50aW9uZWQgZmFjaWxpdGllcywmbmJzcDsgdG8gcGVyZm9ybSBkaWFnbm9z dGljcywgbW9uaXRvcmluZw0KIGFuZCBzZWN1cml0eSBmdW5jdGlvbnMuJm5ic3A7Jm5ic3A7 IChpLmUuIGNvbnRpbnVlIHRvIGVmZmVjdGl2ZWx5IG9wZXJhdGUgYW5kIG1hbmFnZSBvdXIg bmV0d29ya3MpLiZuYnNwOyBBbHRob3VnaCBJIGJlbGlldmUgdGhlIE1hdHQgR3JlZW4gZHJh ZnQgcHJvcG9zZXMgYSB2ZXJ5IGdvb2QsIHZpYWJsZSBhbmQgd2VsbCB0aG91Z2h0IG91dCBz b2x1dGlvbiBmb3IgVExTIDEuMywmbmJzcDsgSSBzdXNwZWN0IG1vc3Qgb2YgdXMgYXJlIG9w ZW4gdG8gZGlmZmVyZW50IG9yIGJldHRlcg0KIHNvbHV0aW9ucywmbmJzcDsgaWYgc3VjaCBl eGlzdHMgb3IgY2FuIGJlIGNvbmNlaXZlZC4mbmJzcDsmbmJzcDsgPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+VGhlcmUgc2VlbXMgdG8gYmUgZ29vZCBkaXNjdXNzaW9uLCByZXF1aXJl bWVudHMgYW5kIGlkZWFzIG9uIGJvdGggc2lkZXMgb2YgdGhpcyBpc3N1ZSwmbmJzcDsgYWxi ZWl0IGluIHNoYXJwIGRpc2FncmVlbWVudCBpbiBtYW55IGNhc2VzLiZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtTdWNoIGNyaXRpY2FsDQogY29sbG9xdXksJm5ic3A7IHdpdGgg c2lnbmlmaWNhbnQgbG9uZyB0ZXJtIGltcGFjdCwmbmJzcDsgc2hvdWxkIG5vdCBiZSBwcmVt YXR1cmVseSB0ZXJtaW5hdGVkLCZuYnNwOyBJTUhPLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RmluYWxseSBhbiBlZGl0b3JpYWwgY29tbWVudCBm cm9tIHRob3NlIG9mIHVzIFRSWUlORyB0byBnZXQgRW50ZXJwcmlzZXMgaW52b2x2ZWQgYXQg SUVURi4mbmJzcDsmbmJzcDsgV2UgZmluYWxseSBoYXZlIHNvbWUgaW50ZXJlc3QgYW5kIGVu Z2FnZW1lbnQgZnJvbSBFbnRlcnByaXNlDQogcGVyc3BlY3RpdmVzLiZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDtLaWxsaW5nIGRpc2N1c3Npb24gb24gdGhpcyBpc3N1ZSwmbmJzcDsgd2hp Y2ggaXMgY2xlYXJseSBpbXBvcnRhbnQgdG8gRW50ZXJwcmlzZXMsIHdpbGwgc2VuZCB0aGUg bWVzc2FnZSB0aGF0IElFVEYgZGlkIG5vdCByZWFsbHkgd2FudCB0aGlzIGlucHV0IG9yIGZl ZWRiYWNrLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGhvcGUgdGhpcyBpcyBu b3QgdGhlIGNhc2UuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSB2ZXJ0aWNhbCBpcyBub3QgYWxsIGVudGVycHJp c2VzLiBQbGVudHkgb2YgY29tcGFuaWVzIGNhbiB0cmFjZSByZXF1ZXN0cyB2aWEgbG9nZ2lu ZyBzeXN0ZW1zIGFuZCBkbyBub3QgbmVlZCBtaXJyb3JpbmcgZm9yIGRpYWdub3N0aWNzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QZXJoYXBzIGlmIHdlIHdlcmVuJ3QgZmFjZWQgd2l0aCBhIGxhc3QgbWludXRlIHJlcXVl c3QgdG8gaW5jbHVkZSBzdGF0aWMgY2lwaGVyc3VpdGVzIHRoaW5ncyB3b3VsZCBiZSBkaWZm ZXJlbnQuIEJ1dCB0aGUgdGVjaG5pcXVlIGV4aXN0cyBhbmQgY2FuIGJlIHVzZWQgcmVnYXJk bGVzcyBvZiBhcHByb3ZhbC4gKEhhdmUgeW91IGNvbnNpZGVyZWQgRHVhbCBFQyYjNDM7ZXh0 ZW5kZWQgcmFuZG9tPyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0tJmd0O2JveCBtb2RlbCBoYXMgbmV2ZXIg YmVlbiB3ZWxsLXN1aXRlZCBmb3IgdGhlIGludGVybmV0LiBUaGVyZSBhcmUgc2VyaW91cyBw b2xpY3kgY29uc2lkZXJhdGlvbnMgaGVyZSBhbmQgYSBsb25nIGFnZW5kYSBmb3IgdGhpcyBX Ry4gU3RvcHBpbmcgZGlzY3Vzc2lvbiBpcyBub3QgYWJvdXQgaWdub3JpbmcgdGhlIHByb2Js ZW06IGl0J3Mgc3RvcHBpbmcgYSBkaXNjdXNzaW9uIGdvaW5nIG5vd2hlcmUNCiBmcm9tIGVh dGluZyB1cCBhbGwgdGhlIGJhbmR3aWR0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtXzE0NTYxMzk3MjI5MDAxOTQzOTZf X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiBUTFMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPlBvbGssIFRpbSAoRmVkKTxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIEp1bHkgMTAsIDIwMTcgOTo1NCBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnRsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRsc0BpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIGNoYWlycyAtIHBsZWFzZSBzaHV0ZG93biB3 aXJldGFwcGluZyBkaXNjdXNzaW9uLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Rmlyc3QsIEkgZG8gbm90IHNlZSB0aGlzIGFzIGEg4oCcd2lyZXRh cHBpbmcgZGlzY3Vzc2lvbuKAnSBiYXNlZCBvbiBteSByZWFkaW5nIG9mIDI4MDQsIGFsdGhv dWdoIG90aGVycyBtYXkgZGlzYWdyZWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2Vjb25kLCBJIGJlbGlldmUgdGhhdCB0 aGlzIGRpc2N1c3Npb24gc2hvdWxkIGdvIGZvcndhcmQgYmFzZWQgb24gc2V2ZXJhbCBwb2lu dHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij50aGlzIHByb3Bv c2FsIGRvZXMgbm90IGludm9sdmUgYW55IGNoYW5nZXMgdG8gdGhlIGJpdHMgb24gdGhlIHdp cmUgc3BlY2lmaWVkIGluIHRoZSBUTFMgMS4zIGRvY3VtZW50PC9zcGFuPjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+dGhp cyBwcm9wb3NhbCBvZmZlcnMgc2lnbmlmaWNhbnRseSBiZXR0ZXIgc2VjdXJpdHkgcHJvcGVy dGllcyB0aGFuIGN1cnJlbnQgcHJhY3RpY2UgKGNlbnRyYWwgZGlzdHJpYnV0aW9uIG9mIHN0 YXRpYyBSU0Ega2V5cyk8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5hbHRlcm5hdGl2ZSBzb2x1dGlvbnMgd2l0 aCBzaWduaWZpY2FudGx5IHdvcnNlIHNlY3VyaXR5IHByb3BlcnRpZXMgYXJlIGFsc28gZmVh c2libGUgdW5kZXIgVExTIDEuMywgYW5kIEkgd291bGQgbGlrZSB0byBhdm9pZCB0aGVtITwv c3Bhbj48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPldlIHNob3VsZCBiZSBpbiB0aGUgYnVzaW5lc3Mgb2YgZGV2ZWxvcGluZyBw cmFnbWF0aWMsIGludGVyb3BlcmFibGUgc29sdXRpb25zIHdpdGggYXBwcm9wcmlhdGUgc2Vj dXJpdHkgcHJvcGVydGllcy4mbmJzcDsgQmFsYW5jaW5nIGNyeXB0b2dyYXBoaWMgc2VjdXJp dHkNCiB3aXRoIG90aGVyIHNlY3VyaXR5IHJlcXVpcmVtZW50cyB0byBhY2hpZXZlIHN1Y2gg c29sdXRpb25zIHNob3VsZCBiZSBhbiBhY2NlcHRhYmxlIHBhdGgsIGFuZCBwdXJzdWluZyB0 aGlzIHdvcmsgaW4gdGhlIFRMUyB3b3JraW5nIGdyb3VwIGdpdmVzIHRoZSBJRVRGIHRoZSBi ZXN0IG9wcG9ydHVuaXR5IHRvIGluZmx1ZW5jZSB0aGVzZSBzb2x1dGlvbnMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cD5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0aGlz IGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdpbmcs IGNvcHlpbmcsDQogZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBpbmZvcm1h dGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0 cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFueSB1bmludGVuZGVkIHJlY2VpcHQgYW5k IGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRob3V0IG1ha2luZyBhbnkgY29waWVz LjxvOnA+PC9vOnA+PC9wPg0KPHA+Qmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdh biBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jw b3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBh bmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0KCgo8QlI+CjxodG1s PgogPHA+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24g aXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlz IGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9z dXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQu IFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVw aG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5h bCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuPC9wPgogPHA+Qmx1ZSBDcm9z cyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWlj aGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vu c2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uPC9w PgogIDwvaHRtbD4KCg== --_000_CY4PR14MB1368742B73E68DA32261FBD6D7A90CY4PR14MB1368namp_-- From nobody Mon Jul 10 14:22:52 2017 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 8B54512F299 for ; Mon, 10 Jul 2017 14:22:50 -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 L4_bSTGlUS1Y for ; Mon, 10 Jul 2017 14:22:48 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 BC5C412EC05 for ; Mon, 10 Jul 2017 14:22:48 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id v202so46028217itb.0 for ; Mon, 10 Jul 2017 14:22:48 -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:cc :content-transfer-encoding:message-id:references:to; bh=KyJnBkajSoQ2a6tL9Oh54GDkZ6cBfPX+448ZJvvkpoE=; b=lU18WH95bHTOo5YcyyakEMa1c/ZhZivsGMGmJj4ks0P8407x5O6K3CH3dFTCvuThqW AXYCo41GfQ1fhbM1UbqPuotg+IwlG/CZXLDOTbk3Ab1uLRLAgsnVdGbzw5UYjWBlwN4M YsxtsDH5T5IPZYGvdLiB3txWBeynPiykfhZMc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KyJnBkajSoQ2a6tL9Oh54GDkZ6cBfPX+448ZJvvkpoE=; b=icxENjdFTxDDX7W/5m/fINMhT53kAETObE3d3gjjwzpvXZR+5YTcYjvrnIdmJ/4VCq M4viLFmfIipgWVrQFfumywpAIeeN6QK20efby3/c6ri3NP9XMEKZImWk6Iz0YDxOK4yz e1xdO3goPpMxIrgzSb+47RG7aH8GdHrE74S5HHhbEUpD5X7UEz8/TRae+5GmVe6ieSlu gUIym8UojT2SeTkaa/NcgfMdsBH1nc2iX7G+9HbX6XDmSdp8rnFr34FvzoqXrQDm/qtm Db02iELVpCPM/exJPwTD5+eUrn+XgKR+9ESzSCmfj48hMp0AftxExPJw4OaE6oABissD NZGA== X-Gm-Message-State: AIVw111iAQ8/F8fLO3CusRuTwuwD6mo3JyBOZ+QeXbxZU3/1qRl42zzV DvLVHHEmHJoIFjsX X-Received: by 10.107.164.199 with SMTP id d68mr5256665ioj.194.1499721768112; Mon, 10 Jul 2017 14:22:48 -0700 (PDT) Received: from [5.5.33.92] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id y92sm4568132ita.31.2017.07.10.14.22.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 14:22:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <660d6280-6865-3a76-fbe3-035a549fcd2c@cs.tcd.ie> Date: Mon, 10 Jul 2017 17:22:45 -0400 Cc: TLS Chairs , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <84D045B3-5275-414C-8975-4DFC96BA7B30@sn3rd.com> References: <867B8F06-63F2-4EDF-9B92-CB2EF7F08D30@sn3rd.com> <660d6280-6865-3a76-fbe3-035a549fcd2c@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 21:22:50 -0000 > On Jul 10, 2017, at 15:29, Stephen Farrell = wrote: >=20 > You did not respond about the Prague agenda. I continue to ask that > you not give this bad idea more f2f time. If you do give it time, > then I'd ask for equal time to debunk this bad idea. But better to > have zero time. Thanks for point this out. We have adjusted the agenda but only to make = room for=20 draft-ietf-tls-dnssec-chain-extension and to rearrange the topics: https://www.ietf.org/proceedings/99/agenda/agenda-99-tls-01 Note that the time allocated for this topics includes discussion time, = where I have no there will be a mad dash to get to the mic. spt From nobody Mon Jul 10 14:26:42 2017 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 930B112EC05 for ; Mon, 10 Jul 2017 14:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 ctOVuNxZLfGr for ; Mon, 10 Jul 2017 14:26:40 -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 0200C127735 for ; Mon, 10 Jul 2017 14:26:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5147030056B for ; Mon, 10 Jul 2017 17:26:39 -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 yHqRQOKQQIza for ; Mon, 10 Jul 2017 17:26:38 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E1AFA300429; Mon, 10 Jul 2017 17:26:37 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AF5252FE-550B-4753-BDEA-DF1501AE61D9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Jul 2017 17:26:37 -0400 In-Reply-To: Cc: "Polk, Tim (Fed)" , IETF TLS To: Stephen Farrell References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 21:26:42 -0000 --Apple-Mail=_AF5252FE-550B-4753-BDEA-DF1501AE61D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Stephen: > And to avoid a repeat of Russ' failed justification, many > protocols use and depend on TLS where the entity controlling > the TLS server private key materials is not the higher > layer sender or receiver, so all four points in the definition > in 2804 are fully met by your wiretapping scheme. It is clear that you do not agree with the reasoning that I posted on = Friday. Some people do, and clearly, others do not. So, I failed to convince you. However, you have also failed to convince = me that the proposal is wiretapping under the definition in RFC 2804, = Section 3. Russ --Apple-Mail=_AF5252FE-550B-4753-BDEA-DF1501AE61D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Stephen:

And to avoid a repeat of Russ' = failed justification, many
protocols use and depend on TLS = where the entity controlling
the TLS server private key = materials is not the higher
layer sender or receiver, so all = four points in the definition
in 2804 are fully met by your = wiretapping scheme.

It is clear that you do not agree with = the reasoning that I posted on Friday.  Some people do, and = clearly, others do not.

So, I failed to convince you.  However, you have also = failed to convince me that the proposal is wiretapping under the = definition in RFC 2804, Section 3.

Russ

= --Apple-Mail=_AF5252FE-550B-4753-BDEA-DF1501AE61D9-- From nobody Mon Jul 10 14:35:29 2017 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 7658A1318EC for ; Mon, 10 Jul 2017 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBXvAb7qxAJD for ; Mon, 10 Jul 2017 14:35:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C06112F27C for ; Mon, 10 Jul 2017 14:35:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BF834BE2F; Mon, 10 Jul 2017 22:35:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82PcvS0tLjfq; Mon, 10 Jul 2017 22:35:23 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7AD72BE2C; Mon, 10 Jul 2017 22:35:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499722523; bh=uZU2SzdFjjzjDo127dmP2Rh7f1VfODiCj6ybpQOQ3Ng=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EMfuzKRdKfsrryW+0aWh3q2UxhnT15GajT+r9FCCbu3eIDc+sfMOTv1ZbZxM+9VAX ynJJwsfhVuUgj9zcT03LhgJIgoiEynSAMfiU/VdzD5xlXGcHz8LYdSSKWtJ1L5P5B7 2mNXU1M41Il57TmmEBWFlPrcMm6CO00EXw1m14aA= To: Russ Housley Cc: "Polk, Tim (Fed)" , IETF TLS References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 10 Jul 2017 22:35:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sC3OJAjtExnpiqCMAHVEQr9pjhc6VqILf" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 21:35:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sC3OJAjtExnpiqCMAHVEQr9pjhc6VqILf Content-Type: multipart/mixed; boundary="OiEUMst4x8RfaN1B1cajaRA5GHuV3kLi3"; protected-headers="v1" From: Stephen Farrell To: Russ Housley Cc: "Polk, Tim (Fed)" , IETF TLS Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> In-Reply-To: --OiEUMst4x8RfaN1B1cajaRA5GHuV3kLi3 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 10/07/17 22:26, Russ Housley wrote: > Stephen: >=20 >> And to avoid a repeat of Russ' failed justification, many protocols >> use and depend on TLS where the entity controlling the TLS server >> private key materials is not the higher layer sender or receiver, >> so all four points in the definition in 2804 are fully met by your >> wiretapping scheme. >=20 > It is clear that you do not agree with the reasoning that I posted on > Friday. Some people do, and clearly, others do not. >=20 > So, I failed to convince you. However, you have also failed to > convince me that the proposal is wiretapping under the definition in > RFC 2804, Section 3. Consider SMTP/TLS. Where one MTA on the path supports this. Say it's one operated by an anti-spam company for example. That is clearly not the sender nor recipient. That meets all 4 points in 2804, right? S. >=20 > Russ >=20 >=20 --OiEUMst4x8RfaN1B1cajaRA5GHuV3kLi3-- --sC3OJAjtExnpiqCMAHVEQr9pjhc6VqILf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZY/MaAAoJEC88hzaAX42i0XQIAKSL0n6InEUhtIfs8zxSvcCI mr5yXN+1xJjsDdqCrtqX5iwtpaAFUHBY1DsPgi/prL8ulGrkoBseZs0LUlKvbWW6 VgH/4MCrgJ7pU9+d2IzfQbKSEsp47iB1X1lCC0cS2Da0rW8No2cQYV3DxyrrLOaA k5iyAiu7ohJJt97rJzFX+aNINXE+JWDzV8612A2g4DRbWmAiX/PlpJhZmrh6wDIt kmh/bKDf9GQdZc5fY703eZ4K3ciW08cSbKn0UjAukL/YPKXGY9kwHqVnG0cczF+v Jy5Id0+kgE51GMDZJ6chVI1gI6+HG5fu0BI0i5kxGJb7dUFCqWAVu8TwMlpClZE= =6GUx -----END PGP SIGNATURE----- --sC3OJAjtExnpiqCMAHVEQr9pjhc6VqILf-- From nobody Mon Jul 10 15:07:28 2017 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 3AF1D13192B for ; Mon, 10 Jul 2017 15:07:27 -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 ovdH_UFvvoKS for ; Mon, 10 Jul 2017 15:07:26 -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 D89D113191C for ; Mon, 10 Jul 2017 15:07:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4F1E23004BC for ; Mon, 10 Jul 2017 18:07:25 -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 Py0cMhKkUXDs for ; Mon, 10 Jul 2017 18:07:24 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 46000300258; Mon, 10 Jul 2017 18:07:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Mon, 10 Jul 2017 18:07:23 -0400 Cc: "Polk, Tim (Fed)" , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 22:07:27 -0000 Stephen: >>=20 >>> And to avoid a repeat of Russ' failed justification, many protocols >>> use and depend on TLS where the entity controlling the TLS server >>> private key materials is not the higher layer sender or receiver, >>> so all four points in the definition in 2804 are fully met by your >>> wiretapping scheme. >>=20 >> It is clear that you do not agree with the reasoning that I posted on >> Friday. Some people do, and clearly, others do not. >>=20 >> So, I failed to convince you. However, you have also failed to >> convince me that the proposal is wiretapping under the definition in >> RFC 2804, Section 3. >=20 > Consider SMTP/TLS. Where one MTA on the path supports this. > Say it's one operated by an anti-spam company for example. > That is clearly not the sender nor recipient. >=20 > That meets all 4 points in 2804, right? You are pointing to email. Some MTAs will use SMTP over TLS, but many = others do not. It would be great if they all do, especially for the = authentication. In your response you are talking about an email system = that has been using plaintext for ages, and you are trying to apply = hop-by-hop a mechanism to the delivery. Then, you are saying that the = sender and receiver have confidentiality expectations that are being = violated. I do not buy it. Russ From nobody Mon Jul 10 15:21:19 2017 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 1EB2C13191D for ; Mon, 10 Jul 2017 15:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vywZiPOzqFUM for ; Mon, 10 Jul 2017 15:21:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF59D1300CE for ; Mon, 10 Jul 2017 15:21:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6A70ABE58; Mon, 10 Jul 2017 23:21:13 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8dN3yiWhniu; Mon, 10 Jul 2017 23:21:12 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EB560BE2F; Mon, 10 Jul 2017 23:21:11 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499725272; bh=pW/m0ymJj1QTMlVe+vRYXWbDhbMEvYZ9nvqbXf1Ukw4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=m6jpvAP//H8Kzs9SCtL6gRkh4RW2lf/XOywZ2DNjz3HIJ71aqQk+33/rgJxDy2yiS nlksvaYbSjC6Z49INpOhg5VZ2mk7WHkcOOhd42ts/kPM8H4LZMijrNV6CHIWL1digz DYdfkrwBIYS6B7O9fu633umZBarxpP588awpjI8U= To: Russ Housley Cc: "Polk, Tim (Fed)" , IETF TLS References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 10 Jul 2017 23:21:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a4KXQAOETPjw3E4vC2UF702fqc36B41R8" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 22:21:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a4KXQAOETPjw3E4vC2UF702fqc36B41R8 Content-Type: multipart/mixed; boundary="XbK1GJucoCqgq7bumb46pjJCHat07cNEE"; protected-headers="v1" From: Stephen Farrell To: Russ Housley Cc: "Polk, Tim (Fed)" , IETF TLS Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> In-Reply-To: <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> --XbK1GJucoCqgq7bumb46pjJCHat07cNEE Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 10/07/17 23:07, Russ Housley wrote: > Stephen: >=20 >>> >>>> And to avoid a repeat of Russ' failed justification, many protocols >>>> use and depend on TLS where the entity controlling the TLS server >>>> private key materials is not the higher layer sender or receiver, >>>> so all four points in the definition in 2804 are fully met by your >>>> wiretapping scheme. >>> >>> It is clear that you do not agree with the reasoning that I posted on= >>> Friday. Some people do, and clearly, others do not. >>> >>> So, I failed to convince you. However, you have also failed to >>> convince me that the proposal is wiretapping under the definition in >>> RFC 2804, Section 3. >> >> Consider SMTP/TLS. Where one MTA on the path supports this. >> Say it's one operated by an anti-spam company for example. >> That is clearly not the sender nor recipient. >> >> That meets all 4 points in 2804, right? >=20 > You are pointing to email. Some MTAs will use SMTP over TLS, but many = others do not. It would be great if they all do, especially for the auth= entication. In your response you are talking about an email system that = has been using plaintext for ages, and you are trying to apply hop-by-hop= a mechanism to the delivery. Then, you are saying that the sender and r= eceiver have confidentiality expectations that are being violated. I do = not buy it. See [1]. Those show nearly 90% of mails being encrypted with TLS now. In many mail deployments there will be an added hop e.g. for anti-spam (we do that here in tcd) to an outside party. While not 100% of mail is encrypted with TLS on all hops, much is. (And the UTA WG are developing MTA-STS to try improve that.) If one of those external parties implements your scheme then mail senders and receivers will not know and that real TLS application meets the 2804 definition for lots and lots and lots of emails. Hence, 2804 applies here and the standards-track label ought be removed. S. [1] https://www.google.com/transparencyreport/saferemail/ >=20 > Russ >=20 >=20 --XbK1GJucoCqgq7bumb46pjJCHat07cNEE-- --a4KXQAOETPjw3E4vC2UF702fqc36B41R8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZY/3XAAoJEC88hzaAX42iGWoIAIHdw8furqB8q6Q2hE3h8tVf pEIKe5rTjb61091z9L3tzcJjvXr2OKuwNt/WoNiFPI7tEOVQ8zCY6loO/+h9qfBe Q9i9dtklhk/RUJ1Yp/u1PcjDsJfxZDSvqVs3Gc8Shg7q3juCHR1LT9JVqRuSW/+e rb24Hdtt0GKWpUzGboyasAnxFZb4lgddVA/WKDwboI5EEpgw6Fn8mXjy1IR/Nm1O iktwujVO2g1lj5QGkV5zSm7NDLV9ygP7dCKWbZRc9g7Kq4EeBPRSYFuY/MBGwkyk UK6+cPa8mifAr1oCRRK1kTR8dW9WPhCidWm7zOHDPzWDKaV2X7CBGCNeJlvJHPU= =73no -----END PGP SIGNATURE----- --a4KXQAOETPjw3E4vC2UF702fqc36B41R8-- From nobody Mon Jul 10 15:32:30 2017 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 356E51317CF for ; Mon, 10 Jul 2017 15:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 wBRb8VtmX00E for ; Mon, 10 Jul 2017 15:32:27 -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 00769131937 for ; Mon, 10 Jul 2017 15:32:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 599F7300258 for ; Mon, 10 Jul 2017 18:32:24 -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 zAqY-nzLi6V2 for ; Mon, 10 Jul 2017 18:32:23 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id EC547300466; Mon, 10 Jul 2017 18:32:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Mon, 10 Jul 2017 18:32:22 -0400 Cc: "Polk, Tim (Fed)" , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <78DF6C63-8DF1-473A-9150-63EEB9E18B20@vigilsec.com> References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 22:32:29 -0000 Stephen: >>>>=20 >>>>> And to avoid a repeat of Russ' failed justification, many = protocols >>>>> use and depend on TLS where the entity controlling the TLS server >>>>> private key materials is not the higher layer sender or receiver, >>>>> so all four points in the definition in 2804 are fully met by your >>>>> wiretapping scheme. >>>>=20 >>>> It is clear that you do not agree with the reasoning that I posted = on >>>> Friday. Some people do, and clearly, others do not. >>>>=20 >>>> So, I failed to convince you. However, you have also failed to >>>> convince me that the proposal is wiretapping under the definition = in >>>> RFC 2804, Section 3. >>>=20 >>> Consider SMTP/TLS. Where one MTA on the path supports this. >>> Say it's one operated by an anti-spam company for example. >>> That is clearly not the sender nor recipient. >>>=20 >>> That meets all 4 points in 2804, right? >>=20 >> You are pointing to email. Some MTAs will use SMTP over TLS, but = many others do not. It would be great if they all do, especially for = the authentication. In your response you are talking about an email = system that has been using plaintext for ages, and you are trying to = apply hop-by-hop a mechanism to the delivery. Then, you are saying that = the sender and receiver have confidentiality expectations that are being = violated. I do not buy it. >=20 > See [1]. >=20 > Those show nearly 90% of mails being encrypted with > TLS now. >=20 > In many mail deployments there will be an added hop e.g. > for anti-spam (we do that here in tcd) to an outside > party. >=20 > While not 100% of mail is encrypted with TLS on all > hops, much is. (And the UTA WG are developing MTA-STS > to try improve that.) >=20 > If one of those external parties implements your > scheme then mail senders and receivers will not know and > that real TLS application meets the 2804 definition for > lots and lots and lots of emails. >=20 > Hence, 2804 applies here and the standards-track label > ought be removed. >=20 > S. >=20 > [1] https://www.google.com/transparencyreport/saferemail/ I'm glad that TLS is being used to protect email delivery. I do not see how this changes the expectation discussed in RFC 2804, = Section 3, Item number 3. Russ From nobody Mon Jul 10 15:34:15 2017 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 828A1131937 for ; Mon, 10 Jul 2017 15:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2lNRXPwwkXn for ; Mon, 10 Jul 2017 15:34:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAA01317CF for ; Mon, 10 Jul 2017 15:34:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0A8E0BE39; Mon, 10 Jul 2017 23:34:10 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3Hl2xuG_fqX; Mon, 10 Jul 2017 23:34:08 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65C08BE2F; Mon, 10 Jul 2017 23:34:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499726048; bh=sc6SNSACHbXgFLRvzWvIYMYZ7OgnzB0YNoa/ukrKq4o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NE443Y17Gbdl/BkcCv87xAVEhvi0iHURUWJegJL+f2BJGESmvSmiBBuI/yDDrPugG tVhDG6XwNnvZCBdrQYqT0+oQnsXNg8gZY+TzgN3HrLRslCmWCXId4oeiO3UaqOGVxo aWIfApehlUK61Dw2oa+70sII7NPugCFCPs2kuR1M= To: Russ Housley Cc: "Polk, Tim (Fed)" , IETF TLS References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> <78DF6C63-8DF1-473A-9150-63EEB9E18B20@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <878f27f4-e43a-ff20-28c9-a59a1ed64bd9@cs.tcd.ie> Date: Mon, 10 Jul 2017 23:34:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <78DF6C63-8DF1-473A-9150-63EEB9E18B20@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cp6fxNsXobKlWGuL3LHuQSMWTWdvcOnP2" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 22:34:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cp6fxNsXobKlWGuL3LHuQSMWTWdvcOnP2 Content-Type: multipart/mixed; boundary="6kCNkmDlahgeIputiaIfPl4mQHwH3mae3"; protected-headers="v1" From: Stephen Farrell To: Russ Housley Cc: "Polk, Tim (Fed)" , IETF TLS Message-ID: <878f27f4-e43a-ff20-28c9-a59a1ed64bd9@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> <78DF6C63-8DF1-473A-9150-63EEB9E18B20@vigilsec.com> In-Reply-To: <78DF6C63-8DF1-473A-9150-63EEB9E18B20@vigilsec.com> --6kCNkmDlahgeIputiaIfPl4mQHwH3mae3 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 10/07/17 23:32, Russ Housley wrote: > Stephen: >=20 >>>>>=20 >>>>>> And to avoid a repeat of Russ' failed justification, many >>>>>> protocols use and depend on TLS where the entity >>>>>> controlling the TLS server private key materials is not the >>>>>> higher layer sender or receiver, so all four points in the >>>>>> definition in 2804 are fully met by your wiretapping >>>>>> scheme. >>>>>=20 >>>>> It is clear that you do not agree with the reasoning that I >>>>> posted on Friday. Some people do, and clearly, others do >>>>> not. >>>>>=20 >>>>> So, I failed to convince you. However, you have also failed >>>>> to convince me that the proposal is wiretapping under the >>>>> definition in RFC 2804, Section 3. >>>>=20 >>>> Consider SMTP/TLS. Where one MTA on the path supports this. Say >>>> it's one operated by an anti-spam company for example. That is >>>> clearly not the sender nor recipient. >>>>=20 >>>> That meets all 4 points in 2804, right? >>>=20 >>> You are pointing to email. Some MTAs will use SMTP over TLS, but >>> many others do not. It would be great if they all do, especially >>> for the authentication. In your response you are talking about >>> an email system that has been using plaintext for ages, and you >>> are trying to apply hop-by-hop a mechanism to the delivery. >>> Then, you are saying that the sender and receiver have >>> confidentiality expectations that are being violated. I do not >>> buy it. >>=20 >> See [1]. >>=20 >> Those show nearly 90% of mails being encrypted with TLS now. >>=20 >> In many mail deployments there will be an added hop e.g. for >> anti-spam (we do that here in tcd) to an outside party. >>=20 >> While not 100% of mail is encrypted with TLS on all hops, much is. >> (And the UTA WG are developing MTA-STS to try improve that.) >>=20 >> If one of those external parties implements your scheme then mail >> senders and receivers will not know and that real TLS application >> meets the 2804 definition for lots and lots and lots of emails. >>=20 >> Hence, 2804 applies here and the standards-track label ought be >> removed. >>=20 >> S. >>=20 >> [1] https://www.google.com/transparencyreport/saferemail/ >=20 > I'm glad that TLS is being used to protect email delivery. >=20 > I do not see how this changes the expectation discussed in RFC 2804, > Section 3, Item number 3. >=20 Talk to our (tcd.ie) or gmail's mail admin folks. Their expectations count too. (Or are we against enterprise requirements or something? ;-) S. > Russ >=20 >=20 >=20 --6kCNkmDlahgeIputiaIfPl4mQHwH3mae3-- --cp6fxNsXobKlWGuL3LHuQSMWTWdvcOnP2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZADfAAoJEC88hzaAX42izgsIAJeQLXyv8NOS/bm6lZNFk6vv ZinVmmDJItjezqjRaRR4tAzuTJ6yT70V4I7HjdZ33UzmURhqiQ/XfmEXuQx61BkP RGgo8Iyc2W+fC9BO+GJy/qCNZNa2Okad3aAj4yjuD677hT+b7wM8hyYh4pfw0oxM 3wk3Gk4AdnKDurGO3qrpdGPLqXcNUhI+UXc80+YznLMkm/hue3bv/EcY14zVh0Xr qZHns0YAtDWviu7DZNQec1zAgtt8MlInH0WW8VZGMsHeantnCk/KOr3BLA6XjE3M QfjMwg3TSjLe14KyjtM4w9UxwCfUeVEByKxbLG4ieAzD3JljKO+r7KOFkPbtbAg= =qnxk -----END PGP SIGNATURE----- --cp6fxNsXobKlWGuL3LHuQSMWTWdvcOnP2-- From nobody Mon Jul 10 16:09:47 2017 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 62009131945 for ; Mon, 10 Jul 2017 16:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=X17Hvxgc; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=teEteG0F Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0p3nq0okMdt for ; Mon, 10 Jul 2017 16:09:44 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16DB13193D for ; Mon, 10 Jul 2017 16:09:44 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C020F877C0 for ; Mon, 10 Jul 2017 19:09:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=Kb+SwjBXNJZ5FEyZCG0hEt//a+0=; b=X17Hvx gcdkEBujEfWzdzE1NqXBV7+96anxDwSO5Oo8bV2nHH5ODvj21HyVH1kcQxx1sJ6P nt0UxV11IvWTfweanhTGkVLik6dNRKgh94VjGQ52nEaeQ8aN+Bbf73WdgU5npoKe fd7zq6VtLVT0RCumz3sb0LFOxD2bjk7jdjcXc= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B858A877BD for ; Mon, 10 Jul 2017 19:09:42 -0400 (EDT) Received: from mail-yw0-f170.google.com (unknown [209.85.161.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 39787877BB for ; Mon, 10 Jul 2017 19:09:42 -0400 (EDT) Received: by mail-yw0-f170.google.com with SMTP id a12so42112928ywh.3 for ; Mon, 10 Jul 2017 16:09:41 -0700 (PDT) X-Gm-Message-State: AIVw111LeSpFL5fqGouWuFUFTDMODC5D8krG/iL/2mwl6+Ut6pjPSQHE msMFjV+G9esSFYC7DyQ/qE9drSOg/w== X-Received: by 10.129.49.213 with SMTP id x204mr2533851ywx.149.1499728181454; Mon, 10 Jul 2017 16:09:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.60.199 with HTTP; Mon, 10 Jul 2017 16:09:00 -0700 (PDT) In-Reply-To: <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> From: Eric Mill Date: Mon, 10 Jul 2017 19:09:00 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: Stephen Farrell , "Polk, Tim (Fed)" , IETF TLS Content-Type: multipart/alternative; boundary="001a11421ce08410d40553fead46" X-Pobox-Relay-ID: DB20FE7E-65C4-11E7-9C62-EFB41968708C-82875391!pb-smtp1.pobox.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=konklone.com; h=mime-version:in-reply-to:references:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=Kb+SwjBXNJZ5FEyZCG0hEt//a+0=; b=teEteG0FGuv4fi6ZP1+LK8/gPxiUHaZTftRY0kxkSRSVYUpHJSyCEz0P9zWth8tVPqfuj1M6vu5cT/4lpDGjDsZkhUN+IbpZS8s2XlwMFs5kdDGokdthhHlkTTr6HNd84z01Gue4lnfdfaAXuMV6jrv3p8vXFOMh7QZ5khpsnc0= Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 23:09:46 -0000 --001a11421ce08410d40553fead46 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley wrote: > > >> So, I failed to convince you. However, you have also failed to > >> convince me that the proposal is wiretapping under the definition in > >> RFC 2804, Section 3. > > > > Consider SMTP/TLS. Where one MTA on the path supports this. > > Say it's one operated by an anti-spam company for example. > > That is clearly not the sender nor recipient. > > > > That meets all 4 points in 2804, right? > > You are pointing to email. Some MTAs will use SMTP over TLS, but many > others do not. It would be great if they all do, especially for the > authentication. In your response you are talking about an email system > that has been using plaintext for ages, and you are trying to apply > hop-by-hop a mechanism to the delivery. Then, you are saying that the > sender and receiver have confidentiality expectations that are being > violated. I do not buy it. > It seems like a weak counterargument to say that because there remain areas where mail servers don't use TLS, that senders and receivers have no expectation of confidentiality with email at all. Are you really saying that if an MTA used this static-DH draft version of TLS to maintain keys to decrypt email traffic, despite it only being "intended" for enterprise use, that it wouldn't be wiretapping? What about if/when MTA STS[1] is implemented? Will MTA adoption have to hit 100% before it's suddenly wiretapping for any given MTA to surreptitiously use the static DH version of TLS that was "intended" only for enterprise use? -- Eric [1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-06 > Russ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- konklone.com | @konklone --001a11421ce08410d40553fead46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 6:07 PM, Russ Housley <housley@vigilsec.com>= wrote:
>> So, I failed to convince you.=C2=A0 However, you have also failed = to
>> convince me that the proposal is wiretapping under the definition = in
>> RFC 2804, Section 3.
>
> Consider SMTP/TLS. Where one MTA on the path supports this.
> Say it's one operated by an anti-spam company for example.
> That is clearly not the sender nor recipient.
>
> That meets all 4 points in 2804, right?

You are pointing to email.=C2=A0 Some MTAs will use SMTP over TLS, b= ut many others do not.=C2=A0 It would be great if they all do, especially f= or the authentication.=C2=A0 In your response you are talking about an emai= l system that has been using plaintext for ages, and you are trying to appl= y hop-by-hop a mechanism to the delivery.=C2=A0 Then, you are saying that t= he sender and receiver have confidentiality expectations that are being vio= lated.=C2=A0 I do not buy it.

It seems = like a weak counterargument to say that because there remain areas where ma= il servers don't use TLS, that senders and receivers have no expectatio= n of confidentiality with email at all. Are you really saying that if an MT= A used this static-DH draft version of TLS to maintain keys to decrypt emai= l traffic, despite it only being "intended" for enterprise use, t= hat it wouldn't be wiretapping?

What about if/= when MTA STS[1] is implemented? Will MTA adoption have to hit 100% before i= t's suddenly wiretapping for any given MTA to surreptitiously use the s= tatic DH version of TLS that was "intended" only for enterprise u= se?

-- Eric



Russ

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



--
=
--001a11421ce08410d40553fead46-- From nobody Mon Jul 10 16:12:08 2017 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 7A41D131945 for ; Mon, 10 Jul 2017 16:12:07 -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 AdT013tYS4Q6 for ; Mon, 10 Jul 2017 16:12:06 -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 E77C513193D for ; Mon, 10 Jul 2017 16:12:05 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id x187so88054760oig.3 for ; Mon, 10 Jul 2017 16:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UR44fQ2bwgwedzsIKvq1dn05aC6rfmNICeXX7yL04ps=; b=NKf1BDtysAzDwnJ9btXMm4IWUFwmIzPJ524/+nFTC5XtQDoHcyI6t5cYJtxmUoW37n oWBEpFlTVpumGEZdNcctTh7x8jTKl9UIo4Yd76BICTXprYQPMC989g6TDwthGyPl1r5A 7w2rxAbPqvx6l8BAW8V6nH3oVV44KGnSKiOZSRdy6p72hs948U08Mc/Elt+6qHHHFNHs f3tfkSFHUA9VHv4ki0aP8ow6r30aV4hIOjDr2bJlCDXpIxW2+T5ryzw7wGe0wW1gHBvR Q0ZQHTZsEpY1iVLBgeoJvVhGgUxFr2G560tVlJi/6rbKJgbNXYsvnbG1B5eCOti6kvgZ rxCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=UR44fQ2bwgwedzsIKvq1dn05aC6rfmNICeXX7yL04ps=; b=CdB14g0xcENsa+gP+Tq/hGWVLpHeCKX5lGFjtxIP74AZBLuZwPXM+6ILn8ZTzUp4+r 94trLogzhcX2/occpJhq2wgNrhIxZO6p1CK3Fri3Jn1W0scdSVtPlF+tOnlBRfAh2ZYz EL/a/qXSAYGhLNBw0zOr9CMQqDmeXpcevW8bFyP/cPZ1A6NC1nd7nzo6WM40luh/9yWJ s4C8b8+QMGb4kmdPr33FvMXgbc9gHmOx7+ylSB//aM5OsFDDwab+/2jQ1EoVeI1H53IF aSwk37Dr+VWs+D2wG0Mdd/0TuoRzNOdgQZZFG8VltOID+NjYx4c/LiPzam463K2Q94vY Rwmw== X-Gm-Message-State: AIVw111tuWY9zBk5RRat2IXa8AT/X+zFOZPQjsXugDvDxKZjG+ISOt0G lFroSFgsFSclKkxYyIj+Z+hhHDIK+LlK3yY= X-Received: by 10.202.72.202 with SMTP id v193mr11178895oia.83.1499728325267; Mon, 10 Jul 2017 16:12:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.5.6 with HTTP; Mon, 10 Jul 2017 16:12:04 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> From: Jeffrey Walton Date: Mon, 10 Jul 2017 19:12:04 -0400 Message-ID: To: Stephen Farrell Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 23:12:07 -0000 On Mon, Jul 10, 2017 at 3:37 PM, Stephen Farrell wrote: > > And if coercion of a server to comply with a wiretap > scheme like this stills fanciful to you, please check > out the history of lavabit - had there been a standard > wiretap API as envisaged here it's pretty certain that > would have been the device of choice in a case like that. > While it's easy enough to envisage many other abuses > that could be based on this wiretap scheme, that one is > a good match and a real one. There's a lot of insight based on the history. If the mechanism operated at layer 3 or 4 (modify the protocol), then the net is cast overly wide in a shared hosting arrangement. That is, all virtual host's traffic is captured and recovered. If it operates at layer 6 or 7 (modify the applications and/or its libraries, like Apache or Nginx), then there is more precision in target traffic. That is, only the target's traffic can captured and recovered. Jeff From nobody Mon Jul 10 16:39:09 2017 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 E069A120726 for ; Mon, 10 Jul 2017 16:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kg06d-C59Akp for ; Mon, 10 Jul 2017 16:39:04 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 8743F1200ED for ; Mon, 10 Jul 2017 16:39:04 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id u62so56867515pgb.3 for ; Mon, 10 Jul 2017 16:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rlx7nmKhJ5tCte0QNnLhiK7Qe4qyDurXLYcu9D7HrsI=; b=LbtQn4kQ+au4CS6Tn/wzd47DLKd9S+53yCO0Zx/nKYvOgzOSf73UDSVLYFXrTWA2Hg EjusOC/Q2wA5N1R0CmYjevnARtvdDT0NE8H+kmnvwCbrDwqjJZIQrG5piLpSUfOqJne9 kw7ACAGULA8kkfPAYV3MPCpuCQx9DlZUAS0D0UkrpQSRdaqA7TtQRZC6SUQliXpvpGKi 3c3Td6MpZiMApUWNCY6O4wMmB8vWCnmKLiM+IPHpD296E6D/JuJ2n3U9YbKVM1Vv7Ttf Wk3KB/9jPBk2UC5O/yEP1xcbqzL9zCSmeV8WAG/e0XUpJVla8J0EZ6kXgrKfujbCOZ5P cJ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rlx7nmKhJ5tCte0QNnLhiK7Qe4qyDurXLYcu9D7HrsI=; b=DwHCVdr50vqaI8kO+Lskk3aw9IHaIOoscL3KH1WoHnfiPB9PDfMbobGtWIQAdeZDWo i5jecGydo8Mku/LuaOnD0rLGcgxX6Xl6RKbGhHwedyvrfVk7k+o6FQXbih6aCAKKmnFR jDErrBkJ8UJsQxkqOCG67x7nV6C7cDSwyixolX+eGgQ+Me9GA/QJkSqNJ4NRpIrT3+dJ 3UZ6aUps+2n+bkNL+CeSckdCX6+Wqdx8DKULf2yLzYvNLtxUdEzXLwyRuaW01i/e8BwX ThAoUb4+X5LZNZK9ZiSRGD4G19HUIPryHpT1qbcR3ww3YsDuSUycwzbsuoxI9DqrIwjJ oeHw== X-Gm-Message-State: AIVw1132agt3mfd0JMH0ViwEhtTwZ6V0VgWU/4VNHNe3hpOe63APNM/L Hdw+7ey0AVDhWnSpXBSVOCzFOMAu5LMe X-Received: by 10.101.76.140 with SMTP id m12mr16859595pgt.159.1499729944099; Mon, 10 Jul 2017 16:39:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Mon, 10 Jul 2017 16:39:03 -0700 (PDT) Received: by 10.100.187.77 with HTTP; Mon, 10 Jul 2017 16:39:03 -0700 (PDT) In-Reply-To: References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> From: Watson Ladd Date: Mon, 10 Jul 2017 16:39:03 -0700 Message-ID: To: Eric Mill Cc: "Polk, Tim (Fed)" , tls@ietf.org, Russ Housley Content-Type: multipart/alternative; boundary="089e0823838493c17e0553ff1638" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2017 23:39:07 -0000 --089e0823838493c17e0553ff1638 Content-Type: text/plain; charset="UTF-8" On Jul 10, 2017 4:09 PM, "Eric Mill" wrote: On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley wrote: > > >> So, I failed to convince you. However, you have also failed to > >> convince me that the proposal is wiretapping under the definition in > >> RFC 2804, Section 3. > > > > Consider SMTP/TLS. Where one MTA on the path supports this. > > Say it's one operated by an anti-spam company for example. > > That is clearly not the sender nor recipient. > > > > That meets all 4 points in 2804, right? > > You are pointing to email. Some MTAs will use SMTP over TLS, but many > others do not. It would be great if they all do, especially for the > authentication. In your response you are talking about an email system > that has been using plaintext for ages, and you are trying to apply > hop-by-hop a mechanism to the delivery. Then, you are saying that the > sender and receiver have confidentiality expectations that are being > violated. I do not buy it. > It seems like a weak counterargument to say that because there remain areas where mail servers don't use TLS, that senders and receivers have no expectation of confidentiality with email at all. Are you really saying that if an MTA used this static-DH draft version of TLS to maintain keys to decrypt email traffic, despite it only being "intended" for enterprise use, that it wouldn't be wiretapping? What about if/when MTA STS[1] is implemented? Will MTA adoption have to hit 100% before it's suddenly wiretapping for any given MTA to surreptitiously use the static DH version of TLS that was "intended" only for enterprise use? I don't read RFC 2804 as applying to cases where intermediaries authorized by a party to view information are handing it over. The MTA is authorized by the recipient to be in the path and to look at the emails for all sorts of reasons, and if they decide to hand over all your emails to someone else via FTP, that's not a reason to be against FTP. If it was to apply anything where a proxy service can be behind another proxy would run afoul of this: they would proxy through the evesdropper. So would reply-all, the most blatant cause of accidental evesdropping online. Historically 2804 came out of (I think) a different situation where signaling information related to interception was going to be included in the protocol. Sadly it talks about sender and recipient without considering cases where the identity is confused by subcontracting, and doesn't distinguish cases like this which are similar to key escrow except there is only one entity involved in the escrow. -- Eric [1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-06 > Russ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- konklone.com | @konklone _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --089e0823838493c17e0553ff1638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jul 10, 2017 4:09 PM, "Eric Mill" <eric@konklone.com> wrote:
<= div class=3D"gmail_quote">
On Mon, Jul 10, 2017 a= t 6:07 PM, Russ Housley <housley@vigilsec.com> wrote: >> So, I failed to convince you.=C2=A0 However, you have also failed = to
>> convince me that the proposal is wiretapping under the definition = in
>> RFC 2804, Section 3.
>
> Consider SMTP/TLS. Where one MTA on the path supports this.
> Say it's one operated by an anti-spam company for example.
> That is clearly not the sender nor recipient.
>
> That meets all 4 points in 2804, right?

You are pointing to email.=C2=A0 Some MTAs will use SMTP over TLS, b= ut many others do not.=C2=A0 It would be great if they all do, especially f= or the authentication.=C2=A0 In your response you are talking about an emai= l system that has been using plaintext for ages, and you are trying to appl= y hop-by-hop a mechanism to the delivery.=C2=A0 Then, you are saying that t= he sender and receiver have confidentiality expectations that are being vio= lated.=C2=A0 I do not buy it.

It = seems like a weak counterargument to say that because there remain areas wh= ere mail servers don't use TLS, that senders and receivers have no expe= ctation of confidentiality with email at all. Are you really saying that if= an MTA used this static-DH draft version of TLS to maintain keys to decryp= t email traffic, despite it only being "intended" for enterprise = use, that it wouldn't be wiretapping?

What abo= ut if/when MTA STS[1] is implemented? Will MTA adoption have to hit 100% be= fore it's suddenly wiretapping for any given MTA to surreptitiously use= the static DH version of TLS that was "intended" only for enterp= rise use?

I don't read RFC 2804 as applying to= cases where intermediaries authorized by a party to view information are h= anding it over. The MTA is authorized by the recipient to be in the path an= d to look at the emails for all sorts of reasons, and if they decide to han= d over all your emails to someone else via FTP, that's not a reason to = be against FTP.

If it wa= s to apply anything where a proxy service can be behind another proxy would= run afoul of this: they would proxy through the evesdropper. So would repl= y-all, the most blatant cause of accidental evesdropping online.

Historically 2804 came out of (I t= hink) a different situation where signaling information related to intercep= tion was going to be included in the protocol. Sadly it talks about sender = and recipient without considering cases where the identity is confused by s= ubcontracting, and doesn't distinguish cases like this which are simila= r to key escrow except there is only one entity involved in the escrow.

=

-- Eric=


<= br> Russ

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



--
<= a href=3D"https://konklone.com" target=3D"_blank">konklone.com | @konklone

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


--089e0823838493c17e0553ff1638-- From nobody Mon Jul 10 18:37:31 2017 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 308821300BB for ; Mon, 10 Jul 2017 18:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AsiAc2kHCpdj for ; Mon, 10 Jul 2017 18:37:27 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 AE83812EC27 for ; Mon, 10 Jul 2017 18:37:27 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id u62so58039610pgb.3 for ; Mon, 10 Jul 2017 18:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q5bDDXIxoiAdCSECvaVoHe/aWxqv8lg4kBVsCzOLEw8=; b=Umrc6a9Oya+0m9sPW8yGc17xA/odtk6yrQXDQBOLgSRde56EdwvNv4AcyFBZG0yFkX Iu0B/6Rm/gOfIez026Xs1snzdH4mKIsoMkw0usysapD8EO6A0YfZRLed7VoFxFtv6NQu QzsTuOq58JtelfubDj/01nEf4Y3lT8z9elc3l1bIEhUJHK1nMXEkWXRuvSSVUISQA62g taRaOzrzaKnfaC/mQk9Qn+DOWN7uc/e/6fIZlxGFfI64J9hFWdVlSNpGb3Rq5eDUtIoY yYs8LhFtGCtWEFKPoHO/etXjlQh74F3DnCVqzlOWCYZ8gBQyEBozWVE1n6Y8w2TFQv3p 6zsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q5bDDXIxoiAdCSECvaVoHe/aWxqv8lg4kBVsCzOLEw8=; b=Fve6O8oTdNhM8nJ/XKq8qqdTUHjDyAgckpzDXnt/SuL4aTDc59z7Ptm88pQrvlwG+5 rAPrcZhKBFXcW6zkPM8aCCDMsX7lmdaubKWb5JR0ZjdKceV+L2d+2nEH/ZQDJmapt8HC qmv7f7VAmz4Gp92UOFK0kqHMnLBx7OC3WxtcsgFEP0vFL1eM0LStC7lcvc4tlh4miBo6 E2pwUhzhlg+s8VcN7JeS4JohnvWJJi4vzUI1EplVY8nWQiq6v+9UrRwgG/pJTUVPX2RX nqM/jO7QEFqob9E+y3vWN+IUHaeSHGvzlxWg22aOo2IxqpbxiJjrI2vxahVo32Wb5iM2 bLtQ== X-Gm-Message-State: AIVw111KA1rqB90GEgD3N66GHS5A9CoWRwJ/10YOMsD9O31O4JOdfqN+ s6s4qE7tvZR00wrTU8GB7JZNRHWHvyhmrC8= X-Received: by 10.98.197.130 with SMTP id j124mr48256280pfg.117.1499737047041; Mon, 10 Jul 2017 18:37:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Mon, 10 Jul 2017 18:37:26 -0700 (PDT) In-Reply-To: <422ef2c7-4d99-20d2-8a39-ffd61277e0bd@huitema.net> References: <149810504637.30481.937244297632371838.idtracker@ietfa.amsl.com> <422ef2c7-4d99-20d2-8a39-ffd61277e0bd@huitema.net> From: Kazuho Oku Date: Tue, 11 Jul 2017 10:37:26 +0900 Message-ID: To: Christian Huitema , Eric Rescorla Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c184d78f20dc0055400bd30" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 01:37:30 -0000 --94eb2c184d78f20dc0055400bd30 Content-Type: text/plain; charset="UTF-8" Thank you for writing the draft. I agree for the need to hide hostnames from passive attackers, and I really like the fact that the draft discusses of various attack vectors that a proper SNI protection should take care of. OTOH, it makes me sad that the proposed methods require an additional roundtrip (when compared to no encrypted SNI). Can't we consider adopting a method that improves both performance and privacy, instead of choosing one between the two? Specifically, I wonder if we could consider embedding part of the TLS handshake within a secure DNS query / response. That will make the connection setup even faster than today at the same time providing us more privacy. Note that regardless of the approach, it is mandatory to migrate DNS onto a secure channel (i.e. over TLS or QUIC) in order to protect the hostname that the client is going to access. Protecting just the SNI is insufficient. Approach 1. embed TLS handshake in the DNS query and response A client queries a DNS over a secure channel. ClientHello is embedded to the DNS query. The resolver that receives the query will always contact the authoritative server by using a secure channel, transmitting both the DNS query and the ClientHello. Upon receiving the query, the authoritative server will send a DNS response that embeds the server's first flight of the TLS handshake (i.e. from ServerHello to ServerFinished). The resolver relays the DNS response (with the handshake messages) to the client. When the client receives the DNS response and the TLS handshake messages, it connects to the server (that is designated by the DNS response) and immediately sends the client's second flight of the TLS handshake (i.e. ClientFinished) with an identifier that correlates that message to the first flight of the messages transmitted through DNS, followed by application data. The merit of the approach is that connection setup will be even more faster than now, since the time being spent changes from 1 RTT-to-DNS + 1 RTT-to-origin to 1 RTT-to-origin-through-DNS (note that reducing the roundtrip to DNS has become important than before due to the fact that resolvers are less common to be located near the client. This is especially the case for mobile networks). Though there could be replay issues until the client receives the server's first flight through the direct connection. In short, the connection setup latency (including DNS) will be reduced from 2 RTT to 1 RTT, whereas in the approaches that are discussed in the draft it will change from 2 RTT to 3 RTT. Approach 2. embed TLS handshake originating from the server in DNS response This is a variation of the former approach. In this approach, a DNS query is sent over a secure channel but does not convey any TLS handshake massage. OTOH it is the server that initiates the handshake, upon receiving a DNS query. The DNS response (sent over a secure channel) will include the necessary parameters to establish an end-to-end secure channel (e.g. nonce, cryptographic parameters, server certificate, and a signature signing the values). When the client receives the DNS response that contains the handshake messages, it will use that to establish a secure connection to the server (by sending it's nonce and the negotiated parameters that are signed). The time required for establishing a connection will be the same as the first approach. However, one interesting difference from the former approach is that it will be possible for a DNS resolver to cache the DNS response including the server's first flight of the handshake messages (at the cost of losing single-op DH). Hence the change required to existing DNS infrastructure could be somewhat smaller. The risk would be that if the resolver reuses the DNS response, a passive observer could determine whether if multiple new connections went to the same origin (by looking at the identifier that designates the handshake that the client is responding to). If that is an issue, a client may want to inject randomness into the query to suppress the resolver from reusing the response. 2017-06-22 13:25 GMT+09:00 Christian Huitema : > We has many discussions of SNI encryption on this list recently, and that > was enough motivation to write a draft about it. I am pretty sure that this > will be met with wide approval and no discussion at all :-). > > -- Christian Huitema > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-huitema-tls-sni- > encryption-00.txt > Date: Wed, 21 Jun 2017 21:17:26 -0700 > From: internet-drafts@ietf.org > To: Christian Huitema , Eric > Rescorla > > A new version of I-D, draft-huitema-tls-sni-encryption-00.txt > has been successfully submitted by Christian Huitema and posted to the > IETF repository. > > Name: draft-huitema-tls-sni-encryption > Revision: 00 > Title: SNI Encryption in TLS Through Tunneling > Document date: 2017-06-20 > Group: Individual Submission > Pages: 19 > URL: https://www.ietf.org/internet-drafts/draft-huitema-tls-sni-encryption-00.txt > Status: https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ > Htmlized: https://tools.ietf.org/html/draft-huitema-tls-sni-encryption-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-tls-sni-encryption-00 > > > Abstract: > This draft describes the general problem of encryption of the Server > Name Identification (SNI) parameter. The proposed solutions hide a > Hidden Service behind a Fronting Service, only disclosing the SNI of > the Fronting Service to external observers. The draft starts by > listing known attacks against SNI encryption, and then presents two > potential solutions that might mitigate these attacks. The first > solution is based on TLS in TLS "quasi tunneling", and the second > solution is based on "combined tickets". These solutions only > require minimal extensions to the TLS protocol. > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Kazuho Oku --94eb2c184d78f20dc0055400bd30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for writing the draft.

I agree for the ne= ed to hide hostnames from passive attackers, and I really like the fact tha= t the draft discusses of various attack vectors that a proper SNI protectio= n should take care of.

OTOH, it makes me sad that the proposed metho= ds require an additional roundtrip (when compared to no encrypted SNI).
=
Can't we consider adopting a method that improves both performance = and privacy, instead of choosing one between the two?

Specifically, = I wonder if we could consider embedding part of the TLS handshake within a = secure DNS query / response. That will make the connection setup even faste= r than today at the same time providing us more privacy.

Note that r= egardless of the approach, it is mandatory to migrate DNS onto a secure cha= nnel (i.e. over TLS or QUIC) in order to protect the hostname that the clie= nt is going to access. Protecting just the SNI is insufficient.

Appr= oach 1. embed TLS handshake in the DNS query and response

A client q= ueries a DNS over a secure channel. ClientHello is embedded to the DNS quer= y. The resolver that receives the query will always contact the authoritati= ve server by using a secure channel, transmitting both the DNS query and th= e ClientHello. Upon receiving the query, the authoritative server will send= a DNS response that embeds the server's first flight of the TLS handsh= ake (i.e. from ServerHello to ServerFinished). The resolver relays the DNS = response (with the handshake messages) to the client.

When the clien= t receives the DNS response and the TLS handshake messages, it connects to = the server (that is designated by the DNS response) and immediately sends t= he client's second flight of the TLS handshake (i.e. ClientFinished) wi= th an identifier that correlates that message to the first flight of the me= ssages transmitted through DNS, followed by application data.

The me= rit of the approach is that connection setup will be even more faster than = now, since the time being spent changes from 1 RTT-to-DNS + 1 RTT-to-origin= to 1 RTT-to-origin-through-DNS (note that reducing the roundtrip to DNS ha= s become important than before due to the fact that resolvers are less comm= on to be located near the client. This is especially the case for mobile ne= tworks). Though there could be replay issues until the client receives the = server's first flight through the direct connection.

In short, t= he connection setup latency (including DNS) will be reduced from 2 RTT to 1= RTT, whereas in the approaches that are discussed in the draft it will cha= nge from 2 RTT to 3 RTT.

Approach 2. embed TLS handshake originating= from the server in DNS response

This is a variation of the former a= pproach.

In this approach, a DNS query is sent over a secure channel= but does not convey any TLS handshake massage. OTOH it is the server that = initiates the handshake, upon receiving a DNS query. The DNS response (sent= over a secure channel) will include the necessary parameters to establish = an end-to-end secure channel (e.g. nonce, cryptographic parameters, server = certificate, and a signature signing the values). When the client receives = the DNS response that contains the handshake messages, it will use that to = establish a secure connection to the server (by sending it's nonce and = the negotiated parameters that are signed).

The time required for es= tablishing a connection will be the same as the first approach.

Howe= ver, one interesting difference from the former approach is that it will be= possible for a DNS resolver to cache the DNS response including the server= 's first flight of the handshake messages (at the cost of losing single= -op DH). Hence the change required to existing DNS infrastructure could be = somewhat smaller.

The risk would be that if the resolver reuses the = DNS response, a passive observer could determine whether if multiple new co= nnections went to the same origin (by looking at the identifier that design= ates the handshake that the client is responding to). If that is an issue, = a client may want to inject randomness into the query to suppress the resol= ver from reusing the response.

2017-06-22 13:25 GMT+09:00 Christian Huitema <hui= tema@huitema.net>:
=20 =20 =20

We has many discussions of SNI encryption on this list recently, and that was enough motivation to write a draft about it. I am pretty sure that this will be met with wide approval and no discussion at all :-).

-- Christian Huitema

-------- Forwarded Message --------

Subject: New Version Notification for draft-huitema-tls-sni-encryption-00.txt
Date: Wed, 21 Jun 2017 21:17:26 -0700
From: internet-drafts@ie= tf.org
To: Christian Huitema <huit= ema@huitema.net>, Eric Rescorla <ekr@rtfm.com> 


A new version of I-D, draft-huitema-tls-sni-encryption-00.t=
xt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-huitema-tls-sni-encryption
Revision:	00
Title:		SNI Encryption in TLS Through Tunneling
Document date:	2017-06-20
Group:		Individual Submission
Pages:		19
URL:            https://www.ietf.org/internet-drafts/draft-hu=
itema-tls-sni-encryption-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-tls-sni-=
encryption/
Htmlized:       https://tools.ietf.org/html/draft-huitema-tls-sni-enc=
ryption-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-huit=
ema-tls-sni-encryption-00


Abstract:
   This draft describes the general problem of encryption of the Server
   Name Identification (SNI) parameter.  The proposed solutions hide a
   Hidden Service behind a Fronting Service, only disclosing the SNI of
   the Fronting Service to external observers.  The draft starts by
   listing known attacks against SNI encryption, and then presents two
   potential solutions that might mitigate these attacks.  The first
   solution is based on TLS in TLS "quasi tunneling", and the sec=
ond
   solution is based on "combined tickets".  These solutions only
   require minimal extensions to the TLS protocol.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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




--
Kazuho Oku
--94eb2c184d78f20dc0055400bd30-- From nobody Mon Jul 10 20:53:17 2017 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 779CB12EC06 for ; Mon, 10 Jul 2017 20:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2_kL9EYx9Vfb for ; Mon, 10 Jul 2017 20:53:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C262A129AAD for ; Mon, 10 Jul 2017 20:53:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQW02852; Tue, 11 Jul 2017 03:53:10 +0000 (GMT) Received: from SINEML706-CAH.china.huawei.com (10.223.161.56) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Jul 2017 04:53:09 +0100 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.175]) by SINEML706-CAH.china.huawei.com ([10.223.161.56]) with mapi id 14.03.0301.000; Tue, 11 Jul 2017 11:53:02 +0800 From: Wang Haiguang To: IETF TLS Thread-Topic: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) Thread-Index: AQHS9KIjbGMCVggeCEW+lkbi2Qxg8qJDAA4AgAQaXQCAAN2SAIAAER2AgAA5LYCAA2o0gIACW+/p Date: Tue, 11 Jul 2017 03:53:02 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309DF6BFEC@SINEML521-MBX.china.huawei.com> References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> <201707062201.08455.davemgarrett@gmail.com> <5af19fe7273748579cb2537313667aba@usma1ex-dag1mb1.msg.corp.akamai.com> <20170707161525.ayv4z4olmo4r3h73@LK-Perkele-VII> <6F5C1F62-2A47-4BE7-AEA6-A8BAE56EDA08@vigilsec.com>, In-Reply-To: Accept-Language: en-SG, en-US Content-Language: en-SG X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.166.78] Content-Type: multipart/alternative; boundary="_000_0AE05CBFB1A6A0468C8581DAE58A31309DF6BFECSINEML521MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59644BA7.003A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2b5d864eb28ec7e99dab34ca7dc08975 Archived-At: Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 03:53:15 -0000 --_000_0AE05CBFB1A6A0468C8581DAE58A31309DF6BFECSINEML521MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all Thanks very much for the discussion over the thread. We have learnt a lot f= rom the discussion. Due to the oversea travel, we were not able to send back our reply the comm= ents from Ilari. Only yesterday, we got some time to prepare the reply. So = in the below, we addressed the issue raised by Ilari and highlighted the an= swer in yellow collor. We will continue our effort to improve the draft and will submit an updated= draft once we finished. Regards. Haiguang On Tue, Jul 04, 2017 at 08:47:16AM +0000, Wang Haiguang wrote: > Dear all, > > This Haiguang Wang from Huawei Technology. > > I have submitted an IETF draft on using ECCSI public key for > authentication over TLS protocols. It is the first version, so the > draft still have a lot of spaces to improve. Some feedback: - I see the certificate message has single opaque field. This is the same as RPK, but isn't trivially mappable to TLS 1.3. See TLS 1.3 draft section 4.4.2 on how TLS 1.3 handles RPK. [Answer]: In fact, here we want to define a simple structure, and please se= e the definition of subjectIdentityBasedPublicKeyInfo. Thanks a lot for poi= nting to us TLS 1.3 for reference. - I think you shouldn't duplicate existing arms in TLS structures. See RFC 4279, section 4 for one example on omitting such arms. - I think you shouldn't duplicate definitions of ClientCertificateType and ServerCertificateType. Leave that to RFC 7250 and TLS 1.3 RFC. You just need the certificate type value. [Answer]: Thanks a lot for raising these issues and pointing out relevant r= eferences. We will rectify them in our subsequent versions. - I think you shouldn't define a new key exchange algorithm, but use ECDHE_ECDSA instead (like EdDSA does). Then get a new TLS 1.3 signatureScheme value, which decomposes to the corresponding TLS 1.2 values (see RFC4492bis for an example). However, this requires TLS 1.2 or newer, but that should not be a problem. [Answer]: Yes, exactly. Our intention is to use existing key exchange algor= ithm, but with a different signature scheme (just like EdDSA does, as you s= aid). At the time of writing, we actually followed the TLS 1.2 convention, = and later we will change to follow TLS 1.3. - The proposed ciphersuites are really bad. No new blockmode or stream- mode ciphers should be defined (especially blockmode, those are almost impossible to implement in secure way). If ECDHE_ECDSA is used, one avoids allocating any new ciphersuites. [Answer]: We specified the ciphersuites according to TLS 1.2. We now realiz= ed that the way ciphersuites are defined has been changed in TLS 1.3, and w= e will follow accordingly later. In fact we have no intention to introduce = new ciphersuites in the sense of TLS 1.3. - Security considerations missing. - IANA considerations missing, should ask for allocation of all new codepoints (and that one OID). - References section is duplicated. [Answer]: We will add or rectify in the subsequent versions. Anyway, our idea of the proposal is simple: to use a certificateless signat= ure (RFC 6507) in TLS to avoid the certificate-based signatures, in order t= o avoid the hassle of certificates. ________________________________________ From: TLS [tls-bounces@ietf.org] on behalf of Martin Thomson [martin.thomso= n@gmail.com] Sent: Monday, 10 July, 2017 7:48:57 AM To: Russ Housley Cc: IETF TLS Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507= ) On 8 July 2017 at 05:40, Russ Housley wrote: > The TLS WG wants to work on a a way to combine a PSK with (EC)DH after th= e > current specification is finished for quantum protection. TLS 1.3 allows this already. The drawback being that you need to get the PSK. At the moment, this means talking to the server once before in most cases. I thought that the PQ plan was to add a new key exchange paired with ECDH, along the lines of what was proposed in draft-whyte-qsh-tls13-01 (I recall someone asking CFRG for advice on combining of the outputs, but that doesn't seem to have gone anywhere). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_0AE05CBFB1A6A0468C8581DAE58A31309DF6BFECSINEML521MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all

Thanks very much for the discussion over the thread. We have learnt a lot f= rom the discussion.

Due to the oversea travel, we were not able to send back our reply the comm= ents from Ilari. Only yesterday, we got some time to prepare the reply. So = in the below, we addressed the issue raised by Ilari and highlighted the an= swer in yellow collor.

We will continue our effort to improve the draft and will submit an updated= draft once we finished.

Regards.

Haiguang


On Tue, Jul 04, 2017 at 08:47:16AM +0000, Wang Haiguang wrote:
> Dear all,
>
> This Haiguang Wang from Huawei Technology.
>
> I have submitted an IETF draft on using ECCSI public key for
> authentication over TLS protocols. It is the first version, so the > draft still have a lot of spaces to improve.

Some feedback:

- I see the certificate message has single opaque field. This is the
same as RPK, but isn't trivially mappable to TLS 1.3. See TLS 1.3
draft section 4.4.2 on how TLS 1.3 handles RPK.

[Answer]: In fact, here= we want to define a simple structure, and please see the definition of sub= jectIdentityBasedPublicKeyInfo. Thanks a lot for pointing to us TLS 1.3 for= reference.


- I think you shouldn't duplicate existing arms in TLS structures.
See RFC 4279, section 4 for one example on omitting such arms.
- I think you shouldn't duplicate definitions of ClientCertificateType
and ServerCertificateType. Leave that to RFC 7250 and TLS 1.3 RFC.
You just need the certificate type value.

[Answer]: Thanks a lot = for raising these issues and pointing out relevant references. We will rect= ify them in our subsequent versions.


- I think you shouldn't define a new key exchange algorithm, but
use ECDHE_ECDSA instead (like EdDSA does). Then get a new TLS 1.3
signatureScheme value, which decomposes to the corresponding TLS
1.2 values (see RFC4492bis for an example). However, this requires
TLS 1.2 or newer, but that should not be a problem.

[Answer]: Yes, exactly.= Our intention is to use existing key exchange algorithm, but with a differ= ent signature scheme (just like EdDSA does, as you said). At the time of wr= iting, we actually followed the TLS 1.2 convention, and later we will change to follow TLS 1.3.


- The proposed ciphersuites are really bad. No new blockmode or stream-
mode ciphers should be defined (especially blockmode, those are almost
impossible to implement in secure way). If ECDHE_ECDSA is used, one
avoids allocating any new ciphersuites.

[Answer]: We specified = the ciphersuites according to TLS 1.2. We now realized that the way ciphers= uites are defined has been changed in TLS 1.3, and we will follow according= ly later. In fact we have no intention to introduce new ciphersuites in the sense of TLS 1.3.


- Security considerations missing.
- IANA considerations missing, should ask for allocation of all
new codepoints (and that one OID).
- References section is duplicated.

[Answer]: We will add o= r rectify in the subsequent versions.

Anyway, our idea of the proposal is simple: to use a certificateless signat= ure (RFC 6507) in TLS to avoid the certificate-based signatures, in order t= o avoid the hassle of certificates.






________________________________________
From: TLS [tls-bounces@ietf.org] on behalf of Martin Thomson [martin.thomso= n@gmail.com]
Sent: Monday, 10 July, 2017 7:48:57 AM
To: Russ Housley
Cc: IETF TLS
Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507= )

On 8 July 2017 at 05:40, Russ Housley <housley@vigilsec.com> wrote: > The TLS WG wants to work on a a way to combine a PSK with (EC)DH after= the
> current specification is finished for quantum protection.

TLS 1.3 allows this already. The drawback being that you need to get
the PSK. At the moment, this means talking to the server once before
in most cases. I thought that the PQ plan was to add a new key
exchange paired with ECDH, along the lines of what was proposed in
draft-whyte-qsh-tls13-01 (I recall someone asking CFRG for advice on
combining of the outputs, but that doesn't seem to have gone
anywhere).

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls --_000_0AE05CBFB1A6A0468C8581DAE58A31309DF6BFECSINEML521MBXchi_-- From nobody Tue Jul 11 03:48:20 2017 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 C10D1128BC8 for ; Tue, 11 Jul 2017 03:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE_Go7Lozrkh for ; Tue, 11 Jul 2017 03:48:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D15127180 for ; Tue, 11 Jul 2017 03:48:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4F934BF4C for ; Tue, 11 Jul 2017 11:48:14 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om84KOwRiXha for ; Tue, 11 Jul 2017 11:48:14 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1ACF7BF48 for ; Tue, 11 Jul 2017 11:48:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499770094; bh=521YQlXkK+CbQAGDi1272+d9yRsKsP1HdwnqSUEk9bk=; h=To:From:Subject:Date:From; b=Tf6AaMUCFjPfTTmeUJXGnNH7iW9YfksPGYC7IHFa/RCKQK/q29BzLyaMjwyaJIm6k 1wzz9zTUDeXliqtONIsgtDPEY5rfGQHh9NUY2HEHu4gxo6/JnvV5ScdK5kKMAnxJLY GZxTsI69GBOeNW7xfRmJ4dx+23/5Y/+gdaTwMlZE= To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> Date: Tue, 11 Jul 2017 11:48:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gdNp1nwJUfOG2fuiVJSTmFDA6FobU4Mnu" Archived-At: Subject: [TLS] wiretapping draft - collecting rebuttal arguments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 10:48:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gdNp1nwJUfOG2fuiVJSTmFDA6FobU4Mnu Content-Type: multipart/mixed; boundary="P6pxoPIv90rcvWn9nfdIjSvKM9PLOKaUk"; protected-headers="v1" From: Stephen Farrell To: "tls@ietf.org" Message-ID: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> Subject: wiretapping draft - collecting rebuttal arguments --P6pxoPIv90rcvWn9nfdIjSvKM9PLOKaUk Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, I've asked the chairs for a slot in Prague to allow for rebutting the claims made by the proponents of the most recent wiretapping draft we're (sadly, still) discussing. [1] So far the chairs seem un-keen, but I'm gonna keep asking as I think having a rebuttal for this kind of bad idea is needed. (And again, I'd prefer the chairs ditch the entire idea of discussing this at all.) In any case, and perhaps with a view to longer-term documenting the arguments against the various "let's break TLS" proposals we continually see, I've started to collect some of those arguments in a github repo [2]. I would welcome contributions to [2] however folks would like to provide 'em (but ideally via PRs) so we can provide a nice crowd-sourced rebuttal in Prague, either as a presentation or via a lively mic-line if need be. Cheers, S. PS: I've just started on this, but will go through the list archive to extract others' arguments and add acks. Not sure if that'll get done before we end up in Prague but please do let me know if I've used an argument you made so I can ack that later. [1] https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 [2] https://github.com/sftcd/tinfoil --P6pxoPIv90rcvWn9nfdIjSvKM9PLOKaUk-- --gdNp1nwJUfOG2fuiVJSTmFDA6FobU4Mnu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZKzuAAoJEC88hzaAX42iRk4IAJ+S/Z9C5I9x63OIPEF7p4fI nPkaxdQs3Zcd5xW9BORHyK2QgukYnbRR4as1Up4a4R9ROTeFEaGXljhgGRPAdJiD Zt62vIz8+/j3M+6gUqrLlbNg6iD8YNMDQX6k3AsdlXqGm1X5a69k0fG/Jf/fDKtd +If76VxwWI5IbIRe+AZk/1IVXw7i8KSCS8vktJvHMhXhpsQFH5SgJ1ur2b23d1qa Zlbk+jet+YhTsJXm48TQWT3ov6LSo10Br8vsH63Tw5wCy6tKtxcpCbmId6ooLahJ ntPq9qNkkoW9YhhzH4uD8v9aj8PcQ9rkOoWbsFLIrbE2DmaRnN5L7zQiLPKmjgE= =QTH+ -----END PGP SIGNATURE----- --gdNp1nwJUfOG2fuiVJSTmFDA6FobU4Mnu-- From nobody Tue Jul 11 04:02:24 2017 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 1EB6612EB99 for ; Tue, 11 Jul 2017 04:02: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, SPF_PASS=-0.001, URIBL_BLOCKED=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 PpTUA4iw5B3q for ; Tue, 11 Jul 2017 04:02:20 -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 5676912EB43 for ; Tue, 11 Jul 2017 04:02:20 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id v143so98376834qkb.0 for ; Tue, 11 Jul 2017 04:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2jnam+aU5bc0Ead3CFrdd7+5QWkIGMYREIj7rFGqq6I=; b=g+4mojoMiSZA3pI9HuvOsp+i8HXwWHCwRN2SsAinP5Gpuaa/4McTJo3sPuJIDgrFJK XIEHQirQsoXeBeBjuiYX6UuR8t/w9qo1j9pdL3OvKs1EHyDNcgyGb4wD0pwdSCbO8LPp TaWBgimuybgGzP8wi7TTY8v+5Gn9V9c3Eg+3ZMbkFosE/ROueMiv2RILDkZWAWn4b3vv oL7Uj69eNpewlTqGLTZsKRI52Fz1ppAshKOuQrek7juePWByrjDw/cH8GCACC5n27PyO pLqYks+p2kUNcU0VqQvW4bxZg9q4Jk72r+p8nJ0r8nDLOGAZQTAAu0IqCoGNtG4GNlqI JnwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2jnam+aU5bc0Ead3CFrdd7+5QWkIGMYREIj7rFGqq6I=; b=YwcEoS2zxdwoBwy5Oo3aR2Lh4DNo9hMJ0SoKnfTNDU57BJz22gRH954dUuOgFdilxg yO2dnFsPNaznR/TCtBjj10XSgf8+hX/7nQ7/Me2JeA+Js6TAuRJnKtL3jk/sc7+Bh7iz FhVo6Czc+tlKCGH1ojocihFEntT415//h8ys1cZ/zrNhDD3JpCPLK5Bg3Yfj50+QM4pJ GzrlnqmTLI3QtAyYxMOSAk9NGOKQFSXvPBbp5s3dzj2nb9pVgUpu+/Urtrmuv/v2zTL6 WzRMSkjwSS5MWGcqL3697vV0dIE1JtdBZsTEffvBsZ9M1S5ETfbBTQASLQ1GQtGI5HpJ VCRg== X-Gm-Message-State: AIVw112tLyTRQAzRuh3GF5mhZz7roBbiSW9NAbckdPoxaqNfOgMjhVKZ jZR7nV/96QNUQNDuVyTxcg== X-Received: by 10.55.38.149 with SMTP id m21mr10269837qkm.39.1499770939422; Tue, 11 Jul 2017 04:02:19 -0700 (PDT) Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n2sm10177579qkc.59.2017.07.11.04.02.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 04:02:18 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E892AD14-9FE3-4D0D-9BE8-6FAE286F461B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Jul 2017 07:02:17 -0400 In-Reply-To: Cc: Russ Housley , "Polk, Tim (Fed)" , IETF TLS To: Stephen Farrell References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 11:02:23 -0000 --Apple-Mail=_E892AD14-9FE3-4D0D-9BE8-6FAE286F461B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 10, 2017, at 5:35 PM, Stephen Farrell = wrote: > Consider SMTP/TLS. Where one MTA on the path supports this. > Say it's one operated by an anti-spam company for example. > That is clearly not the sender nor recipient. >=20 > That meets all 4 points in 2804, right? I don't buy this, Stephen. The anti-spam company is not an = eavesdropper. What I don't understand about your approach to this draft is that it = seems to me that the draft is obviously describing an exploit in TLS = 1.3, for which a mitigation exists: remember keys, and refuse to = communicate with an endpoint that presents a key you've seen before. So rather than opposing the publication of the static keys draft, why = not work on mitigating the attack it describes? This attack exists = whether the static keys draft is published or not. --Apple-Mail=_E892AD14-9FE3-4D0D-9BE8-6FAE286F461B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 10, 2017, at 5:35 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
Consider SMTP/TLS. Where one MTA on the = path supports this.
Say it's one = operated by an anti-spam company for example.
That is clearly not the sender nor = recipient.

That meets all 4 = points in 2804, right?

I don't buy this, Stephen.   The anti-spam company is = not an eavesdropper.

What I don't understand about your approach to this draft is = that it seems to me that the draft is obviously describing an exploit in = TLS 1.3, for which a mitigation exists: remember keys, and refuse to = communicate with an endpoint that presents a key you've seen = before.

So = rather than opposing the publication of the static keys draft, why not = work on mitigating the attack it describes?   This attack exists = whether the static keys draft is published or not.

= --Apple-Mail=_E892AD14-9FE3-4D0D-9BE8-6FAE286F461B-- From nobody Tue Jul 11 05:49:46 2017 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 075911316D0 for ; Tue, 11 Jul 2017 05:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCvrkh7fRxeR for ; Tue, 11 Jul 2017 05:49:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388261200B9 for ; Tue, 11 Jul 2017 05:49:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9E0E2BF74; Tue, 11 Jul 2017 13:49:39 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEv4iAKxYbXu; Tue, 11 Jul 2017 13:49:39 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5E91BBF2E; Tue, 11 Jul 2017 13:49:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499777379; bh=ZYY8PdhgvVg28ncXi+atveSboxHUaILuqU5aGk8POCw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=C3R57OMol/a612i8w0ya+SSOT16Q8UjxVIf1y4kO8Sfp9KHXnbcAh9BlZ93Ol1Par MvEQzJ2us31lQyIrYaOMJi+zh63Mtia7RbtpMsPtAIeuo6rGFbj12RdVyvw8yVdGmg +c7lqLasV2WhlciqGgNFkgNLejA0WlegJFJiQuTI= To: Ted Lemon Cc: Russ Housley , "Polk, Tim (Fed)" , IETF TLS References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> Date: Tue, 11 Jul 2017 13:49:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ORO6d4IGmEkuuaa9lKD9Qfso1O2IXVGa6" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 12:49:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ORO6d4IGmEkuuaa9lKD9Qfso1O2IXVGa6 Content-Type: multipart/mixed; boundary="V96p7FBnQ5rR2W5xD8u064Ot6EMfp5Ihp"; protected-headers="v1" From: Stephen Farrell To: Ted Lemon Cc: Russ Housley , "Polk, Tim (Fed)" , IETF TLS Message-ID: <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> In-Reply-To: --V96p7FBnQ5rR2W5xD8u064Ot6EMfp5Ihp Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 11/07/17 12:02, Ted Lemon wrote: > On Jul 10, 2017, at 5:35 PM, Stephen Farrell > wrote: >> Consider SMTP/TLS. Where one MTA on the path supports this. Say >> it's one operated by an anti-spam company for example. That is >> clearly not the sender nor recipient. >>=20 >> That meets all 4 points in 2804, right? >=20 > I don't buy this, Stephen. The anti-spam company is not an > eavesdropper. This draft proposes a way for an eavesdropper who recorded the cihphertext packets from anywhere to use a standardised interface to get a small package of key material from the anti-spam company (via coercion or collusion), that allows the eavesdropper to decrypt all the TLS protected email traffic sent via the anti-spam company. Looked at one way, tt amounts to standardising a key exfiltration attack. >=20 > What I don't understand about your approach to this draft is that it > seems to me that the draft is obviously describing an exploit in TLS > 1.3, for which a mitigation exists: remember keys, and refuse to > communicate with an endpoint that presents a key you've seen before. The TLS server doesn't need to do things in a way that a TLS client can detect. > So rather than opposing the publication of the static keys draft, why > not work on mitigating the attack it describes? This attack exists > whether the static keys draft is published or not. Good/better TLS1.3 forward secrecy is being discussed as part of the normal work in the WG. It is for sure always possible to manage keys badly, but this draft proposes an API to expose private key materials which is not the same thing as bad implementation or management at all. Cheers, S. >=20 >=20 --V96p7FBnQ5rR2W5xD8u064Ot6EMfp5Ihp-- --ORO6d4IGmEkuuaa9lKD9Qfso1O2IXVGa6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZMljAAoJEC88hzaAX42iAgcH/iRVudl6o9BHFdxEzdb+J1H6 BKsuP/lc19GWdZCERuDq2vW22KjXIf4HvXpr6CLxcp6ly794ByIlb/xKcttInC/J 8WHQ35LlZ+OSasdx0FCF+6uEvG0Kz/Ooo/hrTPrauwXiEGpknn3qhpBHKl5n70+Y HgfGBwRKVfP3Vib64qgCkh21Q2gJ3+/bC5Ply82pxmtNRm7FS1ktNjuDen3Dbt3h 0Afbw/qq4LCpWY2YZT3AJ5I5VNXw6TY1cJ5c8EGq6Nbb9Rc9/nOl7F2uSiy0u2GJ GiKOlVwt4LGAbYb1KNVzI+o7yLlPBO+/8FPZfvMIzRSldcMQ9kLc7C7Cu57gu3w= =XAqk -----END PGP SIGNATURE----- --ORO6d4IGmEkuuaa9lKD9Qfso1O2IXVGa6-- From nobody Tue Jul 11 06:11:47 2017 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 635E8129ADA for ; Tue, 11 Jul 2017 06:11:45 -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=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 oZFknFEgRywX for ; Tue, 11 Jul 2017 06:11:44 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 46C6D128B8D for ; Tue, 11 Jul 2017 06:11:44 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l21so48593406ywb.1 for ; Tue, 11 Jul 2017 06:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gRcAFQm3keztKYQF3pj6MWOld6A0hEMOb1ssYMN4JXc=; b=mgDv+vyCVw0DPkCEAR9oatfnppq9vCCBPIe6Yg6wNaxKT2ea6Z8hqlL3noPf0hLgQc zFnc7Sm7sUzIa3p8jzyQ2QwA+9wDFvbMpp4+AVRbrvffzM1NowhyYbtIH60eQnJ6Y4u/ S+gSrqwBmsCeZdWkJJcSMDI5OG9CgBEpGQFr3eZhcX7GB93wHrsOqccu4xr5rF/6LUVs M5Cv0szP80/mI2qd0Vbd44bDIN0ZGjEla+IMSaTY3zNzgqC0x6JQs5Ghirvq1c9zAiaZ wEQysOL8tPV/hixpaGvZrQnNGmkox1g05BSGwwyLcow4l/EMNXoiPo/wSutP7LOMj0Zf M3Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gRcAFQm3keztKYQF3pj6MWOld6A0hEMOb1ssYMN4JXc=; b=oN3gkre5txboc66pks81JBJS6iLWlGIFLa3/DudtKvaubyJFSTycSJ8aTXzapaleUG SWN7qsXmTx44d3SpHNvr14fB2D6SRZSGKU5HsKDBB8bqnK3bvMsmxLhrx+/erSJZoZso q+zJvdW+3ulY8kpdP9pRiIXVbdcfFgxC7+ZCGNviZsIyz1sz8JzrEX6r/TyG6UuAab5T aDlRBMhv4X+HNDD8vyqzOU/UkpLLyL/RYV6wsO9Ossc1tfml5l7HRfrlmb8Bhq5kX53y CKkGFnYRMRTnsusKJcEDhf+rOyqcWGsiqUWiN43EGnue6r6xk2wz9GFt6mKGs3w+Flav GdLw== X-Gm-Message-State: AIVw110DOwC3nCSB0MJdrLs1Ov8kSsqWhrNjcLqsUKkz7P55pA6teQLB itFGTUXYrkRXlJWd X-Received: by 10.200.49.73 with SMTP id h9mr11382057qtb.13.1499778703172; Tue, 11 Jul 2017 06:11:43 -0700 (PDT) Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id d17sm11838659qtb.47.2017.07.11.06.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 06:11:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5304i) In-Reply-To: <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> Date: Tue, 11 Jul 2017 09:11:40 -0400 Cc: Russ Housley , "Polk, Tim (Fed)" , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 13:11:45 -0000 What the draft actually says is that you can install a fixed key on the serv= er rather than generating new keys every time, and then that fixed key can a= lso be installed on monitoring software. This is, I believe, the actual in= tended use of the proposal. It=E2=80=99s also true that you can just exfiltrate every key as it=E2=80=99= s generated, but that=E2=80=99s not what=E2=80=99s being proposed and would n= ot, I think, suit the needs of the operators who are making this proposal. I don=E2=80=99t see how you could mitigate against deliberate key exfiltrati= on. At some point you really are relying on the security of the endpoint. = But being able to detect repeated keys is useful for preventing pervasive m= onitoring: it requires the monitored either to have access to the key genera= tion stream in realtime, or to request the key for a particular conversation= . So I think there is some value in defending against this attack. I look for= ward to seeing a defense that uses perfect forward secrecy and protects agai= nst key exfiltration. From nobody Tue Jul 11 08:00:32 2017 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 8F0F612F3D5 for ; Tue, 11 Jul 2017 08:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 SN-IjPK_Igxa for ; Tue, 11 Jul 2017 08:00:27 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 1A836127B57 for ; Tue, 11 Jul 2017 08:00:26 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 19211C24C4 for ; Tue, 11 Jul 2017 10:00:26 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 2A9F2C246B; Tue, 11 Jul 2017 10:00:25 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DC627FE063; Tue, 11 Jul 2017 11:00:24 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A14AAFE069; Tue, 11 Jul 2017 11:00:24 -0400 (EDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (unknown [216.32.180.183]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Tue, 11 Jul 2017 11:00:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5Vhhe7FcXdqCZ/uL4YJIiwNUn9hf7HYxRdKwhZtZg2s=; b=5GskbzDc4EFP/0eo3yCJ2gTnFplWyMwFSskfCZmg9DUa1ek+1BIwEgKSvQPQvJJ/dbblW/WiejQfdIu0wTdzyVNdWt7jnKfoK2Jw3RVDc9YxGcEPeuySZtKINudJyR5fG6/Z/wJo3ALJchlbbqtdtrAqobWyBT+lcnJ7IDPkJ8Q= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1367.namprd14.prod.outlook.com (10.172.158.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Tue, 11 Jul 2017 15:00:23 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.020; Tue, 11 Jul 2017 15:00:23 +0000 From: "Ackermann, Michael" To: Ted Lemon , Stephen Farrell CC: "Polk, Tim (Fed)" , IETF TLS Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQHS+YQI7m7fVGNOTUGFuL/08f/fM6JNIUiQgABTlgCAAAqIoIAAEXkAgAAChYCAAAJwgIAA4XWAgAA4+AA= Date: Tue, 11 Jul 2017 15:00:15 +0000 Deferred-Delivery: Tue, 11 Jul 2017 15:00:00 +0000 Message-ID: References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [167.242.122.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1367; 20:OhSDp7Zg6y1R/zUT2gV5rog9gFw+a2awaNEbkERq6GNHaP+4B2h8T3gbZ4DELxgcNvqdfAmMwI1WYu5OTqtHmFvj8hdeczpS1MLLNi/7jzYM87o1CAFvbMkrnMtjgeEEwUz5KwU2ksVAq804I0zcftj2wH8oqFLmyV4u7b9we6U= x-ms-office365-filtering-correlation-id: 50426c6e-540e-417c-e9ad-08d4c86d8e77 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1367; x-ms-traffictypediagnostic: CY4PR14MB1367: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(32856632585715)(65766998875637)(26388249023172)(236129657087228)(48057245064654)(148574349560750)(21748063052155)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1367; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1367; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39400400002)(39410400002)(377454003)(24454002)(99286003)(6116002)(66066001)(189998001)(2900100001)(561944003)(9686003)(54356999)(76176999)(38730400002)(5660300001)(72206003)(229853002)(6306002)(8936002)(53936002)(8656002)(55016002)(14454004)(8676002)(7736002)(3660700001)(50986999)(236005)(478600001)(54906002)(6246003)(25786009)(790700001)(54896002)(102836003)(81166006)(3846002)(86362001)(2950100002)(6436002)(6666003)(80792005)(33656002)(3280700002)(74316002)(53546010)(7696004)(6506006)(93886004)(77096006)(2906002)(4326008)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1367; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB136850F84F0A28AEC8C326C1D7AE0CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2017 15:00:23.2515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1367 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 7ea3f388-15d2-4ab3-b533-b09d71220f04 X-VPM-MSG-ID: 5944cd2f-d85e-40c8-b5e6-b88f1a7d00c1 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 15:00:31 -0000 --_000_CY4PR14MB136850F84F0A28AEC8C326C1D7AE0CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not certain if I speak for all Enterprise individuals involved in = this discourse or not. But I would like to endorse what Ted is saying. As much fun as this debate has become (not), Enterprises originally = raised this issue to the TLS-WG, to engage their considerable expertise, = and to help solve what will be a huge business problem, when TLS 1.3 is = implemented. I believe all of us Enterprise people would prefer to work with the SMEs = at TLS-WG, to determine the best possible answer to this very real issue = we will all face. That is why we came to this WG. The draft proposal is the best solution I have heard. If there is a = better approach, we all need to be open to this, as well as open to = perspectives on both sides of this issue. IMHO we want to work with the = TLS-WG, not work around it, in an effort to craft the best possible = solution(s), with ALL related issues addressed. From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Ted Lemon Sent: Tuesday, July 11, 2017 7:02 AM To: Stephen Farrell Cc: Polk, Tim (Fed) ; IETF TLS Subject: Re: =5BTLS=5D chairs - please shutdown wiretapping discussion... On Jul 10, 2017, at 5:35 PM, Stephen Farrell = > wrote: Consider SMTP/TLS. Where one MTA on the path supports this. Say it's one operated by an anti-spam company for example. That is clearly not the sender nor recipient. That meets all 4 points in 2804, right? I don't buy this, Stephen. The anti-spam company is not an eavesdropper. What I don't understand about your approach to this draft is that it seems = to me that the draft is obviously describing an exploit in TLS 1.3, for = which a mitigation exists: remember keys, and refuse to communicate with = an endpoint that presents a key you've seen before. So rather than opposing the publication of the static keys draft, why not = work on mitigating the attack it describes? This attack exists whether = the static keys draft is published or not. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB136850F84F0A28AEC8C326C1D7AE0CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

I= am not certain if I speak for all Enterprise individuals involved in this = discourse or not. 

B= ut I would like to endorse what Ted is saying.

<= o:p> 

A= s much fun as this debate has become (not),  Enterprises originally = raised this issue to the TLS-WG,  to engage their considerable = expertise, and to help solve what will be a huge business problem,  when TLS 1.3 is implemented.  =

I= believe all of us Enterprise people would prefer to work with the SMEs at = TLS-WG, to determine the best possible answer to this very real issue we = will all face.     That is why we came to this WG.   

T= he draft proposal is the best solution I have heard.   If there = is a better approach, we all need to be open to this, as well as open to = perspectives on both sides of this issue.    IMHO we want to work with the TLS-WG, not work = around it, in an effort to craft the best possible solution(s),  with = ALL related issues addressed. 

<= o:p> 

F= rom: = TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Ted Lemon
Sent: Tuesday, July 11, 2017 7:02 AM
To: Stephen Farrell <stephen.farrell=40cs.tcd.ie>
Cc: Polk, Tim (Fed) <william.polk=40nist.gov>; IETF TLS = <tls=40ietf.org>
Subject: Re: =5BTLS=5D chairs - please shutdown wiretapping = discussion...

 

On Jul 10, 2017, at 5:35 PM, Stephen Farrell = <stephen.farrell=40cs.tcd.ie= > wrote:

= Consider SMTP/TLS. Where one MTA on the path supports this.
Say it's one operated by an anti-spam company for example.
That is clearly not the sender nor recipient.

That meets all 4 points in 2804, right?

 

I don't buy this, Stephen.   The anti-spam = company is not an eavesdropper.

 

What I don't understand about your approach to = this draft is that it seems to me that the draft is obviously describing = an exploit in TLS 1.3, for which a mitigation exists: remember keys, and = refuse to communicate with an endpoint that presents a key you've seen before.

 

So rather than opposing the publication of the = static keys draft, why not work on mitigating the attack it describes? =   This attack exists whether the static keys draft is published or = not.

 


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB136850F84F0A28AEC8C326C1D7AE0CY4PR14MB1368namp_-- From nobody Tue Jul 11 11:39:15 2017 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 26AA513179A for ; Tue, 11 Jul 2017 11:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 YGLmheLRGAny for ; Tue, 11 Jul 2017 11:39:12 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::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 C391313179E for ; Tue, 11 Jul 2017 11:39:09 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id c20so106478qte.0 for ; Tue, 11 Jul 2017 11:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:message-id:date:to:content-transfer-encoding :mime-version; bh=Ziubp72Q2SkUdXHZn3PtBnbNzs6A2dYVMDvtdVa8+6s=; b=gA6uCRL0FUQxbwt/UNSXdTmXqeGlTO9Lk64HO/l4ZEVeEA5YIRnpck8+8et5IM57aI aYGfv7DIDDU7CocomiWAmAA25IfTl2e2lzDLs377zLwMn2x1MZ//kzRuF2TkZ9n5lwpT SQpuumoe7qZ61YGXfEtgeAcrdfe4BppJfHEnuUChCfBvQf6hlpc22mvT+S3VIksTAzZh yeGEBuf8bcD6RQiBZIIfsRAMPdtLu3/Lbja/daNOcyqVSOIpGKy2Kl45RRzFmgtuE1Hc XVzXxZrxRr20V9+5sjrda/Lu4mfroAJP2GceXPWLQZuvOX0OxLOV3JsFunxJiVmvsNzM 355Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:message-id:date:to :content-transfer-encoding:mime-version; bh=Ziubp72Q2SkUdXHZn3PtBnbNzs6A2dYVMDvtdVa8+6s=; b=GxLgx8KIxYi+PKnh99aCmhZ9PBp1cF6r54IvkBzfcr+ZbyXXfgM5msMzESmplbKr57 ivj52uhtDkm42qrD4GNtj9Qhl7jBYjCCUAWdf6RYncc44/D2RNcGP2qadeHKtMAgYTnJ Y7/ecakApeXJlbQ/w7/pIegFA4t6yf+slA0ogqxEppF4OBXqL75bt8flsAexSt9dmLOq 7vdGGrLLmlJxV4gQI3Vm6KBqhpLAq/CO0KPZbZE6b33KZumHHKzvF9BEMVX/HNveCflH gosZX6XANqm3ldK6vIbICobVFcp4SIhI0Fv2SgKi53uQ8IcOEX6aTq4fsdD4uYcL73QC B9bA== X-Gm-Message-State: AIVw110dD3mmsgufr4mXLafhwLyvlwdza4yKEbmhTZxhVX3O7tEOmLtc uPS+MVTChim1ULsiqYg= X-Received: by 10.237.51.70 with SMTP id u64mr1689138qtd.211.1499798348705; Tue, 11 Jul 2017 11:39:08 -0700 (PDT) Received: from [100.73.242.54] (236.sub-174-219-12.myvzw.com. [174.219.12.236]) by smtp.gmail.com with ESMTPSA id q40sm34043qtf.42.2017.07.11.11.39.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Jul 2017 11:39:07 -0700 (PDT) From: Steve Fenter Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11D201) Message-Id: Date: Tue, 11 Jul 2017 13:39:08 -0500 To: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 18:39:14 -0000 Proxies in the Data Center There are a number of reasons that inline proxies are not a scalable solutio= n for monitoring communications in enterprise environments. -- cost -- production risk -- latency Here are some specific examples of where the use of proxies for monitoring c= ommunications is not viable: Network Security Monitoring Network security monitoring is not just monitoring traffic that results from= communications with customers and partners. All it takes is for one user t= o click on a phishing email and there is malware inside the enterprise. Onc= e this happens, TLS becomes the enemy, because 30% of malware is TLS encrypt= ed, and any TLS features intended to thwart payload inspection work against t= he enterprise. Malware does not always phone home out to the Internet on day 1 of infection= . Sometimes it does reconnaissance and lateral movement for a long time. T= he longer this goes on undetected, the worse the situation becomes for the e= nterprise. Microsegmentation is an attempt to contain this movement, but if the malware= is TLS encrypted it will go right through the firewalls. The answer to thi= s problem is ubiquitous plain-text traffic inspection. The scale at which t= his is needed can't be accomplished by inline solutions (proxies). Traffic i= nspection is needed at the Internet, the Extranet, the mainframe, the WAN, D= NS servers, email servers, wireless controllers, and a host of other locatio= ns. Traffic inspection is also needed in the virtual environment, where all= the virtual tools necessary don't exist yet. My Seoul presentation documen= ted 150 physical tap points feeding network security monitoring devices - an= d this footprint is growing. There are too many inspection points to replac= e with inline solutions. You simply cannot place a proxy between every syst= em in the enterprise. One other crucial point to this discussion is that endpoint monitoring doesn= 't catch everything. The strategy of "Defense in Depth" says that the more l= ayers of security infrastructure you have, the better your chances of blocki= ng or identifying malware. Network security monitoring is catching lots of m= alware missed by endpoint inspection. Threat Detection and Incident Analysis Threat detection inside the enterprise is not just receiving IDS or endpoint= monitoring alerts. Threat detection analysts need to track down the source= of the infection, which could be anywhere within the enterprise, and the pr= imary tool for doing this is packet capture with a decrypted payload. Becau= se the source of the infection could be anywhere, we need ubiquitous packet c= apture and ubiquitous decryption capability. Again, inline solutions don't s= cale to the number of monitoring points needed for this level of visibility.= No only does an out-of-band solution like static DH allow many more permanen= t monitoring points with simple network taps, it also allows enterprises to d= eal with gaps in visibility. If a needed flow is missing, we can set up spa= n or mirror sessions, capture the packets, and decrypt them after the fact. = This can't be done when relying only on inline proxies. Adding a new inlin= e proxy is a multi-month or more project. In the midst of an active attack/= infiltration every minute is crucial and network re-architecture is not an o= ption. Troubleshooting Enterprises provide services through complex, multi-layer applications and b= ackend infrastructure. Inevitably, there are bugs in these applications and= the source of the problem must be found through troubleshooting. Network t= roubleshooters need to inspect the packet payload in order to find transacti= ons on the wire in environments where there is extensive NAT and extensive e= ncryption. Both of these are very common in enterprise networks, and encryp= tion inside the data center is becoming more ubiquitous over time. NAT, by= the way, is being used in large part not for IP address exhaustion, but to a= llow for multiple redundant paths. Complex applications can have hundreds of application and infrastructure nod= es as well as many tiers, any of which could be the cause of a slowdown or f= ailure. Often there are no log messages on any device giving a clue as to t= he source of a problem. Troubleshooters need to be able to take a packet tr= ace at any layer of the infrastructure and decrypt the trace in order to fin= d the transaction of interest. This tracing could be between physical devic= es, like between a firewall and load balancer, or it could be between VMs. T= racing in the virtual space could involve tracing between VMs on different b= lades of the same blade chassis or between VMs on the same ESX host. Since t= he root cause of a problem can be anywhere in an enterprise, this translates= into thousands of locations in a large enterprise where troubleshooters may= need to take a trace, decrypt it, and locate a transaction. Inline proxy solutions add cost, production risk, and latency at every layer= in which they are implemented. It doesn't take very many inline locations b= efore the cost is in the millions of dollars. Because the solution is inlin= e, lots of redundancy has to be built in, including multiple columns (doubli= ng the cost), bypass taps for failure scenarios, and extensive procedures fo= r troubleshooting and failover. Bypass taps and TLS decryption appliances c= an and do fail, and when they are inline a production outage is caused, usua= lly in a critical part of the network and affecting multiple critical applic= ations. Proxy solutions also add 1-3 ms of latency to every packet. This i= s not a big problem at one layer, but when many tiers are implemented with i= nlien proxy solutions the latency adds up. From nobody Tue Jul 11 11:52:05 2017 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 4E3C813179F for ; Tue, 11 Jul 2017 11:52:03 -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 UgqeIdKJubLk for ; Tue, 11 Jul 2017 11:52:00 -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 58D5D131756 for ; Tue, 11 Jul 2017 11:52:00 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p21so836248qke.3 for ; Tue, 11 Jul 2017 11:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zOH52o+5vADF8+aE14ekVhoLYKU+Owo/fR+P7j7cMyQ=; b=vjMtRzEuJQGKesbDatRi+k8Egy+N252OUXWfaeZevo+1bsQyhFQ2idG2ndXB7vc+wM Rr7DXPqzzVMGkgYiM/W9fL58NtmGCjfM5a9yIheqlg1Mu3zH5F1Ej1MCOSgFnQg5sksv TJSBT+3RfDagVQxOqiDSCVsbwzONRkzJiqd7IauyCafFH0t6C4d+qQXpDDJCEqQnEMXZ jWOBjPE1xvRhHU87WY24obA2w80SoNIHzPuGGr+vsviHaLG5TFdCqc7SMgiinrMV0wEj +TLwkbhFGrIufaU8YtwolTh1fp0FuLsVyrdz//+hJcsDPutR0f80zuICbrrTRaEVfFAN 1byw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zOH52o+5vADF8+aE14ekVhoLYKU+Owo/fR+P7j7cMyQ=; b=aZChKWap/6P9HLD/hpe/dDhiMKejRK5pQ0DnaCw0REOIrnEj/h6u5mqHXMs6aw7s51 JUsLfHS+S/Xxj9C4g0XX7pRBbIRmFtuUxpgUeE8VtGRKoBWlrvJw6gZ4fShn2ro8MMbe HLjXPrcou8oueIg0iksvyyXz4KfL55vu/KE7bRnFiIzrar8PBCvzswuLPWWBaHhRY7so 77f5Lc/ajdA2qspYdrEw/3intmVFFRFD88BNVTKPB+gCfRq/oUB1BXxAtXbY74VLQ8Wk amxvzDNZaXE30zdNPh2m7T/wqDrgp8aFgz+eIk6EaFB8aqvRMf0MjkSyC/a0mV/0+Kem Ushg== X-Gm-Message-State: AIVw111O5dZLoriykycT2Ahmhb3XOdHYbAHvAsMV2ED97xJqPBm2m0A1 k3aEaZ4H8LXw6miv X-Received: by 10.55.5.135 with SMTP id 129mr1767728qkf.184.1499799119289; Tue, 11 Jul 2017 11:51:59 -0700 (PDT) Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id p24sm41470qki.49.2017.07.11.11.51.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 11:51:58 -0700 (PDT) From: Ted Lemon Message-Id: <972BC031-5CE1-4810-B7DC-62CA3B7B60CB@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F002256-C6C1-490B-AC90-C4FE19F48A12" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Jul 2017 14:51:57 -0400 In-Reply-To: Cc: "tls@ietf.org" To: Steve Fenter References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 18:52:03 -0000 --Apple-Mail=_5F002256-C6C1-490B-AC90-C4FE19F48A12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 11, 2017, at 2:39 PM, Steve Fenter = wrote: > Network security monitoring is not just monitoring traffic that = results from communications with customers and partners. All it takes = is for one user to click on a phishing email and there is malware inside = the enterprise. Once this happens, TLS becomes the enemy, because 30% = of malware is TLS encrypted, and any TLS features intended to thwart = payload inspection work against the enterprise. I realize that you are making a substantive comment here and might not = welcome a sales pitch, but FWIW there are ways of addressing this that = don't involve examining each stream, and are likely as effective. = E.g., malicious domain redirect based on the domain name in the URL. = This is a lot cheaper than doing decryption and inspection of the = contents of every TLS stream. It also allows for other methods than = payload analysis for detecting probably malware=E2=80=94e.g., pattern = analysis. I'm pretty sure that Stephen will tell you that this is an = attack as well, and he's not wrong, but it has the virtue of not = requiring that TLS be broken. Also, please note that the proposal you are referring to does not solve = this problem at all, unless the malware is already on a server on your = network (which is the scenario you are describing). If that's the = case, why is TLS intercept the most cost effective way to detect this = malware? It seems to me that it would be a lot easier to just scan the = file on the server before making it available for download. Can you explain why that's not the right solution for this particular = use case? Also, although there was a lot of talk about how you need to do = decryption-and-inspection rather than using proxies for performance, = that actually just doesn't make sense. Is it because the proxy is too = close to the edge, resulting in trombone routes? Otherwise I don't see = how it could possibly be more efficient to decrypt and eavesdrop than to = proxy. Can you explain? Sorry to hold your feet to the fire, but what you are saying here just = doesn't make sense to me. As for threat detection, again I'm not seeing how decryption and packet = analysis is a win here. Can you explain? I see why it's helpful for troubleshooting, although again a proxy would = take care of that. But in any case, for the other two examples, it = doesn't make sense even from a performance perspective. --Apple-Mail=_5F002256-C6C1-490B-AC90-C4FE19F48A12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 11, 2017, at 2:39 PM, Steve Fenter <steven.fenter58@gmail.com> wrote:
Network security monitoring is not just = monitoring traffic that results from communications with customers and = partners.  All it takes is for one user to click on a phishing = email and there is malware inside the enterprise.  Once this = happens, TLS becomes the enemy, because 30% of malware is TLS encrypted, = and any TLS features intended to thwart payload inspection work against = the enterprise.

I realize that you are making a substantive comment here and = might not welcome a sales pitch, but FWIW there are ways of addressing = this that don't involve examining each stream, and are likely as = effective.   E.g., malicious domain redirect based on the domain = name in the URL.   This is a lot cheaper than doing decryption and = inspection of the contents of every TLS stream.   It also allows = for other methods than payload analysis for detecting probably = malware=E2=80=94e.g., pattern analysis.   I'm pretty sure that = Stephen will tell you that this is an attack as well, and he's not = wrong, but it has the virtue of not requiring that TLS be = broken.

Also, = please note that the proposal you are referring to does not solve this = problem at all, unless the malware is already on a server on your = network (which is the scenario you are describing).   If that's the = case, why is TLS intercept the most cost effective way to detect this = malware?   It seems to me that it would be a lot easier to just = scan the file on the server before making it available for = download.

Can = you explain why that's not the right solution for this particular use = case?

Also, = although there was a lot of talk about how you need to do = decryption-and-inspection rather than using proxies for performance, = that actually just doesn't make sense.   Is it because the proxy is = too close to the edge, resulting in trombone routes?   Otherwise I = don't see how it could possibly be more efficient to decrypt and = eavesdrop than to proxy.   Can you explain?

Sorry to hold your feet to the fire, = but what you are saying here just doesn't make sense to me.

As for threat detection, = again I'm not seeing how decryption and packet analysis is a win here. =   Can you explain?

I see why it's helpful for troubleshooting, although again a = proxy would take care of that.   But in any case, for the other two = examples, it doesn't make sense even from a performance = perspective.

= --Apple-Mail=_5F002256-C6C1-490B-AC90-C4FE19F48A12-- From nobody Tue Jul 11 12:01:43 2017 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 60F251317A8 for ; Tue, 11 Jul 2017 12:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 GIJ-C_KVPbdU for ; Tue, 11 Jul 2017 12:01:39 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 A9A1713179C for ; Tue, 11 Jul 2017 12:01:23 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id r30so1144183qtc.0 for ; Tue, 11 Jul 2017 12:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=9+m0kTs460hcrqt87hGM4/lEEwx+bNMLe0dXdG2vVeM=; b=E6uhu+hGL6vaRkE7NdrVuKqZ8Nnot7jC6rJw2NtNY/4zGhJ3riLkzDQkv5hNZHd/kX Mv/nMOPWJHgupg+1xwkvA7Ta/oDk2AQ3JaHXzYVc/mahWBCiaS6FanRoeFBoVlrNbNGt mpAQ06eMnoFaRhHPJzztKzxOKsXqBe0H7Ntp+0fr7Ad1lDdiFWDk3Rw1/PJ30oCecIeO OPCH70pY4U6z5PbFPvAJAJn8ctv93KMADKsGMlqv9uMC0MeXBNA7H8VU5qNgetNqjkqr NqvieMyAgdpxIg/yQNAudUNTbztgcu91ESHzewFSpjtiXl6MXE/Qm10UI0yTDC2eoq8Y xkMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=9+m0kTs460hcrqt87hGM4/lEEwx+bNMLe0dXdG2vVeM=; b=cInMJuWQtJiTxnHZMu9CVLrFLHlhLgT+0HYLv8zEl9OwLS6LxdbAvQVBsxCIJwBDvs 8FLOj9psLSEoDirCRPdGmnlLPxpXPi4rjv2xqbxUhifv77zUWLblzsb9nw3jVl4jWaHh 6O8DmgrJM5xQfFLkEtz5Lwnd+tjfNSaHJlnmuOTr6ZFuaGwuiFBK4mZuJzM/jJRoqtS7 xKGYf0dDbBtVzIHJ4vgSltyvfYDQ8lgjoy1Vc4s4lUARSoy0dF0s3EtBqbFQbHWMd77E NW8CS9pSghAQ4sUjSiHbMo/heUkPRHVW7pW56QtAKLNRTdA08irqvajxiTyZ62ITafql w4MQ== X-Gm-Message-State: AIVw1102OZ/k0uK/wsoXlvV26TTblS+yBRCuvA8RK9JpcRfPyiVEp/zq ycz5iuBMMAhk2GtDh8s= X-Received: by 10.237.63.24 with SMTP id p24mr1771948qtf.81.1499799682361; Tue, 11 Jul 2017 12:01:22 -0700 (PDT) Received: from ?IPv6:2601:152:4400:dbdc:cd7e:c56c:755f:6862? ([2601:152:4400:dbdc:cd7e:c56c:755f:6862]) by smtp.gmail.com with ESMTPSA id g204sm73266qkb.27.2017.07.11.12.01.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 12:01:20 -0700 (PDT) To: tls@ietf.org References: <1499699684.2933.20.camel@redhat.com> <822604a1-61ca-a13c-9b6f-2cd7b57cadf9@cs.tcd.ie> From: Michael StJohns Message-ID: <43d4417f-875b-cb7a-52dc-cc7176f8705d@nthpermutation.com> Date: Tue, 11 Jul 2017 15:01:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <822604a1-61ca-a13c-9b6f-2cd7b57cadf9@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------F3222EE5E563696A84BF96C5" Content-Language: en-US Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 19:01:42 -0000 This is a multi-part message in MIME format. --------------F3222EE5E563696A84BF96C5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/10/2017 3:38 PM, Stephen Farrell wrote: > > On 10/07/17 17:42, Colm MacCárthaigh wrote: >> It's clear that there is a strong distaste here for the kind of MITM being >> talked about > It is not (only) "distaste," it is IETF policy as a result of > a significant debate on wiretapping. It is a policy some 17 years ago promulgated with respect to some very specific layer 9 threats and was pretty black and white. In 17 years we've gone from workstation class systems homed to application class servers to smart phones and the cloud. The SNI RFC was still three years out and strangely all the privacy stuff we're worried about now wasn't even part of the security considerations. TOR was still a DOD project. Basically, 2804 is woefully out of date with respect to the current state of the world. What this discussion has shown me is that we probably a) need to take another look at 2804 with a view to updating it with respect to the IETF's general views on persistent threats of all kinds, b) need to have whatever revision we make of 2804 provide for the concept that the owner of the data is not necessarily the sender/receiver of the data and has a vested interest in being able to control the flow of that information or protect themselves against persistent system threats (e.g. masked attackers) implicit in protecting against persistent privacy threats, and c) follow the general IETF model of not reading each and every word in any given RFC as if it were immutable truth handed down for all eternity and trust that we can - if we have the discussion - find a way forward through consensus building not bullying. Later, Mike > > S > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------F3222EE5E563696A84BF96C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/10/2017 3:38 PM, Stephen Farrell wrote:

On 10/07/17 17:42, Colm MacCárthaigh wrote:

It's clear that there is a strong distaste here for the kind of MITM being
talked about

It is not (only) "distaste," it is IETF policy as a result of
a significant debate on wiretapping.

It is a policy some 17 years ago promulgated with respect to some very specific layer 9 threats and was pretty black and white.   In 17 years we've gone from workstation class systems homed to application class servers to smart phones and the cloud.  The SNI RFC was still three years out and strangely all the privacy stuff we're worried about now wasn't even part of the security considerations.  TOR was still a DOD project.  Basically, 2804 is woefully out of date with respect to the current state of the world.

What this discussion has shown me is that we probably a) need to take another look at 2804 with a view to updating it with respect to the IETF's general views on persistent threats of all kinds, b) need to have whatever revision we make of 2804 provide for the concept that the owner of the data is not necessarily the sender/receiver of the data and has a vested interest in being able to control the flow of that information or protect themselves against persistent system threats (e.g. masked attackers) implicit in protecting against persistent privacy threats, and c) follow the general IETF model of not reading each and every word in any given RFC as if it were immutable truth handed down for all eternity and trust that we can - if we have the discussion - find a way forward through consensus building not bullying.

Later, Mike



S




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


--------------F3222EE5E563696A84BF96C5-- From nobody Tue Jul 11 12:11:21 2017 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 664BD12EC44 for ; Tue, 11 Jul 2017 12:11:19 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 epdzqFcN2yrX for ; Tue, 11 Jul 2017 12:11:17 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 7DFF0129B66 for ; Tue, 11 Jul 2017 12:11:17 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dV0Z1-0001dF-L9 for tls@ietf.org; Tue, 11 Jul 2017 21:11:16 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dV0Yz-0004Yk-EV for tls@ietf.org; Tue, 11 Jul 2017 15:11:14 -0400 Received: (qmail 908 invoked from network); 11 Jul 2017 19:11:11 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.115]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Jul 2017 19:11:11 -0000 To: tls@ietf.org References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> From: Christian Huitema Message-ID: Date: Tue, 11 Jul 2017 12:11:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.40) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJackVDEeh/s63C3hq8BP19aND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23X7am35/7EOtH5rXShxpFWeoI9GlgXFbGvhvB 71hlmrpgFT16N0zEjVhBqciCa6CjYOEkjsX7F8KmpUaZQHV+ST61TfxIvi8LwOTvVrRIhaC2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpIuW2VxLnS94njDgTNmyTXH6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGydJe2aRMEivIROM7I6TwJEDeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17cFawG5ASbLL3iaPgHmqzBy2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe93qlFit1PvkPF7Ua1AOSWcb0i13zjCiwPgdt77s k1WBMw== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 19:11:19 -0000 On 7/11/2017 6:11 AM, Ted Lemon wrote: > What the draft actually says is that you can install a fixed key on the= server rather than generating new keys every time, and then that fixed k= ey can also be installed on monitoring software. This is, I believe, th= e actual intended use of the proposal. > > It=E2=80=99s also true that you can just exfiltrate every key as it=E2=80= =99s generated, but that=E2=80=99s not what=E2=80=99s being proposed and = would not, I think, suit the needs of the operators who are making this p= roposal. > > I don=E2=80=99t see how you could mitigate against deliberate key exfil= tration. At some point you really are relying on the security of the en= dpoint. But being able to detect repeated keys is useful for preventing= pervasive monitoring: it requires the monitored either to have access to= the key generation stream in realtime, or to request the key for a parti= cular conversation. To paraphrase what Ted says using my own words, the use of static (EC)DH shares is an attack against the integrity of the TLS 1.3 protocol. I think this attack should be documented in the TLS spec, probably in Appendix E since the attack compromises security properties of the protocol, or maybe in Appendix C if we want to outline the implementation issues. Some text like: For various reasons, some implementations may be tempted to use static (EC) DH private key. Using such keys lowers the security guarantees of TLS 1.3. Adversaries that get access to the static (EC) DH private key can now get access to the content of the communication. Adversaries that acquire the key in real-time can compromise the confidentiality of the conversation. Adversaries that acquire the key later can use it to access the content of recorded sessions, thus breaking the forward secrecy promise of the protocol. TLS 1.3 clients should detect the use of static (EC)DH keys by corresponding servers, and should treat servers using such keys as compromised. Clients can perform this detection by comparing keys proposed by servers at different time, or by cooperating with other clients to compare the keys proposed to them by servers. -- Christian Huitema --=20 Christian Huitema From nobody Tue Jul 11 12:15:47 2017 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 0DC4E131774 for ; Tue, 11 Jul 2017 12:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vE8miPzN3LP for ; Tue, 11 Jul 2017 12:15:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FEC128C81 for ; Tue, 11 Jul 2017 12:15:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5A322BF27; Tue, 11 Jul 2017 20:15:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPOfVCAkIy6u; Tue, 11 Jul 2017 20:15:41 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 05623BF25; Tue, 11 Jul 2017 20:15:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499800541; bh=pJuKtjHeK9wn5C4mK1JDcOzEze3d7s8+4YFBZiVr+T8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wyGusmjRTIwSDmyvmg8q5nVLSZjCApcpKjKVbflCsnz2HHN5PNwv75HvdlH3oyNza PHYxx51yZkr6+L3Y9R/Xc0QDV4oyojpN60yUP0M8sjZ5xm89fxr7h7Fdc1yt7i4OA3 mNCNsulsyX3W7tC6V6SUbWcFQBSOzUKhgHylouNI= To: Steve Fenter , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 11 Jul 2017 20:15:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8uveDEt4iiGh85v9iB7Ux5xQ9LlS0N5mH" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 19:15:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8uveDEt4iiGh85v9iB7Ux5xQ9LlS0N5mH Content-Type: multipart/mixed; boundary="N75U3gG043bVDc3ndGaMjGquJu3DN2t4j"; protected-headers="v1" From: Stephen Farrell To: Steve Fenter , "tls@ietf.org" Message-ID: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: In-Reply-To: --N75U3gG043bVDc3ndGaMjGquJu3DN2t4j Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable To add to Ted's clarification requests: On 11/07/17 19:39, Steve Fenter wrote: > Network security monitoring is not just monitoring traffic that > results from communications with customers and partners. All it > takes is for one user to click on a phishing email and there is > malware inside the enterprise. Once this happens, TLS becomes the > enemy, because 30% of malware is TLS encrypted, and any TLS features > intended to thwart payload inspection work against the enterprise. I'd appreciate a citation for that 30% figure. And if you had one an estimate for how much malware does it's own obfuscation or home-grown crypto in addition or instead of using TLS. The reason to ask is that as soon as malware does that then you are back to analysis based on ciphertext only. From descriptions of advanced attack schemes, they do seem to do both when calling home or exfiltrating data. In which case I think your argument falls. > Malware does not always phone home out to the Internet on day 1 of > infection. =20 In what circumstance will malware phone home to a TLS server that is playing your wiretap game? That seems utterly illogical but maybe I'm missing a reason why someone's malware will use TLS to talk to a server that is controlled by the victim network as part of phoning home. Please clarify. S. --N75U3gG043bVDc3ndGaMjGquJu3DN2t4j-- --8uveDEt4iiGh85v9iB7Ux5xQ9LlS0N5mH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZSPcAAoJEC88hzaAX42ixBwH/1HsjuUzalb6eo1dYJ7kg92B xLEldYCRNkIDKcQ0+3gOPQYXJUkz+wyzZ/aUOEHkaAiuGD1QUJXHdRE9woMNil/K jyfRvwxmov+YdvUXX+7NXxYXq+8Yl98eIRutMUDMidHfP8lb27IzCWwr9oscmid7 I2dbsvQdpyjLZWMWFmMqrhq4xqaBWox2eyjPAs4vvVCczZ1xET4Bxlj2bK++hIKN 1S9kVBJMOH0LisqQWZO2j7lzk4lTHf+hsS4ymf8hXtPZDwjzF7KB1KjuuzcJh3p4 1lyD43roq6gcgHmqSWSadeFAOfWwVUxSEWg1PXxsx7ARazmbosqxs1ivNAdnl+w= =A6ai -----END PGP SIGNATURE----- --8uveDEt4iiGh85v9iB7Ux5xQ9LlS0N5mH-- From nobody Tue Jul 11 12:31:46 2017 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 51E821317B7 for ; Tue, 11 Jul 2017 12:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BP6Bkt2r2Foo for ; Tue, 11 Jul 2017 12:31:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3040613175A for ; Tue, 11 Jul 2017 12:31:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C03B6BF2E; Tue, 11 Jul 2017 20:31:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nST81AR5aM6n; Tue, 11 Jul 2017 20:31:33 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7232ABF27; Tue, 11 Jul 2017 20:31:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499801493; bh=uD/JFea/WUkuYHsS28qOlrp7+nglBi1WGtBy6y8j2Gw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=OsXVtpOOyiSFXVqRpT7FDxr6q4vl+T5566DEGYsEd34IQ7R9ryEKA7ewxDL/C9xNx Nr5hvanth+KKtsuexPMG7MMrP+3n1lkn3I+gupSbzlNp1msDSsdp1gytbYBjMjdewX /4MRiEK1s2J8Wbme4zPmMOf+jIQxVDksoUAD2Orc= To: Michael StJohns , tls@ietf.org References: <1499699684.2933.20.camel@redhat.com> <822604a1-61ca-a13c-9b6f-2cd7b57cadf9@cs.tcd.ie> <43d4417f-875b-cb7a-52dc-cc7176f8705d@nthpermutation.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <4c338ca7-dd57-e54e-54ca-b10ead50a993@cs.tcd.ie> Date: Tue, 11 Jul 2017 20:31:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <43d4417f-875b-cb7a-52dc-cc7176f8705d@nthpermutation.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7XqdMEJsF1eJsLnqUvMkjkD7qdiVV4xTB" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 19:31:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7XqdMEJsF1eJsLnqUvMkjkD7qdiVV4xTB Content-Type: multipart/mixed; boundary="E0U0mTATMpORq6KIXUVOarGWJurSOHGep"; protected-headers="v1" From: Stephen Farrell To: Michael StJohns , tls@ietf.org Message-ID: <4c338ca7-dd57-e54e-54ca-b10ead50a993@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <1499699684.2933.20.camel@redhat.com> <822604a1-61ca-a13c-9b6f-2cd7b57cadf9@cs.tcd.ie> <43d4417f-875b-cb7a-52dc-cc7176f8705d@nthpermutation.com> In-Reply-To: <43d4417f-875b-cb7a-52dc-cc7176f8705d@nthpermutation.com> --E0U0mTATMpORq6KIXUVOarGWJurSOHGep Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 11/07/17 20:01, Michael StJohns wrote: > Basically, 2804 is woefully out of date with respect to the current > state of the world. As I said before I do think the authors of this draft should indeed have said that it needs to obsolete 2804 as that is required for them to get the standards track status that they requested in the draft header. I also think that's going about things arseways - if 2804 needs to be updated, that should happen first. And for the current discussion, if the WG consensus is (as it ought be) to not adopt this draft based on 2804, then there is an IETF-level (and not TLS WG level!) question as to how to handle drafts that are inconsistent with 2804 - ISTM that 2804 only envisages those being sent to the ISE and not being IETF work items at all, otherwise the IETF would indeed be developing wiretapping specifications which is clearly and obviously not what 2804 says. And that matches my recollection of the debate at the time, but I've not gone back to the raven archive to check. (And 2804 pre-dating RFC streams won't help there I'm sure in terms of clarity.) So I'd also object to this WG attempting a supposed "compromise" of pursuing an informational RFC as a work item. Doing do would create an almost certainly huge but repeated debate on this aspect during such a WG process and during IETF last call. That specific question could maybe be figured out via an IESG note, and might not need a full-on 2804bis debate, not sure. No doubt such a debate would be a non-trivial undertaking, but if we could reach a new consensus on a 2804bis that strengthened Internet security and privacy, that would be a good thing. (I'm not sure if folks would really be up for that though.) S. --E0U0mTATMpORq6KIXUVOarGWJurSOHGep-- --7XqdMEJsF1eJsLnqUvMkjkD7qdiVV4xTB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZSeUAAoJEC88hzaAX42ixlAH/2LXVbVw0OG1mge7ViKuKGQR /o9bR9zMDOCbNqnkGPXi/xWBvkA3PnQH3lC7xO1oQh7Ina2ZZilPS4ifllujdXS3 QLBtE4yf7fLId8GYsxpsS4kPqum5CJUQJjowJhl0zXXvh7/0M4o+cpNw958fB5xQ R73aBPdZgIsJr4T4bz35I7XF0sUaBZiHr5XhCVMwH+agEMIREmH+z5VXWs0gEBGc cumMMWqilFn6Ymy2rzRoF2FBEk89tqTcQv27S9r9fXJHPQ6KfeiSPRun9X80Sk30 lfq9AifQB8SpC9/NJCKNMjhgjm2kiXZn/li5tgU8cF8k/rCtEMv9979jhso8S1E= =9J9x -----END PGP SIGNATURE----- --7XqdMEJsF1eJsLnqUvMkjkD7qdiVV4xTB-- From nobody Tue Jul 11 12:41:04 2017 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 4A73512EC29 for ; Tue, 11 Jul 2017 12:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx_lVQdSvJeu for ; Tue, 11 Jul 2017 12:41:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA7112EC0B for ; Tue, 11 Jul 2017 12:41:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1225FBE38; Tue, 11 Jul 2017 20:40:59 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhd8Wt8VvcdP; Tue, 11 Jul 2017 20:40:57 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B6737BE2F; Tue, 11 Jul 2017 20:40:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499802057; bh=gB7Bw7PVDvO29XzO370DVexwSQBv+bUAt2TRHf7zBVE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HmjtqybD2rviksyasweoIlROVoxSZbpcLqVvYTuLKrIexySYiEPU3tAq6zk6YG+xa 7uMpU7QwyLB4sDrdOeCuJbqhs0zC/4nvAZ6FvIfpgKKOsaXz2bjtcsveZxjmZYM1w1 O/m1mTJUdoa6xUFaOKypOE0JnnLJWo5tI/wi3dfs= To: Christian Huitema , tls@ietf.org References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> Date: Tue, 11 Jul 2017 20:40:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L77iVtv85SjDtxD4BAFmiOfgnSN2xTbdg" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 19:41:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L77iVtv85SjDtxD4BAFmiOfgnSN2xTbdg Content-Type: multipart/mixed; boundary="XNCca266slhXed5hFXI0USiOsBCe8iN8Q"; protected-headers="v1" From: Stephen Farrell To: Christian Huitema , tls@ietf.org Message-ID: <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> In-Reply-To: --XNCca266slhXed5hFXI0USiOsBCe8iN8Q Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 11/07/17 20:11, Christian Huitema wrote: >=20 > For various reasons, some implementations may be tempted to use static > (EC) DH private key. Using such keys lowers the security guarantees of > TLS 1.3. Adversaries that get access to the static (EC) DH private key > can now get access to the content of the communication. Adversaries tha= t > acquire the key in real-time can compromise the confidentiality of the > conversation. Adversaries that acquire the key later can use it to > access the content of recorded sessions, thus breaking the forward > secrecy promise of the protocol. TLS 1.3 clients should detect the use > of static (EC)DH keys by corresponding servers, and should treat server= s > using such keys as compromised. Clients can perform this detection by > comparing keys proposed by servers at different time, or by cooperating= > with other clients to compare the keys proposed to them by servers. I generally like the idea of such text but I'm not at all sure client detection is really feasible in the general case. It'd seem possible for a server to hold a rather long list of re-used static DH values and unlikely for normal clients to detect those. And it also seems like an arms race too, e.g. if a special zmap-like survey was used to detect this kind of bad crypto. Still worth testing for no doubt, (it'd make for a nice academic publication) but I'm not sure detection could be sufficiently probable that we could make the statement above. Speaking of text changes though, if this wiretapping scheme were to be adopted in any sense, there would be a load of tweaks to text in tls1.3 needed as a result - starting with the abstract to -21 for example as we could no longer say that TLS is "designed to prevent eavesdropping" without a highly embarrassing qualifier. (Hence my request to not have this discussion until after DTLS1.3 is done - and chairs if you're reading this please do reconsider.) Sigh, S. --XNCca266slhXed5hFXI0USiOsBCe8iN8Q-- --L77iVtv85SjDtxD4BAFmiOfgnSN2xTbdg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZSnJAAoJEC88hzaAX42iG1MIAK+RUm3yT+38f/4xtul4XWDg cRMc+41QqSFDVmqwr4paKDpuKe95Hy7YVtg+crspq0DMsb5nCQlkXhfAvFiD1Lb8 6YoNB+Q4uG/JKccuhnkJqCNptiASUN4ZRDUwFke4cb763nBoF2gp6tJ60wPEIV/X tfv7EQPs90aDxBu2jLxBcAj9mDsph0tDg2HjXEcP8sUzbCpK+pCdFPhpnLBXFBQN jMsOkTpaJj61Y4gUH8EnlT2O4yc9f4enqisOfRZzP++d8p9O3VYglVtIA8IPFhxF gNZxqpd+Qi9oYZHjdl89eQSfd/3U1RpGlExBSASdeVP2JrjgvEItPsKtWXQDBAQ= =bWYi -----END PGP SIGNATURE----- --L77iVtv85SjDtxD4BAFmiOfgnSN2xTbdg-- From nobody Tue Jul 11 12:48:33 2017 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 B33EE131788 for ; Tue, 11 Jul 2017 12:48:30 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 v8U_2VFW08n7 for ; Tue, 11 Jul 2017 12:48:29 -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 37991126B6D for ; Tue, 11 Jul 2017 12:48:29 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id b40so2173291qtb.2 for ; Tue, 11 Jul 2017 12:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=en6/KtAQ+lanJCksOtcs4urTkubZN46FjFqG/yPK9oE=; b=g/mJeBGPpv2FVBuk2m3HVGD2hxzUteotDslqoV/n2qNpjG/n1B9IwXBPs0sXKF6Ztf 6mq02sb+9pUYWe/pMz7iQqSN3ii9mfmK1dDxctTXyvBO2KLN/jaDTFYGwFhRw2naNpj0 xgAt3fYe2DIN4asBahYcwm7HWO3QG0MNY8XkAkLfYLZdf1B3bHNtfbKQT0DwcQ6PkiDK Si9O/Iz1M1euResURxZpX/8wXwbrtxq5X/lJ+uMfXP8Pg1ycv3HT552zU8aiM765q0nR bbS+nUuXIrXOcC/uXAK+kYEy1jC5SwIPY1gMehUBUVN7oHCePLW5Efy3q4Co1j0JRtnU 7itw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=en6/KtAQ+lanJCksOtcs4urTkubZN46FjFqG/yPK9oE=; b=EI4UVlAqYDZD4N+dx8BwMrD7Sn3x6+zM8pv4k3yPUL7V9+HSgEcB0atF/e+RyOdBGI 2iFbhjoja8JLGAz6Q9r5Ic2d7iTONdZ432mXtn+7xbl0f6uVXktiwpS/TO+bBDpCeEfm EqamJukCz86qTYDL2aSkozsMgy1wz8tcmUIXDGIMY7I5VnfF71dubptVBYELpYOqdHzX xS3S9AkhJF5Wl5xvzvsn5ofadrWmFnsG4A6Y1vcq4qUDBfWikL2TbIe1EPg5IDmcZKDk TacauGDniYGNbXp2CuLl29Ficd2AjRQ4h9WTlvExZcMB6feeyBIsNcD6dtuvk8S+7diy U5QA== X-Gm-Message-State: AIVw110+O/jesLAToHN2YMJdr5pknHFshl+BExEb7G+FectxI9v/Rjmr JfdXOh6SnFAKJuCRNntYWw== X-Received: by 10.200.40.150 with SMTP id i22mr1989313qti.59.1499802508190; Tue, 11 Jul 2017 12:48:28 -0700 (PDT) Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r191sm165171qke.22.2017.07.11.12.48.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 12:48:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A5304i) In-Reply-To: <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> Date: Tue, 11 Jul 2017 15:48:26 -0400 Cc: Christian Huitema , tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 19:48:31 -0000 On Jul 11, 2017, at 3:40 PM, Stephen Farrell wro= te: > It'd seem possible for a server to hold a rather long > list of re-used static DH values and unlikely for normal > clients to detect those. Bearing in mind that the current proposal is intended to perpetuate a well-e= stablished use model so as to avoid having to re-tool, I don=E2=80=99t think= this is a real concern. In practice I expect that the number of keys used i= n such a system will be small because the operational burden of making it la= rge will be enough to motivate re-tooling.=20 So in practice I would expect a client to be able to cache enough keys to no= tice this attack, if the user were motivated, or the client vendor considere= d this to be a credible threat worth addressing.=20= From nobody Tue Jul 11 12:59:47 2017 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 881DC131788 for ; Tue, 11 Jul 2017 12:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HTYwA43cDQL for ; Tue, 11 Jul 2017 12:59:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F6612EC5D for ; Tue, 11 Jul 2017 12:59:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E64CFBF22; Tue, 11 Jul 2017 20:59:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H12srt3x8e-v; Tue, 11 Jul 2017 20:59:42 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C5D1BF16; Tue, 11 Jul 2017 20:59:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499803182; bh=oHNo81C6PzelJW5Pn7/BWvIaE2AmvkuRj/bUx1m3lL0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OpM1FGkD9A/WHKtEzeObGZiwWSju0EpxcAJmkVVzVaMuvoGdoxvSWliPCFxOXFvtn AcnNrPbYb2sii/WeD50DF6ou0bqqT712y2G1yfckd6ANLGKP85HZ0XjSdN9M1LyHsx efpn2Zxr2coNlJHT2nHxj8P4PtQ6aN9YhmHH8KJE= To: Ted Lemon Cc: Christian Huitema , tls@ietf.org References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 11 Jul 2017 20:59:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uKoDTAJimK8ksXBgnCiD9ShG7c8tedJXV" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 19:59:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uKoDTAJimK8ksXBgnCiD9ShG7c8tedJXV Content-Type: multipart/mixed; boundary="Lxoie4h2KI9TjlTJ3DKbcJG212VqTTRVW"; protected-headers="v1" From: Stephen Farrell To: Ted Lemon Cc: Christian Huitema , tls@ietf.org Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> In-Reply-To: --Lxoie4h2KI9TjlTJ3DKbcJG212VqTTRVW Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 11/07/17 20:48, Ted Lemon wrote: > On Jul 11, 2017, at 3:40 PM, Stephen Farrell > wrote: >> It'd seem possible for a server to hold a rather long list of >> re-used static DH values and unlikely for normal clients to detect >> those. >=20 > Bearing in mind that the current proposal is intended to perpetuate a > well-established use model so as to avoid having to re-tool, I don=E2=80= =99t > think this is a real concern. In practice I expect that the number of > keys used in such a system will be small because the operational > burden of making it large will be enough to motivate re-tooling. >=20 > So in practice I would expect a client to be able to cache enough > keys to notice this attack, if the user were motivated, or the client > vendor considered this to be a credible threat worth addressing. I can't see that happening. Once the first example.com is called out for using this, others will make their list longer or take other approaches, e.g. use one exfiltrated private value as a seed for others via some proprietary mechanism. Actually, that calls out another reason to not standardise or further develop this - any such standard is either undetectable or leads to deployments deviating from the standard to become less detectable - both undesirable outcomes. That latter case also destroys the "but we should scrutinise it" argument IMO as the "it" will change to be undetectable and not the "it" that was ostensibly scrutinised. S. >=20 --Lxoie4h2KI9TjlTJ3DKbcJG212VqTTRVW-- --uKoDTAJimK8ksXBgnCiD9ShG7c8tedJXV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZS4uAAoJEC88hzaAX42iHrsH/Rxh8xgM1Z6NAIQKl+2jq4IA rmyo6nHrMfjy56AnqCgr/BZ2ItRJpZXHa9nVtSaNBHd3EckAqIHN0Dx93vhOhCZ8 bcFNFAfntp3WllvlqWhEOFBt+T+/W30Fr9a9CeCg1Bz7qoafoBpgVsW7LWc5G/l+ 4v01AUQK4xTQAO/0i/p2MEp7OqXnJONObt+YQ1LTj/DXbLwh2Qu/WfH81TNQfk1t aI1jpfUchjUH3726Tfhs5krhYAp/AHKE8gXHdmhD4XbbAfC5aJskq1NolOgFRfNI Q4ua7BF+MtByoiKHBpnGmyOk4LCMZDXqR+e8fxjgrwb8txczsvOaHZvmMrXppa4= =WI9Z -----END PGP SIGNATURE----- --uKoDTAJimK8ksXBgnCiD9ShG7c8tedJXV-- From nobody Tue Jul 11 13:04:01 2017 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 D90671317BC for ; Tue, 11 Jul 2017 13:03:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6QNf6of5Sgb8 for ; Tue, 11 Jul 2017 13:03:57 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 09CD5126DEE for ; Tue, 11 Jul 2017 13:03:56 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id 32so2536223qtv.1 for ; Tue, 11 Jul 2017 13:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=j7uwddLdn1QxlFBh7P4IuMKCDW/m+HSNBjNYrJZbhl4=; b=YWOj6cVl4aHtbvRzKjic76JV0RHCr+wHTmf2/89p5KC1wFKD6/jaWjWbqwVFQLIvJY rX2xMo7OeZ7ph9dPa3GzW2bCw9WMUu5weAgvHRdqypE2WDcso/KPe8ZTdxhH8NH2lbaS +LaEPHFE5lExujwTqg/CFUeY6DLdrqTdg2zPqjIVW/5d6kEX1te5eg+s9HXlPS5URSbE hARC/hGbOSHg2d62X96q1f1ZLyIkaU+rB5z5d+YdFRb33m2xS6NGleMUCrFf0DjFzcVW yohqixP2ubLGnEzrA+S90GX1FQyIRLMEDRLmAIVWjUI47/DQ0/DplM+61w963+WnN/ob aVPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=j7uwddLdn1QxlFBh7P4IuMKCDW/m+HSNBjNYrJZbhl4=; b=qtSxcA/Czva+Kyk25FzHVs7Hkl/qQII/UKwj7Y0w8ui1EXZkx2JbjA2dUWk17j0ha7 qx6u2b1nZQF0zKz81ReIFvBilJRCJioPMODgNRT0PBOdtLkfqVmKr1e7sULmtRx9Gnfh TNPEjmFc1b//9UtskYIgGBRPjBaftzjkUGrxyyRq4px+a8bx9VeWrUZbl8sArwQFL/Eo bndKK9ZeZRLeab0Tb2u9b3JmZrZTsK72NgxC26xWES4FxmUPxOllXX/BwkzwpSB6l33l jOCEsyzmGgHxYJa38tItN6MGV5gqbuSSyLiybyAAHQGBeeUfhoFhktsTRsjWKoTqcrIM FvGg== X-Gm-Message-State: AIVw112Ipf9Yd5gJBvZtze0Zka3rKyzIp0KroEkqtTXiv2k9TBzf03at 5alEEa+sDZiOiDFGnljtXA== X-Received: by 10.200.49.18 with SMTP id g18mr2341190qtb.118.1499803435946; Tue, 11 Jul 2017 13:03:55 -0700 (PDT) Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id q185sm178022qkb.45.2017.07.11.13.03.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 13:03:55 -0700 (PDT) From: Ted Lemon Message-Id: <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0E178CAD-D65A-4FAC-A9ED-B624FA8D5601" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Jul 2017 16:03:53 -0400 In-Reply-To: Cc: Christian Huitema , tls@ietf.org To: Stephen Farrell References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 20:03:59 -0000 --Apple-Mail=_0E178CAD-D65A-4FAC-A9ED-B624FA8D5601 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 11, 2017, at 3:59 PM, Stephen Farrell = wrote: > I can't see that happening. Once the first example.com = is called > out for using this, others will make their list longer or take > other approaches, e.g. use one exfiltrated private value as a > seed for others via some proprietary mechanism. Ah, you mean the first time the attack happens in the wild. Sure, I = can see that, but that gains the attacker no real advantage over just = exfiltrating all the keys. Once you make the number of keys large = enough to be hard to detect, you have a really big key management = problem. Might as well just make it a logging problem. So we've = forced them to do the thing that makes pervasive monitoring hard and = point monitoring easy. I call that a win. Note that if we took a distributed approach to discovering key reuse, it = would be almost impossible for any large site to conceal. > Actually, that calls out another reason to not standardise or > further develop this - any such standard is either undetectable > or leads to deployments deviating from the standard to become less > detectable - both undesirable outcomes. That latter case also > destroys the "but we should scrutinise it" argument IMO as the > "it" will change to be undetectable and not the "it" that was > ostensibly scrutinised. I'm not arguing in favor of standardizing this. I think it's an = attack, and there is a countermeasure which is worth documenting, and = possibly worth deploying. If the working group does a CFA on the = draft, I will argue against adoption. I like Christian's = approach=E2=80=94document this in an appendix, _as an attack_. --Apple-Mail=_0E178CAD-D65A-4FAC-A9ED-B624FA8D5601 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 11, 2017, at 3:59 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
I can't see that happening. Once the = first example.com is called
out for using this, others will make their list = longer or take
other approaches, e.g. use one = exfiltrated private value as a
seed for others via = some proprietary mechanism.

Ah, you mean the first time the attack = happens in the wild.   Sure, I can see that, but that gains the = attacker no real advantage over just exfiltrating all the keys.   = Once you make the number of keys large enough to be hard to detect, you = have a really big key management problem.   Might as well just make = it a logging problem.   So we've forced them to do the thing that = makes pervasive monitoring hard and point monitoring easy.   I call = that a win.

Note= that if we took a distributed approach to discovering key reuse, it = would be almost impossible for any large site to conceal.

Actually, that calls out another reason to not standardise = or
further develop this - = any such standard is either undetectable
or leads to deployments deviating from the standard to become = less
detectable - both = undesirable outcomes. That latter case also
destroys the "but we = should scrutinise it" argument IMO as the
"it" will change to be undetectable and not the "it" that = was
ostensibly = scrutinised.

I'm = not arguing in favor of standardizing this.   I think it's an = attack, and there is a countermeasure which is worth documenting, and = possibly worth deploying.   If the working group does a CFA on the = draft, I will argue against adoption.   I like Christian's = approach=E2=80=94document this in an appendix, _as an attack_.


= --Apple-Mail=_0E178CAD-D65A-4FAC-A9ED-B624FA8D5601-- From nobody Tue Jul 11 13:31:31 2017 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 287BE1317DA for ; Tue, 11 Jul 2017 13:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Snc7M70T897O for ; Tue, 11 Jul 2017 13:31:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123A41317D5 for ; Tue, 11 Jul 2017 13:31:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9560CBED6; Tue, 11 Jul 2017 21:31:25 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI2udIc3NAjl; Tue, 11 Jul 2017 21:31:24 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F787BECA; Tue, 11 Jul 2017 21:31:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499805084; bh=V4Mf4H4xxNbSjC/R8dfkga468KxoeE10f82WOYvh5Ro=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KKTuwoeCk2fyrBlNs0RqZnSOUYGQ1MszT7i+RgoIkHEga/bvdbrPl2AswPPyhaRSc Y8yyEVNmxO1z1uItqbICyAsCNii4574Qiouqfxwj0EcUIX2kzJce0St0N1rUZopEu2 TZcQCXQ6lJyqCREZNlLI1XEALLz7PRCEqCQQtNWQ= To: Ted Lemon Cc: Christian Huitema , tls@ietf.org References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 11 Jul 2017 21:31:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JDLXUQKVJFqU96JQkoEXRla2tVJmWEjVW" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 20:31:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JDLXUQKVJFqU96JQkoEXRla2tVJmWEjVW Content-Type: multipart/mixed; boundary="6IgFhwsvxSvqibmLLoDes8gBeNHsI5RNk"; protected-headers="v1" From: Stephen Farrell To: Ted Lemon Cc: Christian Huitema , tls@ietf.org Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> In-Reply-To: <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> --6IgFhwsvxSvqibmLLoDes8gBeNHsI5RNk Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 11/07/17 21:03, Ted Lemon wrote: > Ah, you mean the first time the attack happens in the wild. =20 Well, the first time it's detected in the wild. > Sure, I > can see that, but that gains the attacker no real advantage over just > exfiltrating all the keys. =20 I agree. I think one can actually generalise here and argue that there's no value in new standards for bad crypto, only in standards for current BCP crypto. (On the basis that if it's crap crypto there's too much damage potential in the homogeneous environment created by a successful standard.) > Once you make the number of keys large > enough to be hard to detect, you have a really big key management > problem. =20 Not necessarily. I'd bet folks would invent proprietary ways of avoiding detection, that deviate from the "standard" and that perhaps make crypto worse all around. Say by deriving secrets from some function f(exfiltrated-secret, time, count) for a small counter or some such and having the decryptor of the wiretapped packets hunt a bit for the right key. > Might as well just make it a logging problem. So we've > forced them to do the thing that makes pervasive monitoring hard and > point monitoring easy. I call that a win. >=20 > Note that if we took a distributed approach to discovering key reuse, > it would be almost impossible for any large site to conceal. I would bet there are ways to hide from that. Cheers, S. PS: There are also genuine performance reasons why the same DH public might be re-used in some cases, so there would be false positives in a survey to consider as well. --6IgFhwsvxSvqibmLLoDes8gBeNHsI5RNk-- --JDLXUQKVJFqU96JQkoEXRla2tVJmWEjVW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZTWbAAoJEC88hzaAX42ilvQH/3ibTK6t5nYYB9geFWb2vuBu ZgPxBIS1kHPp/dnyZPdhNRM79dG3YsgWVT/7LmSCcEEkRSrUviMGFOq5gEtzV5zB /ZOo1Zko7Ep4XgibSFU/2YseH06GqhF6vAGC6j8eIB6vHxGhoB+z+vDqLb+vXyKe wCkL9ERrjmxN9e9krvnGoVEaQvtTo6rxfoLMT0PcF0yXxmLbjGpUjgD+fb8kr/4f EHzjzVdlIftyKrO4vHMVSscyxXisBohyUL8k2gilKtgeTiqzPnX3H1r+z4+pp9Bc +k4g2BgpdwsLqose9MvwwHGj29qOqUkgtcPESqVUk7ygLaFRbeXwuAHIxow2l5g= =U0Qg -----END PGP SIGNATURE----- --JDLXUQKVJFqU96JQkoEXRla2tVJmWEjVW-- From nobody Tue Jul 11 13:39:30 2017 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 DBE9D1317D6 for ; Tue, 11 Jul 2017 13:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 4bO6FSRGDCb5 for ; Tue, 11 Jul 2017 13:39:26 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 8722D131795 for ; Tue, 11 Jul 2017 13:39:26 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6BKbfO0015097; Tue, 11 Jul 2017 21:39:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=LaumMie2jpsgJJ+5jYMTejixP4Wrgm4eab1neLhe0bQ=; b=pDmb5VfLjBIztG5KKmV9+vvbgPrFaW2C1ev6+cyOOyaz8tSoISEe8u6LZoeGhIFIZ0yS 7GPX1/m76JMoSEieSfN4wNVhUi0fXfpG/mpd0Pty+0bxLrf0b+er1LQ1KrsMwRNksoJU tJ5Ih2PC7ZGnscKqKTzArSz21bRy/smXXD+HJU64Ifu+wumssjkeKedcg2J69yYuvzQg HmwioFu9BxNYxiRLCXs/MonG0Bca8ukDqyEd+itu4BquSkuV0Y/evSuiGiwCDs1eQC2l oDGvkY5oRl1qBEPs8illDTejs7DPH37BEzlEakW9MZo5Rdam2Wv/mMXuagJWO7rd2hAM oQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2bn0p3he9x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Jul 2017 21:39:25 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6BKZw1j016440; Tue, 11 Jul 2017 16:39:24 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2bn0p212a8-1; Tue, 11 Jul 2017 16:39:24 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 0AB2920064; Tue, 11 Jul 2017 14:39:23 -0600 (MDT) To: Sean Turner , "" References: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com> From: Benjamin Kaduk Message-ID: Date: Tue, 11 Jul 2017 15:39:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com> Content-Type: multipart/alternative; boundary="------------BA90ABB30F3B8FC510F5228B" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-11_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707110330 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-11_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707110330 Archived-At: Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 20:39:29 -0000 This is a multi-part message in MIME format. --------------BA90ABB30F3B8FC510F5228B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/03/2017 10:53 PM, Sean Turner wrote: > All, > > This is the 2nd working group last call (WGLC) announcement for draft-ietf-tls-tls13 to run through July 18th. This time the WGLC is for version -21 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/). Note that this WGLC ends before the Wednesday TLS WG session @ IETF 99. > > Also note that this WGLC is a targeted WGLC that only address changes introduced since the 1st WGLC on version -18, i.e., changes introduced in versions -19 through -21. Note that the editor has kindly included a change log in s1.2 and the datatracker can also produce diffs (for some reason it’s not working for me right now). In general, we are considering all other material to have WG consensus, so only critical issues should be raised about that material at this time. > Duly limiting myself to reviewing just the changes from -18 to -21, I do still have some comments. The main issue is one that I have raised previously but does not seem to have been resolved by the group, namely, that I think we should have a MUST-level requirement for some stronger anti-replay scheme than the freshness checks of section 8.3. I do not think that we need to mandate specifically the single-use tickets of section 8.1 or the ClientHello recording scheme of section 8.2, and can leave freedom for implementations to choose alternate schemes, but do think that we will be on the wrong side of the "we're building a security protocol"/"we're building an easy-to-implement protocol" divide with the present SHOULD-level indication. Another question I also relates to 0-RTT, specifically with the freshness checks and the case where the computed expected_arrival_time is in outside "the window" by virtue of being in the future. (See the Note: at the end of section 8.2.) (The case where the expected_arrival_time is in the past can clearly be treated as "this is a stale request" and the current text about aborting with "illegal_parameter" or rejecting 0-RTT but accepting the PSK is acceptable, even if it doesn't give guidance as to what might cause someone to pick one behavior or the other.) I am wondering whether we should consider this to be a potential attack and abort the connection. I concede that there are likely to be cases where this situation occurs incidentally, for clients with extremely fast-running clocks, and potential timezone/suspend-resume weirdness. But there is also the potential for a client that deliberately lies about its ticket age and intends to replay the wire messages when the age becomes in window, or an attacker that records the messages and knows that the client's clock is too fast, or other cases. (A client that deliberately does this could of course just send the same application data later as well.) If the time is only a few seconds out of the window, then delaying a response until it is in the window and only then entering it into the single-use cache might be reasonable, but if the time is very far in the future, do we really want to try to succeed in that case? Or perhaps we should just make the time window for 0-RTT acceptance half-infinite and not bother rejecting things that claim to be in the future; that probably has some robustness arguments in its favor. It looks like we no longer do anything to obsolete/reserve/similar the HashAlgorithm and SignatureAlgorithm registries; was that just an editorial mixup or an intended change? We removed the API guidance for separate APIs for read/writing early data versus regular data, which I believe had consensus. But I thought we were going to say something carefully worded about having an API to determine whether the handshake has completed (or client Finished has been validated, or ...), and it looks like this is buried at the end of E.5(.0), with the string "API" not appearing. It might be useful to make this a little more prominent/discoverable, whether by subsection heading or otherwise. I also found some issues that I believe to be purely editorial, for which I will submit a pull request. I will probably try to make another full review pass over the entire document (mostly looking for editorial things), but I have until the end of IETF LC for that, right? ;) -Ben --------------BA90ABB30F3B8FC510F5228B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/03/2017 10:53 PM, Sean Turner wrote:
All,

This is the 2nd working group last call (WGLC) announcement for draft-ietf-tls-tls13 to run through July 18th.  This time the WGLC is for version -21 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/).  Note that this WGLC ends before the Wednesday TLS WG session @ IETF 99.

Also note that this WGLC is a targeted WGLC that only address changes introduced since the 1st WGLC on version -18, i.e., changes introduced in versions -19 through -21.  Note that the editor has kindly included a change log in s1.2 and the datatracker can also produce diffs (for some reason it’s not working for me right now).  In general, we are considering all other material to have WG consensus, so only critical issues should be raised about that material at this time.

Duly limiting myself to reviewing just the changes from -18 to -21, I do still have some comments.

The main issue is one that I have raised previously but does not seem to have been resolved by the group, namely, that I think we should have a MUST-level requirement for some stronger anti-replay scheme than the freshness checks of section 8.3.  I do not think that we need to mandate specifically the single-use tickets of section 8.1 or the ClientHello recording scheme of section 8.2, and can leave freedom for implementations to choose alternate schemes, but do think that we will be on the wrong side of the "we're building a security protocol"/"we're building an easy-to-implement protocol" divide with the present SHOULD-level indication.

Another question I also relates to 0-RTT, specifically with the freshness checks and the case where the computed expected_arrival_time is in outside "the window" by virtue of being in the future. (See the Note: at the end of section 8.2.) (The case where the expected_arrival_time is in the past can clearly be treated as "this is a stale request" and the current text about aborting with "illegal_parameter" or rejecting 0-RTT but accepting the PSK is acceptable, even if it doesn't give guidance as to what might cause someone to pick one behavior or the other.)  I am wondering whether we should consider this to be a potential attack and abort the connection.  I concede that there are likely to be cases where this
situation occurs incidentally, for clients with extremely fast-running clocks, and potential timezone/suspend-resume weirdness.  But there is also the potential for a client that deliberately lies about its ticket age and intends to replay the wire messages when the age becomes in window, or an attacker that records the messages and knows that the client's clock is too fast, or other cases.  (A client that deliberately does this could of course just send the same application data later as well.)  If the time is only a few seconds out of the window, then delaying a response until it is in the window and only then entering it into the single-use cache might be reasonable, but if the time is very far in the future, do we really want to try to succeed in that case?  Or perhaps we should just make the time window for 0-RTT acceptance half-infinite and not bother rejecting things that claim to be in the future; that probably has some robustness arguments in its favor.

It looks like we no longer do anything to obsolete/reserve/similar the HashAlgorithm and SignatureAlgorithm registries; was that just an editorial mixup or an intended change?

We removed the API guidance for separate APIs for read/writing early data versus regular data, which I believe had consensus.  But I thought we were going to say something carefully worded about having an API to determine whether the handshake has completed (or client Finished has been validated, or ...), and it looks like this is buried at the end of E.5(.0), with the string "API" not appearing.  It might be useful to make this a little more prominent/discoverable, whether by subsection heading or otherwise.

I also found some issues that I believe to be purely editorial, for which I will submit a pull request.

I will probably try to make another full review pass over the entire document (mostly looking for editorial things), but I have until the end of IETF LC for that, right? ;)

-Ben
--------------BA90ABB30F3B8FC510F5228B-- From nobody Tue Jul 11 13:51:33 2017 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 47182127869 for ; Tue, 11 Jul 2017 13:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=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 t9onu5p44LnP for ; Tue, 11 Jul 2017 13:51:30 -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 1CBC0127444 for ; Tue, 11 Jul 2017 13:51:30 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id x125so1752750ywa.0 for ; Tue, 11 Jul 2017 13:51:30 -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=inZXNr5gKhI7N3uWskr2efLW7MYVLlwZa4B6wDUqXfw=; b=amSJX1fG82FRJyglwaadTWrkeBT7J/PlXFqxfYrYe6+oRWvcUzvJsi3SK5yHxydAbf YNVxcWZwnk8N8wtj+MrLLDAatcsGcC58VC9TW0LYc4eWYIdQL+RyWhsDNayKIXtL9kxy JdtXwMG0kzE2h4mWWKyI1HC4fJSBYrtm0faG92PWaQv5umHGcLlTgkcerTcNiq0KslAW BBMwzfvZSMk+TbQ/EAiBAydu3Cx/XvIngyeTBopNqOFx8kgOP9q//UKgTUAEa8EhS5rK vP/2f9YwnCJl2lDzBvDxje77YEFf4V+W4QnzOiBoXQrvPf6JO3eFkYEtZxYh45uLx6bU cysg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=inZXNr5gKhI7N3uWskr2efLW7MYVLlwZa4B6wDUqXfw=; b=CzkqHRSexL/rEoggR0QJa9DulUyo2AnJw4rQyFdtsLobRRX955hiOew2KeUEjz4uJb oyOeJ/F+Qjb6F4YaWe6checo8KCRKX6cbX1bPrUeHQBUy7x7GBH+kb3gg5xRFlU46hBI XJP4jiSrLhBFLs9PkeZu4nlmHl7Uv4V0wIdRe2vFcbuLKR0TTf9ijl3YkQiysXXWbsgG o7ml6lQswN7XU600QR0p5iPrcKxX4G+NO0xHmG5Ndv9TgVRSWM74bi5Zm09g8BP/Kgpy 6WJE6ZhwK84sm0QtyPDblpkqDHzLVeovI1OA8Negb45elRjokOMv3KXbxeAK29cTiNmO k7uA== X-Gm-Message-State: AIVw110eyFe7cUiWiIoDVEyOh0JMcQp4t9e+8IUMw+iNJOXAP8ZeCmSD /oqHkiiv5vQE4KjZ9cN+76lZjmU1Erwf X-Received: by 10.129.78.80 with SMTP id c77mr8086ywb.289.1499806289357; Tue, 11 Jul 2017 13:51:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Tue, 11 Jul 2017 13:50:48 -0700 (PDT) In-Reply-To: References: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com> From: Eric Rescorla Date: Tue, 11 Jul 2017 13:50:48 -0700 Message-ID: To: Benjamin Kaduk Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary="001a114dae1a1c08c3055410dd70" Archived-At: Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 20:51:32 -0000 --001a114dae1a1c08c3055410dd70 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk wrote: > > > Another question I also relates to 0-RTT, specifically with the freshness > checks and the case where the computed expected_arrival_time is in outside > "the window" by virtue of being in the future. (See the Note: at the end of > section 8.2.) (The case where the expected_arrival_time is in the past can > clearly be treated as "this is a stale request" and the current text about > aborting with "illegal_parameter" or rejecting 0-RTT but accepting the PSK > is acceptable, even if it doesn't give guidance as to what might cause > someone to pick one behavior or the other.) I am wondering whether we > should consider this to be a potential attack and abort the connection. I > concede that there are likely to be cases where this > situation occurs incidentally, for clients with extremely fast-running > clocks, and potential timezone/suspend-resume weirdness. But there is also > the potential for a client that deliberately lies about its ticket age and > intends to replay the wire messages when the age becomes in window, or an > attacker that records the messages and knows that the client's clock is too > fast, or other cases. (A client that deliberately does this could of > course just send the same application data later as well.) If the time is > only a few seconds out of the window, then delaying a response until it is > in the window and only then entering it into the single-use cache might be > reasonable, but if the time is very far in the future, do we really want to > try to succeed in that case? > If the time is very far in the future, the text is supposed to tell you to fall back to 1-RTT... It looks like we no longer do anything to obsolete/reserve/similar the > HashAlgorithm and SignatureAlgorithm registries; was that just an editorial > mixup or an intended change? > https://tlswg.github.io/draft-ietf-tls-iana-registry-updates/#orphaned-registries We removed the API guidance for separate APIs for read/writing early data > versus regular data, which I believe had consensus. But I thought we were > going to say something carefully worded about having an API to determine > whether the handshake has completed (or client Finished has been validated, > or ...), and it looks like this is buried at the end of E.5(.0), with the > string "API" not appearing. It might be useful to make this a little more > prominent/discoverable, whether by subsection heading or otherwise. > Suggestions welcome for where this would be better.... -Ekr > > I also found some issues that I believe to be purely editorial, for which > I will submit a pull request. > > I will probably try to make another full review pass over the entire > document (mostly looking for editorial things), but I have until the end of > IETF LC for that, right? ;) > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114dae1a1c08c3055410dd70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:

Another question I also relates to 0-RTT, specifically with the freshness checks and the case where the computed expected_arrival_time is in outside "the window" by virtue of= being in the future. (See the Note: at the end of section 8.2.) (The case where the expected_arrival_time is in the past can clearly be treated as "this is a stale request" and the current text abo= ut aborting with "illegal_parameter" or rejecting 0-RTT but acce= pting the PSK is acceptable, even if it doesn't give guidance as to what might cause someone to pick one behavior or the other.)=C2=A0 I am wondering whether we should consider this to be a potential attack and abort the connection.=C2=A0 I concede that there are likely to be cases where this
situation occurs incidentally, for clients with extremely fast-running clocks, and potential timezone/suspend-resume weirdness.=C2=A0 But there is also the potential for a client that deliberately lies about its ticket age and intends to replay the wire messages when the age becomes in window, or an attacker that records the messages and knows that the client's clock is too fast, or other cases.=C2=A0 (A client that deliberately does this could of course just send the same application data later as well.)=C2=A0 If the time is only a few seconds out of the window, then delaying a response until it is in the window and only then entering it into the single-use cache might be reasonable, but if the time is very far in the future, do we really want to try to succeed in that case?

If the time is very far in = the future, the text is supposed to tell you to fall back
to 1-RT= T...



It looks like we no longer do anything to obsolete/reserve/similar the HashAlgorithm and SignatureAlgorithm registries; was that just an editorial mixup or an intended change?


We removed the API guidance for separate APIs for read/writing early data versus regular data, which I believe had consensus.=C2=A0 But I thought we were going to say something carefully worded about having an API to determine whether the handshake has completed (or client Finished has been validated, or ...), and it looks like this is buried at the end of E.5(.0), with the string "API" not appea= ring.=C2=A0 It might be useful to make this a little more prominent/discoverable, whether by subsection heading or otherwise.
=

Suggestions welcome for where this w= ould be better....

-Ekr

<= br>

=C2=A0

I also found some issues that I believe to be purely editorial, for which I will submit a pull request.

I will probably try to make another full review pass over the entire document (mostly looking for editorial things), but I have until the end of IETF LC for that, right? ;)

-Ben

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


--001a114dae1a1c08c3055410dd70-- From nobody Tue Jul 11 13:55:45 2017 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 B9DBD129A97 for ; Tue, 11 Jul 2017 13:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 LkjNJrk0-X1m for ; Tue, 11 Jul 2017 13:55:41 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 36BF6127869 for ; Tue, 11 Jul 2017 13:55:41 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dV2C3-0001I8-CK for tls@ietf.org; Tue, 11 Jul 2017 22:55:40 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dV2BT-0007IW-St for tls@ietf.org; Tue, 11 Jul 2017 16:55:38 -0400 Received: (qmail 12921 invoked from network); 11 Jul 2017 20:55:02 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.115]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Jul 2017 20:55:01 -0000 To: Stephen Farrell , Ted Lemon References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> Cc: tls@ietf.org From: Christian Huitema Message-ID: Date: Tue, 11 Jul 2017 13:54:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BJ2dSchcRNGe5sVOdQDDFOBmlNIT8VQXk" X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJZYP2pkjqshrWYL747BjInHND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23rWrWuqcVlBWkg/OVacUArIryRN09Lit7hjFm LHo/TaVdoeXz5DeswnB8+wRFZgNkYOEkjsX7F8KmpUaZQHV+SejOO+5k046wqf0SEutzqoO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpOWca0Z0beD6jMx95O4U5K/6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyXNjoTjYggJ9y67VShSDm/neNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17GFJHu7VqC2lywbop/MU3ZC2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe93qlFit1PvkPF7Ua1AOSWcb0i13zjCiwPgdt77s k1WBMw== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 20:55:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BJ2dSchcRNGe5sVOdQDDFOBmlNIT8VQXk Content-Type: multipart/mixed; boundary="4VQpKeeQ7x34xVg63oKBHXKhmJAJvJNL7"; protected-headers="v1" From: Christian Huitema To: Stephen Farrell , Ted Lemon Cc: tls@ietf.org Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> In-Reply-To: --4VQpKeeQ7x34xVg63oKBHXKhmJAJvJNL7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/11/2017 1:31 PM, Stephen Farrell wrote: > PS: There are also genuine performance reasons why the same > DH public might be re-used in some cases, so there would be > false positives in a survey to consider as well. Well, yes. The classic argument is performance. Saving the cost of exponentiation, computing G^X once for many session instead of once per session. But you reap most of the benefits of that optimization with a fairly small number of repetitions. Performance alone is not a good reason to use the key over extended period, not to share the exact same key between all servers in a farm. The fact is that wide reuse of the same (EC)DH private key does compromise the security of TLS -- including an obvious issue with forward secrecy. I get your argument that this can turn into a cat and mouse game. Clients detect a bad behavior, misbehaving servers adapt by tweaking the behavior to avoid detection, clients get smarter, etc. On the other hand, documenting the attack clearly marks this key reuse as not desirable and not supported. The public statement provides an argument to developers to "just say no" when asked to add the wiretap "feature". Detection by clients also provides a clear signal to enterprises that they should really find another way to solve their problem. In any case, I just submitted PR #1049 (https://github.com/tlswg/tls13-spec/pull/1049). --=20 Christian Huitema --4VQpKeeQ7x34xVg63oKBHXKhmJAJvJNL7-- --BJ2dSchcRNGe5sVOdQDDFOBmlNIT8VQXk 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 iQEcBAEBCAAGBQJZZTshAAoJELba05IUOHVQDmcH/1WH42oEMKzGVa6VXXaDilHW qWWioCTpNGRwoBmRqUAPX5vjLPqbxBsac+MWPO/Q7y1JXaPl65prPbhbTZweGlUv lsbANNTjBKq8D/0p5t+CJ2f3a7yhWSL3ezkAnEfldi/22On9jwSS2TB8fByChoGf 4n2+7YZ4UzPCTmYqUM1KB0xG5qR9JqD1obpveejlA3VzGWZi+2afC2/RsxRXgn43 pVVp7sCWqFu3hDKw0uBCtzBlH8N7H19RGmuaI1ZGZFJzoN3LC2xD7UXrLNx8lYz1 e8b9AmANd5hK2vVVny3f5DMH5OXDqmiIkItzPQoJAAj7QxznVZx9/7F/R4wMwns= =BRLQ -----END PGP SIGNATURE----- --BJ2dSchcRNGe5sVOdQDDFOBmlNIT8VQXk-- From nobody Tue Jul 11 13:58:24 2017 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 16B90127868 for ; Tue, 11 Jul 2017 13:58:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pN6jE19rfjtT for ; Tue, 11 Jul 2017 13:58:21 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 A313D126E3A for ; Tue, 11 Jul 2017 13:58:21 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id 32so3724509qtv.1 for ; Tue, 11 Jul 2017 13:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Mvr9B0IiUDupmdkFiYxgw/OaTQjJKhZdo5kr789RSes=; b=bB6dbdACIMzGjNgPhQSXCfPo05vz5KvEFnq/zJBlHaypIUYdA1xtgypr81RM8bea6Z Dg+HNfrLwJH6yOAdHjPf86yJZRILEpUeTgu48l2gnrVFjV1i4+BLSOZ/kwQsdcFDjPxR H68YSUQXfp02vP5kAbR2lKcTjdmERKbY+Sh4DBXGkFdqt+xdp3YuFC5Z59AXdivnUUwP cV6VtJJeLB0WC9cqTx9Ge1eSUOXAhJ1Ph9/nJ0yobSqOVtDBhsZ71OOKo9zZdl7iJhoJ tsDjWbl0YBTPRw6/cEuaAErSvHmn7ht7W8n8tgJUVSGntWGESqgGwVkVUhbLRWsONGEE 9Mig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Mvr9B0IiUDupmdkFiYxgw/OaTQjJKhZdo5kr789RSes=; b=k+u9ruiAYi41TuwXFsMO1eD9BKXzUpRnWwf3oKBebHtjx8TB0PpVgNXDIPl5Vrp8bF UUJNEugrXc5qwfUFdKTRbYcI41MVo1oDP51GLw2Rg6c5zXeNXOhyVBoMbWvzVZ7WoriX gSfKVeIEowiKjT2jicj8KKIj9VI3SgavDtXWXaOAgoXGe+1WgbVi7lZi1LQDL0L5Pd3V m/iJCP6s/ooWTiWq7LWdpy9WPijmf4SCeWM6eW03PyRICSwG8+Qzp/EzbNOO0khvtRpo gg+YmTW9jewwnPqNazjBY70OuibRfMdPQZIzfFXD2OlDVJ8UiY6wDkC/Ae8VJAaqai2F 0B8A== X-Gm-Message-State: AIVw1136MN+w/aq7etTME99o8oXKZv6bHCpHtLsRN6FxXocpY8G2eH1l nun/5RmJxQ/Grs2bIHVMyw== X-Received: by 10.237.41.132 with SMTP id o4mr2417900qtd.242.1499806700641; Tue, 11 Jul 2017 13:58:20 -0700 (PDT) Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j65sm274936qkf.38.2017.07.11.13.58.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 13:58:19 -0700 (PDT) From: Ted Lemon Message-Id: <74719010-DD1D-44F5-A65C-2FF5DD539066@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_07FEAB80-00CB-4097-B1BC-8BF2C68D1BF9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Jul 2017 16:58:18 -0400 In-Reply-To: Cc: Christian Huitema , tls@ietf.org To: Stephen Farrell References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 20:58:23 -0000 --Apple-Mail=_07FEAB80-00CB-4097-B1BC-8BF2C68D1BF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 11, 2017, at 4:31 PM, Stephen Farrell = wrote: > I'd bet folks would invent proprietary > ways of avoiding detection, that deviate from the "standard" > and that perhaps make crypto worse all around. Say by deriving > secrets from some function f(exfiltrated-secret, time, count) > for a small counter or some such and having the decryptor of > the wiretapped packets hunt a bit for the right key. Hm, well, but that would be catnip for security researchers, = particularly if it weakened the key. But yeah, you're right, that does = make detecting the attack possibly impractical aside from as a large = research project. --Apple-Mail=_07FEAB80-00CB-4097-B1BC-8BF2C68D1BF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 11, 2017, at 4:31 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
I'd bet folks would invent = proprietary
ways of avoiding detection, that deviate = from the "standard"
and that perhaps = make crypto worse all around. Say by deriving
secrets from some function f(exfiltrated-secret, = time, count)
for a small counter or some such and = having the decryptor of
the wiretapped = packets hunt a bit for the right key.

Hm, well, but that would be catnip for = security researchers, particularly if it weakened the key.   But = yeah, you're right, that does make detecting the attack possibly = impractical aside from as a large research project.

= --Apple-Mail=_07FEAB80-00CB-4097-B1BC-8BF2C68D1BF9-- From nobody Tue Jul 11 13:59:12 2017 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 2287F127869 for ; Tue, 11 Jul 2017 13:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 EqZPrTp8haEx for ; Tue, 11 Jul 2017 13:59:07 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 380FE126E3A for ; Tue, 11 Jul 2017 13:59:07 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6BKwwdk038078; Tue, 11 Jul 2017 16:58:58 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Christian Huitema , Stephen Farrell , Ted Lemon CC: "tls@ietf.org" Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQHS+YQIkdUXlkluJUyIYpIPJvLqsqJNcwgAgABE5ACAAAwtgIAAD9QAgAAChYCAAAJxgIAA4XSAgAAd/4CAAAYnAIAAZHCAgAAIVICAAAIXAIAAAyWAgAABLICAAAevgIAABoIA//++H4A= Date: Tue, 11 Jul 2017 20:58:56 +0000 Message-ID: <5734053D-F491-4A2A-B8CC-451BB0797B41@ll.mit.edu> References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.0.170702 x-originating-ip: [172.26.150.37] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3582637136_1653575835" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-11_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707110333 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 20:59:10 -0000 --B_3582637136_1653575835 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99d rather not deal with this whole mess. -- Regards, Uri=20 On 7/11/2017, 16:56, "TLS on behalf of Christian Huitema" wrote: On 7/11/2017 1:31 PM, Stephen Farrell wrote: =20 > PS: There are also genuine performance reasons why the same > DH public might be re-used in some cases, so there would be > false positives in a survey to consider as well. =20 Well, yes. The classic argument is performance. Saving the cost of exponentiation, computing G^X once for many session instead of once per session. But you reap most of the benefits of that optimization with a fairly small number of repetitions. Performance alone is not a good reason to use the key over extended period, not to share the exact same key between all servers in a farm. The fact is that wide reuse of the same (EC)DH private key does compromise the security of TLS -- includin= g an obvious issue with forward secrecy. =20 I get your argument that this can turn into a cat and mouse game. Clients detect a bad behavior, misbehaving servers adapt by tweaking th= e behavior to avoid detection, clients get smarter, etc. On the other hand, documenting the attack clearly marks this key reuse as not desirable and not supported. The public statement provides an argument to developers to "just say no" when asked to add the wiretap "feature". Detection by clients also provides a clear signal to enterprises that they should really find another way to solve their problem. =20 In any case, I just submitted PR #1049 (https://github.com/tlswg/tls13-spec/pull/1049). =20 --=20 Christian Huitema =20 =20 =20 --B_3582637136_1653575835 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKSUBIdwAAAAC3lzANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE3MDQwNzE5MzYyNFoXDTIwMDQwNjE5MzYyNFow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8OK5RGbI6mDfMw/2HPG57y1TdKRaQwlj5iSXC4gDg tv34L93tRDUTjA27kFG5HOrWar2c37RMkVX7nFR9TfGZh66CSe7Lj7ZMZ3wNyodJqptavXaV DjSuqp6sPJGQFZNr/pIA2g/3uUOq/igeInptaYb3eDsTwt4fv4G3iLp5Z/4bd26LDJltFZnE qOsLsQ3xfkAAaht55x+jl1QNm7+Vfe4RVeInASY7xZu9dQUJChc46p7sVcV9/exjYIkOeeG9 QB6i4CJK4vHbyF2qG+IqZfeYFjXWy3Eq7a7YrgqAl81Xs4Bpjsn9zPlFlwmHNVUBJTgShUql kFvqKjcw0FDpAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUWa29JQeRiwuEcAGFzsv/xdyErcAw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBCDAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAIjee93wr/GEbKbqkXc5 krqRGzwcj6/NhW9rmX+MwXqm63OL+/H159UXdIQCqdd1uovIOcK8y/gXjlJOJ6ol54aixafq sz3ozZ+eIUvphrxRVTxR8vVb17QnPxOQE0Mx9N1uRS+Hps7XgDS628KYfzxMb12+2WriuwyM VAVl+lCBF1S4ZO/0NBx/wVyEu8Hi73kHC93/4HC1c4bwoExAAjY+twm7VBY8eTpvV/604iDf 1NdKtCb5l1fFZkyZnQ5ZDKONBehGsRGF0eWBUDCopoYTu8nbcRocvRGM+ZLFtPLh5xlpjrO2 E+CE6Bjx948aoJJCXqHf7BeKxlbazvl2RaIwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCklA SHcAAAAAt5cwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgOkanMi9KFH+StkD9 /MFCdVfqtahynFJ9QjXJmpvQmHMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcwNzExMjA1ODU2WjANBgkqhkiG9w0BAQEFAASCAQB4IcfgO/pKVRVMVFfu NhN95k4/tq7REhSacdVw58W5CPzQvlpv3XTQNxpZgXoN/Zeo8gylJh5j7f5uoT6sT2VNvIx1 +fCVywOR26uF12r4zVX/I08JR94iQWNXb0n19woPZf1CkkNbPG79B1PP4yaQC2qwT7NU2/lP 5gIRH9mY/SoyyYFWGeNoaLq1yp23GnWkJMA7Zk+YO4thaESefGDuJlutO5gf3ibsp49ZogT7 yE8LXH9FBqZ5Lx0WFzcBOW0EK2L94la8BlYbUaqX4gxo5YWdSvPvzNRs9NVL01ZJMyPppO+A ilBmEYmaz7KD2nbJQyM+RmuaC2adNmkxHbKg --B_3582637136_1653575835-- From nobody Tue Jul 11 14:10:56 2017 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 D2043129B36 for ; Tue, 11 Jul 2017 14:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 SrA__9JwMEWF for ; Tue, 11 Jul 2017 14:10:53 -0700 (PDT) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::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 0998B129A97 for ; Tue, 11 Jul 2017 14:10:53 -0700 (PDT) Received: by mail-lf0-x244.google.com with SMTP id g21so484360lfk.1 for ; Tue, 11 Jul 2017 14:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xFHjv19PeuzyPdm5u46vZ6kg6YvQRWm592z1h7X5BN4=; b=B1rBjLen0qQzzMcLcMKZIqXRU5IQj6+IdJrinTce+Ii8Ya/R3nnMUyain7Ce1n7bm0 Wk+ulrTaqJ9KpLHqRaD4vqmy7E0I/+0Sf4k46RUpJFZstDIwdBLkc3NcXpvVrBA5upFw qivqu7a7c2JHdbHMdyEipKAxQCkLlr3Yo784NwG/OSmnHL0A8RNrWDQIkfAEeRpmtCrR qz//gIkiCDm4q4JrdUs9bEBkC5MRnbEgSan+vEZPIIYeBfIrrwwzx1/U6Akb7K1gI4K5 43MfXW4XEhyowHd/0X6+WyQoXrDQX/kSXnZ4fR+Fe+zfONcrzp0yXtAMu4l/aFD0wnZe BEyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xFHjv19PeuzyPdm5u46vZ6kg6YvQRWm592z1h7X5BN4=; b=bJYG5OyjsO+6Q4JLHRmZcKLGNl9Iz4fCjdf8BWfJr/QKyjvxssKM0x8B21pXIiioSv ft8SRV9lJH0Kw8QdXqYSlV9ZXsx96wyqmMde04hbmJUBUgN6FpG6yxTav3bDC8sikvkc 41ZQ18zqX0HcyFVFUhZyRSFRPVpzZsPQXPIeBYw6+F05PNjo+Us73LrJmN9Iht8ZeRkX PfU9XcazdfbZMNf/wiqOz+eZI9bufSpuWlQ8rYYf8oQspAnBW+TO2OWDhiNBNMVplkIu HUkWoS/CB+IPA2DtMC9EDRC+zS4ux4S/VYoUsTwSpPmjf3z4JblNplwpO+jcGJ8sufYJ EM0A== X-Gm-Message-State: AIVw113npMlz2asEPPAOuVb0WmbnW6RDCadIuUDMsW7+td0rzvqBUxzA RAO3C/of52G0GiuTETg= X-Received: by 10.80.218.135 with SMTP id q7mr3808815edj.85.1499807451271; Tue, 11 Jul 2017 14:10:51 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g38sm197914edc.7.2017.07.11.14.10.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 14:10:50 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F1E128EB-14D9-4200-98EC-AD2F36FE17C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Jul 2017 00:10:47 +0300 In-Reply-To: Cc: Stephen Farrell , Ted Lemon , tls@ietf.org To: Christian Huitema References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 21:10:55 -0000 --Apple-Mail=_F1E128EB-14D9-4200-98EC-AD2F36FE17C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jul 2017, at 23:54, Christian Huitema = wrote: >=20 > On 7/11/2017 1:31 PM, Stephen Farrell wrote: >=20 >> PS: There are also genuine performance reasons why the same >> DH public might be re-used in some cases, so there would be >> false positives in a survey to consider as well. >=20 > Well, yes. The classic argument is performance. Saving the cost of > exponentiation, computing G^X once for many session instead of once = per > session. But you reap most of the benefits of that optimization with a > fairly small number of repetitions. Performance alone is not a good > reason to use the key over extended period, not to share the exact = same > key between all servers in a farm. The fact is that wide reuse of the > same (EC)DH private key does compromise the security of TLS -- = including > an obvious issue with forward secrecy. I don=E2=80=99t think the number of times (within reason) a key is used = matters that much. It only matters whether or not it is exportable. If a = server implementations generates a fresh key for every session and then = stores it in a database that maps public key to private key, then that = database can trivially be used to decrypt all traffic. Conversely, an = implementation could generate a key in memory and use it until reboot = and as long as it=E2=80=99s not exported, nothing happens. I once implemented an ECDHE TLS server with an in-memory key that was = rotated every 10 seconds. Since it was never written to disk (or even = paged out) this practice did not compromise forward secrecy. The draft also recommends rotating the keys, but I guess that would be = far less often than once every 10 seconds. But that is not the crucial = difference. The crucial difference is that these keys get exported. Note, however, that the reason RSA ciphersuites were deprecated is that = we are afraid that a stolen or coerced private key will compromise past = sessions. If the session between us is recorded today and someone steals = or demands my private key tomorrow, than they can decrypt our = conversation from today. This is not the case in (EC)DHE ciphersuites in TLS 1.2 or 1.3. Any = session that happens before this mechanism is turned on, is safe. = Sessions can only be compromised after the server has enabled this = feature, which is equivalent to handing over the RSA private key in RSA = ciphersuites. That is not the forward secrecy issue that we wanted to = solve by removing RSA ciphersuites. If one of the parties to a = conversation cooperates with the wiretap, this isn=E2=80=99t an attack. Yoav --Apple-Mail=_F1E128EB-14D9-4200-98EC-AD2F36FE17C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZZT7YAAoJELhJCxUKWMyZCj4H/jWZRvUH2arfbTPXKaa4PPej FlUqBBsJFDuGwm5nLksvUU/mI7YqgplfKGq6AhDvvlRhWZpSv25jHatp0WU5+biP iW0JAL6SRpg2C0aDW81dI7s0jbdUMUre3j+Qs2LBZMjJK+OP1IELGVQWzVTgIwtG DNZgZ6XTwZseF7sEiuR199LsGvQTHb6C3QJ8YxFNMybW3CBpgJjm+JK57s+zKFFP DG7ZqDZTqiOLoZRVgdBjkxrYR6A/LXM8CRXJBsiJd0iw2Bh9pZrwlRX/yS6eSauN DfyfuoobYpTWlouOwXBIBhAzbJR0yoy/xfMfD/ukV68k+l3lSmZeJwk5YRCgCyQ= =Mq4i -----END PGP SIGNATURE----- --Apple-Mail=_F1E128EB-14D9-4200-98EC-AD2F36FE17C2-- From nobody Tue Jul 11 14:16:37 2017 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 1113612F287 for ; Tue, 11 Jul 2017 14:16:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eR3xCQYnDp9l for ; Tue, 11 Jul 2017 14:16:34 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 0350812ECB5 for ; Tue, 11 Jul 2017 14:16:33 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id r30so4139019qtc.0 for ; Tue, 11 Jul 2017 14:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=s2inkSzTRfCyKxFsUOig+2MffrVeq7eMxRaKxhbf+BU=; b=wNil1rwyLeQwz0rbVN8NW0Re3V5EKupfYVnausLRyivCfTyYfe3rNu6MlpHDOU6hPa otKnSgyMQcb7fc31AcnAU1oPmonhcP0MGgBSglcy2BwGHLZ5cCgoSfCQLYUQJrz93zIz IVuq9nBi5S+s82/ejYLV1c0rsjSD4CDLFHdpMUEWoc3b9xZ3eg0AJyQewoNgSFGTlJzf UWiJYWp+6+mOL9Ys92q4wUf1RWJizhQFqDUg+80ewrz9xHXAiYTZNOb/QIBozuGOd1ah CPbxoLjZNJMzNu6HRPLjCnJKxRWP/ZWCsT5/wo1qKa2KVKdXThjMKxVeEDlbA9VYdNQP J7xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=s2inkSzTRfCyKxFsUOig+2MffrVeq7eMxRaKxhbf+BU=; b=XzKdN/TJz2UeSrnCqefzaHWfFJ3E3/0+gnd4rxFtFQglt/nF7FOJLQhtDG9hXZkAFK xSyumWI6Dpwx/8/vhkwZBVq+Q8bTPDm+X2Y6iSNOBf+be6TS5BOISL2DnmWlEe7b3fM8 dzrPfNNOwI/Rmt3bzpOUX8eDAcl8hX2W3MZ9ISfWiugd+mugmzlDO5z0Y9VGKK6HaHzk F24UkM8ioDteNC+P55v4Q0SMNXA5EEYNphr4Tl/h1a7wmggERAa4ULYfqo3jhiR4jttk rP1u3HtMF3t7h2GrhORRcG96fP4YIhWCI3aunzBG2+y/QCW6TA3Dd1hmXKY05J5DwnJb J1LA== X-Gm-Message-State: AIVw113AdsG9HEztKgdwGp7Go+gvsc/POmQnWZ+Mv/fL2gvPdkuBuUXf POOVh3+YPYQLu70Tyv9kNQ== X-Received: by 10.200.13.4 with SMTP id q4mr2494617qti.221.1499807793028; Tue, 11 Jul 2017 14:16:33 -0700 (PDT) Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id h17sm358327qte.20.2017.07.11.14.16.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 14:16:32 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8AA6497C-735E-4176-8A62-70698828EEE7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Jul 2017 17:16:31 -0400 In-Reply-To: <74719010-DD1D-44F5-A65C-2FF5DD539066@fugue.com> Cc: Christian Huitema , tls@ietf.org To: Stephen Farrell References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> <74719010-DD1D-44F5-A65C-2FF5DD539066@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 21:16:36 -0000 --Apple-Mail=_8AA6497C-735E-4176-8A62-70698828EEE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 11, 2017, at 4:58 PM, Ted Lemon wrote: > On Jul 11, 2017, at 4:31 PM, Stephen Farrell = > wrote: >> I'd bet folks would invent proprietary >> ways of avoiding detection, that deviate from the "standard" >> and that perhaps make crypto worse all around. Say by deriving >> secrets from some function f(exfiltrated-secret, time, count) >> for a small counter or some such and having the decryptor of >> the wiretapped packets hunt a bit for the right key. >=20 > Hm, well, but that would be catnip for security researchers, = particularly if it weakened the key. But yeah, you're right, that does = make detecting the attack possibly impractical aside from as a large = research project. On second thought, this suffers from the same problem as the = many-static-keys problem: there are too many moving parts. This = requires all clocks on all servers and interceptors to be in perfect = sync, not just close, or else potentially halves the performance during = clock skew overlap periods. It requires every server and interceptor = to implement the same algorithm. And you still have to distribute the = information from which the key is derived. So again, yes, you can do this particular mitigation strategy. But = it's expensive, and so nobody's going to do it if they have a better = choice. It's cheaper to just re-tool to support TLS 1.3. As long as = the solution isn't standard, it's only going to appeal to a _very_ = limited audience, if there's any audience for it at all. E.g., = consider trying to deploy something like this on a country-wide scale. = You're just going to exfiltrate every key instead=E2=80=94it's cheaper. --Apple-Mail=_8AA6497C-735E-4176-8A62-70698828EEE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 11, 2017, at 4:58 PM, Ted Lemon <mellon@fugue.com> = wrote:
On Jul 11, 2017, at 4:31 PM, = Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
I'd bet folks would invent proprietary
ways of avoiding detection, that deviate from the = "standard"
and that perhaps make crypto = worse all around. Say by deriving
secrets from some function f(exfiltrated-secret, time, = count)
for a small counter or some = such and having the decryptor of
the wiretapped packets hunt a bit for the right = key.

Hm, well, = but that would be catnip for security researchers, particularly if it = weakened the key.   But yeah, you're right, that does make = detecting the attack possibly impractical aside from as a large research = project.

On = second thought, this suffers from the same problem as the = many-static-keys problem: there are too many moving parts.   This = requires all clocks on all servers and interceptors to be in perfect = sync, not just close, or else potentially halves the performance during = clock skew  overlap periods.   It requires every server and = interceptor to implement the same algorithm.   And you still have = to distribute the information from which the key is derived.

So again, yes, you can = do this particular mitigation strategy.   But it's expensive, and = so nobody's going to do it if they have a better choice.   It's = cheaper to just re-tool to support TLS 1.3.   As long as the = solution isn't standard, it's only going to appeal to a _very_ limited = audience, if there's any audience for it at all.   E.g., consider = trying to deploy something like this on a country-wide scale.   = You're just going to exfiltrate every key instead=E2=80=94it's = cheaper.

= --Apple-Mail=_8AA6497C-735E-4176-8A62-70698828EEE7-- From nobody Tue Jul 11 14:21:23 2017 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 0540E12F268 for ; Tue, 11 Jul 2017 14:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMcJLpfvLgIO for ; Tue, 11 Jul 2017 14:21:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E453F12ECF0 for ; Tue, 11 Jul 2017 14:21:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 99E08BEBE; Tue, 11 Jul 2017 22:21:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4oc6Hx0_UFl; Tue, 11 Jul 2017 22:21:16 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4C301BEAF; Tue, 11 Jul 2017 22:21:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499808076; bh=i27yrwA+I25rMaTZjcfrYUgGdQCnlnqb2NVVeVxYDIU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=e1qEut9Gd9o6nUEblliL34b9sd5fiLRyPNFEB6LiDP98X5ocjO/Uh9tYZtFgyFyAV D6gwA+KeOrmN+fzEG3/zP86q2u/PWdMuBPBk4sqKzRWTzs0kluC5myiBEOi3RnNsJ8 BTYg+fFwsIEovz7XTbeoM0e/XaYBotrVo73z9YYk= To: Yoav Nir , Christian Huitema Cc: Ted Lemon , tls@ietf.org References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <104f5108-751a-c8f5-45dc-bf5d7be26f35@cs.tcd.ie> Date: Tue, 11 Jul 2017 22:21:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D4unTnFaxvxDR1C0AIO0CNGb5hfOJkuHG" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 21:21:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D4unTnFaxvxDR1C0AIO0CNGb5hfOJkuHG Content-Type: multipart/mixed; boundary="HaN3XbOUCvkf8A8SRS2HIarMLPrWHubJ3"; protected-headers="v1" From: Stephen Farrell To: Yoav Nir , Christian Huitema Cc: Ted Lemon , tls@ietf.org Message-ID: <104f5108-751a-c8f5-45dc-bf5d7be26f35@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> In-Reply-To: --HaN3XbOUCvkf8A8SRS2HIarMLPrWHubJ3 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 11/07/17 22:10, Yoav Nir wrote: > If one of the parties to a conversation cooperates with the wiretap, > this isn=E2=80=99t an attack. Lemme try on this one again from a different angle. In classic telephony wiretaps the carrier does the tap. There are similar situations with TLS... In hosted platforms (e.g. wordpress.com and many others) where the senders and receivers (or publishers & readers) have read and write access via PHP code and not via a shell, and cannot therefore control web or TLS configuration, the platform would be doing a wiretap if it turned this on, whilst colluding with or being coerced by some other entity that collects and later decrypts the ciphertext and packets. Are we agreed that that use-case is wiretapping via this mechanism? There are many millions of people who use such constrained hosted environments. Cheers, S. --HaN3XbOUCvkf8A8SRS2HIarMLPrWHubJ3-- --D4unTnFaxvxDR1C0AIO0CNGb5hfOJkuHG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZUFLAAoJEC88hzaAX42iOI0H+gJ1wLAxFYJk9UrKZJlzAtp8 EQMzqnZDC3T11apkUlfIUqHIikT6lFECxFBPKUF8gvHFF3dybxkv1V0/vifhjiyM E4++UV6vD4L3ugHsY16U6EsX4+bCiWGIBHOgf6d28r6XEXNW3XLSQ9To4vIAJd87 5LliDS9Yr0qltxeNnUXEhJD7tJTU/fMtsUe6QExDxHkEIFUCVICOvuH8sb1pye24 qVMMEICS2ngfoV6v+VnWI7x8q3jnALKGIMD6NFuUd0gxv4kVbND4scEcIR9fIGQ5 RXZ8u0jM1cA3ucfhOPOhyuaCBIUiuiNY6aV2e0PCSGB+HG4Ngif6ey8Iiu+t/xI= =cjVZ -----END PGP SIGNATURE----- --D4unTnFaxvxDR1C0AIO0CNGb5hfOJkuHG-- From nobody Tue Jul 11 15:09:10 2017 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 E72D3127735 for ; Tue, 11 Jul 2017 15:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HR2JE3P8UrIe for ; Tue, 11 Jul 2017 15:09:08 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 EA4EA12ECB3 for ; Tue, 11 Jul 2017 15:09:07 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id 77so8048733wrb.1 for ; Tue, 11 Jul 2017 15:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0+36Vun9A2Cl/lBGHdLIi55bxYrrpRHPjfLuXkRWbGA=; b=gpdntCBiIeZUuWHzfE7bvWLYZPo3SfqcTRLnXzMVDAEfX77gM8XSBpwLRaPd6RkSr6 znMXR2AMHkAp1BZ3YWWeRDC3srGhNyu81THdW1e9DJ1W0yGhECxDamkGrdLGQCEsB4QE JBGIeYGfSAyJJMJ9QTrqvrHsPMCAuM5C5/JRf/KdFoaYZjFaKwOBrsEOkYfGDPnRvQYn m3j3EzSd7B3llfbeD8LEERaQ+M8L6oRPX2D5xwxoHIipw3ylqQh2hB8Baj9pNLQvTA9h IAPd/iizxHutisOFdvrrBwL4/IC4fgAaLE92Va2iqhfg05k8jfCRwVuKLySHsV/tOlBc gQ2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0+36Vun9A2Cl/lBGHdLIi55bxYrrpRHPjfLuXkRWbGA=; b=dNsJSo9HzmdZcE4kKCDxq5T1bBfB6KtQ82RpFCT/A83kJS7JNYetG0dZaEOENhyOQr mhRzhB664exiTWNXrwr4v0YQVOqzGP2M9Ziq44tI8woH9vyBQUr78afD3qc2eiQ5u+0O 5o4+aMM4PoRScCDFIM237TZJLJfVKw/QOFrkGri+HssUEKJXmQAKS0rEYd1guwfY1TbD sMHjwhg57IEFdB8lR23PDZ+58quFz1ECty0IpXICtENs7tGyNkj9qNYFb7Ca3B8pt9ri pwZdR+rD/QJ1BdGb0vxOmXfewGcwNmY9p7Z19IwM5tSUVUiLK7KQtDLv30tfM1r0tREX om/w== X-Gm-Message-State: AIVw110bNCd+yCryBn+A8ShEdU8JFynSVc+gLCae2bQOZjtY005ZN41k JaXjIIJYoWtKuA== X-Received: by 10.80.138.34 with SMTP id i31mr3913754edi.119.1499810946521; Tue, 11 Jul 2017 15:09:06 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id a25sm229241eda.44.2017.07.11.15.09.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 15:09:05 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C53FEFAD-201F-4922-8E45-17E8BE2E635A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Jul 2017 01:09:02 +0300 In-Reply-To: <104f5108-751a-c8f5-45dc-bf5d7be26f35@cs.tcd.ie> Cc: Christian Huitema , Ted Lemon , TLS WG To: Stephen Farrell References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> <104f5108-751a-c8f5-45dc-bf5d7be26f35@cs.tcd.ie> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 22:09:10 -0000 --Apple-Mail=_C53FEFAD-201F-4922-8E45-17E8BE2E635A Content-Type: multipart/alternative; boundary="Apple-Mail=_3B035CE6-9A5A-4E2A-8DDA-A9967E02B5FD" --Apple-Mail=_3B035CE6-9A5A-4E2A-8DDA-A9967E02B5FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Jul 2017, at 0:21, Stephen Farrell = wrote: >=20 >=20 >=20 > On 11/07/17 22:10, Yoav Nir wrote: >> If one of the parties to a conversation cooperates with the wiretap, >> this isn=E2=80=99t an attack. > Lemme try on this one again from a different angle. >=20 > In classic telephony wiretaps the carrier does the > tap. There are similar situations with TLS... >=20 > In hosted platforms (e.g. wordpress.com and many > others) where the senders and receivers (or publishers > & readers) have read and write access via PHP code > and not via a shell, and cannot therefore control web > or TLS configuration, the platform would be doing a > wiretap if it turned this on, whilst colluding with > or being coerced by some other entity that collects > and later decrypts the ciphertext and packets. >=20 > Are we agreed that that use-case is wiretapping via > this mechanism? >=20 > There are many millions of people who use such > constrained hosted environments. Wordpress.com is a party to the session. It has = access to the plaintext and could deliver it to whatever third party = whenever they wanted. This draft may be an optimization, but the = plaintext was always theirs to give. I might be deluding myself that I=E2=80=99m sending this email to you = over TLS. In fact I=E2=80=99m only uploading it to gmail.com = who will forward it to TCD=E2=80=99s server. Both = servers will have access to the plaintext. Both servers can send it to a = third party, or share session keys or share ECDHE private keys. Whether one party to a conversation (phone or IP) has the right to share = private contents with a third party is a legal matter that varies from = country to country and from state to state. I only claim that this draft = does not change the fact that is true for PFS suites in TLS 1.x and for = all suites in TLS 1.3, that it=E2=80=99s impossible to decrypt a = recorded session without cooperation from either party, and that = cooperation has to start *before* the session is recorded. That is not the case for POTS wiretap or for the RSA key exchange. Yoav --Apple-Mail=_3B035CE6-9A5A-4E2A-8DDA-A9967E02B5FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 12 Jul 2017, at 0:21, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:



On 11/07/17 22:10, Yoav Nir wrote:
If one of the parties to = a conversation cooperates with the wiretap,
this isn=E2=80=99= t an attack.
Lemme try on this one again from = a different angle.

In classic telephony = wiretaps the carrier does the
tap. There are similar = situations with TLS...

In hosted platforms = (e.g. wordpress.com and = many
others) where the senders and receivers (or = publishers
& readers) have read and write access via = PHP code
and not via a shell, and cannot therefore control = web
or TLS configuration, the platform would be doing a
wiretap if it turned this on, whilst colluding with
or being coerced by some other entity that collects
and later decrypts the ciphertext and packets.

Are we agreed that that use-case is = wiretapping via
this mechanism?

There are many millions of people who use such
constrained hosted environments.

Wordpress.com is a party to the session. It has = access to the plaintext and could deliver it to whatever third party = whenever they wanted. This draft may be an optimization, but the = plaintext was always theirs to give.

I might be deluding myself that I=E2=80=99= m sending this email to you over TLS. In fact I=E2=80=99m only uploading = it to gmail.com who = will forward it to TCD=E2=80=99s server. Both servers will have access = to the plaintext. Both servers can send it to a third party, or share = session keys or share ECDHE private keys. 

Whether one party to a conversation = (phone or IP) has the right to share private contents with a third party = is a legal matter that varies from country to country and from state to = state. I only claim that this draft does not change the fact that is = true for PFS suites in TLS 1.x and for all suites in TLS 1.3, that = it=E2=80=99s impossible to decrypt a recorded session without = cooperation from either party, and that cooperation has to start = *before*  the session is recorded.

That is not the case for POTS wiretap = or for the RSA key exchange.

Yoav

= --Apple-Mail=_3B035CE6-9A5A-4E2A-8DDA-A9967E02B5FD-- --Apple-Mail=_C53FEFAD-201F-4922-8E45-17E8BE2E635A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZZUx/AAoJELhJCxUKWMyZl/0H/0RtIcWCwiywvjuGlMX4v6ad dKukCy1tlKCwRebXNdWKErKCk/JPEZI7tn0igt/ZDTM8bgAbAYQY+8Ahp2nCmBmY bdrQttXJGA+S4f3MVjzptWt2qFP7IoAvq3ww7T8ookAjaaBMFHycK5FPDLzBhKeN QrfqOmvaVx8LnU51MnLjxYOfOK+FglOegezTWyKWEXMN2/HDA13L7YhBLdDAwxpE HBXz0wlJnL8wGlvaI6U+FWfJdaiedcafpcA0b9fCCLLipP2TRQFO11Qiub0dgj5H P8VNbp9FnW0o9ZaGtlFQO6r/G9A//C6oEQpCNmFer/KggzsyQoVKb4AKbtIvp2o= =Xkd6 -----END PGP SIGNATURE----- --Apple-Mail=_C53FEFAD-201F-4922-8E45-17E8BE2E635A-- From nobody Tue Jul 11 15:15:29 2017 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 51B3612EC05 for ; Tue, 11 Jul 2017 15:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swmiEd_qL8ym for ; Tue, 11 Jul 2017 15:15:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED23129B3A for ; Tue, 11 Jul 2017 15:15:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0ED2EBEC3; Tue, 11 Jul 2017 23:15:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clkRw7XvVo-9; Tue, 11 Jul 2017 23:14:56 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 61B41BE73; Tue, 11 Jul 2017 23:14:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499811296; bh=HwKO4FQvH2LL3HhuNH5GSrLI2EjKopMeIkmwOBU+MvU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NTobPZLvpBZJbVnmnM4MED3I0ly1y4GPTmkGKYHbgii+hlJQuUiVHqcfs+T6ihFi/ 0vz9CQxUq7PD3AZkgnKkjMtW09rd8ghtQaYepl9XEeLOsqo9izDAqMisuwqnijIaFC K0lWFay+iTHZYFkcXouG7GIPDnHzIjpqaXRYmiZM= To: Yoav Nir Cc: Christian Huitema , Ted Lemon , TLS WG References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> <104f5108-751a-c8f5-45dc-bf5d7be26f35@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <340c77ed-ad4a-98cd-7b90-b372f665a26a@cs.tcd.ie> Date: Tue, 11 Jul 2017 23:14:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wbGcPWhwmfmO1hVGWq2XoLd3G53O0hjDG" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 22:15:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wbGcPWhwmfmO1hVGWq2XoLd3G53O0hjDG Content-Type: multipart/mixed; boundary="LegxJxjqkVXGpNJ1cLHUfLuhNi4iQEeN6"; protected-headers="v1" From: Stephen Farrell To: Yoav Nir Cc: Christian Huitema , Ted Lemon , TLS WG Message-ID: <340c77ed-ad4a-98cd-7b90-b372f665a26a@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> <104f5108-751a-c8f5-45dc-bf5d7be26f35@cs.tcd.ie> In-Reply-To: --LegxJxjqkVXGpNJ1cLHUfLuhNi4iQEeN6 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 11/07/17 23:09, Yoav Nir wrote: > Whether one party to a conversation (phone or IP) has the right to > share private contents with a third party is a legal matter that > varies from country to country and from state to state. I only claim > that this draft does not change the fact that is true for PFS suites > in TLS 1.x and for all suites in TLS 1.3, that it=E2=80=99s impossible = to > decrypt a recorded session without cooperation from either party, and > that cooperation has to start *before* the session is recorded. But hang on, in this example wordpress.com are the equivalent of the POTS carrier - why is it a wiretap in the POTS case and not in the HTTP/TLS case? That makes no sense. Neither are a callee/caller just the same as when my vanity domain is used to transfer information between you and I via some wordpress plug-in I've installed. I do agree with the "*before*" statement and about optimisation but an optimised-X is still an X. S. >=20 > That is not the case for POTS wiretap or for the RSA key exchange. --LegxJxjqkVXGpNJ1cLHUfLuhNi4iQEeN6-- --wbGcPWhwmfmO1hVGWq2XoLd3G53O0hjDG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZU3fAAoJEC88hzaAX42i69wH+wbiaT1jLD1Mp4lo4jXVCsPj fXm2GyQvZXcEgL/S3OaDRVqv5WpkxjA6mjAG7r76pfJ5/tdvoFN+X3HmMZ4/LAF/ OG+RcBKgYTe3029xSwvwwNgDf0xYUejD7ojHkHh6595F+HkV/4QuNtqaUECrvRgt i3kghZ/KLYb8h7lCTFLdj4Q0FuE8CE29ZQGaOiJzn0tKGFvnBLbS/jeuR0gUkPVA TY+Aw0CctC3VZdUyTeCisUG/QhmwLM/wYUOcqqvNYvFAVGxytbD29kzFP0a/CE4d puC+Po9JzVXrlkmwsZVpQr9XaDSqLkVWWLGZti8IZ0/aJmDDf3qGrvGv+CYledc= =Al0Y -----END PGP SIGNATURE----- --wbGcPWhwmfmO1hVGWq2XoLd3G53O0hjDG-- From nobody Tue Jul 11 16:06:00 2017 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 7D96012F287; Tue, 11 Jul 2017 16:05:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149981435847.9294.11556655754764493172@ietfa.amsl.com> Date: Tue, 11 Jul 2017 16:05:58 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 11 Jul 2017 23:05:58 -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 : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename : draft-ietf-tls-dtls13-01.txt Pages : 39 Date : 2017-07-11 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls13-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-01 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 Tue Jul 11 16:27:24 2017 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 66D6412F287 for ; Tue, 11 Jul 2017 16:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=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 vWISjBO2IfvF for ; Tue, 11 Jul 2017 16:27:20 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B901242F5 for ; Tue, 11 Jul 2017 16:27:20 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 34911C0028A9; Tue, 11 Jul 2017 16:27:20 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id CB10DC0028A5; Tue, 11 Jul 2017 16:27:19 -0700 (PDT) Date: Tue, 11 Jul 2017 18:27:16 -0500 From: Nico Williams To: Ted Lemon Cc: Stephen Farrell , tls@ietf.org Message-ID: <20170711232714.GA9898@localhost> References: <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> <74719010-DD1D-44F5-A65C-2FF5DD539066@fugue.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] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 23:27:22 -0000 On Tue, Jul 11, 2017 at 05:16:31PM -0400, Ted Lemon wrote: > On Jul 11, 2017, at 4:58 PM, Ted Lemon wrote: > > On Jul 11, 2017, at 4:31 PM, Stephen Farrell > wrote: > >> I'd bet folks would invent proprietary > >> ways of avoiding detection, that deviate from the "standard" > >> and that perhaps make crypto worse all around. Say by deriving > >> secrets from some function f(exfiltrated-secret, time, count) > >> for a small counter or some such and having the decryptor of > >> the wiretapped packets hunt a bit for the right key. > > > > Hm, well, but that would be catnip for security researchers, > > particularly if it weakened the key. But yeah, you're right, that > > does make detecting the attack possibly impractical aside from as a > > large research project. > > On second thought, this suffers from the same problem as the > many-static-keys problem: there are too many moving parts. This > requires all clocks on all servers and interceptors to be in perfect > sync, not just close, or else potentially halves the performance > during clock skew overlap periods. It requires every server and > interceptor to implement the same algorithm. And you still have to > distribute the information from which the key is derived. If TLS 1.3 still has server nonces (does it?) then those could be used to provide enough information to reconstruct the server's ECDH key given access to a base secret (per-host secret, say)... Alternatively could one use some extension to signal such information? After all, if one wishes to decrypt past sessions, presumably one is recording them, so if the transcript gives you the bits you need... Or one could also just construct a protocol by which to quickly log {transcript_hash, session_key} encrypted to the log sink. Or {transcript_hash, counter/nonce for ECDH keygen} -- this doesn't need to be encrypted, which simplifies key management for the escrow system, though it also makes past sessions vulnerable to host compromises. If synchronous, reliable escrow is not required then one could immediately send a UDP datagram to the sink and use background retransmission as needed if one wants reliable escrow. One could even just syslog the darned thing. If reliable escrow is required then hold the connection until the sink ACKs the escrow message. This is a very simple design for session key escrow. It requires a sink and storage, granted, but that's pretty cheap nowadays, you almost certainly have such sinks, and, besides, if you're interested in decrypting sessions after the fact then you're recording entire sessions anyways, so storage-wise a session key escrow system is no big deal. Note that such a system would be completely undetectable from a client's point of view. It's a server-side CALEA-like "port" enabling eavesdropping by authorized parties. One could not prove that the server does not do this without access to the server. Such an escrow-via-logging approach works no matter what TLS 1.3 looks like on the wire. More than that, it works for all client-server protocols for that matter: SSHv2, Kerberos, SCRAM, whatever. All you have to do is specify what goes into the transcript hash for each protocol, and what bits to include for key escrow. Universal session key escrow. What's an intranet not to like, right? The best thing about such a scheme is that it completely sidesteps all this entire "it's wiretapping" "no it's not" "yes it is" "nuh uh" ... thread. One might want to standardize a key escrow logging protocol -- why not? Maybe not at the IETF, or maybe in a WG just for that purpose. I don't have a problem with that. I also don't have a problem with draft-green-tls-static-dh-in-tls13 provided that it be published as an Informational RFC. After all, it documents a method that a) doesn't change TLS on the wire, and which b) clients have a hard time deciding when to refuse to talk to a server that appears to implement it. Sure, it breaks the spirit of TLS 1.3, but that was always possible, with or without an RFC. I might not even have a problem with draft-green-tls-static-dh-in-tls13 as a Standards-Track RFC. Not publishing doesn't prevent implementation reuse of ECDH keys, and publishing doesn't cause reuse of ECDH keys to be required. My only objection to publishing on the Standards-Track is that Informational seems much more appropriate given that the contents... is purely informative, lacking even a reference to RFC2119, much less normative RFC2119 keywords. Too much ado about nothing. The best solution here is for the authors to acknowledge the informative/non-normative nature of their I-D and take it to the ISE as an FYI. Done. Nico -- From nobody Tue Jul 11 16:59:58 2017 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 18ECF1276AF for ; Tue, 11 Jul 2017 16:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 InmsiufI_HbI for ; Tue, 11 Jul 2017 16:59:56 -0700 (PDT) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7626126C7A for ; Tue, 11 Jul 2017 16:59:55 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id q66so1108155qki.1 for ; Tue, 11 Jul 2017 16:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=YjsfEcYZnCL36i/ir9TQZYZ7/yu30zhsb2r0jjtka7c=; b=VRj1UhGZ144QQpFbVIORTmx4fUfybuGlYpyYk3+1TVbffbxBJqUypLs6i8we4BI/1V 8MSRO89DB7H71oOYO6Ljw7/gmrNBAuN2CqhhD4mjKUxSuXzPakm/WD6Qf/I1ZzUBHNnv sYWVmvKLnPLyOzZPelKxWe1pAirUlFosNU6WgOsylGg8FEK7IlloH0S7vIDvYUZT2UfE VR5suq4f9KsmooUjEBvNukZiRYivk/qUknuu+4q8RkYS83xBZXpRH0KkNSRY+tbEb3E/ jddv75cnyc8d0u9h/aBwJtamjfTejAG6QNk6gEzRPbu0U6gKjWfgEYMjSA1kkgkWnbW0 BETQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=YjsfEcYZnCL36i/ir9TQZYZ7/yu30zhsb2r0jjtka7c=; b=kIt61LQCGA2G3SlXIabvzN6jyu5gh7NnKGWkfBg+yofbaCoFYtcKGQMjzN23jHGf6Q PLEyRh317VNRrWSlrkasMGFGwjaZYAfKhiGOFjRYdxIZ/CF1/Sl9TH0QX18UbNATMGdt CiI1xCIGkNdanJThqCuVXSvIIB4Qdl7XpwGHKeaAvoXfamIczaj8Ci42QJEsFDtGjiDr hvXscEWKDpMC6o427/YkhE27ykSGfHkv33kinFXf/vkEc+x5RXnDcBcewI0qdWG7xElx 36QKDtdJwVz1jfPt5eT8L8axMxXLnD8N6rJ9Wko2eZlLiaGz11g5LY322Vr/lW/Wp5VM lqRA== X-Gm-Message-State: AIVw1110feMOKUF8WXkHVp/wnSYmpHo24kGksCqyTxPbVgLdpbe61QMz FjphiHrjXWdvkQ== X-Received: by 10.55.162.210 with SMTP id l201mr2944776qke.180.1499817595077; Tue, 11 Jul 2017 16:59:55 -0700 (PDT) Received: from [100.73.242.54] (236.sub-174-219-12.myvzw.com. [174.219.12.236]) by smtp.gmail.com with ESMTPSA id j65sm574114qkf.38.2017.07.11.16.59.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Jul 2017 16:59:54 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2F25802B-195C-47A9-8270-5EF487A1F925@gmail.com> Cc: "tls@ietf.org" X-Mailer: iPad Mail (11D201) From: Steve Fenter Date: Tue, 11 Jul 2017 18:59:55 -0500 To: Stephen Farrell Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2017 23:59:57 -0000 > On Jul 11, 2017, at 2:15 PM, Stephen Farrell w= rote: >=20 >=20 > To add to Ted's clarification requests: >=20 >> On 11/07/17 19:39, Steve Fenter wrote: >> Network security monitoring is not just monitoring traffic that >> results from communications with customers and partners. All it >> takes is for one user to click on a phishing email and there is >> malware inside the enterprise. Once this happens, TLS becomes the >> enemy, because 30% of malware is TLS encrypted, and any TLS features >> intended to thwart payload inspection work against the enterprise. >=20 > I'd appreciate a citation for that 30% figure. 30% came from Cisco Systems at a recent Cisco Live conference. Their number= s indicated 10% in 2015 and 30% today >=20 > And if you had one an estimate for how much malware does it's own > obfuscation or home-grown crypto in addition or instead of using TLS. > The reason to ask is that as soon as malware does that then you > are back to analysis based on ciphertext only. =46rom descriptions > of advanced attack schemes, they do seem to do both when calling > home or exfiltrating data. In which case I think your argument > falls. I don't have any numbers for home-grown crypto. I would think the odds are b= etter for the enterprise if they can decrypt and inspect whatever portion is= TLS. >=20 >> Malware does not always phone home out to the Internet on day 1 of >> infection. =20 >=20 > In what circumstance will malware phone home to a TLS server that > is playing your wiretap game? That seems utterly illogical but > maybe I'm missing a reason why someone's malware will use TLS to > talk to a server that is controlled by the victim network as part > of phoning home. Please clarify. Phone home would have to be caught by an inline solution on the way out the I= nternet. I was just suggesting that malware could be caught earlier in the p= rocess with multiple inspection points throughout the enterprise. >=20 > S. >=20 From nobody Tue Jul 11 17:27:51 2017 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 1A052131606 for ; Tue, 11 Jul 2017 17:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.802 X-Spam-Level: X-Spam-Status: No, score=-9.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, 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=ml.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 e1ymwBrp2PDn for ; Tue, 11 Jul 2017 17:27:47 -0700 (PDT) Received: from bankofamerica.com (rchemail.bankofamerica.com [171.159.227.167]) (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 EB83613181D for ; Tue, 11 Jul 2017 17:27:46 -0700 (PDT) Received: from vadmzmailmx05.bankofamerica.com ([171.182.203.230]) by lrcha0n0xepmx04.bankofamerica.com (8.15.1/8.14.5) with ESMTP id v6C0Rjgk028562 for ; Wed, 12 Jul 2017 00:27:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.com; s=corp1702; t=1499819265; bh=n/UND5zW26OY0RkmBtVJX+5pR373M0NYAxgcWBgIMKQ=; h=Date:From:Subject:In-reply-to:To:Message-id:MIME-version: Content-type:Content-transfer-encoding:References; b=W+3jiaY/3d3RAizUstLboVfYAtn7sMIdamHH4Fo6RnjAarFRcKlBZsLDPLOozYr9J vQwnpz0RdHy9rgUfNGE9Iw6k6P+n2Y9gvFUgW7iukGphp0ExEdr2W1XCMVE2kEJHPZ LMqyJQPwEQI/3PbWIb5l6JdPbFHFxBD8LvZpytH4= Received: from lrcha0n5xepmx12.bankofamerica.com (lrcha0n5xepmx12.bankofamerica.com [171.205.12.15]) by vadmzmailmx05.bankofamerica.com (8.15.1/8.14.5) with ESMTP id v6C0Rald008639 for ; Wed, 12 Jul 2017 00:27:45 GMT Date: Wed, 12 Jul 2017 00:27:40 +0000 From: "Eydlin, Igor - PENNINGTON NJ" In-reply-to: X-Originating-IP: [171.206.3.30] To: "tls@ietf.org" Message-id: <59A768ECCBC05D4CAD5C6A2EDDD8075188DCC8C4@smtp_mail.bankofamerica.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-language: en-US Content-transfer-encoding: 7BIT X-MS-Has-Attach: Accept-Language: en-US Thread-topic: TLS Digest, Vol 156, Issue 60 Thread-index: AQHS+pJgsDEI8CIo3UyfVGvTe8NuO6JPTCQg X-MS-TNEF-Correlator: x-bac-client-sensitivity: X1 References: X-Virus-Scanned: clamav-milter 0.98.7 at vadmzmailmx05.bankofamerica.com X-Virus-Status: Clean X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-11_13:, , signatures=0 Archived-At: Subject: Re: [TLS] TLS Digest, Vol 156, Issue 60 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 00:27:50 -0000 As a person that supports enterprise environments, I would like to make a few points towards supporting draft utilizing static DH keys inside of enterprise perimeters: * We need to support in-line and out of band TLS decryption in order to be able to fulfill our obligations to securely support our clients. We would have to utilize active application firewalls, IPs, IDS, End User Management and monitoring tools. * Supporting Monitoring, EUM, and Security horizontal and vertical traffic coverage inside of the DMZ would be almost impossible. In many cases relying on logs and application/ network alerts and alarms leaves many troubleshooting and monitoring aspects cumbersome and not reliable. * Men in the middle solution (such as proxy, accessibility fabrics/switches, load balancers sandwiches, ... ) adding additional processing time that would increase round trip time by 20 to over 100% (based on our internal benchmarks) That would lead to time X where X is number of application turns. How would users like it if their "favorite web site" had such an increase in response time during browsing? * On the public internet site, exploit client browsers could have a setting or warning to refuse such a TLS conversation to avoid static key usage as it was mentioned in previous communications. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of tls-request@ietf.org Sent: Tuesday, July 11, 2017 6:09 PM To: tls@ietf.org Subject: TLS Digest, Vol 156, Issue 60 Send TLS mailing list submissions to tls@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=obUyEFMB40U1YA3Vm8KOBQKwd4VQax8zip_AAct0jvk&e= or, via email, send a message with subject or body 'help' to tls-request@ietf.org You can reach the person managing the list at tls-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TLS digest..." Today's Topics: 1. Re: chairs - please shutdown wiretapping discussion... (Ted Lemon) 2. Re: chairs - please shutdown wiretapping discussion... (Stephen Farrell) 3. Re: chairs - please shutdown wiretapping discussion... (Yoav Nir) ---------------------------------------------------------------------- Message: 1 Date: Tue, 11 Jul 2017 17:16:31 -0400 From: Ted Lemon To: Stephen Farrell Cc: Christian Huitema , tls@ietf.org Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: Content-Type: text/plain; charset="utf-8" On Jul 11, 2017, at 4:58 PM, Ted Lemon wrote: > On Jul 11, 2017, at 4:31 PM, Stephen Farrell > wrote: >> I'd bet folks would invent proprietary >> ways of avoiding detection, that deviate from the "standard" >> and that perhaps make crypto worse all around. Say by deriving >> secrets from some function f(exfiltrated-secret, time, count) >> for a small counter or some such and having the decryptor of >> the wiretapped packets hunt a bit for the right key. > > Hm, well, but that would be catnip for security researchers, particularly if it weakened the key. But yeah, you're right, that does make detecting the attack possibly impractical aside from as a large research project. On second thought, this suffers from the same problem as the many-static-keys problem: there are too many moving parts. This requires all clocks on all servers and interceptors to be in perfect sync, not just close, or else potentially halves the performance during clock skew overlap periods. It requires every server and interceptor to implement the same algorithm. And you still have to distribute the information from which the key is derived. So again, yes, you can do this particular mitigation strategy. But it's expensive, and so nobody's going to do it if they have a better choice. It's cheaper to just re-tool to support TLS 1.3. As long as the solution isn't standard, it's only going to appeal to a _very_ limited audience, if there's any audience for it at all. E.g., consider trying to deploy something like this on a country-wide scale. You're just going to exfiltrate every key instead?it's cheaper. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 11 Jul 2017 22:21:15 +0100 From: Stephen Farrell To: Yoav Nir , Christian Huitema Cc: Ted Lemon , tls@ietf.org Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: <104f5108-751a-c8f5-45dc-bf5d7be26f35@cs.tcd.ie> Content-Type: text/plain; charset="utf-8" On 11/07/17 22:10, Yoav Nir wrote: > If one of the parties to a conversation cooperates with the wiretap, > this isn?t an attack. Lemme try on this one again from a different angle. In classic telephony wiretaps the carrier does the tap. There are similar situations with TLS... In hosted platforms (e.g. wordpress.com and many others) where the senders and receivers (or publishers & readers) have read and write access via PHP code and not via a shell, and cannot therefore control web or TLS configuration, the platform would be doing a wiretap if it turned this on, whilst colluding with or being coerced by some other entity that collects and later decrypts the ciphertext and packets. Are we agreed that that use-case is wiretapping via this mechanism? There are many millions of people who use such constrained hosted environments. Cheers, S. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: ------------------------------ Message: 3 Date: Wed, 12 Jul 2017 01:09:02 +0300 From: Yoav Nir To: Stephen Farrell Cc: Christian Huitema , Ted Lemon , TLS WG Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: Content-Type: text/plain; charset="utf-8" > On 12 Jul 2017, at 0:21, Stephen Farrell wrote: > > > > On 11/07/17 22:10, Yoav Nir wrote: >> If one of the parties to a conversation cooperates with the wiretap, >> this isn?t an attack. > Lemme try on this one again from a different angle. > > In classic telephony wiretaps the carrier does the > tap. There are similar situations with TLS... > > In hosted platforms (e.g. wordpress.com and many > others) where the senders and receivers (or publishers > & readers) have read and write access via PHP code > and not via a shell, and cannot therefore control web > or TLS configuration, the platform would be doing a > wiretap if it turned this on, whilst colluding with > or being coerced by some other entity that collects > and later decrypts the ciphertext and packets. > > Are we agreed that that use-case is wiretapping via > this mechanism? > > There are many millions of people who use such > constrained hosted environments. Wordpress.com is a party to the session. It has access to the plaintext and could deliver it to whatever third party whenever they wanted. This draft may be an optimization, but the plaintext was always theirs to give. I might be deluding myself that I?m sending this email to you over TLS. In fact I?m only uploading it to gmail.com who will forward it to TCD?s server. Both servers will have access to the plaintext. Both servers can send it to a third party, or share session keys or share ECDHE private keys. Whether one party to a conversation (phone or IP) has the right to share private contents with a third party is a legal matter that varies from country to country and from state to state. I only claim that this draft does not change the fact that is true for PFS suites in TLS 1.x and for all suites in TLS 1.3, that it?s impossible to decrypt a recorded session without cooperation from either party, and that cooperation has to start *before* the session is recorded. That is not the case for POTS wiretap or for the RSA key exchange. Yoav -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP URL: ------------------------------ Subject: Digest Footer _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=obUyEFMB40U1YA3Vm8KOBQKwd4VQax8zip_AAct0jvk&e= ------------------------------ End of TLS Digest, Vol 156, Issue 60 ************************************ ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. From nobody Tue Jul 11 17:42:52 2017 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 CD782131705 for ; Tue, 11 Jul 2017 17:42:49 -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 5ZZ982E7sosF for ; Tue, 11 Jul 2017 17:42:48 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566E113181E for ; Tue, 11 Jul 2017 17:42:48 -0700 (PDT) Received: from [47.143.125.207] (helo=Williams-MacBook-Pro.local) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1dV5jq-0006zr-Vn for tls@ietf.org; Tue, 11 Jul 2017 20:42:47 -0400 Date: Tue, 11 Jul 2017 17:42:47 -0700 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <340c77ed-ad4a-98cd-7b90-b372f665a26a@cs.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79d5084e92f929c64ac9c6b4f05d0e24fa350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.207 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 00:42:50 -0000 I must admit that I mostly agree with Stephan that this kind of=20 thing should not exist. However, it exists now, and the chairs=20 have decided we should at least discuss it. I think there are many ways to meet the "requirements" of=20 network monitoring and protocol debugging, and some are worse=20 than others. Leading the world in the direction of the least=20 damaging ones seems to be the bese way to deal with a bad situation. The major threats I see include: Coerced use by oppressive governments. Use outside the immediate private network Use by an ISP on its customers Use without both ends being aware that it is in use. I think coerced use is by oppressive governments is an obvious=20 bad and I hope I have working group agreement on this point. Limiting the protocol to the immediate private network will=20 prevent 3rd parties from activating it to spy on the enterprise.=20 One possible way to enforce this limitation is to require=20 compliant implementations to limit broadcast of decryption=20 information to the IP addresses on the local subnet. I would be nice to be able to keep an ISP from spying on its=20 customers as part of its "private network". However, I don't see=20 how to differentiate an ISP's network from a enterprise network. If it is not technically possible to use the protocol without=20 both ends being aware that it is in use, then user interfaces=20 can reflect its use. One result would be that enterprise users=20 would be continually warned that their messages aren't private. Any technical fixes we build into the protocol that prevent=20 these actions are a positive improvement. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz | If you want total security, go to prison.=20 There you're 408-356-8506 | fed, clothed, given medical care and so on.=20 The only www.pwpconsult.com | thing lacking is freedom. - Dwight D. Eisenhower From nobody Tue Jul 11 18:22:25 2017 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 67AC712EC1B for ; Tue, 11 Jul 2017 18:22:24 -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=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 tgFdZQDobRyy for ; Tue, 11 Jul 2017 18:22:21 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 615EB126D73 for ; Tue, 11 Jul 2017 18:22:21 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id q85so4505259pfq.1 for ; Tue, 11 Jul 2017 18:22:21 -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=l3WWieATL/ScM+ZzQsQiaXRS38+67et2/F4U0D8aE30=; b=Uo14x4Do88q8+Y3t6Szw/gs9Vh9GELZ1hgeCKtWluMheaeRm3EZNIBdX0nRlCikK6o Kkh4Ofah2PcLSuBzYlv+8foXYeafAu/O0eFEyCwanITgspR6mSUzXwxU9q3HI0rRzFVI 2OeR6ohnmNCnmQ80g7FlYjlaudUGMHK65l/YY/qd4q2Bnmqr9/tzUaRGLEkMDFFGeE1b Wjh4Wxbym5ijV3MVJF1abWW/iATd+bXBw7W0hlkJIna+bC+LEsw3x7V7UqWfadrksVFx /+ilZ/N7Xy3eXej7iK8pJpMQ4fVSaPgZJsMs2Us7T6/aexpk7KZgPrhmztx6jYxQWorj 8f+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l3WWieATL/ScM+ZzQsQiaXRS38+67et2/F4U0D8aE30=; b=keriNoRhFpatMg7rVThO9s29uOJuCcEzXAqdRQXUXnUUjSaF3ClKB2rLDLXG/azM// wOnC7eahU2CwI0gNUgJ9gk7FNB6T+XDoQxyTNz0IeK9SmDG9jkDLT3Dw+dTiRzrnabTK 0bWatTzJMTufju8jCO/AehiyABQnew2PhT/LV+GCn/9DTYPiWUnTHhA5qdFJorOTcNwm 9HkgYf1t3YDNFDy6tHod0xc+yva3eyDh2selJ8HhHYHaT1tQDn6v6YpIGxJqkgqQMzmW DqLnVSCNNwav+X3OqZLIWIvvifADfetdHqO0r4t1cn/x+W2Y5UV0p9ybS7zeR5S777Cy yzAQ== X-Gm-Message-State: AIVw112W3i5/SaDhQ4+HV3BEfGJVD8m7QLs2vbcpUGJ6DKM1ZmexePtr f1usNK6/ozk7+Dw28dAvNIrfQHRAatTK X-Received: by 10.84.192.131 with SMTP id c3mr1409573pld.9.1499822541038; Tue, 11 Jul 2017 18:22:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.170.2 with HTTP; Tue, 11 Jul 2017 18:21:40 -0700 (PDT) In-Reply-To: <2F25802B-195C-47A9-8270-5EF487A1F925@gmail.com> References: <2F25802B-195C-47A9-8270-5EF487A1F925@gmail.com> From: Ted Lemon Date: Tue, 11 Jul 2017 21:21:40 -0400 Message-ID: To: Steve Fenter Cc: Stephen Farrell , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c189e98c8fe6a055414a5fe" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 01:22:24 -0000 --94eb2c189e98c8fe6a055414a5fe Content-Type: text/plain; charset="UTF-8" To paraphrase (and forgive me for being a bit brutal here), you have no basis for what you said other than handwaves and something from a Cisco marketing presentation? That is, "the odds are better if..." is a handwave, and not clearly true. "Malware could be caught ... with multiple inspection points..." is only true if those inspection points are able to detect the malware. Phoning home is actually pretty detectable using DNS snooping--you don't need deep packet inspection, and it's orders of magnitude cheaper. On Tue, Jul 11, 2017 at 7:59 PM, Steve Fenter wrote: > > > > On Jul 11, 2017, at 2:15 PM, Stephen Farrell > wrote: > > > > > > To add to Ted's clarification requests: > > > >> On 11/07/17 19:39, Steve Fenter wrote: > >> Network security monitoring is not just monitoring traffic that > >> results from communications with customers and partners. All it > >> takes is for one user to click on a phishing email and there is > >> malware inside the enterprise. Once this happens, TLS becomes the > >> enemy, because 30% of malware is TLS encrypted, and any TLS features > >> intended to thwart payload inspection work against the enterprise. > > > > I'd appreciate a citation for that 30% figure. > > 30% came from Cisco Systems at a recent Cisco Live conference. Their > numbers indicated 10% in 2015 and 30% today > > > > And if you had one an estimate for how much malware does it's own > > obfuscation or home-grown crypto in addition or instead of using TLS. > > The reason to ask is that as soon as malware does that then you > > are back to analysis based on ciphertext only. From descriptions > > of advanced attack schemes, they do seem to do both when calling > > home or exfiltrating data. In which case I think your argument > > falls. > > I don't have any numbers for home-grown crypto. I would think the odds > are better for the enterprise if they can decrypt and inspect whatever > portion is TLS. > > > >> Malware does not always phone home out to the Internet on day 1 of > >> infection. > > > > In what circumstance will malware phone home to a TLS server that > > is playing your wiretap game? That seems utterly illogical but > > maybe I'm missing a reason why someone's malware will use TLS to > > talk to a server that is controlled by the victim network as part > > of phoning home. Please clarify. > > Phone home would have to be caught by an inline solution on the way out > the Internet. I was just suggesting that malware could be caught earlier > in the process with multiple inspection points throughout the enterprise. > > > > S. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c189e98c8fe6a055414a5fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To paraphrase (and forgive me for being a bit brutal here)= , you have no basis for what you said other than handwaves and something fr= om a Cisco marketing presentation?

That is, "the od= ds are better if..." is a handwave, and not clearly true. =C2=A0 "= ;Malware could be caught ... with multiple inspection points..." is on= ly true if those inspection points are able to detect the malware. =C2=A0 P= honing home is actually pretty detectable using DNS snooping--you don't= need deep packet inspection, and it's orders of magnitude cheaper.

On Tue, J= ul 11, 2017 at 7:59 PM, Steve Fenter <steven.fenter58@gmail.com> wrote:


> On Jul 11, 2017, at 2:15 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>
> To add to Ted's clarification requests:
>
>> On 11/07/17 19:39, Steve Fenter wrote:
>> Network security monitoring is not just monitoring traffic that >> results from communications with customers and partners.=C2=A0 All= it
>> takes is for one user to click on a phishing email and there is >> malware inside the enterprise.=C2=A0 Once this happens, TLS become= s the
>> enemy, because 30% of malware is TLS encrypted, and any TLS featur= es
>> intended to thwart payload inspection work against the enterprise.=
>
> I'd appreciate a citation for that 30% figure.

30% came from Cisco Systems at a recent Cisco Live conference.=C2=A0= Their numbers indicated 10% in 2015 and 30% today
>
> And if you had one an estimate for how much malware does it's own<= br> > obfuscation or home-grown crypto in addition or instead of using TLS.<= br> > The reason to ask is that as soon as malware does that then you
> are back to analysis based on ciphertext only. From descriptions
> of advanced attack schemes, they do seem to do both when calling
> home or exfiltrating data. In which case I think your argument
> falls.

I don't have any numbers for home-grown crypto.=C2=A0 I would th= ink the odds are better for the enterprise if they can decrypt and inspect = whatever portion is TLS.
>
>> Malware does not always phone home out to the Internet on day 1 of=
>> infection.
>
> In what circumstance will malware phone home to a TLS server that
> is playing your wiretap game? That seems utterly illogical but
> maybe I'm missing a reason why someone's malware will use TLS = to
> talk to a server that is controlled by the victim network as part
> of phoning home. Please clarify.

Phone home would have to be caught by an inline solution on the way = out the Internet.=C2=A0 I was just suggesting that malware could be caught = earlier in the process with multiple inspection points throughout the enter= prise.
>
> S.
>

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

--94eb2c189e98c8fe6a055414a5fe-- From nobody Tue Jul 11 18:39:28 2017 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 5169512EC46 for ; Tue, 11 Jul 2017 18: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 Wq4vN1CuPIbT for ; Tue, 11 Jul 2017 18:39:26 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF9512F287 for ; Tue, 11 Jul 2017 18:39:26 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id h64so5076620iod.0 for ; Tue, 11 Jul 2017 18:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EVcny16ck/u61FZw/tVHVs7exX7JMFMTBNoibU9lEVY=; b=j3KAQJaBhdadNyiZKUed/p+3W7/1eCLqV1K9pba1qRAoVeOTdpn9khnJYXGSwh8ywg +cTuFhkYNYNcEkF+TQg0kogFK8YNC9/qJMevWzXLo7f3VCQniPtr/hAyvhrFPyB9R+Qh 99nUeUhf/gISRR+Rowm2teCNOhPvLi3oZ4i0dB5UVhFtQltfkoptDRiTTOh3gKx73HYN P7+/DpI0DV3m7MJeX5nezgc9CvQFdvSn1lEfIzEEVs572QEbJq58ClULbNMBWd5zktW8 WYA1ETfy3JZcWDcCifE10QaXYnQmAmT5V1s0u+gubUNRoiNo1DkRhbCT9ksZTQuH9PIs aiFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EVcny16ck/u61FZw/tVHVs7exX7JMFMTBNoibU9lEVY=; b=UbdRR1EP/BTFHlslwFCj1Oyor/6jMxewgJjv0Yu02dvMOlckpGJdXoDuGFk0nINRya nwbk2AwHbufK6939/ylebIQTMFzMXd2ts4QHB2xknc10wkSXRkr0bXh2/RFLJk4I5Izk 4VYWPlt/dyGDgmIGw8rll4H4fuQv7tKKUwiUfUKjwsULFc6WlhZuCh/N7YH9uJ3BIMnE XU1oL/amac/BfD7Jk0hVoRThXDBTw+JBwO4Av/gRAHzyu4MDQraaxveX66bTCMlT+Qg9 aJUbyKf5OMTKFJz8e26DwQZgm3jkQO33dZSgkOHQYtlQNBaqnC/tRxK20h+oO+dArtTj 8aaQ== X-Gm-Message-State: AIVw110FvGmG2tfJj3eGHX6EXgONWN5pW7caM6657Q9qJQha4tCB7oGp sO8PPwRGj+1C6yT8P2ZTkDKpUrVwFQ== X-Received: by 10.107.39.205 with SMTP id n196mr2978110ion.37.1499823565524; Tue, 11 Jul 2017 18:39:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Tue, 11 Jul 2017 18:39:24 -0700 (PDT) In-Reply-To: <2F25802B-195C-47A9-8270-5EF487A1F925@gmail.com> References: <2F25802B-195C-47A9-8270-5EF487A1F925@gmail.com> From: Martin Thomson Date: Wed, 12 Jul 2017 11:39:24 +1000 Message-ID: To: Steve Fenter Cc: Stephen Farrell , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 01:39:27 -0000 On 12 July 2017 at 09:59, Steve Fenter wrote: >> And if you had one an estimate for how much malware does it's own >> obfuscation or home-grown crypto in addition or instead of using TLS. >> The reason to ask is that as soon as malware does that then you >> are back to analysis based on ciphertext only. From descriptions >> of advanced attack schemes, they do seem to do both when calling >> home or exfiltrating data. In which case I think your argument >> falls. > > I don't have any numbers for home-grown crypto. I would think the odds are better for the enterprise if they can decrypt and inspect whatever portion is TLS. Wouldn't malware avoid connecting to servers that offer the wrong credentials? Implementing elementary key pinning or overriding trust anchors is pretty trivial - it's a feature that enterprises frequently rely on after all. From nobody Wed Jul 12 01:53:16 2017 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 4416412EC3B for ; Wed, 12 Jul 2017 01:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobileironinc.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 ptK9CRyiNUO3 for ; Wed, 12 Jul 2017 01:53:10 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0054.outbound.protection.outlook.com [104.47.37.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32B712708C for ; Wed, 12 Jul 2017 01:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OMneTC90MYQsUru3FYYTd9XIfpgbv8ZKthRhcivk11U=; b=rWJBjWq5LzmuYCpPTmCP0m29kawNeGB8Z80gD3x4u2f4RwLrxBKmS6Ez4+WqCrzAOugTbh7ZyZvICoMtKlFW11VUIFm0bjkz7jMC8GQtU/yDQ/C1wKE9ZGOzqXipNjofrii6QciYPJDO3jjWmUUBkvECl1pc3XHHAd2Sgkb2eyc= Received: from CY4PR10MB1734.namprd10.prod.outlook.com (10.172.69.9) by CY4PR10MB1735.namprd10.prod.outlook.com (10.172.69.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Wed, 12 Jul 2017 08:53:09 +0000 Received: from CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) by CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) with mapi id 15.01.1240.020; Wed, 12 Jul 2017 08:53:09 +0000 From: Timothy Jackson To: Bill Frantz , "tls@ietf.org" Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion... Thread-Index: AQHS+YQIIMr3b+F8O0+nlKMGCO8wcKJNL/oAgABE5ACAAAwtgIAAD9QAgAAChYCAAAJwgIAA4XWAgAAd/4CAAAYnAIAAZHCAgAAIVICAAAIXAIAAAyWAgAABLICAAAevgIAABoEAgAAEgYCAAALtgIAADVkAgAABpYCAAClRgIAAiQJv Date: Wed, 12 Jul 2017 08:53:09 +0000 Message-ID: References: <340c77ed-ad4a-98cd-7b90-b372f665a26a@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pwpconsult.com; dkim=none (message not signed) header.d=none;pwpconsult.com; dmarc=none action=none header.from=mobileiron.com; x-originating-ip: [204.8.168.222] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR10MB1735; 7:3J2QLa4ivt3PUq3+xmFxRCMdvWah99xyyQNRzhIawhdvU0AJ3dAzYbhsIz94Byer2pJFeiPpwQTtBdY7+IuESW3fGL2hp7Zj/ObdePe+7WZPiIGN3ZSZ42cqih5DFvHuZC8q8wyD9PKyDY5O/5c3iYfwOQMUfcQr59ia2Qx3e7fc3/tZoLLYE3F1VyeW4jqJvFxo3UEu6vSKZo4R92AMOtn2AKKKmsIUGNLG89sV6IEDMxzXkLPDFOx1luiF2jr6IleAvtbP8TzyQXMM7QhlaKLu0RePsdA4Kfje4XxMA9AJW8c1/iv+57wj1mZmhGq2XJH9rBcDj8P/M8sJvH+fVvv7V6OdIFpcyw2b/mI7Utv3glm1YbIi4LeNFWxBd+IkIsMr+UH8pAd6RZ+mL+vEw2nFb63PQur7ZnopLBjhw5EVgVbkLgtHFwmzbvXHYp9V/NO2nFsxi5NkNlUxlIxrZGsVC/PmGfb1tMR+hpKH1vY1yWGo3eeOE26gxOd91o4DA7PV4RQBFSXa5uJi1fU45SO/pmjIb8aRCVuWcH53pQkgMYsvrpSR3FizA6yVaYKIxfoF+RgEjLOzHWIUNyDZaZ/vrXX379MfYvnDawvVe0cvu88pMWwSUvN1HU/bpuch9iyM84rNbSA6xD0rUEIwxQVO1sUREndZS4oTNLoIMoh2bYUYFjx1gG3CMeJrr1Uudwq+bVZuyMHJ3FrHYZqKkWuHk9d2z7gMi57hC95Uni6bs/UTSfMTEzme/waNzOvn9Q0DdBNySlc8XOwKjsYXAuOllR3eUo0aIp1bQPufW/E= x-ms-office365-filtering-correlation-id: 5a9d3d1a-456f-471d-064d-08d4c9036bc7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR10MB1735; x-ms-traffictypediagnostic: CY4PR10MB1735: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(26388249023172)(236129657087228)(192374486261705)(148574349560750)(247924648384137)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR10MB1735; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR10MB1735; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39850400002)(39400400002)(39410400002)(39840400002)(377454003)(66066001)(189998001)(86362001)(3660700001)(7736002)(3280700002)(2900100001)(5660300001)(76176999)(50986999)(54356999)(8936002)(2906002)(14454004)(81166006)(33646002)(95246002)(25786009)(53546010)(8676002)(1680700002)(38730400002)(6116002)(102836003)(478600001)(53386004)(6506006)(3846002)(6436002)(229853002)(236005)(51650200002)(606006)(54896002)(966005)(99286003)(77096006)(53936002)(6512007)(6306002)(6486002)(2501003)(2950100002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR10MB1735; H:CY4PR10MB1734.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_pabvkvrnfltgqkgt51u2b2ek1499849588747emailplusmobileiro_" MIME-Version: 1.0 X-OriginatorOrg: mobileiron.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2017 08:53:09.4810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1735 Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 08:53:15 -0000 --_000_pabvkvrnfltgqkgt51u2b2ek1499849588747emailplusmobileiro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bill, I agree that we need to find the "least bad" option, if for no other reason= than to prove there is no acceptable solution. If I may, I'd like to sugge= st another possible way to get to "least bad". Perhaps our goal should not be to prevent servers collaborating with the mo= nitoring, which we can't actually do anyway, but rather to ensure both side= s to know when this is happening. This will give clients the opportunity to= decide whether or not to allow it. A few people have started down this pat= h on this thread. One can imagine a few ways to approach this (these are examples to get peop= le thinking and admittedly aren't fully baked, so be nice ;-) ) 1. Define a new ciphersuite(s) explicitly for this purpose. Call it TLS_ECD= HE_RSA_WITH_AES128_GCM_SHA256_MON(itor) or whatever. This would make it obv= ious what's happening and the client can choose to enable or disable such c= ipher suites. Browser/OS vendors might let users/admins enable these cipher= suites for local network connections and disable them for connections to t= he wider internet. 2. Include something in the server's certificate (a new X509 extension or t= he static ECDH key perhaps?) as a signal to the client that the server is e= nabling monitoring. Again, this can be allowed for connections within an or= ganization but potentially blocked for connections to external networks. 3. Use a 3-party handshake. As I recall, there are three party versions of = RSA and DH (Joux, 2000) and at least progress on making 3-party ECDH work b= ased on Ben Lynn's work. (I haven't checked to see what the latest status o= n this is.) This probably becomes an extension and possibly some newly defi= ned cipher suites as well. There may be any number of other solutions, this isn't meant to be an exhau= stive list, just get people thinking. Because this request is so specialize= d (monitoring inside an enterprise), it seems reasonable to me that the sol= ution can be non-generalizable to the internet at large. In fact, that's pr= obably a desired trait. Therefore, the use of custom ciphersuites, extensio= ns or the like may be viable, since both ends of the connection are ostensi= bly under the control of the enterprise. (I'm sure BITS et al will speak up= if they disagree.) Cheers, Tim -- Tim Jackson Senior Product Security Architect ________________________________ From: "Bill Frantz" > Date: Tuesday, July 11, 2017 at 5:43:03 PM To: "tls@ietf.org" > Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... I must admit that I mostly agree with Stephan that this kind of thing should not exist. However, it exists now, and the chairs have decided we should at least discuss it. I think there are many ways to meet the "requirements" of network monitoring and protocol debugging, and some are worse than others. Leading the world in the direction of the least damaging ones seems to be the bese way to deal with a bad situation. The major threats I see include: Coerced use by oppressive governments. Use outside the immediate private network Use by an ISP on its customers Use without both ends being aware that it is in use. I think coerced use is by oppressive governments is an obvious bad and I hope I have working group agreement on this point. Limiting the protocol to the immediate private network will prevent 3rd parties from activating it to spy on the enterprise. One possible way to enforce this limitation is to require compliant implementations to limit broadcast of decryption information to the IP addresses on the local subnet. I would be nice to be able to keep an ISP from spying on its customers as part of its "private network". However, I don't see how to differentiate an ISP's network from a enterprise network. If it is not technically possible to use the protocol without both ends being aware that it is in use, then user interfaces can reflect its use. One result would be that enterprise users would be continually warned that their messages aren't private. Any technical fixes we build into the protocol that prevent these actions are a positive improvement. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz | If you want total security, go to prison. There you're 408-356-8506 | fed, clothed, given medical care and so on. The only www.pwpconsult.com | thing lacking is freedom. -= Dwight D. Eisenhower _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_pabvkvrnfltgqkgt51u2b2ek1499849588747emailplusmobileiro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bill,

I agree that we need to find the "least bad" option, if for no ot= her reason than to prove there is no acceptable solution. If I may, I'd lik= e to suggest another possible way to get to "least bad".

Perhaps our goal should not be to prevent servers collaborating with the mo= nitoring, which we can't actually do anyway, but rather to ensure both side= s to know when this is happening. This will give clients the opportunity to= decide whether or not to allow it. A few people have started down this path on this thread.

One can imagine a few ways to approach this (these are examples to get peop= le thinking and admittedly aren't fully baked, so be nice ;-) )
1. Define a new ciphersuite(s) explicitly for this purpose. Call it TLS_ECD= HE_RSA_WITH_AES128_GCM_SHA256_MON(itor) or whatever. This would make it obv= ious what's happening and the client can choose to enable or disable such c= ipher suites. Browser/OS vendors might let users/admins enable these cipher suites for local network connec= tions and disable them for connections to the wider internet.
2. Include something in the server's certificate (a new X509 extension or t= he static ECDH key perhaps?) as a signal to the client that the server is e= nabling monitoring. Again, this can be allowed for connections within an or= ganization but potentially blocked for connections to external networks.
3. Use a 3-party handshake. As I recall, there are three party versions of = RSA and DH (Joux, 2000) and at least progress on making 3-party ECDH work b= ased on Ben Lynn's work. (I haven't checked to see what the latest status o= n this is.) This probably becomes an extension and possibly some newly defined cipher suites as well.

There may be any number of other solutions, this isn't meant to be an exhau= stive list, just get people thinking. Because this request is so specialize= d (monitoring inside an enterprise), it seems reasonable to me that the sol= ution can be non-generalizable to the internet at large. In fact, that's probably a desired trait. Therefore= , the use of custom ciphersuites, extensions or the like may be viable, sin= ce both ends of the connection are ostensibly under the control of the ente= rprise. (I'm sure BITS et al will speak up if they disagree.)

Cheers,

Tim
--
Tim Jackson
Senior Product Security Architect


From: "Bill Frantz" <frantz@pwpconsult.com>
Date: Tuesday, July 11, 2017 at 5:43:03 PM
To: "tls@ietf.org" <tls= @ietf.org>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion..= .

I must admit that I mostly agree with Stephan that= this kind of
thing should not exist. However, it exists now, and the chairs
have decided we should at least discuss it.

I think there are many ways to meet the "requirements" of
network monitoring and protocol debugging, and some are worse
than others. Leading the world in the direction of the least
damaging ones seems to be the bese way to deal with a bad situation.

The major threats I see include:

   Coerced use by oppressive governments.

   Use outside the immediate private network

   Use by an ISP on its customers

   Use without both ends being aware that it is in use.

I think coerced use is by oppressive governments is an obvious
bad and I hope I have working group agreement on this point.

Limiting the protocol to the immediate private network will
prevent 3rd parties from activating it to spy on the enterprise.
One possible way to enforce this limitation is to require
compliant implementations to limit broadcast of decryption
information to the IP addresses on the local subnet.

I would be nice to be able to keep an ISP from spying on its
customers as part of its "private network". However, I don't see =
how to differentiate an ISP's network from a enterprise network.

If it is not technically possible to use the protocol without
both ends being aware that it is in use, then user interfaces
can reflect its use. One result would be that enterprise users
would be continually warned that their messages aren't private.

Any technical fixes we build into the protocol that prevent
these actions are a positive improvement.

Cheers - Bill

---------------------------------------------------------------------------=
Bill Frantz        | If you want total s= ecurity, go to prison.
There you're
408-356-8506       | fed, clothed, given medi= cal care and so on.
The only
www.pwpconsult.com | thing lackin= g is freedom. - Dwight D. Eisenhower

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
 --_000_pabvkvrnfltgqkgt51u2b2ek1499849588747emailplusmobileiro_-- From nobody Wed Jul 12 05:24:30 2017 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 A82A4131690 for ; Wed, 12 Jul 2017 05:24: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, 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 mBn7JlaHWceB for ; Wed, 12 Jul 2017 05:24:26 -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 27DFA12EC30 for ; Wed, 12 Jul 2017 05:24:26 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id 16so20218095qkg.2 for ; Wed, 12 Jul 2017 05:24:26 -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=pg6Puo3fjGe/fYzESalEACdZ0KaVRNYLVb1+sUaueXQ=; b=oIWBzzywum0NiSjdLAl07hwZuvjr+GtZ9aAKNIvqjZamcxr7t3TtV0TQTN1Kxf2hty ZPmiq8qCFz9Xw8AlKTHDIrWyRWyRxla5Fowt6SXu8wxVOilLjqmqkIYbeyvkm9z4e1Lf ve409bpdArM/cYF9eA0Jvf8xmfPBjt2tctM2I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pg6Puo3fjGe/fYzESalEACdZ0KaVRNYLVb1+sUaueXQ=; b=o+OAEXIbb6tLfa9hAV0j/nLE6AH/vZB6cEu959D6CNlmxDy2z6QpQNAspfl8brMqal x6RzO61id233iNuFtVAxcYO1HmzDGHmbD/aqy/QkJHgCkzazRz8ebFacvK393+aa9Ykj OEJiduz9W3PbXqANN6spGf6v1yQPs15izwYopo7XnXeE8E89hfOnRWHU1NAC+uiHTkKw cWm26gkb4msVAN9nqsJ1yIcF6L6/XLsSzTms5S9qtxsGn4Hk17jIZJd+g/gdFUmzmk1R pVnTEVWe9N19CFcCc9g6z4HVU47wAA9tXVIxTqcy0DelCvfk+AmKdYBHo3WA+2H9Ksua jHsg== X-Gm-Message-State: AIVw112UM4APHJrOEUj2iWdCa0YGMq4XadWajJ2d9GSEg6ln5r9tDMr5 AaK2UiULBtcjwiSARUUYgzwp7qB5NWtf X-Received: by 10.55.97.13 with SMTP id v13mr5464104qkb.107.1499862265143; Wed, 12 Jul 2017 05:24:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Wed, 12 Jul 2017 05:24:24 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:5cb5:ecff:fe89:28ca] In-Reply-To: <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> From: Kyle Rose Date: Wed, 12 Jul 2017 08:24:24 -0400 Message-ID: To: Ted Lemon Cc: Stephen Farrell , "Polk, Tim (Fed)" , IETF TLS Content-Type: multipart/alternative; boundary="94eb2c05760686b79905541de5e5" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 12:24:29 -0000 --94eb2c05760686b79905541de5e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 11, 2017 at 9:11 AM, Ted Lemon wrote: > It=E2=80=99s also true that you can just exfiltrate every key as it=E2=80= =99s generated, > but that=E2=80=99s not what=E2=80=99s being proposed and would not, I thi= nk, suit the needs > of the operators who are making this proposal. > > I don=E2=80=99t see how you could mitigate against deliberate key exfiltr= ation. > At some point you really are relying on the security of the endpoint. > But being able to detect repeated keys is useful for preventing pervasiv= e > monitoring: it requires the monitored either to have access to the key > generation stream in realtime, or to request the key for a particular > conversation. > Much of this conversation seems to conflate wiretapping with collaboration. 2804 has a clear definition of wiretapping: q( Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a third party: 1. Without the sending party knowing about the third party 2. Without any of the recipient parties knowing about the delivery to the third party 3. When the normal expectation of the sender is that the transmitted information will only be seen by the recipient parties or parties obliged to keep the information in confidence 4. When the third party acts deliberately to target the transmission of the first party, either because he is of interest, or because the second party's reception is of interest. ) This proposal (and related proposals involving encrypting session keys to inspection boxes, either in-band or OOB) violates condition 2 because one endpoint would have to intentionally take action to deliver the session key or private DH share to the third party. If one endpoint is feeding cryptographic material to a third party (the only way that information gets out to the third party, vulnerabilities notwithstanding), they are collaborating, not enabling wiretapping. (I'd argue the inspection box also fails to be a third party, as it is part of the infrastructure of one endpoint, but that's largely irrelevant to the question of whether this is wiretapping once we've determined the delivery of keys is not a secret.) I think this issue of static DH being an attack (maybe; not taking a position) is something of a red herring, because shipping individual session keys to a third party like a government doesn't add any substantive hurdle beyond shipping them a single static DH share. That said, I agree that an infrastructure for detecting the loss of forward secrecy, perhaps in a CT-like manner, may make sense to protect against unintentional key compromise or compromise of one endpoint: the problems that forward secrecy is intended to address, which specifically do *not* include collaboration. Kyle --94eb2c05760686b79905541de5e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 11, 2017 at 9:11 AM, Ted Lemon <mellon@fugue.c= om> wrote:
It=E2=80=99s also = true that you can just exfiltrate every key as it=E2=80=99s generated, but = that=E2=80=99s not what=E2=80=99s being proposed and would not, I think, su= it the needs of the operators who are making this proposal.

I don=E2=80=99t see how you could mitigate against deliberate key exfiltrat= ion.=C2=A0 =C2=A0At some point you really are relying on the security of th= e endpoint.=C2=A0 =C2=A0But being able to detect repeated keys is useful fo= r preventing pervasive monitoring: it requires the monitored either to have= access to the key generation stream in realtime, or to request the key for= a particular conversation.

Much of this conv= ersation seems to conflate wiretapping with collaboration. 2804 has a clear= definition of wiretapping:

q( Wiretapping is what occurs= when information passed across the
=C2=A0=C2=A0 Internet from one party= to one or more other parties is delivered to
=C2=A0=C2=A0 a third party= :

=C2=A0=C2=A0 1. Without the sending party knowing about the third = party

=C2=A0=C2=A0 2. Without any of the recipient parties knowing a= bout the delivery to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the third party
<= br>=C2=A0=C2=A0 3. When the normal expectation of the sender is that the tr= ansmitted
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information will only be seen b= y the recipient parties or parties
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 oblige= d to keep the information in confidence

=C2=A0=C2=A0 4. When the thi= rd party acts deliberately to target the transmission
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 of the first party, either because he is of interest, or becau= se
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the second party's reception is of= interest. )

This proposal (and related proposals involving encrypting session keys to=20 inspection boxes, either in-band or OOB) violates condition 2 because=20 one endpoint would have to intentionally take action to=20 deliver the session key or private DH share to the third party. If one endpoint is feeding cryptographic material to a third party (the=20 only way that information gets out to the third party, vulnerabilities=20 notwithstanding), they are collaborating, not enabling wiretapping.

=
(I'd argue the inspection box also fails to be a third party, as it is part=20 of the infrastructure of one endpoint, but that's largely irrelevant to= =20 the question of whether this is wiretapping once we've determined the= =20 delivery of keys is not a secret.)

I think this issue of static DH being an attack (maybe; not taking a=20 position) is something of a red herring, because shipping individual=20 session keys to a third party like a government doesn't add any=20 substantive hurdle beyond shipping them a single static DH share. That=20 said, I agree that an infrastructure for detecting=20 the loss of forward secrecy, perhaps in a CT-like manner, may make sense to protect against unintentional key compromise or compromise of one=20 endpoint: the problems that forward secrecy is intended to address,=20 which specifically do *not* include collaboration.

Kyle

--94eb2c05760686b79905541de5e5-- From nobody Wed Jul 12 05:57:57 2017 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 14DF713169C for ; Wed, 12 Jul 2017 05:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rbdwpooIx-fe for ; Wed, 12 Jul 2017 05:57:54 -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 9AC5512EC0F for ; Wed, 12 Jul 2017 05:57:54 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id 16so21681831qkg.2 for ; Wed, 12 Jul 2017 05:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=p+EVI1nsy54hdY3Nq6WywqwHqxekIYInnJdcw+c1rQ4=; b=vS47xGgMvtFP5o3NWxfmKDmH57zd/CmsIqJiURkp/Jl9eiTyXXEb8xWlYW5kOyRxvN SQ7KJP2WOzM+S9X33wrEC+0LhN+ItNpNZlD+w7jmnQ4Cyu5lQ6ad7dxqs02OG2yVSBCL RAH6FiKmK8MOHJp+JK+dGc91OzNu35odMFsN+fGh5X0+EdeFejlKvjkwNKEJYwWyqNi8 0Dj+uFfOZV9n1uX8dxjDoo6jTod4rhsX4IEkqkgbWdbZv6hRVqXnPjJn0fjVYDLtQeTv kPR5WS73JpZ2FKIXR2lBbhfMAcuTEuD7IsY8OrEbOO5BNWy1rFk9bbga7XFYMU1fxGZS KryQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=p+EVI1nsy54hdY3Nq6WywqwHqxekIYInnJdcw+c1rQ4=; b=FZNTnD08KPpX8bQQMwVvxkmMHK6EYio4iNc/ruL9s7Z8iWN8+5/uIM868tdTwXjhm+ Mb5RDUnEC1auZm12BYISyk3rs7TTMdin06XZw2y0EDWnjKiRuzKAHbOeku3yLFUe8GXU dbMG/MwuIEZYCv3xKYyldZJd+lvmz3wQYQt/Uo8rlKfrdgo7FLv1dd2H7RCJQs9O1uHp I5iRN8x8vMq7qYEsD6nlzqTeyDNVVGsV1aJ6I+69GCIW26ATxYi3gSpoXEFcf0Mqux30 XzDbatQR4qbDMfKesr9WaTbv1yh8PO2bXRWMz05HCUzpROQb8fOcMzf02JwHdVx06KTa E4Kw== X-Gm-Message-State: AIVw1115oElotIClWM4wqAOaF+t+WtGyglWPA7i1k6qYq+iX5svkcpj1 V2mSrQmGILBXPmwVzaPRDg== X-Received: by 10.55.40.13 with SMTP id o13mr5533881qkh.116.1499864273657; Wed, 12 Jul 2017 05:57:53 -0700 (PDT) Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id c18sm1834748qtd.62.2017.07.12.05.57.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 05:57:52 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_09A7FDCB-CB08-4CD2-BC6F-53B651453A04" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Jul 2017 08:57:51 -0400 In-Reply-To: Cc: IETF TLS To: Kyle Rose References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 12:57:57 -0000 --Apple-Mail=_09A7FDCB-CB08-4CD2-BC6F-53B651453A04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 12, 2017, at 8:24 AM, Kyle Rose wrote: > Much of this conversation seems to conflate wiretapping with = collaboration. 2804 has a clear definition of wiretapping: The problem is that in modern times we can't assume that collaboration = is consensual, so the rules in RFC2804 aren't as applicable as they = were. There's no way to have the consensual collaboration use case = without enabling the non-consensual use case. Anything we do that = makes it easier to enable the non-consensual use case is a bad idea. = So in my mind RFC 7258 is more applicable here than RFC 2804. The problem with arguing this on the basis of whether or not there is a = non-wiretapping operational use case for this is that there is a = legitimate non-wiretapping operational use case here. As I understand = it, the motivation for doing this is to be able to avoid deploying = different pieces of DPI hardware differently in data centers. That's a = legitimate motivation. The problem is that (IMHO) it's not a good = enough reason to standardize this. I would much rather see people who have this operational use case = continue to use TLS 1.2 until the custom DPI hardware that they are = depending on is sufficiently obsolete that they are going to remove it = anyway; at that point they can retool and switch to TLS 1.3 without = needing support for static keys. The advantage of this is that simply = using TLS 1.2 signals to the client that the privacy protections of TLS = 1.3 are not available, so you get the consensual aspect that Tim was = arguing for without having to modify TLS 1.3. --Apple-Mail=_09A7FDCB-CB08-4CD2-BC6F-53B651453A04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 12, 2017, at 8:24 AM, Kyle Rose <krose@krose.org> = wrote:
Much of this conversation seems = to conflate wiretapping with collaboration. 2804 has a clear definition = of wiretapping:

The problem is that in modern times we can't = assume that collaboration is consensual, so the rules in RFC2804 aren't = as applicable as they were.   There's no way to have the consensual = collaboration use case without enabling the non-consensual use case. =   Anything we do that makes it easier to enable the non-consensual = use case is a bad idea.   So in my mind RFC 7258 is more applicable = here than RFC 2804.

The problem with = arguing this on the basis of whether or not there is a non-wiretapping = operational use case for this is that there is a = legitimate non-wiretapping operational use case here.   As I = understand it, the motivation for doing this is to be able to avoid = deploying different pieces of DPI hardware differently in data centers. =   That's a legitimate motivation.   The problem is that (IMHO) = it's not a good enough reason to standardize this.

I would much rather see people who have this = operational use case continue to use TLS 1.2 until the custom DPI = hardware that they are depending on is sufficiently obsolete that they = are going to remove it anyway; at that point they can retool and switch = to TLS 1.3 without needing support for static keys.   The advantage = of this is that simply using TLS 1.2 signals to the client that the = privacy protections of TLS 1.3 are not available, so you get the = consensual aspect that Tim was arguing for without having to modify TLS = 1.3.

= --Apple-Mail=_09A7FDCB-CB08-4CD2-BC6F-53B651453A04-- From nobody Wed Jul 12 07:18:53 2017 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 444DC1316A8 for ; Wed, 12 Jul 2017 07:18:52 -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 nzwA4puXj9i6 for ; Wed, 12 Jul 2017 07:18:50 -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 26C1A129B15 for ; Wed, 12 Jul 2017 07:18:50 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id l21so10954055ywb.1 for ; Wed, 12 Jul 2017 07:18:50 -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=/Olwo/IlvNgJTneRKyboj25+EM6eLYPadMbVDk428lc=; b=Dz9QJkBeQGcCl4NRRf/+beav/GPmuDUkCtOEW38iJpt/kS4JLJmf2yzjCmm/tw9J0M Yt95dy/YO40/eMtpA5AzThYC2FA0VTI7IBhCTI1gH1oqmg3LGsQHCqYwVWWwaHxqFyHQ axyfLN6AqHi2i1/FXCb99VVftWPd607NvqnzY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/Olwo/IlvNgJTneRKyboj25+EM6eLYPadMbVDk428lc=; b=Wcn9JE5e85TFro3nPg9vc4EEQPA2+CbaoR+YmP9r5rmLUYHWhhoAnNADISwZ5tseyG NwYF8u7mRKUPF4rW7mIYjRWIOKq8TgUSFfYHGrtBxz8XyItIODtV39lOYrPVm4ngrsJi P9ROdU9ZPfMhBaAyPsrNksUCRxOY3P8gA5HGuSs9D0TfPVV2/VgkoUXZ4L/xIB22oJUz pzHZJGzY+MNsJqXB2wjxYRgDdUFRAsSGaGh1uSrM1heRmbXVQio2QrXvpJD27XF79fl4 Gmy4daL51sFvAPV2aiufjo4OvDv8HiWnpFMi/d+cV85oIlUq8ZM+zXff2twD92yP+U4Q 1ePg== X-Gm-Message-State: AIVw113/5rvm6KeLb5Zaqh+uENBkVB6mq8jLQr02vHuuUmYVAx+UL0yX Bh3WfafoD3RXvJNhyf8RaCT9Rjc0bamTVbs= X-Received: by 10.237.41.132 with SMTP id o4mr6445903qtd.242.1499869129183; Wed, 12 Jul 2017 07:18:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Wed, 12 Jul 2017 07:18:47 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> From: Kyle Rose Date: Wed, 12 Jul 2017 10:18:47 -0400 Message-ID: To: Ted Lemon Cc: IETF TLS Content-Type: multipart/alternative; boundary="94eb2c08f22ea7ac3505541f7e4f" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 14:18:52 -0000 --94eb2c08f22ea7ac3505541f7e4f Content-Type: text/plain; charset="UTF-8" On Wed, Jul 12, 2017 at 8:57 AM, Ted Lemon wrote: > The problem is that in modern times we can't assume that collaboration is > consensual, so the rules in RFC2804 aren't as applicable as they were. > Until someone comes up with a technical countermeasure for involuntary collusion, the solution space is entirely political. This isn't nuclear science, in which it was conceivable in the 1940's that consensus among the entire community of nuclear physicists could have crippled the development of the bomb: the IETF neither discussing nor publishing a document describing a mechanism for session key sharing does not imply that a government hell-bent on pervasive surveillance will be unable to force something down the throats of site admins, because even the not-entirely-broken ways of doing this are pretty obvious extensions to the protocol. We need to dispel the myth that mere inaction on our part will on its own prevent implementation of these mechanisms, if for no other reason but to redirect energy to the political arena where the pervasive monitoring battles *are* actually fought. > There's no way to have the consensual collaboration use case without > enabling the non-consensual use case. Anything we do that makes it easier > to enable the non-consensual use case is a bad idea. So in my mind RFC > 7258 is more applicable here than RFC 2804. > No contest. > The problem with arguing this on the basis of whether or not there is a > non-wiretapping operational use case for this is that there *is* a > legitimate non-wiretapping operational use case here. As I understand it, > the motivation for doing this is to be able to avoid deploying different > pieces of DPI hardware differently in data centers. That's a legitimate > motivation. The problem is that (IMHO) it's not a good enough reason to > standardize this. > > I would much rather see people who have this operational use case continue > to use TLS 1.2 until the custom DPI hardware that they are depending on is > sufficiently obsolete that they are going to remove it anyway; at that > point they can retool and switch to TLS 1.3 without needing support for > static keys. The advantage of this is that simply using TLS 1.2 signals > to the client that the privacy protections of TLS 1.3 are not available, so > you get the consensual aspect that Tim was arguing for without having to > modify TLS 1.3. > Absolutely. Your recommendation (among others') is precisely why I am opposed to censoring this (or any) discussion. We're not the protocol police: while there is simply no way for us to prevent implementors from doing misguided things, we can provide alternatives and recommendations along with justifications for those judgments. But I see this discussion as mostly limited to improving the practical security of actual users, not as part of some larger war against wiretapping or pervasive surveillance. This isn't that battle, and this is not where that battle will be fought if governments decide they want those things. Kyle --94eb2c08f22ea7ac3505541f7e4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 12, 2017 at 8:57 AM, Ted Lemon <mellon@fugue.com> wro= te:
<= span class=3D"">The problem is that in modern times we can't ass= ume that collaboration is consensual, so the rules in RFC2804 aren't as= applicable as they were. =C2=A0

Unt= il someone comes up with a technical countermeasure for involuntary collusi= on, the solution space is entirely political. This isn't nuclear scienc= e, in which it was conceivable in the 1940's that consensus among the e= ntire community of nuclear physicists could have crippled the development o= f the bomb: the IETF neither discussing nor publishing a document describin= g a mechanism for session key sharing does not imply that a government hell= -bent on pervasive surveillance will be unable to force something down the = throats of site admins, because even the not-entirely-broken ways of doing = this are pretty obvious extensions to the protocol.

We need to dispe= l the myth that mere inaction on our part will on its own prevent implement= ation of these mechanisms, if for no other reason but to redirect energy to= the political arena where the pervasive monitoring battles *are* actually = fought.
=C2=A0
There's no way to have the consensual colla= boration use case without enabling the non-consensual use case. =C2=A0 Anyt= hing we do that makes it easier to enable the non-consensual use case is a = bad idea. =C2=A0 So in my mind RFC 7258 is more applicable here than RFC 28= 04.

No contest.
=C2=A0
The probl= em with arguing this on the basis of whether or not there is a non-wiretapp= ing operational use case for this is that there is a legitimate non-= wiretapping operational use case here. =C2=A0 As I understand it, the motiv= ation for doing this is to be able to avoid deploying different pieces of D= PI hardware differently in data centers. =C2=A0 That's a legitimate mot= ivation. =C2=A0 The problem is that (IMHO) it's not a good enough reaso= n to standardize this.

I would much rather see peo= ple who have this operational use case continue to use TLS 1.2 until the cu= stom DPI hardware that they are depending on is sufficiently obsolete that = they are going to remove it anyway; at that point they can retool and switc= h to TLS 1.3 without needing support for static keys. =C2=A0 The advantage = of this is that simply using TLS 1.2 signals to the client that the privacy= protections of TLS 1.3 are not available, so you get the consensual aspect= that Tim was arguing for without having to modify TLS 1.3.

Absolutely. Your recommendation (among others&= #39;) is precisely why I am opposed to censoring this (or any) discussion. = We're not the protocol police: while there is simply no way for us to p= revent implementors from doing misguided things, we can provide alternative= s and recommendations along with justifications for those judgments. But I = see this discussion as mostly limited to improving the practical security o= f actual users, not as part of some larger war against wiretapping or perva= sive surveillance. This isn't that battle, and this is not where that b= attle will be fought if governments decide they want those things.

<= /div>
Kyle

--94eb2c08f22ea7ac3505541f7e4f-- From nobody Wed Jul 12 07:22:25 2017 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 AB1F8129B26 for ; Wed, 12 Jul 2017 07:22:22 -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 ohyGBQ8_mv7m for ; Wed, 12 Jul 2017 07:22:19 -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 92B01131934 for ; Wed, 12 Jul 2017 07:22:19 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id d78so25420998qkb.1 for ; Wed, 12 Jul 2017 07:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=74P/LAy7RzlVxtdNOI9+LbmWt235FrxwUZd2v9KodXQ=; b=h0/1FNrqxHQhR3lQOl4F7CW6L6Ia3c159ZFP9j7c2hreIWM2DuF5aoVHXLB+ZJr9C1 FgLF4dEa/KRjp7+4VtMBmDYveIb11Z3FUGbxtADczl+eZp0dvi7O2ivEwNwr2suvTsor Y/8RRxq6cYRsmTVk+4rxae/iZ3x4ZQXgUTF8+m99ie7Cca+K8BevfZEjROwKqxcWDyOx E5Wqg9HJG/bZdQJ5kzDn6zM+5XVZXBc2aIU/m6+NOfOmwN4KN/aLyYEBNdQ6KtJHsZUh iuB/KYB88x+SY2vi6rWyOsfY+VByOfn9ra88ToFTuvX3fDRkkGOgV53zZrTZv2xuEWws zkrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=74P/LAy7RzlVxtdNOI9+LbmWt235FrxwUZd2v9KodXQ=; b=RwLcq9Vk2YScaaa57O06IgVTED0iKMQdJGkZpNR8HG24qSB+F9f6+SEfaPDVjVQtYg M2Db9h/BmZjhVLq3oqcGYmCNUVZT/BINIoeJ3Rx/NbP+l0CedVgvTXnXmo8Rf9PlpuOp mUYGiSdt1TCgdeywZZBV3HegbBKe1pcJDm4BlfoMkmPAX9lezsY+e8wjNss53TZOQrOA HkRdRzjU+kkOyLaiIsg3QsE/wwkS7cLv5JlY/wo7AJnmBMLoSudxMEuM2bJacLW5L1UB Ltrgc3l/FrPjnSoL/Acf3kDGF5+ibCgSpUKvJ7qqRruY4HSjpBAtUUTE723QpQICa+OS ftHQ== X-Gm-Message-State: AIVw110fvWvMzA/w288LSsQSRE0vsbQc4s5OgMJNMUFbQtRAmvnDNySF V5xsIG+UDt6h7kA/G2IYUw== X-Received: by 10.55.124.67 with SMTP id x64mr6192206qkc.98.1499869338506; Wed, 12 Jul 2017 07:22:18 -0700 (PDT) Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n21sm1867042qkl.51.2017.07.12.07.22.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 07:22:17 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F2FBAF57-9A99-45AA-A41A-3BDABCAD1AE4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Jul 2017 10:22:16 -0400 In-Reply-To: Cc: IETF TLS To: Kyle Rose References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 14:22:23 -0000 --Apple-Mail=_F2FBAF57-9A99-45AA-A41A-3BDABCAD1AE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 12, 2017, at 10:18 AM, Kyle Rose wrote: > We need to dispel the myth that mere inaction on our part will on its = own prevent implementation of these mechanisms, if for no other reason = but to redirect energy to the political arena where the pervasive = monitoring battles *are* actually fought. Inaction on our part will prevent the code from going into the common = distributions. That's not worthless. --Apple-Mail=_F2FBAF57-9A99-45AA-A41A-3BDABCAD1AE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 12, 2017, at 10:18 AM, Kyle Rose <krose@krose.org> = wrote:
We = need to dispel the myth that mere inaction on our part will on its own = prevent implementation of these mechanisms, if for no other reason but = to redirect energy to the political arena where the pervasive monitoring = battles *are* actually fought.

Inaction on our part will prevent the code from = going into the common distributions.   That's not = worthless.

= --Apple-Mail=_F2FBAF57-9A99-45AA-A41A-3BDABCAD1AE4-- From nobody Wed Jul 12 07:32:20 2017 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 7F6BA131700 for ; Wed, 12 Jul 2017 07:32:19 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 R6nH8lW5w6e7 for ; Wed, 12 Jul 2017 07:32:18 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 F02711287A0 for ; Wed, 12 Jul 2017 07:32:17 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id 77so36237208wrb.1 for ; Wed, 12 Jul 2017 07:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JbZKVSV5gxMPHAg3Uv+CAzUge+otRKU29ZHDYsEPtv8=; b=S2FiF1VjRbc/SiqHNaeXMZ15tjpU1RRnUqlX4WoNIEEcMUx14cYmUciRpw4UhehMkh uodIP22UpJQNzbN+RYDV9B3zNQ1ffvCinl9DoBUxY5ZGU+iT+1U5H5Q0zNsKSZNA6OB4 EC4n5Vfssaqf74Sx6xd9Zv8uRcIkX+J2M62Np1P8IaGDw7VBe6e9g3st9FN61UgSrP4a 8unVEfIv8Wh0wFcZLgXyabvvrW4iVUoiOKs8+/2Iz16D7QXCyJXRWKaNU22db3x5NOy8 8mEKsUHplxEHPB+86xxotQZsf8PFXvVyBCyd5Xcyxen2hvaKsaU6Lj8eNHp7SkhMJJNk 1Btg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JbZKVSV5gxMPHAg3Uv+CAzUge+otRKU29ZHDYsEPtv8=; b=PRnxx60sLBDe7PnaNMLonxNQdHlPaGYLOcTRM9D3ClRon8Gq64esHvMXZhkMetlj25 +eSZYEGm4Ylu85SIqOnc6QGYusuSkC8A0AuwV5w63zCRSTRJNp5IP9bR0GtISeG4Fzi5 BHmlCMwV1aXFi7u5Z8f+T9AiC8VFPvfH+fAKxrppQiOxJqqYdYfX0/JHYsUqOGSr3oT1 0uSfAvlJrzMzK0f2ecwmiXPgPn0uagr068ZBfytIy5fn7taYTpkaPJJ2tGWxn3PcLWnq CZdhP9rGekB+zbKQimcYW123N8XZi7A+vKyzX/W8EkcgULnzsLJs9/Rx0e6CGSdxt7/C rcMA== X-Gm-Message-State: AIVw1121cwwp/xbUVuQKrg6gnDuqjGxENq5R0oHlwdj+UNeTFk3/34Xc qXRg9KrrXhqIbyTIvZXERUht/gV2G+PMRm4= X-Received: by 10.28.167.207 with SMTP id q198mr2949842wme.36.1499869936417; Wed, 12 Jul 2017 07:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Wed, 12 Jul 2017 07:32:15 -0700 (PDT) In-Reply-To: References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> From: Richard Barnes Date: Wed, 12 Jul 2017 10:32:15 -0400 Message-ID: To: Ted Lemon Cc: Kyle Rose , IETF TLS Content-Type: multipart/alternative; boundary="001a114ba0c6c554f705541faec1" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 14:32:19 -0000 --001a114ba0c6c554f705541faec1 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 12, 2017 at 10:22 AM, Ted Lemon wrote: > On Jul 12, 2017, at 10:18 AM, Kyle Rose wrote: > > We need to dispel the myth that mere inaction on our part will on its own > prevent implementation of these mechanisms, if for no other reason but to > redirect energy to the political arena where the pervasive monitoring > battles *are* actually fought. > > > Inaction on our part will prevent the code from going into the common > distributions. That's not worthless. > Oh, come on. You've never seen code in a library that implements something that's not in an IETF RFC? --Richard --001a114ba0c6c554f705541faec1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 12, 2017 at 10:22 AM, Ted Lemon <mellon@fugue.com> wrote:
On Jul 12, 2017, at 10:18 AM, Kyle Rose <krose@krose.org> wrot= e:
We need to dispel the myth that mere = inaction on our part will on its own prevent implementation of these mechan= isms, if for no other reason but to redirect energy to the political arena = where the pervasive monitoring battles *are* actually fought.

Inaction on our part will prevent the code= from going into the common distributions. =C2=A0 That's not worthless.=

Oh, come on.=C2=A0 You've never seen code in a libr= ary that implements something that's not in an IETF RFC?=C2=A0

--Richard=
--001a114ba0c6c554f705541faec1-- From nobody Wed Jul 12 07:35:39 2017 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 B5327129B7A for ; Wed, 12 Jul 2017 07:35:38 -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 mbCh64I7ZiM0 for ; Wed, 12 Jul 2017 07:35:37 -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 25D3E127058 for ; Wed, 12 Jul 2017 07:35:37 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id a66so12152989qkb.0 for ; Wed, 12 Jul 2017 07:35:37 -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=2szMinqXiaw+lSBx8lPgqNWCdJom0Fq2oDXOKR4NdAg=; b=AmAvH2RegpwbQQDW5GqDNOgYnfyyOqRKMcbH7Xv9euPoBtiyQG3IChcYtXNb5xxn7M Smfs0BnJfYpOnbxjq32XoXsXGMeLYcegp1RKaHn7tPkoxKftsiFDMWV7gdP1vIu+SNoy OAreW9CjGbz/uNE4T1eU36KH6f8rqhIHNn4DQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2szMinqXiaw+lSBx8lPgqNWCdJom0Fq2oDXOKR4NdAg=; b=JZmr1JrvpdRA1GZZqTro4ZKZWgi4zhVhljANyrySEhcnkEds7af47k/ED+XKlsrOwM zSi/O130kx/rJQFUqOtQh/MFURZBjqcHopYLc07tQ/bQiF8AkCcIawW79DEO48i63T3n 2DH/9CnY3FYCtL8DqVfvUx7ZtKz1LHn9dQ+k6+VbZB5A9EtKyVdFFYZxV4l6dtuJaPRS J8H8l4CyAQAltFXSUTBOriYLmy+G4iW3pKJit4mOehtqfh2ROFhs/WK7wcUU7VZbIwSo vN1yQLvmy4DoG/DCxecg7dkNQ8YIvfUWiL6TRyfSwrMcvR8ImCVlc/bMnuNyGfVyWbFA SHZg== X-Gm-Message-State: AIVw110t/gYHx/Wo4hN6k5JvIhHQWDgJV30AKE6XtvEmYzOBXeUPFEag GuNSf59EgRozYimdxBVgZbyF7oOz8Mbl X-Received: by 10.55.97.13 with SMTP id v13mr6190605qkb.107.1499870136149; Wed, 12 Jul 2017 07:35:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Wed, 12 Jul 2017 07:35:34 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> From: Kyle Rose Date: Wed, 12 Jul 2017 10:35:34 -0400 Message-ID: To: Ted Lemon Cc: IETF TLS Content-Type: multipart/alternative; boundary="94eb2c057606acbea205541fba11" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 14:35:39 -0000 --94eb2c057606acbea205541fba11 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 12, 2017 at 10:22 AM, Ted Lemon wrote: > On Jul 12, 2017, at 10:18 AM, Kyle Rose wrote: > > We need to dispel the myth that mere inaction on our part will on its own > prevent implementation of these mechanisms, if for no other reason but to > redirect energy to the political arena where the pervasive monitoring > battles *are* actually fought. > > > Inaction on our part will prevent the code from going into the common > distributions. That's not worthless. > Which will have zero impact on pervasive surveillance until some government decides they want to use this mechanism or something like it and mandates that it be implemented universally within their borders. Then it will appear in short order, even if the government has to hire their own code monkeys to do it, at which point it will continue to have zero impact on pervasive surveillance. Again, I'm not recommending any TLS distribution implement this, only that we stop fooling ourselves into believing that refusing to standardize a mechanism like this will prevent one from being implemented when someone decides they want it. This is fundamentally different from the question of standardizing potentially privacy-violating protocol extensions that need to survive end-to-end on the internet to be useful to the third party: this entire functionality can be implemented at a single endpoint without anyone else's permission or custom interop. Kyle --94eb2c057606acbea205541fba11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 12, 2017 at 10:22 AM, Ted Lemon <mellon@fugue.com> wr= ote:
On Jul 12, 2017, at 10:18 A= M, Kyle Rose <krose= @krose.org> wrote:
We need to dis= pel the myth that mere inaction on our part will on its own prevent impleme= ntation of these mechanisms, if for no other reason but to redirect energy = to the political arena where the pervasive monitoring battles *are* actuall= y fought.

Inaction on our par= t will prevent the code from going into the common distributions. =C2=A0 Th= at's not worthless.

Which will have zero impact on pervasive surveillance unti= l some government decides they want to use this mechanism or something like= it and mandates that it be implemented universally within their borders. T= hen it will appear in short order, even if the government has to hire their= own code monkeys to do it, at which point it will continue to have zero im= pact on pervasive surveillance.

Aga= in, I'm not recommending any TLS distribution implement this, only that= we stop fooling ourselves into believing that refusing to standardize a me= chanism like this will prevent one from being implemented when someone deci= des they want it.

This is fundamentally different from the question = of standardizing potentially privacy-violating protocol extensions that nee= d to survive end-to-end on the internet to be useful to the third party: th= is entire functionality can be implemented at a single endpoint without any= one else's permission or custom interop.

Kyle

--94eb2c057606acbea205541fba11-- From nobody Wed Jul 12 07:39:00 2017 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 4821E13169D for ; Wed, 12 Jul 2017 07:38:59 -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 J4zWuZREGUU5 for ; Wed, 12 Jul 2017 07:38:58 -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 C6E181316A8 for ; Wed, 12 Jul 2017 07:38:57 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id 16so26019697qkg.2 for ; Wed, 12 Jul 2017 07:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HQ+XK5IcgKEp1HiFhFdPSjxPv+Wqo+gff1dSv5MVego=; b=0XLSLFqIeR9VZppNunyVxd+ImVPTaD/bTXdtWgyKQntvMsY+yHC1zybuSqvfNzHv2c fv0YhpIDqjuZ7XmCsfqNfTlMBi1Bzs4pKpLnnjRuGcWJtucCTLBk/i5z9RbVpAKCzphU Z71rpdKL1O8wszvA1tURa7ighD0tDaClUeafuZ34otA96yTs8FtBuVAMEkcVJ2Ci8qTp Xl2oFFF7kwC63j3xmapTBOtzF3oXztWXkBfDimxktUo1KSZNtKQCVxAHb0pq2BJGhZf1 Ap6378HprlSUcI4EFjlrDe3APSy9ZXU+e5e97j1DBufZKCST12Et45QHYe8gdgLxXaO+ LYrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HQ+XK5IcgKEp1HiFhFdPSjxPv+Wqo+gff1dSv5MVego=; b=oMCIFUNFl1cdwiWvvb4sAwYe1ZzDAUhNWVYqyVIlvxHtr4dROHLl0EcMhsF2AtMb9x /i+WFvZrvJsLpVqaw8jWaGRi9cNxXfWsTVt6LXs7u+eBcxRscM+WW7Sq2ZN8qYrNi8ZY GHiyiRzeRHK7D/FySlU33nZheO7gRslPhz1PNlD+1UbFpqwwPZO4JDpy2Kk4JjM6JhPp hxO5bi8V9vTb6dbVdqeBB5Xn88R7TAB9K7olFXd8WKDkyvZQiB8DSb6uE3QPOfueybGG uqzw8jUABwMynzPzd+6mmxVg2D5QJ5X6cI9qjfcNmB58vo3u8YCoe/PaH/HrGck0VcX1 3xpg== X-Gm-Message-State: AIVw110EXb10POtp3f5eMwMe83BuPO6W5u6No05kjoVrq0uXudOHRhhQ x8uPqM07g8M/KGNO X-Received: by 10.55.105.130 with SMTP id e124mr6206346qkc.117.1499870336968; Wed, 12 Jul 2017 07:38:56 -0700 (PDT) Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 8sm2181552qkc.30.2017.07.12.07.38.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 07:38:56 -0700 (PDT) From: Ted Lemon Message-Id: <23DFCB04-F60F-427A-A06D-834F9034AA38@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_24949563-10AF-4312-A184-4F399E2466FA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Jul 2017 10:38:54 -0400 In-Reply-To: Cc: Kyle Rose , IETF TLS To: Richard Barnes References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 14:38:59 -0000 --Apple-Mail=_24949563-10AF-4312-A184-4F399E2466FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 12, 2017, at 10:32 AM, Richard Barnes wrote: > Oh, come on. You've never seen code in a library that implements = something that's not in an IETF RFC? =20 Of course I have. I think that putting a warning in the TLS 1.3 spec = as Christian suggested will mean that the code won't appear in places = where there isn't a strong use case for it. It may well appear in = places where there is a strong use case, but anything open source is = going to face a stiff headwind in terms of implementing this, and that's = what I'm suggesting we encourage. If it doesn't show up in openssl, = gnutls or boringssl, it's a much smaller problem. We can't actually = stop it happening=E2=80=94I'm just arguing for not making it convenient. --Apple-Mail=_24949563-10AF-4312-A184-4F399E2466FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 12, 2017, at 10:32 AM, Richard Barnes <rlb@ipv.sx> = wrote:
Oh, come on.  You've never seen = code in a library that implements something that's not in an IETF = RFC?  

Of course I have.   I think that putting a = warning in the TLS 1.3 spec as Christian suggested will mean that the = code won't appear in places where there isn't a strong use case for it. =   It may well appear in places where there is a strong use case, = but anything open source is going to face a stiff headwind in terms of = implementing this, and that's what I'm suggesting we encourage.   = If it doesn't show up in openssl, gnutls or boringssl, it's a much = smaller problem.   We can't actually stop it happening=E2=80=94I'm = just arguing for not making it convenient.

= --Apple-Mail=_24949563-10AF-4312-A184-4F399E2466FA-- From nobody Wed Jul 12 07:41:38 2017 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 950FA13193E for ; Wed, 12 Jul 2017 07:41:36 -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=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 dSzkAwtDX6SB for ; Wed, 12 Jul 2017 07:41:35 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 19596129B7A for ; Wed, 12 Jul 2017 07:41:35 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 32so14096754qtv.1 for ; Wed, 12 Jul 2017 07:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GxHUE9f6RWr0T47ovVL8G4/ftZg3mdLM8Sf6r0cCTj4=; b=d/u1Jjw5DtWrsLdi7CDaFazyEzJ96snihC35ep/deOr7UrQjIJx9AfRZ8+Nbi47iLk 36pe8UdG6yuJwp50f4W3LI5JwSEMKszslsBKn0uK98wDJNWeDTl/90rOlHrjBdguLi24 uWuPxlwMWQIkpZ25HW0bcyGt69UlBCCkFeTr3NyIwO4ar6owqMjyArAZiMXdUJTscwU4 Av1BV4MY2AyuQCehYIuQv6AOWYu2yjnc7AZ21EZaLeCfqVSZ9xB4/hJZENOoJUzWztos kQ/o5GKeqHfN7tvLFIY+d23nq1dnTyyjO1HG/kA1GMxyYb1kMkp38o1OZ50sTsryImSZ aKlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GxHUE9f6RWr0T47ovVL8G4/ftZg3mdLM8Sf6r0cCTj4=; b=dobn+FNEgza/yT10CUihT4bvE+rcdZfi0CLB2r35j0voxQfiIjj/zMJNK0Lv1E0il8 7kqrCCOht+TTPrvl6Zo7ZtFKrcUel9GIUJNoDA8oFk4Jl+PGxXQW3U0cDpWOhq7+UfCG BXvZYAwMp+3EHtspPdz4uDV37Tb7NVtP3mgT8qMaXXiBsO+y69sqiTZt9Y/vY4Cz05UR TqsZP7LYj9nSoo0ZTgutM/aXCip2XXYcG8ERAC2ZWxzFbvQWkkZe7Zx15vxErLJDVnYA kb0iz1WqoPsGO2ULeBMqPGw8YYHt2zBiZo/dBFffmv3tSR3dp16pwo+wVhYMPrxHH/nM wvCg== X-Gm-Message-State: AIVw1110zZlnGfioSb0beKuS7bZ3CPfgfZM0OwtYaGqs4yHRIIceoMfj MAYluW9jTP9GLjp5R3t4kg== X-Received: by 10.200.41.238 with SMTP id 43mr7078773qtt.168.1499870494171; Wed, 12 Jul 2017 07:41:34 -0700 (PDT) Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id x25sm2081087qth.61.2017.07.12.07.41.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 07:41:33 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ABF71214-B62B-42B7-B7ED-A777D1B1C0BE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Jul 2017 10:41:32 -0400 In-Reply-To: Cc: IETF TLS To: Kyle Rose References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 14:41:37 -0000 --Apple-Mail=_ABF71214-B62B-42B7-B7ED-A777D1B1C0BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 12, 2017, at 10:35 AM, Kyle Rose wrote: > Which will have zero impact on pervasive surveillance until some = government decides they want to use this mechanism or something like it = and mandates that it be implemented universally within their borders. = Then it will appear in short order, even if the government has to hire = their own code monkeys to do it, at which point it will continue to have = zero impact on pervasive surveillance. Right, and then there will have to be a public debate. I expect that = exactly what you describe will happen or be attempted in various = jurisdictions. That's okay. Requiring this stuff to be done publicly = is better than it happening in secret. (Is this conversation still really useful? I don't think I'm saying = anything you don't already know, so I don't know why you made this = point.) --Apple-Mail=_ABF71214-B62B-42B7-B7ED-A777D1B1C0BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 12, 2017, at 10:35 AM, Kyle Rose <krose@krose.org> = wrote:
Which will have zero impact on = pervasive surveillance until some government decides they want to use = this mechanism or something like it and mandates that it be implemented = universally within their borders. Then it will appear in short order, = even if the government has to hire their own code monkeys to do it, at = which point it will continue to have zero impact on pervasive = surveillance.

Right, and then there will have to be a public debate.   = I expect that exactly what you describe will happen or be attempted in = various jurisdictions.   That's okay.   Requiring this stuff = to be done publicly is better than it happening in secret.

(Is this conversation = still really useful?   I don't think I'm saying anything you don't = already know, so I don't know why you made this point.)

= --Apple-Mail=_ABF71214-B62B-42B7-B7ED-A777D1B1C0BE-- From nobody Wed Jul 12 07:45:23 2017 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 122C01316D6 for ; Wed, 12 Jul 2017 07:45:22 -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 hGuf5UDbRVSr for ; Wed, 12 Jul 2017 07:45:20 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6951813169D for ; Wed, 12 Jul 2017 07:45:20 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id 16so26201345qkg.2 for ; Wed, 12 Jul 2017 07:45:20 -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=YHNWOccSVSiOqZaTmh+bm53WQIORHzstI3fikNgWm3g=; b=EvXYoumgXeqCATemiRfe/1f+6/52tmszP8BahQ9RrAknXc8AmW7NqwxkBFJ1TMBbgj gHusNAGuWYX3i2L48s0frB5ghJ9B3Qn3amUeCcDJ+w4M2Rk12VXcJWyL+fXlK3axJjvw q1Q8hP6nDAykum9yVkg9my4XI32rtD7A9L3Ok= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YHNWOccSVSiOqZaTmh+bm53WQIORHzstI3fikNgWm3g=; b=RdCL2o0cppqo5n+hmPpQ2TRU8UNKkoQ1I5FyJjf63vvkIdKYNa1ggYD670U4ZtQDwH UDbY/Na3VKvCCqLLEwXR1dSV8ZuPQmitFlic2zBvjzsqBIvVhgWAdlltJYD6BsaeYtF0 4bOtLPZbNf1BEe/bw6Nb1mL0P+3F5vmKhSItOwWnix6YkUOw4tp1vBUpTwlxeLHXSJCx PTygJ23K7je/czCAVmMrjOLHHEW2fP7VavRBsGUvf5Oj1hhYYbmGsjyPFYNOOci+6YD6 ZviUwbjgwGuekO/rJY67athD3a78TEqPMT59I57U+0geuvJoPmiqwJAoKqt9IGtu3dSg OeKA== X-Gm-Message-State: AIVw113sSEclwjxtpcQvtmNfYB72eQLnqbtUVK9FdxfqDqXrd7YPxF14 7lQSXyRr0l8rnksGwa7pwKrTDlLeQ9h/sqE= X-Received: by 10.55.123.199 with SMTP id w190mr6912596qkc.21.1499870719513; Wed, 12 Jul 2017 07:45:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Wed, 12 Jul 2017 07:45:18 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <23DFCB04-F60F-427A-A06D-834F9034AA38@fugue.com> References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <23DFCB04-F60F-427A-A06D-834F9034AA38@fugue.com> From: Kyle Rose Date: Wed, 12 Jul 2017 10:45:18 -0400 Message-ID: To: Ted Lemon Cc: Richard Barnes , IETF TLS Content-Type: multipart/alternative; boundary="94eb2c05ef54723bc705541fdd92" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 14:45:22 -0000 --94eb2c05ef54723bc705541fdd92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 12, 2017 at 10:38 AM, Ted Lemon wrote: > On Jul 12, 2017, at 10:32 AM, Richard Barnes wrote: > > Oh, come on. You've never seen code in a library that implements > something that's not in an IETF RFC? > > > Of course I have. I think that putting a warning in the TLS 1.3 spec as > Christian suggested will mean that the code won't appear in places where > there isn't a strong use case for it. It may well appear in places wher= e > there is a strong use case, but anything open source is going to face a > stiff headwind in terms of implementing this, and that's what I'm > suggesting we encourage. If it doesn't show up in openssl, gnutls or > boringssl, it's a much smaller problem. We can't actually stop it > happening=E2=80=94I'm just arguing for not making it convenient. > Knowing the people involved in at least some of those projects, there is very little chance of that happening. Beyond that lies political action, which is definitely not what the TLS WG mailing list should be used for. To your last email, I agree that we've mostly beaten this to death. I'm happy to let the conversation move elsewhere. Kyle --94eb2c05ef54723bc705541fdd92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 12, 2017 at 10:38 AM, Ted Lemon <mellon@fugue.com> wrote:
On Jul 12, 2017, at 10:32 AM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wrote:
Oh, come on.=C2=A0 Y= ou've never seen code in a library that implements something that's= not in an IETF RFC?=C2=A0=C2=A0

Of cou= rse I have. =C2=A0 I think that putting a warning in the TLS 1.3 spec as Ch= ristian suggested will mean that the code won't appear in places where = there isn't a strong use case for it. =C2=A0 It may well appear in plac= es where there is a strong use case, but anything open source is going to f= ace a stiff headwind in terms of implementing this, and that's what I&#= 39;m suggesting we encourage. =C2=A0 If it doesn't show up in openssl, = gnutls or boringssl, it's a much smaller problem. =C2=A0 We can't a= ctually stop it happening=E2=80=94I'm just arguing for not making it co= nvenient.

Knowing the people involved in = at least some of those projects, there is very little chance of that happen= ing. Beyond that lies political action, which is definitely not what the TL= S WG mailing list should be used for.

To your last email, I agree that we've mostly beaten this to death. = I'm happy to let the conversation move elsewhere.

Kyle

--94eb2c05ef54723bc705541fdd92-- From nobody Wed Jul 12 07:56:40 2017 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 873F6131691 for ; Wed, 12 Jul 2017 07:56: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wewIIG-GQjGS for ; Wed, 12 Jul 2017 07:56:36 -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 4854612F3D0 for ; Wed, 12 Jul 2017 07:56:36 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id i2so14463212qta.3 for ; Wed, 12 Jul 2017 07:56:36 -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:cc :content-transfer-encoding:message-id:references:to; bh=+tzyuejQG7pYOy51GJhARQryViSP4atux2Cy/9t6F/8=; b=gQ/BxpWRjHUm+dhTFI74kCyK4D33dlbsVK6BWFVAmdlkn5zMrOYaCvOv946Q3u0KCa //fqOqrcUm6LMatM/tMKCvVuND4A093T049Fe8STtfzLap4oo4eW4UIl2uwMqZe9vT3q TKe2AiNb9/RRL5PAxwWHzh0oCs8Kjc/dEhYrs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+tzyuejQG7pYOy51GJhARQryViSP4atux2Cy/9t6F/8=; b=irYEMN0KZGg1lR0vPXrgP7+s7JxBzFKrPjcTg4zSViAuKxraS6r2r5q8SbyKgtlM8Y 1Kb4vsGdx39KG8KPqQfJEiMgmSkN6IQFNLEWb/1mrBS5GhTTIjdTTmdFTbw6XcRgC6kd TIwLMH1LY2CCejhXCRZGcabKb0Rtkqq2wWlVtSRbcrIk+131ACjplv6CrYiQ6EgOkcR8 nPk3lA1CYtN/jXwTNOWFB1px8fB4w9UmIlW83OwMlezOLkFAHVDE5InmwF6c1cEgDycR RU6o9JRYvEyNjWRyc/4Un41qd4ZqiW6dnwu44bDdOf4GXuM4aqJw3HL096DQZ4poUyEC etNw== X-Gm-Message-State: AIVw1115txOYu3EbbLnDTVF/9Oq0wvG7KSYIhawi1wUa3oRmFIQwP1eb hTRUnwdjydw0ylvC X-Received: by 10.200.10.202 with SMTP id g10mr6593331qti.227.1499871395292; Wed, 12 Jul 2017 07:56:35 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.165]) by smtp.gmail.com with ESMTPSA id n11sm2134894qtf.45.2017.07.12.07.56.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 07:56:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Wed, 12 Jul 2017 10:56:32 -0400 Cc: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: yinxinxing X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 14:56:39 -0000 =20 > On Jul 6, 2017, at 23:04, yinxinxing wrote: >=20 > Hi all, > =20 > The NAT table expiring problem mentioned in the following email = should also be considered in DTLS1.2 as an extension. > =20 > The value and necessity are as follows. > =20 > 1. Essentially, NAT expiring problem causing DTLS renegotiation with = high power consumption is existing in DTLS 1.2. Even if we solve this in = DTLS1.3, this problem still exist for products using DTLS1.2. > Currently, many IOT products using DTLS 1.2 are going to be deployed = commercially, such as intelligent water/gas meter. These meters usually = have limited battery and low cost. To be more accurate, the battery of = the chip module of the intelligent water/gas meter are required to last = for 10 years. These lead to an exercise strict control over the power = consumption of the chip module. NAT expiring problem causing DTLS = renegotiation with high power consumption is a bottleneck of these IOT = devices. According to our experimental data, under the worst coverage = level (ECL2), power consumption of the chip module when DTLS is embedded = increases by nearly 60%. Therefore, there should be a solution to solve = the urgent problem to match the low-cost and low-battery feature of the = IOT devices in DTLS 1.2. I have to ask whether these IoT devices are updatable? > 2. DTLS 1.3 will be standardized in 2018, but the corresponding open = source code will be available about one year later after the = standardization. At present, large-scale commercial IOT industry = deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope = that the above problem could be solved in DTLS 1.2 as soon as possible. On this point, I=E2=80=99m hoping that you=E2=80=99ll be wrong ;). =46rom = the list of TLS implementations found here: https://github.com/tlswg/tls13-spec/wiki/Implementations and assuming there is as much enthusiasm to implement DTLS1.3 as there = was for TLS1.3 then I=E2=80=99m hoping that the DTLS implementations = will be ready much sooner than a year after publication (they might be = ready before the RFC is published). spt > Any comment is appreciated. > =20 > Regards, > Yin Xinxing > =20 > =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: yinxinxing=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8827=E6=97=A5= 16:28 > =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric Rescorla' > =E6=8A=84=E9=80=81: tls@ietf.org; Tobias Gondrom > =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG > =20 > Thanks Eric, > =20 > I have seen the CID scheme, and talked with Hannes(the author of the = scheme). > =20 > CID scheme is a good idea to solve the problem I mentioned. > =20 > I think the length of CID (currently, it is 32 bits) can be longer so = that it can support more DTLS sessions. It is known that for IOT = scenario, 1 million connection is nothing. > =20 > Regards, > Yin Xinxing > =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8825=E6=97=A5= 21:33 > =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing > =E6=8A=84=E9=80=81: tls@ietf.org; Xiongxiaochun > =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG > =20 > Hi Yin, > =20 > The usual solution to this is to add a connection id. Please see: > https://github.com/tlswg/dtls13-spec/issues/6 > =20 > -Ekr > =20 > =20 > =20 > =20 > On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing = wrote: > Hello everyone, > =20 > I am Yin Xinxing from Huawei company. I am glad to join the TLS WG. > =20 > For the DLTS 1.3 draft, I am interested and have some ideas to talk = with you. > =20 > DTLS has a lot of application scenarios in IOT fields, but currently, = there is some difficulty when DTLS 1.2 is applied to IOT devices, = especially the battery-constrained IOT devices. > =20 > For example, when the IOT device wakes up from sleep mode, the NAT = table may have expired. > Then the IOT device has to establish a new DTLS session or at least = launches a resume process with the server, the corresponding power = consumption is too high for some power-constrained devices.=20 > How can DTLS renegotiation be avoided in order to save battery? > =20 > I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this = problem and give a proper solution. =20 > =20 > Any comment or idea about this problem is welcome. > =20 > Regards, > Yin Xinxing >=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 Wed Jul 12 08:08:43 2017 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 5750E1316FF for ; Wed, 12 Jul 2017 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 m4zg3bGqfgV8 for ; Wed, 12 Jul 2017 08:08:39 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 224BD12EAF0 for ; Wed, 12 Jul 2017 08:08:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id F192120A5E; Wed, 12 Jul 2017 18:08:36 +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 A3dUgzySvnLl; Wed, 12 Jul 2017 18:08:36 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 24A9F2313; Wed, 12 Jul 2017 18:08:32 +0300 (EEST) Date: Wed, 12 Jul 2017 18:08:31 +0300 From: Ilari Liusvaara To: Christian Huitema Cc: Stephen Farrell , Ted Lemon , tls@ietf.org Message-ID: <20170712150831.xdq2byvjxlkbf2p3@LK-Perkele-VII> References: <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 15:08:41 -0000 On Tue, Jul 11, 2017 at 01:54:40PM -0700, Christian Huitema wrote: > On 7/11/2017 1:31 PM, Stephen Farrell wrote: > > > PS: There are also genuine performance reasons why the same > > DH public might be re-used in some cases, so there would be > > false positives in a survey to consider as well. > > Well, yes. The classic argument is performance. Saving the cost of > exponentiation, computing G^X once for many session instead of once per > session. But you reap most of the benefits of that optimization with a > fairly small number of repetitions. Performance alone is not a good > reason to use the key over extended period, not to share the exact same > key between all servers in a farm. The fact is that wide reuse of the > same (EC)DH private key does compromise the security of TLS -- including > an obvious issue with forward secrecy. Yes, the cost saturates very rapidly as the number of reuses increases. Even 100 reuses gets one within ~1% of asymptotic limit (half load). > In any case, I just submitted PR #1049 > (https://github.com/tlswg/tls13-spec/pull/1049). I didn't see this document the attack on integerity (full MITM attack) of the connection if attacker has aquired the DH share before the connection. -Ilari From nobody Wed Jul 12 08:18:31 2017 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 97B1D12FEE1 for ; Wed, 12 Jul 2017 08:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nemQIix5lur for ; Wed, 12 Jul 2017 08:18:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B850E1298BA for ; Wed, 12 Jul 2017 08:18:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 12DACBE5B; Wed, 12 Jul 2017 16:18:25 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81ouKb2g4b_N; Wed, 12 Jul 2017 16:18:24 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0F0EBE4C; Wed, 12 Jul 2017 16:18:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499872704; bh=lEWzg7LfXBstM/D7v0vnZYPq/4xeX+/g7H+FaCCWMjg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FXOYpHYzM0i7DSH7UoKczb1GW707nkG+dJAmi26Z5wHNXdOpa0d4TpXXOYBvX3W4b qq4Bnsug2KdzGNFvjBQeJZQSnNuzDc0ofgYsFakIgPv/1OBEb63Y1+Dhomz4L4tded yY39rYfUs/zeFPPs/NQBE1r3aXJQF8r2QWGnQTvE= To: Kyle Rose , Ted Lemon Cc: "Polk, Tim (Fed)" , IETF TLS References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 12 Jul 2017 16:18:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RgrM2nDl7ackvo7DXBxpoLcUBPQcrD7kp" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 15:18:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RgrM2nDl7ackvo7DXBxpoLcUBPQcrD7kp Content-Type: multipart/mixed; boundary="fL8P0T8hL9tNjKKi0mqBdD1cu5qjlKMrm"; protected-headers="v1" From: Stephen Farrell To: Kyle Rose , Ted Lemon Cc: "Polk, Tim (Fed)" , IETF TLS Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> In-Reply-To: --fL8P0T8hL9tNjKKi0mqBdD1cu5qjlKMrm Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 12/07/17 13:24, Kyle Rose wrote: > This proposal (and related proposals involving encrypting session keys = to > inspection boxes, either in-band or OOB) violates condition 2 because o= ne > endpoint would have to intentionally take action to deliver the session= key > or private DH share to the third party. I agree if there are only two parties, i.e. some deployments of schemes like this wiretapping scheme, do not meet the definition of wiretapping in 2804. > If one endpoint is feeding > cryptographic material to a third party (the only way that information = gets > out to the third party, vulnerabilities notwithstanding), they are > collaborating, not enabling wiretapping. That's nonsense. In the POTS case, telcos are collaborating with their local LEAs and that is wiretapping. Claiming that no deployment of this scheme (e.g. the SMTP or wordpress.com type ones already described on the list) meets the 2804 definition is just silly. S. --fL8P0T8hL9tNjKKi0mqBdD1cu5qjlKMrm-- --RgrM2nDl7ackvo7DXBxpoLcUBPQcrD7kp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZj2/AAoJEC88hzaAX42ipVAH/32el7FWytMa4+nrxeGjwxqS YCb0oZZYZpV47QuZQ0tJ8N5zrjaOr0OlNhvHOvi+yNnhYYjo5JP4xKRLM7eM6xzk zxJDlTVfGo61ZUjaw5K4reBXZY+DDWoUPArwCZWNSUKrv8iCmeEPqG8Y9LZxPhb+ MVf9kPORtC/6Id48mxK+URm7YkNjJfhKN0GHsT7Bq8+6lau8Bw6PQn/Y5fFJmQTA dLZXtHzBVrYxhrtKZkrzdrfB91rNAHBN2J4Laers3Y4KHW+ZV69QtYagOoapGQTy okzdc0U6qbpNlIgz8OikDvVd/D8mvaHeEo/0HiAQRjT8r83mK+wboEfzucJcHw0= =a2r6 -----END PGP SIGNATURE----- --RgrM2nDl7ackvo7DXBxpoLcUBPQcrD7kp-- From nobody Wed Jul 12 08:27:15 2017 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 6488C1316D6 for ; Wed, 12 Jul 2017 08:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PEcmufyriuSP for ; Wed, 12 Jul 2017 08:27:11 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 CC873131670 for ; Wed, 12 Jul 2017 08:27:11 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id b40so15336074qtb.2 for ; Wed, 12 Jul 2017 08:27:11 -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=Sk1eizqc+CYePPnwUmGA8v199kZd6Xiqg0Lpm+OU9qQ=; b=pvjvqmvrHeqihB1PLLbZBvpiIbs2Yp0SOXLgya/E/qENZhuiLXe3UNbBdjeyfJLTSa AyExnhpuOkow+7JGDEPSMM0XYgarKD0tFPPsm21eZdNUKw7mbwqUzlpRifkVTa26Jt/m 0sCG6B4Q1Q0PlLvoOgL2D2f5UK/JrHcSV9ysU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sk1eizqc+CYePPnwUmGA8v199kZd6Xiqg0Lpm+OU9qQ=; b=YR2QZBnHiJSNxH+x/BENScOXLSDm7LZiyJw+u4svIG3yxSh6T760wCvEYgE5RgpOt/ FNHtfOKpgJmbklRfvGItYzGQ6mRgh5uQWmGIMkcfEkf3syvwKYecG1w2dQe9RQkkBznU eHfNHKfsFY2cxU/0lP5rviy/LxTO26RXqOcDo5P5GZyW0scvPlJWQsedqMix0IH8lFz4 Txn0H4e4I7woTyEOTrGPTJm1NgRsApEoNvPQfQVBi0CY6yX9kdWWIT72+r/wws1U1XNP qgL2Y0k04XTmjXO12UooQjKyFysqwJDDeJlIlM1u868FOv5VyDlA+0inC5jEFiUrDe50 WLfg== X-Gm-Message-State: AIVw111fkhwUzu2lhp3z8xFHFc1hVll8bywjq7d0h/FsILOqToEFBi+s Vk9P24C40yAefoeoMoocO20wJ2F4iRGV X-Received: by 10.200.55.44 with SMTP id o41mr6943698qtb.120.1499873230750; Wed, 12 Jul 2017 08:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Wed, 12 Jul 2017 08:27:09 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> From: Kyle Rose Date: Wed, 12 Jul 2017 11:27:09 -0400 Message-ID: To: Stephen Farrell Cc: Ted Lemon , "Polk, Tim (Fed)" , IETF TLS Content-Type: multipart/alternative; boundary="001a1141e830209a0e0554207372" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 15:27:13 -0000 --001a1141e830209a0e0554207372 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 12, 2017 at 11:18 AM, Stephen Farrell wrote: > > If one endpoint is feeding > > cryptographic material to a third party (the only way that information > gets > > out to the third party, vulnerabilities notwithstanding), they are > > collaborating, not enabling wiretapping. > > That's nonsense. In the POTS case, telcos are collaborating > with their local LEAs and that is wiretapping. The telco in the POTS case isn't either endpoint. The third-party surveillance is unknown to those endpoints. Therefore: wiretapping. Kyle --001a1141e830209a0e0554207372 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 12, 2017 at 11:18 AM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
> If one endpoint is feeding
> cryptographic material to a third party (the only way that information= gets
> out to the third party, vulnerabilities notwithstanding), they are
> collaborating, not enabling wiretapping.

That's nonsense. In the POTS case, telcos are collaborating
with their local LEAs and that is wiretapping.

<= div>The telco in the POTS case isn't either endpoint. The third-party s= urveillance is unknown to those endpoints. Therefore: wiretapping.

<= /div>
Kyle

--001a1141e830209a0e0554207372-- From nobody Wed Jul 12 08:29:04 2017 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 C341712F4EA for ; Wed, 12 Jul 2017 08:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JabQpU1x5F4Q for ; Wed, 12 Jul 2017 08:29:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA554129AA0 for ; Wed, 12 Jul 2017 08:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8B406BE5B; Wed, 12 Jul 2017 16:29:00 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIBNarcgmCZZ; Wed, 12 Jul 2017 16:29:00 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5673FBE4C; Wed, 12 Jul 2017 16:29:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499873340; bh=fpqzHpiV8WquK4LusdJO0b+ju/Wq27I6M6QLG0bIfS0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NJOElGakYjw1/P7d6mb9iDQ5roh2pawxAYv4mT2Cu159qrRrc80KZgilBndW1/2Ud qQ7jB9xraAV5BFb05hL/nHOLJ9opt4u38Yx141i8D232n89xN+kviqg/ju+6yDJF+7 cXZejSUm2Ng4VJE9/lZrJWAeq+j1aaI5JWNTFpW8= To: Kyle Rose Cc: Ted Lemon , "Polk, Tim (Fed)" , IETF TLS References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9a5b276d-b1f2-bea9-19c1-d9eadf4da377@cs.tcd.ie> Date: Wed, 12 Jul 2017 16:28:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cHdh3Xdq1GuvHrSJtBCqac1UTv3RHPFBU" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 15:29:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cHdh3Xdq1GuvHrSJtBCqac1UTv3RHPFBU Content-Type: multipart/mixed; boundary="f0csJaHvUQMmQuLVIKElBlQe1dVm8wnma"; protected-headers="v1" From: Stephen Farrell To: Kyle Rose Cc: Ted Lemon , "Polk, Tim (Fed)" , IETF TLS Message-ID: <9a5b276d-b1f2-bea9-19c1-d9eadf4da377@cs.tcd.ie> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> In-Reply-To: --f0csJaHvUQMmQuLVIKElBlQe1dVm8wnma Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 12/07/17 16:27, Kyle Rose wrote: > The telco in the POTS case isn't either endpoint. The third-party > surveillance is unknown to those endpoints. Therefore: wiretapping. Same in the wordpress.com or smtp/tls cases already described on list. Therefore: wiretapping. My point was that "collaborating" does not mean not wiretapping. Saying otherwise is what'd be silly. S. >=20 > Kyle >=20 --f0csJaHvUQMmQuLVIKElBlQe1dVm8wnma-- --cHdh3Xdq1GuvHrSJtBCqac1UTv3RHPFBU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZkA7AAoJEC88hzaAX42i2kMIALr8Jh4FSFo65CwHtKJEjHMp 8haMMD7ubUvjEFXleDnfEIlpe2mLjgueIGsGh+ao8WDJbLKMMOrDwbQUOO/kfwGu padyADdQb7hsjfKj3uIKibm+qTvf0eX21mM2h3jj+FeFAiM8R/axUou1WY5RYePq mjTvl3PMr9AIB0sZ7xIoxkjk9nlJ0WB/dVvwdBkDayxlE0/hKuE6LhqmbDDS7TYL xoO4tABwekX7OqlUs9JXp1IvPLSPff0U5j5UVdH4UQfHGBA4Qj7A7SmPaYVWa20o wuB15PF18I4aDTWIaD1FB5wB3vNFzIzozJKdQ9Z52l3nHrrQVUQ15x8/Amb+K5o= =4o6a -----END PGP SIGNATURE----- --cHdh3Xdq1GuvHrSJtBCqac1UTv3RHPFBU-- From nobody Wed Jul 12 08:54:35 2017 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 22EFD1316FF for ; Wed, 12 Jul 2017 08:54:34 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Xp7WmFSI2Pz7 for ; Wed, 12 Jul 2017 08:54:32 -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 2ACD013144F for ; Wed, 12 Jul 2017 08:54:32 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 32so16040833qtv.1 for ; Wed, 12 Jul 2017 08:54:32 -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=7HJfvz39zileIPMaof/0xV1pf+xlk+R1VKYtTJfi2Xc=; b=icIx978hU6paxIC+yJkFl2yg1r0dXxOpWlZgDlmMxU4TKghqZXoEoVea5MvGR1nNUh EsU/sHcirvP12dnooQ+j8VbUxokbNglRX6tOUNquGBzWRG0npUFUXUXCXkFyxd0LwRA9 Av0jZ2wB6SWLsBSPMIjw9re0ta5lMkH6Voi2s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7HJfvz39zileIPMaof/0xV1pf+xlk+R1VKYtTJfi2Xc=; b=NkepzLFcSKQqNOAXwpWDlzvZas4VQHhPECjNj4/kBqyrkbPFgH2F7MI7Tv1lq3RCYj nEn0IgPgHAOozMsgq1kM38r99tqhOUtTb/6Mxe+P5z7NjeW2GUcW9usZ9OWyq5DUvLRu gzsTXw+WE6O07BqKy3WgXz4djQ/M0mtSUVNCnJV+Hva1A2qaxhTE7LLtkpqxvDOE9AFI 7OwKNlZgV3MuPnKIm1m2vHgaJqB8WABXrsBR+RntlGIjPX8gqLa9tdR9sEWI650nQuNR kk1YqNjJk0mrN1jpuS2F8lVNuoKv7wnCu93OVbocEST2ilf64XDdvbClQgc8vGBt4tR4 uPgA== X-Gm-Message-State: AIVw112CDr6SYKANNJMRXjz1Fk/qVw9allHXGU6WlGv6ty6Og3VWmyX5 UF4mdEdentCNC363YHUeOp2QKGw5y+4cHDg= X-Received: by 10.200.40.150 with SMTP id i22mr6769330qti.59.1499874871243; Wed, 12 Jul 2017 08:54:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Wed, 12 Jul 2017 08:54:30 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <9a5b276d-b1f2-bea9-19c1-d9eadf4da377@cs.tcd.ie> References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <9a5b276d-b1f2-bea9-19c1-d9eadf4da377@cs.tcd.ie> From: Kyle Rose Date: Wed, 12 Jul 2017 11:54:30 -0400 Message-ID: To: Stephen Farrell Cc: Ted Lemon , "Polk, Tim (Fed)" , IETF TLS Content-Type: multipart/alternative; boundary="001a1141c2d6e88994055420d493" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 15:54:34 -0000 --001a1141c2d6e88994055420d493 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell wrote: > > > On 12/07/17 16:27, Kyle Rose wrote: > > The telco in the POTS case isn't either endpoint. The third-party > > surveillance is unknown to those endpoints. Therefore: wiretapping. > > Same in the wordpress.com or smtp/tls cases already > described on list. Therefore: wiretapping. > > My point was that "collaborating" does not mean not > wiretapping. Saying otherwise is what'd be silly. > And yet that's what 2804, what you have repeatedly cited, explicitly states. I'm going to go with the definition given there, "silly" or not. This isn't wiretapping: it's *something else* potentially bad, but not all surveillance is wiretapping. Kyle --001a1141c2d6e88994055420d493 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 12/07/17 16:27, Kyle Rose wrote:
> The telco in the POTS case isn't either endpoint. The third-party<= br> > surveillance is unknown to those endpoints. Therefore: wiretapping.
Same in the wordpress.com or smtp/tls cases already
described on list. Therefore: wiretapping.

My point was that "collaborating" does not mean not
wiretapping. Saying otherwise is what'd be silly.
=
And yet that's what 2804, what you have repeatedly cited= , explicitly states. I'm going to go with the definition given there, &= quot;silly" or not. This isn't wiretapping: it's *something el= se* potentially bad, but not all surveillance is wiretapping.

Kyle

--001a1141c2d6e88994055420d493-- From nobody Wed Jul 12 09:06:53 2017 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 9FB161316B9 for ; Wed, 12 Jul 2017 09:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.802 X-Spam-Level: X-Spam-Status: No, score=-9.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, 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=ml.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 coDLRzM1hpwz for ; Wed, 12 Jul 2017 09:06:49 -0700 (PDT) Received: from bankofamerica.com (rdnemail.bankofamerica.com [171.161.147.155]) (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 30DC312F3D6 for ; Wed, 12 Jul 2017 09:06:49 -0700 (PDT) Received: from txdmzmailmx07.bankofamerica.com ([171.180.168.234]) by lrdna0myxepmx02.bankofamerica.com (8.15.1/8.14.5) with ESMTP id v6CG6mkj002414 for ; Wed, 12 Jul 2017 16:06:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.com; s=corp1702; t=1499875608; bh=uBxv3vDZ4DWe4FccWsSaLk7WOUxKjUsq0xp/Up+SEj4=; h=Date:From:Subject:In-reply-to:To:Message-id:MIME-version: Content-type:Content-transfer-encoding:References; b=HweuM+BKa/huLsVuVJrR5mpUnvLc271QslrgEgwxh+2gTlsaYtF0IQmc4nyUheUk4 JbgMgdcqWVag1hdykKYdoAaYmq9e6TbMwZQe8ofIKNQaij7xxswPqfcJwEdu2+3PW7 0bHWIO8P2at/4LmrncgDCT9qYyoaMkRNjvGvG4R0= Received: from lrdna0n5xepmx13.bankofamerica.com (lrdna0n5xepmx13.bankofamerica.com [171.206.154.14]) by txdmzmailmx07.bankofamerica.com (8.15.1/8.14.5) with ESMTP id v6CG6k4j004635 for ; Wed, 12 Jul 2017 16:06:47 GMT Date: Wed, 12 Jul 2017 16:06:45 +0000 From: "Eydlin, Igor - PENNINGTON NJ" In-reply-to: X-Originating-IP: [171.206.3.32] To: "tls@ietf.org" Message-id: <59A768ECCBC05D4CAD5C6A2EDDD8075188DCD70B@smtp_mail.bankofamerica.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-language: en-US Content-transfer-encoding: 7BIT X-MS-Has-Attach: Accept-Language: en-US Thread-topic: TLS Digest, Vol 156, Issue 65 Thread-index: AQHS+yNtU3Ig9oamjU+RXdZeC6GoyaJQVyZA X-MS-TNEF-Correlator: x-bac-client-sensitivity: X2 References: X-Virus-Scanned: clamav-milter 0.98.7 at txdmzmailmx07.bankofamerica.com X-Virus-Status: Clean X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-12_05:, , signatures=0 Archived-At: Subject: Re: [TLS] TLS Digest, Vol 156, Issue 65 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 16:06:51 -0000 I agree that all political aspects should not be part of TLS WG discussions. TLS 1.3 is supposed to increase users(that include not only end point users but all the "evil" service providers, enterprises , ..)) security and privacy but not to avoid legal court of law judgments for private companies to provide information to law enforcement. That will be done without utilizing "wiretapping". Thank you, Igor Eydlin -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of tls-request@ietf.org Sent: Wednesday, July 12, 2017 11:27 AM To: tls@ietf.org Subject: TLS Digest, Vol 156, Issue 65 Send TLS mailing list submissions to tls@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=eagfdAHLcUjsGrQuWbCquOnjlxa-xY34_J43XOpnCGg&e= or, via email, send a message with subject or body 'help' to tls-request@ietf.org You can reach the person managing the list at tls-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TLS digest..." Today's Topics: 1. Re: chairs - please shutdown wiretapping discussion... (Kyle Rose) 2. Re: Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 (Sean Turner) 3. Re: chairs - please shutdown wiretapping discussion... (Ilari Liusvaara) 4. Re: chairs - please shutdown wiretapping discussion... (Stephen Farrell) 5. Re: chairs - please shutdown wiretapping discussion... (Kyle Rose) ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Jul 2017 10:45:18 -0400 From: Kyle Rose To: Ted Lemon Cc: Richard Barnes , IETF TLS Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: Content-Type: text/plain; charset="utf-8" On Wed, Jul 12, 2017 at 10:38 AM, Ted Lemon wrote: > On Jul 12, 2017, at 10:32 AM, Richard Barnes wrote: > > Oh, come on. You've never seen code in a library that implements > something that's not in an IETF RFC? > > > Of course I have. I think that putting a warning in the TLS 1.3 spec as > Christian suggested will mean that the code won't appear in places where > there isn't a strong use case for it. It may well appear in places where > there is a strong use case, but anything open source is going to face a > stiff headwind in terms of implementing this, and that's what I'm > suggesting we encourage. If it doesn't show up in openssl, gnutls or > boringssl, it's a much smaller problem. We can't actually stop it > happening?I'm just arguing for not making it convenient. > Knowing the people involved in at least some of those projects, there is very little chance of that happening. Beyond that lies political action, which is definitely not what the TLS WG mailing list should be used for. To your last email, I agree that we've mostly beaten this to death. I'm happy to let the conversation move elsewhere. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Wed, 12 Jul 2017 10:56:32 -0400 From: Sean Turner To: yinxinxing Cc: "tls@ietf.org" Subject: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 Message-ID: Content-Type: text/plain; charset=utf-8 > On Jul 6, 2017, at 23:04, yinxinxing wrote: > > Hi all, > > The NAT table expiring problem mentioned in the following email should also be considered in DTLS1.2 as an extension. > > The value and necessity are as follows. > > 1. Essentially, NAT expiring problem causing DTLS renegotiation with high power consumption is existing in DTLS 1.2. Even if we solve this in DTLS1.3, this problem still exist for products using DTLS1.2. > Currently, many IOT products using DTLS 1.2 are going to be deployed commercially, such as intelligent water/gas meter. These meters usually have limited battery and low cost. To be more accurate, the battery of the chip module of the intelligent water/gas meter are required to last for 10 years. These lead to an exercise strict control over the power consumption of the chip module. NAT expiring problem causing DTLS renegotiation with high power consumption is a bottleneck of these IOT devices. According to our experimental data, under the worst coverage level (ECL2), power consumption of the chip module when DTLS is embedded increases by nearly 60%. Therefore, there should be a solution to solve the urgent problem to match the low-cost and low-battery feature of the IOT devices in DTLS 1.2. I have to ask whether these IoT devices are updatable? > 2. DTLS 1.3 will be standardized in 2018, but the corresponding open source code will be available about one year later after the standardization. At present, large-scale commercial IOT industry deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope that the above problem could be solved in DTLS 1.2 as soon as possible. On this point, I?m hoping that you?ll be wrong ;). From the list of TLS implementations found here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_wiki_Implementations&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=6XdEipZFd5sHWy_5fW04oKE1b36o_YKc-yZqp2ky4BA&e= and assuming there is as much enthusiasm to implement DTLS1.3 as there was for TLS1.3 then I?m hoping that the DTLS implementations will be ready much sooner than a year after publication (they might be ready before the RFC is published). spt > Any comment is appreciated. > > Regards, > Yin Xinxing > > > ???: yinxinxing > ????: 2017?6?27? 16:28 > ???: 'Eric Rescorla' > ??: tls@ietf.org; Tobias Gondrom > ??: Re: [TLS] Yin Xinxing joins the TLS WG > > Thanks Eric, > > I have seen the CID scheme, and talked with Hannes(the author of the scheme). > > CID scheme is a good idea to solve the problem I mentioned. > > I think the length of CID (currently, it is 32 bits) can be longer so that it can support more DTLS sessions. It is known that for IOT scenario, 1 million connection is nothing. > > Regards, > Yin Xinxing > > ???: Eric Rescorla [mailto:ekr@rtfm.com] > ????: 2017?6?25? 21:33 > ???: yinxinxing > ??: tls@ietf.org; Xiongxiaochun > ??: Re: [TLS] Yin Xinxing joins the TLS WG > > Hi Yin, > > The usual solution to this is to add a connection id. Please see: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_dtls13-2Dspec_issues_6&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=5YWOYG8tcG7o_991Mf2zy24y1TW9TAfAtwFpcdh5Juo&e= > > -Ekr > > > > > On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing wrote: > Hello everyone, > > I am Yin Xinxing from Huawei company. I am glad to join the TLS WG. > > For the DLTS 1.3 draft, I am interested and have some ideas to talk with you. > > DTLS has a lot of application scenarios in IOT fields, but currently, there is some difficulty when DTLS 1.2 is applied to IOT devices, especially the battery-constrained IOT devices. > > For example, when the IOT device wakes up from sleep mode, the NAT table may have expired. > Then the IOT device has to establish a new DTLS session or at least launches a resume process with the server, the corresponding power consumption is too high for some power-constrained devices. > How can DTLS renegotiation be avoided in order to save battery? > > I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this problem and give a proper solution. > > Any comment or idea about this problem is welcome. > > Regards, > Yin Xinxing > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=eagfdAHLcUjsGrQuWbCquOnjlxa-xY34_J43XOpnCGg&e= > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=eagfdAHLcUjsGrQuWbCquOnjlxa-xY34_J43XOpnCGg&e= ------------------------------ Message: 3 Date: Wed, 12 Jul 2017 18:08:31 +0300 From: Ilari Liusvaara To: Christian Huitema Cc: Stephen Farrell , Ted Lemon , tls@ietf.org Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: <20170712150831.xdq2byvjxlkbf2p3@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8 On Tue, Jul 11, 2017 at 01:54:40PM -0700, Christian Huitema wrote: > On 7/11/2017 1:31 PM, Stephen Farrell wrote: > > > PS: There are also genuine performance reasons why the same > > DH public might be re-used in some cases, so there would be > > false positives in a survey to consider as well. > > Well, yes. The classic argument is performance. Saving the cost of > exponentiation, computing G^X once for many session instead of once per > session. But you reap most of the benefits of that optimization with a > fairly small number of repetitions. Performance alone is not a good > reason to use the key over extended period, not to share the exact same > key between all servers in a farm. The fact is that wide reuse of the > same (EC)DH private key does compromise the security of TLS -- including > an obvious issue with forward secrecy. Yes, the cost saturates very rapidly as the number of reuses increases. Even 100 reuses gets one within ~1% of asymptotic limit (half load). > In any case, I just submitted PR #1049 > (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_1049&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=YkJeOlVlo3Qx-uAKThkyEZUyfHt71R_O2sqFEKkVVK0&e= ). I didn't see this document the attack on integerity (full MITM attack) of the connection if attacker has aquired the DH share before the connection. -Ilari ------------------------------ Message: 4 Date: Wed, 12 Jul 2017 16:18:23 +0100 From: Stephen Farrell To: Kyle Rose , Ted Lemon Cc: "Polk, Tim (Fed)" , IETF TLS Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: Content-Type: text/plain; charset="utf-8" On 12/07/17 13:24, Kyle Rose wrote: > This proposal (and related proposals involving encrypting session keys to > inspection boxes, either in-band or OOB) violates condition 2 because one > endpoint would have to intentionally take action to deliver the session key > or private DH share to the third party. I agree if there are only two parties, i.e. some deployments of schemes like this wiretapping scheme, do not meet the definition of wiretapping in 2804. > If one endpoint is feeding > cryptographic material to a third party (the only way that information gets > out to the third party, vulnerabilities notwithstanding), they are > collaborating, not enabling wiretapping. That's nonsense. In the POTS case, telcos are collaborating with their local LEAs and that is wiretapping. Claiming that no deployment of this scheme (e.g. the SMTP or wordpress.com type ones already described on the list) meets the 2804 definition is just silly. S. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: ------------------------------ Message: 5 Date: Wed, 12 Jul 2017 11:27:09 -0400 From: Kyle Rose To: Stephen Farrell Cc: Ted Lemon , "Polk, Tim (Fed)" , IETF TLS Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: Content-Type: text/plain; charset="utf-8" On Wed, Jul 12, 2017 at 11:18 AM, Stephen Farrell wrote: > > If one endpoint is feeding > > cryptographic material to a third party (the only way that information > gets > > out to the third party, vulnerabilities notwithstanding), they are > > collaborating, not enabling wiretapping. > > That's nonsense. In the POTS case, telcos are collaborating > with their local LEAs and that is wiretapping. The telco in the POTS case isn't either endpoint. The third-party surveillance is unknown to those endpoints. Therefore: wiretapping. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=eagfdAHLcUjsGrQuWbCquOnjlxa-xY34_J43XOpnCGg&e= ------------------------------ End of TLS Digest, Vol 156, Issue 65 ************************************ ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. From nobody Wed Jul 12 09:18:56 2017 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 AF212129ACD for ; Wed, 12 Jul 2017 09:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-RCpwBmTRyH for ; Wed, 12 Jul 2017 09:18:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FAF1250B8 for ; Wed, 12 Jul 2017 09:18:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3D96BBE74; Wed, 12 Jul 2017 17:18:50 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EroFVzTXd8Gs; Wed, 12 Jul 2017 17:18:50 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 03823BE6F; Wed, 12 Jul 2017 17:18:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499876330; bh=GUiK09ygkt9U93eVON5DPyzHgN1PZq5oh+U6mNg8gA0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ECTC64VpaH1jIvSv7R6Wmh/sL8aJRDDFlZHkc0fb3Lh6Px4FIuJHQj6r1apG4dVJE QSyaof3pVrl802Tt/Bu+TmCoUgPnvSp1qabBL9pBr8iCaxXfNLoqX8R8BZr4Y6tz88 gVhOIRwE8mIXRrtVfNRGTFr5MVSkDC8MnpQdpEwk= To: Kyle Rose Cc: Ted Lemon , "Polk, Tim (Fed)" , IETF TLS References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <9a5b276d-b1f2-bea9-19c1-d9eadf4da377@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 12 Jul 2017 17:18:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7oJGckvV5pt3pdG2M83eubmCDVEJGWcAV" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 16:18:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7oJGckvV5pt3pdG2M83eubmCDVEJGWcAV Content-Type: multipart/mixed; boundary="mCDaS4g85RrX8B5HroGNKxbCVD8DHnQFg"; protected-headers="v1" From: Stephen Farrell To: Kyle Rose Cc: Ted Lemon , "Polk, Tim (Fed)" , IETF TLS Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <9a5b276d-b1f2-bea9-19c1-d9eadf4da377@cs.tcd.ie> In-Reply-To: --mCDaS4g85RrX8B5HroGNKxbCVD8DHnQFg Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 12/07/17 16:54, Kyle Rose wrote: > On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell > wrote: >=20 >> >> >> On 12/07/17 16:27, Kyle Rose wrote: >>> The telco in the POTS case isn't either endpoint. The third-party >>> surveillance is unknown to those endpoints. Therefore: wiretapping. >> >> Same in the wordpress.com or smtp/tls cases already >> described on list. Therefore: wiretapping. >> >> My point was that "collaborating" does not mean not >> wiretapping. Saying otherwise is what'd be silly. >> >=20 > And yet that's what 2804, what you have repeatedly cited, explicitly > states. I'm going to go with the definition given there, "silly" or not= =2E The definition in 2804 is not silly, nor did I say it was. I said your implication that "collaboration" =3D> "not wiretapping" was silly. > This isn't wiretapping: it's *something else* potentially bad, but not = all > surveillance is wiretapping. Not all surveillance is wiretapping, sure, that is true. What is also true is that the draft being discussed is entirely clearly usable for wiretapping in some applications that use TLS according to the definition in 2804. S. >=20 > Kyle >=20 --mCDaS4g85RrX8B5HroGNKxbCVD8DHnQFg-- --7oJGckvV5pt3pdG2M83eubmCDVEJGWcAV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZkvpAAoJEC88hzaAX42iuuEH/3TxSKDVJvrqcMj6pRS/MzPN /vAoPit48A/zqmQ1bUG05tw5ZG+YZ/Ha5uedOOgMXy5uPL/FYlDkf6oVrKWM0r8o bgFiPUaZdtF3RMGfSteTFOHTyyVWoqt/L3hDxzXS2oOIYTkf6Zijroml/L3dJP7N ct1nDeb76p8mqE57g/ADvyH2BE3P84Cwt+p83rWLxDq37poolYZTkY7BNBACQFID CFBaJGzdtCxK9/Q6/YsZpSVh0H2cjE1SjhMjgJiV+5e25dLANR4yOgJd4haPt2Fw dO6HTqpJGYLDXUZWrNIOnp9OHSjc5CLh6LBn1M54UGBljv6X04wi+tWexLL3mK0= =ESkH -----END PGP SIGNATURE----- --7oJGckvV5pt3pdG2M83eubmCDVEJGWcAV-- From nobody Wed Jul 12 10:08:54 2017 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 A9781129AD1 for ; Wed, 12 Jul 2017 10:08:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xQeUGg9tW8vW for ; Wed, 12 Jul 2017 10:08:49 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D402126B7E for ; Wed, 12 Jul 2017 10:08:49 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id y129so3715595pgy.3 for ; Wed, 12 Jul 2017 10:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hasHG9sE+dNellLlvO5rYOx9n35zPdoc8XbOzsapfJ0=; b=R5y5DDwwDnUUYvlc4yD6Xr8G1ia1tyA/mjwyHlYM3Wkw52pr/9J/cPxPVKtIwZXbtD IsblDknvviJHsjnXU3w3YJCd+Ojssr6X4AokfedRYADtgfdLNR5q2PitxB1HiLo5ttE8 06qstNkKUwh5yuxw1in79EWxbThSlBg2c6rjSJzvHF7XvFWqPygZXrZamZtwmKGSDSwC kr66z7am9XiVDfHEC0UbXbeWFWlAWsc+4MAXLOkpAIEWNSgsrbtA1Cyyg7WOTyUUmT2E fzMom6WhQkKpgspbUfwodYtymK5f94ixCgT5qEJAa3o0o+mwy3nzHJR+8gPC/GQMbigm mY1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hasHG9sE+dNellLlvO5rYOx9n35zPdoc8XbOzsapfJ0=; b=nnUSTDczFtiLnSsD04N9KD3whNg+SMppjjK6CbwNfnfTRIQOF3NHWMXXExLKneKWiN ZVueYprL8FXxHID0zqvewOM4zi8LbX2AQ6hKmwm1purFyNlwcghxN52EZK+3SU49BwOK mRURysheq/yJT4fGcGl9SdN7x8AVVA46oOEe+5jR5VWG+D9TLrww1ebhtNkdnG46zCi4 Lsl/VEmmpLFXIl6zPN5FMt4Rkk2efvLXg4c6S905thEttC6STrfFgQsyX41bAwww39m/ TBBAr3TpLarSLRXvhbsH/kWYk5usWNhW37+kh/2df6MYrpk7eQ928SrMQ6Qx2lY5xaUr a2lg== X-Gm-Message-State: AIVw112XhJoZ109StMHCc86Tzd8+raaWUrsSNndrmT6iq3Ve1SvIB74i +TGWhzIwRXVOVQ== X-Received: by 10.99.156.18 with SMTP id f18mr4850132pge.25.1499879329014; Wed, 12 Jul 2017 10:08:49 -0700 (PDT) Received: from prome-1n-dhcp2-133.eng.vmware.com ([208.91.1.34]) by smtp.gmail.com with ESMTPSA id o24sm6316803pfk.116.2017.07.12.10.08.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 10:08:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dan Wing In-Reply-To: Date: Wed, 12 Jul 2017 10:08:46 -0700 Cc: "tls@ietf.org" , Sean Turner Content-Transfer-Encoding: quoted-printable Message-Id: <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com> References: To: yinxinxing X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 17:08:52 -0000 > On Jul 12, 2017, at 7:56 AM, Sean Turner wrote: >=20 >=20 >> On Jul 6, 2017, at 23:04, yinxinxing wrote: >>=20 >> Hi all, >>=20 >> The NAT table expiring problem mentioned in the following email = should also be considered in DTLS1.2 as an extension. >>=20 >> The value and necessity are as follows. >>=20 >> 1. Essentially, NAT expiring problem causing DTLS renegotiation with = high power consumption is existing in DTLS 1.2. Even if we solve this in = DTLS1.3, this problem still exist for products using DTLS1.2. >> Currently, many IOT products using DTLS 1.2 are going to be deployed = commercially, such as intelligent water/gas meter. These meters usually = have limited battery and low cost. To be more accurate, the battery of = the chip module of the intelligent water/gas meter are required to last = for 10 years. These lead to an exercise strict control over the power = consumption of the chip module. NAT expiring problem causing DTLS = renegotiation with high power consumption is a bottleneck of these IOT = devices. According to our experimental data, under the worst coverage = level (ECL2), power consumption of the chip module when DTLS is embedded = increases by nearly 60%. Therefore, there should be a solution to solve = the urgent problem to match the low-cost and low-battery feature of the = IOT devices in DTLS 1.2. >=20 > I have to ask whether these IoT devices are updatable? >=20 >> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open = source code will be available about one year later after the = standardization. At present, large-scale commercial IOT industry = deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope = that the above problem could be solved in DTLS 1.2 as soon as possible. >=20 > On this point, I=E2=80=99m hoping that you=E2=80=99ll be wrong ;). = =46rom the list of TLS implementations found here: > https://github.com/tlswg/tls13-spec/wiki/Implementations > and assuming there is as much enthusiasm to implement DTLS1.3 as there = was for TLS1.3 then I=E2=80=99m hoping that the DTLS implementations = will be ready much sooner than a year after publication (they might be = ready before the RFC is published). Yin Xinxing, While waiting for cid, perhaps today do session resumption (RFC5077), = anytime the client has reason to suspect their UDP port or IP address = might have changed -- such as it's been longer than, say, 30 seconds = since last UDP transmission. (The problem isn't solely NAT; there are = several ISPs that change subscriber's IP address, also forcing = re-negotiation of DTLS security association. Less frequent than NATs = timing out UDP, of course.) -d > spt >=20 >> Any comment is appreciated. >>=20 >> Regards, >> Yin Xinxing >>=20 >>=20 >> =E5=8F=91=E4=BB=B6=E4=BA=BA: yinxinxing=20 >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8827=E6=97=A5= 16:28 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric Rescorla' >> =E6=8A=84=E9=80=81: tls@ietf.org; Tobias Gondrom >> =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG >>=20 >> Thanks Eric, >>=20 >> I have seen the CID scheme, and talked with Hannes(the author of the = scheme). >>=20 >> CID scheme is a good idea to solve the problem I mentioned. >>=20 >> I think the length of CID (currently, it is 32 bits) can be longer so = that it can support more DTLS sessions. It is known that for IOT = scenario, 1 million connection is nothing. >>=20 >> Regards, >> Yin Xinxing >>=20 >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]=20 >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8825=E6=97=A5= 21:33 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing >> =E6=8A=84=E9=80=81: tls@ietf.org; Xiongxiaochun >> =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG >>=20 >> Hi Yin, >>=20 >> The usual solution to this is to add a connection id. Please see: >> https://github.com/tlswg/dtls13-spec/issues/6 >>=20 >> -Ekr >>=20 >>=20 >>=20 >>=20 >> On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing = wrote: >> Hello everyone, >>=20 >> I am Yin Xinxing from Huawei company. I am glad to join the TLS WG. >>=20 >> For the DLTS 1.3 draft, I am interested and have some ideas to talk = with you. >>=20 >> DTLS has a lot of application scenarios in IOT fields, but currently, = there is some difficulty when DTLS 1.2 is applied to IOT devices, = especially the battery-constrained IOT devices. >>=20 >> For example, when the IOT device wakes up from sleep mode, the NAT = table may have expired. >> Then the IOT device has to establish a new DTLS session or at least = launches a resume process with the server, the corresponding power = consumption is too high for some power-constrained devices.=20 >> How can DTLS renegotiation be avoided in order to save battery? >>=20 >> I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this = problem and give a proper solution. =20 >>=20 >> Any comment or idea about this problem is welcome. >>=20 >> Regards, >> Yin Xinxing >>=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 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 12 13:01:27 2017 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 15CA3131946 for ; Wed, 12 Jul 2017 13:01: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, 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 O7o8E9eSpXt7 for ; Wed, 12 Jul 2017 13:01:22 -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 2933F1317B8 for ; Wed, 12 Jul 2017 13:01:22 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id 62so4375973wmw.1 for ; Wed, 12 Jul 2017 13:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PNKV38tpcNe/XdnQ3Anjgi7jEPyoXtcSj3lYPzIbNsQ=; b=uBrt4zYG1YaQinRqQX2yxUDaDsgAPfSawNDsC5FZKZ/JtlymmDpwb0nN7CDpbOdMEd pKbUrB/eMPjhSU4Hb2OGwlNJb48bgEH7T1W40yVzxKtkVs8m+kLN2uJ3xbC9SsiNx0CN mjcC703e8efYa0SOKxASZMU5eq5xshqBEt2SNzOaxZqP41XPfMdhfH5RyEtDE6wKqgtM rYeGLGD2pMQY1S4IWLjdUCA/1uA2YfyNF7hBSjD+G13ZfxvUvkPnjiH0rzuD5btrmb6t UPLOAjjU0lC2Mfga7aCEIJlIwJzFqJ78UfOePXHMHJhOcSF+DaVGx63BLMa87vRU6zwB 8IiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PNKV38tpcNe/XdnQ3Anjgi7jEPyoXtcSj3lYPzIbNsQ=; b=PQ+Mq8CmXu6j4Vr+fm/OX1h3TqCYoOh6l5bsY0onywqcXhU/E0tCUJWTJ22CAacoR8 2RAkJwodTLFLkq8NRFEGyMuK/1VlDGdyA6XK9S4bXuBAZsrsReEdQdEacPYLhoW76s4A 59m/ynIosoMT+9wx2/EkhRnGJACsBrad3vw17De13s3XvL/OUK6Ohd8Hzc57ssGXpOZL MpigHRr/qjWE0xp/x0vL8JWFWaVzsHo5jPY9ZEXrtXAIxydReJsDtNeW98ZyyVZWG/OO M3qTUJ/KeU8bfFpGXVZTINKBDrUmeB/fHfQyMpi8jGt5a/HxptAXwnwMaB2cj4dC8Wc6 +aUg== X-Gm-Message-State: AIVw111lJjrB57WeLDTWdkGoiaFuBPGVZj8jOwaPqUsydfpPtIQH0hEH dJUVfEdffOlkLg== X-Received: by 10.28.8.144 with SMTP id 138mr3921118wmi.8.1499889680723; Wed, 12 Jul 2017 13:01:20 -0700 (PDT) Received: from [10.0.6.178] ([62.168.35.66]) by smtp.gmail.com with ESMTPSA id w30sm4333468wrb.49.2017.07.12.13.01.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 13:01:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Wed, 12 Jul 2017 22:01:18 +0200 Cc: Kyle Rose , "Polk, Tim (Fed)" , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <9a5b276d-b1f2-bea9-19c1-d9eadf4da377@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 20:01:24 -0000 With no hat on... Sent from my iPhone > On Jul 12, 2017, at 6:18 PM, Stephen Farrell w= rote: >=20 >=20 >=20 >> On 12/07/17 16:54, Kyle Rose wrote: >> On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell >> wrote: >>=20 >>>=20 >>>=20 >>>> On 12/07/17 16:27, Kyle Rose wrote: >>>> The telco in the POTS case isn't either endpoint. The third-party >>>> surveillance is unknown to those endpoints. Therefore: wiretapping. >>>=20 >>> Same in the wordpress.com or smtp/tls cases already >>> described on list. Therefore: wiretapping. >>>=20 >>> My point was that "collaborating" does not mean not >>> wiretapping. Saying otherwise is what'd be silly. >>>=20 >>=20 >> And yet that's what 2804, what you have repeatedly cited, explicitly >> states. I'm going to go with the definition given there, "silly" or not. >=20 > The definition in 2804 is not silly, nor did I say it was. >=20 > I said your implication that "collaboration" =3D> "not > wiretapping" was silly. >=20 >> This isn't wiretapping: it's *something else* potentially bad, but not al= l >> surveillance is wiretapping. >=20 > Not all surveillance is wiretapping, sure, that is > true. >=20 The difference with the WordPress & SMTP examples is that you know content w= ill sit in plaintext on the servers, whereas with POTS, you need to wiretap t= o get the voice content. You only expect the log that the call transpired to= exist with the service provider. I'm still in a mode of listening to arguments, but wanted to point this out= in case better examples emerged. Thanks, Kathleen=20 > What is also true is that the draft being discussed > is entirely clearly usable for wiretapping in some > applications that use TLS according to the definition > in 2804. >=20 > S. >=20 >=20 >>=20 >> Kyle >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 12 13:16:15 2017 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 1B8911316A5 for ; Wed, 12 Jul 2017 13:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVvxsZOSZG-g for ; Wed, 12 Jul 2017 13:16:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00E012EC3A for ; Wed, 12 Jul 2017 13:16:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 08D35BE5F; Wed, 12 Jul 2017 21:16:10 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IvBb-J7nzHL; Wed, 12 Jul 2017 21:16:08 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 40425BE58; Wed, 12 Jul 2017 21:16:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499890568; bh=nAvwvuwnE7fYR0Ye/fqXN7lTgfuElN4O8030QSe0VrE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EJQloBBioYr2yOmSc3N+cHVpAiZQ6RhmrizbX0YnIVM6n5BQ+t9FtIpBDOt6VP88P hJmoAcs1jc0rVfka78nccBTFXymofo6bamMv2572FMyBQHeQEHbvJsT9zeHmoombbq jGNhYfEXspJwuxvUOWsu2YsRqBri9usHSfR1SwjM= To: Kathleen Moriarty Cc: Kyle Rose , "Polk, Tim (Fed)" , IETF TLS References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <9a5b276d-b1f2-bea9-19c1-d9eadf4da377@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 12 Jul 2017 21:16:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XIG1A16IvHqLRfNNpt97hjC8qqhIciENW" Archived-At: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 20:16:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XIG1A16IvHqLRfNNpt97hjC8qqhIciENW Content-Type: multipart/mixed; boundary="EMxxlV6aHSAXGSEFTbGXsu4HgpoCsFkTu"; protected-headers="v1" From: Stephen Farrell To: Kathleen Moriarty Cc: Kyle Rose , "Polk, Tim (Fed)" , IETF TLS Message-ID: Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... References: <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <9a5b276d-b1f2-bea9-19c1-d9eadf4da377@cs.tcd.ie> In-Reply-To: --EMxxlV6aHSAXGSEFTbGXsu4HgpoCsFkTu Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 12/07/17 21:01, Kathleen Moriarty wrote: > With no hat on... >=20 > The difference with the WordPress & SMTP examples is that you know > content will sit in plaintext on the servers, whereas with POTS, you > need to wiretap to get the voice content. You only expect the log > that the call transpired to exist with the service provider. Sure POTS !=3D the web or smtp, though 2804 specifically calls out pen-traces as being covered, so we're not only dealing with bulk call content. But in any case the precise mechanisms used to get the pen-trace equivalent or the bulk content to the wiretapper as cleartext isn't really significant - whether that be via a carload of tapes, a fat pipe from the MTA or wordpress.com-like site to the wiretapper, or via a few KB-per-DH-private if the wiretapper already has the bulk ciphertext in hand. The crucial thing here is that the leak of the DH private values is needed to enable that ciphertext to be rendered as plain, and this proposed mechanism is how that part of the wiretap service would be enabled, and that's why these examples fit the 2804 definition. Put another way - it doesn't matter if a traditional POTs wiretap is done via a conference call setup (frequently done) or by actually recording to a tape device as was done in the past. And just the same, it doesn't matter that the mail or web content is also available as plaintext to the leaker of the DH private value. All of those can be used to provide a wiretap service as per the 2804 definitions. (In fact a wiretap based on leaking DH private values would be much more efficient for an entity that already has the capability to capture packets are lots of places on the Internet, but that's not that important in terms of whether the 2804 term is right or not.) Does that help? Cheers, S. >=20 > I'm still in a mode of listening to arguments, but wanted to point > this out in case better examples emerged. >=20 > Thanks, Kathleen >=20 >=20 >> What is also true is that the draft being discussed is entirely >> clearly usable for wiretapping in some applications that use TLS >> according to the definition in 2804. >>=20 >> S. >>=20 >>=20 >>>=20 >>> Kyle >>>=20 >>=20 >> _______________________________________________ TLS mailing list=20 >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --EMxxlV6aHSAXGSEFTbGXsu4HgpoCsFkTu-- --XIG1A16IvHqLRfNNpt97hjC8qqhIciENW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZoOHAAoJEC88hzaAX42i6WMH/2PVBnoVBshfY09XCO4FJphQ n8WlZ10roo3FJ6XijoU7QK+oGRkU6GzJtPH0u9kA9y+IpEQ9dCZnggQlLuVtVxiD RCg4fyCE/o6MT07wHRMeub5BSlfNYzs2+hcEk6wfIGCwk32X8op0ekVm1wh2yw/B n+pE6CX4hhbG9A9yJ736GCe7J0nYL6rqys4hdKBoBg9+0vfVWpZXi7rcnFwOrHDT pGvY31K2P5tRYS4MJZVFkZxXKiJfYDveSFRNhmJZXPQ0BUvGodrTNeYxx+njDULK jzMr1BOozAHZrWAKkxvn/FYRd8jlMdUyzuTi5vQ5BaaErHyH63X1JEeHwfqHvX0= =4Sut -----END PGP SIGNATURE----- --XIG1A16IvHqLRfNNpt97hjC8qqhIciENW-- From nobody Wed Jul 12 15:39:27 2017 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 D481D12F26D for ; Wed, 12 Jul 2017 15:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 44lzc3b2PQOc for ; Wed, 12 Jul 2017 15:39:23 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 CC5E112EB8C for ; Wed, 12 Jul 2017 15:39:14 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6CMasVS023941; Wed, 12 Jul 2017 23:39:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=PZfr/K1/5+brHp0DfsIAszmG1Y2XYzlt897VlkpO/pk=; b=T18LRzQuJfc/K37GGVOxXaQf2rZWpr325kqsfElubR3aA9t8YMIyBTjDB+0yllnP8fNB APqw4Z/tTdp/CruxyAgHMbi9EwP2EOcx3IN0a3a+hCJWDCX3l/uuokY6kHplGfIsnsMR gtWteWlKagpd3czX1mQJbWvPBa+KuIG8QogUreID6VUcOMzK644pdTWHHcz3AdXByipG wubxS/CKTLF7jdoJ7T941k9HTQy6g7IdCH9piXgqlPpF/rylC2qcMjqwU11/dTZy4T9Z sBleLJpy0K4Z43HJEoBnYsk2PvgnXPZiM3CYw6nta2MszJ7hrXFKg+N6V+PdJHhBgw1T qA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bn0p3pu05-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jul 2017 23:39:12 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6CMaLSu001559; Wed, 12 Jul 2017 18:39:11 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bn0p1v6es-1; Wed, 12 Jul 2017 18:39:11 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 4C3571FC7B; Wed, 12 Jul 2017 22:39:11 +0000 (GMT) To: Eric Rescorla Cc: Sean Turner , "" References: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com> From: Benjamin Kaduk Message-ID: <752c2b4e-fb24-6857-ac88-e42504029dd6@akamai.com> Date: Wed, 12 Jul 2017 17:39:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6C5DBF9EF3D8494EBD2AAAAA" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-12_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707120360 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-12_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707120359 Archived-At: Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2017 22:39:26 -0000 This is a multi-part message in MIME format. --------------6C5DBF9EF3D8494EBD2AAAAA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/11/2017 03:50 PM, Eric Rescorla wrote: > > > On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk > wrote: > > > Another question I also relates to 0-RTT, specifically with the > freshness checks and the case where the computed > expected_arrival_time is in outside "the window" by virtue of > being in the future. (See the Note: at the end of section 8.2.) > (The case where the expected_arrival_time is in the past can > clearly be treated as "this is a stale request" and the current > text about aborting with "illegal_parameter" or rejecting 0-RTT > but accepting the PSK is acceptable, even if it doesn't give > guidance as to what might cause someone to pick one behavior or > the other.) I am wondering whether we should consider this to be > a potential attack and abort the connection. I concede that there > are likely to be cases where this > situation occurs incidentally, for clients with extremely > fast-running clocks, and potential timezone/suspend-resume > weirdness. But there is also the potential for a client that > deliberately lies about its ticket age and intends to replay the > wire messages when the age becomes in window, or an attacker that > records the messages and knows that the client's clock is too > fast, or other cases. (A client that deliberately does this could > of course just send the same application data later as well.) If > the time is only a few seconds out of the window, then delaying a > response until it is in the window and only then entering it into > the single-use cache might be reasonable, but if the time is very > far in the future, do we really want to try to succeed in that case? > > > If the time is very far in the future, the text is supposed to tell > you to fall back > to 1-RTT... > I agree that that is what the text currently says. I'm questioning whether that's actually the behavior we want. That is, in this case, the CH+0RTT data can be replayed by an observer once enough time has elapsed that the expected_arrival_time is within the window, similar to one of the reordering attacks mentioned elsewhere. We could add the CH to the strike register in this case, which would bloat its storage somewhat and have entries that take longer than the window to expire out. I don't have a good sense for how often we expect postdated CHs to occur and whether the ensuing breakage would be manageable, but I'm not sure that we've thought very hard as a group about this question. > > > It looks like we no longer do anything to obsolete/reserve/similar > the HashAlgorithm and SignatureAlgorithm registries; was that just > an editorial mixup or an intended change? > > > https://tlswg.github.io/draft-ietf-tls-iana-registry-updates/#orphaned-registries > > Oh right, I forgot about that -- thanks. > > We removed the API guidance for separate APIs for read/writing > early data versus regular data, which I believe had consensus. > But I thought we were going to say something carefully worded > about having an API to determine whether the handshake has > completed (or client Finished has been validated, or ...), and it > looks like this is buried at the end of E.5(.0), with the string > "API" not appearing. It might be useful to make this a little > more prominent/discoverable, whether by subsection heading or > otherwise. > > > Suggestions welcome for where this would be better.... > I'll see if I have time to think about it some more. -Ben --------------6C5DBF9EF3D8494EBD2AAAAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/11/2017 03:50 PM, Eric Rescorla wrote:


On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:

Another question I also relates to 0-RTT, specifically with the freshness checks and the case where the computed expected_arrival_time is in outside "the window" by virtue of being in the future. (See the Note: at the end of section 8.2.) (The case where the expected_arrival_time is in the past can clearly be treated as "this is a stale request" and the current text about aborting with "illegal_parameter" or rejecting 0-RTT but accepting the PSK is acceptable, even if it doesn't give guidance as to what might cause someone to pick one behavior or the other.)  I am wondering whether we should consider this to be a potential attack and abort the connection.  I concede that there are likely to be cases where this
situation occurs incidentally, for clients with extremely fast-running clocks, and potential timezone/suspend-resume weirdness.  But there is also the potential for a client that deliberately lies about its ticket age and intends to replay the wire messages when the age becomes in window, or an attacker that records the messages and knows that the client's clock is too fast, or other cases.  (A client that deliberately does this could of course just send the same application data later as well.)  If the time is only a few seconds out of the window, then delaying a response until it is in the window and only then entering it into the single-use cache might be reasonable, but if the time is very far in the future, do we really want to try to succeed in that case?

If the time is very far in the future, the text is supposed to tell you to fall back
to 1-RTT...


I agree that that is what the text currently says.  I'm questioning whether that's actually the behavior we want.

That is, in this case, the CH+0RTT data can be replayed by an observer once enough time has elapsed that the expected_arrival_time is within the window, similar to one of the reordering attacks mentioned elsewhere.  We could add the CH to the strike register in this case, which would bloat its storage somewhat and have entries that take longer than the window to expire out.

I don't have a good sense for how often we expect postdated CHs to occur and whether the ensuing breakage would be manageable, but I'm not sure that we've thought very hard as a group about this question.




It looks like we no longer do anything to obsolete/reserve/similar the HashAlgorithm and SignatureAlgorithm registries; was that just an editorial mixup or an intended change?



Oh right, I forgot about that -- thanks.


We removed the API guidance for separate APIs for read/writing early data versus regular data, which I believe had consensus.  But I thought we were going to say something carefully worded about having an API to determine whether the handshake has completed (or client Finished has been validated, or ...), and it looks like this is buried at the end of E.5(.0), with the string "API" not appearing.  It might be useful to make this a little more prominent/discoverable, whether by subsection heading or otherwise.

Suggestions welcome for where this would be better....


I'll see if I have time to think about it some more.

-Ben
--------------6C5DBF9EF3D8494EBD2AAAAA-- From nobody Wed Jul 12 17:21:34 2017 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 B36AE131703 for ; Wed, 12 Jul 2017 17:21:32 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ACL9DWP4O4o1 for ; Wed, 12 Jul 2017 17:21:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420DF126CC4 for ; Wed, 12 Jul 2017 17:21:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQZ76562; Thu, 13 Jul 2017 00:21:27 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Jul 2017 01:21:26 +0100 Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by nkgeml412-hub.china.huawei.com (10.98.56.73) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 13 Jul 2017 08:21:23 +0800 Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.203]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0301.000; Thu, 13 Jul 2017 08:21:20 +0800 From: yinxinxing To: Dan Wing CC: "tls@ietf.org" , Sean Turner Thread-Topic: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 Thread-Index: AdL2zV5W/HDgxBACQSqQFOyDPszOzQEDqAMAAASeQgAAH2kMQA== Date: Thu, 13 Jul 2017 00:21:20 +0000 Message-ID: References: <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com> In-Reply-To: <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5966BD07.00F1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.203, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7c9b4d1e7dd2418be352d6763ee8b7a5 Archived-At: Subject: [TLS] =?utf-8?b?562U5aSNOiAgU29sdmluZyB0aGUgTkFUIGV4cGlyaW5nIHBy?= =?utf-8?q?oblem_causing_DTLS_renegotiation_with_high_power_consumption_in?= =?utf-8?q?_DTLS1=2E2?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 00:21:33 -0000 SGkgRGFuIFdpbmcsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KUGxlYXNlIHNlZSBt eSBjb21tZW50cyBpbmxpbmUuDQoNClJlZ2FyZHMsDQpZaW4gWGlueGluZw0KDQotLS0tLemCruS7 tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IERhbiBXaW5nIFttYWlsdG86ZGFud2luZ0BnbWFpbC5j b21dIA0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0N+aciDEz5pelIDE6MDkNCuaUtuS7tuS6ujogeWlu eGlueGluZw0K5oqE6YCBOiB0bHNAaWV0Zi5vcmc7IFNlYW4gVHVybmVyDQrkuLvpopg6IFJlOiBb VExTXSBTb2x2aW5nIHRoZSBOQVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVzaW5nIERUTFMgcmVuZWdv dGlhdGlvbiB3aXRoIGhpZ2ggcG93ZXIgY29uc3VtcHRpb24gaW4gRFRMUzEuMg0KDQoNCj4gT24g SnVsIDEyLCAyMDE3LCBhdCA3OjU2IEFNLCBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+IHdy b3RlOg0KPiANCj4gDQo+PiBPbiBKdWwgNiwgMjAxNywgYXQgMjM6MDQsIHlpbnhpbnhpbmcgPHlp bnhpbnhpbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpIGFsbCwNCj4+IA0KPj4gVGhl IE5BVCB0YWJsZSBleHBpcmluZyBwcm9ibGVtIG1lbnRpb25lZCBpbiB0aGUgIGZvbGxvd2luZyBl bWFpbCBzaG91bGQgYWxzbyBiZSBjb25zaWRlcmVkIGluIERUTFMxLjIgYXMgYW4gZXh0ZW5zaW9u Lg0KPj4gDQo+PiBUaGUgdmFsdWUgYW5kIG5lY2Vzc2l0eSBhcmUgYXMgZm9sbG93cy4NCj4+IA0K Pj4gMS4gRXNzZW50aWFsbHksIE5BVCBleHBpcmluZyBwcm9ibGVtIGNhdXNpbmcgRFRMUyByZW5l Z290aWF0aW9uIHdpdGggaGlnaCBwb3dlciBjb25zdW1wdGlvbiBpcyBleGlzdGluZyBpbiBEVExT IDEuMi4gRXZlbiBpZiB3ZSBzb2x2ZSB0aGlzIGluIERUTFMxLjMsIHRoaXMgcHJvYmxlbSBzdGls bCBleGlzdCBmb3IgcHJvZHVjdHMgdXNpbmcgRFRMUzEuMi4NCj4+IEN1cnJlbnRseSwgbWFueSBJ T1QgcHJvZHVjdHMgdXNpbmcgRFRMUyAxLjIgYXJlIGdvaW5nIHRvIGJlIGRlcGxveWVkIGNvbW1l cmNpYWxseSwgc3VjaCBhcyBpbnRlbGxpZ2VudCB3YXRlci9nYXMgbWV0ZXIuIFRoZXNlIG1ldGVy cyB1c3VhbGx5IGhhdmUgbGltaXRlZCBiYXR0ZXJ5IGFuZCBsb3cgY29zdC4gVG8gYmUgbW9yZSBh Y2N1cmF0ZSwgdGhlIGJhdHRlcnkgb2YgdGhlIGNoaXAgbW9kdWxlIG9mIHRoZSBpbnRlbGxpZ2Vu dCB3YXRlci9nYXMgbWV0ZXIgYXJlIHJlcXVpcmVkIHRvIGxhc3QgZm9yIDEwIHllYXJzLiBUaGVz ZSBsZWFkIHRvIGFuIGV4ZXJjaXNlIHN0cmljdCBjb250cm9sIG92ZXIgdGhlIHBvd2VyIGNvbnN1 bXB0aW9uIG9mIHRoZSBjaGlwIG1vZHVsZS4gTkFUIGV4cGlyaW5nIHByb2JsZW0gY2F1c2luZyBE VExTIHJlbmVnb3RpYXRpb24gd2l0aCBoaWdoIHBvd2VyIGNvbnN1bXB0aW9uIGlzIGEgYm90dGxl bmVjayBvZiB0aGVzZSBJT1QgZGV2aWNlcy4gQWNjb3JkaW5nIHRvIG91ciBleHBlcmltZW50YWwg ZGF0YSwgdW5kZXIgdGhlIHdvcnN0IGNvdmVyYWdlIGxldmVsIChFQ0wyKSwgcG93ZXIgY29uc3Vt cHRpb24gb2YgdGhlIGNoaXAgbW9kdWxlIHdoZW4gRFRMUyBpcyBlbWJlZGRlZCBpbmNyZWFzZXMg YnkgbmVhcmx5IDYwJS4gVGhlcmVmb3JlLCB0aGVyZSBzaG91bGQgYmUgYSBzb2x1dGlvbiB0byBz b2x2ZSB0aGUgdXJnZW50IHByb2JsZW0gdG8gbWF0Y2ggdGhlIGxvdy1jb3N0IGFuZCBsb3ctYmF0 dGVyeSBmZWF0dXJlIG9mIHRoZSBJT1QgZGV2aWNlcyBpbiBEVExTIDEuMi4NCj4gDQo+IEkgaGF2 ZSB0byBhc2sgd2hldGhlciB0aGVzZSBJb1QgZGV2aWNlcyBhcmUgdXBkYXRhYmxlPw0KPiANCj4+ IDIuIERUTFMgMS4zIHdpbGwgYmUgc3RhbmRhcmRpemVkIGluIDIwMTgsIGJ1dCB0aGUgY29ycmVz cG9uZGluZyBvcGVuIHNvdXJjZSBjb2RlIHdpbGwgYmUgYXZhaWxhYmxlIGFib3V0IG9uZSB5ZWFy IGxhdGVyIGFmdGVyIHRoZSBzdGFuZGFyZGl6YXRpb24uIEF0IHByZXNlbnQsIGxhcmdlLXNjYWxl IGNvbW1lcmNpYWwgSU9UIGluZHVzdHJ5IGRlcGxveW1lbnQgaXMgdXJnZW50LCBpdCBpcyB0b28g bGF0ZSB0byB3YWl0IGZvciBEVExTIDEuMy4gVGh1cywgd2UgaG9wZSB0aGF0IHRoZSBhYm92ZSBw cm9ibGVtIGNvdWxkIGJlIHNvbHZlZCBpbiBEVExTIDEuMiBhcyBzb29uIGFzIHBvc3NpYmxlLg0K PiANCj4gT24gdGhpcyBwb2ludCwgSeKAmW0gaG9waW5nIHRoYXQgeW914oCZbGwgYmUgd3Jvbmcg OykuIEZyb20gdGhlIGxpc3Qgb2YgVExTIGltcGxlbWVudGF0aW9ucyBmb3VuZCBoZXJlOg0KPiBo dHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy93aWtpL0ltcGxlbWVudGF0aW9ucw0K PiBhbmQgYXNzdW1pbmcgdGhlcmUgaXMgYXMgbXVjaCBlbnRodXNpYXNtIHRvIGltcGxlbWVudCBE VExTMS4zIGFzIHRoZXJlIHdhcyBmb3IgVExTMS4zIHRoZW4gSeKAmW0gaG9waW5nIHRoYXQgdGhl IERUTFMgaW1wbGVtZW50YXRpb25zIHdpbGwgYmUgcmVhZHkgbXVjaCBzb29uZXIgdGhhbiBhIHll YXIgYWZ0ZXIgcHVibGljYXRpb24gKHRoZXkgbWlnaHQgYmUgcmVhZHkgYmVmb3JlIHRoZSBSRkMg aXMgcHVibGlzaGVkKS4NCg0KDQo+WWluIFhpbnhpbmcsDQoNCj5XaGlsZSB3YWl0aW5nIGZvciBj aWQsIHBlcmhhcHMgdG9kYXkgZG8gc2Vzc2lvbiByZXN1bXB0aW9uIChSRkM1MDc3KSwgYW55dGlt ZSB0aGUgY2xpZW50IGhhcyByZWFzb24gdG8gc3VzcGVjdCB0aGVpciBVRFAgcG9ydCBvciBJUCBh ZGRyZXNzIG1pZ2h0IGhhdmUgY2hhbmdlZCAtLSBzdWNoIGFzIGl0J3MgYmVlbiBsb25nZXIgdGhh biwgc2F5LCAzMCBzZWNvbmRzIHNpbmNlIGxhc3QgVURQIHRyYW5zbWlzc2lvbi4gIChUaGUgcHJv YmxlbSBpc24ndCBzb2xlbHkgTkFUOyB0aGVyZSBhcmUgc2V2ZXJhbCBJU1BzIHRoYXQgY2hhbmdl IHN1YnNjcmliZXIncyBJUCBhZGRyZXNzLCA+YWxzbyBmb3JjaW5nIHJlLW5lZ290aWF0aW9uIG9m IERUTFMgc2VjdXJpdHkgYXNzb2NpYXRpb24uICBMZXNzIGZyZXF1ZW50IHRoYW4gTkFUcyB0aW1p bmcgb3V0IFVEUCwgb2YgY291cnNlLikNCg0KPi1kDQpbWWluXSBZZXMsIHlvdSBhcmUgcmlnaHQu IFRoZSBwcm9ibGVtIGlzbid0IHNvbGVseSBOQVQgZXhwaXJpbmcsIGJ1dCBjaGFuZ2luZyBmcm9t IFdMQU4gdG8gM0dQUCwgb3IgSU9UIGRldmljZXMgd2FraW5nIHVwIGZyb20gc2xlZXAgbW9kZS4g QWxsIG9mIHRoZXNlIGNvdWxkIGxlYWQgdG8gSVAgY2hhbmdlLg0KU2Vzc2lvbiByZXN1bXB0aW9u IGlzIGEgZ29vZCB3YXkgdG8gcmUtbmVnb3RpYXRlIHRoZSBEVExTIHNlc3Npb24uIEhvd2V2ZXIs IGFjY29yZGluZyB0byBvdXIgSU9UIHByb2R1Y3RzLCBlLmcuLCBpbnRlbGxpZ2VudCB3YXRlci9n YXMgbWV0ZXIsIHNlc3Npb24gcmVzdW1wdGlvbiBtZWNoYW5pc20gc3RpbGwgbmVlZHMgdG8gY29t bXVuaWNhdGUgNiBvciA1IG1lc3NhZ2VzKGJhc2VkIG9uIHRoZSBjaXBoZXIgc3VpdGUgVExTX1BT S19XSVRIX0FFU18xMjhfQ0JDX1NIQTI1NikgYW5kIHRoaXMgcmUtbmVnb3RpYXRpb24gbWVjaGFu aXNtIHN0aWxsIGNvc3RzIHRvbyBtdWNoIGJhdHRlcnkgYW5kIGNhbiBub3QgZW5zdXJlIDEwLXll YXIgbGlmZXRpbWUgb2YgdGhlIElPVCBwcm9kdWN0cycgYmF0dGVyeS4gDQoNCj4gc3B0DQo+IA0K Pj4gQW55IGNvbW1lbnQgaXMgYXBwcmVjaWF0ZWQuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiBZaW4g WGlueGluZw0KPj4gDQo+PiANCj4+IOWPkeS7tuS6ujogeWlueGlueGluZyANCj4+IOWPkemAgeaX tumXtDogMjAxN+W5tDbmnIgyN+aXpSAxNjoyOA0KPj4g5pS25Lu25Lq6OiAnRXJpYyBSZXNjb3Js YScNCj4+IOaKhOmAgTogdGxzQGlldGYub3JnOyBUb2JpYXMgR29uZHJvbQ0KPj4g5Li76aKYOiBS ZTogW1RMU10gWWluIFhpbnhpbmcgam9pbnMgdGhlIFRMUyBXRw0KPj4gDQo+PiBUaGFua3MgRXJp YywNCj4+IA0KPj4gSSBoYXZlIHNlZW4gdGhlIENJRCBzY2hlbWUsIGFuZCB0YWxrZWQgd2l0aCBI YW5uZXModGhlIGF1dGhvciBvZiB0aGUgc2NoZW1lKS4NCj4+IA0KPj4gQ0lEIHNjaGVtZSBpcyBh IGdvb2QgaWRlYSB0byBzb2x2ZSB0aGUgcHJvYmxlbSBJIG1lbnRpb25lZC4NCj4+IA0KPj4gSSB0 aGluayB0aGUgbGVuZ3RoIG9mIENJRCAoY3VycmVudGx5LCBpdCBpcyAzMiBiaXRzKSBjYW4gYmUg bG9uZ2VyIHNvIHRoYXQgaXQgY2FuIHN1cHBvcnQgbW9yZSBEVExTIHNlc3Npb25zLiBJdCBpcyBr bm93biB0aGF0IGZvciBJT1Qgc2NlbmFyaW8sIDEgbWlsbGlvbiBjb25uZWN0aW9uIGlzIG5vdGhp bmcuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiBZaW4gWGlueGluZw0KPj4gDQo+PiDlj5Hku7bkuro6 IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dIA0KPj4g5Y+R6YCB5pe26Ze0OiAy MDE35bm0NuaciDI15pelIDIxOjMzDQo+PiDmlLbku7bkuro6IHlpbnhpbnhpbmcNCj4+IOaKhOmA gTogdGxzQGlldGYub3JnOyBYaW9uZ3hpYW9jaHVuDQo+PiDkuLvpopg6IFJlOiBbVExTXSBZaW4g WGlueGluZyBqb2lucyB0aGUgVExTIFdHDQo+PiANCj4+IEhpIFlpbiwNCj4+IA0KPj4gVGhlIHVz dWFsIHNvbHV0aW9uIHRvIHRoaXMgaXMgdG8gYWRkIGEgY29ubmVjdGlvbiBpZC4gUGxlYXNlIHNl ZToNCj4+IGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy9kdGxzMTMtc3BlYy9pc3N1ZXMvNg0KPj4g DQo+PiAtRWtyDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IE9uIFN1biwgSnVuIDI1LCAyMDE3IGF0 IDI6MzMgQU0sIHlpbnhpbnhpbmcgPHlpbnhpbnhpbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiBI ZWxsbyBldmVyeW9uZSwNCj4+IA0KPj4gSSBhbSBZaW4gWGlueGluZyBmcm9tIEh1YXdlaSBjb21w YW55LiBJIGFtIGdsYWQgdG8gam9pbiB0aGUgVExTIFdHLg0KPj4gDQo+PiBGb3IgdGhlIERMVFMg MS4zIGRyYWZ0LCBJIGFtIGludGVyZXN0ZWQgYW5kIGhhdmUgc29tZSBpZGVhcyB0byB0YWxrIHdp dGggeW91Lg0KPj4gDQo+PiBEVExTIGhhcyBhIGxvdCBvZiBhcHBsaWNhdGlvbiBzY2VuYXJpb3Mg aW4gSU9UIGZpZWxkcywgYnV0IGN1cnJlbnRseSwgdGhlcmUgaXMgc29tZSBkaWZmaWN1bHR5IHdo ZW4gRFRMUyAxLjIgaXMgYXBwbGllZCB0byBJT1QgZGV2aWNlcywgZXNwZWNpYWxseSB0aGUgYmF0 dGVyeS1jb25zdHJhaW5lZCBJT1QgZGV2aWNlcy4NCj4+IA0KPj4gRm9yIGV4YW1wbGUsIHdoZW4g dGhlIElPVCBkZXZpY2Ugd2FrZXMgdXAgZnJvbSBzbGVlcCBtb2RlLCB0aGUgTkFUIHRhYmxlIG1h eSBoYXZlIGV4cGlyZWQuDQo+PiBUaGVuIHRoZSBJT1QgZGV2aWNlIGhhcyB0byBlc3RhYmxpc2gg YSBuZXcgRFRMUyBzZXNzaW9uIG9yIGF0IGxlYXN0IGxhdW5jaGVzIGEgcmVzdW1lIHByb2Nlc3Mg d2l0aCB0aGUgc2VydmVyLCB0aGUgY29ycmVzcG9uZGluZyBwb3dlciBjb25zdW1wdGlvbiBpcyB0 b28gaGlnaCBmb3Igc29tZSBwb3dlci1jb25zdHJhaW5lZCBkZXZpY2VzLiANCj4+IEhvdyBjYW4g RFRMUyByZW5lZ290aWF0aW9uIGJlIGF2b2lkZWQgaW4gb3JkZXIgdG8gc2F2ZSBiYXR0ZXJ5Pw0K Pj4gDQo+PiBJIGhvcGUgdGhlIGNvbnRyaWJ1dG9ycyBvZiBEVExTIDEuMyAob3IgRFRMUyAxLjIp IGNhbiBjb25zaWRlciB0aGlzIHByb2JsZW0gYW5kIGdpdmUgYSBwcm9wZXIgc29sdXRpb24uICAN Cj4+IA0KPj4gQW55IGNvbW1lbnQgb3IgaWRlYSBhYm91dCB0aGlzIHByb2JsZW0gaXMgd2VsY29t ZS4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IFlpbiBYaW54aW5nDQo+PiANCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBUTFMgbWFpbGluZyBsaXN0 DQo+PiBUTFNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzDQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IFRMUyBtYWlsaW5nIGxpc3QNCj4+IFRMU0BpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRMUyBtYWlsaW5nIGxpc3QN Cj4gVExTQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGxzDQoNCg== From nobody Wed Jul 12 17:52:29 2017 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 1EA7312EC01 for ; Wed, 12 Jul 2017 17:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WDns2p4Q2yxs for ; Wed, 12 Jul 2017 17:52:24 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::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 A8B7D126C7A for ; Wed, 12 Jul 2017 17:52:24 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id c24so5090889pfe.1 for ; Wed, 12 Jul 2017 17:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U994YohKKzENlo4mXYbnT/kiLgg4QhGMHF2j+uAZFLU=; b=WqfRzgipSMhyDN77kiEuvqtF0wCuW9J13GMlV9nNM0djjHxnUQMzfOyc4oSEg+Paey 0LwmuXORpKYTPrbVnsBtV/INYFM3d1EvZvB9uKFvA44J+ZHQrNNlm2njzRx9EZg8WfE1 BE80VItMix3NSXhWgYlePUAdpqvckdwZcyT2GTUqO+Cfb6mM54SbZQ9c4h0Z2lAXaXpn M7o/zgXJ6hMVwwDcF1qWW9KjXbKb6/Mcbq2G6KxPIyLU/P8FEioQJv0mbb1wGmw90n0a VidKWRUVhPtN4UieFrAlbiNQgGNBuqoH/kQTk+gMpJCmSplCjwcTvCFKunQ11KTvd2NX ZQgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U994YohKKzENlo4mXYbnT/kiLgg4QhGMHF2j+uAZFLU=; b=uM+KI0VGRqGaAvS7asEx3lLDudrOsL7apZ9bFfftA99o1S/4mnC4X165CI5SqipxOp 09rf019FPpRg1R0CKDQOmx2FTxyAsGevZZ9QzQpN+/tly/tE+neeqJy/vuft5TdifUSj W3zPVGvguyyU5vL5EDkxFz8p2Gj7vfnWMMAtSJUExNeoE4ObLjHU3M2aB1bLdGNHA2ZV EWB5JdzEJgBqQlBOjYUfIqMkJDqIsjoqLKVZ8CNjD1U6lYRQTSMhngxRyvtrdBdVg8I4 YIYmvwjGdgisecNViAH4BpiKDFtLF01NpeEZosWmD0u0Hq9HltJBgDhpjoPSIs86aRf0 o18Q== X-Gm-Message-State: AIVw110xPZtrV0KUDnldXDLqfqCuiBTm3Fxq3LrKwkHFY3KwTKSEu97m 5aAbJLNhO09hXw== X-Received: by 10.98.217.23 with SMTP id s23mr58849522pfg.204.1499907144087; Wed, 12 Jul 2017 17:52:24 -0700 (PDT) Received: from prome-1n-dhcp2-133.eng.vmware.com ([208.91.1.34]) by smtp.gmail.com with ESMTPSA id f19sm10793632pfj.14.2017.07.12.17.52.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 17:52:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dan Wing In-Reply-To: Date: Wed, 12 Jul 2017 17:52:21 -0700 Cc: "tls@ietf.org" , Sean Turner Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com> To: yinxinxing X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 00:52:27 -0000 > On Jul 12, 2017, at 5:21 PM, yinxinxing wrote: >=20 > Hi Dan Wing, >=20 > Thanks for your comments. >=20 > Please see my comments inline. >=20 > Regards, > Yin Xinxing >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Dan Wing [mailto:danwing@gmail.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8813=E6=97=A5= 1:09 > =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing > =E6=8A=84=E9=80=81: tls@ietf.org; Sean Turner > =E4=B8=BB=E9=A2=98: Re: [TLS] Solving the NAT expiring problem causing = DTLS renegotiation with high power consumption in DTLS1.2 >=20 >=20 >> On Jul 12, 2017, at 7:56 AM, Sean Turner wrote: >>=20 >>=20 >>> On Jul 6, 2017, at 23:04, yinxinxing wrote: >>>=20 >>> Hi all, >>>=20 >>> The NAT table expiring problem mentioned in the following email = should also be considered in DTLS1.2 as an extension. >>>=20 >>> The value and necessity are as follows. >>>=20 >>> 1. Essentially, NAT expiring problem causing DTLS renegotiation with = high power consumption is existing in DTLS 1.2. Even if we solve this in = DTLS1.3, this problem still exist for products using DTLS1.2. >>> Currently, many IOT products using DTLS 1.2 are going to be deployed = commercially, such as intelligent water/gas meter. These meters usually = have limited battery and low cost. To be more accurate, the battery of = the chip module of the intelligent water/gas meter are required to last = for 10 years. These lead to an exercise strict control over the power = consumption of the chip module. NAT expiring problem causing DTLS = renegotiation with high power consumption is a bottleneck of these IOT = devices. According to our experimental data, under the worst coverage = level (ECL2), power consumption of the chip module when DTLS is embedded = increases by nearly 60%. Therefore, there should be a solution to solve = the urgent problem to match the low-cost and low-battery feature of the = IOT devices in DTLS 1.2. >>=20 >> I have to ask whether these IoT devices are updatable? >>=20 >>> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open = source code will be available about one year later after the = standardization. At present, large-scale commercial IOT industry = deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope = that the above problem could be solved in DTLS 1.2 as soon as possible. >>=20 >> On this point, I=E2=80=99m hoping that you=E2=80=99ll be wrong ;). = =46rom the list of TLS implementations found here: >> https://github.com/tlswg/tls13-spec/wiki/Implementations >> and assuming there is as much enthusiasm to implement DTLS1.3 as = there was for TLS1.3 then I=E2=80=99m hoping that the DTLS = implementations will be ready much sooner than a year after publication = (they might be ready before the RFC is published). >=20 >=20 >> Yin Xinxing, >=20 >> While waiting for cid, perhaps today do session resumption (RFC5077), = anytime the client has reason to suspect their UDP port or IP address = might have changed -- such as it's been longer than, say, 30 seconds = since last UDP transmission. (The problem isn't solely NAT; there are = several ISPs that change subscriber's IP address, >also forcing = re-negotiation of DTLS security association. Less frequent than NATs = timing out UDP, of course.) >=20 >> -d > [Yin] Yes, you are right. The problem isn't solely NAT expiring, but = changing from WLAN to 3GPP, or IOT devices waking up from sleep mode. = All of these could lead to IP change. > Session resumption is a good way to re-negotiate the DTLS session. = However, according to our IOT products, e.g., intelligent water/gas = meter, session resumption mechanism still needs to communicate 6 or 5 = messages(based on the cipher suite TLS_PSK_WITH_AES_128_CBC_SHA256) and = this re-negotiation mechanism still costs too much battery and can not = ensure 10-year lifetime of the IOT products' battery.=20 I see 3 messages and no cryptographic operations for the client in = Figure 2 of https://tools.ietf.org/html/rfc5077#page-5. So I guess = you're saying the IoT device can't send two packets and receive one = packet without impacting its battery. I agree 'cid' is more efficient, = but it isn't yet standardized. I would consider doing RFC5077 and then, = when 'cid' or DTLS 1.3 is available, update the devices to support 'cid' = or DTLS 1.3, as Sean implied when he asked if the devices could be = updated. (I hope the devices aren't using the same pre-shared key! That would be = bad.) -d >=20 >> spt >>=20 >>> Any comment is appreciated. >>>=20 >>> Regards, >>> Yin Xinxing >>>=20 >>>=20 >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: yinxinxing=20 >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8827=E6=97=A5= 16:28 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric Rescorla' >>> =E6=8A=84=E9=80=81: tls@ietf.org; Tobias Gondrom >>> =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG >>>=20 >>> Thanks Eric, >>>=20 >>> I have seen the CID scheme, and talked with Hannes(the author of the = scheme). >>>=20 >>> CID scheme is a good idea to solve the problem I mentioned. >>>=20 >>> I think the length of CID (currently, it is 32 bits) can be longer = so that it can support more DTLS sessions. It is known that for IOT = scenario, 1 million connection is nothing. >>>=20 >>> Regards, >>> Yin Xinxing >>>=20 >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]=20 >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8825=E6=97=A5= 21:33 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing >>> =E6=8A=84=E9=80=81: tls@ietf.org; Xiongxiaochun >>> =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG >>>=20 >>> Hi Yin, >>>=20 >>> The usual solution to this is to add a connection id. Please see: >>> https://github.com/tlswg/dtls13-spec/issues/6 >>>=20 >>> -Ekr >>>=20 >>>=20 >>>=20 >>>=20 >>> On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing = wrote: >>> Hello everyone, >>>=20 >>> I am Yin Xinxing from Huawei company. I am glad to join the TLS WG. >>>=20 >>> For the DLTS 1.3 draft, I am interested and have some ideas to talk = with you. >>>=20 >>> DTLS has a lot of application scenarios in IOT fields, but = currently, there is some difficulty when DTLS 1.2 is applied to IOT = devices, especially the battery-constrained IOT devices. >>>=20 >>> For example, when the IOT device wakes up from sleep mode, the NAT = table may have expired. >>> Then the IOT device has to establish a new DTLS session or at least = launches a resume process with the server, the corresponding power = consumption is too high for some power-constrained devices.=20 >>> How can DTLS renegotiation be avoided in order to save battery? >>>=20 >>> I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this = problem and give a proper solution. =20 >>>=20 >>> Any comment or idea about this problem is welcome. >>>=20 >>> Regards, >>> Yin Xinxing >>>=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 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Wed Jul 12 18:11:36 2017 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 7DF3E12FEE2 for ; Wed, 12 Jul 2017 18:11:35 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cr4FoPQXJLhh for ; Wed, 12 Jul 2017 18:11:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BA912EC12 for ; Wed, 12 Jul 2017 18:11:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQZ80734; Thu, 13 Jul 2017 01:11:30 +0000 (GMT) Received: from DGGEMI403-HUB.china.huawei.com (10.3.17.136) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Jul 2017 02:11:29 +0100 Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.203]) by dggemi403-hub.china.huawei.com ([10.3.17.136]) with mapi id 14.03.0301.000; Thu, 13 Jul 2017 09:11:26 +0800 From: yinxinxing To: Sean Turner CC: "tls@ietf.org" Thread-Topic: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 Thread-Index: AdL2zV5W/HDgxBACQSqQFOyDPszOzQEDqAMAACSRuvA= Date: Thu, 13 Jul 2017 01:11:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5966C8C3.002C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.203, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7c9b4d1e7dd2418be352d6763ee8b7a5 Archived-At: Subject: [TLS] =?utf-8?b?562U5aSNOiAgU29sdmluZyB0aGUgTkFUIGV4cGlyaW5nIHBy?= =?utf-8?q?oblem_causing_DTLS_renegotiation_with_high_power_consumption_in?= =?utf-8?q?_DTLS1=2E2?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 01:11:35 -0000 VGhhbmtzIFNlYW4hDQoNCllvdXIgcXVlc3Rpb24gYW5kIGNvbW1lbnRzIGFyZSB2YWx1YWJsZS4g DQoNClBsZWFzZSBjaGVjayBteSBjb21tZW50cyBpbmxpbmUuDQoNClJlZ2FyZHMsDQpZaW4gWGlu eGluZw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IFNlYW4gVHVybmVyIFtt YWlsdG86c2VhbkBzbjNyZC5jb21dIA0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0N+aciDEy5pelIDIy OjU3DQrmlLbku7bkuro6IHlpbnhpbnhpbmcNCuaKhOmAgTogdGxzQGlldGYub3JnDQrkuLvpopg6 IFJlOiBbVExTXSBTb2x2aW5nIHRoZSBOQVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVzaW5nIERUTFMg cmVuZWdvdGlhdGlvbiB3aXRoIGhpZ2ggcG93ZXIgY29uc3VtcHRpb24gaW4gRFRMUzEuMg0KDQog DQo+IE9uIEp1bCA2LCAyMDE3LCBhdCAyMzowNCwgeWlueGlueGluZyA8eWlueGlueGluZ0BodWF3 ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIGFsbCwNCj4gIA0KPiBUaGUgTkFUIHRhYmxlIGV4cGly aW5nIHByb2JsZW0gbWVudGlvbmVkIGluIHRoZSAgZm9sbG93aW5nIGVtYWlsIHNob3VsZCBhbHNv IGJlIGNvbnNpZGVyZWQgaW4gRFRMUzEuMiBhcyBhbiBleHRlbnNpb24uDQo+ICANCj4gVGhlIHZh bHVlIGFuZCBuZWNlc3NpdHkgYXJlIGFzIGZvbGxvd3MuDQo+ICANCj4gMS4gRXNzZW50aWFsbHks IE5BVCBleHBpcmluZyBwcm9ibGVtIGNhdXNpbmcgRFRMUyByZW5lZ290aWF0aW9uIHdpdGggaGln aCBwb3dlciBjb25zdW1wdGlvbiBpcyBleGlzdGluZyBpbiBEVExTIDEuMi4gRXZlbiBpZiB3ZSBz b2x2ZSB0aGlzIGluIERUTFMxLjMsIHRoaXMgcHJvYmxlbSBzdGlsbCBleGlzdCBmb3IgcHJvZHVj dHMgdXNpbmcgRFRMUzEuMi4NCj4gQ3VycmVudGx5LCBtYW55IElPVCBwcm9kdWN0cyB1c2luZyBE VExTIDEuMiBhcmUgZ29pbmcgdG8gYmUgZGVwbG95ZWQgY29tbWVyY2lhbGx5LCBzdWNoIGFzIGlu dGVsbGlnZW50IHdhdGVyL2dhcyBtZXRlci4gVGhlc2UgbWV0ZXJzIHVzdWFsbHkgaGF2ZSBsaW1p dGVkIGJhdHRlcnkgYW5kIGxvdyBjb3N0LiBUbyBiZSBtb3JlIGFjY3VyYXRlLCB0aGUgYmF0dGVy eSBvZiB0aGUgY2hpcCBtb2R1bGUgb2YgdGhlIGludGVsbGlnZW50IHdhdGVyL2dhcyBtZXRlciBh cmUgcmVxdWlyZWQgdG8gbGFzdCBmb3IgMTAgeWVhcnMuIFRoZXNlIGxlYWQgdG8gYW4gZXhlcmNp c2Ugc3RyaWN0IGNvbnRyb2wgb3ZlciB0aGUgcG93ZXIgY29uc3VtcHRpb24gb2YgdGhlIGNoaXAg bW9kdWxlLiBOQVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVzaW5nIERUTFMgcmVuZWdvdGlhdGlvbiB3 aXRoIGhpZ2ggcG93ZXIgY29uc3VtcHRpb24gaXMgYSBib3R0bGVuZWNrIG9mIHRoZXNlIElPVCBk ZXZpY2VzLiBBY2NvcmRpbmcgdG8gb3VyIGV4cGVyaW1lbnRhbCBkYXRhLCB1bmRlciB0aGUgd29y c3QgY292ZXJhZ2UgbGV2ZWwgKEVDTDIpLCBwb3dlciBjb25zdW1wdGlvbiBvZiB0aGUgY2hpcCBt b2R1bGUgd2hlbiBEVExTIGlzIGVtYmVkZGVkIGluY3JlYXNlcyBieSBuZWFybHkgNjAlLiBUaGVy ZWZvcmUsIHRoZXJlIHNob3VsZCBiZSBhIHNvbHV0aW9uIHRvIHNvbHZlIHRoZSB1cmdlbnQgcHJv YmxlbSB0byBtYXRjaCB0aGUgbG93LWNvc3QgYW5kIGxvdy1iYXR0ZXJ5IGZlYXR1cmUgb2YgdGhl IElPVCBkZXZpY2VzIGluIERUTFMgMS4yLg0KDQo+IEkgaGF2ZSB0byBhc2sgd2hldGhlciB0aGVz ZSBJb1QgZGV2aWNlcyBhcmUgdXBkYXRhYmxlPw0KW1lpbl1ZZXMsIHRoZXNlIElPVCBkZXZpY2Vz IGFyZSB1cGRhdGFibGUuIEhvd2V2ZXIsIGluIElPVCBhcHBsaWNhdGlvbiBzY2VuYXJpbywgdGhl cmUgd2lsbCBiZSBtaWxsaW9ucyggZXZlbiBiaWxsaW9ucyApIG9mIElPVCBkZXZpY2VzLiBDb21w YW5pZXMgd2lsbCBub3QgZWFzaWx5IHVwZ3JhZGUgc3VjaCBhIGxhcmdlIG51bWJlciBvZiBkZXZp Y2VzIGJlY2F1c2Ugb2Ygb3BlcmF0aW9uIGFuZCBtYWludGVuYW5jZSBjb3N0IGFuZCBwb3dlciBj b25zdW1wdGlvbiBvZiBJT1QgZGV2aWNlIHVwZ3JhZGluZy4gWW91IHNlZSB0aGF0IGN1cnJlbnQg cHJvZHVjdHMgZnJvbSBkaWZmZXJlbnQgY29tcGFuaWVzIGFyZSBhbGwgYmFzZWQgb24gRFRMUzEu MiBzaW5jZSBEVExTMS4zIGlzIHVuZGVyIHN0YW5kYXJkaXphdGlvbi4gV2UgaG9wZSB0aGVyZSBj b3VsZCBiZSBhIHNvbHV0aW9uIHRvIHNvbHZlIHRoZSBwcm9ibGVtIG9mIHRoZXNlIHByb2R1Y3Rz IGJhc2VkIG9uIERUTFMxLjIuDQoNCj4gMi4gRFRMUyAxLjMgd2lsbCBiZSBzdGFuZGFyZGl6ZWQg aW4gMjAxOCwgYnV0IHRoZSBjb3JyZXNwb25kaW5nIG9wZW4gc291cmNlIGNvZGUgd2lsbCBiZSBh dmFpbGFibGUgYWJvdXQgb25lIHllYXIgbGF0ZXIgYWZ0ZXIgdGhlIHN0YW5kYXJkaXphdGlvbi4g QXQgcHJlc2VudCwgbGFyZ2Utc2NhbGUgY29tbWVyY2lhbCBJT1QgaW5kdXN0cnkgZGVwbG95bWVu dCBpcyB1cmdlbnQsIGl0IGlzIHRvbyBsYXRlIHRvIHdhaXQgZm9yIERUTFMgMS4zLiBUaHVzLCB3 ZSBob3BlIHRoYXQgdGhlIGFib3ZlIHByb2JsZW0gY291bGQgYmUgc29sdmVkIGluIERUTFMgMS4y IGFzIHNvb24gYXMgcG9zc2libGUuDQoNCj4gT24gdGhpcyBwb2ludCwgSeKAmW0gaG9waW5nIHRo YXQgeW914oCZbGwgYmUgd3JvbmcgOykuIEZyb20gdGhlIGxpc3Qgb2YgVExTIGltcGxlbWVudGF0 aW9ucyBmb3VuZCBoZXJlOg0KPiBodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy93 aWtpL0ltcGxlbWVudGF0aW9ucw0KPiBhbmQgYXNzdW1pbmcgdGhlcmUgaXMgYXMgbXVjaCBlbnRo dXNpYXNtIHRvIGltcGxlbWVudCBEVExTMS4zIGFzIHRoZXJlIHdhcyBmb3IgVExTMS4zIHRoZW4g SeKAmW0gaG9waW5nIHRoYXQgdGhlIERUTFMgaW1wbGVtZW50YXRpb25zIHdpbGwgYmUgcmVhZHkg bXVjaCBzb29uZXIgdGhhbiBhIHllYXIgYWZ0ZXIgcHVibGljYXRpb24gKHRoZXkgbWlnaHQgYmUg cmVhZHkgYmVmb3JlIHRoZSBSRkMgaXMgcHVibGlzaGVkKS4NCg0KPiBzcHQNCltZaW5dIFRoYW5r cyBmb3IgcHJvdmlkaW5nIHRoaXMgdXNlZnVsIGluZm9ybWF0aW9uLiBJIGdvdCB3cm9uZyBpbmZv cm1hdGlvbiBhYm91dCB0aGUgaW1wbGVtZW50YXRpb24gc3RhdGUgb2YgVExTL0RUTFMxLjMuIEZv ciBEVExTMS4zLCB0aGUgaW1wbGVtZW50YXRpb24gd2lsbCBiZSByZWFkeSBhYm91dCAxIHllYXIs IGFuZCBkdXJpbmcgdGhpcyBwZXJpb2QgcHJvZHVjdHMgaGF2ZSBubyBEVExTMS4zIGltcGxlbWVu dGF0aW9uIHRvIHVzZS4gDQoNCj4gQW55IGNvbW1lbnQgaXMgYXBwcmVjaWF0ZWQuDQo+ICANCj4g UmVnYXJkcywNCj4gWWluIFhpbnhpbmcNCj4gIA0KPiAgDQo+IOWPkeS7tuS6ujogeWlueGlueGlu ZyANCj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0NuaciDI35pelIDE2OjI4DQo+IOaUtuS7tuS6ujog J0VyaWMgUmVzY29ybGEnDQo+IOaKhOmAgTogdGxzQGlldGYub3JnOyBUb2JpYXMgR29uZHJvbQ0K PiDkuLvpopg6IFJlOiBbVExTXSBZaW4gWGlueGluZyBqb2lucyB0aGUgVExTIFdHDQo+ICANCj4g VGhhbmtzIEVyaWMsDQo+ICANCj4gSSBoYXZlIHNlZW4gdGhlIENJRCBzY2hlbWUsIGFuZCB0YWxr ZWQgd2l0aCBIYW5uZXModGhlIGF1dGhvciBvZiB0aGUgc2NoZW1lKS4NCj4gIA0KPiBDSUQgc2No ZW1lIGlzIGEgZ29vZCBpZGVhIHRvIHNvbHZlIHRoZSBwcm9ibGVtIEkgbWVudGlvbmVkLg0KPiAg DQo+IEkgdGhpbmsgdGhlIGxlbmd0aCBvZiBDSUQgKGN1cnJlbnRseSwgaXQgaXMgMzIgYml0cykg Y2FuIGJlIGxvbmdlciBzbyB0aGF0IGl0IGNhbiBzdXBwb3J0IG1vcmUgRFRMUyBzZXNzaW9ucy4g SXQgaXMga25vd24gdGhhdCBmb3IgSU9UIHNjZW5hcmlvLCAxIG1pbGxpb24gY29ubmVjdGlvbiBp cyBub3RoaW5nLg0KPiAgDQo+IFJlZ2FyZHMsDQo+IFlpbiBYaW54aW5nDQo+ICANCj4g5Y+R5Lu2 5Lq6OiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXSANCj4g5Y+R6YCB5pe26Ze0 OiAyMDE35bm0NuaciDI15pelIDIxOjMzDQo+IOaUtuS7tuS6ujogeWlueGlueGluZw0KPiDmioTp gIE6IHRsc0BpZXRmLm9yZzsgWGlvbmd4aWFvY2h1bg0KPiDkuLvpopg6IFJlOiBbVExTXSBZaW4g WGlueGluZyBqb2lucyB0aGUgVExTIFdHDQo+ICANCj4gSGkgWWluLA0KPiAgDQo+IFRoZSB1c3Vh bCBzb2x1dGlvbiB0byB0aGlzIGlzIHRvIGFkZCBhIGNvbm5lY3Rpb24gaWQuIFBsZWFzZSBzZWU6 DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy9kdGxzMTMtc3BlYy9pc3N1ZXMvNg0KPiAgDQo+ IC1Fa3INCj4gIA0KPiAgDQo+ICANCj4gIA0KPiBPbiBTdW4sIEp1biAyNSwgMjAxNyBhdCAyOjMz IEFNLCB5aW54aW54aW5nIDx5aW54aW54aW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiBIZWxsbyBl dmVyeW9uZSwNCj4gIA0KPiBJIGFtIFlpbiBYaW54aW5nIGZyb20gSHVhd2VpIGNvbXBhbnkuIEkg YW0gZ2xhZCB0byBqb2luIHRoZSBUTFMgV0cuDQo+ICANCj4gRm9yIHRoZSBETFRTIDEuMyBkcmFm dCwgSSBhbSBpbnRlcmVzdGVkIGFuZCBoYXZlIHNvbWUgaWRlYXMgdG8gdGFsayB3aXRoIHlvdS4N Cj4gIA0KPiBEVExTIGhhcyBhIGxvdCBvZiBhcHBsaWNhdGlvbiBzY2VuYXJpb3MgaW4gSU9UIGZp ZWxkcywgYnV0IGN1cnJlbnRseSwgdGhlcmUgaXMgc29tZSBkaWZmaWN1bHR5IHdoZW4gRFRMUyAx LjIgaXMgYXBwbGllZCB0byBJT1QgZGV2aWNlcywgZXNwZWNpYWxseSB0aGUgYmF0dGVyeS1jb25z dHJhaW5lZCBJT1QgZGV2aWNlcy4NCj4gIA0KPiBGb3IgZXhhbXBsZSwgd2hlbiB0aGUgSU9UIGRl dmljZSB3YWtlcyB1cCBmcm9tIHNsZWVwIG1vZGUsIHRoZSBOQVQgdGFibGUgbWF5IGhhdmUgZXhw aXJlZC4NCj4gVGhlbiB0aGUgSU9UIGRldmljZSBoYXMgdG8gZXN0YWJsaXNoIGEgbmV3IERUTFMg c2Vzc2lvbiBvciBhdCBsZWFzdCBsYXVuY2hlcyBhIHJlc3VtZSBwcm9jZXNzIHdpdGggdGhlIHNl cnZlciwgdGhlIGNvcnJlc3BvbmRpbmcgcG93ZXIgY29uc3VtcHRpb24gaXMgdG9vIGhpZ2ggZm9y IHNvbWUgcG93ZXItY29uc3RyYWluZWQgZGV2aWNlcy4gDQo+IEhvdyBjYW4gRFRMUyByZW5lZ290 aWF0aW9uIGJlIGF2b2lkZWQgaW4gb3JkZXIgdG8gc2F2ZSBiYXR0ZXJ5Pw0KPiAgDQo+IEkgaG9w ZSB0aGUgY29udHJpYnV0b3JzIG9mIERUTFMgMS4zIChvciBEVExTIDEuMikgY2FuIGNvbnNpZGVy IHRoaXMgcHJvYmxlbSBhbmQgZ2l2ZSBhIHByb3BlciBzb2x1dGlvbi4gIA0KPiAgDQo+IEFueSBj b21tZW50IG9yIGlkZWEgYWJvdXQgdGhpcyBwcm9ibGVtIGlzIHdlbGNvbWUuDQo+ICANCj4gUmVn YXJkcywNCj4gWWluIFhpbnhpbmcNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IFRMUyBtYWlsaW5nIGxpc3QNCj4gVExTQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+IA0KPiAgDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRMUyBtYWls aW5nIGxpc3QNCj4gVExTQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzDQoNCg== From nobody Wed Jul 12 19:11:34 2017 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 C152012EC1B for ; Wed, 12 Jul 2017 19:11:32 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GuVM0BFxHuWf for ; Wed, 12 Jul 2017 19:11:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E9912EC37 for ; Wed, 12 Jul 2017 19:11:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKG73735; Thu, 13 Jul 2017 02:11:27 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Jul 2017 03:11:26 +0100 Received: from DGGEMI403-HUB.china.huawei.com (10.3.17.136) by NKGEML413-HUB.china.huawei.com (10.98.56.74) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 13 Jul 2017 10:11:23 +0800 Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.203]) by dggemi403-hub.china.huawei.com ([10.3.17.136]) with mapi id 14.03.0301.000; Thu, 13 Jul 2017 10:11:22 +0800 From: yinxinxing To: Dan Wing CC: "tls@ietf.org" , Sean Turner Thread-Topic: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 Thread-Index: AdL2zV5W/HDgxBACQSqQFOyDPszOzQEDqAMAAASeQgAAH2kMQP//hj2A//9mI6A= Date: Thu, 13 Jul 2017 02:11:21 +0000 Message-ID: References: <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5966D6CF.010D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.203, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 729de73786621886ca58b7311dfe0d2e Archived-At: Subject: [TLS] =?utf-8?b?562U5aSNOiAgU29sdmluZyB0aGUgTkFUIGV4cGlyaW5nIHBy?= =?utf-8?q?oblem_causing_DTLS_renegotiation_with_high_power_consumption_in?= =?utf-8?q?_DTLS1=2E2?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 02:11:32 -0000 VGhhbmtzIFdpbmcsDQoNClBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLg0KDQpSZWdhcmRz LA0KWWluIFhpbnhpbmcNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBEYW4g V2luZyBbbWFpbHRvOmRhbndpbmdAZ21haWwuY29tXSANCuWPkemAgeaXtumXtDogMjAxN+W5tDfm nIgxM+aXpSA4OjUyDQrmlLbku7bkuro6IHlpbnhpbnhpbmcNCuaKhOmAgTogdGxzQGlldGYub3Jn OyBTZWFuIFR1cm5lcg0K5Li76aKYOiBSZTogW1RMU10gU29sdmluZyB0aGUgTkFUIGV4cGlyaW5n IHByb2JsZW0gY2F1c2luZyBEVExTIHJlbmVnb3RpYXRpb24gd2l0aCBoaWdoIHBvd2VyIGNvbnN1 bXB0aW9uIGluIERUTFMxLjINCg0KDQo+IE9uIEp1bCAxMiwgMjAxNywgYXQgNToyMSBQTSwgeWlu eGlueGluZyA8eWlueGlueGluZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIERhbiBXaW5n LA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KPiANCj4gUGxlYXNlIHNlZSBteSBj b21tZW50cyBpbmxpbmUuDQo+IA0KPiBSZWdhcmRzLA0KPiBZaW4gWGlueGluZw0KPiANCj4gLS0t LS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IERhbiBXaW5nIFttYWlsdG86ZGFud2lu Z0BnbWFpbC5jb21dIA0KPiDlj5HpgIHml7bpl7Q6IDIwMTflubQ35pyIMTPml6UgMTowOQ0KPiDm lLbku7bkuro6IHlpbnhpbnhpbmcNCj4g5oqE6YCBOiB0bHNAaWV0Zi5vcmc7IFNlYW4gVHVybmVy DQo+IOS4u+mimDogUmU6IFtUTFNdIFNvbHZpbmcgdGhlIE5BVCBleHBpcmluZyBwcm9ibGVtIGNh dXNpbmcgRFRMUyByZW5lZ290aWF0aW9uIHdpdGggaGlnaCBwb3dlciBjb25zdW1wdGlvbiBpbiBE VExTMS4yDQo+IA0KPiANCj4+IE9uIEp1bCAxMiwgMjAxNywgYXQgNzo1NiBBTSwgU2VhbiBUdXJu ZXIgPHNlYW5Ac24zcmQuY29tPiB3cm90ZToNCj4+IA0KPj4gDQo+Pj4gT24gSnVsIDYsIDIwMTcs IGF0IDIzOjA0LCB5aW54aW54aW5nIDx5aW54aW54aW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+ IA0KPj4+IEhpIGFsbCwNCj4+PiANCj4+PiBUaGUgTkFUIHRhYmxlIGV4cGlyaW5nIHByb2JsZW0g bWVudGlvbmVkIGluIHRoZSAgZm9sbG93aW5nIGVtYWlsIHNob3VsZCBhbHNvIGJlIGNvbnNpZGVy ZWQgaW4gRFRMUzEuMiBhcyBhbiBleHRlbnNpb24uDQo+Pj4gDQo+Pj4gVGhlIHZhbHVlIGFuZCBu ZWNlc3NpdHkgYXJlIGFzIGZvbGxvd3MuDQo+Pj4gDQo+Pj4gMS4gRXNzZW50aWFsbHksIE5BVCBl eHBpcmluZyBwcm9ibGVtIGNhdXNpbmcgRFRMUyByZW5lZ290aWF0aW9uIHdpdGggaGlnaCBwb3dl ciBjb25zdW1wdGlvbiBpcyBleGlzdGluZyBpbiBEVExTIDEuMi4gRXZlbiBpZiB3ZSBzb2x2ZSB0 aGlzIGluIERUTFMxLjMsIHRoaXMgcHJvYmxlbSBzdGlsbCBleGlzdCBmb3IgcHJvZHVjdHMgdXNp bmcgRFRMUzEuMi4NCj4+PiBDdXJyZW50bHksIG1hbnkgSU9UIHByb2R1Y3RzIHVzaW5nIERUTFMg MS4yIGFyZSBnb2luZyB0byBiZSBkZXBsb3llZCBjb21tZXJjaWFsbHksIHN1Y2ggYXMgaW50ZWxs aWdlbnQgd2F0ZXIvZ2FzIG1ldGVyLiBUaGVzZSBtZXRlcnMgdXN1YWxseSBoYXZlIGxpbWl0ZWQg YmF0dGVyeSBhbmQgbG93IGNvc3QuIFRvIGJlIG1vcmUgYWNjdXJhdGUsIHRoZSBiYXR0ZXJ5IG9m IHRoZSBjaGlwIG1vZHVsZSBvZiB0aGUgaW50ZWxsaWdlbnQgd2F0ZXIvZ2FzIG1ldGVyIGFyZSBy ZXF1aXJlZCB0byBsYXN0IGZvciAxMCB5ZWFycy4gVGhlc2UgbGVhZCB0byBhbiBleGVyY2lzZSBz dHJpY3QgY29udHJvbCBvdmVyIHRoZSBwb3dlciBjb25zdW1wdGlvbiBvZiB0aGUgY2hpcCBtb2R1 bGUuIE5BVCBleHBpcmluZyBwcm9ibGVtIGNhdXNpbmcgRFRMUyByZW5lZ290aWF0aW9uIHdpdGgg aGlnaCBwb3dlciBjb25zdW1wdGlvbiBpcyBhIGJvdHRsZW5lY2sgb2YgdGhlc2UgSU9UIGRldmlj ZXMuIEFjY29yZGluZyB0byBvdXIgZXhwZXJpbWVudGFsIGRhdGEsIHVuZGVyIHRoZSB3b3JzdCBj b3ZlcmFnZSBsZXZlbCAoRUNMMiksIHBvd2VyIGNvbnN1bXB0aW9uIG9mIHRoZSBjaGlwIG1vZHVs ZSB3aGVuIERUTFMgaXMgZW1iZWRkZWQgaW5jcmVhc2VzIGJ5IG5lYXJseSA2MCUuIFRoZXJlZm9y ZSwgdGhlcmUgc2hvdWxkIGJlIGEgc29sdXRpb24gdG8gc29sdmUgdGhlIHVyZ2VudCBwcm9ibGVt IHRvIG1hdGNoIHRoZSBsb3ctY29zdCBhbmQgbG93LWJhdHRlcnkgZmVhdHVyZSBvZiB0aGUgSU9U IGRldmljZXMgaW4gRFRMUyAxLjIuDQo+PiANCj4+IEkgaGF2ZSB0byBhc2sgd2hldGhlciB0aGVz ZSBJb1QgZGV2aWNlcyBhcmUgdXBkYXRhYmxlPw0KPj4gDQo+Pj4gMi4gRFRMUyAxLjMgd2lsbCBi ZSBzdGFuZGFyZGl6ZWQgaW4gMjAxOCwgYnV0IHRoZSBjb3JyZXNwb25kaW5nIG9wZW4gc291cmNl IGNvZGUgd2lsbCBiZSBhdmFpbGFibGUgYWJvdXQgb25lIHllYXIgbGF0ZXIgYWZ0ZXIgdGhlIHN0 YW5kYXJkaXphdGlvbi4gQXQgcHJlc2VudCwgbGFyZ2Utc2NhbGUgY29tbWVyY2lhbCBJT1QgaW5k dXN0cnkgZGVwbG95bWVudCBpcyB1cmdlbnQsIGl0IGlzIHRvbyBsYXRlIHRvIHdhaXQgZm9yIERU TFMgMS4zLiBUaHVzLCB3ZSBob3BlIHRoYXQgdGhlIGFib3ZlIHByb2JsZW0gY291bGQgYmUgc29s dmVkIGluIERUTFMgMS4yIGFzIHNvb24gYXMgcG9zc2libGUuDQo+PiANCj4+IE9uIHRoaXMgcG9p bnQsIEnigJltIGhvcGluZyB0aGF0IHlvdeKAmWxsIGJlIHdyb25nIDspLiBGcm9tIHRoZSBsaXN0 IG9mIFRMUyBpbXBsZW1lbnRhdGlvbnMgZm91bmQgaGVyZToNCj4+IGh0dHBzOi8vZ2l0aHViLmNv bS90bHN3Zy90bHMxMy1zcGVjL3dpa2kvSW1wbGVtZW50YXRpb25zDQo+PiBhbmQgYXNzdW1pbmcg dGhlcmUgaXMgYXMgbXVjaCBlbnRodXNpYXNtIHRvIGltcGxlbWVudCBEVExTMS4zIGFzIHRoZXJl IHdhcyBmb3IgVExTMS4zIHRoZW4gSeKAmW0gaG9waW5nIHRoYXQgdGhlIERUTFMgaW1wbGVtZW50 YXRpb25zIHdpbGwgYmUgcmVhZHkgbXVjaCBzb29uZXIgdGhhbiBhIHllYXIgYWZ0ZXIgcHVibGlj YXRpb24gKHRoZXkgbWlnaHQgYmUgcmVhZHkgYmVmb3JlIHRoZSBSRkMgaXMgcHVibGlzaGVkKS4N Cj4gDQo+IA0KPj4gWWluIFhpbnhpbmcsDQo+IA0KPj4gV2hpbGUgd2FpdGluZyBmb3IgY2lkLCBw ZXJoYXBzIHRvZGF5IGRvIHNlc3Npb24gcmVzdW1wdGlvbiAoUkZDNTA3NyksIGFueXRpbWUgdGhl IGNsaWVudCBoYXMgcmVhc29uIHRvIHN1c3BlY3QgdGhlaXIgVURQIHBvcnQgb3IgSVAgYWRkcmVz cyBtaWdodCBoYXZlIGNoYW5nZWQgLS0gc3VjaCBhcyBpdCdzIGJlZW4gbG9uZ2VyIHRoYW4sIHNh eSwgMzAgc2Vjb25kcyBzaW5jZSBsYXN0IFVEUCB0cmFuc21pc3Npb24uICAoVGhlIHByb2JsZW0g aXNuJ3Qgc29sZWx5IE5BVDsgdGhlcmUgYXJlIHNldmVyYWwgSVNQcyB0aGF0IGNoYW5nZSBzdWJz Y3JpYmVyJ3MgSVAgYWRkcmVzcywgPmFsc28gZm9yY2luZyByZS1uZWdvdGlhdGlvbiBvZiBEVExT IHNlY3VyaXR5IGFzc29jaWF0aW9uLiAgTGVzcyBmcmVxdWVudCB0aGFuIE5BVHMgdGltaW5nIG91 dCBVRFAsIG9mIGNvdXJzZS4pDQo+IA0KPj4gLWQNCj4gW1lpbl0gWWVzLCB5b3UgYXJlIHJpZ2h0 LiBUaGUgcHJvYmxlbSBpc24ndCBzb2xlbHkgTkFUIGV4cGlyaW5nLCBidXQgY2hhbmdpbmcgZnJv bSBXTEFOIHRvIDNHUFAsIG9yIElPVCBkZXZpY2VzIHdha2luZyB1cCBmcm9tIHNsZWVwIG1vZGUu IEFsbCBvZiB0aGVzZSBjb3VsZCBsZWFkIHRvIElQIGNoYW5nZS4NCj4gU2Vzc2lvbiByZXN1bXB0 aW9uIGlzIGEgZ29vZCB3YXkgdG8gcmUtbmVnb3RpYXRlIHRoZSBEVExTIHNlc3Npb24uIEhvd2V2 ZXIsIGFjY29yZGluZyB0byBvdXIgSU9UIHByb2R1Y3RzLCBlLmcuLCBpbnRlbGxpZ2VudCB3YXRl ci9nYXMgbWV0ZXIsIHNlc3Npb24gcmVzdW1wdGlvbiBtZWNoYW5pc20gc3RpbGwgbmVlZHMgdG8g Y29tbXVuaWNhdGUgNiBvciA1IG1lc3NhZ2VzKGJhc2VkIG9uIHRoZSBjaXBoZXIgc3VpdGUgVExT X1BTS19XSVRIX0FFU18xMjhfQ0JDX1NIQTI1NikgYW5kIHRoaXMgcmUtbmVnb3RpYXRpb24gbWVj aGFuaXNtIHN0aWxsIGNvc3RzIHRvbyBtdWNoIGJhdHRlcnkgYW5kIGNhbiBub3QgZW5zdXJlIDEw LXllYXIgbGlmZXRpbWUgb2YgdGhlIElPVCBwcm9kdWN0cycgYmF0dGVyeS4gDQoNCj5JIHNlZSAz IG1lc3NhZ2VzIGFuZCBubyBjcnlwdG9ncmFwaGljIG9wZXJhdGlvbnMgZm9yIHRoZSBjbGllbnQg aW4gRmlndXJlIDIgb2YgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUwNzcjcGFnZS01 LiAgU28gSSBndWVzcyB5b3UncmUgc2F5aW5nIHRoZSBJb1QgZGV2aWNlIGNhbid0IHNlbmQgdHdv IHBhY2tldHMgYW5kIHJlY2VpdmUgb25lIHBhY2tldCB3aXRob3V0IGltcGFjdGluZyBpdHMgYmF0 dGVyeS4gIEkgYWdyZWUgJ2NpZCcgaXMgbW9yZSBlZmZpY2llbnQsIGJ1dCBpdCBpc24ndCB5ZXQg c3RhbmRhcmRpemVkLiAgSSB3b3VsZCBjb25zaWRlciBkb2luZyA+UkZDNTA3NyBhbmQgdGhlbiwg d2hlbiAnY2lkJyBvciBEVExTIDEuMyBpcyBhdmFpbGFibGUsIHVwZGF0ZSB0aGUgZGV2aWNlcyB0 byBzdXBwb3J0ICdjaWQnIG9yIERUTFMgMS4zLCBhcyBTZWFuIGltcGxpZWQgd2hlbiBoZSBhc2tl ZCBpZiB0aGUgZGV2aWNlcyBjb3VsZCBiZSB1cGRhdGVkLg0KDQo+IChJIGhvcGUgdGhlIGRldmlj ZXMgYXJlbid0IHVzaW5nIHRoZSBzYW1lIHByZS1zaGFyZWQga2V5ISAgVGhhdCB3b3VsZCBiZSBi YWQuKQ0KDQo+LWQNCltZaW5dIEZpZ3VyZSAyIGlzIFRMUyByZXN1bXB0aW9uLiBGb3IgRFRMUywg dGhlcmUgYXJlICJjbGllbnRoZWxsbyIgYW5kICJoZWxsb3ZlcmlmeXJlcXVlc3QiIGJlZm9yZSB0 aGUgcmVzdW1wdGlvbiBwcm9jZWR1cmUgaW4gRmlndXJlMi4gQW55d2F5LCB0aGUgcmVzdW1wdGlv biBtZWNoYW5pc20gaXMgbm90IGVmZmljaWVudCBmb3IgYmF0dGVyeS1jb25zdHJhaW5lZCBJT1Qg ZGV2aWNlcy4NCkZvciB1cGdyYWRpbmcgcHJvYmxlbSB5b3UgYW5kIFNlYW4gbWVudGlvbmVkLCBw bGVhc2Ugc2VlIG15IHJlcGx5IGZvciBTZWFuLiANCg0KDQoNCj4gDQo+PiBzcHQNCj4+IA0KPj4+ IEFueSBjb21tZW50IGlzIGFwcHJlY2lhdGVkLg0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+Pj4gWWlu IFhpbnhpbmcNCj4+PiANCj4+PiANCj4+PiDlj5Hku7bkuro6IHlpbnhpbnhpbmcgDQo+Pj4g5Y+R 6YCB5pe26Ze0OiAyMDE35bm0NuaciDI35pelIDE2OjI4DQo+Pj4g5pS25Lu25Lq6OiAnRXJpYyBS ZXNjb3JsYScNCj4+PiDmioTpgIE6IHRsc0BpZXRmLm9yZzsgVG9iaWFzIEdvbmRyb20NCj4+PiDk uLvpopg6IFJlOiBbVExTXSBZaW4gWGlueGluZyBqb2lucyB0aGUgVExTIFdHDQo+Pj4gDQo+Pj4g VGhhbmtzIEVyaWMsDQo+Pj4gDQo+Pj4gSSBoYXZlIHNlZW4gdGhlIENJRCBzY2hlbWUsIGFuZCB0 YWxrZWQgd2l0aCBIYW5uZXModGhlIGF1dGhvciBvZiB0aGUgc2NoZW1lKS4NCj4+PiANCj4+PiBD SUQgc2NoZW1lIGlzIGEgZ29vZCBpZGVhIHRvIHNvbHZlIHRoZSBwcm9ibGVtIEkgbWVudGlvbmVk Lg0KPj4+IA0KPj4+IEkgdGhpbmsgdGhlIGxlbmd0aCBvZiBDSUQgKGN1cnJlbnRseSwgaXQgaXMg MzIgYml0cykgY2FuIGJlIGxvbmdlciBzbyB0aGF0IGl0IGNhbiBzdXBwb3J0IG1vcmUgRFRMUyBz ZXNzaW9ucy4gSXQgaXMga25vd24gdGhhdCBmb3IgSU9UIHNjZW5hcmlvLCAxIG1pbGxpb24gY29u bmVjdGlvbiBpcyBub3RoaW5nLg0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+Pj4gWWluIFhpbnhpbmcN Cj4+PiANCj4+PiDlj5Hku7bkuro6IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21d IA0KPj4+IOWPkemAgeaXtumXtDogMjAxN+W5tDbmnIgyNeaXpSAyMTozMw0KPj4+IOaUtuS7tuS6 ujogeWlueGlueGluZw0KPj4+IOaKhOmAgTogdGxzQGlldGYub3JnOyBYaW9uZ3hpYW9jaHVuDQo+ Pj4g5Li76aKYOiBSZTogW1RMU10gWWluIFhpbnhpbmcgam9pbnMgdGhlIFRMUyBXRw0KPj4+IA0K Pj4+IEhpIFlpbiwNCj4+PiANCj4+PiBUaGUgdXN1YWwgc29sdXRpb24gdG8gdGhpcyBpcyB0byBh ZGQgYSBjb25uZWN0aW9uIGlkLiBQbGVhc2Ugc2VlOg0KPj4+IGh0dHBzOi8vZ2l0aHViLmNvbS90 bHN3Zy9kdGxzMTMtc3BlYy9pc3N1ZXMvNg0KPj4+IA0KPj4+IC1Fa3INCj4+PiANCj4+PiANCj4+ PiANCj4+PiANCj4+PiBPbiBTdW4sIEp1biAyNSwgMjAxNyBhdCAyOjMzIEFNLCB5aW54aW54aW5n IDx5aW54aW54aW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+IEhlbGxvIGV2ZXJ5b25lLA0KPj4+ IA0KPj4+IEkgYW0gWWluIFhpbnhpbmcgZnJvbSBIdWF3ZWkgY29tcGFueS4gSSBhbSBnbGFkIHRv IGpvaW4gdGhlIFRMUyBXRy4NCj4+PiANCj4+PiBGb3IgdGhlIERMVFMgMS4zIGRyYWZ0LCBJIGFt IGludGVyZXN0ZWQgYW5kIGhhdmUgc29tZSBpZGVhcyB0byB0YWxrIHdpdGggeW91Lg0KPj4+IA0K Pj4+IERUTFMgaGFzIGEgbG90IG9mIGFwcGxpY2F0aW9uIHNjZW5hcmlvcyBpbiBJT1QgZmllbGRz LCBidXQgY3VycmVudGx5LCB0aGVyZSBpcyBzb21lIGRpZmZpY3VsdHkgd2hlbiBEVExTIDEuMiBp cyBhcHBsaWVkIHRvIElPVCBkZXZpY2VzLCBlc3BlY2lhbGx5IHRoZSBiYXR0ZXJ5LWNvbnN0cmFp bmVkIElPVCBkZXZpY2VzLg0KPj4+IA0KPj4+IEZvciBleGFtcGxlLCB3aGVuIHRoZSBJT1QgZGV2 aWNlIHdha2VzIHVwIGZyb20gc2xlZXAgbW9kZSwgdGhlIE5BVCB0YWJsZSBtYXkgaGF2ZSBleHBp cmVkLg0KPj4+IFRoZW4gdGhlIElPVCBkZXZpY2UgaGFzIHRvIGVzdGFibGlzaCBhIG5ldyBEVExT IHNlc3Npb24gb3IgYXQgbGVhc3QgbGF1bmNoZXMgYSByZXN1bWUgcHJvY2VzcyB3aXRoIHRoZSBz ZXJ2ZXIsIHRoZSBjb3JyZXNwb25kaW5nIHBvd2VyIGNvbnN1bXB0aW9uIGlzIHRvbyBoaWdoIGZv ciBzb21lIHBvd2VyLWNvbnN0cmFpbmVkIGRldmljZXMuIA0KPj4+IEhvdyBjYW4gRFRMUyByZW5l Z290aWF0aW9uIGJlIGF2b2lkZWQgaW4gb3JkZXIgdG8gc2F2ZSBiYXR0ZXJ5Pw0KPj4+IA0KPj4+ IEkgaG9wZSB0aGUgY29udHJpYnV0b3JzIG9mIERUTFMgMS4zIChvciBEVExTIDEuMikgY2FuIGNv bnNpZGVyIHRoaXMgcHJvYmxlbSBhbmQgZ2l2ZSBhIHByb3BlciBzb2x1dGlvbi4gIA0KPj4+IA0K Pj4+IEFueSBjb21tZW50IG9yIGlkZWEgYWJvdXQgdGhpcyBwcm9ibGVtIGlzIHdlbGNvbWUuDQo+ Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiBZaW4gWGlueGluZw0KPj4+IA0KPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gVExTIG1haWxpbmcgbGlz dA0KPj4+IFRMU0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzDQo+Pj4gDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+PiBUTFMgbWFpbGluZyBsaXN0DQo+Pj4gVExTQGlldGYub3Jn DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCj4+IA0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFRMUyBt YWlsaW5nIGxpc3QNCj4+IFRMU0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90bHMNCj4gDQoNCg== From nobody Wed Jul 12 21:35:21 2017 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 B552112955F for ; Wed, 12 Jul 2017 21:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vhfGpdyQHAuE for ; Wed, 12 Jul 2017 21:35:17 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4B4126B6D for ; Wed, 12 Jul 2017 21:35:17 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id q85so5667755pfq.2 for ; Wed, 12 Jul 2017 21:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HI4I07Zi65cV9z/vjsN1k5URDS9ag8KF/D1oXukY3OM=; b=TwTahbt/itXDFlKd8q1rCxSBeAs+IwhXyDQSApA9CowvN1XTCmyvwSArzMfIQ+INJd GL//FCuAYPPpT8sQmIfjqd5YnP6L6lN5RaVHOeaJbo5doA0MfRqm7IwoiSXKg5W/nrqc x9MDyYFpY/wDdltGznC5JBiMaNZwKcHuXmhAyjW1lW/dJK0CI66rOi8/w1IW8SDGFJsY dstlsc28UYfF8ttkFersqo/+E2E/S2VZbxrKCDSMI22qXBBtR4OKETVHfK1+8swCqO+2 H6LWZ+DGak67rUzPjYd4SJ92Asn5HQ0dtNn5ZAx0mnzaFFtw+oYWGBYzQjVEGw2rlZeh S/8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HI4I07Zi65cV9z/vjsN1k5URDS9ag8KF/D1oXukY3OM=; b=FRyx8ewR4BTPeOrOWEMbh3B+V1FRQndA5W/X6XZqv7vz0BVvxI7geZobX18/PZDHr5 3vRirF3RtYi9wZqS2OPnKTqHp6qvABQkZPfoK+qbkX2PVjDI5TF17e7kDC3N7Opt6j4A F/YnIYkYml501oBbOkk12hO57eJSjWaOauNLiG4wT+F5XsXB+DuMa7WebbF7bGjabiKU NTJwuGYi9Ae9hGQMS/RlTKqD2DPuXcCPM2dzKwurRWiNYo0fI48ayX4zpOWw95BUNZ7/ 5HrjtNLc3FVY/unye3MCpSojOGxns9yYT0s8DtZnzHLhimqceEZKNAq4P5xjj4apyaMO TLZQ== X-Gm-Message-State: AIVw111Oy7JMX/MbSWzb5F1qKgAE1Ic/NENoU1Kr/EIuYfMUezTNYV6/ GR7MpFtSblO9ng== X-Received: by 10.99.172.67 with SMTP id z3mr7266756pgn.246.1499920516905; Wed, 12 Jul 2017 21:35:16 -0700 (PDT) Received: from [192.168.1.2] (c-76-103-103-185.hsd1.ca.comcast.net. [76.103.103.185]) by smtp.gmail.com with ESMTPSA id b13sm8431663pfc.25.2017.07.12.21.35.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 21:35:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dan Wing In-Reply-To: Date: Wed, 12 Jul 2017 21:35:15 -0700 Cc: "tls@ietf.org" , Sean Turner Content-Transfer-Encoding: quoted-printable Message-Id: <609E20D4-2430-4DE0-BF10-C3F44AA4A350@gmail.com> References: <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com> To: yinxinxing X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 04:35:20 -0000 > On Jul 12, 2017, at 7:11 PM, yinxinxing wrote: >=20 > Thanks Wing, >=20 > Please see my comments inline. >=20 > Regards, > Yin Xinxing >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Dan Wing [mailto:danwing@gmail.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8813=E6=97=A5= 8:52 > =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing > =E6=8A=84=E9=80=81: tls@ietf.org; Sean Turner > =E4=B8=BB=E9=A2=98: Re: [TLS] Solving the NAT expiring problem causing = DTLS renegotiation with high power consumption in DTLS1.2 >=20 >=20 >> On Jul 12, 2017, at 5:21 PM, yinxinxing = wrote: >>=20 >> Hi Dan Wing, >>=20 >> Thanks for your comments. >>=20 >> Please see my comments inline. >>=20 >> Regards, >> Yin Xinxing >>=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dan Wing [mailto:danwing@gmail.com]=20 >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8813=E6=97=A5= 1:09 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing >> =E6=8A=84=E9=80=81: tls@ietf.org; Sean Turner >> =E4=B8=BB=E9=A2=98: Re: [TLS] Solving the NAT expiring problem = causing DTLS renegotiation with high power consumption in DTLS1.2 >>=20 >>=20 >>> On Jul 12, 2017, at 7:56 AM, Sean Turner wrote: >>>=20 >>>=20 >>>> On Jul 6, 2017, at 23:04, yinxinxing wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> The NAT table expiring problem mentioned in the following email = should also be considered in DTLS1.2 as an extension. >>>>=20 >>>> The value and necessity are as follows. >>>>=20 >>>> 1. Essentially, NAT expiring problem causing DTLS renegotiation = with high power consumption is existing in DTLS 1.2. Even if we solve = this in DTLS1.3, this problem still exist for products using DTLS1.2. >>>> Currently, many IOT products using DTLS 1.2 are going to be = deployed commercially, such as intelligent water/gas meter. These meters = usually have limited battery and low cost. To be more accurate, the = battery of the chip module of the intelligent water/gas meter are = required to last for 10 years. These lead to an exercise strict control = over the power consumption of the chip module. NAT expiring problem = causing DTLS renegotiation with high power consumption is a bottleneck = of these IOT devices. According to our experimental data, under the = worst coverage level (ECL2), power consumption of the chip module when = DTLS is embedded increases by nearly 60%. Therefore, there should be a = solution to solve the urgent problem to match the low-cost and = low-battery feature of the IOT devices in DTLS 1.2. >>>=20 >>> I have to ask whether these IoT devices are updatable? >>>=20 >>>> 2. DTLS 1.3 will be standardized in 2018, but the corresponding = open source code will be available about one year later after the = standardization. At present, large-scale commercial IOT industry = deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope = that the above problem could be solved in DTLS 1.2 as soon as possible. >>>=20 >>> On this point, I=E2=80=99m hoping that you=E2=80=99ll be wrong ;). = =46rom the list of TLS implementations found here: >>> https://github.com/tlswg/tls13-spec/wiki/Implementations >>> and assuming there is as much enthusiasm to implement DTLS1.3 as = there was for TLS1.3 then I=E2=80=99m hoping that the DTLS = implementations will be ready much sooner than a year after publication = (they might be ready before the RFC is published). >>=20 >>=20 >>> Yin Xinxing, >>=20 >>> While waiting for cid, perhaps today do session resumption = (RFC5077), anytime the client has reason to suspect their UDP port or IP = address might have changed -- such as it's been longer than, say, 30 = seconds since last UDP transmission. (The problem isn't solely NAT; = there are several ISPs that change subscriber's IP address, >also = forcing re-negotiation of DTLS security association. Less frequent than = NATs timing out UDP, of course.) >>=20 >>> -d >> [Yin] Yes, you are right. The problem isn't solely NAT expiring, but = changing from WLAN to 3GPP, or IOT devices waking up from sleep mode. = All of these could lead to IP change. >> Session resumption is a good way to re-negotiate the DTLS session. = However, according to our IOT products, e.g., intelligent water/gas = meter, session resumption mechanism still needs to communicate 6 or 5 = messages(based on the cipher suite TLS_PSK_WITH_AES_128_CBC_SHA256) and = this re-negotiation mechanism still costs too much battery and can not = ensure 10-year lifetime of the IOT products' battery.=20 >=20 >> I see 3 messages and no cryptographic operations for the client in = Figure 2 of https://tools.ietf.org/html/rfc5077#page-5. So I guess = you're saying the IoT device can't send two packets and receive one = packet without impacting its battery. I agree 'cid' is more efficient, = but it isn't yet standardized. I would consider doing >RFC5077 and = then, when 'cid' or DTLS 1.3 is available, update the devices to support = 'cid' or DTLS 1.3, as Sean implied when he asked if the devices could be = updated. >=20 >> (I hope the devices aren't using the same pre-shared key! That would = be bad.) >=20 >> -d > [Yin] Figure 2 is TLS resumption. For DTLS, there are "clienthello" = and "helloverifyrequest" HelloVerifyRequest is only sent if the DTLS server is defending itself = from attack. I would imagine DDoS mitigation companies will, or have = already, built DTLS defenses that can avoid sending that message in many = cases, or such logic could be included as part of a quality DTLS server = implementation? If the client devices are so sensitive to = sending/receiving packets, I wouldn't want the server to challenge them = with HelloVerifyRequest, but instead be sure there is DoS and DDoS = mitigation on the server that doesn't push effort back to the clients. = Afterall, the client sent a packet that the server could have validated, = at cryptographic cost to the server. Creative encoding of that nonce = could allow the server to reduce its validation effort and reduce its = likelyhood of challenging with a HelloVerifyRequest. > before the resumption procedure in Figure2. Anyway, the resumption = mechanism is not efficient for battery-constrained IOT devices. > For upgrading problem you and Sean mentioned, please see my reply for = Sean.=20 Thanks, I did read that reply. The devices can't be upgraded. -d >=20 >=20 >=20 >>=20 >>> spt >>>=20 >>>> Any comment is appreciated. >>>>=20 >>>> Regards, >>>> Yin Xinxing >>>>=20 >>>>=20 >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: yinxinxing=20 >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8827=E6=97= =A5 16:28 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric Rescorla' >>>> =E6=8A=84=E9=80=81: tls@ietf.org; Tobias Gondrom >>>> =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG >>>>=20 >>>> Thanks Eric, >>>>=20 >>>> I have seen the CID scheme, and talked with Hannes(the author of = the scheme). >>>>=20 >>>> CID scheme is a good idea to solve the problem I mentioned. >>>>=20 >>>> I think the length of CID (currently, it is 32 bits) can be longer = so that it can support more DTLS sessions. It is known that for IOT = scenario, 1 million connection is nothing. >>>>=20 >>>> Regards, >>>> Yin Xinxing >>>>=20 >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]=20 >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8825=E6=97= =A5 21:33 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing >>>> =E6=8A=84=E9=80=81: tls@ietf.org; Xiongxiaochun >>>> =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG >>>>=20 >>>> Hi Yin, >>>>=20 >>>> The usual solution to this is to add a connection id. Please see: >>>> https://github.com/tlswg/dtls13-spec/issues/6 >>>>=20 >>>> -Ekr >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing = wrote: >>>> Hello everyone, >>>>=20 >>>> I am Yin Xinxing from Huawei company. I am glad to join the TLS WG. >>>>=20 >>>> For the DLTS 1.3 draft, I am interested and have some ideas to talk = with you. >>>>=20 >>>> DTLS has a lot of application scenarios in IOT fields, but = currently, there is some difficulty when DTLS 1.2 is applied to IOT = devices, especially the battery-constrained IOT devices. >>>>=20 >>>> For example, when the IOT device wakes up from sleep mode, the NAT = table may have expired. >>>> Then the IOT device has to establish a new DTLS session or at least = launches a resume process with the server, the corresponding power = consumption is too high for some power-constrained devices.=20 >>>> How can DTLS renegotiation be avoided in order to save battery? >>>>=20 >>>> I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this = problem and give a proper solution. =20 >>>>=20 >>>> Any comment or idea about this problem is welcome. >>>>=20 >>>> Regards, >>>> Yin Xinxing >>>>=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 >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 From nobody Thu Jul 13 01:56:11 2017 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 E2E94131488 for ; Thu, 13 Jul 2017 01:56:09 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 i534MnDYAVgy for ; Thu, 13 Jul 2017 01:56:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1153131468 for ; Thu, 13 Jul 2017 01:56:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRA41083; Thu, 13 Jul 2017 08:56:03 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Jul 2017 09:55:43 +0100 Received: from DGGEMI401-HUB.china.huawei.com (10.3.17.134) by NKGEML413-HUB.china.huawei.com (10.98.56.74) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 13 Jul 2017 16:55:34 +0800 Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.203]) by dggemi401-hub.china.huawei.com ([10.3.17.134]) with mapi id 14.03.0301.000; Thu, 13 Jul 2017 16:55:32 +0800 From: yinxinxing To: Dan Wing CC: "tls@ietf.org" , Sean Turner Thread-Topic: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 Thread-Index: AdL2zV5W/HDgxBACQSqQFOyDPszOzQEDqAMAAASeQgAAH2kMQP//hj2A//9mI6CAANgkgP//MwQA Date: Thu, 13 Jul 2017 08:55:31 +0000 Message-ID: References: <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com> <609E20D4-2430-4DE0-BF10-C3F44AA4A350@gmail.com> In-Reply-To: <609E20D4-2430-4DE0-BF10-C3F44AA4A350@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.596735A4.001A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.203, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7c9b4d1e7dd2418be352d6763ee8b7a5 Archived-At: Subject: [TLS] =?utf-8?b?562U5aSNOiAgU29sdmluZyB0aGUgTkFUIGV4cGlyaW5nIHBy?= =?utf-8?q?oblem_causing_DTLS_renegotiation_with_high_power_consumption_in?= =?utf-8?q?_DTLS1=2E2?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 08:56:10 -0000 SGkgV2luZywNCg0KUGxlYXNlIHNlZSB0aGUgY29tbWVudHMgaW5saW5lDQoNClJlZ2FyZHMsDQpZ aW4gWGlueGluZw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IERhbiBXaW5n IFttYWlsdG86ZGFud2luZ0BnbWFpbC5jb21dIA0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0N+aciDEz 5pelIDEyOjM1DQrmlLbku7bkuro6IHlpbnhpbnhpbmcNCuaKhOmAgTogdGxzQGlldGYub3JnOyBT ZWFuIFR1cm5lcg0K5Li76aKYOiBSZTogW1RMU10gU29sdmluZyB0aGUgTkFUIGV4cGlyaW5nIHBy b2JsZW0gY2F1c2luZyBEVExTIHJlbmVnb3RpYXRpb24gd2l0aCBoaWdoIHBvd2VyIGNvbnN1bXB0 aW9uIGluIERUTFMxLjINCg0KDQo+IE9uIEp1bCAxMiwgMjAxNywgYXQgNzoxMSBQTSwgeWlueGlu eGluZyA8eWlueGlueGluZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IFRoYW5rcyBXaW5nLA0K PiANCj4gUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuDQo+IA0KPiBSZWdhcmRzLA0KPiBZ aW4gWGlueGluZw0KPiANCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IERh biBXaW5nIFttYWlsdG86ZGFud2luZ0BnbWFpbC5jb21dIA0KPiDlj5HpgIHml7bpl7Q6IDIwMTfl ubQ35pyIMTPml6UgODo1Mg0KPiDmlLbku7bkuro6IHlpbnhpbnhpbmcNCj4g5oqE6YCBOiB0bHNA aWV0Zi5vcmc7IFNlYW4gVHVybmVyDQo+IOS4u+mimDogUmU6IFtUTFNdIFNvbHZpbmcgdGhlIE5B VCBleHBpcmluZyBwcm9ibGVtIGNhdXNpbmcgRFRMUyByZW5lZ290aWF0aW9uIHdpdGggaGlnaCBw b3dlciBjb25zdW1wdGlvbiBpbiBEVExTMS4yDQo+IA0KPiANCj4+IE9uIEp1bCAxMiwgMjAxNywg YXQgNToyMSBQTSwgeWlueGlueGluZyA8eWlueGlueGluZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4+ IA0KPj4gSGkgRGFuIFdpbmcsDQo+PiANCj4+IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCj4+ IA0KPj4gUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuDQo+PiANCj4+IFJlZ2FyZHMsDQo+ PiBZaW4gWGlueGluZw0KPj4gDQo+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+PiDlj5Hku7bk uro6IERhbiBXaW5nIFttYWlsdG86ZGFud2luZ0BnbWFpbC5jb21dIA0KPj4g5Y+R6YCB5pe26Ze0 OiAyMDE35bm0N+aciDEz5pelIDE6MDkNCj4+IOaUtuS7tuS6ujogeWlueGlueGluZw0KPj4g5oqE 6YCBOiB0bHNAaWV0Zi5vcmc7IFNlYW4gVHVybmVyDQo+PiDkuLvpopg6IFJlOiBbVExTXSBTb2x2 aW5nIHRoZSBOQVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVzaW5nIERUTFMgcmVuZWdvdGlhdGlvbiB3 aXRoIGhpZ2ggcG93ZXIgY29uc3VtcHRpb24gaW4gRFRMUzEuMg0KPj4gDQo+PiANCj4+PiBPbiBK dWwgMTIsIDIwMTcsIGF0IDc6NTYgQU0sIFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT4gd3Jv dGU6DQo+Pj4gDQo+Pj4gDQo+Pj4+IE9uIEp1bCA2LCAyMDE3LCBhdCAyMzowNCwgeWlueGlueGlu ZyA8eWlueGlueGluZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEhpIGFsbCwNCj4+ Pj4gDQo+Pj4+IFRoZSBOQVQgdGFibGUgZXhwaXJpbmcgcHJvYmxlbSBtZW50aW9uZWQgaW4gdGhl ICBmb2xsb3dpbmcgZW1haWwgc2hvdWxkIGFsc28gYmUgY29uc2lkZXJlZCBpbiBEVExTMS4yIGFz IGFuIGV4dGVuc2lvbi4NCj4+Pj4gDQo+Pj4+IFRoZSB2YWx1ZSBhbmQgbmVjZXNzaXR5IGFyZSBh cyBmb2xsb3dzLg0KPj4+PiANCj4+Pj4gMS4gRXNzZW50aWFsbHksIE5BVCBleHBpcmluZyBwcm9i bGVtIGNhdXNpbmcgRFRMUyByZW5lZ290aWF0aW9uIHdpdGggaGlnaCBwb3dlciBjb25zdW1wdGlv biBpcyBleGlzdGluZyBpbiBEVExTIDEuMi4gRXZlbiBpZiB3ZSBzb2x2ZSB0aGlzIGluIERUTFMx LjMsIHRoaXMgcHJvYmxlbSBzdGlsbCBleGlzdCBmb3IgcHJvZHVjdHMgdXNpbmcgRFRMUzEuMi4N Cj4+Pj4gQ3VycmVudGx5LCBtYW55IElPVCBwcm9kdWN0cyB1c2luZyBEVExTIDEuMiBhcmUgZ29p bmcgdG8gYmUgZGVwbG95ZWQgY29tbWVyY2lhbGx5LCBzdWNoIGFzIGludGVsbGlnZW50IHdhdGVy L2dhcyBtZXRlci4gVGhlc2UgbWV0ZXJzIHVzdWFsbHkgaGF2ZSBsaW1pdGVkIGJhdHRlcnkgYW5k IGxvdyBjb3N0LiBUbyBiZSBtb3JlIGFjY3VyYXRlLCB0aGUgYmF0dGVyeSBvZiB0aGUgY2hpcCBt b2R1bGUgb2YgdGhlIGludGVsbGlnZW50IHdhdGVyL2dhcyBtZXRlciBhcmUgcmVxdWlyZWQgdG8g bGFzdCBmb3IgMTAgeWVhcnMuIFRoZXNlIGxlYWQgdG8gYW4gZXhlcmNpc2Ugc3RyaWN0IGNvbnRy b2wgb3ZlciB0aGUgcG93ZXIgY29uc3VtcHRpb24gb2YgdGhlIGNoaXAgbW9kdWxlLiBOQVQgZXhw aXJpbmcgcHJvYmxlbSBjYXVzaW5nIERUTFMgcmVuZWdvdGlhdGlvbiB3aXRoIGhpZ2ggcG93ZXIg Y29uc3VtcHRpb24gaXMgYSBib3R0bGVuZWNrIG9mIHRoZXNlIElPVCBkZXZpY2VzLiBBY2NvcmRp bmcgdG8gb3VyIGV4cGVyaW1lbnRhbCBkYXRhLCB1bmRlciB0aGUgd29yc3QgY292ZXJhZ2UgbGV2 ZWwgKEVDTDIpLCBwb3dlciBjb25zdW1wdGlvbiBvZiB0aGUgY2hpcCBtb2R1bGUgd2hlbiBEVExT IGlzIGVtYmVkZGVkIGluY3JlYXNlcyBieSBuZWFybHkgNjAlLiBUaGVyZWZvcmUsIHRoZXJlIHNo b3VsZCBiZSBhIHNvbHV0aW9uIHRvIHNvbHZlIHRoZSB1cmdlbnQgcHJvYmxlbSB0byBtYXRjaCB0 aGUgbG93LWNvc3QgYW5kIGxvdy1iYXR0ZXJ5IGZlYXR1cmUgb2YgdGhlIElPVCBkZXZpY2VzIGlu IERUTFMgMS4yLg0KPj4+IA0KPj4+IEkgaGF2ZSB0byBhc2sgd2hldGhlciB0aGVzZSBJb1QgZGV2 aWNlcyBhcmUgdXBkYXRhYmxlPw0KPj4+IA0KPj4+PiAyLiBEVExTIDEuMyB3aWxsIGJlIHN0YW5k YXJkaXplZCBpbiAyMDE4LCBidXQgdGhlIGNvcnJlc3BvbmRpbmcgb3BlbiBzb3VyY2UgY29kZSB3 aWxsIGJlIGF2YWlsYWJsZSBhYm91dCBvbmUgeWVhciBsYXRlciBhZnRlciB0aGUgc3RhbmRhcmRp emF0aW9uLiBBdCBwcmVzZW50LCBsYXJnZS1zY2FsZSBjb21tZXJjaWFsIElPVCBpbmR1c3RyeSBk ZXBsb3ltZW50IGlzIHVyZ2VudCwgaXQgaXMgdG9vIGxhdGUgdG8gd2FpdCBmb3IgRFRMUyAxLjMu IFRodXMsIHdlIGhvcGUgdGhhdCB0aGUgYWJvdmUgcHJvYmxlbSBjb3VsZCBiZSBzb2x2ZWQgaW4g RFRMUyAxLjIgYXMgc29vbiBhcyBwb3NzaWJsZS4NCj4+PiANCj4+PiBPbiB0aGlzIHBvaW50LCBJ 4oCZbSBob3BpbmcgdGhhdCB5b3XigJlsbCBiZSB3cm9uZyA7KS4gRnJvbSB0aGUgbGlzdCBvZiBU TFMgaW1wbGVtZW50YXRpb25zIGZvdW5kIGhlcmU6DQo+Pj4gaHR0cHM6Ly9naXRodWIuY29tL3Rs c3dnL3RsczEzLXNwZWMvd2lraS9JbXBsZW1lbnRhdGlvbnMNCj4+PiBhbmQgYXNzdW1pbmcgdGhl cmUgaXMgYXMgbXVjaCBlbnRodXNpYXNtIHRvIGltcGxlbWVudCBEVExTMS4zIGFzIHRoZXJlIHdh cyBmb3IgVExTMS4zIHRoZW4gSeKAmW0gaG9waW5nIHRoYXQgdGhlIERUTFMgaW1wbGVtZW50YXRp b25zIHdpbGwgYmUgcmVhZHkgbXVjaCBzb29uZXIgdGhhbiBhIHllYXIgYWZ0ZXIgcHVibGljYXRp b24gKHRoZXkgbWlnaHQgYmUgcmVhZHkgYmVmb3JlIHRoZSBSRkMgaXMgcHVibGlzaGVkKS4NCj4+ IA0KPj4gDQo+Pj4gWWluIFhpbnhpbmcsDQo+PiANCj4+PiBXaGlsZSB3YWl0aW5nIGZvciBjaWQs IHBlcmhhcHMgdG9kYXkgZG8gc2Vzc2lvbiByZXN1bXB0aW9uIChSRkM1MDc3KSwgYW55dGltZSB0 aGUgY2xpZW50IGhhcyByZWFzb24gdG8gc3VzcGVjdCB0aGVpciBVRFAgcG9ydCBvciBJUCBhZGRy ZXNzIG1pZ2h0IGhhdmUgY2hhbmdlZCAtLSBzdWNoIGFzIGl0J3MgYmVlbiBsb25nZXIgdGhhbiwg c2F5LCAzMCBzZWNvbmRzIHNpbmNlIGxhc3QgVURQIHRyYW5zbWlzc2lvbi4gIChUaGUgcHJvYmxl bSBpc24ndCBzb2xlbHkgTkFUOyB0aGVyZSBhcmUgc2V2ZXJhbCBJU1BzIHRoYXQgY2hhbmdlIHN1 YnNjcmliZXIncyBJUCBhZGRyZXNzLCA+YWxzbyBmb3JjaW5nIHJlLW5lZ290aWF0aW9uIG9mIERU TFMgc2VjdXJpdHkgYXNzb2NpYXRpb24uICBMZXNzIGZyZXF1ZW50IHRoYW4gTkFUcyB0aW1pbmcg b3V0IFVEUCwgb2YgY291cnNlLikNCj4+IA0KPj4+IC1kDQo+PiBbWWluXSBZZXMsIHlvdSBhcmUg cmlnaHQuIFRoZSBwcm9ibGVtIGlzbid0IHNvbGVseSBOQVQgZXhwaXJpbmcsIGJ1dCBjaGFuZ2lu ZyBmcm9tIFdMQU4gdG8gM0dQUCwgb3IgSU9UIGRldmljZXMgd2FraW5nIHVwIGZyb20gc2xlZXAg bW9kZS4gQWxsIG9mIHRoZXNlIGNvdWxkIGxlYWQgdG8gSVAgY2hhbmdlLg0KPj4gU2Vzc2lvbiBy ZXN1bXB0aW9uIGlzIGEgZ29vZCB3YXkgdG8gcmUtbmVnb3RpYXRlIHRoZSBEVExTIHNlc3Npb24u IEhvd2V2ZXIsIGFjY29yZGluZyB0byBvdXIgSU9UIHByb2R1Y3RzLCBlLmcuLCBpbnRlbGxpZ2Vu dCB3YXRlci9nYXMgbWV0ZXIsIHNlc3Npb24gcmVzdW1wdGlvbiBtZWNoYW5pc20gc3RpbGwgbmVl ZHMgdG8gY29tbXVuaWNhdGUgNiBvciA1IG1lc3NhZ2VzKGJhc2VkIG9uIHRoZSBjaXBoZXIgc3Vp dGUgVExTX1BTS19XSVRIX0FFU18xMjhfQ0JDX1NIQTI1NikgYW5kIHRoaXMgcmUtbmVnb3RpYXRp b24gbWVjaGFuaXNtIHN0aWxsIGNvc3RzIHRvbyBtdWNoIGJhdHRlcnkgYW5kIGNhbiBub3QgZW5z dXJlIDEwLXllYXIgbGlmZXRpbWUgb2YgdGhlIElPVCBwcm9kdWN0cycgYmF0dGVyeS4gDQo+IA0K Pj4gSSBzZWUgMyBtZXNzYWdlcyBhbmQgbm8gY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb25zIGZvciB0 aGUgY2xpZW50IGluIEZpZ3VyZSAyIG9mIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1 MDc3I3BhZ2UtNS4gIFNvIEkgZ3Vlc3MgeW91J3JlIHNheWluZyB0aGUgSW9UIGRldmljZSBjYW4n dCBzZW5kIHR3byBwYWNrZXRzIGFuZCByZWNlaXZlIG9uZSBwYWNrZXQgd2l0aG91dCBpbXBhY3Rp bmcgaXRzIGJhdHRlcnkuICBJIGFncmVlICdjaWQnIGlzIG1vcmUgZWZmaWNpZW50LCBidXQgaXQg aXNuJ3QgeWV0IHN0YW5kYXJkaXplZC4gIEkgd291bGQgY29uc2lkZXIgZG9pbmcgPlJGQzUwNzcg YW5kIHRoZW4sIHdoZW4gJ2NpZCcgb3IgRFRMUyAxLjMgaXMgYXZhaWxhYmxlLCB1cGRhdGUgdGhl IGRldmljZXMgdG8gc3VwcG9ydCAnY2lkJyBvciBEVExTIDEuMywgYXMgU2VhbiBpbXBsaWVkIHdo ZW4gaGUgYXNrZWQgaWYgdGhlIGRldmljZXMgY291bGQgYmUgdXBkYXRlZC4NCj4gDQo+PiAoSSBo b3BlIHRoZSBkZXZpY2VzIGFyZW4ndCB1c2luZyB0aGUgc2FtZSBwcmUtc2hhcmVkIGtleSEgIFRo YXQgd291bGQgYmUgYmFkLikNCj4gDQo+PiAtZA0KPiBbWWluXSBGaWd1cmUgMiBpcyBUTFMgcmVz dW1wdGlvbi4gRm9yIERUTFMsIHRoZXJlIGFyZSAiY2xpZW50aGVsbG8iIGFuZCAiaGVsbG92ZXJp ZnlyZXF1ZXN0Ig0KDQo+IEhlbGxvVmVyaWZ5UmVxdWVzdCBpcyBvbmx5IHNlbnQgaWYgdGhlIERU TFMgc2VydmVyIGlzIGRlZmVuZGluZyBpdHNlbGYgZnJvbSBhdHRhY2suICBJIHdvdWxkIGltYWdp bmUgRERvUyBtaXRpZ2F0aW9uIGNvbXBhbmllcyB3aWxsLCBvciBoYXZlIGFscmVhZHksIGJ1aWx0 IERUTFMgZGVmZW5zZXMgdGhhdCBjYW4gYXZvaWQgc2VuZGluZyB0aGF0IG1lc3NhZ2UgaW4gbWFu eSBjYXNlcywgb3Igc3VjaCBsb2dpYyBjb3VsZCBiZSBpbmNsdWRlZCBhcyBwYXJ0IG9mIGEgcXVh bGl0eSBEVExTIHNlcnZlciBpbXBsZW1lbnRhdGlvbj8gIA0KPiBJZiB0aGUgY2xpZW50IGRldmlj ZXMgYXJlIHNvIHNlbnNpdGl2ZSB0byBzZW5kaW5nL3JlY2VpdmluZyBwYWNrZXRzLCBJIHdvdWxk bid0IHdhbnQgdGhlIHNlcnZlciB0byBjaGFsbGVuZ2UgdGhlbSB3aXRoIEhlbGxvVmVyaWZ5UmVx dWVzdCwgYnV0IGluc3RlYWQgYmUgc3VyZSB0aGVyZSBpcyBEb1MgYW5kIEREb1MgbWl0aWdhdGlv biBvbiB0aGUgc2VydmVyIHRoYXQgZG9lc24ndCBwdXNoIGVmZm9ydCBiYWNrIHRvIHRoZSBjbGll bnRzLiAgQWZ0ZXJhbGwsIHRoZSBjbGllbnQgc2VudCBhIHBhY2tldCB0aGF0IHRoZSBzZXJ2ZXIg Y291bGQgaGF2ZSB2YWxpZGF0ZWQsIA0KPiBhdCBjcnlwdG9ncmFwaGljIGNvc3QgdG8gdGhlIHNl cnZlci4gIENyZWF0aXZlIGVuY29kaW5nIG9mIHRoYXQgbm9uY2UgY291bGQgYWxsb3cgdGhlIHNl cnZlciB0byByZWR1Y2UgaXRzIHZhbGlkYXRpb24gZWZmb3J0IGFuZCByZWR1Y2UgaXRzIGxpa2Vs eWhvb2Qgb2YgY2hhbGxlbmdpbmcgd2l0aCBhIEhlbGxvVmVyaWZ5UmVxdWVzdC4NCg0KPiBiZWZv cmUgdGhlIHJlc3VtcHRpb24gcHJvY2VkdXJlIGluIEZpZ3VyZTIuIEFueXdheSwgdGhlIHJlc3Vt cHRpb24gbWVjaGFuaXNtIGlzIG5vdCBlZmZpY2llbnQgZm9yIGJhdHRlcnktY29uc3RyYWluZWQg SU9UIGRldmljZXMuDQo+IEZvciB1cGdyYWRpbmcgcHJvYmxlbSB5b3UgYW5kIFNlYW4gbWVudGlv bmVkLCBwbGVhc2Ugc2VlIG15IHJlcGx5IGZvciBTZWFuLiANCg0KPiBUaGFua3MsIEkgZGlkIHJl YWQgdGhhdCByZXBseS4gIFRoZSBkZXZpY2VzIGNhbid0IGJlIHVwZ3JhZGVkLg0KDQo+IC1kDQoN CltZaW5dIEkgZG9uJ3QgdGhpbmsgc28uIEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHNlY3VyaXR5 LCB0aGVzZSBtZXNzYWdlcyBhcmUgbmVlZGVkLiBFdmVuIHRoZSBjbGllbnQgZGV2aWNlcyBhcmUg YmF0dGVyeS1jb25zdHJhaW5lZCwgc2VjdXJpdHkgaXMgbmVlZGVkIGluIERUTFMgYXMgcmVxdWly ZWQgYnkgb3VyIGN1c3RvbWVycy4gDQoNCj4gDQo+IA0KPiANCj4+IA0KPj4+IHNwdA0KPj4+IA0K Pj4+PiBBbnkgY29tbWVudCBpcyBhcHByZWNpYXRlZC4NCj4+Pj4gDQo+Pj4+IFJlZ2FyZHMsDQo+ Pj4+IFlpbiBYaW54aW5nDQo+Pj4+IA0KPj4+PiANCj4+Pj4g5Y+R5Lu25Lq6OiB5aW54aW54aW5n IA0KPj4+PiDlj5HpgIHml7bpl7Q6IDIwMTflubQ25pyIMjfml6UgMTY6MjgNCj4+Pj4g5pS25Lu2 5Lq6OiAnRXJpYyBSZXNjb3JsYScNCj4+Pj4g5oqE6YCBOiB0bHNAaWV0Zi5vcmc7IFRvYmlhcyBH b25kcm9tDQo+Pj4+IOS4u+mimDogUmU6IFtUTFNdIFlpbiBYaW54aW5nIGpvaW5zIHRoZSBUTFMg V0cNCj4+Pj4gDQo+Pj4+IFRoYW5rcyBFcmljLA0KPj4+PiANCj4+Pj4gSSBoYXZlIHNlZW4gdGhl IENJRCBzY2hlbWUsIGFuZCB0YWxrZWQgd2l0aCBIYW5uZXModGhlIGF1dGhvciBvZiB0aGUgc2No ZW1lKS4NCj4+Pj4gDQo+Pj4+IENJRCBzY2hlbWUgaXMgYSBnb29kIGlkZWEgdG8gc29sdmUgdGhl IHByb2JsZW0gSSBtZW50aW9uZWQuDQo+Pj4+IA0KPj4+PiBJIHRoaW5rIHRoZSBsZW5ndGggb2Yg Q0lEIChjdXJyZW50bHksIGl0IGlzIDMyIGJpdHMpIGNhbiBiZSBsb25nZXIgc28gdGhhdCBpdCBj YW4gc3VwcG9ydCBtb3JlIERUTFMgc2Vzc2lvbnMuIEl0IGlzIGtub3duIHRoYXQgZm9yIElPVCBz Y2VuYXJpbywgMSBtaWxsaW9uIGNvbm5lY3Rpb24gaXMgbm90aGluZy4NCj4+Pj4gDQo+Pj4+IFJl Z2FyZHMsDQo+Pj4+IFlpbiBYaW54aW5nDQo+Pj4+IA0KPj4+PiDlj5Hku7bkuro6IEVyaWMgUmVz Y29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dIA0KPj4+PiDlj5HpgIHml7bpl7Q6IDIwMTflubQ2 5pyIMjXml6UgMjE6MzMNCj4+Pj4g5pS25Lu25Lq6OiB5aW54aW54aW5nDQo+Pj4+IOaKhOmAgTog dGxzQGlldGYub3JnOyBYaW9uZ3hpYW9jaHVuDQo+Pj4+IOS4u+mimDogUmU6IFtUTFNdIFlpbiBY aW54aW5nIGpvaW5zIHRoZSBUTFMgV0cNCj4+Pj4gDQo+Pj4+IEhpIFlpbiwNCj4+Pj4gDQo+Pj4+ IFRoZSB1c3VhbCBzb2x1dGlvbiB0byB0aGlzIGlzIHRvIGFkZCBhIGNvbm5lY3Rpb24gaWQuIFBs ZWFzZSBzZWU6DQo+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy9kdGxzMTMtc3BlYy9pc3N1 ZXMvNg0KPj4+PiANCj4+Pj4gLUVrcg0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4g T24gU3VuLCBKdW4gMjUsIDIwMTcgYXQgMjozMyBBTSwgeWlueGlueGluZyA8eWlueGlueGluZ0Bo dWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4gSGVsbG8gZXZlcnlvbmUsDQo+Pj4+IA0KPj4+PiBJIGFt IFlpbiBYaW54aW5nIGZyb20gSHVhd2VpIGNvbXBhbnkuIEkgYW0gZ2xhZCB0byBqb2luIHRoZSBU TFMgV0cuDQo+Pj4+IA0KPj4+PiBGb3IgdGhlIERMVFMgMS4zIGRyYWZ0LCBJIGFtIGludGVyZXN0 ZWQgYW5kIGhhdmUgc29tZSBpZGVhcyB0byB0YWxrIHdpdGggeW91Lg0KPj4+PiANCj4+Pj4gRFRM UyBoYXMgYSBsb3Qgb2YgYXBwbGljYXRpb24gc2NlbmFyaW9zIGluIElPVCBmaWVsZHMsIGJ1dCBj dXJyZW50bHksIHRoZXJlIGlzIHNvbWUgZGlmZmljdWx0eSB3aGVuIERUTFMgMS4yIGlzIGFwcGxp ZWQgdG8gSU9UIGRldmljZXMsIGVzcGVjaWFsbHkgdGhlIGJhdHRlcnktY29uc3RyYWluZWQgSU9U IGRldmljZXMuDQo+Pj4+IA0KPj4+PiBGb3IgZXhhbXBsZSwgd2hlbiB0aGUgSU9UIGRldmljZSB3 YWtlcyB1cCBmcm9tIHNsZWVwIG1vZGUsIHRoZSBOQVQgdGFibGUgbWF5IGhhdmUgZXhwaXJlZC4N Cj4+Pj4gVGhlbiB0aGUgSU9UIGRldmljZSBoYXMgdG8gZXN0YWJsaXNoIGEgbmV3IERUTFMgc2Vz c2lvbiBvciBhdCBsZWFzdCBsYXVuY2hlcyBhIHJlc3VtZSBwcm9jZXNzIHdpdGggdGhlIHNlcnZl ciwgdGhlIGNvcnJlc3BvbmRpbmcgcG93ZXIgY29uc3VtcHRpb24gaXMgdG9vIGhpZ2ggZm9yIHNv bWUgcG93ZXItY29uc3RyYWluZWQgZGV2aWNlcy4gDQo+Pj4+IEhvdyBjYW4gRFRMUyByZW5lZ290 aWF0aW9uIGJlIGF2b2lkZWQgaW4gb3JkZXIgdG8gc2F2ZSBiYXR0ZXJ5Pw0KPj4+PiANCj4+Pj4g SSBob3BlIHRoZSBjb250cmlidXRvcnMgb2YgRFRMUyAxLjMgKG9yIERUTFMgMS4yKSBjYW4gY29u c2lkZXIgdGhpcyBwcm9ibGVtIGFuZCBnaXZlIGEgcHJvcGVyIHNvbHV0aW9uLiAgDQo+Pj4+IA0K Pj4+PiBBbnkgY29tbWVudCBvciBpZGVhIGFib3V0IHRoaXMgcHJvYmxlbSBpcyB3ZWxjb21lLg0K Pj4+PiANCj4+Pj4gUmVnYXJkcywNCj4+Pj4gWWluIFhpbnhpbmcNCj4+Pj4gDQo+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IFRMUyBtYWls aW5nIGxpc3QNCj4+Pj4gVExTQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGxzDQo+Pj4+IA0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gVExTIG1haWxpbmcgbGlzdA0KPj4+ PiBUTFNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90bHMNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IFRMUyBtYWlsaW5nIGxpc3QNCj4+PiBUTFNAaWV0Zi5vcmcNCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KPj4gDQo+IA0KDQo= From nobody Thu Jul 13 05:00:17 2017 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 23C48127B60 for ; Thu, 13 Jul 2017 05:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCf0YIv2PHCj for ; Thu, 13 Jul 2017 05:00:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C70126557 for ; Thu, 13 Jul 2017 05:00:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52753BE5F; Thu, 13 Jul 2017 13:00:07 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVxl2Vx6U1yb; Thu, 13 Jul 2017 13:00:07 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1898ABE5C; Thu, 13 Jul 2017 13:00:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499947207; bh=IYrKKw7IsPWBomzRqJ0HmawetVegJL3VsvYJ5+1hmTA=; h=To:Cc:From:Subject:Date:From; b=EXaxHw2nv7JdmW7RtFMRX0zizSOPodjlCxHZ5914iJgpP8r5wFN8nleCmWwzRl25K S/Si7z6Wge60RBIgR27Id4zOEQoVih4wA4i8e3rMXcDFMr0ycskoVUbNNe4jre2Zt0 ktIYW+fKshAbjVXHxT/gp16GoG+IzdWkCk0CK3ZM= To: tls chair Cc: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 13 Jul 2017 13:00:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="soBSJclCM0SXaNV8RLfJPAxdIuKULAIso" Archived-At: Subject: [TLS] possible new work item: not breaking TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 12:00:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --soBSJclCM0SXaNV8RLfJPAxdIuKULAIso Content-Type: multipart/mixed; boundary="QIISL6X94OBDRjo5mS4gxSrBUW9uWV37p"; protected-headers="v1" From: Stephen Farrell To: tls chair Cc: "tls@ietf.org" Message-ID: Subject: possible new work item: not breaking TLS --QIISL6X94OBDRjo5mS4gxSrBUW9uWV37p Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi again TLS WG chairs, I've done a bit more work on the collection of arguments against the latest break-TLS proposal. [1] I plan to keep working on that so more input is welcome. (Corrections where I've gotten stuff wrong are even more welcome.) I'd like to again request some time on the agenda to allow discussion of those points in a more structured manner than will be possible during the mic-line scrum that'll likely follow a sales-pitch for draft-green. I'd also like to ask the WG if we think it'd be useful to document the arguments against that and other "let's break-tls" proposals we've seen in the past in an RFC. If people think it would be useful, I'd be willing to do work to edit such a draft, or help edit that. Thanks, S. [1] https://github.com/sftcd/tinfoil --QIISL6X94OBDRjo5mS4gxSrBUW9uWV37p-- --soBSJclCM0SXaNV8RLfJPAxdIuKULAIso Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZ2DGAAoJEC88hzaAX42i+cwH/igl1yJCOzlxwn8uEPBwnOMh KrDkwpjNOoO2owpva2aMF5gjNC1lZZ8Eqfyxo5Api7Sy7Hiu8531h9P1dYHwsNWC 1KnT1LA3bQSdnHdqNqbeibRbK25fA6r+J17Zqbftx/OHZZ5+vbxDvW9D+RqMFlNq iciNKGGxe6o/tTthtVuZMxSs/6h9PFwIetufaZLKr/9Ls9+xOk5xw5zm+7xKchfe 8A+lDB1fGXv7sBkMxmDjsPucCA+dHLd3tSS3UnghSgAk9JjvyS+7P35K4gOBMJWa aPuCZEk2sQ9ggWncQTwWqrnq3GI9kCAm26kDWjr5ior3zlIpPE7hYRtWKdME1WI= =Kzn5 -----END PGP SIGNATURE----- --soBSJclCM0SXaNV8RLfJPAxdIuKULAIso-- From nobody Thu Jul 13 08:09:06 2017 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 24F8512741D for ; Thu, 13 Jul 2017 08:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BmECLx08Ax80 for ; Thu, 13 Jul 2017 08:09:02 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 7685812ECB0 for ; Thu, 13 Jul 2017 08:09:02 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id c73so30896378pfk.2 for ; Thu, 13 Jul 2017 08:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J5qsgwhy8/OctqKRV9xyiO7255aN5HHgNLCqvKv+Abg=; b=rkfstBhtobcNMxexi99emj8hp7WTkKAl5IsFIFCwwyeIXunNtJ9ECnbRAYuiPozUWT AfqHRkhfwYjOTV6Jg8I5tfRjinZSKYd9HGYYEmIX9oA15e6+C13Gip7TdkmrKlCdB3Th hpksHPJdXInw66DR4jKHVfrsDC59unNrvJKhZkEibBH75ucMVGDWOIMGWUrACplM9AqW DfAmELeEpRQfaG5ETZKGIVj95zUT1atS+Sf8JEm5zdtgGsDOSaMYctwQZUhIkEb7/jA+ 5O+tbje971lBaixVWyxAZS2Ow095anUV8tkdxngUkZNDidfckwoCl/fjKBbUlO72qNJk Yc+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J5qsgwhy8/OctqKRV9xyiO7255aN5HHgNLCqvKv+Abg=; b=G1aeJxysUbQknT1pALprGRJne3PC9Rv2jUhYXAwav2/Gjtspb/Kx+0In8OOgnKEc0+ osmBB9OOweNGKayQU561TeOIvd17VaFmA/svTjl6BOAhjHG8RPg01V5svwga/ogbWzIG HCKyGIcjLB6+iy4O5adf9xcMkTGSoThyDnXcmmbGbYN/LiB4twQG14F70GyIQAf/AifK Ezb4rO/0bCufquEBQhFRwIBzMnWCe6YIiQ3sV3U79yXUSMUSCiRhuSQxosQd8yB/BHCr kPmz1Pxh1+Q4sHclMzTOI4IvEvx5w8vdUZPjWAEEwHAPPI1YO32VqeSZBCoaOdsPO3cd opGw== X-Gm-Message-State: AIVw112bVFb2cHKi8CiQEKBpzIaWJaSqVRMlBY0L5bkJk2opOy1Dq4W1 VLGHzrsiQaX4dkPJJnQvjA68ktImdg== X-Received: by 10.98.7.204 with SMTP id 73mr92684pfh.110.1499958541937; Thu, 13 Jul 2017 08:09:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.193 with HTTP; Thu, 13 Jul 2017 08:08:21 -0700 (PDT) In-Reply-To: References: <2F25802B-195C-47A9-8270-5EF487A1F925@gmail.com> From: Kathleen Moriarty Date: Thu, 13 Jul 2017 11:08:21 -0400 Message-ID: To: Martin Thomson Cc: Steve Fenter , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 15:09:04 -0000 Hi Steve, Thanks for taking the time to detail out your concerns and current use cases. This is helpful. On Tue, Jul 11, 2017 at 9:39 PM, Martin Thomson wrote: > On 12 July 2017 at 09:59, Steve Fenter wrote: >>> And if you had one an estimate for how much malware does it's own >>> obfuscation or home-grown crypto in addition or instead of using TLS. >>> The reason to ask is that as soon as malware does that then you >>> are back to analysis based on ciphertext only. From descriptions >>> of advanced attack schemes, they do seem to do both when calling >>> home or exfiltrating data. In which case I think your argument >>> falls. >> >> I don't have any numbers for home-grown crypto. I would think the odds are better for the enterprise if they can decrypt and inspect whatever portion is TLS. > > Wouldn't malware avoid connecting to servers that offer the wrong > credentials? Implementing elementary key pinning or overriding trust > anchors is pretty trivial - it's a feature that enterprises frequently > rely on after all. It sounds like for malware, we could do something to better document your security options as well as monitoring. While the documentation is there for key pinning and trust anchors, this might not be obvious to network managers - what RFC to look at and how they fit together. The points Stephen, Ted, Martin have made are good. A TLS overview document with an appendix of use cases might be a good start to help fill this gap for operators. Even if it isn't published, we could figure out wiki space or something like wikipedia to make sure it's available to operators. If the start of this documentation looks like it will generate new work developing alternate ways to accomplish the goals while maintaining the integrity of TLS, a new WG could even be an option. For malware, the proposed solution (Matt Green draft) isn't a great fit as the server side won't be managed within your enterprise to allow for the decryption described in the proposal. For the other parts of your original message that were snipped from this thread, I have a few questions/comments to see how we might be able to narrow the scope and clarify a few things. For the Troubleshooting description, could redefining the end point of the server work as terminating at a load balancer to help with at least some of your use cases? For the threat detection and security analytics, I know a number of current products rely on the ability to TLS. The primary concern here would be the remote server not managed by the enterprise. TLS 1.3 prevents this from being possible and the proposed draft doesn't help, so I think it would be best to figure out a way forward for this use case either with the help of MILE (incident responders) or others. Currently products use proprietary methods to accomplish this task (at least some do). For DDoS, the experts say they can work with fingerprints of encrypted streams, so it's other attack types that may require some thinking through of options. I'm happy to chat about that as I've done a lot of work in incident response and know of others that may be able to assist as well. I'm still reading through messages and drafts on this topic, so this message should not be read as a position on either side, but more to narrow the scope if possible and think through what is being requested and why - so it is clarified. Thanks. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Best regards, Kathleen From nobody Thu Jul 13 08:52:46 2017 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 4536E12EE8D for ; Thu, 13 Jul 2017 08:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 yHKGK61x8pYB for ; Thu, 13 Jul 2017 08:52:41 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8CF129B53 for ; Thu, 13 Jul 2017 08:52:40 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6DFqWsb003440; Thu, 13 Jul 2017 11:52:35 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Stephen Farrell , tls chair CC: "tls@ietf.org" Thread-Topic: [TLS] possible new work item: not breaking TLS Thread-Index: AQHS+8+nbhJkbtO5NkyhZG32p2qUhqJR6HKA Date: Thu, 13 Jul 2017 15:52:31 +0000 Message-ID: <253E111A-5B80-4477-B1EF-E0785EA202AD@ll.mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.23.0.170610 x-originating-ip: [172.25.177.195] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3582791551_695363862" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707130247 Archived-At: Subject: Re: [TLS] possible new work item: not breaking TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 15:52:44 -0000 --B_3582791551_695363862 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I support allocating a time slot for the arguments against the draft-green (and similar/related approaches). I also support documenting the above arguments, possibly in a TLS WG draft. -- Regards, Uri Blumenthal On 7/13/17, 08:00, "TLS on behalf of Stephen Farrell" wrote: Hi again TLS WG chairs, I've done a bit more work on the collection of arguments against the latest break-TLS proposal. [1] I plan to keep working on that so more input is welcome. (Corrections where I've gotten stuff wrong are even more welcome.) I'd like to again request some time on the agenda to allow discussion of those points in a more structured manner than will be possible during the mic-line scrum that'll likely follow a sales-pitch for draft-green. I'd also like to ask the WG if we think it'd be useful to document the arguments against that and other "let's break-tls" proposals we've seen in the past in an RFC. If people think it would be useful, I'd be willing to do work to edit such a draft, or help edit that. Thanks, S. [1] https://github.com/sftcd/tinfoil --B_3582791551_695363862 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg6XJQmdN57DMn9Rqy 37/Ew6D7/aTvwurnSu6LFRtiCz4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcwNzEzMTU1MjMxWjANBgkqhkiG9w0BAQEFAASCAQBr8m94smuPnT981GBU m7RBb3OsEGxFU9LSuFuJx6JJglA37XGi8zJH7LaP12UC+hetF8zaTtWJgo8W8Sq1cUvXM66y FXYOs7e937KByxTGRghCDkcbqraq8wnxRJE/swGd8jxK4KwdYUWHKXgh6Vd611LjrG8qXcAG 6dz9EVDXUDgb1hyyuO8c6cOl/nVa32S2gsoGPrq5IAdPYBOUkstQ/aAXY4JCejAyi4duR9sA dV57ckqHsD/p/1bJWgXQVXh1CcOmhMBtnqN4PC3MEDL2uX0Wmnor/7A3wi+ob+f1/7Vrrl8l 8pxYLlXLYSb2MGdYaBx7vPQVoJFopMGhxc6t --B_3582791551_695363862-- From nobody Thu Jul 13 12:21:28 2017 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 4049A13174B for ; Thu, 13 Jul 2017 12:21: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 KMX_7LJn5zCY for ; Thu, 13 Jul 2017 12:21:25 -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 9063612969E for ; Thu, 13 Jul 2017 12:21:25 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id v17so53081417qka.3 for ; Thu, 13 Jul 2017 12:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=BqkjUCyzXAbwBUbljdXNc3MmtGhEyOyumzWh0vhe8wo=; b=nYVfYRJntDCCwC3PZDly/ZA5cABnVsaZaeAzpod/LobPRs4GLkFyhvKQF67dnKlHmy qbVyncvkLp1T2Io6C3mKfOehNK/pP0USxezGLq5lBb7LbbandhvVF9anHtCbj1bhT7gD kA6ouaoq8bxaJWOPs1dZHQF/KCO2WNjyAFsgI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=BqkjUCyzXAbwBUbljdXNc3MmtGhEyOyumzWh0vhe8wo=; b=mlMRv2Q4H5mFlvoV406Zj95iFRabZ9LHOmFAUuM8RjPsRxkF1LegBql6T73erXwaZH 2hmcbc3cAveKHvw+T4tmvSPngVk4nco/YqqYZOlSIZhGtDYV6RhDBWhyIdqWa/STIPEA Vt2xQGt9cP76BSFH9AK0MjCbSo9XnRddeJ0ojGN0ayDzQojCPDlfh1fsKBNhsDF5hhvU E4jSKPEgmaruazC7JgxshHlpHHjOP9goubIORPDZGMdBP01gDYu3+JER5Zzi9zvzgUhY xtkrUj7ipPnPNp1zrlrnoLIo+Or3Y4dSIij652BCpTswhq5+6zzkwDZfq9FCDcDoP/cJ 2AZw== X-Gm-Message-State: AIVw110pQBwLV4Yzo0C5C+YjnpABo/4ptX/hfuHo6dKqyDhDsx5RDwU9 ANpgiOFyaujNy+Xs7mdFzg== X-Received: by 10.55.191.7 with SMTP id p7mr1881177qkf.223.1499973684564; Thu, 13 Jul 2017 12:21:24 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.165]) by smtp.gmail.com with ESMTPSA id z5sm4592429qkz.53.2017.07.13.12.21.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 12:21:23 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 13 Jul 2017 15:21:22 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] GH repo location for draft-ietf-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 19:21:27 -0000 Nick reminded me to create a repo for = draft-ietf-tls-exported-authenticator. It can be found here: https://github.com/tlswg/tls-exported-authenticator Nick=E2=80=99s going to copy the draft from his private repo to this one = soon. spt= From nobody Thu Jul 13 13:01:10 2017 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 2E0AE1316A9 for ; Thu, 13 Jul 2017 13:01:09 -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=pahtak-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 BnXzmJf3FJyS for ; Thu, 13 Jul 2017 13:01:07 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 A30D013176A for ; Thu, 13 Jul 2017 13:01:07 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id v202so3296867itb.0 for ; Thu, 13 Jul 2017 13:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pahtak-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=aQOdrWglViUUonujMmCKURa1TMzNpnMqgPEtjLfAN3E=; b=GOJEJBPRHkOUFmLo89dvUEWvGyVzPN6kFtjFssCK+MYSbA3v2cE6D59LB7UNOyoei6 j5CiPl298w6nEEmq96kI9vQNAtxgFDYc1bhcKa7jLY9NIf7Wu7uMdG6nWLsZeia3HBw0 /YOqH4QOI+PXHkWoFjAQ8G5KmZu0k7HXKdilDs0D7ogXBGD9bywmTs++/2wDN3ikdgHi IRFFkmbQJOw0cSvDV67kI5NEQTQ534n8VXzvDZxLJw2piCeV6FHnaES/fNMfkm+y/hnP EjkRK5QB3bUVV4mVasOMbJRkAhi7lDV53fdw360CxWS2sPliXbRyBlkodOf8Rl9NSGuF yWzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=aQOdrWglViUUonujMmCKURa1TMzNpnMqgPEtjLfAN3E=; b=PmMaeMGl5Vsmct3NFavGvvAPPMv0nbyPf3wHToGK4hcJo9OiM7gYt1XcPP8IswsS9g UbOx2LE//Rs1yC23nBvt/yp80F5dEJau8d6Gewx8Us5iGHLF7TWwyQY8oTGyrleLIocT AEK1r7eadlEcTptCwbmFa//mXSjWtAS5oWa5GKfLL87mSLiekHoFgFXsrGk3kQx+dHB1 t1w7XAeJxmY0F8azKkyp82R40B0T0cjb+99QQIbwuClCIQyaA44Ndkilgmu88TGdA/Tt Ya2/GVtZNoi9BtCdIhAuvH/WbM19HVnfq5jkWFaqGag2OucBNp3cetKmwnOMEMtJ04Zr YsLg== X-Gm-Message-State: AIVw113EmvNnN05KbflSPva/fhFgFBN5XmUJ9ixFyyqG/6FtML4u4knt zaJ6hzK2eY3hfS6M7mMGNQ== X-Received: by 10.107.44.2 with SMTP id s2mr6095635ios.187.1499976066525; Thu, 13 Jul 2017 13:01:06 -0700 (PDT) Received: from zbox.pahtak.org ([2601:241:8b00:fe1f:201:2eff:febc:8976]) by smtp.gmail.com with ESMTPSA id z13sm144937ita.22.2017.07.13.13.01.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 13:01:05 -0700 (PDT) Received: from hackintosh.hsd1.il.comcast.net (router [192.168.1.1]) by zbox.pahtak.org (Postfix) with ESMTPSA id 26FB5AC2C5D for ; Thu, 13 Jul 2017 15:01:05 -0500 (CDT) From: Stephen Checkoway Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Jul 2017 15:01:04 -0500 References: To: "TLS@ietf.org (tls@ietf.org)" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 20:01:09 -0000 I don't think the WG should adopt this. There are essentially two separate proposals in the I-D. Section 5 = proposes a slight change to TLS that results in no changes on the wire = and, as far as I can tell, is already allowed (but should probably be = discouraged) in the TLS 1.3 I-D. Thus, there's nothing for the WG to do. Sections 6 and 7 propose a new protocol for distributing key pairs. The = use case is TLS, but it isn't specific to TLS and doesn't interact with = TLS (outside of using TLS for HTTPS). As such, I believe it's outside = the WG's charter. --=20 Stephen Checkoway From nobody Thu Jul 13 13:27:28 2017 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 A2888129562 for ; Thu, 13 Jul 2017 13:27:27 -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 XvlMShKfs02u for ; Thu, 13 Jul 2017 13:27:26 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874AC12009C for ; Thu, 13 Jul 2017 13:27:26 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 0CE54C086D10; Thu, 13 Jul 2017 13:27:26 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id AAEFAC086D0A; Thu, 13 Jul 2017 13:27:25 -0700 (PDT) Date: Thu, 13 Jul 2017 15:27:22 -0500 From: Nico Williams To: Stephen Checkoway Cc: "TLS@ietf.org (tls@ietf.org)" Message-ID: <20170713202721.GA2926@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 20:27:28 -0000 On Thu, Jul 13, 2017 at 03:01:04PM -0500, Stephen Checkoway wrote: > I don't think the WG should adopt this. +1 > There are essentially two separate proposals in the I-D. Section 5 > proposes a slight change to TLS that results in no changes on the wire > and, as far as I can tell, is already allowed (but should probably be > discouraged) in the TLS 1.3 I-D. Thus, there's nothing for the WG to > do. > > Sections 6 and 7 propose a new protocol for distributing key pairs. > The use case is TLS, but it isn't specific to TLS and doesn't interact > with TLS (outside of using TLS for HTTPS). As such, I believe it's > outside the WG's charter. Agreed. Authors should make an ISE submission aiming for Informational, or just let the I-D expire and never bring it up again -- that would work just as well for me. The IESG could always direct the ISE to not publish. Given the lack of normative language in the proposed I-D, Informational is the only track that makes sense. What's to be gained by anyone in having this be a WG item anyways? A patina of legitimacy is the only thing I can think of. What's to be gained by anyone in having this be an RFC? A patina of legitimacy with which to flog it at implementors is the only thing I can think of. Legislatures elsewhere can always just legislate this sort of thing (think CALEA). But there's no reason the IETF should preemptively help such things along. I wouldn't be too annoyed if this gets published as an RFC because it's all obvious and could always get published elsewhere anyways. Refusing to publish here won't keep this sort of thing from getting specified and implemented. But there is no need for the IETF's help in the matter. Nico -- From nobody Thu Jul 13 13:36:47 2017 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 60AD113174E for ; Thu, 13 Jul 2017 13:36:41 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 suIu5vJiRxtI for ; Thu, 13 Jul 2017 13:36:40 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E0B3212EC44 for ; Thu, 13 Jul 2017 13:36:39 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6DKWHQS009445; Thu, 13 Jul 2017 21:36:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=teIR0dLgzubUBswg/KYRLTJ/tDmTKQNinKtH/Xs65tA=; b=nuzg/SYno3QiPg9diEKSkTN9K6okXxlgw5aU9YgxtfVbhdiXKm28J9geOcUw0/vpscPd qTe9Yg1oggd4I5qkm+hQsOKzMYcV8vWimHnZ2Q2lG6RHoJd8uLOukl17yHAMZnRdmjsF WRFVCahFv4h3YyOCpFYLwuvbU3Zc2T6I3jvVRUDddxsMdYZRthTMehkcgKha+mcMiMkx kPZiCve2kLxkkh9DNeoeInHVQTXFCsfhEkWNBls445acp887GToNAaHumHxlIBBCKkjM wr8lDTKe86Z51HhXyhleI4WiO8kCJ8r/Y2Qrqnnolu+waXO6l4xo8IdPIjOldLfX052l tQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2bn0pw33t6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Jul 2017 21:36:36 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6DKa3xR022771; Thu, 13 Jul 2017 16:36:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bn0p1xya1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 13 Jul 2017 16:36:35 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 13 Jul 2017 16:36:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 13 Jul 2017 16:36:35 -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.1263.000; Thu, 13 Jul 2017 16:36:35 -0400 From: "Salz, Rich" To: Nico Williams , Stephen Checkoway CC: "TLS@ietf.org (tls@ietf.org)" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJSerMAgAAHWQD//78xgA== Date: Thu, 13 Jul 2017 20:36:34 +0000 Message-ID: <3a42af1eab7d457f8a1112de35b800c8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170713202721.GA2926@localhost> In-Reply-To: <20170713202721.GA2926@localhost> 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.152.112] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-13_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707130318 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-13_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707130317 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2017 20:36:41 -0000 > What's to be gained by anyone in having this be an RFC? A patina of > legitimacy with which to flog it at implementors is the only thing I can = think > of. Folks who were at the last IETF might want to think of Prof Clark's talk ab= out tilting the playing field; https://www.ietf.org/proceedings/98/slides/s= lides-98-ietf-sessc-david-clark-human-rights-in-the-balance-00.pdf From nobody Thu Jul 13 23:02:26 2017 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 95FF612EC02 for ; Thu, 13 Jul 2017 23:02: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, 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 Q_f3W16BIWS3 for ; Thu, 13 Jul 2017 23:02:22 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 BDD8212EB69 for ; Thu, 13 Jul 2017 23:02:22 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id v202so12718247itb.0 for ; Thu, 13 Jul 2017 23:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Ac7/Aqszsm09jZ69KT7D04t52UiYHsYu5g2TjlcdO5E=; b=seXgLTwrReWJb0LYe6BPC9nv0zB892J6rwOERhnh5m1nROOH3tA1imU/rwyobTb6b1 CTVhT/9EG5AXO9sLJ8GC70C5MCq5IL0IUvp0xcHA66U7FzRsCwNFDhLXnuXDOWP7m25V 0zudl6N7ZcKWWQf2bhr0l2dQjEQNgdz+jyeKK1Ni07NtTeavR8f0IOZSoA3YmGlZUahq 74WzcFtiGNYh4YSTtMIrgSaITECPpQ6690utx9Dgms/WBY3iAC6esWLpSc5arJsxNt2M bsM8OeAc17cVW1siAs9XBYszfEIMW0ymZjdWwI6y3oY1LFAIoHPv2I2B4PVs5VSSLp+z fPMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Ac7/Aqszsm09jZ69KT7D04t52UiYHsYu5g2TjlcdO5E=; b=AueoOBv8O39QQ5PRJEgf1rnPM1KDGY/NVomsRATBACxnp8z//sekU0G4AJJwCItiDN CgOCL1Vo4YmraA4EoHt3zTiCQdZ3kEFMlRZ2SkZxDuhdS634tsx2f8gImA/wNFPbIy/Z 888IFnki0jjMfIF3GFtYxLaDCmFh09b/yIAw/kS8eiZaUJTGqhTvSrpKbWiqOmM9TUbb FnOoNLJNf3izd0F5qQ3k22yXw8Z7eEaSz4tALFPuHuAHfasOD/2eHbtObNtL8ngNYxeU pw+jbdJPnopywsC/GCmJ4MmmXAUYleL28bKHOg9WfSAGtM1fuYv+xLrDWO8rBgURrO7L 6+ow== X-Gm-Message-State: AIVw110ZjFmnLY9YMM4GqGIy0GXeY07WVc6VCiSIq2zevT8ZXP7ROxIr xLD3UIuGbAymi466sFN6azPkdjLWNQ== X-Received: by 10.107.39.205 with SMTP id n196mr6634172ion.37.1500012141906; Thu, 13 Jul 2017 23:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Thu, 13 Jul 2017 23:02:21 -0700 (PDT) From: Martin Thomson Date: Fri, 14 Jul 2017 16:02:21 +1000 Message-ID: To: Kathleen Moriarty Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 06:02:25 -0000 On 14 July 2017 at 01:08, Kathleen Moriarty wrote: > It sounds like for malware, we could do something to better document > your security options as well as monitoring. While the documentation > is there for key pinning and trust anchors, this might not be obvious > to network managers - what RFC to look at and how they fit together. Just an aside, though I think Kathleen already made this point: If I were writing malware, I would use TLS. It's pretty good at what it does and it's hard to distinguish from legitimate uses (there are some trick's suggested by McGrew's research on this point). At the point that I have sufficient control over a host that I can run my software, then I would pin certificates and the best you could do is block me. None of the advice about configuration of trust anchors (pinning, overrides, etc...) helps at that point. Most discussions regarding breaking TLS focus on the breaking of TLS to *prevent* malware from infesting machines. There at least the defender has a reason to attack end-to-end security. But then we're talking about a very different deployment model than the gazillion emails recently have contemplated. From nobody Thu Jul 13 23:24:57 2017 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 BA17C12EC02 for ; Thu, 13 Jul 2017 23:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 vB0T99QJkP5H for ; Thu, 13 Jul 2017 23:24:53 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF73128B93 for ; Thu, 13 Jul 2017 23:24:53 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6E6OpNP039672; Fri, 14 Jul 2017 02:24:51 -0400 From: "Blumenthal, Uri - 0553 - MITLL" Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_DFBDFE62-6BAC-4867-9154-3EDEE481B713" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Jul 2017 02:24:51 -0400 In-Reply-To: CC: Kathleen Moriarty , "tls@ietf.org" To: Martin Thomson References: X-Mailer: Apple Mail (2.3273) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-13_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707140104 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 06:24:56 -0000 --Apple-Mail=_DFBDFE62-6BAC-4867-9154-3EDEE481B713 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" TLS is a tool. Good guys want to use it to defend against the bad guys. = Bad guys may want to use it against the good guys. (No surprise here, = right?) You cannot =E2=80=9Csabotage=E2=80=9D the second use case without = sabotaging the first one at the same time.=20 Two decades ago Jeff Schiller said something that remains perfectly = valid today: (paraphrasing) =E2=80=9CThe price of having a secure = infrastructure is our adversaries having a secure infrastructure=E2=80=9D.= Understandably, you don=E2=80=99t want bad guys to use TLS =E2=80=9Cshield= " against your =E2=80=9Cweapons=E2=80=9D. Breaking this =E2=80=9Cshield=E2= =80=9D would accomplish this goal - but at a cost I (for one) don=E2=80=99= t want to pay. =E2=80=94 Regards, Uri > On Jul 14, 2017, at 02:02, Martin Thomson = wrote: >=20 > On 14 July 2017 at 01:08, Kathleen Moriarty > wrote: >> It sounds like for malware, we could do something to better document >> your security options as well as monitoring. While the documentation >> is there for key pinning and trust anchors, this might not be obvious >> to network managers - what RFC to look at and how they fit together. >=20 > Just an aside, though I think Kathleen already made this point: If I > were writing malware, I would use TLS. It's pretty good at what it > does and it's hard to distinguish from legitimate uses (there are some > trick's suggested by McGrew's research on this point). >=20 > At the point that I have sufficient control over a host that I can run > my software, then I would pin certificates and the best you could do > is block me. None of the advice about configuration of trust anchors > (pinning, overrides, etc...) helps at that point. >=20 > Most discussions regarding breaking TLS focus on the breaking of TLS > to *prevent* malware from infesting machines. There at least the > defender has a reason to attack end-to-end security. But then we're > talking about a very different deployment model than the gazillion > emails recently have contemplated. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_DFBDFE62-6BAC-4867-9154-3EDEE481B713 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
TLS is a tool. Good guys want to use it to = defend against the bad guys. Bad guys may want to use it against the = good guys. (No surprise here, right?)

You cannot =E2=80=9Csabotage=E2=80=9D = the second use case without sabotaging the first one at the same = time. 

Two = decades ago Jeff Schiller said something that remains perfectly valid = today: (paraphrasing) =E2=80=9CThe price of having a secure = infrastructure is our adversaries having a secure = infrastructure=E2=80=9D.

Understandably, you don=E2=80=99t want bad guys to use TLS = =E2=80=9Cshield" against your =E2=80=9Cweapons=E2=80=9D. Breaking this = =E2=80=9Cshield=E2=80=9D would accomplish this goal - but at a cost I = (for one) don=E2=80=99t want to pay.
=
=E2=80=94=
Regards,
Uri

On Jul 14, 2017, at 02:02, Martin Thomson <martin.thomson@gmail.com> wrote:

On = 14 July 2017 at 01:08, Kathleen Moriarty
<kathleen.moriarty.ietf@gmail.com> wrote:
It sounds like for = malware, we could do something to better document
your = security options as well as monitoring.  While the documentation
is there for key pinning and trust anchors, this might not be = obvious
to network managers - what RFC to look at and how = they fit together.

Just an = aside, though I think Kathleen already made this point:  If I
were writing malware, I would use TLS.  It's pretty good = at what it
does and it's hard to distinguish from = legitimate uses (there are some
trick's suggested by = McGrew's research on this point).

At the = point that I have sufficient control over a host that I can run
my software, then I would pin certificates and the best you = could do
is block me.  None of the advice about = configuration of trust anchors
(pinning, overrides, = etc...) helps at that point.

Most = discussions regarding breaking TLS focus on the breaking of TLS
to *prevent* malware from infesting machines.  There at = least the
defender has a reason to attack end-to-end = security.  But then we're
talking about a very = different deployment model than the gazillion
emails = recently have contemplated.

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

= --Apple-Mail=_DFBDFE62-6BAC-4867-9154-3EDEE481B713-- From nobody Fri Jul 14 03:17:58 2017 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 79A691316F4 for ; Fri, 14 Jul 2017 03:17:57 -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 hZOltSSlVm9g for ; Fri, 14 Jul 2017 03:17:56 -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 C530912EC3B for ; Fri, 14 Jul 2017 03:17:55 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id w126so16349564wme.0 for ; Fri, 14 Jul 2017 03:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E9tBcLitE9Evx0DmtgnCpkR9p9DOsAQld8H1C+/CkBY=; b=P6Pk+RsWtTI/Zrp93y71B8NHXSX0w7o7Ug9Y2rrA+dno1WRAZcxOPkGPjlVSw5JUeT +ZSfnAyaryXRCuLwKkOKc9tL1yq2F1Y+C6HRVE6xhpjdA8lMqoFFcCmaZZR5b6FdpkVT TmGi2DCmhWJeXpH/7g6tb176A66NyWMN1EwQYDrPw0caq9mRo6NX1h0loCCu4brGhs/w jA7TqQsNdF5UNmNh9ThMDK6wY2s623FzP0+OHtEtup3HwdDUeY0HdePTSRNtegr8Qyr7 aohAUvwb7mdrrVl7/pTnkVYU4trgVjIoQfq6G6Yec2Bm3tPj1IddWmM2i1PZhZUoYWUE vGsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E9tBcLitE9Evx0DmtgnCpkR9p9DOsAQld8H1C+/CkBY=; b=YXBwAOnW2rZCzArQ1bQqtFQruOryyBNu3S94Be76eqh/a/XlRdQFI9oBbYMCqaXUVJ 1MO2EGo77foxJWymia/0+XlNeJNmBbTNP+VBJO8R+aeSQclsAeRU9HtVZgJWsy9//eG3 IezG6b8P02vsZ44uBRv1sRqyiwhvqEe/zsHj2BfMkXkzBzzVb9wIPrZY+LCC0n9W8Gfz YEOxpI8yrtOhijdYJAeR+z8FLLRoagdTlefV3BZjyi0EAxwoTjzkA+nOA7NxpOnOtZxF x0zWUPKnzUMqeFs5/WG3cL8Lb+8GAleGOrGdB6kN0Cpiir+SYvp7c9iC51fHLRYLCNVh MoEw== X-Gm-Message-State: AIVw112+upAfel+w6rPye6yw25lpudaTnRrKXsAJYqX4/5Z5YScJJfEA +JhHU3y4wdwtjw== X-Received: by 10.28.94.13 with SMTP id s13mr2058012wmb.33.1500027474145; Fri, 14 Jul 2017 03:17:54 -0700 (PDT) Received: from [10.0.6.178] ([62.168.35.66]) by smtp.gmail.com with ESMTPSA id t33sm8877122wrc.50.2017.07.14.03.17.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 03:17:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Fri, 14 Jul 2017 12:17:52 +0200 Cc: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <20E2D146-07BC-40DA-9DE2-031503916F52@gmail.com> References: To: Martin Thomson Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 10:17:57 -0000 Sent from my iPhone > On Jul 14, 2017, at 8:02 AM, Martin Thomson wro= te: >=20 > On 14 July 2017 at 01:08, Kathleen Moriarty > wrote: >> It sounds like for malware, we could do something to better document >> your security options as well as monitoring. While the documentation >> is there for key pinning and trust anchors, this might not be obvious >> to network managers - what RFC to look at and how they fit together. >=20 > Just an aside, though I think Kathleen already made this point: If I > were writing malware, I would use TLS. It's pretty good at what it > does and it's hard to distinguish from legitimate uses (there are some > trick's suggested by McGrew's research on this point). >=20 > At the point that I have sufficient control over a host that I can run > my software, then I would pin certificates and the best you could do > is block me. None of the advice about configuration of trust anchors > (pinning, overrides, etc...) helps at that point. I do think we could help tie together this advice for the many operators usi= ng TLS so they know and understand options better. Yes, agreed, detection at that point relies on anomalous behavior on the man= aged end point, connection information (unusual destination, size of packets= , timing of streams, etc.), or known indicators of compromise. These all wo= rk with encryption and TLS should not be a hinderance to incident detection a= t that point >=20 > Most discussions regarding breaking TLS focus on the breaking of TLS > to *prevent* malware from infesting machines. There at least the > defender has a reason to attack end-to-end security. But then we're > talking about a very different deployment model than the gazillion > emails recently have contemplated. I think the points on why the solution doesn't help with malware have been c= lear, but just in case, preventing malware from infecting endpoints receivin= g content over HTTP/TLS can also be done using indicators of compromise. Br= eaking TLS only works if the malware has been identified and can be detected= by the analysis box. This does work when it's been deployed to newly infect= ed servers when the malware hasn't been altered enough to avoid detection. T= his is useful to enterprises, but you'd need the server key or more realisti= cally going forward, would need a TLS proxy. Otherwise, with the proposed so= lution, your still relying on indicators of compromise that can be detected u= sing the encrypted traffic. Best regards, Kathleen=20= From nobody Fri Jul 14 07:51:20 2017 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 4309F1318F1 for ; Fri, 14 Jul 2017 07:51:19 -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 uSJoLEUICibN for ; Fri, 14 Jul 2017 07:51:18 -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 CABF61200ED for ; Fri, 14 Jul 2017 07:51:17 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id a66so63377076qkb.0 for ; Fri, 14 Jul 2017 07:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=E9D55kCJcLlVSzX7YesIKM+8mHLni402KElZVK0O8qA=; b=MkgnwLx7awRJLIWFmy4yanH9ifxGBUeK2sY5+bT2NWf2adU2RilvF4qmF5HdD8vDar zRjobCkSnT5dhsGoz7wgwupYqY5+G2S9mY9oUhPKeWQgYDPUN96gyMJI7FdmkhRqn7NH 3u1pT2ODol7Re3JjNwlkNVyestl0NQDct8Aww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=E9D55kCJcLlVSzX7YesIKM+8mHLni402KElZVK0O8qA=; b=Y4s8Na0iynBHlnetXkxUmOXZnViWTpEnpxAxIeuci1NYtS1Di1XlXVotFgmc5em0rr 8yiM2S8XcLSj/TPLwaD2mqMmXDUwABpk9kvRT4Y6bfOpjX6tOSp7CTFqiM81n2AeJFHJ bQnwCyH5e1RnmoTNJB2oIh+A4R/hir+z3rm0zgD2OFK0e4wt3TVqhrUbGBVzCA0QDsq4 V+ulNX61XCRfoZh42XrOAP+AOCAIe+6hyTJ6I4FlNv9nPAiuj+SE9o2E64yZ2pJgw7gD /WwUWioOAxEdKOFWc4Hz39KdbJgrQnM/anS+OkogFTmXdXC9dRtFlwrSWik2xoetdC1r R9Mg== X-Gm-Message-State: AIVw112ZIz7xYVc9HqsVxV8HEUR6djq2qgLz+2RhAjd4jXOt9P5L7oIp mbdHwEk/wDe+MEf9uaegfw== X-Received: by 10.55.185.6 with SMTP id j6mr11212738qkf.14.1500043876401; Fri, 14 Jul 2017 07:51:16 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.165]) by smtp.gmail.com with ESMTPSA id 143sm6282924qkf.8.2017.07.14.07.51.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 07:51:15 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> Date: Fri, 14 Jul 2017 10:51:14 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 14:51:19 -0000 The chairs have requested an additional time on the IETF agenda for TLS. = The Secretariat has allocated us the Monday @ 13:30-15:30 slot. = Because the main point of the TLS WG are the TLS and DTLS drafts and the = schedule was already announced, we want to leave those presentations on = Wednesday. What follows is a revised agenda; note that we=E2=80=99ve = alloced 40 minutes for further about draft-green-tls-static-dh-in-tls13. = Please let us know your thoughts. Monday @ 1330-1530 CET: - Administrivia (5min) - Document Status (5min) - A DANE Record and DNSSEC Authentication Chain Extension for TLS = (20min) = https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ - Record Size Limit Extension for TLS (15min) https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/ - SNI Encryption (25min) https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ Wednesday @ 0930-1200 CET: - Administrivia (5min) - TLS1.3 (20min) https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ - DTLS1.3 (45min) https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ - Data Center use of Static DH (30 min) https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ - National Cybersecurity Center of Excellence (NCCOE) project for visibility within the datacenter with TLS 1.3 (10min) aka implementing draft-green-tls-static-dh-in-tls13 - Discussion about the previous topic (40min) J&S= From nobody Fri Jul 14 08:09:55 2017 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 5FC24131687 for ; Fri, 14 Jul 2017 08:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCmtH71UMS7W for ; Fri, 14 Jul 2017 08:09:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CB6131562 for ; Fri, 14 Jul 2017 08:09:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5C56EBE53; Fri, 14 Jul 2017 16:09:47 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0bf3YJbx3Vs; Fri, 14 Jul 2017 16:09:46 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2D3D0BE2C; Fri, 14 Jul 2017 16:09:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500044986; bh=0f6ch/k0oG/3AOiLhim44kdCq/TLBms2Xidjezi5+Cc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ied3kOdBAHl4f+2wiJQFFD5/UiwbFlUcXFPW4vKg924d9PeIhf98G2Zmbq4UdkXH7 DmWL1NOfD4rGQtYonS0zwZITLecGgYKf0nwS3yY2D7z8jfCi2hDifoVDYRefsrw9Fi bVePBx5mp0za11dzqULfkkKogZsaUPs0CItx9ghU= To: Sean Turner , "" References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 14 Jul 2017 16:09:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2HnuogOBEXEJbsU3PMcsIUn3H2K5FNE8S" Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 15:09:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2HnuogOBEXEJbsU3PMcsIUn3H2K5FNE8S Content-Type: multipart/mixed; boundary="jfh8F7K7OqNfgNUllGWokCCH1ngJeXxGj"; protected-headers="v1" From: Stephen Farrell To: Sean Turner , "" Message-ID: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> In-Reply-To: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> --jfh8F7K7OqNfgNUllGWokCCH1ngJeXxGj Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 14/07/17 15:51, Sean Turner wrote: > Please let us know your thoughts. 80 minutes for wiretapping is too much. Zero would be better. But if not... I'd suggest: 10 minutes for draft-green, 10 minutes to describe issues with that (i.e. the slot for which I continue to ask) and then 10 minutes discussion. If we assume the folks in the room have read the list and the draft that should be plenty. If we assume they haven't read the list, then it's more important that the counter-arguments be given sufficient time. So your draft agenda seems to get that backwards to me, in that it allocates 40 minutes for a sales-pitch and then 40 minutes where we bitch about that at the mic interspersed with proponents repeating bits of the sales pitch. That might be more amusing for us all, but seems like a worse use of time to me. Cheers, S. --jfh8F7K7OqNfgNUllGWokCCH1ngJeXxGj-- --2HnuogOBEXEJbsU3PMcsIUn3H2K5FNE8S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZaN65AAoJEC88hzaAX42iCksIAKxPd90G95TTeHEZszOpoHlh pzDzuT5rvxzay7NLW1s9nC5EHVJBOqzl3NLy1BwDQMjllRkNflT0PQqcnNTN0Ya6 pzNncCNxYtLur10kBxCdm5Ii+UFHvdIR/4L0ZjEWCTmqv/l6XGglA3VVIgWeSIVr NUJJvdm9mvC6Cm/MqBjgR4KItt28szcl3zCOYdzh2YCcxtUusWQaSli1+t55ni+F i9+vhou2ssYZ8Hcvi5SU1JZ4vTnpMW6H6nmTNJwMM3aUbytD5CPFoRLTkejcg/rq ZchURVhi+/1E3s/MXs9OLWs7tW4/BK3dpUrELivB3aSQuG09rtUSLLAdV5ILXqw= =iP45 -----END PGP SIGNATURE----- --2HnuogOBEXEJbsU3PMcsIUn3H2K5FNE8S-- From nobody Fri Jul 14 08:13:12 2017 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 4DA41128B8D for ; Fri, 14 Jul 2017 08:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 EcNBKhT3hxdq for ; Fri, 14 Jul 2017 08:13:09 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0CA131562 for ; Fri, 14 Jul 2017 08:13:08 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6EFD4dm040260; Fri, 14 Jul 2017 11:13:05 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Stephen Farrell , "" Thread-Topic: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! Thread-Index: AQHS/LC5Yd/BsGKLV0aovc3qwkyFuaJTsCCAgAAA7IA= Date: Fri, 14 Jul 2017 15:13:04 +0000 Message-ID: References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-389DECCE-3D69-4BE7-BB37-E40F8BC4966F"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-13_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707140239 Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 15:13:11 -0000 --Apple-Mail-389DECCE-3D69-4BE7-BB37-E40F8BC4966F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 Current agenda does look backwards. IMHO, do as Stephen suggested. Regards, Uri Sent from my iPhone > On Jul 14, 2017, at 11:10, Stephen Farrell wro= te: >=20 >=20 > Hiya, >=20 >> On 14/07/17 15:51, Sean Turner wrote: >> Please let us know your thoughts. >=20 > 80 minutes for wiretapping is too much. Zero would > be better. But if not... >=20 > I'd suggest: 10 minutes for draft-green, 10 minutes > to describe issues with that (i.e. the slot for which > I continue to ask) and then 10 minutes discussion. If > we assume the folks in the room have read the list and > the draft that should be plenty. >=20 > If we assume they haven't read the list, then it's more > important that the counter-arguments be given sufficient > time. >=20 > So your draft agenda seems to get that backwards to me, > in that it allocates 40 minutes for a sales-pitch and > then 40 minutes where we bitch about that at the mic > interspersed with proponents repeating bits of the sales > pitch. That might be more amusing for us all, but seems > like a worse use of time to me. >=20 > Cheers, > S. >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-389DECCE-3D69-4BE7-BB37-E40F8BC4966F Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4 MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd 8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg 1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4 HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK +4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8 F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01 Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+ BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s 6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p 6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2 oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1 RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G /HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9 Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE0MTUxMzAzWjAjBgkqhkiG9w0BCQQxFgQUM2KqPz0anqU7 zDUw98/5H9t+ZZ0wbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAG9zF9pOlMlfFg90PYtg7r8KqSOnn3LBd6zgZf2i tEXJs2+wYERhK80+xz/Hj2hBnNdCzUrhsmT+a+dcPxXbeJF+BwEAFiBtpLIw2LyCO/ifrDKXps5y etCZvGV+rBnBE00FMR3QpeQWIyFc/NBw4iB5IjlrG75ddba3kD4FOqMvMXRSkfHubmY3khiUTCYj drQLEjfhttY2bKMRKDE/iAUbe8YS+RugYnSKIuRe/5G1dKaX3Wdh3BhWM6/eqLIgT7zug5N9Er81 5ccwsoXOzUK97tXD5X1h1aAzOeZiUFuq9QZk2ygoi1CFkgIsdgwstzItrK7gpq0TT5BAQ9/hbkUA AAAAAAA= --Apple-Mail-389DECCE-3D69-4BE7-BB37-E40F8BC4966F-- From nobody Fri Jul 14 08:35:41 2017 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 697B9131B34 for ; Fri, 14 Jul 2017 08:35:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 Yu2bbn-jcbIY for ; Fri, 14 Jul 2017 08:35:38 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 3D301131A92 for ; Fri, 14 Jul 2017 08:35:38 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id g13so35300959uaj.0 for ; Fri, 14 Jul 2017 08:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ap2ccjm1ouJUuSNPEBHLr7/rwJNhhdr73d3UxnzNi4E=; b=egF8lHkY6eMTfOrIphDd7bncdKnbevytF0CMydddPHZpgnPI5NbwM1MjllamI/D03T fVxECfqoFo2ZNol3kbUNqiygpxM06JkOduGxWJ9lsEqJfFVchTXw/gtqJFWj8WdWYzJw h0qm7JOI+gLDipdcXNqGMVhF9ZiSXNmEF33qg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ap2ccjm1ouJUuSNPEBHLr7/rwJNhhdr73d3UxnzNi4E=; b=CmOMzGiO29c/05I7LJWTT7AWZ2LDXRy6LZggv1EwErlBGgDxypNMAmgUihYiH3XOaO Vl46OY8xgq0mu2SMo8hZ0bI/PaTcwAe22aUkX2BQQbSJHKAA9z96Tcp8o10NYZF5Pk8X AQ4SCczQy3DGz3TX839rYOjWywHUOGn302wwyxZpv9fJK8oujelLlc0LrRlEhXnaGnym 6y/xJZadUBeojo3z7WOqFuES04/yuZEA6kjrhbu0XtoW0umjaPXqBvyQXegekx8KDPSa lSMC0uGwujYbAARTWFF/QusKypMu4nL1pAqtBNag3JqWVq2x7UV6rX5wlhX3OFD2BwjR tCmg== X-Gm-Message-State: AIVw111exiCcPcHXjrF9BGhF6vpuUeLbyobM5hhyLiJ7Mfxpa8uACdDF OVHvlg2l+SO04z4q67yRHzT6AE2LGAf6 X-Received: by 10.176.17.26 with SMTP id e26mr5052149uab.94.1500046537128; Fri, 14 Jul 2017 08:35:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joseph Lorenzo Hall Date: Fri, 14 Jul 2017 15:35:26 +0000 Message-ID: To: Matthew Green , Nick Sullivan , tls@ietf.org Content-Type: multipart/alternative; boundary="f403045e3e36fe3d1e055448cce1" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 15:35:40 -0000 --f403045e3e36fe3d1e055448cce1 Content-Type: text/plain; charset="UTF-8" Just want to +1 the notion that this should be opt-in for both sides and in an extension! On Sat, Jul 8, 2017 at 23:16 Nick Sullivan wrote: > Putting questions of whether or not this belongs as a working group > document, I think there are some necessary requirements for > intra-datacenter passive decryption schemes that are not met by this draft. > > Specifically, any passive decryption scheme should the following two > properties: > 1) Both server and client must explicitly opt-in > 2) A third party should be able to tell whether or not this feature is > enabled by observing the stream > > These two requirements protect services on the wider Internet from being > accidentally (or surreptitiously forced to be) subject to unauthorized > decryption. The static DH proposal satisfies neither of the above > requirements. > > What you likely want is something similar to TLS 1.2 session tickets with > centrally managed session ticket keys. The client would advertise support > for "passive session decryption" in an extension and the server would > return an unencrypted extension containing the session keys encrypted by a > server "passive decryption key". The passive decryption key would be > managed in the same way as the static DH key in this draft: rotated > frequently and synchronized centrally. > > A TLS 1.2 session ticket-like scheme provides the same semantics as this > static DH but provides more safeguards against accidental use outside the > datacenter. Both client and server need to opt in, it's visible from the > network, and limits the data visible to the inspection service to the > session (rather than exposing the master secret which can be used to > compute exporters and other things outside of the scope of session > inspection). Furthermore, in the session ticket-like scheme, a *public > key *could be used to encrypt the session keys, removing the need for a > secure distribution scheme for the endpoints. The passive decryption > private key could me managed in a secure location and only the public key > distributed to the endpoints. > > Session ticket-like scheme advantages vs this static DH proposal: > 1) Mandatory client opt-in > 2) Passive indication that scheme is being used > 3) Decryption service only gets session keys, not master secret > 4) No need for private distribution system for static keys to endpoints > > In summary, even if this was to be considered as a working group document, > I think this is the wrong solution to problem. > > Nick > > On Fri, Jul 7, 2017 at 8:03 AM Matthew Green > wrote: > >> The need for enterprise datacenters to access TLS 1.3 plaintext for >> security and operational requirements has been under discussion since >> shortly before the Seoul IETF meeting. This draft provides current thinking >> about the way to facilitate plain text access based on the use of static >> (EC)DH keys on the servers. These keys have a lifetime; they get replaced >> on a regular schedule. A key manager in the datacenter generates and >> distributes these keys. The Asymmetric Key Package [RFC5958] format is >> used to transfer and load the keys wherever they are authorized for use. >> >> We have asked for a few minutes to talk about this draft in the TLS WG >> session at the upcoming Prague IETF. Please take a look so we can have a >> productive discussion. Of course, we're eager to start that discussion on >> the mail list in advance of the meeting. >> >> The draft can be found here: >> >> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 >> >> Thanks for your attention, >> Matt, Ralph, Paul, Steve, and Russ >> _______________________________________________ >> 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 > -- 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 --f403045e3e36fe3d1e055448cce1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just want to +1 the notion that this should be opt-in for= both sides and in an extension!

<= div>On Sat, Jul 8, 2017 at 23:16 Nick Sullivan <nicholas.sullivan@gmail.com> wrote:
=
Putting questions of whe= ther or not this belongs as a working group document, I think there are som= e necessary requirements for intra-datacenter passive decryption schemes th= at are not met by this draft.

Specifically, any passive d= ecryption scheme should the following two properties:
1) Both serv= er and client must explicitly opt-in
2) A third party should be ab= le to tell whether or not this feature is enabled by observing the stream
These two requirements protect services on the wider Inter= net from being accidentally (or surreptitiously forced to be) subject to un= authorized decryption. The static DH proposal satisfies neither of the abov= e requirements.

What you li= kely want is something similar to TLS 1.2 session tickets with centrally ma= naged session ticket keys. The client would advertise support for "pas= sive session decryption" in an extension and the server would return a= n unencrypted extension containing the session keys encrypted by a server &= quot;passive decryption key". The passive decryption key would be mana= ged in the same way as the static DH key in this draft: rotated frequently = and synchronized centrally.

A TLS 1.2 session ticket-like scheme pro= vides the same semantics as this static DH but provides more safeguards aga= inst accidental use outside the datacenter. Both client and server need to = opt in, it's visible from the network, and limits the data visible to t= he inspection service to the session (rather than exposing the master secre= t which can be used to compute exporters and other things outside of the sc= ope of session inspection). Furthermore, in the session ticket-like scheme,= a public key could be used to encrypt the session keys, remo= ving the need for a secure distribution scheme for the endpoints. The passi= ve decryption private key could me managed in a secure location and only th= e public key distributed to the endpoints.

Session ticket= -like scheme advantages vs this static DH proposal:
1) Mandat= ory client opt-in
2) Passive indication that scheme is being = used
3) Decryption service only gets session keys, not master= secret
4) No need for private distribution system for static= keys to endpoints

In summary, even if this wa= s to be considered as a working group document, I think this is the wrong s= olution to problem.

=
Nick

On Fri, Jul 7, 2017 at 8:03 AM Matthew Green <matthewdgreen@gmai= l.com> wrote:
The need for enterprise datacenters to access TLS 1.= 3 plaintext for security and operational requirements has been under discus= sion since shortly before the Seoul IETF meeting. This draft provides curre= nt thinking about the way to facilitate plain text access based on the use = of static (EC)DH keys on the servers. These keys have a lifetime; they get = replaced on a regular schedule. A key manager in the datacenter generates a= nd distributes these keys.=C2=A0 The Asymmetric Key Package [RFC5958] forma= t is used to transfer and load the keys wherever they are authorized for us= e.

= We have asked for a few minutes to talk about this draft in the TLS WG sess= ion at the upcoming Prague IETF. Please take a look so we can have a produc= tive discussion.=C2=A0 Of course, we're eager to start that discussion = on the mail list in advance of the meeting.

The draft can be found= here:

https://tools.ietf.org/html/draft-green-tl= s-static-dh-in-tls13-01

Thanks for your attention,
Matt, Ralph, Paul, Steve, and Russ
_______________________________________________
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
--
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
Finger= print: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871
--f403045e3e36fe3d1e055448cce1-- From nobody Fri Jul 14 09:19:16 2017 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 537E712EAF0 for ; Fri, 14 Jul 2017 09:19:14 -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=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 VMHNOs8YUaTC for ; Fri, 14 Jul 2017 09:19:12 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089FA129AB2 for ; Fri, 14 Jul 2017 09:19:12 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id f68so45500119vkg.2 for ; Fri, 14 Jul 2017 09:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M1BJC6yJ6s6WY1ETvDu7D6hcu9bnrpfnUkO+/uG/N/0=; b=c1OmmaYd07K2iBCX9k+GmE3NyIVQu0ryXCP8IKgkANyAJMJynZ0cuDaTKMJNhOlmeS Px9RCG9vRpExLtWSYWyk83JnYZXJab5SJKg3DFxDIDf+c4SjliXDoZn+Y8ahszC+Fq7i 6/L8RPQwdueeMW57KagfG2X3LV+chR2JW9Ttc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M1BJC6yJ6s6WY1ETvDu7D6hcu9bnrpfnUkO+/uG/N/0=; b=WqA72+pGJuxSgScnQH7v+KRaKhrPGx1Gz/hCZpSqf+H195ooTD/dw7RyHtjnZo8G+6 RyxSdSGgMvqTY1wMv8EfigqIgH4t+2B+DotOyCrQTDc1hduwODeRAe+/TYYyixaz/WSE Hzkk8KRiK+vD4+3BirPFGdOeuFLpfs2/CieXMp6CASNtI90FjE7FuDjyXLtL+RE6s0ul DOkuWeUpERnIsGPlLY/I5ZXnOjTCG7EPKuACu7RiUjV31OdWOZgMQoSJ5X1hNEmVZbDK LzaeRkXHxJX7DcLsrIBp0Aho37QZEy5g8dBI5QlC46yoYmE4ANE25ec9Uxf9FT1YyDWZ 7q5A== X-Gm-Message-State: AIVw111EkYbDgk4I6pH5jhULvAvJj15DCZSAxBY77qJ4vF02XypjnmpR VV/100zEExWVRpnrYZNaJ3LhsGuIRVxS X-Received: by 10.31.134.208 with SMTP id i199mr5582767vkd.102.1500049150999; Fri, 14 Jul 2017 09:19:10 -0700 (PDT) MIME-Version: 1.0 References: <253E111A-5B80-4477-B1EF-E0785EA202AD@ll.mit.edu> In-Reply-To: <253E111A-5B80-4477-B1EF-E0785EA202AD@ll.mit.edu> From: Joseph Lorenzo Hall Date: Fri, 14 Jul 2017 16:19:00 +0000 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" , Stephen Farrell , tls chair Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1141262eca953c055449684c" Archived-At: Subject: Re: [TLS] possible new work item: not breaking TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 16:19:14 -0000 --001a1141262eca953c055449684c Content-Type: text/plain; charset="UTF-8" I also support both time here and a "let's put all the bad breaking TLS ideas in one draft". On Thu, Jul 13, 2017 at 17:52 Blumenthal, Uri - 0553 - MITLL wrote: > I support allocating a time slot for the arguments against the draft-green > (and similar/related approaches). > > I also support documenting the above arguments, possibly in a TLS WG draft. > -- > Regards, > Uri Blumenthal > > On 7/13/17, 08:00, "TLS on behalf of Stephen Farrell" < > tls-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote: > > > Hi again TLS WG chairs, > > I've done a bit more work on the collection of arguments > against the latest break-TLS proposal. [1] I plan to keep > working on that so more input is welcome. (Corrections > where I've gotten stuff wrong are even more welcome.) > > I'd like to again request some time on the agenda to > allow discussion of those points in a more structured > manner than will be possible during the mic-line scrum > that'll likely follow a sales-pitch for draft-green. > > I'd also like to ask the WG if we think it'd be useful > to document the arguments against that and other "let's > break-tls" proposals we've seen in the past in an RFC. > If people think it would be useful, I'd be willing to > do work to edit such a draft, or help edit that. > > Thanks, > S. > > [1] https://github.com/sftcd/tinfoil > > > _______________________________________________ > 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 --001a1141262eca953c055449684c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also support both time here and a "let's put a= ll the bad breaking TLS ideas in one draft".

On Thu, Jul 13, 2017 at 17:52 Blumenthal, Uri - 0553 = - MITLL <uri@ll.mit.edu> wrote:=
I support allocating a time slot f= or the arguments against the draft-green (and similar/related approaches).<= br>
I also support documenting the above arguments, possibly in a TLS WG draft.=
--
Regards,
Uri Blumenthal

On 7/13/17, 08:00, "TLS on behalf of Stephen Farrell" <tls-bounces@ietf.org= on behalf of stephen.farrell@cs.tcd.ie> wrote:


=C2=A0 =C2=A0 Hi again TLS WG chairs,

=C2=A0 =C2=A0 I've done a bit more work on the collection of arguments<= br> =C2=A0 =C2=A0 against the latest break-TLS proposal. [1] I plan to keep
=C2=A0 =C2=A0 working on that so more input is welcome. (Corrections
=C2=A0 =C2=A0 where I've gotten stuff wrong are even more welcome.)

=C2=A0 =C2=A0 I'd like to again request some time on the agenda to
=C2=A0 =C2=A0 allow discussion of those points in a more structured
=C2=A0 =C2=A0 manner than will be possible during the mic-line scrum
=C2=A0 =C2=A0 that'll likely follow a sales-pitch for draft-green.

=C2=A0 =C2=A0 I'd also like to ask the WG if we think it'd be usefu= l
=C2=A0 =C2=A0 to document the arguments against that and other "let= 9;s
=C2=A0 =C2=A0 break-tls" proposals we've seen in the past in an RF= C.
=C2=A0 =C2=A0 If people think it would be useful, I'd be willing to
=C2=A0 =C2=A0 do work to edit such a draft, or help edit that.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 S.

=C2=A0 =C2=A0 [1] https://github.com/sftcd/tinfoil


_______________________________________________
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
Finger= print: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871
--001a1141262eca953c055449684c-- From nobody Fri Jul 14 09:45:23 2017 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 2559212702E for ; Fri, 14 Jul 2017 09:45:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 nKQ85PlZ9yEx for ; Fri, 14 Jul 2017 09:45:20 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944E4126C2F for ; Fri, 14 Jul 2017 09:45:20 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id u23so11782296wma.2 for ; Fri, 14 Jul 2017 09:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9BFKZi5NvaeXnCmvhMI5oqQIn3sefMP5rNqEiZo6s8Y=; b=GutrCG7M4TOPVMEJCgIzEnE17e6mqU5YXLmokhELs/XZXhoVajv+SJ/qbWP7HcsRIm hHJt71VoOjSi5goLI0WTPSQtI4+ZffeYiYpfEX0JYuSa4LNvZyXWEpu4ZLv1aF4CR2Yx ERemd+5FbabLMqKILhCO7qkKAmWoelTD3r6GxIYGdUdu4yK0OtkOHoSUw98nW+7JGcwD npHF9n1Offw5uO8ikavyJ2nSDtGVOzKdkc6NzcklFu2+zZAT6w0H/4Z/MwPkLLu17syb 0eYdmU6FrLU3jCRL4ihcqGlQCifbSgMdv1aVfuKreRUHYHNfiIq11Cg3x93WAqiH7eX5 rU9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9BFKZi5NvaeXnCmvhMI5oqQIn3sefMP5rNqEiZo6s8Y=; b=ODVtU6HnRDD5BD4ZibX3ogPHgYQSm8jclDhvjAoKPVik3EyCY1hoWWUTqVHMdh8GfA l3pijm0fx719qWZEWL0d0GynYzqhLG/2EuSoOS0evfZmguInIED0ewXym8dsEQGK14UO YNAnsNphcskijo/E8cDAPVxxPgYl3vIVIr604Duu7/WSEyBU2WeBTSaJxeeUY70ViFjl yzQMJX2CiE3ieQVJS/hIjZt15tvcVaAORsdul9YSCdDsoWAk5GN7zDwN0gx+XvfX9ig0 n10MgR8/BMkhTk6JWTHZmoA29Ltldho2dhdzCDga+hyXonEm+FUk09E5sO+x9EHSW7nz C6BQ== X-Gm-Message-State: AIVw110H3qUSBY2XXYU+3bECH1OgFf6Voqa6EvoI690XihcbDP79Rk6s Xy4L0Xn5E+Dagw== X-Received: by 10.80.241.144 with SMTP id x16mr7543783edl.66.1500050719198; Fri, 14 Jul 2017 09:45:19 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id h18sm4645644eda.46.2017.07.14.09.45.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 09:45:18 -0700 (PDT) From: Yoav Nir Message-Id: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_03F49B74-F3F4-42F8-BCAA-7A4397636E74"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Jul 2017 19:45:15 +0300 In-Reply-To: Cc: Matthew Green , Nick Sullivan , tls@ietf.org To: Joseph Lorenzo Hall References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 16:45:22 -0000 --Apple-Mail=_03F49B74-F3F4-42F8-BCAA-7A4397636E74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Jul 2017, at 18:35, Joseph Lorenzo Hall wrote: >=20 > Just want to +1 the notion that this should be opt-in for both sides = and in an extension! It=E2=80=99s a good notion, but =E2=80=9Cwe have to change one side=E2=80=9D= usually wins over =E2=80=9Cwe have to change both sides=E2=80=9D --Apple-Mail=_03F49B74-F3F4-42F8-BCAA-7A4397636E74 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZaPUcAAoJELhJCxUKWMyZbWQH/3xWKpv28jXXy7Ifr0UqbtXd 9B0ErUva9N/OZPJEfezbuT61LUmWca/DMLKAixvi1/QCvpiAMddgJvPvtohXksX2 x5V3QGhmVuwY3QJ/3YPv24F7uXM4rAWVL+Y8BzMGdfhS2VmnXLu5ukUeemWfJxrd fRMINQqsrrsSSndGMx18VpQzizobK+dGqmFIsLBz3nif86XweN/z5/UbKz82xN0q GW3SPFJknzskXtp3dA5xhzmtrFqUSri6iL1Dz7s0/nM9XwLbZvOSlaZDjw4SPBTq fibxJnjLAf4JtYCsZhTqosGeDtW0bJJvPR9BGYxG/c2F3PeR0hKocprtIczjr0M= =sXA5 -----END PGP SIGNATURE----- --Apple-Mail=_03F49B74-F3F4-42F8-BCAA-7A4397636E74-- From nobody Fri Jul 14 10:11:38 2017 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 58E5F129B53 for ; Fri, 14 Jul 2017 10:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5TfUe11ptmFC for ; Fri, 14 Jul 2017 10:11:28 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 7165B1270A0 for ; Fri, 14 Jul 2017 10:11:28 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id k14so48681406pgr.0 for ; Fri, 14 Jul 2017 10:11:28 -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=W1yvz6PnP++DntTLvfsUX/X5f7LpBYCeZaUmO2Z9slo=; b=KrsMjfX5X3WtFdXsr3i0gQ9bL8cL9DQm+p6+L5UjIpZ6oURGRmTmIp/DCFV1I9HD7r t9PmMjeQdzpE31zvz+Apw54TMsoKhWlMEKm2fjMU4QAWHXj6SGO7H3upiio757Df0+TR 9CkVBnN7Xs+AqCU/xQ1J5pjvfLzmtw8ZNaZXqgHbu1L0uJkSjSxvFJwaUkwFz7wjonsj 9sD228cM6chLncuSrYCX3C6ry3rfNzI8qGMDkWUkTTnDF3qp+LWcZQ2KJMIdiXAyWzN9 cGsj84A+jM+FKJ6YhYsX6Z3XNurmyUd4unTA3VoB99jGVfbNIQPBAz0gmiQJLe1VA0zw mFFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W1yvz6PnP++DntTLvfsUX/X5f7LpBYCeZaUmO2Z9slo=; b=b2OZGZ4vcVb01FLn59lGDik4QqihvdNLxStNuHb94bQKQM+CpVWL7pPc8K2Sa/pRR3 EipaRap12PyuZrB5Fs063Hvn4iH7coKpFeVhwkDe2QfXelGEiuAq2SpWIBmZsPvAfQIl hE0zOKFf2s68ez8yEQYPc0R7V1o27K/TjwOtR9Huv0brFzR7NmciNDEkqcj1YLtGWYgg t8YeKVj7aSNcLFE+97Np56jB9WMo+oI4DIfk8FKyTnQlsM25tXrP9yxJx/V7MJDpOhMa CO13RlrpdFdPgkZ965ooYPH9nYYw8cCDa8+WPlyvOBF2pV69pQWFBaZwdNL31HZ4sNX8 09VA== X-Gm-Message-State: AIVw110A5MD068vSJFCX0v5E6RRxSEwnWB8kSAjhq3g9eS9jidzuQpBX RmeRcn8AFYONEKsDeeTJ0Bw31kwhlVLF X-Received: by 10.99.105.4 with SMTP id e4mr16262679pgc.228.1500052288029; Fri, 14 Jul 2017 10:11:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Fri, 14 Jul 2017 10:10:47 -0700 (PDT) In-Reply-To: References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> From: Ted Lemon Date: Fri, 14 Jul 2017 19:10:47 +0200 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" Cc: Stephen Farrell , "" Content-Type: multipart/alternative; boundary="94eb2c140dcec5d9a505544a23d1" Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 17:11:37 -0000 --94eb2c140dcec5d9a505544a23d1 Content-Type: text/plain; charset="UTF-8" I have two working groups already in the monday slot. I doubt I'm unique in this. It seems like you should put the important business in the slot that was previously scheduled, and the overflow into the Monday slot. It's hard to imagine how a discussion of the wiretapping thing could be anything other than a dance at the mic, full of sound and fury, signifying nothing. On Fri, Jul 14, 2017 at 5:13 PM, Blumenthal, Uri - 0553 - MITLL < uri@ll.mit.edu> wrote: > +1 > > Current agenda does look backwards. IMHO, do as Stephen suggested. > > Regards, > Uri > > Sent from my iPhone > > > On Jul 14, 2017, at 11:10, Stephen Farrell > wrote: > > > > > > Hiya, > > > >> On 14/07/17 15:51, Sean Turner wrote: > >> Please let us know your thoughts. > > > > 80 minutes for wiretapping is too much. Zero would > > be better. But if not... > > > > I'd suggest: 10 minutes for draft-green, 10 minutes > > to describe issues with that (i.e. the slot for which > > I continue to ask) and then 10 minutes discussion. If > > we assume the folks in the room have read the list and > > the draft that should be plenty. > > > > If we assume they haven't read the list, then it's more > > important that the counter-arguments be given sufficient > > time. > > > > So your draft agenda seems to get that backwards to me, > > in that it allocates 40 minutes for a sales-pitch and > > then 40 minutes where we bitch about that at the mic > > interspersed with proponents repeating bits of the sales > > pitch. That might be more amusing for us all, but seems > > like a worse use of time to me. > > > > Cheers, > > S. > > > > > > > > _______________________________________________ > > 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 > > --94eb2c140dcec5d9a505544a23d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have two working groups already in the monday slot. =C2= =A0 I doubt I'm unique in this. =C2=A0 It seems like you should put the= important business in the slot that was previously scheduled, and the over= flow into the Monday slot. =C2=A0 It's hard to imagine how a discussion= of the wiretapping thing could be anything other than a dance at the mic, = full of sound and fury, signifying nothing.

On Fri, Jul 14, 2017 at 5:13 PM, Blumenthal= , Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
+1

Current agenda does look backwards. IMHO, do as Stephen suggested.

Regards,
Uri

Sent from my iPhone

> On Jul 14, 2017, at 11:10, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>
> Hiya,
>
>> On 14/07/17 15:51, Sean Turner wrote:
>> Please let us know your thoughts.
>
> 80 minutes for wiretapping is too much. Zero would
> be better. But if not...
>
> I'd suggest: 10 minutes for draft-green, 10 minutes
> to describe issues with that (i.e. the slot for which
> I continue to ask) and then 10 minutes discussion. If
> we assume the folks in the room have read the list and
> the draft that should be plenty.
>
> If we assume they haven't read the list, then it's more
> important that the counter-arguments be given sufficient
> time.
>
> So your draft agenda seems to get that backwards to me,
> in that it allocates 40 minutes for a sales-pitch and
> then 40 minutes where we bitch about that at the mic
> interspersed with proponents repeating bits of the sales
> pitch. That might be more amusing for us all, but seems
> like a worse use of time to me.
>
> Cheers,
> S.
>
>
>
> __________________= _____________________________
> 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


--94eb2c140dcec5d9a505544a23d1-- From nobody Fri Jul 14 10:11:54 2017 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 0FA6112955F for ; Fri, 14 Jul 2017 10:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 WdPCfXMMl4ZO for ; Fri, 14 Jul 2017 10:11:42 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D79212F4EA for ; Fri, 14 Jul 2017 10:11:40 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6EHBYuP009354; Fri, 14 Jul 2017 13:11:34 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Yoav Nir CC: Joseph Lorenzo Hall , "tls@ietf.org" , "Matthew Green" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8cSScAhmTiiEWvrRLNt+JsyqJKs/sAgAkO1QCAABOCgIAAA4QA Date: Fri, 14 Jul 2017 16:57:51 +0000 Message-ID: References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> In-Reply-To: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-BF1FCA3D-305D-49FE-9939-DE7D93DDD8C1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-14_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707140274 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 17:11:48 -0000 --Apple-Mail-BF1FCA3D-305D-49FE-9939-DE7D93DDD8C1 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: base64 RXhjZXB0IHdoZW4gaXQncyB0aGUgaXNzdWUgb2YgbXV0dWFsIGNvbnNlbnQgKHJhdGhlciB0aGFu IG9mIGEgbWVyZWx5IHRlY2huaWNhbCBjaGFuZ2UpLg0KDQpPdGhlcndpc2UgLSAid2UgaGF2ZSB0 byBjaGFuZ2Ugb25lIHNpZGUiIG1pZ2h0IHR1cm4gaW50byAiaGF2ZSB5b3UgcGF5IG1lICQ1MCww MDAgZXZlcnkgbW9udGgsIHlvdXIgb3B0LWluIGlzbid0IG5lY2Vzc2FyeSIuIDotKQ0KDQpSZWdh cmRzLA0KVXJpDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiBPbiBKdWwgMTQsIDIwMTcsIGF0 IDEyOjQ1LCBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4+ IE9uIDE0IEp1bCAyMDE3LCBhdCAxODozNSwgSm9zZXBoIExvcmVuem8gSGFsbCA8am9lQGNkdC5v cmc+IHdyb3RlOg0KPj4gDQo+PiBKdXN0IHdhbnQgdG8gKzEgdGhlIG5vdGlvbiB0aGF0IHRoaXMg c2hvdWxkIGJlIG9wdC1pbiBmb3IgYm90aCBzaWRlcyBhbmQgaW4gYW4gZXh0ZW5zaW9uIQ0KPiAN Cj4gSXSScyBhIGdvb2Qgbm90aW9uLCBidXQgk3dlIGhhdmUgdG8gY2hhbmdlIG9uZSBzaWRllCB1 c3VhbGx5IHdpbnMgb3ZlciCTd2UgaGF2ZSB0byBjaGFuZ2UgYm90aCBzaWRlc5QNCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUTFMg bWFpbGluZyBsaXN0DQo+IFRMU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Rscw0K --Apple-Mail-BF1FCA3D-305D-49FE-9939-DE7D93DDD8C1 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4 MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd 8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg 1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4 HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK +4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8 F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01 Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+ BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s 6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p 6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2 oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1 RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G /HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9 Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE0MTY1NzUwWjAjBgkqhkiG9w0BCQQxFgQU64WrLGrYm29Y 5qjtomtP83UIsacwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAAwk4/M2mdUuMtgEbYumsfMeNiYAnVjAFWZd/6ac HfxjVeIKCnhJa7/N4faHutdUgtU0MAe2u/Gmxlgz4kXZ8bg+25RtXNmsoJix8o6ENDS5wH3e3Fb2 TZgxxBxXUM+H27rMg5Ml6Rizj6PYSTcc5lNbwpwkQ/yCb0YJeNXB/bow+DpgY3iRJbd8Zg8vwxq8 xxxjB4x3hR/h3EHW/tpVuFS0ydoosxLYxJHJgfAzQr2QH/aPqkQFc9KOU9OXZm1TFhVLHm8QmOfo 9uu11nbAuQNSLyf+CnK/G1U9u+A4vf+lDY8JwWVRcMQnTajd1tLGvhAe2l9a4at3bKyiwzMPTWcA AAAAAAA= --Apple-Mail-BF1FCA3D-305D-49FE-9939-DE7D93DDD8C1-- From nobody Fri Jul 14 10:29:47 2017 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 79C9B12F29A for ; Fri, 14 Jul 2017 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 4MHNpnAFA6BS for ; Fri, 14 Jul 2017 10:29:44 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 97D791271DF for ; Fri, 14 Jul 2017 10:29:43 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6EHTbiI019404; Fri, 14 Jul 2017 13:29:39 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Ted Lemon CC: Stephen Farrell , "" Thread-Topic: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! Thread-Index: AQHS/LC5Yd/BsGKLV0aovc3qwkyFuaJTsCCAgAAA7ICAACDlgIAAA1AA Date: Fri, 14 Jul 2017 17:22:41 +0000 Message-ID: <89DFCCB3-69E6-4323-A080-67FD9799B7AA@ll.mit.edu> References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-258F6C6B-D59D-4E5A-BF5E-03D9893DD984"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-14_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707140281 Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 17:29:46 -0000 --Apple-Mail-258F6C6B-D59D-4E5A-BF5E-03D9893DD984 Content-Type: multipart/alternative; boundary=Apple-Mail-ED032273-C933-4FC1-883B-C3028F640834 Content-Transfer-Encoding: 7bit --Apple-Mail-ED032273-C933-4FC1-883B-C3028F640834 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I will be perfectly happy not allocating any time at all for the wiretapping= presentation. I would not call the discussed draft "the important business" - for me it's a= nything but that.=20 Regards, Uri Sent from my iPhone > On Jul 14, 2017, at 13:11, Ted Lemon wrote: >=20 > I have two working groups already in the monday slot. I doubt I'm unique= in this. It seems like you should put the important business in the slot t= hat was previously scheduled, and the overflow into the Monday slot. It's h= ard to imagine how a discussion of the wiretapping thing could be anything o= ther than a dance at the mic, full of sound and fury, signifying nothing. >=20 >> On Fri, Jul 14, 2017 at 5:13 PM, Blumenthal, Uri - 0553 - MITLL wrote: >> +1 >>=20 >> Current agenda does look backwards. IMHO, do as Stephen suggested. >>=20 >> Regards, >> Uri >>=20 >> Sent from my iPhone >>=20 >> > On Jul 14, 2017, at 11:10, Stephen Farrell w= rote: >> > >> > >> > Hiya, >> > >> >> On 14/07/17 15:51, Sean Turner wrote: >> >> Please let us know your thoughts. >> > >> > 80 minutes for wiretapping is too much. Zero would >> > be better. But if not... >> > >> > I'd suggest: 10 minutes for draft-green, 10 minutes >> > to describe issues with that (i.e. the slot for which >> > I continue to ask) and then 10 minutes discussion. If >> > we assume the folks in the room have read the list and >> > the draft that should be plenty. >> > >> > If we assume they haven't read the list, then it's more >> > important that the counter-arguments be given sufficient >> > time. >> > >> > So your draft agenda seems to get that backwards to me, >> > in that it allocates 40 minutes for a sales-pitch and >> > then 40 minutes where we bitch about that at the mic >> > interspersed with proponents repeating bits of the sales >> > pitch. That might be more amusing for us all, but seems >> > like a worse use of time to me. >> > >> > Cheers, >> > S. >> > >> > >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 --Apple-Mail-ED032273-C933-4FC1-883B-C3028F640834 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SSB3aWxs IGJlIHBlcmZlY3RseSBoYXBweSBub3QgYWxsb2NhdGluZyBhbnkgdGltZSBhdCBhbGwgZm9yIHRo ZSB3aXJldGFwcGluZyBwcmVzZW50YXRpb24uPC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0 dXJlIj48YnI+PC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5JIHdvdWxkIG5vdCBj YWxsIHRoZSBkaXNjdXNzZWQgZHJhZnQgInRoZSBpbXBvcnRhbnQgYnVzaW5lc3MiIC0gZm9yIG1l IGl0J3MgYW55dGhpbmcgYnV0IHRoYXQuJm5ic3A7PGJyPjxicj5SZWdhcmRzLDxkaXY+VXJpPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+PC9kaXY+PGRp dj48YnI+T24gSnVsIDE0LCAyMDE3LCBhdCAxMzoxMSwgVGVkIExlbW9uICZsdDs8YSBocmVmPSJt YWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSI+bWVsbG9uQGZ1Z3VlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48bWV0YSBodHRwLWVxdWl2 PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+PGRpdiBk aXI9Imx0ciI+SSBoYXZlIHR3byB3b3JraW5nIGdyb3VwcyBhbHJlYWR5IGluIHRoZSBtb25kYXkg c2xvdC4gJm5ic3A7IEkgZG91YnQgSSdtIHVuaXF1ZSBpbiB0aGlzLiAmbmJzcDsgSXQgc2VlbXMg bGlrZSB5b3Ugc2hvdWxkIHB1dCB0aGUgaW1wb3J0YW50IGJ1c2luZXNzIGluIHRoZSBzbG90IHRo YXQgd2FzIHByZXZpb3VzbHkgc2NoZWR1bGVkLCBhbmQgdGhlIG92ZXJmbG93IGludG8gdGhlIE1v bmRheSBzbG90LiAmbmJzcDsgSXQncyBoYXJkIHRvIGltYWdpbmUgaG93IGEgZGlzY3Vzc2lvbiBv ZiB0aGUgd2lyZXRhcHBpbmcgdGhpbmcgY291bGQgYmUgYW55dGhpbmcgb3RoZXIgdGhhbiBhIGRh bmNlIGF0IHRoZSBtaWMsIGZ1bGwgb2Ygc291bmQgYW5kIGZ1cnksIHNpZ25pZnlpbmcgbm90aGlu Zy48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBGcmksIEp1bCAxNCwgMjAxNyBhdCA1OjEzIFBNLCBCbHVtZW50aGFsLCBVcmkgLSAw NTUzIC0gTUlUTEwgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86dXJpQGxsLm1p dC5lZHUiIHRhcmdldD0iX2JsYW5rIj51cmlAbGwubWl0LmVkdTwvYT4mZ3Q7PC9zcGFuPiB3cm90 ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+KzE8YnI+ DQo8YnI+DQpDdXJyZW50IGFnZW5kYSBkb2VzIGxvb2sgYmFja3dhcmRzLiBJTUhPLCBkbyBhcyBT dGVwaGVuIHN1Z2dlc3RlZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClVyaTxicj4NCjxicj4N ClNlbnQgZnJvbSBteSBpUGhvbmU8YnI+DQo8ZGl2IGNsYXNzPSJIT0VuWmIiPjxkaXYgY2xhc3M9 Img1Ij48YnI+DQomZ3Q7IE9uIEp1bCAxNCwgMjAxNywgYXQgMTE6MTAsIFN0ZXBoZW4gRmFycmVs bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiPnN0ZXBoZW4u ZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgSGl5YSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgT24gMTQvMDcvMTcgMTU6NTEsIFNl YW4gVHVybmVyIHdyb3RlOjxicj4NCiZndDsmZ3Q7IFBsZWFzZSBsZXQgdXMga25vdyB5b3VyIHRo b3VnaHRzLjxicj4NCiZndDs8YnI+DQomZ3Q7IDgwIG1pbnV0ZXMgZm9yIHdpcmV0YXBwaW5nIGlz IHRvbyBtdWNoLiBaZXJvIHdvdWxkPGJyPg0KJmd0OyBiZSBiZXR0ZXIuIEJ1dCBpZiBub3QuLi48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ2Qgc3VnZ2VzdDogMTAgbWludXRlcyBmb3IgZHJhZnQtZ3Jl ZW4sIDEwIG1pbnV0ZXM8YnI+DQomZ3Q7IHRvIGRlc2NyaWJlIGlzc3VlcyB3aXRoIHRoYXQgKGku ZS4gdGhlIHNsb3QgZm9yIHdoaWNoPGJyPg0KJmd0OyBJIGNvbnRpbnVlIHRvIGFzaykgYW5kIHRo ZW4gMTAgbWludXRlcyBkaXNjdXNzaW9uLiBJZjxicj4NCiZndDsgd2UgYXNzdW1lIHRoZSBmb2xr cyBpbiB0aGUgcm9vbSBoYXZlIHJlYWQgdGhlIGxpc3QgYW5kPGJyPg0KJmd0OyB0aGUgZHJhZnQg dGhhdCBzaG91bGQgYmUgcGxlbnR5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHdlIGFzc3VtZSB0 aGV5IGhhdmVuJ3QgcmVhZCB0aGUgbGlzdCwgdGhlbiBpdCdzIG1vcmU8YnI+DQomZ3Q7IGltcG9y dGFudCB0aGF0IHRoZSBjb3VudGVyLWFyZ3VtZW50cyBiZSBnaXZlbiBzdWZmaWNpZW50PGJyPg0K Jmd0OyB0aW1lLjxicj4NCiZndDs8YnI+DQomZ3Q7IFNvIHlvdXIgZHJhZnQgYWdlbmRhIHNlZW1z IHRvIGdldCB0aGF0IGJhY2t3YXJkcyB0byBtZSw8YnI+DQomZ3Q7IGluIHRoYXQgaXQgYWxsb2Nh dGVzIDQwIG1pbnV0ZXMgZm9yIGEgc2FsZXMtcGl0Y2ggYW5kPGJyPg0KJmd0OyB0aGVuIDQwIG1p bnV0ZXMgd2hlcmUgd2UgYml0Y2ggYWJvdXQgdGhhdCBhdCB0aGUgbWljPGJyPg0KJmd0OyBpbnRl cnNwZXJzZWQgd2l0aCBwcm9wb25lbnRzIHJlcGVhdGluZyBiaXRzIG9mIHRoZSBzYWxlczxicj4N CiZndDsgcGl0Y2guIFRoYXQgbWlnaHQgYmUgbW9yZSBhbXVzaW5nIGZvciB1cyBhbGwsIGJ1dCBz ZWVtczxicj4NCiZndDsgbGlrZSBhIHdvcnNlIHVzZSBvZiB0aW1lIHRvIG1lLjxicj4NCiZndDs8 YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7IFMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KPC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iSE9FblpiIj48ZGl2IGNsYXNzPSJoNSI+ Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyBUTFMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86VExT QGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL3Rsczwv YT48YnI+DQo8L2Rpdj48L2Rpdj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdi cj5fX19fX19fX19fX19fX19fXzxicj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby90 bHM8L2E+PGJyPg0KPGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo8L2Rpdj48L2Js b2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-ED032273-C933-4FC1-883B-C3028F640834-- --Apple-Mail-258F6C6B-D59D-4E5A-BF5E-03D9893DD984 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4 MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd 8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg 1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4 HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK +4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8 F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01 Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+ BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s 6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p 6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2 oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1 RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G /HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9 Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE0MTcyMjM4WjAjBgkqhkiG9w0BCQQxFgQUjwYySRPiWZLu NxgyBqEh7jngSC0wbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAIKftLVxDNGw8K1RZlneF59kB2uqmIJh7NVwuCBD LU98LOVyueMbBfUPH9y2NE8CERjE0vx1PIL2Njmbt4U/+N9UuXr2JBJqtYBmETXycgwkJlFysRv3 dF7XWLUee2xyEOP2TQy9aIowY+pPxdnHNapq0dmKGmlFNfeySA/gsNQX8TdL1haYu4VcYiRmiPX0 J1TqKmmFGFH5V4WVHXE3Djj6ZXIsPi9Dc67yHS4GhmBfop9y9z2CL/JZfPM0BnQe+jqoKT8gb8vN gLtxExOD6kg5OsXNFLpELXwsdSNRmYsjL8hv4Dmo5pULrZVS+5lihj3Yf8HSdb4vduag0zQMWgMA AAAAAAA= --Apple-Mail-258F6C6B-D59D-4E5A-BF5E-03D9893DD984-- From nobody Fri Jul 14 11:01:14 2017 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 E9BA9129AFF for ; Fri, 14 Jul 2017 11:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 hgy3gBWsGysy for ; Fri, 14 Jul 2017 11:01:11 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6235D126E64 for ; Fri, 14 Jul 2017 11:01:11 -0700 (PDT) Received: from fifthhorseman.net (38.200.broadband6.iol.cz [88.101.200.38]) by che.mayfirst.org (Postfix) with ESMTPSA id E6C8AF999; Fri, 14 Jul 2017 14:01:09 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5294F203E3; Fri, 14 Jul 2017 20:01:06 +0200 (CEST) From: Daniel Kahn Gillmor To: Sean Turner , "\" In-Reply-To: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> Date: Fri, 14 Jul 2017 20:01:03 +0200 Message-ID: <87efti7va8.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 18:01:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri 2017-07-14 10:51:14 -0400, Sean Turner wrote: > The Secretariat has allocated us the Monday @ 13:30-15:30 slot. hm, that's disappointing for those of us who had other things we'd planned on going to already in that slot. :/ But it's not on the agenda yet, so maybe it has been changed already? https://datatracker.ietf.org/meeting/99/agenda.html > Because the main point of the TLS WG are the TLS and DTLS drafts and > the schedule was already announced, we want to leave those > presentations on Wednesday. What follows is a revised agenda; note > that we=E2=80=99ve alloced 40 minutes for further about > draft-green-tls-static-dh-in-tls13. Please let us know your thoughts. As Stephen points out, it looks like we've allocated 80 minutes to the topic of how to remove the forward secrecy guarantees that we've struggled for over a year to introduce. That's more than we've allocated for the "main point of the TLS WG", which are only 65 minutes combined. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAllpBt8ACgkQFJitxsGS Mjf5Og//RMBcu/uSPpgbqJn/S0JqHjyr6jSyhLrXTdX626zh2A9hC5xUCgvl4K2N 9OZ0czIwUl8/bCOsiCRKjdHLRJr+/Ax4qlccIa63iOCFzVSu8KfeEV5LpiGWVv9m 6K0XAwPv8YO5MA1Ex7b+lTkgo6iYFoJmrjBJIKwXHjkVe8o+CTH6GwLlAMoOmrJQ EiUerl39xC1Zg3WXGRddLgAIJhUKq9KQjvOSfo1l8z3iKi19O94e3jXsmIeIvkvg g5preBaLsXx0qQyLt1AG3t/eyxxFtdRJEuygNK4gpoF46ZuwsuWEe4HsrWHWZ68T tIL86V2OhROUMqDkGjWwDfAooskrp6Kp2Hnsm41DUcbvT+CsWGGAy6qoy+bjhovC t1Ga98kzn4re3SIqibe4LPZGfpfrU7fWYsKFqx7hP7qCSp/tWSDzVng/AJAdocds MBNXnKhrDufLsRQWekQZwDaAKLrqemVL78W556mxC4r6wf/ukvGsdDY8zZJugMdu ZAqdahMYWLAV32aRHofEz3VBfxo8lm2K97NenmgoWHE2qbyidILZZnuOetmW/oOF 9DOrkW8bl0fPx96PJ8wKeAzc+59wVyx5XcEgASi0HtuaWPw2qqYB81fGdGz1y2I8 tqbe/pun6X/pMAEyektkJv5pRUroNK/ReXtMu5cy8ViQbqQVgEc= =n8wa -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 14 11:02:00 2017 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 3CE54131537 for ; Fri, 14 Jul 2017 11:01:59 -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, 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=nomountain-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 hwrErkpvxjSv for ; Fri, 14 Jul 2017 11:01:58 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26176126E64 for ; Fri, 14 Jul 2017 11:01:58 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id l130so77497073oib.1 for ; Fri, 14 Jul 2017 11:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=kIxK4Bgr8SUC0vBrX/ga6x7nCdOipU066e0uMhA5ho8=; b=thzJk8i5Ypg7NTkTnK5oHY7pgHpLZG5b9QJL2o0YJuPO7/jmqIIjJZOlu6942QTZmq /3upyJnOe7scWYPy5uiw8VHcTyGahOlUmVl5r8i2seIdK6BuBlJ8Pl7N501km+mfFfn8 UpnBKCbOVgYYWNHCJCXyvxV3d6CFyrkK951nUMK+kaUPKzEOIqKHUO+GdEo5zeGl4Tgo 0OpwmhBfKT5jcCDIF8FIAWONIhwiUgXm97cEpCQVO0e8A5sXThLHc9+33PAFzF6zl3dS Eefq1qcYkEeR0YN2CZ4Y/BeNvjaGTlG1HPPY1V61CVyEuO3YCTWBZKxts57Gw3lI1Efp 0Tlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=kIxK4Bgr8SUC0vBrX/ga6x7nCdOipU066e0uMhA5ho8=; b=FBgt/vvOS/cJkIRxtiHtiZsXz2aCCJedZppCnT2fX8FqRHJ7+Ku0urMWV+UHldG2V2 vTdwNX0h2CEmzEFuBaf9exyYb+SbIeUObQ1eUV3+PvxrPtmQK69Wo8MmLyZ/ySG0sWAX 7DmhJX4edAbhqPRmVp5Xz2VWLUdIlqlHXbuCQM6Jpam5iyzm4P4eM6nJPWfqMok4+9YD BEA2UwjIztTCtTVHRpaxIc8PHsRsrkDeQNWcCmArk1Ql8cVer4cSghfSvPSbeig5ndbH xyAODSRa+B8zwJq4AZXN8KjbFjjUFz1tW8IwHofItSuF/KVxy60H0XFgE/GkQZZNbjGP UCVA== X-Gm-Message-State: AIVw112Wcp9F9/IwHIZb784GF6dWOHUuxzmqeNS1G05gWN7qa1Vpuste 1GS5zQuIDOjnEjJQbQkCVA== X-Received: by 10.202.242.213 with SMTP id q204mr1690882oih.88.1500055317247; Fri, 14 Jul 2017 11:01:57 -0700 (PDT) Received: from Melindas-MacBook-Pro.local ([173.254.255.141]) by smtp.gmail.com with ESMTPSA id z81sm9517310oig.32.2017.07.14.11.01.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 11:01:56 -0700 (PDT) To: tls@ietf.org References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> From: Melinda Shore Message-ID: Date: Fri, 14 Jul 2017 20:01:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8Rm1Dj583hQDCQ7UbWrqL2nUCJKlq5FQK" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 18:01:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8Rm1Dj583hQDCQ7UbWrqL2nUCJKlq5FQK Content-Type: multipart/mixed; boundary="qmbGucX8P4MGV6be1GJWT6VK5ngGVMIOQ"; protected-headers="v1" From: Melinda Shore To: tls@ietf.org Message-ID: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> In-Reply-To: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> --qmbGucX8P4MGV6be1GJWT6VK5ngGVMIOQ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/14/17 6:45 PM, Yoav Nir wrote: >> On 14 Jul 2017, at 18:35, Joseph Lorenzo Hall wrote: >> Just want to +1 the notion that this should be opt-in for both sides a= nd in an extension! > It=92s a good notion, but =93we have to change one side=94 usually wins= over =93we have to change both sides=94 Something that demands a forklift upgrade of both/all sides at the same time tends not to be deployed, ever (look at the history of NAT/firewall traversal technologies in the IETF, as one example). I'm basically in agreement with Stephen and Uri here but now that I'm working for a company that's providing services I'm becoming more aware of the real need for network monitoring. It does need to be discussed somewhere but I don't think that that discussion needs to take place in the TLS working group in the context of this one particular proposal. There's more than one way to solve this problem and while the fact that these folks want to keep solving it basically the same way that they have in the past is interesting but perhaps not as compelling as it could be. It might make sense to kick it over to ops for a discussion with people whose meat and potatoes is monitoring, management, and measurement. It needn't necessarily stay there but I think that there are a bunch of options that need to be sorted through. I can't really see the static Diffie-Hellman proposal going anywhere quickly, anyway, to be honest, so might as well use that time to develop a fuller understanding of the potential solutions to the problem. Melinda --qmbGucX8P4MGV6be1GJWT6VK5ngGVMIOQ-- --8Rm1Dj583hQDCQ7UbWrqL2nUCJKlq5FQK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZaQcRAAoJELiGRpM6HoEup2sQAL6ksZ6JAOuFGN6MRCDy4dcc 9olzITzrzrV2mxu+Wj1KcWcNaFNeIQA7dTh34Y2tEx2CapPs/bhd1NAkUOtiCEG2 fHp2W8E2RsBK7heESAfZAMAp1Ao9LxJJ3M+9sqBKtlK6bWRwSQphcJpTGVjwnkc9 ipkb6vEAJrA0xzmbjLMw/6XFVngRcUxIim9Ib+7gZz9bq9JWfLdL53WmRmvzpkyC spiRPjS97FNOE9X2TapC5Jo5sE/al0i9sqZCAlIH55d2KBivjS+JBRdAS2kq9hI1 g7RQ9g+JugC1vGSPii7Iboj37N8mEZM79Z0zPNA1988S0l1r7oDu1EIrmoI+RAAh y60DhIWK4cn4AhOqlvXqoLudeDc9gxeNhXkvnq+e1khBOUx6HBD5cPBdAIg+Olee 8YSHuqHobWjlJQABNHR94wxceF4iuX08gUFiyE7xoRUvh5saoKUAje/deJ4N0tqb lX+8pyZo8895uznsUIz/ll1uQtozvxETYth/KqxhdvHgU03ICvVwr1uXeS7ghWPA 1SgjAcrorXeG7GTOlrErUkxM5lzfQrAUKv29+g2WZoNX8lCcOkg7h4G1idAF94jU 9+3tgINaI8PwEMk+PgwQ/RG78qSOt8pZrFa38VvojRAca92ncvYm1NuB45af1yF9 NjM6LR22OereNrl8LjLY =BPQW -----END PGP SIGNATURE----- --8Rm1Dj583hQDCQ7UbWrqL2nUCJKlq5FQK-- From nobody Fri Jul 14 11:31:18 2017 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 BA5931316DA for ; Fri, 14 Jul 2017 11:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 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=-2.8, 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 2i0-75H-c15M for ; Fri, 14 Jul 2017 11:31:14 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0098.outbound.protection.outlook.com [104.47.42.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD0C131691 for ; Fri, 14 Jul 2017 11:31:14 -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=kvZvIMavwHxdWJxbFZcxQUOvb65lG8VjSCYIPaD1sNE=; b=Z0c0yVfVnVhQ6kemNZchzsDVVeTacD8IX8Zwk+8W0BFAS0h2F7j/myUuiVkf8QKvkfEyPdmVi8alDBtZ4uBMGxkReZ9evG+rmSvCgaQ2UqCT2o+rRozUp4Z/o838f2goyf9B86bdGmXH4lN+1ZM7H2tC8g4zqsMQUjmvnVIV5eU= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0076.namprd21.prod.outlook.com (10.161.141.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Fri, 14 Jul 2017 18:31:12 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::c8c3:4f7d:e655:1fb2]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::c8c3:4f7d:e655:1fb2%13]) with mapi id 15.01.1282.000; Fri, 14 Jul 2017 18:31:12 +0000 From: Andrei Popov To: Daniel Kahn Gillmor , Sean Turner , "" Thread-Topic: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! Thread-Index: AQHS/LCuYGeMEtwIw0+uMCmb9M4dcKJTnO+AgAAGHvA= Date: Fri, 14 Jul 2017 18:31:12 +0000 Message-ID: References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> <87efti7va8.fsf@fifthhorseman.net> In-Reply-To: <87efti7va8.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0076; 7:BnRqRyK7ls5PEuo1zlpLh04gpMiRhpV2zMVqmsP7A/jdzJbmP5gVZzyzWM0zPxeJag++3WFkjCPH46eIc0Pqq5o9WXTV+mdQ7GQqE70/1XJHHE5Qq7gnJKkwbz3UwdDI1EJRCp0mgLfqQAyDnIP+3s1KDs9jnnqX31sUNTdHt1hPAS4eGYvG9xegPyehqFGICc6oT+aHIZUNeUBhHzcsTNDqhsHoTmJNGWAdY8UnfElT4CP0mB1jNfCEQTplJhZhvKyX2WzYwy6zp44a7t6/2AOpcK0/bcNGiClRXcWMDokj4/rnTPBr3giQRGdhDbiMHn1bzK0mkDzDyeA4y8drm5TJyJOKMd0y9vIfJEjBMNfqDzkLmC2sfaerxzsfU+AI1Xbj1vylo5SxnwVe4rU8jCL9+yMQz8mb3QwSbiqHjHUAo+1jlpHmmsDJOkcODukfTVxItPsDMrf/X6GPh97r+Zeq4602pR3MC/um66AiNrN0l2G6Glq9E/uP9gT7YLnsNS8H3YZz7aqy2z4luxOcRt4iPWteTIPmRB9xMiO7aCtV0QGe6iu51KV/HRMeS/GYOTGpLHpfsRLAfOw6cj3KR4OjcjpIKG/u8wXdOkGPcx4eLjcZpAowUakvvZf24vZdgKOQWVEym9U2UZuwI3UpQ6MRANldlIUAoIDs6EDUUY9NfwL52NZJ8166OctWrFVGEGtg/B6X+HhwUEJg7pPWQa0NY19gYKqYleYnyovKJxmBi/qyHemNhQsh7MaD0DCEdL693U2vVDYHbRM7npqZafu1G8zSqTOfEI2QWxiemQstKFVR1lPqXfP6hBMhuazH x-ms-office365-filtering-correlation-id: 3805b1df-49bf-4161-71c6-08d4cae68120 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR21MB0076; x-ms-traffictypediagnostic: DM2PR21MB0076: x-exchange-antispam-report-test: UriScan:(236129657087228); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(2017060910075)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0076; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0076; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39400400002)(39860400002)(39850400002)(39450400003)(226693001)(76176999)(5250100002)(305945005)(7736002)(25786009)(33656002)(54356999)(86362001)(478600001)(38730400002)(102836003)(50986999)(6246003)(10090500001)(10290500003)(5005710100001)(81166006)(6116002)(229853002)(8990500004)(14454004)(6506006)(8676002)(2900100001)(8936002)(6436002)(99286003)(3280700002)(2906002)(74316002)(9686003)(5660300001)(189998001)(72206003)(3660700001)(2950100002)(7696004)(55016002)(53936002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0076; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 14 Jul 2017 18:31:12.2664 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0076 Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 18:31:16 -0000 PiBBcyBTdGVwaGVuIHBvaW50cyBvdXQsIGl0IGxvb2tzIGxpa2Ugd2UndmUgYWxsb2NhdGVkIDgw IG1pbnV0ZXMgdG8gdGhlIHRvcGljIG9mIGhvdyB0byByZW1vdmUgdGhlIGZvcndhcmQgc2VjcmVj eSBndWFyYW50ZWVzIHRoYXQgd2UndmUgc3RydWdnbGVkIGZvciBvdmVyIGEgeWVhciB0byBpbnRy b2R1Y2UuICBUaGF0J3MgbW9yZSB0aGFuIHdlJ3ZlIGFsbG9jYXRlZCBmb3IgdGhlICJtYWluIHBv aW50IG9mIHRoZSBUTFMgV0ciLCB3aGljaCBhcmUgb25seSA2NSBtaW51dGVzIGNvbWJpbmVkLg0K DQorMS4gUmVzdGF0aW5nIHRoZSBzYW1lIHBvc2l0aW9ucyBvdmVyIGFuZCBvdmVyIGFnYWluIGZv ciA4MCBtaW51dGVzIG1pZ2h0IGdldCByZXBldGl0aXZlLi4uIEl0IHNlZW1zIHRoYXQgYWxsIHdl IG5lZWQgaXMgYSBxdWljayBzdW1tYXJ5IGZyb20gZWFjaCBzaWRlLCBwZXJoYXBzIHNvbWUgUSZB IGFuZCBhIGh1bS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg== From nobody Fri Jul 14 11:42:21 2017 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 1C149124217 for ; Fri, 14 Jul 2017 11:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 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_H2=-2.8, 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=thescout.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 Z58JsitpraSl for ; Fri, 14 Jul 2017 11:42:16 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F0112778D for ; Fri, 14 Jul 2017 11:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YHlXFL8RI2I8vQ69lSNoKCtJEwl3oIWW4kvOjMddCbQ=; b=HK56jHAYvE5TFlhdwT8kfh8UjgsSCQykRdF46NtaQ9mjdS5auUZY4MjFlBIMSyvnMpbV8lP1bPKjSn07s+8dLakLNd2NL5VpzMJQLfpdXsIBfPseq/qGLM1KL/zcPhmhWyqZj8W25wlaa18caE2tTv/GbevAuBZnKMMVqDc7FrY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arbor.net; Received: from [172.19.254.116] (49.228.100.193) by BY1PR0101MB1029.prod.exchangelabs.com (10.160.199.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Fri, 14 Jul 2017 18:42:13 +0000 From: "Roland Dobbins" To: tls@ietf.org Date: Sat, 15 Jul 2017 01:41:57 +0700 Message-ID: <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> In-Reply-To: References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [49.228.100.193] X-ClientProxiedBy: KL1PR0601CA0022.apcprd06.prod.outlook.com (10.170.160.160) To BY1PR0101MB1029.prod.exchangelabs.com (10.160.199.154) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3a23fd30-a3d2-4b60-97bb-08d4cae80bd6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY1PR0101MB1029; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 3:u0SsFdpstIOnr0chPsX70Mbaoi0RJdnVA+0MACPEAM8lrESeJVmvMEoKY08xEoOdx36A4haqXQTcHOGCwcKNdM2iGO64UIcgwR10AkSUynR9VyrbD/zl5ikQJIOsigHHW6vNetxnedmEPkh5qPxB5k9cv1J2HZD/2WGct1qozYMOMRsz08qHQftuvuQcubWk93Ywl/ZMPAPHLCayiL1UA0aS2zRoGmsl6ins+laKBtmApwnp3X/sa834XfxSqBJl4vgXPaXhg18jsyO21OY+34tXyEPYxYWEm64HrsrsxGalveOdUqegBjzQ5LGv8RxsZU5ssmbvUAUtlrmIQtPVgjuWNQfR4WX/5BDt5mX0xvLLec6Gr14ws+upWLJW2Otnpf5h+kkZqi7vU8CT9CZCZI9dtccQcPK2o63gvFfD92vT+fOh9k2Tmurh9yvXQPl4s+re71Wogbc4zpvqcCdesDGKtHFZTaBseTMQrnSic6yESofAV4lwB5Ws4zX1Va8dS+n+wi3cMBb0gfuSkmc5gnatmYCuGwolSH9zGbnO5lImoAJVeh2Ux6RS4Mmep+1idQTxK2M2R8I/fOAoASC6j9ikEwIBrq1BVN+hsZAWlAkOhvq+2H7/Ob3b48u8I6Jt3UEA7Wge9i0HDdld16H6CdAFRzbUuC2+hC2P6KX8jDZj8U4RLZ9i+Qzo/uvxmEJLjJG4BtAxfci4fwlcYC++/ON1zSqZ6proVJ59xjjywcg= X-MS-TrafficTypeDiagnostic: BY1PR0101MB1029: X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 25:j3BK3VO7O8H5DA29rhi4F422/TqgijFJ1HKwFUaL2Fqn525BgQYZFgjlIUAfMHrVGnEDM/e4XQHOiW1bRsCHmEsBkUAsj/8WqFzTSQWN63QgUED0Y5O7YSAeIyi1OG58MuEfdyjqCi0rjdOuUv3f3SEq586VJU/1VBmzZvvEMdYPzf9DGplC3b8o+F8UqF4n1VRbjQxapewrAfHibaeYAeyeC7TmBVYlVu9EfKLjn3O4LmeUfgWFEvKMhap7EUowGdlApMSc+v8gVtzP1E6xGdaGtDUnFHc/eDmvA1Z+RrWPq8M6mRzfc+s0uF6ZplI+u9iSPRGcIeyTSiEOwiAJy+5Rbgo3dxxfXTdsILj/vDe4KVzfDwCBXKvB4xZHc+ySSOxg4KbtfTxpkznB6lzMSqVXsLOgeqDRJz0S90aiqAPATl3sedlVVkUwH7yUrWDFPkI8sosoxXJE5nGSklU7UzGzskEuYD5uBy3LYFde3maxY6uImePbMdEj7JgqNYAtF/5YCOA4mJDLb1nLrQZD25h7u4ps8NXZMRtZcwe+PsoqD/A49MVAjuL1Is7m5IwYW6Mo1webURzgtdeynLMuF1bb6m5/6+vdgAU1FwUICZ1IZPK+hgLfEE+2pVkStlGPHERqav5FuqvTObqTlqwiB+AyLbyb+SZg62XuajioAC4frJMgl2ss+nGikRViDWkp1PJR3reuQMu98rEpfmX+XAvclro8voXHvAw/YfebMCOafaQj6Bmi44hLQhBHi07gawYjtCC7tK3HDJv+tthF0kKg2XYOnc8lNk+hSA8sKhJRlukzgWmyz2+7dVwQbuA6k+RRqEO4FTWJhuTn61wnSp/QBHHT5M3pQEOdwG/XEz147mpRB/darBm2/oJCQOpmMI2RTwTwLZ9n5G407+DT80UZjv0vZiiu3vNX7oMj3S4= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 31:uzYxkFFJ5tqXEULaBh8rkMdVCO0VXJrJeBKvpoiNvVPoUZJdx8lCgulNnh4pr9zh4zAzMHnYP/ZUmDRCpZPpJqJwDwN6bg92rww0LjfMtE2EFSgugjCPVZ8SDzACtug7/orz5ALFOwn/aV/EyQ8lPBUYqVTywOoJq7lTJjwDd04xxwLWjeFOcxgaY/vYFUoGhpM8RZraMmOlF/Hy1bib7mUzIaFhrHfeWFFjaS4TDOsd6Kq5RYSbHoP5I9IElg8Yozmc5nQiKU8WosQil0sONmnRJRrzBfPltnHf76L4Y9beXFLR0H4Sx0X9YY148tE5JPCeWOwedhL9lYblaZVu+6Wv4p3s4OgkZePY38gQamrtdMTV2SHUqo7tf7CWBLz7PUBtJVGXAaAiP1WO6KwZhd+aT6fQjr1HhqxS5tCxzq+g/btKqylA8gaf0ZklSSHXzQ+BIG7Hv45ouAa0b0URbrGVTnhfudurbN+74VWE0jOiOU6JhrfrxwumJw6PvZDjcduM9RYqIgqR3ikisDAZOWb/0jsA1nV6xHGFxhWVxJhwgnfDmsUZTl9jfkrzzBhOcZ1r76j529l9Q+Lw7HPre/hpEwWFA1KIWVdQPVwyF37lzaP/GSix6SLBr9/yTU1EKcrrrPdbIuASYAUfW26nkkiT3Wm+I+MhKcrK6en7pwRMp4JYB073G6hm28SEYPBJtiXZwz0tzbpfV3e/L6mJ3g== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 20:tKh98/FwjFX3XMgCIpvN9NhUwygZ0Sn8NRVzqXAF7haxzuJ5N9SWaO+VfEHzamHEwUdb1Cby92JqoUi8IrSA1t6F2IApVnX0RjzAkg8cbN1kwwJseyW75WhCmNQ3KB2AKjbwB06+4eWT2UTlG6xvUyB/fzYX058+h7UVG8Cqk+QtwMAr/ZlD6Jiog3iFBLV/YFcnc6ag6Qlxzv0AtLZu9ubVoVPexCrRCjWGS9mYiZ9/0wEM0+jHh9pw115tKFuRy4RVbbMYCs5xb0oq7ZNdpUPIgP5zc5NCgtPRhMFVMALjHy21NrspcBl972lAfytttfow42JXpR3MqqBsuQ3kZHcIb7uSvEhEqtBo1Nh5I3Qwc/czU/z71ThxZAfXfxNNv3oSq68ssMCyk1Kxty2xXdbMIPHa8bnOdTUgxsYHTRqIPCG/S2X1XlaliJSC1QQPivm4VWwrpFsJdOF15/o4mMFezRvqOOVhdzzYWID4xK/fMqKqH8HtukWvjmSMyytR X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(72170088055959)(236129657087228)(192374486261705)(35073007944872)(158140799945019)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0101MB1029; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0101MB1029; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1029; 4:OjygqCS1/BMha5TsHRb3oHY68NgFHMv6Kc0Zab5/?= =?us-ascii?Q?bKbZfB9bIMXB0tzmmGGUs7cZU9p2liDiyZi3pdwoxcx2oKNE2qpQznI2sMPo?= =?us-ascii?Q?60VMjLsacLQVWHvGj5C+S6Izzv7rMI06uTft+HXDIEb8Z29bbqENdO1B9vWg?= =?us-ascii?Q?2Rk5XqoAQ8fWmezAnZQwC9LlqrP+ONZBBiZdtCntpcu7UYdTN/91k0aJcgR7?= =?us-ascii?Q?GThKj9rQEpYs93vpjeOnyOJtI4JtuxbE62R2+3wVUK8yNES4aUVbzE6Bvtpr?= =?us-ascii?Q?cPZ5J3eYkK+qhJYR9wJC7vOQWQ9XeNNB/d8W1LWGcKzVZCSUkxKSNH2kfRtv?= =?us-ascii?Q?6oJa4U6rzVC+zmDsrj8dHEG1Lhqe+/8G8lfVYjy//i/bAAzUhTk+i456dna1?= =?us-ascii?Q?6QflSpjdoEVWP8YsSqUN/Nzf15zFIBCQ3nGQYvEOo56NWIXqBmBWsMDZNcda?= =?us-ascii?Q?U7knCgDT73iOsD6K8OeE6nKn73hpAJpPX3KvlHW18zFf4U4FR8a3OeBExOng?= =?us-ascii?Q?9k7AXp6xkGxZYxq1RE4772ujH60c6JKsda+lzTqk04b/zaTFNYyeLksiqyBI?= =?us-ascii?Q?3FVUO8HBe1QS5Tk+Pu14NhO5ZNc4EFOkG8fE9lGnTpKwbBzVJqOHaFxpjaqP?= =?us-ascii?Q?kvZyKzcVskDPJy9aZQNfx/QoXnvJHZ2mZtXubYFdtcGGgssndvDjjLRjdDEp?= =?us-ascii?Q?G95l89C/f78hKfM5jMAJtd1W7huabcg5T51buURgQwYZ+NdmR8O916rcJuxj?= =?us-ascii?Q?ORis2EpzzTYCqglGe0nw2Ru3IeUHkVfXc1FIjvAVFzmz7Dh79CIrD+zK4NC5?= =?us-ascii?Q?7SWZ+fczhK0JlsrMqRplGtTJ+wLXW/lBBt8Jjn9gY0f24SUrmR2wtVa48jgZ?= =?us-ascii?Q?9Lr3/ck1Dja+Z46Ob8n1/+07rTrCd9h6ljDi+jTWeaa45ZIPrf6Fr089RlCN?= =?us-ascii?Q?SkfLWed2vlIzRUO0Zw5Bq8hwuUwfLKlGSH/kh2ohk9I9eB8DOMAcyPwWgEJJ?= =?us-ascii?Q?N8VljOmvNnBStxGX6ad5sGOk4+0Eh3iRploCWo76K+eV5BKRwcBB2psiuU0x?= =?us-ascii?Q?AUVVSryOjFbTh0EHCHk/d6CFgrjY+tThdkfMOb9oHFlusuDCRBI3wh37Y9Le?= =?us-ascii?Q?SG6gGHNnB96MmF3fxrQ9yXcHEHWrLljgkgovP3C6idzQCfJlTc6qTfPEXUMO?= =?us-ascii?Q?2XyW84tb29jGdCHu+Pju+pa7iGqonay4C7VbwIX+zkCR1sLVY/PjGtvuoPeV?= =?us-ascii?Q?4T4d7/y0QFuzWzS7xYeaksbQWai7NraMip2KoehY2jc8ItaY29UfnkApRipb?= =?us-ascii?Q?7xmHyqDxoEo8qYg4thfSB2NgcYxLA2+19fFjlnrq8LajtLtkw+R89Y1VThy8?= =?us-ascii?Q?UYvGBfaFNVTEZgWnXpYjB4Nlu9qy/qkhqk00EQgGj/qPyj+8ZZ2ZpV/Z09l1?= =?us-ascii?Q?e5iWvKbFbw=3D=3D?= X-Forefront-PRVS: 0368E78B5B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39840400002)(39450400003)(39400400002)(39850400002)(39410400002)(24454002)(50226002)(5003940100001)(6246003)(230783001)(86362001)(53936002)(189998001)(110136004)(66066001)(93886004)(7350300001)(53546010)(6486002)(6666003)(5660300001)(82746002)(229853002)(83716003)(478600001)(6916009)(2950100002)(77096006)(305945005)(36756003)(6116002)(7736002)(33656002)(3846002)(50986999)(76176999)(2361001)(38730400002)(50466002)(25786009)(81166006)(8676002)(47776003)(2351001)(2906002)(42186005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0101MB1029; H:[172.19.254.116]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1029; 23:OkgTDKd1bxxS1c2xusicOiDkduGIAMEwXd9SPr9?= =?us-ascii?Q?+jP+lg3HNVC3KJvRptYv5C0geYAiy0cfMXDt69GxHKdl+yDQKI/54uHiwa7D?= =?us-ascii?Q?wUBLjnPSmsgDS43gKKa33Ed7knuK11OrIFMsHDLJWQ558sCvye2pr5VLcg0O?= =?us-ascii?Q?lXBe2eOYVcB/+xydUeoVEEVO37KtNQZaeSKfHtuiAZfTACC42cQlp1HZyjVl?= =?us-ascii?Q?Ax+rWsZpm5x3CgwM8x6tb7LSejrcTZ+zX/Kmn3YPoZ2WAQDc4+e3+EZ7bMTG?= =?us-ascii?Q?BrgAf29IOSQwdlc4Pya5kgtXu0FiOzpxooYNrx8NY99hmB2lfDanIV0pRt+h?= =?us-ascii?Q?s4yw0/36kLAToPXpua2U3uIBOf7IrGaw6fFM1hwSOer1zjIpPSpeb/GYwmVo?= =?us-ascii?Q?8BgyeyRr4Ic7ahxEjaay/eakCCBO9Ly9oQkBG4ByxL9PYraUWDaHKrtpj1Vv?= =?us-ascii?Q?fM/tdNySzuebrt7N04FezwkQxYhTBC7ZbZYBETZTUtcMel1S49og84y72Ruj?= =?us-ascii?Q?O3ERG5D+ZY7ogUkIUARV4gF2So75BPtWD+LCSqPw23jKwSnI+CUjL/byt00K?= =?us-ascii?Q?DMkc+TWunctYpN45v4YMk5PVMdAJfO5Q90Ody9tt1SRsD20gfJysR/CxUNIL?= =?us-ascii?Q?OrRx+899wyMdJrYA5pFnPItysBpNDXnckpMvyfdUP4U9R5l/z35LcHehLRCy?= =?us-ascii?Q?nQOO9kloZy615Im2uHfM6xscHXaAVOPQ9ipBoXKgV+Q0CBHp7PFidS3UzV/K?= =?us-ascii?Q?7GJhuqnYL0jTfynjHp6N8r2GzSCV/TmWWjyAmv9ssIroR7zD5n92tAfoTlt/?= =?us-ascii?Q?EFTRKWuo4Z2D1Kl5+UD1Ub4lGp73PpiYuHgUeLZwcEQeE9TzufrtC3oJJJm+?= =?us-ascii?Q?SIGS/9DG8jbfp61zYMg1edPA2Asy+FF0kgY8nCro7hDP3c8m9GWbOVKpHj0r?= =?us-ascii?Q?FUeVX98/BRjdvnGXJMaA/HzmdRA6FEUe7GTYifFDJUlyYsymRcRx1AzvhjHd?= =?us-ascii?Q?RvilCQ+q3A3V1knJnQ+c6zIBAxKJ2uApit+0VJVK7C9LEnUQoBJmMIhOGfp2?= =?us-ascii?Q?bcTyugSfk46wM8//q3210lyFc0sLoYIBurxEM62Im7eASnn61WnbsnIn6EnT?= =?us-ascii?Q?4Qjpv+FnQWAtktKkeaHiA1006tepFChm5G5pTtQqNzxRlSG3c81jNkeT3Aza?= =?us-ascii?Q?O6qHnKoT/AKX2Hk1gfWEOV0YfamPjyIDeCNTGzs03yzXJVFKKhMxT2EA+xFx?= =?us-ascii?Q?B47sHWfCvjXiZH4CoCQs=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1029; 6:A6H2HuK86z0gtCUZBvDInPqRXtQ5HNBz+vGoYgZ2?= =?us-ascii?Q?7F86+xDrYv3L+IYNnz8cpZLiak0C4jp/X3izelDQQCj/8PkE19y7xBPf6wfC?= =?us-ascii?Q?iR4t2+tiPD+El5z19z84uSoXJkyHZf0JDCLaXhLDSKzjtm2nKy/LyBM5jlfb?= =?us-ascii?Q?ln7dnrW355NDUR5lIdFy765VSwfEvLh6fXQbJf9uXLoPeGohPaOP99ncu2wx?= =?us-ascii?Q?CHkc9k/aCkt9HxERdW2qJzPJHc3IiLOT3s2ufCogftjrHOxymKFE5sU0cVml?= =?us-ascii?Q?j5OJK5cw7DP2kqly/XIx3aA9dPElp/z3PHBVs2AybCAWnx3gv0vi6XjKuUQb?= =?us-ascii?Q?U9ZBzcFtpgyVDisdsrpScrzM4RZ1gU9roJokAmnsjqC/FUhVQczOYx79wr8k?= =?us-ascii?Q?jPcYL9NAGdnV1hUjzm49+yf+W1lC/1ya0YwA0PyXtZ1KbjU0IObleXILNDyg?= =?us-ascii?Q?X+Pvz0rCwkgl5TV/UzBC4LMl8aPoWK5TmzV2DeFqdr0SrancpTEoeJPObK3u?= =?us-ascii?Q?D1KQPUqDkmPR9tVBuPnbi1dhALhYYVbJLn5+k/4G7bO9B3928TVgMIRdTTvI?= =?us-ascii?Q?6lyZ/rKrY8wBex526WIBuq+1tG/glpuiiONliBZ6tyB1IHhUUq6gg1Tlm5zt?= =?us-ascii?Q?z6FjtQJasInLTyM7apAXLaVxehUNctpD4Cye8YNOi5H2Ka1ft1BRGZyeftBx?= =?us-ascii?Q?Yx69uPA9ykH/eKO3zBj/b7pSguusGmb4Mw56tzUspWljaRHMNp48utvpuYSW?= =?us-ascii?Q?9T9r1s0Am06N2IROi38X0kHhfo2Nf0aj6MdLIGuYi6d6CLki4pZ2uevwm3AO?= =?us-ascii?Q?EwyVN8TFhPeeR5ii2JRSl/aXS7zdQFmf9DKGjdZh3DiP+YF/+6XUuzhUv/9C?= =?us-ascii?Q?+BUth8j5yxUclaoeLu1qIWrZwSWQsqdIYUASZvRm8Wi80fIN5TZpj6BraLyc?= =?us-ascii?Q?TkzT1YK8uKmz60rbRXPfFvWkgcMj5NqdqV6v97u3LYtmwDFe4zK67QHzwNkS?= =?us-ascii?Q?EpM=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 5:I6y1WfGgIsh/Q53VYdZlm0NR0Y4/P6S/66Aw9cV3ilLrlucATl4zjM7vmofuuts68ihc5Es8dB97T4QAosnZ2uS8sEcsAycT1AQiauYDKSc9jZ9GQtfJHKq0tq+1lQ5M7gYYYb/9oX5sVpSONeZR8amD81SX28tib4uBqwwMeUosI8PcbRUi0t9VspmnYQVmwVq/idX0fL8qM9nm2XM1YEn84xnMOBXnPORPjMRrCw6OPSz2uDEFIhbCJ0uEfe7WrSlz6LFG+czkXrVEh9AKuHUYB3cYkNJP1GksDhknnr4a5Kg7lwcvNiyR5VaVDmriEIQKty7HTEKw4QWYPEhxEnlsOw9D+kylKY3hG21bio76F40cmYBS73gWPfl5b3ZoePjjnMuUpQSrISu70SzohXXSfSqa4OhNSbkR7UMfkrU1QOeHHIH0tdNh0N3ffT3aUEIn95Vt/kSmRG3Uu5L9JM+B86JO4BblG7nVj6PTpmYD1SNkQ8JyBDR7zdvqwQEc; 24:t5FyisOdum3vbj9YPIuI1DWZfWPqW2ZAqsyhMVyv4wIFv5S11DdFwJ9dhaLBozwqwMJsdwIJJUAEkX4p8hAR2mPm38M7vi9O/skOJfxoYwU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 7:gfkNBy30d3KOukylLhvDweagAkUmjwkR8yimsni+H8t+9J/hqvJTOeln622vTTE6BWqFwYiavTEP8kc/45FJgspNAk+2wPHDK3aTC3iVJwzig5uzGEiQyA7vdntWXah0pzgrEqfz+hQmSs7dBkdlFKh736mfeah9izE9KkgNBbql+FL5QMWzaqdBreeR6U8b2WJLv+vSLKLuYTwxylXVioRDRAjo1/w1De0ttJ9HEKftz/wfY7jhPDLjoX39pMUMWfRny9bhtMW7zKnjNdjby4wgWDYNaW/mDET5AmTenbX4XJuEoe/ytaj3HCVdksw7/sSS+k6OeQSsQEBSGpX7u+7bgQ8T1QF5E7/fcSU3kotLQYql39BXHJA/LGf5IKmvoo/LsSJE3rRmW8GpPagBnnxWk4qFXaoN3/PSs9LgLV2c8qgTF52RiQZ8icbXxhBW/blA1lx42nH+UiDmioCypj/gfJViNUYYuZ+zxuIrpOEOkKtPishBq2hWznDOhDVnEpgo/4VFNQmGCE8onxLBW/hT54zAavqdbmCy+g/adLesyGXrcONXryJ5fRnJZ0qChEgEWrNbSId2UoFSNIoBLLQYPXQWk7dm7iA/WzQX2ErE69He2h1mpb8VMeScUs7TMhn1U0l1wflJHRC88xGQ/t5KOYWnlfgwU+fswjnkUPklIhPkvIVoI6MoUrBdKX7OrkTG3Bxaag+c/IMICCDFwcBhSVT3HVF5DjWx65odf+TTPjzorK6kylzQ4UzIZABabmgqubCXm4bM2bq26mkQa7UevT7jNeV70Iq/jp3oMkw= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2017 18:42:13.8731 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0101MB1029 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 18:42:19 -0000 On 15 Jul 2017, at 1:01, Melinda Shore wrote: > It might make sense to kick it over to ops for a discussion with > people whose meat and potatoes is monitoring, management, and > measurement. As someone who is ops-focused, I think this is an excellent suggestion! There have been several assertions posted to the list recently regarding various aspects of security and their intersection with encryption. It may be useful to take a moment and clarify a few of them. With regards to DDoS mitigation as it relates to encrypted attack traffic, only a subset of attacks in a subset of situations can actually be adequately mitigated without full visibility into (and often the ability to interact with) the traffic within the cryptostream. There are various ways to approach this issue, including full session termination and 'transparent' detection/classification, the latter of which isn't of course feasible in a PFS scenario. Each of these general approaches has its advantages and drawbacks. Very specifically, fingerprints of encrypted streams are not in fact adequate for DDoS defense; again, they're only useful for a subset of attack types in a subset of situations. In the case of detecting and classifying hostile activity within a given network - which isn't limited to malware spreading, but includes data extraction, attempts at unauthorized access, attempts at subverting additional devices, et. al. - the same basic caveats apply. It is not in fact possible to adequately detect and classify all, or even a large subset, of hostile network traffic without visibility into the cryptostream. There are some gross behaviors which can be detected/classified whilst standing outside the tunnel, but assertions to the effect that all or most of what's required in this arena is possible without visibility (one way or another) into the relevant encrypted traffic are incorrect. It's also important to understand that inserting proxies into multiple points of a network topology is not cost-free, nor an unalloyed good. It is impractical in many circumstances, and has highly unwelcome side-effects in many more, including a negative impact on reliability, performance, and availability, as well as broadening the potential attack surface. Endpoint monitoring does not scale well, is often impossible to implement due to both technical and administrative challenges - and one can't really trust endpoints to self-report, anyways, as they can be subverted. In many scenarios, one form or another of network-based visibility into encrypted traffic streams within the span of administrative control of a single organization is legitimate, vital and necessary. It is not 'wiretapping', any more than tools such as tcpdump or telemetry formats such as IPFIX and PSAMP can be categorized as 'wiretapping'. The fact is, the availability, confidentiality, and integrity of systems, applications, and networks that everyone on this list relies upon is highly dependent upon the ability of organizations to have visibility into encrypted traffic streams within their own networks, for purposes of security as well as testing and troubleshooting. How this can be accomplished is a matter for further discussion. But it's important that everyone focused on this topic understands that it is simply not possible to successfully defend against many forms of DDoS attacks nor to detect and classify hostile network traffic in the context of encrypted communications without visibility into the traffic in question, via some mechanism. The same goes for troubleshooting complex problems. Those with operational experience at scale will likely recognize and acknowledge the difficulties and challenges noted above; others may wish to consider these factors and their impact on the operational community and the networks, services, and applications for which they are responsible, and upon which we all depend, every day. ----------------------------------- Roland Dobbins From nobody Fri Jul 14 11:55:26 2017 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 E11A2131760 for ; Fri, 14 Jul 2017 11:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 wSb1BGdaOo1o for ; Fri, 14 Jul 2017 11:55:23 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4CC131548 for ; Fri, 14 Jul 2017 11:55:23 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 7DF2EC0028AC; Fri, 14 Jul 2017 11:55:23 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 17868C0028A9; Fri, 14 Jul 2017 11:55:23 -0700 (PDT) Date: Fri, 14 Jul 2017 13:55:19 -0500 From: Nico Williams To: Ted Lemon Cc: "Blumenthal, Uri - 0553 - MITLL" , "" Message-ID: <20170714185518.GB2926@localhost> References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.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] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 18:55:25 -0000 On Fri, Jul 14, 2017 at 07:10:47PM +0200, Ted Lemon wrote: > I have two working groups already in the monday slot. I doubt I'm unique > in this. It seems like you should put the important business in the slot > that was previously scheduled, and the overflow into the Monday slot. > It's hard to imagine how a discussion of the wiretapping thing could be > anything other than a dance at the mic, full of sound and fury, signifying > nothing. +1 At some point decisions have to be made though, and someone will end up on the rough side of consensus in the WG. There could be (will be!) appeals. Lastly, the IESG could also decline to allow such a WG item to get published. This would all be much easier if the authors would just go the ISE Informational route. Then only the IESG needs to decide anything -- either way the IESG will be the last stop for this train. Better skip the Q/A at the WG meeting -- it makes no difference as to determining consensus, and no one needs the other side screaming bloody murder and judging one a moron or evil. It won't be worthy of popcorn. Just boring, oh so boring. Nico -- From nobody Fri Jul 14 12:15:24 2017 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 421491316A8 for ; Fri, 14 Jul 2017 12:15:23 -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=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 567SwoWSifci for ; Fri, 14 Jul 2017 12:15:21 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 17F41131690 for ; Fri, 14 Jul 2017 12:15:21 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id j186so49742961pge.2 for ; Fri, 14 Jul 2017 12:15:21 -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=UePewbRvoDVav4WwzV0ZHk0hkOLnxMEUDnjLP1Ws570=; b=OdWgTey1GIua+tFxFJ4AFEhAfw5LOsWClh11rv8OywEIqIlnUMVv349y1Zwr+L28mg Bu/7rh5yx3MQqkLFsk6WvfHFcWZWR+u0toTTsBk+QKOKys0QO7Z2tFnTInGq0lEj5O6E 5+WKq3zKF/Oh16j82eeMRhL8Hxl0NleR7dob6mh6OTsl+l3jBy6Z8PIm6+d8fHnb0UE3 giRQulvPyhfaKJVu5ZvtJs/cVcNW8qFE5W/wYn+DfkrV+OIIYsmIcPxUkBL5Qn3UN8D8 OPvWNb5Rbfx2O83NkRFeaka9fWX+Y20EN0r+l1zOAWsCYURs+kOTjLNccN5HiNWao9CQ dYXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UePewbRvoDVav4WwzV0ZHk0hkOLnxMEUDnjLP1Ws570=; b=R74h78v6/OUEb0dwRsd2lS2aqPVsFW7/2vA5YqiAk9uLxCvgz8O4G9NdAhZTpmUALV fWcfPVX9kN6cLk6Rac0uB2iDhnli7Oi8g5HhwXITTKnZvxBmHfdhpFFpiO4iDE0YO8td LQpYVbRbsTOndZ6XTv9TGgwsTn1HnCnzi1hHIQ2CdguV6wtS1b60AgtYx/xs6p86e1hD LhO/Kmupv+s9jk/HHOarBaKE8asBSfYQUMqpLsB5l23juTr4cHLWSOC/EKO/Qyc8gncP 1u/D2TckUBA0qoTCeBTZRCOZ6kwsZSfsPyUvT+tEK6mj2IncFomD4QTQLcL3hop9eaas Hv1w== X-Gm-Message-State: AIVw110YbjryLmiz+j0Lzf2LOWu4V+ouwIIugxWxklwQSB+yvujmX83p FnxHLr64kBcfhh1KhLe/C8fGnAH9Blap X-Received: by 10.99.105.4 with SMTP id e4mr16787315pgc.228.1500059720529; Fri, 14 Jul 2017 12:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Fri, 14 Jul 2017 12:15:19 -0700 (PDT) Received: by 10.100.181.42 with HTTP; Fri, 14 Jul 2017 12:15:19 -0700 (PDT) In-Reply-To: <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> From: Ted Lemon Date: Fri, 14 Jul 2017 21:15:19 +0200 Message-ID: To: Roland Dobbins Cc: "" Content-Type: multipart/alternative; boundary="94eb2c140dcec8cee905544bde94" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 19:15:23 -0000 --94eb2c140dcec8cee905544bde94 Content-Type: text/plain; charset="UTF-8" It seems to me that all the use cases you just described require the *client* to have a static key, since the client is the thing that the operator controls. If the client uses an unknown key, is malware or unauthorized. On Jul 14, 2017 20:42, "Roland Dobbins" wrote: > On 15 Jul 2017, at 1:01, Melinda Shore wrote: > > It might make sense to kick it over to ops for a discussion with people >> whose meat and potatoes is monitoring, management, and >> measurement. >> > > As someone who is ops-focused, I think this is an excellent suggestion! > > There have been several assertions posted to the list recently regarding > various aspects of security and their intersection with encryption. It may > be useful to take a moment and clarify a few of them. > > With regards to DDoS mitigation as it relates to encrypted attack traffic, > only a subset of attacks in a subset of situations can actually be > adequately mitigated without full visibility into (and often the ability to > interact with) the traffic within the cryptostream. There are various ways > to approach this issue, including full session termination and > 'transparent' detection/classification, the latter of which isn't of course > feasible in a PFS scenario. Each of these general approaches has its > advantages and drawbacks. > > Very specifically, fingerprints of encrypted streams are not in fact > adequate for DDoS defense; again, they're only useful for a subset of > attack types in a subset of situations. > > In the case of detecting and classifying hostile activity within a given > network - which isn't limited to malware spreading, but includes data > extraction, attempts at unauthorized access, attempts at subverting > additional devices, et. al. - the same basic caveats apply. It is not in > fact possible to adequately detect and classify all, or even a large > subset, of hostile network traffic without visibility into the > cryptostream. There are some gross behaviors which can be > detected/classified whilst standing outside the tunnel, but assertions to > the effect that all or most of what's required in this arena is possible > without visibility (one way or another) into the relevant encrypted traffic > are incorrect. > > It's also important to understand that inserting proxies into multiple > points of a network topology is not cost-free, nor an unalloyed good. It > is impractical in many circumstances, and has highly unwelcome side-effects > in many more, including a negative impact on reliability, performance, and > availability, as well as broadening the potential attack surface. Endpoint > monitoring does not scale well, is often impossible to implement due to > both technical and administrative challenges - and one can't really trust > endpoints to self-report, anyways, as they can be subverted. > > In many scenarios, one form or another of network-based visibility into > encrypted traffic streams within the span of administrative control of a > single organization is legitimate, vital and necessary. It is not > 'wiretapping', any more than tools such as tcpdump or telemetry formats > such as IPFIX and PSAMP can be categorized as 'wiretapping'. The fact is, > the availability, confidentiality, and integrity of systems, applications, > and networks that everyone on this list relies upon is highly dependent > upon the ability of organizations to have visibility into encrypted traffic > streams within their own networks, for purposes of security as well as > testing and troubleshooting. > > How this can be accomplished is a matter for further discussion. But it's > important that everyone focused on this topic understands that it is simply > not possible to successfully defend against many forms of DDoS attacks nor > to detect and classify hostile network traffic in the context of encrypted > communications without visibility into the traffic in question, via some > mechanism. The same goes for troubleshooting complex problems. > > Those with operational experience at scale will likely recognize and > acknowledge the difficulties and challenges noted above; others may wish to > consider these factors and their impact on the operational community and > the networks, services, and applications for which they are responsible, > and upon which we all depend, every day. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c140dcec8cee905544bde94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems to me that all the use cases you just described = require the client=C2=A0to have a static key, since the client is th= e thing that the operator controls. If the client uses an unknown key, is m= alware or unauthorized.=C2=A0

On Jul 14, 2017 20:42, "Roland Dobbins" <rdobbins@arbor.net> wrote:
On 15 Jul 2017, at 1:01, M= elinda Shore wrote:

It might make sense to kick it over to ops for a discussion with people who= se meat and potatoes is monitoring, management, and
measurement.

As someone who is ops-focused, I think this is an excellent suggestion!

There have been several assertions posted to the list recently regarding va= rious aspects of security and their intersection with encryption.=C2=A0 It = may be useful to take a moment and clarify a few of them.

With regards to DDoS mitigation as it relates to encrypted attack traffic, = only a subset of attacks in a subset of situations can actually be adequate= ly mitigated without full visibility into (and often the ability to interac= t with) the traffic within the cryptostream.=C2=A0 There are various ways t= o approach this issue, including full session termination and 'transpar= ent' detection/classification, the latter of which isn't of course = feasible in a PFS scenario.=C2=A0 Each of these general approaches has its = advantages and drawbacks.

Very specifically, fingerprints of encrypted streams are not in fact adequa= te for DDoS defense; again, they're only useful for a subset of attack = types in a subset of situations.

In the case of detecting and classifying hostile activity within a given ne= twork - which isn't limited to malware spreading, but includes data ext= raction, attempts at unauthorized access, attempts at subverting additional= devices, et. al. - the same basic caveats apply.=C2=A0 It is not in fact p= ossible to adequately detect and classify all, or even a large subset, of h= ostile network traffic without visibility into the cryptostream.=C2=A0 Ther= e are some gross behaviors which can be detected/classified whilst standing= outside the tunnel, but assertions to the effect that all or most of what&= #39;s required in this arena is possible without visibility (one way or ano= ther) into the relevant encrypted traffic are incorrect.

It's also important to understand that inserting proxies into multiple = points of a network topology is not cost-free, nor an unalloyed good.=C2=A0= It is impractical in many circumstances, and has highly unwelcome side-eff= ects in many more, including a negative impact on reliability, performance,= and availability, as well as broadening the potential attack surface.=C2= =A0 Endpoint monitoring does not scale well, is often impossible to impleme= nt due to both technical and administrative challenges - and one can't = really trust endpoints to self-report, anyways, as they can be subverted.
In many scenarios, one form or another of network-based visibility into enc= rypted traffic streams within the span of administrative control of a singl= e organization is legitimate, vital and necessary.=C2=A0 It is not 'wir= etapping', any more than tools such as tcpdump or telemetry formats suc= h as IPFIX and PSAMP can be categorized as 'wiretapping'.=C2=A0 The= fact is, the availability, confidentiality, and integrity of systems, appl= ications, and networks that everyone on this list relies upon is highly dep= endent upon the ability of organizations to have visibility into encrypted = traffic streams within their own networks, for purposes of security as well= as testing and troubleshooting.

How this can be accomplished is a matter for further discussion.=C2=A0 But = it's important that everyone focused on this topic understands that it = is simply not possible to successfully defend against many forms of DDoS at= tacks nor to detect and classify hostile network traffic in the context of = encrypted communications without visibility into the traffic in question, v= ia some mechanism.=C2=A0 The same goes for troubleshooting complex problems= .

Those with operational experience at scale will likely recognize and acknow= ledge the difficulties and challenges noted above; others may wish to consi= der these factors and their impact on the operational community and the net= works, services, and applications for which they are responsible, and upon = which we all depend, every day.

-----------------------------------
Roland Dobbins <= rdobbins@arbor.net>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--94eb2c140dcec8cee905544bde94-- From nobody Fri Jul 14 12:25:37 2017 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 42D0E13175F for ; Fri, 14 Jul 2017 12:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 O9LktRuCdME3 for ; Fri, 14 Jul 2017 12:25:34 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 03A58131457 for ; Fri, 14 Jul 2017 12:25:33 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6EJOO7L034919; Fri, 14 Jul 2017 15:25:31 -0400 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Blumenthal, Uri - 0553 - MITLL" In-Reply-To: <20170714185518.GB2926@localhost> Date: Fri, 14 Jul 2017 15:25:26 -0400 CC: Ted Lemon , "" Content-Transfer-Encoding: quoted-printable Message-ID: <32E7F7C7-6D6B-47D2-8A3C-7176B1FE8327@ll.mit.edu> References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> <20170714185518.GB2926@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3273) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707140309 Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 19:25:35 -0000 > ... the IESG could also decline to allow such a WG item to > get published. =20 That=E2=80=99s what I=E2=80=99d expect and hope for. > Better skip the Q/A at the WG meeting -- it makes no difference as to > determining consensus, +1 > and no one needs the other side screaming bloody > murder and judging one a moron or evil. =20 I thought the judgment has already been made? ;-) P.S. I assume the =E2=80=9Cor=E2=80=9D above is an =E2=80=9Cinclusive = or=E2=80=9D? ;-)= From nobody Fri Jul 14 12:51:42 2017 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 23D2C131559 for ; Fri, 14 Jul 2017 12:51:42 -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 VVkg4R7XbV5d for ; Fri, 14 Jul 2017 12:51:40 -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 11EDB131465 for ; Fri, 14 Jul 2017 12:51:40 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id d78so83643096qkb.1 for ; Fri, 14 Jul 2017 12:51:39 -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:cc :content-transfer-encoding:message-id:references:to; bh=uy5oJcnx97+8DzF8BPtC8+lrhf+ms8FdlYz6sabVWvM=; b=W3jsyGw5EeB2EFtwhxJaiycmbRqR7YKslPn2uz0FMVB2rVxKlYk0hk1EFnntU7EL/2 Jb4I3W2W0PtgBlQsersVzSuwcCG9jbiblC7pr7ZD9mDPO0Ctd7WSs45uW5mTRUE4IRgC H3Mu8Q9tiEzJvp7aCFtDiEt8OZmiHymj5bGKU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uy5oJcnx97+8DzF8BPtC8+lrhf+ms8FdlYz6sabVWvM=; b=Det5CH754X94uf66Y10cyCqF4Gy18nGTdondPAFMO28xV8+P0bHa/cVyyPSFFrg5/z H5M3mSeNsRQrAt6lZ6D6ixifTwOBPyibuZAtdfdkOF/F4J4x8v8EwmqKOPW/0YrW0ExL gtodQYn3V2CpOSEa2ZXD3GcnqTYoW5yI6r+N12yQOiugTnJWfScd/fwQLJxXJSBDerse xR9/xd+b5LwA9zCo3fOylaed8l+G/5xt+S+jwMaS9EgvMaksLZd4QvXRlGZSpDdiUdwq zWjr5oBotVwfljrBYtNBYRPit2KEFLhZ2KtgcYFvE6fkQKY1IHjqzosy/es2OtRQQ0/Q Mn8g== X-Gm-Message-State: AIVw113Wh0nCLkXFuflDBSgpPuGdlt1s/eHqHm4Fmok1nHzFB9Q4XXoR tKpxHn+ltf5V2k17 X-Received: by 10.55.60.13 with SMTP id j13mr14146741qka.71.1500061899120; Fri, 14 Jul 2017 12:51:39 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.165]) by smtp.gmail.com with ESMTPSA id w72sm7270081qka.63.2017.07.14.12.51.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 12:51:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <89DFCCB3-69E6-4323-A080-67FD9799B7AA@ll.mit.edu> Date: Fri, 14 Jul 2017 15:51:35 -0400 Cc: Ted Lemon , "" Content-Transfer-Encoding: quoted-printable Message-Id: <3CE0375B-CD87-4271-B7B5-FCD74702FAF5@sn3rd.com> References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> <89DFCCB3-69E6-4323-A080-67FD9799B7AA@ll.mit.edu> To: "Blumenthal, Uri - 0553 - MITLL" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 19:51:42 -0000 And by the important business I was referring to the TLS and DTLS = drafts. spt > On Jul 14, 2017, at 13:22, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > I will be perfectly happy not allocating any time at all for the = wiretapping presentation. >=20 > I would not call the discussed draft "the important business" - for me = it's anything but that.=20 >=20 > Regards, > Uri >=20 > Sent from my iPhone >=20 > On Jul 14, 2017, at 13:11, Ted Lemon wrote: >=20 >> I have two working groups already in the monday slot. I doubt I'm = unique in this. It seems like you should put the important business in = the slot that was previously scheduled, and the overflow into the Monday = slot. It's hard to imagine how a discussion of the wiretapping thing = could be anything other than a dance at the mic, full of sound and fury, = signifying nothing. >>=20 >> On Fri, Jul 14, 2017 at 5:13 PM, Blumenthal, Uri - 0553 - MITLL = wrote: >> +1 >>=20 >> Current agenda does look backwards. IMHO, do as Stephen suggested. >>=20 >> Regards, >> Uri >>=20 >> Sent from my iPhone >>=20 >> > On Jul 14, 2017, at 11:10, Stephen Farrell = wrote: >> > >> > >> > Hiya, >> > >> >> On 14/07/17 15:51, Sean Turner wrote: >> >> Please let us know your thoughts. >> > >> > 80 minutes for wiretapping is too much. Zero would >> > be better. But if not... >> > >> > I'd suggest: 10 minutes for draft-green, 10 minutes >> > to describe issues with that (i.e. the slot for which >> > I continue to ask) and then 10 minutes discussion. If >> > we assume the folks in the room have read the list and >> > the draft that should be plenty. >> > >> > If we assume they haven't read the list, then it's more >> > important that the counter-arguments be given sufficient >> > time. >> > >> > So your draft agenda seems to get that backwards to me, >> > in that it allocates 40 minutes for a sales-pitch and >> > then 40 minutes where we bitch about that at the mic >> > interspersed with proponents repeating bits of the sales >> > pitch. That might be more amusing for us all, but seems >> > like a worse use of time to me. >> > >> > Cheers, >> > S. >> > >> > >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jul 14 12:53:53 2017 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 4356613191C for ; Fri, 14 Jul 2017 12:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 uANCZ4jzV55W for ; Fri, 14 Jul 2017 12:53:50 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id D0E18131559 for ; Fri, 14 Jul 2017 12:53:49 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6EJrmkt003095; Fri, 14 Jul 2017 15:53:48 -0400 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Blumenthal, Uri - 0553 - MITLL" In-Reply-To: <3CE0375B-CD87-4271-B7B5-FCD74702FAF5@sn3rd.com> Date: Fri, 14 Jul 2017 15:53:47 -0400 CC: Ted Lemon , "" Content-Transfer-Encoding: quoted-printable Message-ID: <4EFDA2BD-F7C9-473B-9B6B-0422B0EC3DD1@ll.mit.edu> References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> <89DFCCB3-69E6-4323-A080-67FD9799B7AA@ll.mit.edu> <3CE0375B-CD87-4271-B7B5-FCD74702FAF5@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3273) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707140312 Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 19:53:51 -0000 On Jul 14, 2017, at 15:51, Sean Turner wrote: >=20 > And by the important business I was referring to the TLS and DTLS = drafts. My apology. We=E2=80=99re in agreement then. From nobody Fri Jul 14 13:08:36 2017 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 8DB1313191C for ; Fri, 14 Jul 2017 13:08:34 -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 T6diBn0VmDzM for ; Fri, 14 Jul 2017 13:08:33 -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 55BB7131780 for ; Fri, 14 Jul 2017 13:08:33 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id a66so70246021qkb.0 for ; Fri, 14 Jul 2017 13:08:33 -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:cc :content-transfer-encoding:message-id:references:to; bh=QUTWK+Lop2YvzGs51G5UQxfUpR3c4Pctr0zZAWk8arw=; b=ND/38lhteAbt55rPcWBQRzQmPu/jkKSO39jrnEybabISdBNYkJTEI5Uc0xWzlUONAy 7EgyAAt8BYPMuS9HyUk9+xq+sDeLjAnx+E1FoVP4IonHUxwjPM7TrW8uy6B6rRvQyYOr zfBvDLkWHy6w+BbmVpD76K0nhrl84paHglh7I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QUTWK+Lop2YvzGs51G5UQxfUpR3c4Pctr0zZAWk8arw=; b=Eh1rLS6qZyzRf1+8U8Qmw/Dl/vyMePRaidV9/C3WkinYEodZbRqZ+2leNQb2Sn7PzX AodcOvADaX/cMOuhPO/UKgMvpAGyFSPHRANYjD9t+AC49kp7W6XfUYJBmCGCEwBIlUpW yCk/ax5RHQy6qwq6ou6y0XEI7BCtCkpxMBwYZxEH3ZCXxrgS3ffVgmOmL3Iplu5NkpaT Jc7X85YyyW/nAJG2Bx3/jInirJovxlTfKu08YrL4E4qvJ8f447/iGHpV4P29y0q46Yn9 QJWavEWLNke12rf7zIJwTzHgphoppJUKZ2LDHDRgzwG62eT1H5tiHOymG+g64OXik4qU n9aQ== X-Gm-Message-State: AIVw113PXPKK25gvsVqaz6JuGMd/E2vwqQhm6ojJCf+WeaXBqbfVroUb qs/fcVI7389s7hX5 X-Received: by 10.55.147.3 with SMTP id v3mr13218382qkd.149.1500062912577; Fri, 14 Jul 2017 13:08:32 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.165]) by smtp.gmail.com with ESMTPSA id j7sm7347143qtb.60.2017.07.14.13.08.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 13:08:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <4EFDA2BD-F7C9-473B-9B6B-0422B0EC3DD1@ll.mit.edu> Date: Fri, 14 Jul 2017 16:08:29 -0400 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> <89DFCCB3-69E6-4323-A080-67FD9799B7AA@ll.mit.edu> <3CE0375B-CD87-4271-B7B5-FCD74702FAF5@sn3rd.com> <4EFDA2BD-F7C9-473B-9B6B-0422B0EC3DD1@ll.mit.edu> To: "Blumenthal, Uri - 0553 - MITLL" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 20:08:34 -0000 > On Jul 14, 2017, at 15:53, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > On Jul 14, 2017, at 15:51, Sean Turner wrote: >>=20 >> And by the important business I was referring to the TLS and DTLS = drafts. >=20 > My apology. We=E2=80=99re in agreement then. No worries I should have been more explicit. spt= From nobody Fri Jul 14 13:35:31 2017 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 EBE161316E5 for ; Fri, 14 Jul 2017 13:35:29 -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=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 fRusFIxDaqrR for ; Fri, 14 Jul 2017 13:35:28 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6897A131563 for ; Fri, 14 Jul 2017 13:35:28 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id r126so52672645vkg.0 for ; Fri, 14 Jul 2017 13:35:28 -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:content-transfer-encoding; bh=I8zxWMcPUlfNDYu80F0luxAwC/O6cRW/M6OOgCx6W1A=; b=eA+ItXIagP1O7v1Sad4ffEx+9ml7o9grSOz2cln0WMHvVhcr1IYJsEG3j76EyjbDfv EQcP8AaTJoCXhgMug+lIkNyLHUWtz30BIsZsSgP58iRfD3RhoG9481aEDcAs9VsHqfxG q4GfBvy3cSp4nKEm7Ht30XiRuiBk/uXrqL4W4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=I8zxWMcPUlfNDYu80F0luxAwC/O6cRW/M6OOgCx6W1A=; b=PyBgNWu53cLTBwx7slELDBvCNNzv07ZA0LFk5vSFWCLVrWkCUVABT/zEqzAYSZ4PBN vApsyEaU4BZAOBKP+Ukx9a6iG6NQ0pdD7ctxYLcWjXYZkrY+sWwWovr0ecfivUs1bIet e+lIVPfgcgx3p6fHlV52l1BtEEYCVW2KgjQMBjSeKBatTg+i7qV9Kfyr8LKna9X1cYrP e+QDuR3Ja/dcWqcPeyjyJp/bSfNfB/YBlj07AFmOHCUR89P0O4YcZwOYyZVoSLrTdol6 Hcs9/suA6bRX5y/3kz8N/UwIJ0K+NEB6Bc6wtVBllmTz4smXbV8qKbV/WgA+nw4qIqWE L+AQ== X-Gm-Message-State: AIVw112bDXnql5k8hgEX4B4GgBqXifiufvG1GvvWzdcsNnY+xGYQX8o5 ew+AQj22Sep1JAEIVg8E/qITt2G9nxvH X-Received: by 10.31.16.22 with SMTP id g22mr6532750vki.46.1500064527270; Fri, 14 Jul 2017 13:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.80.198 with HTTP; Fri, 14 Jul 2017 13:35:06 -0700 (PDT) In-Reply-To: References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> <89DFCCB3-69E6-4323-A080-67FD9799B7AA@ll.mit.edu> <3CE0375B-CD87-4271-B7B5-FCD74702FAF5@sn3rd.com> <4EFDA2BD-F7C9-473B-9B6B-0422B0EC3DD1@ll.mit.edu> From: Joseph Lorenzo Hall Date: Fri, 14 Jul 2017 16:35:06 -0400 Message-ID: To: Sean Turner Cc: "Blumenthal, Uri - 0553 - MITLL" , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 20:35:30 -0000 Sean, can you let us know what room the new session will be in when you know? (Not on the agenda.) On Fri, Jul 14, 2017 at 4:08 PM, Sean Turner wrote: > >> On Jul 14, 2017, at 15:53, Blumenthal, Uri - 0553 - MITLL wrote: >> >> On Jul 14, 2017, at 15:51, Sean Turner wrote: >>> >>> And by the important business I was referring to the TLS and DTLS draft= s. >> >> My apology. We=E2=80=99re in agreement then. > > No worries I should have been more explicit. > > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 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 Fri Jul 14 14:01:34 2017 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 8B42813189C for ; Fri, 14 Jul 2017 14:01: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, 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 MTr65qtEZb1E for ; Fri, 14 Jul 2017 14:01:31 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3473C12EA74 for ; Fri, 14 Jul 2017 14:01:31 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id 62so30145846wmw.1 for ; Fri, 14 Jul 2017 14:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jv0lCpQnZAGNvcAFzfOIt/XKf+lJJkCaxkqP01TxZhs=; b=RbRI6mLNeYyK5vIBJHg/VQJEIAFMfrvB4ke0jNYeP8jHYpHU4+hinJDCAtkhV6WEAl b6+aW1PL6Qz2c08QIby1NNMVsHd7OZU1kjI4c7cULVjlnLfJJGmDWGwS3JwnRbDT/75W 2KD+vZc1ZLzZRi+Pe7sPlNargNdYG+vHNc/nxldzS9clFF4P50oUHADi2vhu/Maa+OV9 J3bRu8HdHh19AqENfWsUDEn6kOwSGQhsfGD7xSdbcoNtHowzxRmYgECgtbUU8hcvIJd8 x7mEPKpDPQliU938okWkeajbgPZHfBsB0KR3pBHjBVn8nMq7ksAFWchk+BTmsxmiAbyC TO5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jv0lCpQnZAGNvcAFzfOIt/XKf+lJJkCaxkqP01TxZhs=; b=NcIvF/TH2TaBbaDPsi1UoYxGJobk35hsZbtcrh991iTJcWR0WiPJuKWqG+sqiYwZCD PD9v5EOORU5U3dVQKkvy12g1BxN62zOwYSrDA/c56VrEzk3EpLWWzAPsJI5IQZJIMNbn 6qhWCkUJoFctSfPb33ifetKyD8CMBkKK5BYZpmaioViF6240nxiccbd8r0wegLdyLCpz eVYRfT64USJznQmyJWWExsPUXraTwSjY+HzN3uFvqetzK0tBuJbRFFBGjSHgaJ7H/Xpi vwE087J7+2dEgtuMkSzyD+fH7OgycN32bqFX18FITkcoZgtQXsKtBtxIhpKUHczOcFPA OdSg== X-Gm-Message-State: AIVw113zsuKpTzlN4CaM9hJUto0iWjLaJxBSfD6WaW0+u/lfqBauy1DL y0r+gzU3SPX599dJgyI= X-Received: by 10.28.147.137 with SMTP id v131mr4205074wmd.98.1500066089227; Fri, 14 Jul 2017 14:01:29 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:2dfc:340f:9a86:e0c9? ([2001:67c:1232:144:2dfc:340f:9a86:e0c9]) by smtp.gmail.com with ESMTPSA id z108sm10040459wrb.41.2017.07.14.14.01.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 14:01:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> Date: Fri, 14 Jul 2017 23:01:26 +0200 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <31FB06FE-F2A5-4A15-B896-D0FEBECCC6D4@gmail.com> References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> To: Roland Dobbins Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 21:01:34 -0000 Hi Roland, It sounds like you misread my messages and should read them in context of TL= S 1.3 and the draft using DH static keys proposed to help with monitoring. Best regards, Kathleen=20 Sent from my iPhone > On Jul 14, 2017, at 8:41 PM, Roland Dobbins wrote: >=20 >> On 15 Jul 2017, at 1:01, Melinda Shore wrote: >>=20 >> It might make sense to kick it over to ops for a discussion with people w= hose meat and potatoes is monitoring, management, and >> measurement. >=20 > As someone who is ops-focused, I think this is an excellent suggestion! >=20 > There have been several assertions posted to the list recently regarding v= arious aspects of security and their intersection with encryption. It may b= e useful to take a moment and clarify a few of them. >=20 > With regards to DDoS mitigation as it relates to encrypted attack traffic,= only a subset of attacks in a subset of situations can actually be adequate= ly mitigated without full visibility into (and often the ability to interact= with) the traffic within the cryptostream. There are various ways to appro= ach this issue, including full session termination and 'transparent' detecti= on/classification, the latter of which isn't of course feasible in a PFS sce= nario. Each of these general approaches has its advantages and drawbacks. >=20 > Very specifically, fingerprints of encrypted streams are not in fact adequ= ate for DDoS defense; again, they're only useful for a subset of attack type= s in a subset of situations. >=20 > In the case of detecting and classifying hostile activity within a given n= etwork - which isn't limited to malware spreading, but includes data extract= ion, attempts at unauthorized access, attempts at subverting additional devi= ces, et. al. - the same basic caveats apply. It is not in fact possible to a= dequately detect and classify all, or even a large subset, of hostile networ= k traffic without visibility into the cryptostream. There are some gross be= haviors which can be detected/classified whilst standing outside the tunnel,= but assertions to the effect that all or most of what's required in this ar= ena is possible without visibility (one way or another) into the relevant en= crypted traffic are incorrect. >=20 > It's also important to understand that inserting proxies into multiple poi= nts of a network topology is not cost-free, nor an unalloyed good. It is im= practical in many circumstances, and has highly unwelcome side-effects in ma= ny more, including a negative impact on reliability, performance, and availa= bility, as well as broadening the potential attack surface. Endpoint monito= ring does not scale well, is often impossible to implement due to both techn= ical and administrative challenges - and one can't really trust endpoints to= self-report, anyways, as they can be subverted. >=20 > In many scenarios, one form or another of network-based visibility into en= crypted traffic streams within the span of administrative control of a singl= e organization is legitimate, vital and necessary. It is not 'wiretapping',= any more than tools such as tcpdump or telemetry formats such as IPFIX and P= SAMP can be categorized as 'wiretapping'. The fact is, the availability, co= nfidentiality, and integrity of systems, applications, and networks that eve= ryone on this list relies upon is highly dependent upon the ability of organ= izations to have visibility into encrypted traffic streams within their own n= etworks, for purposes of security as well as testing and troubleshooting. >=20 > How this can be accomplished is a matter for further discussion. But it's= important that everyone focused on this topic understands that it is simply= not possible to successfully defend against many forms of DDoS attacks nor t= o detect and classify hostile network traffic in the context of encrypted co= mmunications without visibility into the traffic in question, via some mecha= nism. The same goes for troubleshooting complex problems. >=20 > Those with operational experience at scale will likely recognize and ackno= wledge the difficulties and challenges noted above; others may wish to consi= der these factors and their impact on the operational community and the netw= orks, services, and applications for which they are responsible, and upon wh= ich we all depend, every day. >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jul 14 14:31:20 2017 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 98DBF12EC44 for ; Fri, 14 Jul 2017 14:31:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 HocL7dqAg_Jv for ; Fri, 14 Jul 2017 14:31:17 -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 A3384129B10 for ; Fri, 14 Jul 2017 14:31:17 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 32so72020525qtv.1 for ; Fri, 14 Jul 2017 14:31:17 -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:cc :content-transfer-encoding:message-id:references:to; bh=hVKVPfaKUD1SXqlVLeqXx4M5f/NIDL3NlWKKBCCu/6g=; b=SpYCd2tPZPxVn6S7k1M8DeTfREflpM5hG6I/SCNJT1soQXphZNWNFbChP3S+x8LDuI E1U9DJIAowItokYw7Islv+KDupUPIbtir8K0+6AB2aI5pLPFd7FljWdaLNHtODnv61j2 M7iw2JKCPyhr8N9jPATYBgYrPZl0+PZqGgVOw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hVKVPfaKUD1SXqlVLeqXx4M5f/NIDL3NlWKKBCCu/6g=; b=Vu1JhsKUH8OBZj5DJeC0X+Oe83qF64HHvmEheZttPm4n+PoK+1jy+90JNyh6i+lTR+ nPba1hLldJZUG3sbF6c/48YJ/Moap3+v5HMhUstfC3dlfJqdC2zpZ3V+u5fwCn0y2rkh fkfegqCk6WLY2AoTmSfrjAuTgbTlrSoP6uCB9r1L7QdsgK0nb3bqzv6gUEoBDhevrhum Jyd8xlJNBct3MnEa9KmxsA70yZaDtQqI0BDVqMNeH5maElshvL4Fk6424nmc/yq++Lev ZUcD8kh+UECsLvSlMDesgjb21mh2LQqzLOXlMAnY+cJCW5vOuQc7tZILhT+9YYtmoAGK Z1Tw== X-Gm-Message-State: AIVw112P4/Czlu3MZ/oVPllC10w9USGKySRC0eLNdJIgCJ921DqJE6y5 62BJx4b2b9g5749I X-Received: by 10.237.53.79 with SMTP id b15mr14283208qte.83.1500067876870; Fri, 14 Jul 2017 14:31:16 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.165]) by smtp.gmail.com with ESMTPSA id w8sm7792304qtb.53.2017.07.14.14.31.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 14:31:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Fri, 14 Jul 2017 17:31:13 -0400 Cc: "Blumenthal, Uri - 0553 - MITLL" , "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> <89DFCCB3-69E6-4323-A080-67FD9799B7AA@ll.mit.edu> <3CE0375B-CD87-4271-B7B5-FCD74702FAF5@sn3rd.com> <4EFDA2BD-F7C9-473B-9B6B-0422B0EC3DD1@ll.mit.edu> To: Joseph Lorenzo Hall X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2017 21:31:19 -0000 The Secretariat is going to put out a revised IETF agenda tomorrow. I = suspect we=E2=80=99ll be in the room that was allocated to RTCweb. spt > On Jul 14, 2017, at 16:35, Joseph Lorenzo Hall wrote: >=20 > Sean, can you let us know what room the new session will be in when > you know? (Not on the agenda.) >=20 > On Fri, Jul 14, 2017 at 4:08 PM, Sean Turner wrote: >>=20 >>> On Jul 14, 2017, at 15:53, Blumenthal, Uri - 0553 - MITLL = wrote: >>>=20 >>> On Jul 14, 2017, at 15:51, Sean Turner wrote: >>>>=20 >>>> And by the important business I was referring to the TLS and DTLS = drafts. >>>=20 >>> My apology. We=E2=80=99re in agreement then. >>=20 >> No worries I should have been more explicit. >>=20 >> spt >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 > --=20 > 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 Fri Jul 14 18:40:05 2017 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 5320812EC1D for ; Fri, 14 Jul 2017 18:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 b0WhnxnZpUJg for ; Fri, 14 Jul 2017 18:40:02 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 26B27126B72 for ; Fri, 14 Jul 2017 18:40:02 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id q86so52669152pfl.3 for ; Fri, 14 Jul 2017 18:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=SZPJDkExKOYCY2IPPHeZK5XqUUNA32t1hp69KRfbxAg=; b=EZ2NZFYkLusHezIENfv4DLBvFbNJghZaR+jzu3gNtmSVMhJ5l2rGMAUddF5hOl40rT MI7I/6RzJefAZR3xcbHT47QQ0v3ML2o1ncHNZd7239SAzkJN0kwDqmODm7b0pqoWa9s3 QpVla5ojj280Yv4Qo3n2xVD1Z4KPsO1Qc2FQLSr98nhLqtrdzeseKkvQ2Px8PqX3i+Vr 7QKvm0CD4JtON1dAPEty3vAWu/K7sQVL9ggefQnpZGzHpuUgoWZKJRNqxleZkeBCMfLa DgCDAAyGAHBIFXGobVTe8UV5RwNR+zubPG5IRxq+UphHMyxN0jmNAQXVyYo7hbM+DFRr xAkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=SZPJDkExKOYCY2IPPHeZK5XqUUNA32t1hp69KRfbxAg=; b=BGCXq5kyz3FB4XKPHlK1LvHk1eMCQaAyCjewMFcL8i64j799p9M1dvMJPfEETuRhgx XkEi0LNFDMU4KB65IKKwlZUlnZOrybj1uOu+H+QtJ0qXuYkTapahXiVyjbfvddF7ngHP QaJp/9b4lL4thgfkvDSTgHMdnQakoh4DPBpI+lIWuH2w9pXytuvGWzMDfsWIBs6TZX9g obhRu7Fum3O5k+wAdzZgUaLH1Y5yChsFmxaUG0d2iUvGNnPm3MDjaxZQHKf2cmDoMyKx 9p3THu63LWNTmITjTQW/0enfZaYOF3fYzZM5Pay5WQd4zfuloQ4VZuSP+hAyPZ3UE1sy KXgw== X-Gm-Message-State: AIVw111chtIwSwi614VYbsQ/kv0c603AP/LKWfknK3VSUeOGwPKAGRit JyIPAZoirsKUNOaM7+w86m9DD8ySysrz X-Received: by 10.98.139.11 with SMTP id j11mr8264620pfe.18.1500082801378; Fri, 14 Jul 2017 18:40:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Fri, 14 Jul 2017 18:40:00 -0700 (PDT) In-Reply-To: References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> From: Watson Ladd Date: Fri, 14 Jul 2017 18:40:00 -0700 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Fwd: draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 01:40:04 -0000 On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins wrote= : > > On 15 Jul 2017, at 1:01, Melinda Shore wrote: > >> It might make sense to kick it over to ops for a discussion with people = whose meat and potatoes is monitoring, management, and >> measurement. > > > As someone who is ops-focused, I think this is an excellent suggestion! > > There have been several assertions posted to the list recently regarding = various aspects of security and their intersection with encryption. It may= be useful to take a moment and clarify a few of them. > > With regards to DDoS mitigation as it relates to encrypted attack traffic= , only a subset of attacks in a subset of situations can actually be adequa= tely mitigated without full visibility into (and often the ability to inter= act with) the traffic within the cryptostream. There are various ways to a= pproach this issue, including full session termination and 'transparent' de= tection/classification, the latter of which isn't of course feasible in a P= FS scenario. Each of these general approaches has its advantages and drawb= acks. DDoS mitigation can be done at endpoints, and indeed has to be given that other tools do not know which endpoints need to be rate-limited or are expensive. A lot of distinct things are being crammed together into DDoS, and the fact is endpoints can deal with application layer attacks via rate-limits, CAPTCHAs, and other techniques, while not-application layer attacks don't require visibility to defeat. What can a middlebox do that an endpoint cannot? Globbing a bunch of distinct things together is not helping the debate. > > Very specifically, fingerprints of encrypted streams are not in fact adeq= uate for DDoS defense; again, they're only useful for a subset of attack ty= pes in a subset of situations. > > In the case of detecting and classifying hostile activity within a given = network - which isn't limited to malware spreading, but includes data extra= ction, attempts at unauthorized access, attempts at subverting additional d= evices, et. al. - the same basic caveats apply. It is not in fact possible= to adequately detect and classify all, or even a large subset, of hostile = network traffic without visibility into the cryptostream. There are some g= ross behaviors which can be detected/classified whilst standing outside the= tunnel, but assertions to the effect that all or most of what's required i= n this arena is possible without visibility (one way or another) into the r= elevant encrypted traffic are incorrect. > > It's also important to understand that inserting proxies into multiple po= ints of a network topology is not cost-free, nor an unalloyed good. It is = impractical in many circumstances, and has highly unwelcome side-effects in= many more, including a negative impact on reliability, performance, and av= ailability, as well as broadening the potential attack surface. Endpoint m= onitoring does not scale well, is often impossible to implement due to both= technical and administrative challenges - and one can't really trust endpo= ints to self-report, anyways, as they can be subverted. You are conflating different situations. If you want to detect unauthorized access to a resource, having the resource which determines access anyway log that is enough. Exfiltration detection based on looking for sensitive identifiers doesn't work: real attackers will encrypt the data and dribble it out slowly or pretend to be videoconferencing. Did any exfiltration detector stop heartbleed? Endpoint subversion is not an issue for access control: if the endpoint is subverted, access has been gained. It isn't an issue for DDoS protection. Malware detection on the network does have to worry about subversion of endpoints, and yes, being able to recognize anomalous traffic is helpful here. As for attack surface why is "Press here to get plaintex of everything" not a major, major increase in attackability? Any honest assessment of middlebox techniques would acknowledge they can also be attacked and are inherently unsegmented. Just because many large organizations have decided not to adopt the smart-endpoint, dumb-network model of the Internet doesn't mean the Internet needs to be redesigned to accommodate them. I am seeing middlebox vendors and one vertical express need for this. > > > In many scenarios, one form or another of network-based visibility into e= ncrypted traffic streams within the span of administrative control of a sin= gle organization is legitimate, vital and necessary. It is not 'wiretappin= g', any more than tools such as tcpdump or telemetry formats such as IPFIX = and PSAMP can be categorized as 'wiretapping'. The fact is, the availabili= ty, confidentiality, and integrity of systems, applications, and networks t= hat everyone on this list relies upon is highly dependent upon the ability = of organizations to have visibility into encrypted traffic streams within t= heir own networks, for purposes of security as well as testing and troubles= hooting. > > > How this can be accomplished is a matter for further discussion. But it'= s important that everyone focused on this topic understands that it is simp= ly not possible to successfully defend against many forms of DDoS attacks n= or to detect and classify hostile network traffic in the context of encrypt= ed communications without visibility into the traffic in question, via some= mechanism. The same goes for troubleshooting complex problems. Which DDoS attacks specifically? And if the traffic isn't hitting endpoints, does it matter? > > > Those with operational experience at scale will likely recognize and ackn= owledge the difficulties and challenges noted above; others may wish to con= sider these factors and their impact on the operational community and the n= etworks, services, and applications for which they are responsible, and upo= n which we all depend, every day. I'm currently working at place you notice when we go down. We do not use these techniques on our production network. We use mutual TLS for a large number of internal services, even within the datacenter and the same machine. We debug many complex issues through logs and specialized tools to examine troublesome state, as well as request tracing. I've not personally had the pleasure of doing this, but I know it is possible because it is done every day. Finally, most software can export the secrets from TLS connections to a file. The capacity being asked for already exists. > > ----------------------------------- > Roland Dobbins > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Jul 14 22:58:44 2017 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 6D3C712762F for ; Fri, 14 Jul 2017 22:58:42 -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, HTML_MESSAGE=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=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 1VcLfNonEMR9 for ; Fri, 14 Jul 2017 22:58:40 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E0C3B126B7F for ; Fri, 14 Jul 2017 22:58:39 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6F5uQHe000883; Sat, 15 Jul 2017 06:58:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=lALeR95VF8wVB2dUJSWexykUP+nV6P34KeJbPuyca9M=; b=cQJvZRhgWYE6+uT+WMGinaXnjGwHiNWfFg0J/heslR9BbDYHxXxSwLy4BJRgT8GQkJNH Li4tNrOlWCtAFQBGXA1G8qPUyl3oJlyZxHFvi35CD/CsAAiW+TaVKfljX5Hkf8UExMS1 Jgo0wWcPIjBcp0UD2VdfsAf6nDsi0frtNi0DScteAgHPf/TDIBUCQaxLxhDJXCturxgz vmT3CWXEWyVUvPTbaxqQroUgoztORAy2Vk+38Gztu78yH0IOd/jO674T5whggHNU66wY wkDtmQ3tTollrGg7f7tti0bSrkg7wFZnsVlnp2fFwdN+y8iegvCh4mqoJZ0H1wtu7oWU jw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bq84d0sde-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 06:58:34 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6F5uWA3027987; Sat, 15 Jul 2017 01:58:33 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bn0p22nm8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 01:58:33 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 15 Jul 2017 01:58:32 -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.1263.000; Sat, 15 Jul 2017 01:58:32 -0400 From: "Salz, Rich" To: Joseph Lorenzo Hall , Matthew Green , Nick Sullivan , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYA== Date: Sat, 15 Jul 2017 05:58:31 +0000 Message-ID: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.146] Content-Type: multipart/alternative; boundary="_000_8b502340b84f48e99814ae0f16b6b3efusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-14_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707150095 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-14_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707150095 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 05:58:42 -0000 --_000_8b502340b84f48e99814ae0f16b6b3efusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VW5sZXNzIEkgbWlzc2VkIHRoZSByZXBseSwgSSBkaWQgbm90IHNlZSBhbnkgYW5zd2VyIHRvIG15 IHF1ZXN0aW9uIGFzIHRvIHdoeSBpdCBtdXN0IGJlIG9wdC1pbi4gIERvIHdlIHRoaW5rIGV2aWxk b2VycyB3aWxsIHRlbGwgdGhlIHRydXRoIGFib3V0IHdoYXQgdGhleSBhcmUgZG9pbmc/DQo= --_000_8b502340b84f48e99814ae0f16b6b3efusma1exdag1mb1msgcorpak_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlVubGVzcyBJIG1pc3NlZCB0aGUgcmVwbHksIEkgZGlkIG5v dCBzZWUgYW55IGFuc3dlciB0byBteSBxdWVzdGlvbiBhcyB0byB3aHkgaXQgbXVzdCBiZSBvcHQt aW4uJm5ic3A7IERvIHdlIHRoaW5rIGV2aWxkb2VycyB3aWxsIHRlbGwgdGhlIHRydXRoIGFib3V0 IHdoYXQgdGhleSBhcmUgZG9pbmc/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_8b502340b84f48e99814ae0f16b6b3efusma1exdag1mb1msgcorpak_-- From nobody Fri Jul 14 23:10:45 2017 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 B1A7512FB9A for ; Fri, 14 Jul 2017 23:10:38 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 74iUmr0CE8QF for ; Fri, 14 Jul 2017 23:10:34 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B48D12EC55 for ; Fri, 14 Jul 2017 23:10:34 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 191so86333888oii.2 for ; Fri, 14 Jul 2017 23:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=si9tmk3ueFWaMan6FSN1ODpYl4U28o2zwQ8kz5c+q+U=; b=M4gsJ6IQnlpeikaCiOUg2e6Q29vkbYmnmFinv/vtRplgsQ19bwdDnCQH7z+vM9goj3 EOHDqS02IMOQfUHfF8Fn4yC5ILarFlqMbXhSZikclNDPVMIAN5L4fGF+fH3dYMh6avx8 EH56dG/5gAIe42N3p+cIoRUrzaNxtgVY1MVZ5N9ides35P6NqLxaLDuA/jcmdxWBCgCZ 6u1lC9aVPUTBQOP+Kp4Xm1PtoUbSIg6gOG5xFd/V/miEYHdXE7owEuEjwdEpoNbe+6Ze uSscb/Tpy07WW8jvXIARGXJ54KYxZdylhC0sXFgacbTun1N9KiutZA3aoOgo5hqIVNUP cqEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=si9tmk3ueFWaMan6FSN1ODpYl4U28o2zwQ8kz5c+q+U=; b=O7j7gZoBWfipl1P6JBSGqVQv8asiZw6/13V+H7wti1yRCqFSSZw3RYZ/iMEqDcZSQ4 juAKl8ishsKDO1UTGT44ob0D7mf3P88OQEN6C8XucLdFRT/rY6UO94fqEn2xGfXLFW1w uWcQ9Z5MMmwoK5GTasHveIFsEjO/pUFAX0P2oinrrJltq6PzX9KX69mEMkDYN3Pzew+n S2OoNDUmiapcodRUPZenTPsP8Lln281NJFjRXR7SfVj40wPI5GRPLBoJHsw2uGJhKWLy 29MlhpPOaChQofem5oIkaZy1c+7tjeN3KSu3ftpQgHtgbV5NrIewCJD5EHseShOQCDx/ m1lw== X-Gm-Message-State: AIVw111x6JLoaNT8yzh/fqQ96lhnnL/LRB86B8WHCPA8sMmaYYVB+ZW/ SddkQWCL4VZrpePgD0VJ0JoS8WIbvA== X-Received: by 10.202.232.135 with SMTP id f129mr8436669oih.157.1500099033546; Fri, 14 Jul 2017 23:10:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.5.6 with HTTP; Fri, 14 Jul 2017 23:10:32 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> From: Jeffrey Walton Date: Sat, 15 Jul 2017 02:10:32 -0400 Message-ID: To: "Salz, Rich" Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 06:10:39 -0000 On Sat, Jul 15, 2017 at 1:58 AM, Salz, Rich wrote: > Unless I missed the reply, I did not see any answer to my question as to why > it must be opt-in. Do we think evildoers will tell the truth about what > they are doing? Opt-in is choice. Choice for a consumer is usually a good thing. Sunlight is the best disinfectant. The market can punish those who don't respect privacy concerns. I can't speak for others, but I regularly avoid services that I find unpalatable. Some evildoers won't tell the truth. Eventually some will be caught. The market can punish those who get caught. EU regulators may be able to exert legal pressure on dishonest evildoers. I doubt the US will take any action. The oligarchy is strong on this side of the pond. I speculate EU entities that were honest about their practices will sidestep some regulatory actions. Jeff From nobody Fri Jul 14 23:14:22 2017 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 71F5D127137 for ; Fri, 14 Jul 2017 23:14:21 -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 U2NO6WHwiasq for ; Fri, 14 Jul 2017 23:14:20 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3B391126B7F for ; Fri, 14 Jul 2017 23:14:20 -0700 (PDT) Received: from fifthhorseman.net (38.200.broadband6.iol.cz [88.101.200.38]) by che.mayfirst.org (Postfix) with ESMTPSA id 931C8F999; Sat, 15 Jul 2017 02:14:18 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6AFBF20302; Sat, 15 Jul 2017 08:12:45 +0200 (CEST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , Joseph Lorenzo Hall , Matthew Green , Nick Sullivan , "tls\@ietf.org" In-Reply-To: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Sat, 15 Jul 2017 08:12:42 +0200 Message-ID: <87o9smrzxh.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 06:14:21 -0000 --=-=-= Content-Type: text/plain On Sat 2017-07-15 05:58:31 +0000, Salz, Rich wrote: > Unless I missed the reply, I did not see any answer to my question as > to why it must be opt-in. Do we think evildoers will tell the truth > about what they are doing? Because presumably the people who do *not* want to do evil want to avoid specifying a mechanism that will be widely implemented that could leak into use outside of the intended scenario. right? As far as i can tell, we're all in agreement here that: * This proposed TLS variant is *never* acceptable for use on the public Internet. At most it's acceptable only between two endpoints within a datacenter under a single zone of administrative control. * Forward secrecy is in general a valuable property for encrypted communications in transit. If there's anyone on the list who disagrees with the above two statements, please speak up! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAllpsloACgkQFJitxsGS MjdxVg//Ziofb+NnQWC2pM4yDFkGNyzcncMfG84bblvEyg79rxBO4qP0BF/zrht+ 3x/nlyRchTphGbWkXSnFGuyBeMDxqXg0F6aOui1PXcjjoaqoF6qNix6JMzFwIk1V DJTrMQ/fbhflovq4pd0AT3BjeFDtk4WO5TP+AiHg40RBuJvp+3bfsfe0HWrUbgOz xGSDW1ueWv1N0n/CKcnH8EJodreTAhgT9WtXHKqLmMwajRV1CYtqjkiqewsf/vLk +o7AmjY785SupVapWCh93d9h2+i30rEoA94B5y0tp/2z9/HemsSgHLy9Jlgd2Yqc bzFMt5sSxRGR26hu1DLO5tOf65U/Bx/7YdlF3N7Iu7DqpsMOp1T4L3mBTJ5H/uZe TxnLI1XxvUSHdv4EaFvBO7lg+qk+vGCSlStvo3Y1qIxmyXO+w5X34P8xTeWfYu9o 3CgwKMhAlqTebcw7JYxhIktl16DmnnCD74DPDx6V3AlcnMUNiF7nItSbtYZe/GdH JFKN8GDpHGNlKCHpbLo4fjuqI/Bw3l4UMeMtrC1UjZL+5Tj+UDGyzPlTnM7ICags UihYATXEP5TTgi8Vf6gVNF0Lb1BRAeCkX5YmJ8dZGnpA2RFw7J/9YDEpaC9iMgOQ qjYUB3f0mbu3xAYqoGJz3P5DxDTnc/OJhUgn1Kh+29tVaSi2vBk= =ig4L -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 14 23:26:49 2017 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 A109812EC37 for ; Fri, 14 Jul 2017 23:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ItrdYZyOoG7X for ; Fri, 14 Jul 2017 23:26:46 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id ADDE612EB69 for ; Fri, 14 Jul 2017 23:26:46 -0700 (PDT) Received: from fifthhorseman.net (38.200.broadband6.iol.cz [88.101.200.38]) by che.mayfirst.org (Postfix) with ESMTPSA id 6AA67F999; Sat, 15 Jul 2017 02:26:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 4F712202F8; Sat, 15 Jul 2017 08:26:39 +0200 (CEST) From: Daniel Kahn Gillmor To: Russ Housley , Stephen Farrell Cc: IETF TLS , Matthew Green In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> Date: Sat, 15 Jul 2017 08:26:35 +0200 Message-ID: <87k23arzac.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 06:26:48 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri 2017-07-07 16:04:20 -0400, Russ Housley wrote: > In some industries, there are regulatory requirements that cannot be > met without access to the plaintext. This is surely true, but it's not clear to me that any regulator requires access to the plaintext *from direct network capture*. Could you point to an example of any regulation that requires plaintext from network capture specifically? There are many non-network-based ways that plaintext can be produced as required by the regulated endpoints, without introducing a standardized mechanism that increases the attack surface of widespread implementations on the public Internet. Why should we privilege network capture (e.g. retrospectively decryptable pcap dumps) as a means of meeting regulatory requirements when: (a) other means of meeting regulatory requirements exist, and (b) we know that network capture is widely used adversarially by the kinds of attackers that TLS is explicitly intended to defend against? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAllptZwACgkQFJitxsGS MjeHDxAAyDxhMVT92b40CCfXV7jEwW4U19Lv7MEaT0iexI3gK+B+rHjnf5ATx3qw Y2NI4yGDXiMgJMb1ypLU4z3cC9ig4nxqjlTRtDkRu5hFGflsff6AMqzVlBeSIj9f QZcsC6mHzPodSOP8zEjyeBiHZtq1gpKoY+cNhxwH0Ix9unJfOgYB1AOO2xZAvKKN DFfJxAnnHcqaijSI5kVtFBc/q6BKoLGij2mw1WsfTzvncvJxTWeVQSWKdiNrGyO2 qWUMsmWxM2oKXi4Mb3+HuKhJPEqUrbWaPXP/KmLR1iV76DtrUt44XIs2RiaVIFAi VILqyOa6+NPJkhZpdUsQwlDAnyGWs9TzCKYXLGVIhzjtKL5zPNOI4+aDVXwzgfrj XuEyMQDux6yUjWyQ7kKxPfTOL642E6iCTZLtl54xsGaV6xog+jhksZTWgRz7S0fa S9pgdwb96ajPPDW28VflLtaVyGUyFUZ/YfRTWZWrXCj98+j9HS9qtg96dCkUEfth GwCCTwNMGJglga+sMkGbNm9UNUvQXORb03yIIP6v+hsQYxIK9Y2dZQxxCk9t6G8d QhfTuC5fhUbiyydCOzTYXeWdoxniGvf3V0J1l+MQbaAV0BtFVKQE94DvYev5VPel NN9ZcHZFkKpHe2P1tc2nCO1QhT9U+E3031U1IZZhDWa+3dX1wyY= =2JFA -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 15 00:39:05 2017 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 5F11B131AAF for ; Sat, 15 Jul 2017 00:39:03 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 PJ98ICLXLsi3 for ; Sat, 15 Jul 2017 00:39:01 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0103.outbound.protection.outlook.com [104.47.38.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55B4131761 for ; Sat, 15 Jul 2017 00:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FnfZduUF8cuIPDUNr21x4R6BDMeMNLmD/TPNo3r9Lcg=; b=lBpubleSCwgIzVJ5Wu3RbkAfVEEobdShSgWBrrrPsBpfxByV4/qIR6CmPpatpWB/OzIQsDbqaIrPOUzhDdTaZVjY1vSEqwtNYISkr3/Nr+mYo3f+eUMUy08fzZ27U3hk1fEUKl63SFeQDLQmmA3hgwyshznEmPulQYIQNRX3t0E= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 07:38:58 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 07:38:57 +0000 From: "Dobbins, Roland" To: Daniel Kahn Gillmor CC: "Salz, Rich" , Joseph Lorenzo Hall , Matthew Green , Nick Sullivan , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/LbQetAoAc0WMUGwvSG+0rIljKJUZVeAgAAD9wCAABgasA== Date: Sat, 15 Jul 2017 07:38:57 +0000 Message-ID: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com>, <87o9smrzxh.fsf@fifthhorseman.net> In-Reply-To: <87o9smrzxh.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=arbor.net; x-originating-ip: [2405:9800:b408:a9c1:213f:172e:972e:6441] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:1PKvY8dZ2IdYnFgridQBLrvoaKxqNvOVFN777xGm2znGWCJa+xX1fO6KsUvmXPWUe+v7TR82TwVMiav3IFW9CCyVkHIKUBRollyVQf0EbR/8G5i7PtjAxqLxa/Rd9649JYEPSUOFr9WLPhVuAGHBnUpwj3pL1xUmKP8P8iOyM4T/RJeylrIXWjAOLU94eNCxZiAygq2p0FBDvatCMGvTJ0oxwhb+kcJnc34FVMb3h9+rqcgSZxRmDPf96LoSGxAodff04Tfu1JHqCQlt/0GKbF0WNwqJu82EmivuT2AlsJbd3kwFwrpTGCiXiWC7yhHXcb4te6SpKHtGHWa2Tx/jxC5V5eH3T5LslEHEDweS+3+4ZuqqNPJpI782P5Q3DA8YV1+96+DclbdFmEUprGVIojozZ3BzPMYP+/R3Bdh7Yv9uQ9+Sj4YwHof6L0uSYbavqmvVyp5LfZpSiSObGJZSJXCterc4uxrNIiC0uzs3LUH+cwHvGCbK6bcIjkwvmBbpKBLT7dYAeAYZR1AQ4w8/zLolfMfukKnrl2EJFNthQCVcP2h1BTmy0pYE94a+3ore/na1rXQK907vaSA5/K+CYp1JZ6+pfVgE1kBFPblyJLN3QgHX2JVVqHMep74pIrqSSrUNqCkcoKVNsuD4qK52WOtQu8gdNQYSZfIcY46E4JN1vlyUFwA+zAOexR+oZzo92lzD9OyDwg2Sx1fkN1y3sThRiXBzsvIYsmTwLrfxjeOh2alOlR7McAmi8h46qq9TuapUkFA/JlmYV4gU8QAjql93URJBlE5QIty48KQP+cI= x-ms-office365-filtering-correlation-id: 6a6c1499-a417-4f76-55d5-08d4cb548d93 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(236129657087228); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39450400003)(39830400002)(24454002)(33656002)(3280700002)(83716003)(36756003)(229853002)(6916009)(53546010)(7736002)(82746002)(5250100002)(6486002)(2950100002)(6506006)(305945005)(8936002)(14454004)(189998001)(110136004)(6436002)(81166006)(8676002)(2900100001)(6246003)(38730400002)(25786009)(86362001)(102836003)(6116002)(39060400002)(478600001)(5660300001)(53936002)(54356999)(2906002)(76176999)(50986999)(99286003)(6512007)(230783001)(4326008)(54906002)(3660700001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 07:38:57.6986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 07:39:03 -0000 > On Jul 15, 2017, at 13:14, Daniel Kahn Gillmor wr= ote: >=20 > * This proposed TLS variant is *never* acceptable for use on the public > Internet. At most it's acceptable only between two endpoints within > a datacenter under a single zone of administrative control. I would strongly attempt to dissuade anyone from using it across the public= Internet. I agree that it is best-suited for use on networks within a sing= le span of administrative control, & that's the use for which it is intende= d.=20 ----------------------------------- Roland Dobbins = From nobody Sat Jul 15 00:43:03 2017 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 50830131AAF for ; Sat, 15 Jul 2017 00:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 GMgc1GRJiCme for ; Sat, 15 Jul 2017 00:43:00 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0138.outbound.protection.outlook.com [104.47.38.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655ED131761 for ; Sat, 15 Jul 2017 00:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=o8L34X237pMCj4iK9THqJyDsDqhMMWBpX7MUfk6LeiI=; b=UULMjqGwXBUgTVL5q956pL6obg6T827yJD6BF6wnkCdNafilXKamBpnAz8J9FxrVut24Nk/FR2nCaBacsbkNvQJ42cgsOhgItfMyghvRlvMDIko0ZAI60/SFkFgCVyFlqk9ryYFNDQ1LtoWVIkU/Wc7vMNEcXqI0WhYkalPELeo= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 07:42:58 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 07:42:58 +0000 From: "Dobbins, Roland" To: Daniel Kahn Gillmor CC: Russ Housley , Stephen Farrell , IETF TLS , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/TNOetAoAc0WMUGwvSG+0rIljKJUgY1i Date: Sat, 15 Jul 2017 07:42:58 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> , <87k23arzac.fsf@fifthhorseman.net> In-Reply-To: <87k23arzac.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=arbor.net; x-originating-ip: [2405:9800:b408:a9c1:213f:172e:972e:6441] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 7:rtxjy+4pvTt3DUh97Bq+bo/SD8W51Cqyg/9GbC8KTAwgKEiRO+y/0iogRwcF7zoUlmPE2dQvD+jSyfhttGGqqXkBOTIaCsy5/DDCJ/Z2qPoiWucIxRPHSrZ4TY62vYqX+//55EJ1RV1VUF4x1mHWm+d9NHlEBANlfPy355BY3j7LthluaNk2GCTaNGBKnlyt+BSs/tXyq/jPKwDxsE8GNWMJSpKzjBXt0X5Pi5Zr8v3W18D6wscBWYEJaIYwSSF8wdgjVEicfRUPIXSZtrItLUWXZZ3BRJBbSLrhYrh2I41H3zQErZe96nUf78+9BKR25Kh7i5FvePZQc2fEnjJ/0GKnKKo0LSmTrblL0X68Ilnt7VMWddJT6hodQYelXdqoF6hX60RGu0QkJQA/r7R5bK7qwr8JQJLKLbFos00Ys3MTqFPOWi4pT1Xf9AGor65cPVYRw1tNWbEDTw023QDdsslKV8r4hQZuezKLImmhtBTASH52+RBcPNjvW8xMWbyZ0BC+oMTaZ087ZPEZTac46Fw53ht8s8kDhJ/X65O8oJ377WLa4JL20hkn/VA5J6JDIpAT+blJ/A7ltj90CE1XiTACQxm6B+dHGOMv9avWzyff0QT6nQfdzhDhAGL5wbPokShT1tGbBNfX/DUEicLEAlrWj5trm2FvSIdg50KNAkbVUK7R2WqU7U+mQJBYpdMdfP2ZBy+0WFyIlHTmWnYgjjBZ/qYh4TJwCFKsJfvRYLxW6aetYRdhpU7pbo6Mz38IvXUTsaghqNQDypUfmk1NeA7HV8fNzbS0dcgR7HNE+U0= x-ms-office365-filtering-correlation-id: cb0fbd80-3c22-4cc7-59b7-08d4cb551cf6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; x-ms-traffictypediagnostic: DM2PR0101MB1039: x-exchange-antispam-report-test: UriScan:(278428928389397)(236129657087228)(192374486261705)(155532106045638); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39830400002)(39400400002)(24454002)(4326008)(86362001)(229853002)(8936002)(6486002)(2950100002)(5660300001)(5250100002)(8676002)(25786009)(83716003)(6916009)(81166006)(36756003)(6506006)(6436002)(93886004)(7736002)(3280700002)(6116002)(102836003)(33656002)(230783001)(305945005)(189998001)(3660700001)(478600001)(14454004)(6512007)(39060400002)(82746002)(2900100001)(50986999)(54356999)(110136004)(6246003)(38730400002)(76176999)(53936002)(53546010)(2906002)(99286003)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 07:42:58.3241 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 07:43:02 -0000 > On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor wr= ote: >=20 > Could you point to an example of any regulation that requires plaintext > from network capture specifically? It often isn't feasible to obtain the plaintext any other way in a given ci= rcumstance.=20 Not to mention the security & troubleshooting applications which require in= sight into the cryptostream on the wire.=20 ----------------------------------- Roland Dobbins = From nobody Sat Jul 15 00:48:20 2017 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 22049131AAF for ; Sat, 15 Jul 2017 00:48:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WanshZoTs-cu for ; Sat, 15 Jul 2017 00:48:17 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2282C131761 for ; Sat, 15 Jul 2017 00:48:17 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id c73so55378243pfk.2 for ; Sat, 15 Jul 2017 00:48:17 -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=ga2v0YF7XPCpqxIGWQVvAes8CtBAjdtnhjNo7VV/RoI=; b=B3JvAI9De8rcgUrWv9vXe9rgQOtp/EoZglCJERKHzoVRq/9fWjqmxoZgin86d9ss3U Jwe7kuCfqcjOM6dTgdXgeQ6t3Pr01nHhWcy4y7RfeEuSWOiEPYo4iWVkO32Ls5tj21zs 1qjyJ+WGWZcmln9w4jaLxaqOXdetN1I+/is7UUEN3QHdI5Bsk2SahvKKmbbkhchfn2Oo QGBKu7nRPLt/BA2DmuTHZc8qLkHwh0K6u+9P6O5OfPfUM/5SXFepmDM+011VGN/7Bj1a Quryx9k08OmrYCEPn/P1+ywcVJnQb+Dq3ZvqBNtzN0DjojQcLjTcOQf+biyAQh2VVQLH /q3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ga2v0YF7XPCpqxIGWQVvAes8CtBAjdtnhjNo7VV/RoI=; b=XxzVrZ87Uwd5WpOyOYUPt0xsAMu35QrpNl7d+UfL/si+lD+Wqk6Fd9S2+5kpahP72F NBNJqTQ+a7Idz5eBQ7gU0gSUGNWzB27QdbyvXjkktdNxGmNw6wADDwoMFXWLnmkTY7WE KHgNcC9Qi1/1GfFEIz5zGFFb1d4oWJileenRwz+m+R3Pd4bYHtAyC9CbIV9qK3cuKBai X0N/FLKOBQ4Q5BelckVJSuXzxKdaW2pgYj06zAmgRXuhofP/tZslJLMAusoiSTYuoyhC 1tKJwsA/dK6Dd4PhYC0A5IOicKmbaGDC/cBa9kFnYBf750pbbwJZiRMAUWXwD5EVNq2q fOZw== X-Gm-Message-State: AIVw110dferqVPE2XxMrXydZWWnu/Ts1Vzviyk2yAOQy9EEkwFHHcJmd pYVmdFf0sLhVCxQ/t83jgcb39r/YYHRC X-Received: by 10.98.23.3 with SMTP id 3mr9251899pfx.55.1500104896513; Sat, 15 Jul 2017 00:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Sat, 15 Jul 2017 00:47:35 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> From: Ted Lemon Date: Sat, 15 Jul 2017 09:47:35 +0200 Message-ID: To: "Dobbins, Roland" Cc: Daniel Kahn Gillmor , Matthew Green , IETF TLS Content-Type: multipart/alternative; boundary="94eb2c1107d47ba8dc055456635d" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 07:48:19 -0000 --94eb2c1107d47ba8dc055456635d Content-Type: text/plain; charset="UTF-8" In the event that it is not feasible for an operator to obtain the plaintext of a message without the key, isn't that because they don't control either endpoint? If so, why would it be their responsibility to obtain the plaintext? It should be the responsibility of the controller of one of the endpoints. If they do control one of the endpoints, then they don't need the key, or rather, they have it. So it is not our problem to provide them with a way to change it less frequently, which is really what this proposal boils down to. Can you give an example of a use case for this proposal where what I just said is not true, and explain why it is not true for that use case? Sorry if I am being dense, but I just don't understand why this is an issue. On Sat, Jul 15, 2017 at 9:42 AM, Dobbins, Roland wrote: > > > > On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor > wrote: > > > > Could you point to an example of any regulation that requires plaintext > > from network capture specifically? > > It often isn't feasible to obtain the plaintext any other way in a given > circumstance. > > Not to mention the security & troubleshooting applications which require > insight into the cryptostream on the wire. > > ----------------------------------- > Roland Dobbins > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1107d47ba8dc055456635d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the event that it is not feasible for an operator to ob= tain the plaintext of a message without the key, isn't that because the= y don't control either endpoint? =C2=A0 If so, why would it be their re= sponsibility to obtain the plaintext? =C2=A0 It should be the responsibilit= y of the controller of one of the endpoints.

If they do = control one of the endpoints, then they don't need the key, or rather, = they have it. =C2=A0 So it is not our problem to provide them with a way to= change it less frequently, which is really what this proposal boils down t= o.

Can you give an example of a use case for this = proposal where what I just said is not true, and explain why it is not true= for that use case? =C2=A0 Sorry if I am being dense, but I just don't = understand why this is an issue.

On Sat, Jul 15, 2017 at 9:42 AM, Dobbins, Roland <rd= obbins@arbor.net> wrote:


> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>
> Could you point to an example of any regulation that requires plaintex= t
> from network capture specifically?

It often isn't feasible to obtain the plaintext any other way in= a given circumstance.

Not to mention the security & troubleshooting applications which requir= e insight into the cryptostream on the wire.

-----------------------------------
Roland Dobbins <rdobbins@arbor.net= >
______________________________= _________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c1107d47ba8dc055456635d-- From nobody Sat Jul 15 00:48:34 2017 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 48928131B03; Sat, 15 Jul 2017 00:48:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, smccammon@amsl.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150010490218.31463.9483504134008363087.idtracker@ietfa.amsl.com> Date: Sat, 15 Jul 2017 00:48:22 -0700 Archived-At: Subject: [TLS] tls - Update to a Meeting Session Request for IETF 99 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 15 Jul 2017 07:48:22 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Stephanie McCammon Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: curdle uta acme cfrg httpbis rtcweb saag stir tcpinc tokbind perc quic Second Priority: sacm oauth People who must be present: Eric Rescorla Stephen Farrell Sean Turner Joseph A. Salowey Kathleen Moriarty Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jul 15 00:48:42 2017 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 8FB0F131AD9 for ; Sat, 15 Jul 2017 00:48:33 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 FJCZV8OKMDmw for ; Sat, 15 Jul 2017 00:48:27 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0108.outbound.protection.outlook.com [104.47.33.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8187A131B03 for ; Sat, 15 Jul 2017 00:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l3t4Kf0+v45h1Vbfcn6cLJ+VzphSqgwYy9Y7nhYfCVo=; b=CpwJ7E6rb+/tjJYrBdBk31WCNXPiBF1+3deJy+oBx0tsLmEuuS+dt7tmKxB4CiT9Dssj4lxBv8NMRw7smSppzViB4Y7cpMiOMlhtkQSsgdL0xe0fKwHbi2SV7f6bzvIPj9HF6yo3hLcOdVjmZsFDnyLWLX3eWngHMJfhTe2UMi8= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 07:48:25 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 07:48:25 +0000 From: "Dobbins, Roland" To: Daniel Kahn Gillmor CC: Russ Housley , Stephen Farrell , IETF TLS , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/TNOetAoAc0WMUGwvSG+0rIljKJUgxMo Date: Sat, 15 Jul 2017 07:48:25 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> , <87k23arzac.fsf@fifthhorseman.net> In-Reply-To: <87k23arzac.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=arbor.net; x-originating-ip: [2405:9800:b408:a9c1:213f:172e:972e:6441] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 7:+H0MU2f94r4KnH6Ucb2hVXipJu0ca6MrvX0lXTuDJ/rfAbqF83bHfXe5LAwd2IaLw+f43v2hHqIWH4xyHNfr43Yl33L1qAsaehJuKHNF86w2RdVV1wF+7RoWp+m+Ae2RaEI7p13MpUwtFRYU8JgYXAiIefS/X35Gymdbf6GJ4nkS61NDUsZat6O3B62jYx/BqwqhysfCPDo2sJIg9Gm2U+tR2tKJpAOJftNHuD/U14FkE2ZdTBe2mZkbPBvf03j0hgP758o5MDRa6l+C2dp0XcZYE++strXL1dHIBBK5kheKk6CiAhEHYrkHSCyS3i/2eAZaItXQFucSt58uP21N1oyRGlVuCc2TJGktlIBheP9zXXJdbKJ+uj1FqSdccIzF3PeDgzI3RPAvKUtcQC5O9MzGeF47wlDjFvvrRPNfWeojfTyHIi8FVuxbG8lKDt+OLxoWeW3r3oSUENIiCxhjkkJXWsgRkPOFSFqP37eKNR/uXOvWUpES8D/U46/+4CbJ//d8Eo6bh7Rm82TCF5wWjaz8ZlUzlvVpj40tXThRIqFFK1AhAI04C4Sx8EcAjSFrwbp1r2PFjHUEbD1XCeH3YJiKp8R+wio36QXjQvfFq2E518X+mpfdtp5Ggv7ex2mmAo2uwN3rbb1m9RAdDHcHzFYLUht/xqMi8i9DfqiIA3jtU5tcEEsQGZs6Le6b1eeuABnm0zmhVGQZ1TtQmsjMqtANP3e7E+CuPOZsdgCpshoDp5jPYoq5ByRQzq2SiZCgIY0wvm3497fJhH6VEDsCkqjojGmHzlq5JiX73sWRylE= x-ms-office365-filtering-correlation-id: 65b9f3ba-0433-4654-fd8d-08d4cb55dfeb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; x-ms-traffictypediagnostic: DM2PR0101MB1039: x-exchange-antispam-report-test: UriScan:(278428928389397)(236129657087228)(192374486261705)(158140799945019); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39830400002)(39450400003)(39410400002)(24454002)(478600001)(189998001)(3660700001)(6436002)(6116002)(33656002)(230783001)(305945005)(102836003)(7736002)(93886004)(3280700002)(2906002)(53546010)(54906002)(99286003)(39060400002)(82746002)(2900100001)(14454004)(6512007)(54356999)(50986999)(53936002)(110136004)(6246003)(38730400002)(76176999)(6486002)(8936002)(5660300001)(2950100002)(4326008)(86362001)(229853002)(81166006)(36756003)(6506006)(8676002)(5250100002)(6916009)(83716003)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 07:48:25.4120 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 07:48:34 -0000 > On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor wr= ote: >=20 > (b) we know that network capture is widely used adversarially by the > kinds of attackers that TLS is explicitly intended to defend > against? Because we know that network capture is an absolute, unquestionable require= ment in order to defeat adversaries who are both prevalent & who can actual= ly be defeated.=20 There's no talk of 'privileging' anything. The talk is about not arbitraril= y depriving network administrators & security personnel of the tools & tech= niques they've been using for many years and with great success to troubles= hoot & defend their networks, applications, services, & data.=20 ----------------------------------- Roland Dobbins = From nobody Sat Jul 15 00:55:04 2017 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 DB1C7131761 for ; Sat, 15 Jul 2017 00:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 sReNKBG0CODW for ; Sat, 15 Jul 2017 00:55:00 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0131.outbound.protection.outlook.com [104.47.36.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BB8131B05 for ; Sat, 15 Jul 2017 00:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F0k6+vNHtSCYocWIsuRXn9Zi9gFGnhcHxqEK6IOWXwY=; b=V+sh+n8NnCedvwHp3SY6av77ujNex7vlhOXy6gXplpvBHTcuOCTAR06vgiI9tdoqk7T8vI16L/gJv+SdT6TmkFzoswFKw/OMOalYsTzy4IBOzlB+qKKFkrqGUPD2MTqFLNiiUt4Bnv4bTjqhPPCSNQ5xYhCFao+L9HEfkCODx0A= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1038.prod.exchangelabs.com (10.160.129.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 07:54:57 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 07:54:57 +0000 From: "Dobbins, Roland" To: Ted Lemon CC: Daniel Kahn Gillmor , Matthew Green , IETF TLS Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/TNOetAoAc0WMUGwvSG+0rIljKJUgY1igAABS4CAAAIPEw== Date: Sat, 15 Jul 2017 07:54:57 +0000 Message-ID: <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [2405:9800:b408:a9c1:213f:172e:972e:6441] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1038; 7:VFGjixaOaPue8roXtLwZLY3piWGM6BwS6pALooK/tuMTEAPRHKHJML0q+DNxdz4tBahyt0KR60M/XC507NCf5B0w14S/4IwLsMsCkRo4/fHxdjvgMJaeGKaYoQoNZUhvBXGFJJxdcfLMEENrVgLquRp4pZTIxrua0dv0IFq4r9uQeb3fihJXq58a81f1p5zmYDZdTCb4BYKrm+FveL0NKtoRsx+jOk1xrpyCkHmj9AlH/2E9FN9FFIsaAUZ5k1E4F+itj4rAPpwLZE1vg5R7Nwjly3D+tS+Q9grxX1qyZVAXDwlEiMv8vko1/AhO8UPGA4Xo74ojbxBJ8EGv1TlIr2ZlLL290FNznY64W2JO8gyMKcI+DByvUSBt7JXTzYpQEDrG41rFmfIpSq+l7r5SFSgbUOWptSWyKzy+dB5YlpwqSH5tUURjx5Z8xP6dtNXKRC3YaybKAGK8JOxk9cfwusINKOmdFglCbMn+5l7zDXxd0XDt/M8nRziLcoT/9hi9zuVZUTs6+GvQNf9Lsd6AvQH/aLOsLaS7FO33u2zlyp1ufdR+wDMywbISbViesgSVDIaltFo+4i1sVXeB0RaFj69em3wvhWwvJGgvpiBIuqY4qIDC7YIct4KVRFbI1Z54oFQ0nLAhRN1wNdULSXyMiuvPdbsZczfDTKLtD77/k7lCfNkmjCyRWS1f6GNXYgZ/cxErdqvr5QBsy4qlfKX9rG3Tfvlq0s0KkSA/8X8R3XUlVuAzmE3Z5F29jEtsKeczpFN2roNmPxTvWoiVDRaWWMipTTRGFhCp7HBxT2T7mNQ= x-ms-office365-filtering-correlation-id: ebca30de-f2c4-4a8f-4ee0-08d4cb56c9b5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1038; x-ms-traffictypediagnostic: DM2PR0101MB1038: x-exchange-antispam-report-test: UriScan:(278428928389397)(236129657087228)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1038; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1038; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39830400002)(39410400002)(39450400003)(24454002)(53936002)(110136004)(38730400002)(6246003)(6116002)(102836003)(53546010)(76176999)(50986999)(3280700002)(6506006)(54356999)(81166006)(14454004)(3660700001)(8676002)(39060400002)(189998001)(2906002)(33656002)(36756003)(8936002)(93886004)(54906002)(6512007)(99286003)(6436002)(230783001)(5660300001)(305945005)(478600001)(4326008)(6916009)(25786009)(7736002)(82746002)(86362001)(2900100001)(5250100002)(83716003)(2950100002)(6486002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1038; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 07:54:57.6092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1038 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 07:55:02 -0000 > On Jul 15, 2017, at 14:48, Ted Lemon wrote: >=20 > In the event that it is not feasible for an operator to obtain the plaint= ext of a message without the key, isn't that because they don't control eit= her endpoint? First of all, what goes on the wire is often contextually different (and p= robatively so) from what's recorded in abstract log files.=20 Secondly, administrative divisions within a single organization often imped= e cooperation between those tasked with securing & troubleshooting communic= ations and those who 'own' the assets in question.=20 Thirdly, for both security & troubleshooting applications, the hard require= ment is for real-time visibility & possible intercession, not ex post facto= analysis.=20 ----------------------------------- Roland Dobbins = From nobody Sat Jul 15 01:07:12 2017 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 11009131B25 for ; Sat, 15 Jul 2017 01:07:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 le-iZEtj3LRe for ; Sat, 15 Jul 2017 01:07:09 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 9B7F0131B06 for ; Sat, 15 Jul 2017 01:07:09 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e7so55476087pfk.0 for ; Sat, 15 Jul 2017 01:07:09 -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=79P21paJ6Wml9+NlIB3uhJOKdkrAFMOLMP8N1Pebou8=; b=sqXtaK1yTvP+fgAuF2cEFfOhlf7zF5zblGWKxPtlzoRj1MRJegh+KrlVbNzmWahnf3 BDH7O1U7pMuiilsfdUhVP2TyvG6MRAKkLCmqF1Q0EN+3jLN5VN4IazWUnLuh/xg7NnPY QVaeNcSjXtW2b0jJQYKaKMrhjUq+dM57RJ9r+dirtlF4hZlHYIvH5/LWbhVPNA7u/biq LdaZ/uF/37ojfSP4AHzJBKkot2zyoL7BU6ouyImmKirG807/BN1MRJf/lzkgvErbtZ2A +jHdwYeWYV8HltsMgl3lnvt8kjLXeqCJevdcE8OX8xtj87L85UjjKp3OR+1gdTPwizDL eN0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=79P21paJ6Wml9+NlIB3uhJOKdkrAFMOLMP8N1Pebou8=; b=aZJrXH7LrpU1U/fra4FyUigF+YPd27P9cjF7srT1Mmk4ibdXxMv2pProK0ui2u3gwy 8tdblLyfvWSYR9sCAc2U76/o34/nDxakr0eslxZmWDUjd7oJHAlsLY3iT/Z95DqRN2Wr 8QCjmGRjVjkt4L8pPP7EpG94W7DhsL0kpNPI3yY9hVSLed+oE5rKvYrwqBaonwz2QPxE 6EmcpHZNjck+RGPHninj1RX+rBeXkGjp0s2osNGogUBSkFlgnO4A2hlrCiv7wm5nLAsU luFrtf42RDDe+TezQ2sZg9hlAo06OsO2RcyJzpzwhTZKn7DI8eRI1qYiVNdNJcB2evZ/ U3Iw== X-Gm-Message-State: AIVw113QgbGXc8bVd3WQRoSlh5N/C6Fkk4C7cu4MYuR6DHbT/aTh1alz BuFCSIRD/ZttYccGbT5fU0FkgY2KEgpa X-Received: by 10.98.23.3 with SMTP id 3mr9304736pfx.55.1500106029201; Sat, 15 Jul 2017 01:07:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Sat, 15 Jul 2017 01:06:28 -0700 (PDT) In-Reply-To: <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> From: Ted Lemon Date: Sat, 15 Jul 2017 10:06:28 +0200 Message-ID: To: "Dobbins, Roland" Cc: Daniel Kahn Gillmor , Matthew Green , IETF TLS Content-Type: multipart/alternative; boundary="94eb2c1107d4ff0bc5055456a628" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 08:07:11 -0000 --94eb2c1107d4ff0bc5055456a628 Content-Type: text/plain; charset="UTF-8" I think that your first and third points are actually non-sequiturs: the unencrypted stream is available to the entities controlling either endpoint, not just the log. There is no *technical *reason that in-flight capture is required to address those two points. Regarding your second point, this seems to be the real key that is motivating you to make the first and third points. If I may paraphrase, the problem you are attempting to address is that in some situations two sub-organizations both of which are in principle responsible to a larger organization nonetheless are unable to cooperate due essentially to a failure by one sub-organization to take seriously the responsibilities of the other sub-organization, and the failure of the organization to which they are both subordinate to successfully encourage cooperation on the part of the intransigent sub-organization. Did I paraphrase that correctly? On Sat, Jul 15, 2017 at 9:54 AM, Dobbins, Roland wrote: > > > > On Jul 15, 2017, at 14:48, Ted Lemon wrote: > > > > In the event that it is not feasible for an operator to obtain the > plaintext of a message without the key, isn't that because they don't > control either endpoint? > > First of all, what goes on the wire is often contextually different (and > probatively so) from what's recorded in abstract log files. > > Secondly, administrative divisions within a single organization often > impede cooperation between those tasked with securing & troubleshooting > communications and those who 'own' the assets in question. > > Thirdly, for both security & troubleshooting applications, the hard > requirement is for real-time visibility & possible intercession, not ex > post facto analysis. > > ----------------------------------- > Roland Dobbins --94eb2c1107d4ff0bc5055456a628 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that your first and third points are actually= non-sequiturs: the unencrypted stream is available to the entities control= ling either endpoint, not just the log. =C2=A0 There is no technical reason that in-flight capture is required to address those two points.

Regarding your second point, this seems to be the real key= that is motivating you to make the first and third points. =C2=A0 If I may= paraphrase, the problem you are attempting to address is that in some situ= ations two sub-organizations both of which are in principle responsible to = a larger organization nonetheless are unable to cooperate due essentially t= o a failure by one sub-organization to take seriously the responsibilities = of the other sub-organization, and the failure of the organization to which= they are both subordinate to successfully encourage cooperation on the par= t of the intransigent sub-organization. =C2=A0 Did I paraphrase that correc= tly?

On Sat,= Jul 15, 2017 at 9:54 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:


> On Jul 15, 2017, at 14:48, Ted Lemon <mellon@fugue.com> wrote:
>
> In the event that it is not feasible for an operator to obtain the pla= intext of a message without the key, isn't that because they don't = control either endpoint?

First of all, what goes on the wire is often contextually different= =C2=A0 (and probatively so) from what's recorded in abstract log files.=

Secondly, administrative divisions within a single organization often imped= e cooperation between those tasked with securing & troubleshooting comm= unications and those who 'own' the assets in question.

Thirdly, for both security & troubleshooting applications, the hard req= uirement is for real-time visibility & possible intercession, not ex po= st facto analysis.

-----------------------------------
Roland Dobbins <rdobbins@arbor.net= >

--94eb2c1107d4ff0bc5055456a628-- From nobody Sat Jul 15 01:14:59 2017 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 1E64B131B03 for ; Sat, 15 Jul 2017 01:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rMRBuU_FRR5k for ; Sat, 15 Jul 2017 01:14:56 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A809D131B34 for ; Sat, 15 Jul 2017 01:14:55 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id 15so2487151wmm.3 for ; Sat, 15 Jul 2017 01:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=V6DZQ2zCXQoKRaRmHiLqnxbmqh5yoF1+FBvhzBKvtDw=; b=AaKEE1wViCFZsdI5SgcTz6046pUEIfQ+grLfHAzZ6zHsJnlsx3SGUI55CQaXMAzMLG WmW2Fui2TLTdQyV6UkWwSdZhEk3Pa7X9b2HFivTuClMuf5KHZipsLlEeKsMFJukwEH22 GFEEHqwJ4MKHX+0hOFBF9dX9H9NIJmH9tNSF0yaVycVDCdKR8UWEq8QCd9kB3TVvASDZ hgJIqhs6jlIJEH76Ha9kCW/BVak/ToL9hhZH8TG4oK/P3yisLWABKSqJ5Ojr0q4t2s4a FBsqysnJN5GPSOaL0uCqP07bSlNXN5yy4RF306Y4YfjTNMfX4wfkv/8NnirSFe+0i4KT RE0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=V6DZQ2zCXQoKRaRmHiLqnxbmqh5yoF1+FBvhzBKvtDw=; b=qddguKnkM2Fu74l2taYEF8ycn/YjXjWjxLzyPKEK91WyG5dvh4xNamfNmNlIN1K5qQ ZhMc6hxTRJ7MqNXmEK2Y4Qfz9HYFB8uu3ijYtyhaTTxvGVb2MRIdxOziYqs/PyYr7xfE hl/ZDn6NU/SfG1rOQ5CXHu+MEZ6SzldTtfUjBlfc7vujVgbS5h5ddqdRW+0i99rKlvO+ EjwGXrN6ciHslaJfaPsYv/k4mH+yoX3wjzN5bquldc2urxjEpS6DC8yeMb0lhDaEUZMY pgGMGShUO6lehFqvpsHOo7qpcKCmWDx8vY+d0jRYQz2PfLRUZZM1Rf8UAf8lpMLYrKwo JUDA== X-Gm-Message-State: AIVw111yei04goAZVDMvsbq2xWnRfRBwlaZxNvlvJUcPlEj341WCO0zj tu9N5Nn0twa4Jw== X-Received: by 10.80.170.74 with SMTP id p10mr9774517edc.33.1500106494255; Sat, 15 Jul 2017 01:14:54 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l3sm4901532edc.32.2017.07.15.01.14.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 01:14:53 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6D17C65C-6FED-4DE1-BF26-E9FB4C79C092"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 15 Jul 2017 11:14:50 +0300 In-Reply-To: <87o9smrzxh.fsf@fifthhorseman.net> Cc: Rich Salz , Joseph Lorenzo Hall , Matthew Green , Nick Sullivan , "tls@ietf.org" To: Daniel Kahn Gillmor References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 08:14:57 -0000 --Apple-Mail=_6D17C65C-6FED-4DE1-BF26-E9FB4C79C092 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Jul 2017, at 9:12, Daniel Kahn Gillmor = wrote: >=20 > On Sat 2017-07-15 05:58:31 +0000, Salz, Rich wrote: >> Unless I missed the reply, I did not see any answer to my question as >> to why it must be opt-in. Do we think evildoers will tell the truth >> about what they are doing? >=20 > Because presumably the people who do *not* want to do evil want to = avoid > specifying a mechanism that will be widely implemented that could leak > into use outside of the intended scenario. right? >=20 > As far as i can tell, we're all in agreement here that: >=20 > * This proposed TLS variant is *never* acceptable for use on the = public > Internet. At most it's acceptable only between two endpoints within > a datacenter under a single zone of administrative control. This TLS variant is only about using the same key share for a while. = This is already done for optimization (as in =E2=80=9Cuse the same key = share for 1 minute before generating a new one=E2=80=9D) although I = guess for decryption a key would be used for longer than a minute. The one difference between reusing a key share for optimization and = reusing a key share for decryption is whether or not the server dumps = this key share to disk. That is not a difference in TLS. In fact these = two are indistinguishable. And that brings us back to Rich=E2=80=99s = question: Do we expect evildoers to signal that they=E2=80=99re doing = this? --Apple-Mail=_6D17C65C-6FED-4DE1-BF26-E9FB4C79C092 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZac77AAoJELhJCxUKWMyZMwwIALJ+l/nR+ihaAgTBQLstH7qt MTdhMK7+GdxOJ4ZTHZkKAQmJbIl/G8vxyN6iOyui171QldnlWijyIJqgqLJnokoF KWWXn7W9y7i+uoylsOl7RLawxM05+6/wH73FeJOyWo7b+8jyEC8OxwaqjFxOpSvu sjpOl39+lDALZM7PwaXUSjW0+Om4hWv8fOFFsm/D7dpuvJS3ysQHDi+8lLqMhrMo 7l5slNLAgPR876IeZOUb6s5iBeZ5qyutAmu2ldP8p1lJhbKWFd14GBiFe5nbAHvz BkYz68zeT/uPbvHF87C0wt1OHafHBcKQNNGN/Mk1YT0cZLbgGSYZ+W4pVuIZC8M= =AmN4 -----END PGP SIGNATURE----- --Apple-Mail=_6D17C65C-6FED-4DE1-BF26-E9FB4C79C092-- From nobody Sat Jul 15 01:22:57 2017 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 18ED1131B34 for ; Sat, 15 Jul 2017 01:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 wudPOwjevZtg for ; Sat, 15 Jul 2017 01:22:54 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0124.outbound.protection.outlook.com [104.47.33.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E28131B03 for ; Sat, 15 Jul 2017 01:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LrA/EIZHM3DU6hpMYfL9aAKjChlFEXxxeknUaXuur+w=; b=fotzhr6OT/JAXEhoMx2WIGgP1FxgYRTCjs92EJFliFGFiWklShOlrvfj4cGQUyDkCWoTs6R/5tsKwRJhRO4tHaIsWmYVthTCv8EIhwzT7/fQ3dVXBljVRCNgw8gqxJw4z/lVK0Q7cAmrWX5Z0I7d9Vt9Wsxss0dh3/cVl/B+x1c= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1040.prod.exchangelabs.com (10.160.129.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 08:22:51 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 08:22:51 +0000 From: "Dobbins, Roland" To: Ted Lemon CC: Daniel Kahn Gillmor , Matthew Green , IETF TLS Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/TNOetAoAc0WMUGwvSG+0rIljKJUgY1igAABS4CAAAIPE4AAAzcAgAAElA0= Date: Sat, 15 Jul 2017 08:22:50 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [2405:9800:b408:a9c1:213f:172e:972e:6441] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1040; 7:h+NZlZiHQL9Y1AQNPuzyDnS17oKEHRqVmcWc7bs9UthEUVhLc27h8hTgXQfTWPMq625zhIR3h2HiUXCb9kvGU6H7MO18SHi2Z+jwYlWGnjNZvmFDBQcjZBpLqrMACQwyVNGHOx7fV1Y1/RYqciCy48bKU/Ii9JiEcpybUB7hDpF19puU/x/tedVt/kPnSryhNSwT9PqSIrh32qkf+bnTedGkqZo4DoaX0+VbQ1X1CQpzXKAar9PvEvzPCyj9++9o5kP+4kK8eoO2D/KI3cQNizpfNC3YALD2tST9FyXPGOu5jWDlCSXTKIDDhwVBYVIBp2nx5+WMMeCvCpFZAI+BIBTMk4+LIWDKiM6KSawmknmkU9ksP7v3kb9V7L7VULG6dBCfu4mTIH2Kni6TpoEx0iTZ4WWoGY7Pnbtf6EK8RIGxfbUxY2ZiQ16cCMGEj0lty1iXN3ge/PhtTaEJcOrdZild+qpYrjQ+MMXzOzG8CF0zjVu3KM35VC5QZucA/2ZFhQaL/0ighbI2e93DYazZC+vRt7axLEY+gtAI4Y7f99RWQHl8skDg3tU8IN9RL/EiBsU1WndQijF3GXrYhNuH70OGLKa//smVSA6e9IwrNgSLc1g9k2yE2kiRLrU43RcoE0acUuE+Ryczw+70D2vpJb6+urISILmaqWJdzg15ke1wAm7iQ0+WZmcynvmk4DS4mjjVNISLYwLsDGn7DNHNDVtlq6ec88T8tCsmPKislyHJgUpRjThwxJZi8Af5fyMwoaJ1UtW8lImKW1LBZUw+1TNFKzRI9O/nzFlSdzoLCig= x-ms-office365-filtering-correlation-id: 811e96bf-6334-4e33-40b7-08d4cb5aaf1f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1040; x-ms-traffictypediagnostic: DM2PR0101MB1040: x-exchange-antispam-report-test: UriScan:(236129657087228)(192374486261705)(48057245064654)(50300203121483)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1040; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1040; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400002)(39400400002)(39450400003)(39410400002)(51444003)(24454002)(6246003)(36756003)(6436002)(99286003)(3660700001)(54906002)(6486002)(189998001)(6506006)(53936002)(2900100001)(236005)(6512007)(2906002)(54896002)(110136004)(229853002)(7736002)(3280700002)(38730400002)(86362001)(8936002)(93886004)(5250100002)(230783001)(39060400002)(14454004)(478600001)(5660300001)(8676002)(83716003)(50986999)(4326008)(54356999)(33656002)(76176999)(53546010)(82746002)(102836003)(6116002)(25786009)(81166006)(6916009)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1040; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D43C78369F724D3CA8FAE536FCBEEB6Aarbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 08:22:50.9294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1040 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 08:22:56 -0000 --_000_D43C78369F724D3CA8FAE536FCBEEB6Aarbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgMTUsIDIwMTcsIGF0IDE1OjA3LCBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb208 bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20+PiB3cm90ZToNCg0KSSB0aGluayB0aGF0IHlvdXIgZmly c3QgYW5kIHRoaXJkIHBvaW50cyBhcmUgYWN0dWFsbHkgbm9uLXNlcXVpdHVyczogdGhlIHVuZW5j cnlwdGVkIHN0cmVhbSBpcyBhdmFpbGFibGUgdG8gdGhlIGVudGl0aWVzIGNvbnRyb2xsaW5nIGVp dGhlciBlbmRwb2ludCwgbm90IGp1c3QgdGhlIGxvZy4NCg0KVGhpcyBhc3NlcnRpb24gaXMgYm90 aCBpbmNvcnJlY3QgJiBpbmNvbXBsZXRlIGluIGl0cyBzY29wZS4NCg0KVGhlcmUgaXMgbm8gdGVj aG5pY2FsIHJlYXNvbiB0aGF0IGluLWZsaWdodCBjYXB0dXJlIGlzIHJlcXVpcmVkIHRvIGFkZHJl c3MgdGhvc2UgdHdvIHBvaW50cy4NCg0KVGhpcyBhc3NlcnRpb24gaXMgZmFjdHVhbGx5IGluY29y cmVjdC4gIFRoZXJlIGFyZSBxdWl0ZSBmcmVxdWVudGx5IHJlYXNvbnMgdG8gaGF2ZSBib3RoIHZp c2liaWxpdHkgJiB0aGUgYWJpbGl0eSB0byBpbnRlcmNlZGUgaW50byB0aGUgdHJhZmZpYyBpbiBx dWVzdGlvbiBhdCBvbmUgb3IgbW9yZSBzcGVjaWZpYyBwb2ludHMgaW4gdGhlIG5ldHdvcmsgdG9w b2xvZ3kgKmJldHdlZW4qIGVuZHBvaW50cy4NCg0KVGhpcyBpcyBuZXR3b3JrIHNlY3VyaXR5ICYg dHJvdWJsZXNob290aW5nIDEwMS4NCg0KICBEaWQgSSBwYXJhcGhyYXNlIHRoYXQgY29ycmVjdGx5 Pw0KDQpObyAtIHRoZSBhdHRlbXB0IHRvIGRlbmlncmF0ZSAmIGRpc21pc3MgcmVhbC13b3JsZCB0 ZWNobmljYWwgb3BlcmF0aW9uYWwgcmVxdWlyZW1lbnRzIGlzIGludmFsaWQsIGFzIGlzIHRoZSBk aXNtaXNzYWwgb2YgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnRleHQgb2YgYWN0dWFsIG5ldHdvcmsg b3BlcmF0b3JzIGluIHRoZSByZWFsIHdvcmxkLg0KDQpUaGUgdGhyZWUgcG9pbnRzIEkgbWFkZSBh cmUgaW5kZXBlbmRlbnQgb2Ygb25lIGFub3RoZXIsICYgY2FuIGJlIHZhbGlkYXRlZCBieSBhbnlv bmUgd2l0aCBhIG1vZGVyYXRlIGRlZ3JlZSBvZiBvcGVyYXRpb25hbCBleHBlcmllbmNlIG9uIHBy b2R1Y3Rpb24gbmV0d29ya3MuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJv ci5uZXQ+Pg0K --_000_D43C78369F724D3CA8FAE536FCBEEB6Aarbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T24gSnVsIDE1LCAyMDE3LCBhdCAx NTowNywgVGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSI+bWVs bG9uQGZ1Z3VlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5JIHRoaW5rIHRoYXQgeW91ciBmaXJzdCBhbmQg dGhpcmQgcG9pbnRzIGFyZSBhY3R1YWxseSBub24tc2VxdWl0dXJzOiB0aGUgdW5lbmNyeXB0ZWQg c3RyZWFtIGlzIGF2YWlsYWJsZSB0byB0aGUgZW50aXRpZXMgY29udHJvbGxpbmcgZWl0aGVyIGVu ZHBvaW50LCBub3QganVzdCB0aGUgbG9nLiAmbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBhc3NlcnRpb24gaXMgYm90aCBpbmNv cnJlY3QgJmFtcDsgaW5jb21wbGV0ZSBpbiBpdHMgc2NvcGUuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5UaGVyZSBp cyBubyA8aT50ZWNobmljYWwgPC9pPnJlYXNvbiB0aGF0IGluLWZsaWdodCBjYXB0dXJlIGlzIHJl cXVpcmVkIHRvIGFkZHJlc3MgdGhvc2UgdHdvIHBvaW50cy48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NClRoaXMgYXNzZXJ0aW9uIGlzIGZhY3R1YWxseSBp bmNvcnJlY3QuICZuYnNwO1RoZXJlIGFyZSBxdWl0ZSBmcmVxdWVudGx5IHJlYXNvbnMgdG8gaGF2 ZSBib3RoIHZpc2liaWxpdHkgJmFtcDsgdGhlIGFiaWxpdHkgdG8gaW50ZXJjZWRlIGludG8gdGhl IHRyYWZmaWMgaW4gcXVlc3Rpb24gYXQgb25lIG9yIG1vcmUgc3BlY2lmaWMgcG9pbnRzIGluIHRo ZSBuZXR3b3JrIHRvcG9sb2d5ICpiZXR3ZWVuKiBlbmRwb2ludHMuJm5ic3A7DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGlzIGlzIG5ldHdvcmsgc2VjdXJpdHkgJmFtcDsgdHJvdWJsZXNob290 aW5nIDEwMS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8ZGl2PiZuYnNwOyBEaWQgSSBwYXJhcGhyYXNlIHRoYXQgY29ycmVjdGx5Pzwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pk5vIC0gdGhlIGF0dGVtcHQg dG8gZGVuaWdyYXRlICZhbXA7IGRpc21pc3MgcmVhbC13b3JsZCB0ZWNobmljYWwgb3BlcmF0aW9u YWwgcmVxdWlyZW1lbnRzIGlzIGludmFsaWQsIGFzIGlzIHRoZSBkaXNtaXNzYWwgb2YgdGhlIGFk bWluaXN0cmF0aXZlIGNvbnRleHQgb2YgYWN0dWFsIG5ldHdvcmsgb3BlcmF0b3JzIGluIHRoZSBy ZWFsIHdvcmxkLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHRocmVl IHBvaW50cyBJIG1hZGUgYXJlIGluZGVwZW5kZW50IG9mIG9uZSBhbm90aGVyLCAmYW1wOyBjYW4g YmUgdmFsaWRhdGVkIGJ5IGFueW9uZSB3aXRoIGEgbW9kZXJhdGUgZGVncmVlIG9mIG9wZXJhdGlv bmFsIGV4cGVyaWVuY2Ugb24gcHJvZHVjdGlvbiBuZXR3b3Jrcy4mbmJzcDs8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1 NSwgMjU1LCAyNTUsIDApOyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5v cm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0 aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5v cm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0 aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9 ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46 IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7Ij4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUs IDApOyI+Um9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5u ZXQiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_D43C78369F724D3CA8FAE536FCBEEB6Aarbornet_-- From nobody Sat Jul 15 01:49:44 2017 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 EC2B9131B9E for ; Sat, 15 Jul 2017 01:49:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tqnPXuj_JsYC for ; Sat, 15 Jul 2017 01:49:33 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 B680E131B8B for ; Sat, 15 Jul 2017 01:49:31 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id t186so56340082pgb.1 for ; Sat, 15 Jul 2017 01:49:31 -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=CGocVXqQzagHqBWaE7wDixdU5pneaTDossJxv7JXE0Y=; b=Tp+y2BrCVzCBmhkQ92hEGQppYqzrSJr6ZqSylNiiTAae3iLptppnYAmuDemybvhUvB pOQsRknEeIxxMDA/H1wpih/7aeepS+jo7NTsNkRINdMrjgzECUruMOO/0YBR5wdUqMVJ 2d/X12yac2JpEF86wsnoL0zP2rNrY5xCKKayWMVy43cJVhJ0DntLlCtXMLGoflcL9xhy zFbCjYM4LkafqhrF/vjvvSB6TFgUOu/WNC1tiiviWqLAZrE0FvG5jKxre/LlcBIe5bUp qtn+yQ/4Bmqhx6V4RjMyj7byZBCiA2ISzYKRRNRCe3/1YR3dd6TCtERzI06quCCX/yk+ lVcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CGocVXqQzagHqBWaE7wDixdU5pneaTDossJxv7JXE0Y=; b=MKZovX7z8pcsGVirjQPDa4+F7NQ+8XbSmEQLOcY+DAX8R3IHF5lzQ9pPtce2cuikSH oEDOfOcN4FbgCLNBcG2/YNBWwIIEmO4x2b9mG1ojz25bzovJkFXtQWtJKlUdg7b9FxFv EvUUTf2DvKcYwVAEUOyahjNUcDQIT7b3j4fXadMfoCfhM2rysc0gzXNv5XKn+DAo8k27 9C7KjRNCICiSvB4y6GY0yn5GUs4KcPC1unlcY7DLyQ8nyXQg5HbeZRmj24XJCndzzI7b kFs7QsOZrCm4j3jirFHAsnD3ozeJlTYxG+B4urbXSB42kZMikuKjQnYC4fBehD827gvs aM8A== X-Gm-Message-State: AIVw113ESH/jQ7tdu6xh4PlI48Qf1m/6d5XROfBNHE8LhoTA2sO9THcH OytBr785eodFnWTFy5DGvvLJl1TJZlyQ X-Received: by 10.84.216.21 with SMTP id m21mr20289443pli.294.1500108571102; Sat, 15 Jul 2017 01:49:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Sat, 15 Jul 2017 01:48:50 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> From: Ted Lemon Date: Sat, 15 Jul 2017 10:48:50 +0200 Message-ID: To: "Dobbins, Roland" Cc: Daniel Kahn Gillmor , Matthew Green , IETF TLS Content-Type: multipart/alternative; boundary="f403045c69a2816a390554573ec7" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 08:49:43 -0000 --f403045c69a2816a390554573ec7 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 10:22 AM, Dobbins, Roland wrote: > > I think that your first and third points are actually non-sequiturs: the > unencrypted stream is available to the entities controlling either > endpoint, not just the log. > > This assertion is both incorrect & incomplete in its scope. > Okay. What did I miss? > There is no *technical *reason that in-flight capture is required to > address those two points. > > This assertion is factually incorrect. There are quite frequently reasons > to have both visibility & the ability to intercede into the traffic in > question at one or more specific points in the network topology *between* > endpoints. > For example? > This is network security & troubleshooting 101. > Great! Can you point me to the textbook for that class, because I must have missed it! > No - the attempt to denigrate & dismiss real-world technical operational > requirements is invalid, as is the dismissal of the administrative context > of actual network operators in the real world. > I believe that I merely described the situation. If you think my description was not accurate, then it would be great if you could explain in what way it was not accurate. I realize that institutional problems of the sort that I described do exist, are real, and do cause real pain for ops people--that's not my point. My point is that what you are describing sounds like it's a layer 9 problem. If it's not, I'm genuinely not seeing it. Rather than being offended at what you say is my mischaracterization of the situation, could you just point out where the mischaracterization lies? --f403045c69a2816a390554573ec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 15, 2017 at 10:22 AM, Dobbins, Roland <rdobbins@arbor.net>= wrote:
I think that your first and third= points are actually non-sequiturs: the unencrypted stream is available to = the entities controlling either endpoint, not just the log. =C2=A0
This assertion is both incorrect & incomplete in its scope.= =C2=A0

Okay. =C2=A0 What did I = miss?
=C2=A0
There is no technical reason that in-flight capture is required= to address those two points.
 This assertion is factually incorrect.=C2=A0 There are quite frequently rea= sons to have both visibility & the ability to intercede into the traffi= c in question at one or more specific points in the network topology *betwe= en* endpoints.

For example?
=C2=A0
This is network security & troubleshooting 101.

Great! =C2=A0 Can you point me to the textbook fo= r that class, because I must have missed it!
=C2=A0
No - the attempt to denigrate & dismiss real-world technical opera= tional requirements is invalid, as is the dismissal of the administrative c= ontext of actual network operators in the real world.=C2=A0

I believe that I merely described t= he situation. =C2=A0 If you think my description was not accurate, then it = would be great if you could explain in what way it was not accurate. =C2=A0= I realize that institutional problems of the sort that I described do exis= t, are real, and do cause real pain for ops people--that's not my point= . =C2=A0 My point is that what you are describing sounds like it's a la= yer 9 problem. =C2=A0 If it's not, I'm genuinely not seeing it. =C2= =A0 Rather than being offended at what you say is my mischaracterization of= the situation, could you just point out where the mischaracterization lies= ?
=C2=A0=C2=A0
--f403045c69a2816a390554573ec7-- From nobody Sat Jul 15 01:55:52 2017 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 132131317A9 for ; Sat, 15 Jul 2017 01:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 LRF6WmqguyvI for ; Sat, 15 Jul 2017 01:55:49 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id DA7CF13145A for ; Sat, 15 Jul 2017 01:55:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 2D93324BF4; Sat, 15 Jul 2017 11:55:47 +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 kn9fmVOiemVQ; Sat, 15 Jul 2017 11:55:46 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id ABAEFC4; Sat, 15 Jul 2017 11:55:44 +0300 (EEST) Date: Sat, 15 Jul 2017 11:55:44 +0300 From: Ilari Liusvaara To: "Dobbins, Roland" Cc: IETF TLS Message-ID: <20170715085544.y3hozzzpqzrfacd7@LK-Perkele-VII> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 08:55:51 -0000 On Sat, Jul 15, 2017 at 07:48:25AM +0000, Dobbins, Roland wrote: > > > > On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor wrote: > > > > (b) we know that network capture is widely used adversarially by the > > kinds of attackers that TLS is explicitly intended to defend > > against? > > Because we know that network capture is an absolute, unquestionable > requirement in order to defeat adversaries who are both prevalent > & who can actually be defeated. s/we know/I believe/ You seem to think that more data is better. Except collecting more data will drive up background. And if you have high background, even common events will just blend in and be missed completely, or are detected with very poor efficiency. Have big enough backgrounds, and one can have estimated over one million events of certain interesting kind in one year, _while_ taking data, but not able to be reasonbly sure that even a single event of the kind occured. And that's while people specifically looking for events of that kind. OTOH, with small backgrounds, even very small amount of events will really stand out. With really small backgrounds, even _one_ event will stand out. > There's no talk of 'privileging' anything. The talk is about not > arbitrarily depriving network administrators & security personnel of > the tools & techniques they've been using for many years and with > great success to troubleshoot & defend their networks, applications, > services, & data. You mean using security problems, that are exploited for bad ends too, in past versions of TLS? E.g. using various problems in session tickets and RSA key exchange? Oh, and like any backdoor, this backdoor too has variety of security problems. And your adversaries would absolutely love to be able to exploit _you_ using these problems, as that would make their lives much easier. -Ilari From nobody Sat Jul 15 02:05:06 2017 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 DB75F126B6D for ; Sat, 15 Jul 2017 02:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 UYki2jIuIUJH for ; Sat, 15 Jul 2017 02:05:02 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0106.outbound.protection.outlook.com [104.47.38.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85F7120725 for ; Sat, 15 Jul 2017 02:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fsqwZSsJlTnlwZgS9odvbQrLH3QlqgCKkQGRwXthi3E=; b=fhDnyjoS0f92M84PZAtSfI6cFFiNPxm6K8GuY3k6zycvKoSFoDXe6s1qH5i4we7ID1IdemjXyu8TR6hPjPtc3GhlTi+WcgDCI1WufQKSTkVqHBMmRZ3rgSWbs8mvHnUOKKw4p06Ud0nlx1cjqTP/J1plUdfXJLVrrAVhSPFyBe8= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 09:05:00 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 09:05:00 +0000 From: "Dobbins, Roland" To: Ted Lemon CC: Daniel Kahn Gillmor , Matthew Green , IETF TLS Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/TNOetAoAc0WMUGwvSG+0rIljKJUgY1igAABS4CAAAIPE4AAAzcAgAAElA2AAAdCAIAABIWa Date: Sat, 15 Jul 2017 09:05:00 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [2405:9800:b408:a9c1:213f:172e:972e:6441] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 7:jXE7vdaO2hMUepa02DDKYzkwvWa5ZKD8MuU/rgaZ9vsTUfcR1QoQ4H8ayeBPlXLJv38JpbBff3eAXapoLZJU4yqaNVH40DvrLEXT0QS6Lr931llP2fFpW4+0FxhVFnuAeXaYiryyM0+PRCg2w9YsIxDOO/TNpzJ2sM3KTI6GC4thOjmdH8VL8xOHN8EyPJc5VvZOMj5m8oojCmQKh0Rz268h7RAp0YcTNqz5f+wwLHrTwg9mp0zEMzSfmYT5UGZXO1ePYaMcak60D3AVGGdypF7tQt4cUqxjQ76ViXsloqwoxBlZ9BZ4/H9Gn86FwHsUnS3bam8mdtTzz2JFFTG6hJ0/e1c4cVTS7LKCMODo4hGM9Lza8uyxMZNqokZJhB88r0U3a6UtiOyrCnZkZUMfkUrlxokeTG9A491lRX/my2XwiBS1R83QLC8rkpW+JPu6lyj9gxVHovJoeh5I+ZiZ1fKBYoi7FB619YuOSuoHtuek9+mzzaD5Eew9n4J2xSpKti4JNosYKU3rWEllVKLCNVhiAr+SlDAjAFdAeOunH7Fy9E8aUugbmYUHwG2RVuilJ6HgvURuGXeAnAY34Dqb6a9lUZGkvP42zj6FrfBxaE8gmv/bmsglICnbSkKXpbjWlirXAvKPZJ4ASGl+GvmVjLlYomKDEx25Tcf5wlE8VT/DmjxCKHsPFFMqO8WdAXdACl8KAzY3B0A79uCdF5e8fDT4BP6cc7ku7OuIx8A/+0r9zVWCy+5wQD4gBZEla9Jn4K8csnLquRmlR75G7FAXjWU4I3jri9heooyia9qQ28Y= x-ms-office365-filtering-correlation-id: 835b804a-e116-4b80-aa0d-08d4cb6092e0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; x-ms-traffictypediagnostic: DM2PR0101MB1039: x-exchange-antispam-report-test: UriScan:(236129657087228)(192374486261705)(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39400400002)(39830400002)(24454002)(4326008)(86362001)(229853002)(8936002)(6486002)(2950100002)(5660300001)(5250100002)(8676002)(25786009)(6916009)(83716003)(81166006)(36756003)(6506006)(6436002)(93886004)(7736002)(3280700002)(6116002)(102836003)(33656002)(230783001)(3660700001)(189998001)(478600001)(14454004)(6512007)(39060400002)(82746002)(2900100001)(54356999)(50986999)(6246003)(38730400002)(2906002)(53936002)(236005)(53546010)(76176999)(110136004)(99286003)(54896002)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CF285C9C98224B5F98FCC5B2701619D4arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 09:05:00.5547 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 09:05:05 -0000 --_000_CF285C9C98224B5F98FCC5B2701619D4arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNSwgMjAxNywgYXQgMTU6NDksIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNv bTxtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbT4+IHdyb3RlOg0KDQpDYW4geW91IHBvaW50IG1lIHRv IHRoZSB0ZXh0Ym9vayBmb3IgdGhhdCBjbGFzcywgYmVjYXVzZSBJIG11c3QgaGF2ZSBtaXNzZWQg aXQhDQoNClRoZXJlIGlzIHBsZW50eSBvZiBpbmZvcm1hdGlvbiBvbiB0aGVzZSB0b3BpY3MgYXZh aWxhYmxlIG9uIHRoZSBJbnRlcm5ldCB0b2RheS4gIFNlYXJjaCBlbmdpbmVzIGV4aXN0LiAgSXQg aXNuJ3QgcmVhc29uYWJsZSB0byBleHBlY3QgYSBjbGFzcyB0byBiZSBoZWxkIG9uIHRoZSBiYXNp Y3Mgb2YgbmV0d29yayBzZWN1cml0eSAmIHRyb3VibGVzaG9vdGluZyB0b29scyAmIHRlY2huaXF1 ZXMgb24gdGhpcyBXRyBsaXN0Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJi b3IubmV0Pj4NCg== --_000_CF285C9C98224B5F98FCC5B2701619D4arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE1LCAyMDE3 LCBhdCAxNTo0OSwgVGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNv bSI+bWVsbG9uQGZ1Z3VlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PkNhbiB5b3UgcG9pbnQgbWUgdG8gdGhlIHRleHRi b29rIGZvciB0aGF0IGNsYXNzLCBiZWNhdXNlIEkgbXVzdCBoYXZlIG1pc3NlZCBpdCE8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXJlIGlzIHBsZW50eSBv ZiBpbmZvcm1hdGlvbiBvbiB0aGVzZSB0b3BpY3MgYXZhaWxhYmxlIG9uIHRoZSBJbnRlcm5ldCB0 b2RheS4gJm5ic3A7U2VhcmNoIGVuZ2luZXMgZXhpc3QuICZuYnNwO0l0IGlzbid0IHJlYXNvbmFi bGUgdG8gZXhwZWN0IGEgY2xhc3MgdG8gYmUgaGVsZCBvbiB0aGUgYmFzaWNzIG9mIG5ldHdvcmsg c2VjdXJpdHkgJmFtcDsgdHJvdWJsZXNob290aW5nIHRvb2xzICZhbXA7IHRlY2huaXF1ZXMgb24g dGhpcyBXRyBsaXN0LiAmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PHNwYW4g c3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3Qt YXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnIg c3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3Qt YXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7Ij4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6 IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBv c2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+Um9sYW5kIERvYmJpbnMgJmx0 OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPnJkb2JiaW5zQGFyYm9yLm5ldDwv YT4mZ3Q7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4 OyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IG1pbi1oZWlnaHQ6IDEzLjhweDsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJw dDsiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CF285C9C98224B5F98FCC5B2701619D4arbornet_-- From nobody Sat Jul 15 02:16:19 2017 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 6929F131B9E for ; Sat, 15 Jul 2017 02:16:12 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 E6qjABDadxtu for ; Sat, 15 Jul 2017 02:16:11 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0103.outbound.protection.outlook.com [104.47.40.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E565131B9D for ; Sat, 15 Jul 2017 02:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x0buBqQ5OjmLE7fvdfDpj2oNIbSLlz5QHnPlUlV8F98=; b=ecgq4PR+OGKqa3acyS3QzVDKw12d63RVytlaiFNB8IoVAKqsgaHoPxle/WuyTh4L8McXg0Ou2j4b7Dk7e8fYLFHFX4g8qiUTy1BgsMXVM9tQ/Cmxch8PPJdwQ6C2BuP/jTsANrCTRmlYu9lMDSJeLr97AvDO4AUgsEUI40JY5/I= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 09:16:08 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 09:16:08 +0000 From: "Dobbins, Roland" To: Ted Lemon CC: Daniel Kahn Gillmor , Matthew Green , IETF TLS Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/TNOetAoAc0WMUGwvSG+0rIljKJUgY1igAABS4CAAAIPE4AAAzcAgAAElA2AAAdCAIAABIWagAADHLQ= Date: Sat, 15 Jul 2017 09:16:08 +0000 Message-ID: <6770F4F3-3793-46F9-B47C-25EBE2E7DF5A@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [2405:9800:b408:a9c1:213f:172e:972e:6441] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:dy3Dx6QrTSVUy4oo6OQrVYk0Wy9gT53pSrYDFUO/Z92WhgIf4Y9KawrEpWLkhVwwv63Esls71eVVW5kF24eDSO+VaxofZ+cFvxpQQLx4+lD6/QpVSWEZQkM73x8UfFFcHaIj3fBm/SIE+1PkCW9EZ2K8mkKdg/UAuSTxRzqA5K6gv73kO7nMEUqf8CLDZcNX01VUlIA0GbTh/9tX201mUgc3h6xY9sUbYi/1n10K03B/OsFYEoIdLFnl+GPH2L0rStVngS4DsQwxThIxpwYoz7XZkAxT1N4WnTK1HNAHTPraQqLAUVV/9NweHhaN1tZPGP4+PHVnCKEBM2tLVcYI+Ny06sjYdfLyV99z0XmxcQq6suETshVZ8Kr+IsYkaLJLncKDnyCQjXBXzeJxU0nffCqY+BjpcvYYax9JDJl24TSJ7QFEXh2UjQxp4dYb38mwSQnpd8ohnhPie0DF4sJe4i/FWml11axETpPbUXK9uI4wRYYmbPqXVLi6FUd8x/69+Qk06KmSVGJyekIhXuiaiOfT2N6R0L0R6ZP8zACLoU8zqPCKwIwXQYOoG83KwtPleFsTB0oiXs20DBTP3dO5zTxtJIJbjNGtvs9qz4gvvBPh4PXbX8ADDQLAKtWoawv9Fk0b2EnLSt57z1oLXdxg2K89YNfquCDo+0muRns0C0SV/WYRu6yK26MyEHRgyWjGEPRZyol72PGIXaxCJdOoyq+cDBWc9sr2kejmLt32wxJ5sBJpzdYPlcezhc6jiF2BsX++eFbsBWHxYB/hyGpc2zfSkc7sFE/freMHs81ZfUY= x-ms-office365-filtering-correlation-id: 3d23cfd0-d46b-4f1e-0514-08d4cb6220eb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(236129657087228); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39450400003)(39830400002)(24454002)(33656002)(3280700002)(6916009)(36756003)(83716003)(229853002)(53546010)(7736002)(82746002)(5250100002)(6486002)(2950100002)(6506006)(305945005)(8936002)(14454004)(189998001)(110136004)(6436002)(81166006)(8676002)(2900100001)(6246003)(38730400002)(25786009)(86362001)(102836003)(6116002)(39060400002)(478600001)(5660300001)(53936002)(54356999)(2906002)(76176999)(50986999)(230783001)(99286003)(6512007)(4326008)(54906002)(3660700001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 09:16:08.2933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 09:16:12 -0000 > On Jul 15, 2017, at 16:05, Dobbins, Roland wrote: >=20 > There is plenty of information on these topics available on the Internet = today. At the risk of self-replying, it should also be noted that highly informati= ve discussions of these challenges, & detailed presentations thereof, have = taken place in WG meetings at previous IETF meetings. =20 There has also been ample time since those discussions & presentations to g= ain additional understanding & insight.=20 ----------------------------------- Roland Dobbins = From nobody Sat Jul 15 02:30:38 2017 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 7667D131B0B for ; Sat, 15 Jul 2017 02:30:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Id7gW7o5Chid for ; Sat, 15 Jul 2017 02:30:35 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 2D26412EC4B for ; Sat, 15 Jul 2017 02:30:35 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id k14so56624394pgr.0 for ; Sat, 15 Jul 2017 02:30:35 -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=ssxh9ehKx7AnU23Ycgi5DTuNpcYwEdscMXSi5PR8RG0=; b=uyYEvIudGIQyy/znGi2rSvaWLItoX2aviTs3HiIuIwFXN3nlpRST3BD8Mlm2RsqW7Q LHlThrWSsExzfN88Z5B50jizdBY49BvTPE2yPvLO0oX/6K48ASB2KBK/AwNDFTSjXfcq WxLBR1NUb/jZg1mteghxjvetAXIAfPybzG1slnS8ESa8ucXLnx7y6k6u5ctwoU/daSDF zm+pLH4WlpFM2CM+XPNf80YC1G1ELRzbwYOSYjGxX3dJj23pk34RZnbFACRBg8BO6MLT 3wutOCSN0GJ58Jr2/gK8SD60K+0xn84aaGa5Dy0/wZcVyPyvrLG1pGJfUOnlLT4HfI3x DXEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ssxh9ehKx7AnU23Ycgi5DTuNpcYwEdscMXSi5PR8RG0=; b=i5387vj7nY34uESfKHbwQzfWvRzfd8dTSGhzyXZ4ZIiei8Pt5JQP4aAXfqBWB2KRKw EsyGwUrpQ6irbLS1T0oF9Ln9iomVFSAtkGyN/6E1HN2fLeXvHWKRlx8oKyzu797MJ4FA lO3rxTIDf9wb1CFgZBuXz9g0195PEs4M1c7cyAN+N6Y0ivyOPessToHgu/9t0vW+GQ7K e5e8ofUOW8xRRTLCyf0rva4ZlTa4WjILdV0obUsHaPz4ejVBiFyveK8goX5siVWm4DAa hq6j0v/zB2GGBmb26Xm2QTJOfWn7aOj6dQJbiYJJPP8Hf3zXzYv53frpK7pWsEByQ/2r eBVw== X-Gm-Message-State: AIVw112flcXp0gQnuuZRryu1t/EXMnQY++czUPtXan9gmV1yoOSA2Tsz 7CxOt8XUieHNuB/K1axdtGsNhNbG/66m X-Received: by 10.84.143.1 with SMTP id 1mr14849329ply.103.1500111034797; Sat, 15 Jul 2017 02:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Sat, 15 Jul 2017 02:29:53 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> From: Ted Lemon Date: Sat, 15 Jul 2017 11:29:53 +0200 Message-ID: To: "Dobbins, Roland" Cc: IETF TLS Content-Type: multipart/alternative; boundary="94eb2c1194ae5a63bc055457d176" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 09:30:36 -0000 --94eb2c1194ae5a63bc055457d176 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 11:05 AM, Dobbins, Roland wrote: > There is plenty of information on these topics available on the Internet > today. Search engines exist. It isn't reasonable to expect a class to be > held on the basics of network security & troubleshooting tools & techniques > on this WG list. > Roland, the reason that I made that particular comment was to try to show you that the position you have taken here is untenable. There is no such textbook. There is no consensus that what you have said is true. I understand that you believe it is true, and I'm sure it's frustrating that not everybody believes it. But if you want everybody to believe it, you have to make your case, and not just hand-wave when I ask you for specifics. --94eb2c1194ae5a63bc055457d176 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 15, 2017 at 11:05 AM, Dobbins, Roland <rdobbins@arbor.net>= wrote:
There is plenty of information on these topics available on the Intern= et today.=C2=A0 Search engines exist.=C2=A0 It isn't reasonable to expe= ct a class to be held on the basics of network security & troubleshooti= ng tools & techniques on this WG list. =C2=A0

Ro= land, the reason that I made that particular comment was to try to show you= that the position you have taken here is untenable. =C2=A0 There is no suc= h textbook. =C2=A0 There is no consensus that what you have said is true. = =C2=A0 I understand that you believe it is true, and I'm sure it's = frustrating that not everybody believes it. =C2=A0 But if you want everybod= y to believe it, you have to make your case, and not just hand-wave when I = ask you for specifics.
--94eb2c1194ae5a63bc055457d176-- From nobody Sat Jul 15 02:39:05 2017 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 F41AE126CD8 for ; Sat, 15 Jul 2017 02:39:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Rl6XIwdHvaCs for ; Sat, 15 Jul 2017 02:39:02 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588C2126C83 for ; Sat, 15 Jul 2017 02:39:02 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 123so6034001pgd.3 for ; Sat, 15 Jul 2017 02:39:02 -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=EOHUiLxKjsRYje5gFuKeKicjdKk3DbqhUYZBwy0EIeI=; b=qkpTTs1TEYKwGbgfYDYEdIIFaHG293k6d1xD+K6oUgkIJSACsYHahILJsvPIwzhxG5 AGdbQ6N1eMU7a+0Q6KLZ4Urn2Ovkvo4zsweZ/S8zvkjvpdm9RJcMyasvpzq7k35Jv2r+ oT2FBoNscT0NOU2wwxJe0yUEEbYqpzJiWD4Hz8WwkgRDCb5wAcFCuuJhGEeZu4xo5VMX Axv8JCYIcsk/tVPk776etfk3t1dIbJcc/qfLJY3XLvtgz4tNLf1jMgPe4aOv9nnymJXM KXvi2vCsqIDLNFLQ2drx2k3oyEk0TptHeSHCn1aBgX2aFv24xWerrr7CEx9jljt6MyD6 BdEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EOHUiLxKjsRYje5gFuKeKicjdKk3DbqhUYZBwy0EIeI=; b=Us6ClVi730now9WDLaWEcd9weZu86XSjrS/T69vNX+dhqGI93yeGAyzjlnki+h2hvD ApUrV4AeebBLkImlMbACcQzP9WalTRZ3R3i76o2jVM/LZadouGqqDcGbDosmocV867AU uHZokDRrMMerAIvrj6IeD0gx8zVxy2QFK4KVTHy1lgFX9na+95XR0YDtVx6B/1mTI3pq lB1/6DvIpnmEVpqeZ5oELY1JQMNxbGxn+trjKx0epJdbayL5qGxi7o3wuyH9svaSvUbi 0+hQluIVVRh/F9aXfjuLg++oWmuQiwthjBZ9reNsKaNRRIWJ4nLFEIPVrpL97ieF1Tf0 L0Bw== X-Gm-Message-State: AIVw11237IW1ChwRV6rNc3jw50EpLoPOlcxUn+U6p9bVaxnm8ddo3iNH C1DxJcNGEDIG7PTxVXoFkzxgZfDQF3D9 X-Received: by 10.99.114.82 with SMTP id c18mr107887pgn.32.1500111541887; Sat, 15 Jul 2017 02:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Sat, 15 Jul 2017 02:38:21 -0700 (PDT) In-Reply-To: <6770F4F3-3793-46F9-B47C-25EBE2E7DF5A@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> <6770F4F3-3793-46F9-B47C-25EBE2E7DF5A@arbor.net> From: Ted Lemon Date: Sat, 15 Jul 2017 11:38:21 +0200 Message-ID: To: "Dobbins, Roland" Cc: IETF TLS Content-Type: multipart/alternative; boundary="f403045c772493fdc4055457ef13" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 09:39:04 -0000 --f403045c772493fdc4055457ef13 Content-Type: text/plain; charset="UTF-8" I was at at least one of those presentations recently, and while it certainly convinced me that there was a problem in the short term, it did not convince me that the points you are making are inherent problems with the technology. That is, the problem is not that there is no way to achieve what you intend without static keys, but rather that it would be difficult in the context of some existing deployed architectures to achieve what you intend without static keys. I agree that this is a problem. On Sat, Jul 15, 2017 at 11:16 AM, Dobbins, Roland wrote: > > > > On Jul 15, 2017, at 16:05, Dobbins, Roland wrote: > > > > There is plenty of information on these topics available on the Internet > today. > > At the risk of self-replying, it should also be noted that highly > informative discussions of these challenges, & detailed presentations > thereof, have taken place in WG meetings at previous IETF meetings. > > There has also been ample time since those discussions & presentations to > gain additional understanding & insight. > > ----------------------------------- > Roland Dobbins --f403045c772493fdc4055457ef13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was at at least one of those presentations recently, and= while it certainly convinced me that there was a problem in the short term= , it did not convince me that the points you are making are inherent proble= ms with the technology. =C2=A0 That is, the problem is not that there is no= way to achieve what you intend without static keys, but rather that it wou= ld be difficult in the context of some existing deployed architectures to a= chieve what you intend without static keys.=C2=A0 I agree that this is a pr= oblem.

On Sa= t, Jul 15, 2017 at 11:16 AM, Dobbins, Roland <rdobbins@arbor.net>= wrote:


> On Jul 15, 2017, at 16:05, Dobbins, Roland <rdobbins@arbor.net> wrote:
>
> There is plenty of information on these topics available on the Intern= et today.

At the risk of self-replying, it should also be noted that highly in= formative discussions of these challenges, & detailed presentations the= reof, have taken place in WG meetings at previous IETF meetings.

There has also been ample time since those discussions & presentations = to gain additional understanding & insight.

-----------------------------------
Roland Dobbins <rdobbins@arbor.net= >

--f403045c772493fdc4055457ef13-- From nobody Sat Jul 15 03:00:42 2017 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 E5316129B43 for ; Sat, 15 Jul 2017 03:00:40 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 JNXF2tHF815Z for ; Sat, 15 Jul 2017 03:00:39 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0111.outbound.protection.outlook.com [104.47.33.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFD7129B2C for ; Sat, 15 Jul 2017 03:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9jLgqx+WbtOWSmtwAdFHD78Z2yU72KpSL1rUfNg93Vc=; b=azI0CNLIjOesYyxtZMCsSR1zsk/Nx7AHJ7O3id1MWGpqz5k+l9AThgIQGOTNdsS8rlp39HrC0Ul065ol6WIQGB39VId5hgF/VTs9pXaqOsuKk/1UuyN+yAr/EdkXbXirHf+Heg5WXxKxOW1Iue6e2OFnrMeSZ0HrhkODLGh5TtY= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 10:00:36 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 10:00:36 +0000 From: "Dobbins, Roland" To: Ted Lemon CC: IETF TLS Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/TNOetAoAc0WMUGwvSG+0rIljKJUgY1igAABS4CAAAIPE4AAAzcAgAAElA2AAAdCAIAABIWagAAG9ICAAAiVJw== Date: Sat, 15 Jul 2017 10:00:36 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [2405:9800:b408:a9c1:213f:172e:972e:6441] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:d9Ie36SmQRMHZ1oF7IDniXO6yx+VYwhAcr1hGPvEcH3lUPiLryRoXbfxeQ3+QwfFD9iiX9HkYA/3Bhpyuy0r2UW0Kh5DjC9TfvaPHdmsemirFV6hJ1IARw5osIA2P271zxSyUsO3aFqlDcgzFak2tqeX98/8IeG+dbzBNpDQOQY1g4JmvIt8Ar6sZ71nrACzlfJcY7eLkVYImJOZP9LAC0wYAZkPda73cIB7HAhSQI8WltRxkt8H191DuLATutYS1tNw923IJ++3zPWskeQxPRaodtSwAi+qDixYDDDJ/eDzZpclI0h7kI4xxQJh1uWoEjpOqfsT1Z8DOfq8XP/xWpntJmhNgZdL7MEUPqPv/IzZTnQOKxI0VXdKUZoEMUtXTLKb6S7DluTVY+Ft10KlhyAlhuuXFr9XPH7PSgAzMa7eSDoW8eZ3uJeK2eAc5kxP+XEOPIvGUJl0DAAQh35Spruk4ZlwmvtPd4LI4AMyuqlJ5LIStHqDMU0DFb9iIrmsnQg7kQx7lZZgHPnzkwJ3BzuppA0+4uhUB6rKjpmmg7mC69i3IT2ircmQgWQhjAMzF/EfIlzLOfvMGygAiFGT4KP/vbXEvDlf9WCrI5z/htajEtl/KbbivHVY1WVRZXVnp8wXC+wevtEZMe2vPVRCIv6mviiWUM/9Iq6nBxtt419GQ6jtU8aiZrbcihqq2nth5Vt4ZCg8PxXHRrVsg6eKfIVLuClRjvvifhXlzyZQeLWxdKcOjaBlAe4PVzcIDJrRFyHklT98zi83JfksyLuOsw+B0LZZRwWr79VIfXZ44kU= x-ms-office365-filtering-correlation-id: 9d9a424a-ead1-43d4-10d6-08d4cb68572e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(100405760836317)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39410400002)(24454002)(50986999)(76176999)(53936002)(5660300001)(2906002)(54356999)(93886004)(3660700001)(6512007)(230783001)(99286003)(4326008)(2950100002)(6506006)(305945005)(8936002)(14454004)(36756003)(229853002)(83716003)(33656002)(6916009)(3280700002)(5250100002)(82746002)(6486002)(53546010)(7736002)(25786009)(86362001)(478600001)(102836003)(6116002)(81166006)(8676002)(189998001)(110136004)(6436002)(38730400002)(6246003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 10:00:36.4037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 10:00:41 -0000 > On Jul 15, 2017, at 16:30, Ted Lemon wrote: >=20 > Roland, the reason that I made that particular comment was to try to show= you that the position you have taken here is untenable. It is not untenable. It is operational really.=20 > There is no such textbook. As you now, that was a euphemism for 'a moderate degree of operational expe= rience on networks of at least moderate complexity and scope'. One comes b= y this knowledge by doing the work.=20 To deny the reality of the situation as described is equivalent to denying = that the sun rises in the East. You can deny it all you want, but it doesn'= t change the objective facts of the situation.=20 > There is no consensus that what you have said is true. There is amongst those with actual operational experience.=20 > I understand that you believe it is true, I *know* it to be true. It is objective, verifiable fact.=20 > and I'm sure it's frustrating that not everybody believes it. It's not frustrating. It's just indicative that the level of operational ex= perience of many of those engaged on this topic is minimal.=20 For myself, I would not presume to interpose myself in a discussion of topi= cs of which I've little understanding, nor would I dismiss the arguments of= specialists in the relevant fields without first having educated myself to= attain a reasonable degree of understanding of those arguments.=20 > But if you want everybody to believe it, you have to make your case, an= d not just hand-wave when I ask you for specifics. It has already been explained in detail. Beyond what I've already explained= here, relevant information is readily available both in the context of me= etings of this WG and elsewhere on the Internet.=20 Anyone who has genuine interest in understanding these topics has plenty of= information available to be perused. And it is obvious that if there were= n't significant issues at stake, then they wouldn't have been raised in the= first place. =20 ----------------------------------- Roland Dobbins From nobody Sat Jul 15 03:57:30 2017 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 6657912F257 for ; Sat, 15 Jul 2017 03:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 vyR1DVH5jCbu for ; Sat, 15 Jul 2017 03:57:26 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F0412EC34 for ; Sat, 15 Jul 2017 03:57:26 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id p188so88664534oia.0 for ; Sat, 15 Jul 2017 03:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eqgwf30YaeU55NAQoWWcd7Qt3UJ7CRFKkgSa4IQgdR4=; b=fdGEReQTIjJfBvofjNzQMvRzpBI6FtLPI6VyaEUkm0hjxy+kcH+PZqb9no4B/MwSQI 2jQDV1ro/Fwudj/3L6y2GDL7uZjEJ02QhqHp7EDKUEwUmOada0G0g4S4ePzQU63Rcuee ktebbEPfNyXls43/SJLf6gFIWFBUqlEJ4qK7kXxTiEewj4Or9oh9bkbaonoqpCT4PQEr QNRw1ylVB6BniMXC0PU+dgELiCYxPlMaCw/ilNjlE5R3LpYKCXxBvzGWFlVjAvz0Z9rO sAQZ0FWLlZI0N5GT+jsoP/z1kptoX+dL5oqhnpPCucoS0YdgV8E5jNXYISdG5p/wjJD1 E3ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eqgwf30YaeU55NAQoWWcd7Qt3UJ7CRFKkgSa4IQgdR4=; b=h5/gWDuQ3BG+2GqcPK2fnlEkpZ0ig2vrdsMMW8Bj5qrgrXD2bIxCqElqEM16Ln6gw6 XSeYO+xiDvvCzRVQtGJ5Hc3maDDxJ/LGksngmDxolFGBmqD2faoAN6awppHthK0t+qMC 7n14gyqbSlG24xFZdAnvjBWxbwMwCB4XGZvsgmckmzXMujZKGNPLudZfH/WEMkHCQw21 VrOyUnwCOKnFcmI2oGuYGgWsL23xpKPT33r9w7rATMQhlYXYv4U6y4e0vgFf/Y9tfqf5 LqWpNO7SOmUGtU35AVHhVV8hhLgl3n2ZOlXHgZsZDm/thHaVynnl7p8z0ihLHgHSEVfX BcFw== X-Gm-Message-State: AIVw1125tInvaro7nyvI4ghEIop5YUM56JZ0v9qokV5hCFe4RYodyydp 00hk45Wks0JN2UfWhkk0FE+RC7hOCQ== X-Received: by 10.202.93.2 with SMTP id r2mr7311444oib.193.1500116245865; Sat, 15 Jul 2017 03:57:25 -0700 (PDT) MIME-Version: 1.0 References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> <6770F4F3-3793-46F9-B47C-25EBE2E7DF5A@arbor.net> In-Reply-To: <6770F4F3-3793-46F9-B47C-25EBE2E7DF5A@arbor.net> From: Nick Sullivan Date: Sat, 15 Jul 2017 10:57:14 +0000 Message-ID: To: "Dobbins, Roland" , Ted Lemon Cc: IETF TLS , Matthew Green Content-Type: multipart/alternative; boundary="001a113d4becf4ead005545907f6" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 10:57:28 -0000 --001a113d4becf4ead005545907f6 Content-Type: text/plain; charset="UTF-8" I'd like to raise another point. Static Diffie-Hellman is a cryptographically problematic construction. Not only was it found to be fragile to implement in the prime field variant (LogJam), the Elliptic Curve variant has recently been identified as troublesome as well (see recent JWE vulnerability https://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html and CVE-2017-8932). Furthermore, many post-quantum key exchange mechanisms cannot be secured with repeated key shares (SIDH is one example). Encouraging (or worse, standardizing) the repeated use of a key share seems risky and shortsighted. For this reason, and the fact that there are alternative techniques to achieve the same goals (put the symmetric key material in a serverhello extension encrypted with an exfiltration key, for example), I don't think this proposal should be considered. If alternative proposals come are presented that don't require key shares to be reused, I am not against discussing them. Nick On Sat, Jul 15, 2017 at 10:16 AM Dobbins, Roland wrote: > > > > On Jul 15, 2017, at 16:05, Dobbins, Roland wrote: > > > > There is plenty of information on these topics available on the Internet > today. > > At the risk of self-replying, it should also be noted that highly > informative discussions of these challenges, & detailed presentations > thereof, have taken place in WG meetings at previous IETF meetings. > > There has also been ample time since those discussions & presentations to > gain additional understanding & insight. > > ----------------------------------- > Roland Dobbins > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113d4becf4ead005545907f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to raise another point.

Static Diffie-Hellman is a cryptograp= hically problematic construction. Not only was it found to be fragile to im= plement in the prime field variant (LogJam), the Elliptic Curve variant has= recently been identified as troublesome as well (see recent JWE vulnerabil= ity https://blogs.adobe.com/security/201= 7/03/critical-vulnerability-uncovered-in-json-encryption.html and CVE-2= 017-8932). Furthermore, many post-quantum key exchange mechanisms cannot be= secured with repeated key shares (SIDH is one example).

Encouraging (or worse, standardizing) the = repeated use of a key share seems risky and shortsighted.

For this reason, and the fact that there = are alternative techniques to achieve the same goals (put the symmetric key= material in a serverhello extension encrypted with an exfiltration key, fo= r example), I don't think this proposal should be considered. If altern= ative proposals come are presented that don't require key shares to be = reused, I am not against discussing them.

Nick

On Sat, Jul 15, 2017 at 10:16 AM Dobbins, Roland <rdobbins@arbor.net>= wrote:


> On Jul 15, 2017, at 16:05, Dobbins, Roland <rdobbins@arbor.net> wrote:
>
> There is plenty of information on these topics available on the Intern= et today.

At the risk of self-replying, it should also be noted that highly informati= ve discussions of these challenges, & detailed presentations thereof, h= ave taken place in WG meetings at previous IETF meetings.

There has also been ample time since those discussions & presentations = to gain additional understanding & insight.

-----------------------------------
Roland Dobbins <= rdobbins@arbor.net>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113d4becf4ead005545907f6-- From nobody Sat Jul 15 04:19:22 2017 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 921DA131B0A for ; Sat, 15 Jul 2017 04:19:20 -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 fwO29ARndZp3 for ; Sat, 15 Jul 2017 04:19:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87C1317D2 for ; Sat, 15 Jul 2017 04:19:19 -0700 (PDT) Received: from fifthhorseman.net (dhcp-88bf.meeting.ietf.org [31.133.136.191]) by che.mayfirst.org (Postfix) with ESMTPSA id 088D8F999; Sat, 15 Jul 2017 07:19:16 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 520B420D76; Sat, 15 Jul 2017 13:19:13 +0200 (CEST) From: Daniel Kahn Gillmor To: Ilari Liusvaara , "Dobbins\, Roland" Cc: IETF TLS In-Reply-To: <20170715085544.y3hozzzpqzrfacd7@LK-Perkele-VII> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <20170715085544.y3hozzzpqzrfacd7@LK-Perkele-VII> Date: Sat, 15 Jul 2017 13:19:10 +0200 Message-ID: <87379yrlqp.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 11:19:21 -0000 --=-=-= Content-Type: text/plain On Sat 2017-07-15 11:55:44 +0300, Ilari Liusvaara wrote: > Oh, and like any backdoor, this backdoor too has variety of security > problems. And your adversaries would absolutely love to be able to > exploit _you_ using these problems, as that would make their lives much > easier. I'd like to hear from the people who are doing full-take network capture within their datacenters about how they protect the security of the internal decryption systems. It certainly sounds like a tempting target for any adversary interested in datacenter operations. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAllp+i4ACgkQFJitxsGS MjeOhRAAhh1a+RtosMrTN1/F3WO/wkeLGbYX/87pMSKCtQZ90MfW6Wv5mw2F2CjG +3tTRbjUlUvVDYWx4BYx3WPUid70A3wx9e//I7On8K9Y4zDENN3EMhuh+VX5X3MH ecRLVhz4LTu0GXN7+BkoXTxXn60avwrSEg/ycY9T+EpCtw5L+VvBNX4rv3Q0U/yu w/bkWERsvhigxwCoUuBYYtJ2DKLLDCGh+LIoMmqiXu5D74ykCvXQoouD/XvXBV3t az1t/bl8ES7Fs3kGalX5T3OQ3D2ND+lBjYF3apVrbT0Mi/g5NSN5tKXjbpsnUh34 D0jgsTIuVnDoC195ncT1z+Qtz/ImJVgChxJyHqkhfUCs0mUYuB1o6mjYL5yipD2D lN+vCDropO+0s8b8Sp6TVHp6BVX9YaZKNevD3pbyZWI4+8FJzUg212WPZPeigIpx NY28KATYSN0heYIOjpQqJ50d2Rj58MDIC/emod3y9FhbcqxLIC7S88qnrxUg1mMi b4V9iOOSnaDYK2kXkRN4oxSco4ufCPBg04OUhwiVcNGOEXpkBiJ2jqb5bOW4HIEN Jvz52EfCyxNGsGlD17B5eOQ4d2EpHeR85FkIi3CoDaa4F3zKSoBqWCMc/c7lfCNz caPOcqdxZHfVnXxb+ZI7xdzeuiIfGh7xJCU43CuSzTnH/jihHwU= =Kn9c -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 15 04:24:16 2017 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 71384131B10 for ; Sat, 15 Jul 2017 04:24:14 -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, URIBL_BLOCKED=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 zZY8Jfh72POF for ; Sat, 15 Jul 2017 04:24:13 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 98C6D131471 for ; Sat, 15 Jul 2017 04:24:13 -0700 (PDT) Received: from fifthhorseman.net (dhcp-88bf.meeting.ietf.org [31.133.136.191]) by che.mayfirst.org (Postfix) with ESMTPSA id CBC34F99D; Sat, 15 Jul 2017 07:23:41 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CA6AC20D76; Sat, 15 Jul 2017 13:23:38 +0200 (CEST) From: Daniel Kahn Gillmor To: "Dobbins\, Roland" Cc: Russ Housley , Stephen Farrell , IETF TLS , Matthew Green In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> Date: Sat, 15 Jul 2017 13:23:35 +0200 Message-ID: <871spirljc.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 11:24:14 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat 2017-07-15 07:42:58 +0000, Dobbins, Roland wrote: >> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor w= rote: >>=20 >> Could you point to an example of any regulation that requires plaintext >> from network capture specifically? > > It often isn't feasible to obtain the plaintext any other way in a > given circumstance. > > Not to mention the security & troubleshooting applications which > require insight into the cryptostream on the wire. I asked for examples of regulations that specifically require plaintext from the network. This e-mail contains no such example, just an assertion that it's technically easier/simpler to do network capture for some deployments. i believe this assertion, btw, so you don't need to argue it further. Whether it justifies a loss of security is a separate question. If anyone has a specific example of a regulation that mandates network capture, i'd like to know about it. If there are no such examples, and we plan to continue to discuss this draft, i'd appreciate it if folks could take the "regulators require it" argument off of the table, and we can focus on the actual technical merits and risks of the proposal directly. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAllp+zcACgkQFJitxsGS Mjc6TRAAiWcOEX39DhRI1UbkMyJh+B7Ixb1N+vRZXVnKgKnRMYDYkBvabmj4hsMW zoyM3T7ei++XqpbsU8n1dt8TyfeeVmxGSjmYXvLQTItg0R46ImDFCypisAfcUc5I b7OGNwe0D73BeFJNxBLV2jEcNtJ6W4J/qpSicU9UXd3ANRzqryqlk9iAR+F3qS10 1NpqXUVrkjueOHQ6DZAaftTYVgqHwm+jkBOj6amVJZsbIMxRi1zVnBI9/DBffdCA DiBPef1lxwVr9kuOt692xsuGm/RgSpmvbJkygNslP+0/WqmNP2KRvJPVj9Iqjul3 UCoOMxyPI4ZIz1mCLFmeINObVQhTS+5Bbr+W87D2eB1OlOR//s66l1fWbeFz+/5B WN+waB6t+bksgzWuft0DLUzS8GaG3T8XVMI5MksKrieGHc19AyUR/Od8nRvJ1wtC Q/H7GyhoFlB2hYhJlM6C1YRPHY9vZrO+ZZYgBd/ulzLhVpmZGYy4+vvpRKMAoxAl ncp78bLJM78h5sqOUYpZNEAtnDv5Zi0Fg1GFVTpPRK/q8UDf9a9PklTDBBdhaczU tWIYaKNvv8xjSWVGpFj3z7M+Tdj2oHrrvZ8FYDKWbpJ2mORQJ8Nmdd+91h+yqzG9 HoNRsQ9IO2ttrs+zCe9Xh1zFTs7yZvzC9n96pyaqQVVChvlSWX0= =rjzR -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 15 04:56:56 2017 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 48312131B14 for ; Sat, 15 Jul 2017 04:56:55 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 kWqNpLG_qCq7 for ; Sat, 15 Jul 2017 04:56:53 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0133.outbound.protection.outlook.com [104.47.32.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239F312EBF4 for ; Sat, 15 Jul 2017 04:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4KPz0rfcVxkeWQxwre6bPNIeDW+se7p+YiIQHqETqZU=; b=lCX6O8Sv9r1FKdt6RUEUeW1lPQz3chsMiHS4heA+NW+NPyePxjyReQ8RZ60zRkSfcl0zJVjFLLA8tpg+u1iHUbEjNLnMVfWrS15ue6MHRMmetfuVfNv83ow6zko77edO4lMtG7LKCVwBIzjDJW6TGaMtDMncXZ78bgDcX+7vSEk= Authentication-Results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=arbor.net; Received: from [172.19.254.116] (49.228.100.193) by DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 11:56:49 +0000 From: "Roland Dobbins" To: "Daniel Kahn Gillmor" Cc: "Ilari Liusvaara" , "IETF TLS" Date: Sat, 15 Jul 2017 18:56:31 +0700 Message-ID: <31358CD2-0913-4CA5-88A2-89AB8C4FBF88@arbor.net> In-Reply-To: <87379yrlqp.fsf@fifthhorseman.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <20170715085544.y3hozzzpqzrfacd7@LK-Perkele-VII> <87379yrlqp.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [49.228.100.193] X-ClientProxiedBy: SG2PR06CA0089.apcprd06.prod.outlook.com (2603:1096:3:14::15) To DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 53f7ab98-3900-475e-f5d4-08d4cb7893fd X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 3:PzhGN7HxCQGOz5odmSEKTIAYnpjQWgVXDOhYi6IMS03feN4uvujr4ZMjXD0xitAsOTM2uT/RQicUxWfsSkfgCbtpQbtZThxJ3XnhfdbuaMWrM73Q6xMmimvmqejMWDrBoIJWW8GjkdTe1DXPNJ7KgsahOi4GydzAfEVOsI5p9LUzWZKdMe+0su66NW8ptGblbB9eZ5z/4D5MbQASjTB+hO4z57rWOQcITNG3gHo4Mm9vPI6u6iINcQcRobmjHpsjqZOGHkU8jIPQH5QbFaeE5JoGpTEAMKR9y+QK+/3m+3EyhCyu+0BuvPiCCww44xzkZcMdil/ZHODbZokDsE3WiQneSzOyAqyU6wjut+9YsRJYhQMOyjnlAxHuztEQOZ4hRMCw5fDNbRFCUoaevx5hyjaXC9uXDP59RKcYAp+ZOMgZl7iE5udY9IgDSYrQowLxfqfF/Zf+FDsWIAk85Yiv8Yqp1SKWMFm/0Bxdvl7UEXfWqqcMG+/mBTJeWeFKduA2mdC9fmoXg+mVGkgSnhO/Ly6MzEWfbLsEY8thenBOE9nBJdJtN89V0XRoh8oDfepSZojkAgWKB7unVHg6FST8+6BRJHV+WylS/+yGaNZczUc/pVFRPlr1bgPtPlPH7zdeiZzb3pQj4sPTaHncsU1iZzejLAPukFEDmxov9+mEXL0S935OTYSgXOy+fnapw2901yX740e0k8qiW4u72OrMcSFi/GOFl5areGpKyOGDVDs= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1037: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 25:BlfY+NDdwrgx0sV9UPVckf5NisDIE1ONxRH1Ay60bhOJpKSHmhRKgMnXHD2tYq8ZtHO+Q1Nlma4Z2SeOkDCSUtUfod5mDaNKD5Cz2TPkLcvHlY0OnX5se+qcsOFt07ymEQk5O/qvZDBPr8Ybd6AzrQeBorefXN8FLNv5znJwgBL8hpvmoWGo5Bhn4IE2qFZJZKRkSZqBenvhIsE0804UYlWFVS/vNdGZlN9o5smJmRSnaArCoTbMvO5G5zbzWlci/fw6TDOfOffmXeIa4sBM02ULnHLsIUYPcADgBmaJetzz5nJbepb4tbSfY+xHXdmjZp8OFNUdypShMJfRCuptuB6NmdU2YRt3fv7l3tz+9oQbVY2lDNBnoH6zoEfUFJl6duankO4rLFVOBdKPMtI/6qdqGcA7Uy9hWGiVLJ/R8jlmX6udnUZccqTjrur0YduJW3j86W2AqZJ48aZolbkfsOngY3lWO4rDJRVCx9Q5iY4vW9JpAi0dBYZAhL1WYNvmDpxk9oA8aaJncq5M2m3bwDQoLpJR0ozuAGtt0evNIZdSVQ2+p1XEZW+dOiRZzZZcgVir29VnKV+MIN7IeXf7/Tkx+Ng2H/9dGeC2IaByum4LxB33/JvEDlHTGex2pvrY7d4uWQxB1588iFko9lFLWNFvE91Lwf+6yaWrg+MJLo9oTSfmRjY7p/f5AQj+kj+y3B12q4zftXJVu6APEH7ApKFpmCnd/JsOQkZ/6RsrWNoh+14fkqYtDloF5eAcK2q+sKVJVdXKF966A6OQKc5oocj5/GH6NE6tJ3LdWbNBTywCPyj5fP1diCXtPzAkWR7pu4ScwPeuMr5gtP48FfJg+8H63WngmJyRYKpRh024mjcFDuPjuGf2Xqu6UYGuwP1LQzA9Ie1ECz9tXlLzSxU6V5MMKGJDDxlZuTaEbhzwGvg= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 31:ze7Ymvm3JdGDoJrpiPv1hoUu55MH7/hBb/kb3E3psfDwr9qQ6HX2uJUZQ6ws/hRCvInO6nzdEZYDQeLqEq9Z2T64EFv7+42A0P2FJjGFN/SEj3AschNB4lS7LtmlS+7wu7avp9zuRKCVLY33qno8c55KM560UVZ6LpHq/gVh/ezbUj6jy4NZsIKTLJQmWaoNlgA6qSQFukGDG6DAVRCi9UuJJ5N6h8A5WAtvairMHmoVhdmW6UR0G/BZCbpMk7qeBqGLjB/f1/Bz5g+nRmhiP/WUP5tfymTYinDm7NEDnWkv1LMQMVAxAfRHdh+Ky4FyhJQ0xvWsBIgS1+RsrZxdN9ZwYn5iyMkyIpvyMRWn7p6xp+01A6U/8Wf/RL+D3fzVYBrJGwzMUqADSUnHgC5FijDUZM+ldii0gLbTs8xoDJS52/EeosqO7IRRbKm5iHnl44TiG3UYEWmKHKH4Fyf47x4MDA3LxoeG3OwFhiO6zEfD7beWTU6uzXzrsz9ZDLLg9jWKSL9Mzd3sOOGgGPa+f0PTDN/zrvODn198pjMeRM8rHk2wz3QYk8fxMCIQNjA1S1EuRLHR87tUu6SzkgUDGDHvtjA/V6SmK7j1wNYemrw5BGJeQH+dpQpF+KXPhXvH8s05Jh9ukOhf7SPuInebg6yqc3y6ESObXCayKimzERhzZPNpouK2M0ddggMpW8vM3TN3YOIbFiZz2ZJqdZj8EA== X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 20:zPf1raUiSWnYKdBgkdfxgG2H1MyNj4KykBVul/eWRTzWMMvyVJnyUe2TGXbj4isIxFPtyaB4OISf/L4n+Ek93sfcLQ5CccpRsFnJxoDzEPF7KKnLS29ukz6yu1s72Dylo8JbhVfk65fiVeHyFvJa94oDqSfLqJ2o++VxO2KrjgitBbfWEnEDymu8idUh+gJWh7zy/pu6wDLx+m6GDnDdk0Fnpu5ZJ05pwIBVgt7PXoPoJ55naRxVKUYYGwGhCkC+c8H7kY0DiASdJzNRYENDRto5nXqMbpF9hzTIGr5MSnZdD7NfPbnM0lQt00uDt5dW6g2kWpuLQDlzqmkxHZ3WFAj8quLTROBzMn9+ssoqSa6Qlwp98hR2shwR9JbZPnx6+atb96fHfOl+RUw2Tlevlndg90wWWcgqH9V5Ju4d0TY/DT2J/+NYeN/9HOIWnfRWad16QtNc+b+Dhg1kp3ONAH1T8RufLG4Dgvf7qpPQzPsdRQRklV5OHOygYAvpRtHF X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(192374486261705)(48057245064654)(148574349560750); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 4:4BTiskoxIdF3MDlbcUqgHQFmHlbJx6HVy0aPPc6g?= =?us-ascii?Q?weNl3GYNmm++LvsUeLJLpWD5jD98JyF4BunQbfAWZZRq0bTzKAkmDIBAav0M?= =?us-ascii?Q?c0c/NDo1XoMtgRaLrHv+y0KXv7BDHUXqBV1lzGscY2Cor7dEBXgysLzs3OqZ?= =?us-ascii?Q?k5ak3u0diStHJ78hh/DdSpc6OOQZVhMcxrbdewrz8uK/OlNLSUb5Bm3AZ4Wh?= =?us-ascii?Q?02IRQ3EiAcV2xjjw8fl2UApKRLhRsVEsSoykhgotDki1LnGgNldB4hQztslz?= =?us-ascii?Q?CgJ/KTH10GHgRQ8iMGfLXrQIdxQNvrppgipKR7Cy5dwQzlp6urqc6AFbAvp9?= =?us-ascii?Q?nln1S4OanPWM/slBTbRhkLU3+YVtRD5+eGKIlFhkLsYGxT1ytcnJRHc5ymSK?= =?us-ascii?Q?+ja64xdgCx+ihxNed85AhFZSLh8kcDUiKMdOujSDrjI6Vozs/JMebGSeA8KE?= =?us-ascii?Q?TR8PbDiaHQOa0e56dY8l28ilfV9PHUw9G4jccGYvlSZ9Xem7nF/fAFo8rriT?= =?us-ascii?Q?1SlHoRguuYs+Z0f+GHWxQ2hquHW82eoPgruJrgH+6HApk4fJA5mUdEER3gnK?= =?us-ascii?Q?DE39sJFbwOgQ5qv9dcrzTO1BcpERvrL/iw0JCexk3vwg4epuA14FYFERAjDr?= =?us-ascii?Q?CJDGtNq+y1ySJ3iidETzoe02ILsfrktey9jC56Ffscq7TDsHIOfwOOv9a4/L?= =?us-ascii?Q?Ez+R6Va14Gz5rwNGpLiHrODvj1Pok4uGKqQ1mStOc5BThcrrU1Gl0V0JC/SZ?= =?us-ascii?Q?gX69gOviduEXaO1WX2jL+qpDMSMK7l1FdAfo7VeTv5Ox6a5CdfFR88SURWYZ?= =?us-ascii?Q?H9p7QdyM9kRhKWLOrkkXQUNn1JX9CkTNzfxOms6SD+vecfvd5E62Iyeq5DKw?= =?us-ascii?Q?ohNnw9kFDUln5gha4cArBvkw9D3U3CFMFQFXDFj4QBrMSynjY36mCi838smo?= =?us-ascii?Q?kKyxzgj3xpnHlJfu6Hoxx+8um3sbvJkmWNba8M+249csMS5KCq3yAjSrbq+a?= =?us-ascii?Q?XMSb8asNOs4YvxJKFkrX7ETX8u35IRwtK0qzsJisZ1ciZM60dUQflj0+P+fc?= =?us-ascii?Q?0xYfC8+o5NC6R8IqFh/t6kCwFhMOA1k83KHWUGUJQGUUnxCbwHHYEe6rRo2n?= =?us-ascii?Q?L6UJi5fc64F3XFSOnFpFRfjeMt2zeJkrEKCGDwU7F3JcomlxP+I9vfZMvHhS?= =?us-ascii?Q?vXXvACn7kgMnqPM0uEXNAFWRwDuk5T0tfRfxuPY1KDj+6SElfTUh5KxJzYwB?= =?us-ascii?Q?HG4dstGQcv+EFzQB3pHx7l6dgp8rqn/QCnRo4M2Y+gMFvjpixnaAHMU9oO5k?= =?us-ascii?Q?7dKhJR/uD/8r19Wep/UnUfU=3D?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(979002)(6009001)(6049001)(39450400003)(39410400002)(39400400002)(39840400002)(24454002)(50986999)(76176999)(53936002)(47776003)(5660300001)(2906002)(66066001)(50226002)(93886004)(42186005)(230783001)(54906002)(4326008)(305945005)(2950100002)(229853002)(83716003)(36756003)(82746002)(33656002)(6486002)(53546010)(7736002)(77096006)(6916009)(25786009)(86362001)(478600001)(6666003)(6116002)(50466002)(81166006)(8676002)(5003940100001)(189998001)(3846002)(110136004)(38730400002)(6246003)(7350300001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:[172.19.254.116]; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 23:Om+AV38bmqMBWKh9v10KyfAtUb1XQfZfCzMfztJ?= =?us-ascii?Q?3Wg3AhaEtUuvBAWUVJskTKF4AWNy7UxjiRvPy4OsxYH4NEz+vyoyGe0rroAA?= =?us-ascii?Q?kdDQTWO8Fow7t9jR1urb9Wtu6UzJl52Ak8oOc9Sm+dw5kVDa8P6+RE5yKrnM?= =?us-ascii?Q?rE/KpDvMw9A7MEC6R5BO5RdEe2NDGeH0zH2eMivFGgq+10lPSMIVlqf2OHzr?= =?us-ascii?Q?6cmGVDia4r8raDq4ghmDuIUT+1aYA9VAyX4URbiMv9RoLqFTq39CLAtKgMAr?= =?us-ascii?Q?MzGB3leypmgmLUBqJC8kj9ReEGwtRpG4enTUAEULs+LmElXJgCsFbf4nPdnl?= =?us-ascii?Q?NCx5VDhZYOmmnIPPhklk7ZmXDYqBV0fClQf6/oRsHf0gQFu8hDcT3/ad6qiY?= =?us-ascii?Q?A2LEdslf48pHJHUdEHBhuqBiIQhVFyZHJxGrlasf8vqLAp2AiMfIzypBdv9J?= =?us-ascii?Q?ahL8eO3bhnVYxHC9K3ADm5R7HwTSBi0wnSzMf81sX3BsWp8r/PmRRtmkqKj2?= =?us-ascii?Q?kG90jjD+nULDPSwSwhka/9H7miARzvegH/raKCOrJY26Qsu8CFMBUQvsOaYJ?= =?us-ascii?Q?fwf1Au3OrPGliSsO6pDh9jgDAWbRoUvwV8dll+Qy9rPAJPMitZXEezs0/m8x?= =?us-ascii?Q?tJEC2NIDjjAcwt1Bla2+C63VxyPdhvcBHs0Zdvytr5Ee80/NmXSMimvweMUR?= =?us-ascii?Q?9z2LxjcC+gIAI+MYdpwxCJiwVR3E23ligb8EAp3SEmk21iZviftU3PKtm3Lt?= =?us-ascii?Q?dYQ7BGDiDIZyPY9WRJgHNKzdKPAibFr2HHMuxCQZlpnzFmo8W3CLCWrMU4Kl?= =?us-ascii?Q?PguJEDqX4R2/KY1ByTfg3NY2cLeK6aYfW5r6sM1KgU2yDhMjJWTV+htgHhkq?= =?us-ascii?Q?d0gC1Q8+a3Xxzjp79Krg69zsbiNrgn/LTBUwtdbOPASpmmm/Oj38MYcr+67R?= =?us-ascii?Q?T1iNoGSML4Sj10qLFsYM3bydTORA7KLcamt1XHaf6RatA0gxdbjhBfNWq9pW?= =?us-ascii?Q?emSsSZNQj5+RfZIRwSuHcr5KgzQ+MUn2LfGMyZYQ3UdbmAcFDIqZTR9X2828?= =?us-ascii?Q?iKIv1Z8xOxGbQ/e8lSHmGQwnK4QiRef9epPvlrGugW2cj8cXxjmWRMIc0Cea?= =?us-ascii?Q?IkSESE1U0hKIjFB5n1yUTiPvNw4jJiVARbIAqf8zZCxtrO1DScTc+/UKajzD?= =?us-ascii?Q?QnWksEBs515n8F8aqfwLuOVNg1hIhna/QUI1AVazsQS6stbNoF7YQmG0KT6a?= =?us-ascii?Q?+7gbr1boN4ge8/g8UoLQTII+mF8ORqnlKWMPUKEJKc6unEXklM/ksLuVIeI4?= =?us-ascii?Q?nmd27jATAmVlO7g35ktu3SCuB4zjNQgqw+MmeXYQ5kgUQ?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 6:UrrTDTO0mQTtyNtrB7h/Ka7GOEbltcb6OY9E6x6X?= =?us-ascii?Q?oirJph4Ek4EOkVraGHhOtiEPbGgmpV/muwAjSnDBowRbZzhzY/cM2EFK6Dwa?= =?us-ascii?Q?pVNfFREzpUorIrOBkUeFki1iUuIgJ7g8rbaZ8QdbhrrUAr4kWhGHzKYGw3p3?= =?us-ascii?Q?U78UAaxzGBPQ26k24cAwYrccSJoZbovoZfWNzEvSNA/ntMU7GTMLKICunuPV?= =?us-ascii?Q?qgEvB+NHQ5f1w55DEIkfbHWh0vFJ79C/nezaA42dGkAnnhx6vYkBIlqWxGJt?= =?us-ascii?Q?srUYBqb1Sbbr5Q4ngVBSP3Wsdazb/hocSY+yHRh70TyOU8sei2q+2NG0NmkY?= =?us-ascii?Q?HUW9J1TF32yMZGgz3KmeVdgXszhwycNsXZyOBCuJgJseqf7PTdb/aessKMxN?= =?us-ascii?Q?l//O4RzMQNxFK/QnMXyHq5He0zi32wJ+AY3EXf729NrbZtPDr/JKhWtarubZ?= =?us-ascii?Q?88PPSl4ylFmcfCo6TIW843jVQdDOnFP1SmmJKCx3GeqvYdDdb03xXC+6p9fn?= =?us-ascii?Q?SI0awNq80SrjyCmQzbw2ESEacr9n+oww+Z1XOjB6FuOTLQ737NA3IG4JNc/N?= =?us-ascii?Q?Y2iNNHYR1cGIkx+kJTJW0J1kCvaUGfqQ0csjtOlskVBm0XMoPUld4yb4OjKs?= =?us-ascii?Q?Ddkk+fqlIa2HXxcp2Nud18HMDtFlTiiHF9Zr+JyItavtqpJ/PuFpR+jlnR3X?= =?us-ascii?Q?dxRxyC1rsEaOOAOvaWBSzjgQ6Ka4JH86kixrP2q2Gy7/vM/cl+m6HH0/uVwV?= =?us-ascii?Q?vXdFE6BdaH+Dvw3alE9ThAP5f39+F0NKuAD3FhBieT01ba8hfUlh8HDp29TK?= =?us-ascii?Q?MW1PWRgBPQMhgntPF2ElzOtlgpc48igULJMiRD6QkA3h63WXY5rkgfxv+l91?= =?us-ascii?Q?61VRTN9TGwEbdN5Vy+ia5OkpJDAGfduEJ4xRSEbj96C0vI0KyWynNo7l9KHe?= =?us-ascii?Q?xqLfp8/4AK81ST62zCjSM1jYlXZt4t0kRBfoEJBl2GN4bqqrN6VXACC0NaEi?= =?us-ascii?Q?jOQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 5:NFHUuRzHa5iUJ4BI+TyjwF8CpNETAeUUkq7bQT5srD36HxEG8zJs+LBywyqSrxz5H8b2o0Ruxz9HVgAL27w4J6T/9Y3HgWXpr7yOUIk6jZBFISPTBpuiqd0Jl5cXMFXhXZY6qQCiirjfW/X2kfCKvd6tSluJF708X1PIs6uHV7kL6x59jnAknfmaIvhy4RCLcIC7Rts2aP55otW4946hTN9gWTE6nr1ousOL03rinhsGvfF3gA0iBNyEurpfzI4EFXrOBKisBat0+VtueYM5S4OhgeL4WBUb0xtqHZSjP6GqVtKpuSYhkxIA3hyeI0iaWqyQ022/PdcRmtFw9XESSMgJOwP3DMke+Hhu+tqpdONLK2SVUS3DzbSIHkJnZyC2BS6QpdItw/y4yOMWxq0Iqf93vTwEIz9bUNcNs50Js3TW95m+y+MgSJGsIrgYFqrh3Rj7Y0OSQ9v3zojbgmay5zvKVswmCksvTPJDc7M9chXByb8PHyNVQXrGz+Lda5+H; 24:rBT+igmqb1tw9tJ3FnUGGxAkAikaMkxCb1iTJ1h6LdHve2pqxpEjV4iYw0bDk00yQDiAC7XUhIS8pnMq1a20bDfdKb3QWv99pmF3z0Jw868= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 7:wwNs8Za4Nn1JyZHaLU9K9wA5YRtWnwLCfEdWMHw+eZod11sPwneLp6au65qfGsaD8bdkpQ78QWApABnD+34O5BFcUQniyAELqzBbPHGSpSUZ2tJ12U2Dl5QRYRMn3Pod0sOCpBEQIVLOGLjaXHMrhmJKa+1poIenuPQmdiCy7lDEr7dkZoULjqzFhufnczDcW56VC1xl50excOHqGDa7YMX5AgLd96Rva96hgWu4dBcs3rnKOFfSU/8+pP+vuDr/64NkkgGSnLwdfQ7TMcEVXDd/rV/EUvpGftQSOtCh+yWQIrTLOBh/L7wU7iKCgRm0oJWhNrYoq7ILwJ1o2SGR+t4oWXc5OL7aeOhE8hHzlYVnilQBDLQpI9rhXR3WhVlHVtUJra1XITJI0q6coFc/AMeqpWZ9OZdFEdi7GhFgth+DZtcOT26+YCVSn2bZPEiwH73p6DFTyEVVZxZczsG0U9lcGOTcMEBIUPCfZ9DWH37MfH9IFKyfY5UUqaY98hGWThj3tQ2sgGHVfQyqxP12zPwGpKdZ3uNIzEVQZq4AcqEalkK4PhGmDaOtUaRYTixFiy/b1BBwxdgVAL+LVx0pGvCTbzCifvN24yBVfUtGkXpj7k8ARe/q/Pf5XT0rp4978xgoctD15krDbfMmigbDCWs4pMqS4V17L5T07B5boLFqZmY2N/yeSnx4aa06Cv88LupAbSud6vmVTP/fF47LMwO7uFpgFWPEKP5TXYaY3ssNDxuNYQcK04uoPEmAwp29NZvPPsJcFAh88rlBxKp1t4sjRrcZwjI3ZK8PcAUsh44= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 11:56:49.2365 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 11:56:55 -0000 On 15 Jul 2017, at 18:19, Daniel Kahn Gillmor wrote: > I'd like to hear from the people who are doing full-take network > capture > within their datacenters about how they protect the security of the > internal decryption systems. Firstly, they generally aren't storing everything, forever. Most of the time, they feed into collection/analysis systems, and most if not all of the actual packets are discarded. In many cases, they're only enabled on a situational basis - say, a security incident or a troubleshooting session. Most if not all of the packets are discarded afterwards, in most cases. In most cases, they're running on completely out-of-band management networks, using transparent taps or SPAN ports or equivalent. In some cases, they can be used to intervene in the cryptostream - but even in that in-band case, all the management functions are still isolated on out-of-band management networks which are not interconnected with the production network, and are further isolated as necessary by implementing situationally-appropriate network access policies. > It certainly sounds like a tempting target for any adversary > interested in datacenter operations. I guarantee you that your bank, your hospital, your insurance provider, your credit card processor, your retailer, and/or your government welfare agency are doing this, and have been doing it for a long time. It's quite common in the national security space, as well as other governmental bureaux. I'm not saying everyone has implemented this perfectly, or optimally - but it is a common practice which has been going on for many years, and the loss of the ability to perform these functions would result in a net security loss for these organizations and for their customers and constituents - i.e., proles like you and me. It isn't new, it isn't unique, it isn't a case of a small group engaging in special pleading. What's amazing is that very few engaged in this discussion seems to understand all this. ----------------------------------- Roland Dobbins From nobody Sat Jul 15 05:00:06 2017 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 02EA9131B1B for ; Sat, 15 Jul 2017 05:00:04 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 AKLz48Cmxmsk for ; Sat, 15 Jul 2017 05:00:02 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEA3131B18 for ; Sat, 15 Jul 2017 05:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GGJRMHV1gKBkcKvo3DKZtgaWZkAbw07bHaBd0nsSvwI=; b=ht2KNjMGUNabOmD/DM7yf3QCt/j/AHgWpLH1qAZ5qb5lyQuxY0O0Q5z8CMHjsqomsp+YdDwIRYHmNt4clgdGsKhHPi0ScRyFuuC1YI/bmpKllrmoG1q1ZXJqPblRnbegWTGdtxDyn4AUxs3ThaR9euFgvAwa42cLZ+XeDWx6NM8= Authentication-Results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=arbor.net; Received: from [172.19.254.116] (49.228.100.193) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 11:59:56 +0000 From: "Roland Dobbins" To: "Daniel Kahn Gillmor" Cc: "Russ Housley" , "Stephen Farrell" , "IETF TLS" , "Matthew Green" Date: Sat, 15 Jul 2017 18:59:37 +0700 Message-ID: <14403761-47B4-4F6C-BF89-2553D180E776@arbor.net> In-Reply-To: <871spirljc.fsf@fifthhorseman.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <871spirljc.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [49.228.100.193] X-ClientProxiedBy: SG2PR0601CA0013.apcprd06.prod.outlook.com (2603:1096:3::23) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2b30b56a-2a23-47e6-7a5b-08d4cb7903ec X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:6IT1xTNo0B4Eu3uzz+6bp29nT/EHwgFnpNzKIWyWVqnJ+DuOpNtVmpAIFNjrwK/E0msbzCrcFFo9P+2OrKkAP3rF+ihmelm7cmpo/ju6XYogknoOk5GVfjj9z3M6DsWDcvUY6zTVEbkEtOmZuX5cKT9auX7o2RPiDQiOZlHmga/ofJv2ASgtgDa5Vt5cPGpCgCYSLuFzIId+BBjVlXaF08GvgNfEPY8GeMzEOxtBzOtepshkZ9l4OYlSB7Rn/++7Fkv/LGe5FYZFxo+rmX7F3BzA/ErF4KXPMW0zhAGlBn6SaZbQTMPgN1bde6keKnSw+AOIxqsGvkTV0LXun8Sp1gJq8Go2e/YAP7U+4hs1kpWV7f7vschuvr6ALAQI+cpg28jxIsKZounY4052+2Q/k/pD39kSvkI9Arh37z88+LnxruFOdIzHqtO+X2Cy9s/DXJsHqnnyExyiaVx8Rfqf5MaijPHaPHm4Q/e12m1Znp4dp8cmP0b4a55goSZL1q1R60bkQDj3asccdCUM2FfXIdSXSfxD0hnOgHEDxfIGWXk24K9qznZYofFoyito8HETPeL/6SOsAS42N8lZxbsI8BI6vm5lMlhbisUFqnFYK+ydCofnRqINmt2sBERu5ta+n901m29+lZaBr9DgDJ5i1s2QHikttEq9gWhsb0vBGxr9ByYbZwm+A1R2peDwROsG55OmuASOQdlWNCRgpTTDFhxiXdHA1Pa6WSFDrx8qpKw= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 25:UVji6XlNxanbCGFwTQOCWKB40ViFlGOF5fRdWzEoqaPk0X3HmzAym5+VmcCwqZPLuZLK8jbiJugc6Q1/jNyH4MIqJHXSs5rYvgYgjWOsHWmOQkX4uoadi+eGSTGqPEGwjOPDeGhRbMKbzEazWnlSMIes6j2OkupY/WYY7mRJu+XpTmK35DvRnXNeG3ZkUs6JVoJji56d+FRKW/e+0WMP/Nt3xjaud3mJZtfaiZcP7UQ21TqHuf+kdA8XFmwlkNuu5Z7Z1oQ1PqNpkP1TNqdIbRKoPFwDiZ5lEJGaj598BNLIsS7Ov5EVjTVPAFi09JXe3de4A74VlBRuH2h1ySFruze6lW5vPjzNciZXjuiqBM8FvrFyQE8zCQPH9ARtwkB+RAiHk1BvakUDJYlC9YcDSJQN0rF5rRWP9xJ6J6E/AXGCEcq+j4WEWopspoyUUTHGpQkvctWKOAlTFoAGc1GXDWs6/V1UiaNtCyjpA5Rnpq+M4k9uey7r/yFC5O80Q4kbEyvmUDH+gcaoLref8LSHovAO5O8zTZGsF4LBD6o/H5+mp9QtXbc1MJOSgPq8duekf8aaGoFqlSeSM7nCfgRajmcG70JJmcQ7F9vNcsbq40EAeN/O6kmpab1/TBSc6qV7gvonitMZljl0rbW5xd3RtZAfsIltat2YIhxZvCkOSw/naAAiSVEbDgoQ7+JZWFBvvWHBaDJ8dxdFYXGu/2Y5xGTM+3Lqy3ZDGttjse+fK4dY+9XqAOJZlznmF/Y0/5It/HjVzxBYlEZczd+F+vSO4vyKYiYk27M4yK3Kiai1xjQMLOi4dd2UxKt8iXQPHAzJr4TCip9EAkMb5mPkCm0yi00ncI5gaEgROxjq+t5W8qisoJMgvRFkNc3PosY/U9H8BlqzVKgs1/eibZNke7zKPggVBePCX5gCH34RM9dO99c= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 31:S4wdiU+tbWcEzy8sUnglcaIFKYikxw80aLGysmicGgs82XDCnf1SOj9wf52OQ/VV3yJNRftTAMlCfULSHagHiCLXDOFz6T31PmCEgJkbAjFPvGKAK0duSKgEqdLCiLV8rE1OOH6BjDUS8UzBaie4Ppx9tbrOXXuz3NYQ3f7OTonQe1Xx4pSpfYusZMx/MUudOz7lITKyD1N5tp8oYWkflKDIsMy6vQ4xnoR3B6AQMsDL0sgWgR0AJeT1UQHcykNS9ppoSOUKoIF0MrSHM3ZQ1Kt5nbWwV0A9a3+vqls3nZSvVM7NydgeruLmDLefhOYxcbOvyU6+rx3L6GfcdBU9gsyVLVSUnIb6iS18KbNZe5rKbJx7hm/itSp3QntNHo0vG+V9SnvFjXlphqxhJw2ePg2C9KNVNcRR110VUfvzRfIri1BN7U202AblZZcLYFARb8DoCy5yDmteBzAPTTm3bxyq9O9BWVcGU0rKE44JzZGRaiJCEjhGwpl69AwVO+Tky0utqAngcTqLWBgosAU55CwuCuPsOAu8uV74B2TviRLPMClp8TLxyc8KlWMMWrOXBnZzWVy5bhzQXSxIsF9hJNI5GvNMJgJ9YmSRg3S6YeRjQQZmNEGP9cyI/phmVe5M8oJ5VXfL2o2oTQRDKbtG2xQyyzKjFLc3YcEH061sQPI92fs2C6GeVi11JI+k/t0v+yQSDDH9wPfXs52ITa7gVQ== X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:2YN3GvyrY2AMIqiHSV/2W/JDQzyglNPx+HzXjWLrT+TD/5OGoRsd98AuCYOi+dqTfLzgUsq8swGQCu1dcTCZ+9jCiY3xI7Vn8oEc6LGCWHMerWPz9EXxAgXVxAD7pplTAJhmboXaOdYMDqccoYikNXAblFor7ScT82KPeZs1jRX3aVT+r/dpliaL6m8k1DdL28wO8dUlwYLcRJ3MK0S4DC3cN2Dowdev3zWyvVcNNRUuos+zb9GwXwIRkCU2mOK1Od6ul2/el//Zs2d3YCjOVk7VJic6tGMck+FzSEFWqiQle96awFiYALA1iubqCfKd1+H210VgCs9NvltZvf1YVBU8Tgq77feF7JYZEAl6bV9hrmyXMNrYSNmWbzuZ6BIe60pMHeIZE2RUgzR0jcwh5EemVO1W7pY8T8i+o+PXUhHLj0Jh7A0lQGT5hWih5WY38++2MJ+QNaQn4YApGYZxJb+6O0XExJNk+SOVA0PsRtjObZUevccSfrFYWAS7iq7S X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(192374486261705); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 4:CEZg5oa7usyUUyut996ZDCcfbZxBR4d8WBgxSRc0?= =?us-ascii?Q?SeTjBKAM3oNgOViPa5lRtiQHN4it6vnPI4INZRtEsAyUi3bAuOQraKzLQukl?= =?us-ascii?Q?HAZ/MfNplrwTph6HLZY3jBxQkWSlDYDI0Uu5s1SDWz8gS+RNk5GGdnx9FArx?= =?us-ascii?Q?CMzlhtMRDEnt1eJDEFGTa6zBXBdAvxr0+DjbJuLQa0qzVQFdTjZ32CL7GNWw?= =?us-ascii?Q?JtObgbhpFvW0creJrn420X0ZEtUzBa/DMxb+YlBqHW3MwkFSj/Q10BH5xX0F?= =?us-ascii?Q?Zc4mxsH48fM9eIpgHXL9jgg3WVLvWlQ2HQ+ywEtdsxWFePGmacrRsgB3fMSl?= =?us-ascii?Q?FWi+aJjgOkznc0HXc//wrMHFsV6yz+qz85yY20JYvNKPlTEIXJVI2c0O1UzD?= =?us-ascii?Q?fA4tIYftC7EsbJ+TdZI9/y7Rzf3/VCcsqFbQwSdKjsODyoEIB7UJ09M/cEhq?= =?us-ascii?Q?Pv1X7JpSv7WDxlaE+iby9BAyRYMQlEjSBvZAPkyDeJ5YTmXkoD5sQauCXppO?= =?us-ascii?Q?BPlD89L6yw2tcSFhymUOGG7Ie0EYeAdGPDwxSE286FZn2xX8kLKal79Kjddb?= =?us-ascii?Q?xClWRq6TYtmcGzsA/oIUqF1H7lLlOq564x6UcM3R9E5Q8H16G983FbP+5oVW?= =?us-ascii?Q?gDXZpaIpqwHxMqfmnerootjddfniBuVZBEmDovTE0WpH0uskAeAUXuZrL6FQ?= =?us-ascii?Q?nkLBlYwNyctyJ4dP7NwnRab3ZC8W/TzSjo2LUddrmRaH4mHl1xZRy/5gjjqn?= =?us-ascii?Q?dzkRYEjkdfpwQ2YROMsHGeWcM/mD+P9+2iHrp3G79bg58zzGFxk+e43ola8T?= =?us-ascii?Q?w7+B8XsGPBpKv7Uf7b/EwMFfZ6JogZCxKjDChg6eNL+bu8D93rrx7KtuEy7r?= =?us-ascii?Q?RAaZNleoQJb6IrpKIrh26hAkPLkr2WFXdIz17mup6jIDkQoH4hAMJt7QDPC0?= =?us-ascii?Q?5CQGjWvC0oCvfWIs10BTK3I3XkOFXtjGuRjL6Vz9YtbAnAMKFov43ScMfovB?= =?us-ascii?Q?dXUnBGzDZP1+/g5LD7pOJdM6COYqL+NQ2XzvMhUoOFiuhestOLtHt5X5WNWX?= =?us-ascii?Q?amFaSAkzZmoGbQft4yDV/MGulh6yGu8msEReELSPZIH0SEqdxmxNmB3VQsHI?= =?us-ascii?Q?NlDA5HRiv9DXeCL5rtKBHb20dEvbiVANT08kCPK17jbDMpX7fDauJ0tS/W0J?= =?us-ascii?Q?lx5XhKAhuUwwlSuzvMc5WHPAB9leG1QMNUAzu6gZf+yQjScabM90GBzbI71x?= =?us-ascii?Q?TWLJhEbGMhteP24hBZo=3D?= X-Forefront-PRVS: 0369E8196C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6049001)(6009001)(39400400002)(39410400002)(39450400003)(24454002)(478600001)(189998001)(3846002)(6116002)(93886004)(230783001)(305945005)(33656002)(7736002)(42186005)(76176999)(38730400002)(110136004)(53546010)(54906002)(82746002)(50986999)(2906002)(53936002)(6246003)(77096006)(66066001)(6486002)(6666003)(47776003)(5660300001)(2950100002)(4326008)(86362001)(50466002)(7350300001)(229853002)(50226002)(81166006)(36756003)(5003940100001)(8676002)(6916009)(83716003)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.19.254.116]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:aqMAdNzIwD9+MLEji3ibt6TfC1OEGV6+8li9hIL?= =?us-ascii?Q?5H4yipQpMbvBYsMiIG2c4gFv2Un01MzIqbOHXp6iRJE3fbhq/sZ53Cq6SAsn?= =?us-ascii?Q?FKCjMDqT45Wu38T90dEyLwkzppkbucd7pZk7sTpzz8MbzQV4Fz37W9BKZZR2?= =?us-ascii?Q?ckji0TCGBimZdeuUD0B5vPyjayK2hU5X9CUWlPeOUQNGygbqkNEf1HpkyQIR?= =?us-ascii?Q?PbF2u9fjVPEnOGsjn2UFABurm6rPPOv/cR8Eelr2Yf4LzP6S5aho1DduKwxO?= =?us-ascii?Q?hubIfe5TUeDWqq571R2G5TdQ95Aw6WiG0+7ynRhgP1H1RyOvz74S+8A+3Ddb?= =?us-ascii?Q?OaEcY92a0YW1Q5gyLD9T4cVUCOdpeuZ4/T9i6H4En8jtS1yupVx1qiO5poOX?= =?us-ascii?Q?6qmSqkPbAA1IQQUJYwjeHlFdg9tHj4iiJf8zqHNW4ZnuRXS+uVMbq8B0wmya?= =?us-ascii?Q?loMFRZvZas5nFKCd9X7nKOyDbq63NjZkeRQ0Se1wmQxGOd4isMmeFYcj9yuG?= =?us-ascii?Q?+9OG/uJUPx2LbB9rAvp0lzvopQCqRwCXrHq1HutMUlWDzfxwAvMjL+ui7XIw?= =?us-ascii?Q?KT+FLeDoJU2Dhrz40u5MkhR81nx+eialeHJ8pjXEe8jub18OK2IZLhZ9xnl7?= =?us-ascii?Q?hlAomLZaCFIOU52Jim/uMICUqpsSOgHz1LmcnBIlOtWkvF/LpwTdzjXOlzQS?= =?us-ascii?Q?/2Rf4onJtSHr1M2Ec15zMHIsaJMEkQvaBYh/3l+Z+R1UM5RF+anZX/UascBj?= =?us-ascii?Q?Zp4z7OnLJRL0A5t5OCuzjmcRH/PVftHYBmMzb/mBVLFB3kCfc6EzBwdTNc6o?= =?us-ascii?Q?r8oUu2bPZWvtWOXjxubdLdF6TdSr8k38O+r8aXauNp5v2aRDgLNZzpleIuIv?= =?us-ascii?Q?2YqYro/P7r7Vz4oMfkd4Yrmk3fQRedOvFN72FAGpUVJwlFOKqSlZ6/scvRPR?= =?us-ascii?Q?PYWb91KFC4BIJqUDtXqw9wuiKl9pwO7M2oHlRZEUsrn8kodupr1GtlGlT18o?= =?us-ascii?Q?pi0KBZnM2vBdUjetMATNpFpfLCVHgVOlgiNPC496hZcpn8lezFPrLyVwS81X?= =?us-ascii?Q?vGQk/bErkLYLdhEMYkbDLyeQyfJYkWHf/7D/gkBOZaFYB4kqF82mOsCa4kWG?= =?us-ascii?Q?GnpHatBVjm9vb3UALCOlTIK5C5P9v0t5aOxxo3MPUGews6xx5pGapMchanis?= =?us-ascii?Q?Qtk0F7hKE029Ipoz2TY3QultLXDJyJa55iRft?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 6:E2Xj67YT0fhjaLWGnWUyvA1bxZcT+FfDu+UySY23?= =?us-ascii?Q?iED0N9ZxmMDHaHUqK3bAt3gV8ZjK6/hqPFG8SNEsVbUfhowN1QVvC8yDWQWB?= =?us-ascii?Q?edSONXx4rMzBAFrgFApwmMcIt4FpD03YTBC7WfQTR3udzopMFgaIlm8Nh7Uj?= =?us-ascii?Q?OCe1gJmiowJ5ZfFVx+rapaIRDxs5G4d4MznVnOZe1AheP7Il66vSd+iqMqzk?= =?us-ascii?Q?de6lF3nEOn74b/LsyVWIfnLciRu996Xfzi2p4AN7yQ1BqbJmFafFpOYKKyqc?= =?us-ascii?Q?VjKHlbTwePExw3gStyEz0Ued8fBg3hUiW4qtIFkpeol5/ZVTufPpeHDNindY?= =?us-ascii?Q?KwirH6NwVjHqlg5KVXI8l8PTgxb+nOY5vE1Y8oDYzTAut5FtLgpJXm+fSiHJ?= =?us-ascii?Q?TOuVE48/vR3whex9SmZnygmOsm3xAfSnkISVE95iTr9aboDAwb73Lj8qLQD+?= =?us-ascii?Q?zdE1M+tXgyPltGidBi0pVXgHeSKZmDyaK4ce0Y4WVhhS/f9kwG3tcSoKOADr?= =?us-ascii?Q?XXGceWUPl9uP9YU0429sD5Ss87cToVyU8SlrG7qlH1FqN/y1inzK9lt0QAm0?= =?us-ascii?Q?aydd7hXOLwJCbjgZRlskPuaNWroQUPMSAvsZZnW2UTLwNLNlo+/IbsIwf7td?= =?us-ascii?Q?Vpo6oobr+dPmNCse4Kq3PkP4LmJsrtHhXekHGZK91x7NSNMckmbQYDFoPB7X?= =?us-ascii?Q?faOHWeAtd9Gp2rjoeYy7oCD8KOIL9yX48cgKBFrNVJGY48xZ5hUyhZEgnx/7?= =?us-ascii?Q?8IEFA+mW9d9y3/fTX/ceAsovT1hy5Op9RgLY0sqPipKl2aY7oMxzxZ6GBwtu?= =?us-ascii?Q?AC8D8tvrJjrXfOTmuAFb5y/j9/vzAS8iqYYuSnohZSd2vN9Wi79YVMQxlm13?= =?us-ascii?Q?g3gjQC5Ou77wQ6kXgwsDk1OVC90P966HRYHzYu+Ei6YWPwzgVY8hJTa1zISR?= =?us-ascii?Q?OFAKmEvtI7TGqyXIUoWqbjFFSgSxKA2iRxbsw1vdDb6d71BKlpJieq6QlfMt?= =?us-ascii?Q?gyc=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 5:4wxiDIhvb8Q0XhvH4mICci24TIeufT4qFpHhq/m7V3fcA2qZ2W2RFWhSft80woaZhZ1mqrvnKCLZgmFRpE8lv1KCKZlw4q2MwdSAI1iPPyHuy1NAAtun29xwVP3YLI1zYvALcKoKuC5LRB5z0L/XdxFXZnCrQ33Myeza/iCUZDwfd2lzrQNNEOyIERpoZ7W4WqNPyPP2x58Zz8JsqEEfx9ELvV2Q/6/rDTE7y7/letgF8iE6subgZR8KVABMbsx2BycBy8gcxVXqyujyfexeWrTPAIYkX+W2BB2ZLiuYbyDYHkd7fMI38873DwD4IkdbFX2K96y5eaHoIHdUVCKDVPyJ9ijyz3YrLYU54PF9Fot+mt8iYYu3mTS5wEp1wTLcTatkfxSW0vV9FIxsOTjN+c0XosYh8VenT5wqLBnZbLerS9dkU5s/80Q5Okh2OJeK9KXPimDTGV3+GSktD7TYYhinI4pEfK1QqwXuOvwh3f1rLnaLHXtNOrA2iednTwOS; 24:RPWZEzNHm2+kVIFQ6sPGs8iTPIebrT07iioNdEVJ3Nd1pBDnWxgGVdzck/AamvT8pOIb2H2UBS7HdMmye9dtmrmuGvfy5fh0Vm9OLPsStdY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 7:ORoS0bOJj/7VFiUrHpLz+nMHgWLJnhb4AUsWIvb/tNbX74R6yQ+loYdG5X6gUfLXjCXXEUJHF8BysCLN+xAafpQD2C+6TAF6iw8bEL/e+1Ng+kptXYttIqZTIc9BdpOlKndRfbvBkk35VlzddluvjAXSfB8o2wWl9eYs/a9hWRWEm5kkDTTdtvX5SRR8XFJoiU3NnmARGLDnxPUbejw0pvEW48Q2T4O8MjuQh1kyYxD5pE5SEfm86zwFgwHnkKYcAxFQsV7zCcN/0sovfL5cSlqC7ucKFSSkJRzHqEy3kv6afG6YrVlejndL0+WKD9CjgUtXbr8Ade5Q+GyaqABVw06A/rt7nys/27y3pqkjTnNRpQMWIxdrPATQovUbtdNq1FcMwBFRaEt82EoE7T7Yb9s8IxIiJx7tSp7v1nru3YCFVUE84U5Jbf8qbjY4CYV2tPJ+zPagN7K0Y/59RBEorAjPB2G7q/jSMMxR29niISUZcShTvUsI/WlCOYywspuLTz0ijyf1mWq+9VfnuSfc89EUJSGo329OKL7Kl4rv0WLvjWTC0QnQR7NbyEYEqcUeFo3B5XjCYwBADhJF9XzEOv691hPib2MqRWKaSIbJvi4ViZ7BJ0CT8lnUWmzNj9YXZU52bJORbNgc6FP8lNPQJWonSM9PXeHpOlb0FnwGZbP2zMyZcVu/hBsQnHQhtublHa+EY/4WEH6yhoPRMDtGoem0KCehChgz0SysWbF3jmREHF5o8CE6WS4WCUlfJL3dYlv3DKr+HY7QmCML4yTVSIh/Mt8xTUJFAU20J0s9/OI= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2017 11:59:56.5424 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 12:00:04 -0000 On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote: > Whether it justifies a loss of security is a separate question. It isn't a loss of security - it's actually a net gain for security. Network visibility, independent of any end-host, is a key requirement for network security. As to the specific regulations, folks from the appropriate verticals will need to speak up. I know vaguely that there are regulations in the financial sector and the defense contracting sector which apply, but can't cite chapter and verse. I'm sure someone on the list can, however. ----------------------------------- Roland Dobbins From nobody Sat Jul 15 05:18:51 2017 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 B5354131B16 for ; Sat, 15 Jul 2017 05:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3tkL8LO6sGax for ; Sat, 15 Jul 2017 05:18:48 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD291316F4 for ; Sat, 15 Jul 2017 05:18:48 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id c20so13013969qte.0 for ; Sat, 15 Jul 2017 05:18:48 -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=3SKaodYZmdAoKwwoFOe+lYDMw52EPkDFC57nO2nK2xU=; b=M3nDjhipGUx5huOn17mu7TkRYyLq8E+wQpm7SF2ESvrRjJX+q+GoVQQ0q0O4yJdylN bBMCn57OI7Y1zofTWfa+L7YmVq1M19Z3jhR2/G0tjkTMTMZPO7cCSZjVebU8XvfU0RUK lo7BHvCJceE2CDEQwc7uIRqaJ62AG9Odltxcs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3SKaodYZmdAoKwwoFOe+lYDMw52EPkDFC57nO2nK2xU=; b=okvklpnhJO6gcwWIWOcWyWb0ulSPGi1JH1KJOfRn21zk4lQDHJGr4P9F9ZjK7yqopz HC55jLk9XYzdMtCg0Ej0edWFAGXopUuySH3V40pJBfdGenMe82X5tBVfesXlUts0O/cy P9mvXMxG8wOw50+NQDY4pVe/czyeqPtnsZ4rOVUn//ViDbgsdlLHpzGIROJ+5GGycFyz 9tC/l/+6g56tN/9gnTTwBYznJk2UiB1RwTuzRuOj7OE5zmYjhMixqSJ7K5mEWtWVCPHG 97qFLjwQOQj0QNSxAIWqgPccvZR9hh6OTpSqo87KxGIaY9pP3nEU55xW7r6CMfxrRF93 AiJA== X-Gm-Message-State: AIVw113ivWS+SLlqvMfwZ5NYiw24AnrMiYFIaYL3gB/LdBeLvOK2edWA r1RFl/OSurzEI9+3L8qo5g2u5fQ8vcPs X-Received: by 10.237.52.161 with SMTP id x30mr17790039qtd.55.1500121127021; Sat, 15 Jul 2017 05:18:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Sat, 15 Jul 2017 05:18:45 -0700 (PDT) X-Originating-IP: [31.133.128.218] In-Reply-To: <14403761-47B4-4F6C-BF89-2553D180E776@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <871spirljc.fsf@fifthhorseman.net> <14403761-47B4-4F6C-BF89-2553D180E776@arbor.net> From: Kyle Rose Date: Sat, 15 Jul 2017 08:18:45 -0400 Message-ID: To: Roland Dobbins Cc: Daniel Kahn Gillmor , Matthew Green , IETF TLS Content-Type: multipart/alternative; boundary="94eb2c00560ee5b70905545a2a32" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 12:18:51 -0000 --94eb2c00560ee5b70905545a2a32 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins wrote: > On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote: > > Whether it justifies a loss of security is a separate question. >> > > It isn't a loss of security - it's actually a net gain for security. Security isn't a scalar quantity, so there's no way you can credibly assert this. OTOH, it's easy to point to the individual security properties lost by expanding the attack surface for a particular session key or by mandating key-reuse. Analyzing the impact of any particular mechanism for middlebox inspection is a question of tradeoffs: what are you giving up, what are you gaining, and is the trade worth it? The first two are questions of fact (though I'm under no illusion that there would even be broad agreement on those). The last is not: it's inherently subjective and among other things it depends on the threats, the alternative mechanisms available, and the value placed on the properties TLS provides to end users in its unadulterated form. Every one of your emails seems to boil down to an argument of the form "Organizations have infrastructure and operations set up to do inspection this way, so we need some way to apply that to TLS 1.3." I am unpersuaded by such arguments as a reason for standardizing a weakening of TLS. Given that, I would like to understand the origins of this approach to monitoring, as that may shed light on the hidden or unspecified constraints other than those imposed by TLS. (For example, if this approach is deemed to be less costly than doing endpoint monitoring, or if there are insufficient access controls for entry to the privileged network, or if the privileged network has systems that are too difficult to secure.) Kyle --94eb2c00560ee5b70905545a2a32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins <rdobbi= ns@arbor.net> wrote:
On 15 Jul = 2017, at 18:23, Daniel Kahn Gillmor wrote:

Whether it justifies a loss of security is a separate question.

 It isn't a loss of security - it's actually a net gain for security= .

Security isn't a scalar quantity, so = there's no way you can credibly assert this. OTOH, it's easy to poi= nt to the individual security properties lost by expanding the attack surfa= ce for a particular session key or by mandating key-reuse.

Analyzing the impact of any particular mechanism for middlebox inspection= is a question of tradeoffs: what are you giving up, what are you gaining, = and is the trade worth it? The first two are questions of fact (though I= 9;m under no illusion that there would even be broad agreement on those). T= he last is not: it's inherently subjective and among other things it de= pends on the threats, the alternative mechanisms available, and the value p= laced on the properties TLS provides to end users in its unadulterated form= .

Every one of your emails seems to boil down to an argum= ent of the form "Organizations have infrastructure and operations set = up to do inspection this way, so we need some way to apply that to TLS 1.3.= " I am unpersuaded by such arguments as a reason for standardizing a w= eakening of TLS. Given that, I would like to understand the origins of this= approach to monitoring, as that may shed light on the hidden or unspecifie= d constraints other than those imposed by TLS. (For example, if this approa= ch is deemed to be less costly than doing endpoint monitoring, or if there = are insufficient access controls for entry to the privileged network, or if= the privileged network has systems that are too difficult to secure.)
<= br>
Kyle

--94eb2c00560ee5b70905545a2a32-- From nobody Sat Jul 15 06:08:47 2017 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 D8F4312ECCB for ; Sat, 15 Jul 2017 06:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XAyjsw8RSQuk for ; Sat, 15 Jul 2017 06:08:37 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176BC129B4B for ; Sat, 15 Jul 2017 06:08:37 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id c20so13121646qte.0 for ; Sat, 15 Jul 2017 06:08:36 -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=G8wkspLMMkkm3F+VMC2W38EG3lnRRTQW+CfKxkkMYIE=; b=GyRQA4x//iZDSh7sIfPQjgGpkH/XdxpGERWzvJnGa07o5GKMGNUEkfdKiq55wycF8B mML30IZjzd39tRafU2heI/7SRCImEeYYalIulA52mpay/g1DLyfGffVR1e52kycS4ejK ZNgv7pEnV5ueEs7F0E059ZtqHWZ9WHBLTNibY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8wkspLMMkkm3F+VMC2W38EG3lnRRTQW+CfKxkkMYIE=; b=pktpszRnHYHxS3N8s0KcVMH0BczoIkhgI8y3waZJSxCscI1XP12LxPbabXTMDWwh3C A5VnKEw3F0giO1k5xqvp0zxH91UWQXo0zKtzkEV/snOJF6MnmnJosRcunnyf0s6LgwYz YyBFiS+UzkWPXcF3Z926sHnXb3f/r+Gt2IEVB0soX8oK+znDqMPbj2j+FeOoQEGa9bBt Gm6E5Ba/QFw3gExT2GEI1ULaRx33nO0DEe27HOGp2VNOt64IEXBSqLPzrCLu9HfcCSEH 87+x5RvxtRZhPZpRu0dlB1EBMpsBcr/u9rqxLnj0bUyFu3p/CjcgTPOtrNYSZUKjDJ1F SCSg== X-Gm-Message-State: AIVw111xQ8KXvS0xDxCRcgj/2ZbAts5huPacx8kJzGUZ88WuJ6uhdPbX 4m2BYDCCbZ3aZq6Y9gTJI2g2WrVbQ+xn X-Received: by 10.200.51.235 with SMTP id d40mr17210672qtb.151.1500124116027; Sat, 15 Jul 2017 06:08:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Sat, 15 Jul 2017 06:08:34 -0700 (PDT) X-Originating-IP: [31.133.128.218] In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <871spirljc.fsf@fifthhorseman.net> <14403761-47B4-4F6C-BF89-2553D180E776@arbor.net> From: Kyle Rose Date: Sat, 15 Jul 2017 09:08:34 -0400 Message-ID: To: Roland Dobbins Cc: Daniel Kahn Gillmor , Matthew Green , IETF TLS Content-Type: multipart/alternative; boundary="001a114547be0e1f3105545addb0" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 13:08:46 -0000 --001a114547be0e1f3105545addb0 Content-Type: text/plain; charset="UTF-8" I've rebased from the kernel master HEAD (4.12.0+), tested, and force-pushed the repository. Conveniently, it looks like, since the last time I searched for one, someone added an ECDH implementation to the kernel. That makes this a lot easier. Kyle On Sat, Jul 15, 2017 at 8:18 AM, Kyle Rose wrote: > On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins > wrote: > >> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote: >> >> Whether it justifies a loss of security is a separate question. >>> >> >> It isn't a loss of security - it's actually a net gain for security. > > > Security isn't a scalar quantity, so there's no way you can credibly > assert this. OTOH, it's easy to point to the individual security properties > lost by expanding the attack surface for a particular session key or by > mandating key-reuse. > > Analyzing the impact of any particular mechanism for middlebox inspection > is a question of tradeoffs: what are you giving up, what are you gaining, > and is the trade worth it? The first two are questions of fact (though I'm > under no illusion that there would even be broad agreement on those). The > last is not: it's inherently subjective and among other things it depends > on the threats, the alternative mechanisms available, and the value placed > on the properties TLS provides to end users in its unadulterated form. > > Every one of your emails seems to boil down to an argument of the form > "Organizations have infrastructure and operations set up to do inspection > this way, so we need some way to apply that to TLS 1.3." I am unpersuaded > by such arguments as a reason for standardizing a weakening of TLS. Given > that, I would like to understand the origins of this approach to > monitoring, as that may shed light on the hidden or unspecified constraints > other than those imposed by TLS. (For example, if this approach is deemed > to be less costly than doing endpoint monitoring, or if there are > insufficient access controls for entry to the privileged network, or if the > privileged network has systems that are too difficult to secure.) > > Kyle > > --001a114547be0e1f3105545addb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've rebased from the kernel master HEAD (4.12.0+= ), tested, and force-pushed the repository.

Conveniently, it looks l= ike, since the last time I searched for one, someone added an ECDH implemen= tation to the kernel. That makes this a lot easier.

Kyle

On Sat, Jul 1= 5, 2017 at 8:18 AM, Kyle Rose <krose@krose.org> wrote:
On Sat, Jul 15= , 2017 at 7:59 AM, Roland Dobbins <rdobbins@arbor.net> wrot= e:
On 15 Jul 2017, at 18:23, Dan= iel Kahn Gillmor wrote:

Whether it justifies a loss of security is a separate question.

 It isn't a loss of security - it's actually a net gain for security= .

Security isn't a scalar quanti= ty, so there's no way you can credibly assert this. OTOH, it's easy= to point to the individual security properties lost by expanding the attac= k surface for a particular session key or by mandating key-reuse.

Analyzing the impact of any particular mechanism for middlebox ins= pection is a question of tradeoffs: what are you giving up, what are you ga= ining, and is the trade worth it? The first two are questions of fact (thou= gh I'm under no illusion that there would even be broad agreement on th= ose). The last is not: it's inherently subjective and among other thing= s it depends on the threats, the alternative mechanisms available, and the = value placed on the properties TLS provides to end users in its unadulterat= ed form.

Every one of your emails seems to boil down to a= n argument of the form "Organizations have infrastructure and operatio= ns set up to do inspection this way, so we need some way to apply that to T= LS 1.3." I am unpersuaded by such arguments as a reason for standardiz= ing a weakening of TLS. Given that, I would like to understand the origins = of this approach to monitoring, as that may shed light on the hidden or uns= pecified constraints other than those imposed by TLS. (For example, if this= approach is deemed to be less costly than doing endpoint monitoring, or if= there are insufficient access controls for entry to the privileged network= , or if the privileged network has systems that are too difficult to secure= .)

Kyle

--001a114547be0e1f3105545addb0-- From nobody Sat Jul 15 06:10:43 2017 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 0EF1312EC36 for ; Sat, 15 Jul 2017 06:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pWPJiiMl2vY3 for ; Sat, 15 Jul 2017 06:10:40 -0700 (PDT) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515D3126D73 for ; Sat, 15 Jul 2017 06:10:40 -0700 (PDT) Received: by mail-qk0-x241.google.com with SMTP id v17so13094950qka.3 for ; Sat, 15 Jul 2017 06:10:40 -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=RkZpPj8nv+DAhiUoLuezzA4HdQEMYjvAeqy9hruwY8I=; b=jR6XbPDeih8n49zkExE9A6zpB+dBUmpBpJauwY7DN5ldl46x+sh3eMiNXa0Y/tjM3P 4OlMemV8/fr10ujvEMb0jX3uzlHZzS81K4NjBE230SN67sLlhkc8FeEvwW9M6Wpb2kah GhCllpa4Y3LdvEZW00JUYEplnJQj/oTVYXBNs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RkZpPj8nv+DAhiUoLuezzA4HdQEMYjvAeqy9hruwY8I=; b=i2oCAhi4JCA2oT0nGOu8Hms+nRRHYkJVDUhkXMlLnYCVmwiTctXbNDsdPOfqLCHaSF NfpVAR+AA2l1XQPZ2Bbzz4Y6YUgHidRTIZDMvsnXBi3uY6qLr43jznoY4qu4c/QZinaZ ST/1n8NE0PLnJuxNgePl4YhobiEmh+Fyq3tCInf//azV4XicUEtuYmWYkUaN0tEejI50 elJ/6WLKHGiZPPhZyFohTh8+M72fbXF77pbUa934e6rAZkla/KUt7+TCz+DSpS9iJU0K HkfTSweft5Descks4N7Dzh/mWxBWO5uxEvyO8t0eJJgUtLvDRR7l3elCGktuqWUJBph4 +hBA== X-Gm-Message-State: AIVw112ZoNCyrOg/4jnbfV6XVmgaBt1JP0T8sKdrF/pPI8yUruxVS3K4 8meTLtQqs7cl0X3C2ngYUTqHUZG3qrac X-Received: by 10.55.145.6 with SMTP id t6mr16334903qkd.101.1500124239262; Sat, 15 Jul 2017 06:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Sat, 15 Jul 2017 06:10:38 -0700 (PDT) X-Originating-IP: [31.133.128.218] In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <871spirljc.fsf@fifthhorseman.net> <14403761-47B4-4F6C-BF89-2553D180E776@arbor.net> From: Kyle Rose Date: Sat, 15 Jul 2017 09:10:38 -0400 Message-ID: To: Roland Dobbins Cc: Daniel Kahn Gillmor , Matthew Green , IETF TLS Content-Type: multipart/alternative; boundary="94eb2c08ad4a6690b505545ae42f" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 13:10:42 -0000 --94eb2c08ad4a6690b505545ae42f Content-Type: text/plain; charset="UTF-8" I might want to try responding to the right thread. Apologies for the noise. ;-) Kyle On Sat, Jul 15, 2017 at 9:08 AM, Kyle Rose wrote: > I've rebased from the kernel master HEAD (4.12.0+), tested, and > force-pushed the repository. > > Conveniently, it looks like, since the last time I searched for one, > someone added an ECDH implementation to the kernel. That makes this a lot > easier. > > Kyle > > On Sat, Jul 15, 2017 at 8:18 AM, Kyle Rose wrote: > >> On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins >> wrote: >> >>> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote: >>> >>> Whether it justifies a loss of security is a separate question. >>>> >>> >>> It isn't a loss of security - it's actually a net gain for security. >> >> >> Security isn't a scalar quantity, so there's no way you can credibly >> assert this. OTOH, it's easy to point to the individual security properties >> lost by expanding the attack surface for a particular session key or by >> mandating key-reuse. >> >> Analyzing the impact of any particular mechanism for middlebox inspection >> is a question of tradeoffs: what are you giving up, what are you gaining, >> and is the trade worth it? The first two are questions of fact (though I'm >> under no illusion that there would even be broad agreement on those). The >> last is not: it's inherently subjective and among other things it depends >> on the threats, the alternative mechanisms available, and the value placed >> on the properties TLS provides to end users in its unadulterated form. >> >> Every one of your emails seems to boil down to an argument of the form >> "Organizations have infrastructure and operations set up to do inspection >> this way, so we need some way to apply that to TLS 1.3." I am unpersuaded >> by such arguments as a reason for standardizing a weakening of TLS. Given >> that, I would like to understand the origins of this approach to >> monitoring, as that may shed light on the hidden or unspecified constraints >> other than those imposed by TLS. (For example, if this approach is deemed >> to be less costly than doing endpoint monitoring, or if there are >> insufficient access controls for entry to the privileged network, or if the >> privileged network has systems that are too difficult to secure.) >> >> Kyle >> >> > --94eb2c08ad4a6690b505545ae42f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I might want to try responding to the right thread. A= pologies for the noise. ;-)

Kyle

On Sat, Jul 15, 2017 at 9:08 AM, Kyle= Rose <krose@krose.org> wrote:
I've rebased from the kernel master HEAD (4.12= .0+), tested, and force-pushed the repository.

Conveniently, it look= s like, since the last time I searched for one, someone added an ECDH imple= mentation to the kernel. That makes this a lot easier.

Kyle

On Sat, Jul 15, 2017 at 8:18 AM, Kyle Rose <krose@krose.org> wrote:
On Sat, J= ul 15, 2017 at 7:59 AM, Roland Dobbins <rdobbins@arbor.net>= wrote:
On 15 Jul 2017, at 18:23, Daniel Ka= hn Gillmor wrote:

Whether it justifies a loss of security is a separate question.

 It isn't a loss of security - it's actually a net gain for security= .

Security isn't a scalar quanti= ty, so there's no way you can credibly assert this. OTOH, it's easy= to point to the individual security properties lost by expanding the attac= k surface for a particular session key or by mandating key-reuse.

Analyzing the impact of any particular mechanism for middlebox ins= pection is a question of tradeoffs: what are you giving up, what are you ga= ining, and is the trade worth it? The first two are questions of fact (thou= gh I'm under no illusion that there would even be broad agreement on th= ose). The last is not: it's inherently subjective and among other thing= s it depends on the threats, the alternative mechanisms available, and the = value placed on the properties TLS provides to end users in its unadulterat= ed form.

Every one of your emails seems to boil down to a= n argument of the form "Organizations have infrastructure and operatio= ns set up to do inspection this way, so we need some way to apply that to T= LS 1.3." I am unpersuaded by such arguments as a reason for standardiz= ing a weakening of TLS. Given that, I would like to understand the origins = of this approach to monitoring, as that may shed light on the hidden or uns= pecified constraints other than those imposed by TLS. (For example, if this= approach is deemed to be less costly than doing endpoint monitoring, or if= there are insufficient access controls for entry to the privileged network= , or if the privileged network has systems that are too difficult to secure= .)
<= br>
Kyle



--94eb2c08ad4a6690b505545ae42f-- From nobody Sat Jul 15 06:46:56 2017 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 4C2E6131BF1 for ; Sat, 15 Jul 2017 06:46:54 -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=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 9lQpiSj-pWnv for ; Sat, 15 Jul 2017 06:46:52 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 97A92131BEB for ; Sat, 15 Jul 2017 06:46:52 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6FDgxwG028429; Sat, 15 Jul 2017 14:46:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=8PPXowiIqD2aa5VaGj6BcZ85QLCsxSJN7fTDn00SJUg=; b=V4xiWcUgBZgNS4Htxjv7rEdcDIIuCzoUYjBJddSa3StEEIjFASCGBnan44p3Pp68umvX trEtP9nfVnQexFrmrsbzSIGgJ0qr7RXe4CIZ6z6KC9N0b2ncxZJWz6kvplzI0uF5RNnP ofWsc47YCXLi8Ouu6UH0y+9BmqDzg445uHLMh1OTIZV2bu73CsIx/7O31G3yLfFLze+L pFU7qBrtSe7lditJphvrtqWchdJjuyYZnMMw9+LdodtKkEOKPg/pVboq0W/frVzfb6pz wJ+2sK8XXiTYPFy1Z7O762XZK9mSiI4toJBJDiBrdQk0AUL4/6VmllRBH8y9Y1YFI5al gQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bq84d1tf9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 14:46:50 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6FDk2uO004312; Sat, 15 Jul 2017 09:46:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecugfxh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 09:46:49 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 15 Jul 2017 09:46:48 -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.1263.000; Sat, 15 Jul 2017 09:46:47 -0400 From: "Salz, Rich" To: Sean Turner , "" Thread-Topic: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! Thread-Index: AQHS/LCtIul++Gg2tUevX4zDTDqcXaJU56fA Date: Sat, 15 Jul 2017 13:46:47 +0000 Message-ID: References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> In-Reply-To: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.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.153.211] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707150227 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707150226 Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 13:46:54 -0000 SSB3b3VsZCAqVkVSWSBWRVJZIFNUUk9OR0xZKiBsaWtlIHRvIHNlZSB0aGUgc3RhdGljLWRoIGRy YWZ0IGJlIG9uIE1vbmRheSwgYW5kIGFsbCB0aGUgTW9uZGF5IHRvcGljcyBtb3ZlZCB0byB0aGUg bWFpbiBzY2hlZHVsZWQgc2xvdCBvbiBXZWRuZXNkYXksIGV2ZW4gaWYgaXQgbWVhbnMgdGFraW5n IDUgbWludXRlcyBvZiBlYWNoIG9mIGVuY3J5cHRpbmctU05JIGFuZCBEQU5FL0ROU1NFQw0KDQpU aG9zZSBhcmUgdGVjaG5pY2FsIHRvcGljcywgZmFyIG1vcmUgc3VpdGVkIHRvIHRoZSBtYWluIGV2 ZW50IHRoZW4gdGhlIG90aGVyIG9uZSB3aGljaCBoYXMgdmVyeSBsaXR0bGUgdGVjaG5pY2FsIGNv bnRlbnQgYXQgdGhpcyBzdGFnZS4NCg== From nobody Sat Jul 15 06:51:29 2017 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 8E933131BF4 for ; Sat, 15 Jul 2017 06:51:25 -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, URIBL_BLOCKED=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 pge1QuAzNGP1 for ; Sat, 15 Jul 2017 06:51:23 -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 CBA62131BF3 for ; Sat, 15 Jul 2017 06:51:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1EC8E300567 for ; Sat, 15 Jul 2017 09:51:23 -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 L5Oc9TpN5cQe for ; Sat, 15 Jul 2017 09:51:21 -0400 (EDT) Received: from dhcp-88c4.meeting.ietf.org (dhcp-88c4.meeting.ietf.org [31.133.136.196]) by mail.smeinc.net (Postfix) with ESMTPSA id 338D3300258; Sat, 15 Jul 2017 09:51:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Sat, 15 Jul 2017 09:51:19 -0400 Cc: Sean Turner , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <514028E4-A2E7-4995-AB80-1BE91993CA70@vigilsec.com> References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> To: Rich Salz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 13:51:26 -0000 Travel plans were made based on the published agenda, an Matt Green will = not be on Prague on Monday. We should not discuss draft-green- without = him. Russ > On Jul 15, 2017, at 9:46 AM, Salz, Rich wrote: >=20 > I would *VERY VERY STRONGLY* like to see the static-dh draft be on = Monday, and all the Monday topics moved to the main scheduled slot on = Wednesday, even if it means taking 5 minutes of each of encrypting-SNI = and DANE/DNSSEC >=20 > Those are technical topics, far more suited to the main event then the = other one which has very little technical content at this stage. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jul 15 07:01:32 2017 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 B3F53131BF9 for ; Sat, 15 Jul 2017 07:01:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oPNDqzNZpDqC for ; Sat, 15 Jul 2017 07:01:30 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 8B2D2131BF2 for ; Sat, 15 Jul 2017 07:01:30 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id r30so80383609qtc.0 for ; Sat, 15 Jul 2017 07:01:30 -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:cc :content-transfer-encoding:message-id:references:to; bh=xj5ZY6Fumo2lX2CzuqXwXOVDYcnaUp11Q4oC6gTyVpQ=; b=ZoNy4tgwFcKW5hdjSVBAKhOkERhT2KmGTwIvgJV5HR0m9BTlRRi0qvA49/8/hALOhp t//wS5EU8l3IAxkBQGeueKrvaGZRhJaPST6fuWDFjTgsTYNZNj8Q8fOMFpN3Z2XkS7R8 0Hzj+Ij1LbxGN/pg9RWkmzktk3XWdLmd/lD7k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xj5ZY6Fumo2lX2CzuqXwXOVDYcnaUp11Q4oC6gTyVpQ=; b=Wh7zgjgplyJ8y5LZ4EA0DUeJI15IWk3bFvXs/PVoNLr4+qJKH01rXbiTpfk65k3+Ps sNkBFwdgufzcOf4xt6wGua6OilE3woRC96KuFpnbBaU301jro2GepwmpnCHdPavlMSbj BhAD1a68bfIhePpke4vY8/JMAfFlS24AwYyEHqFI3C14SMqGfjr/kYOVlvOlYAZBr6vc US1EVyjTuNc4iOGi8nJJWMaZJ9BPYQ9mZF44CAKv/MH5c0j5OxaERUa0gR1/qkTK7X/8 1Ttll0sP1ifNbuSK6v8gYACMMD9aZhOVfAdT0UeZeX5+AYWxFJbzbpwEHry+mRnVlm35 UKFA== X-Gm-Message-State: AIVw113Z8wCbO/QT38evVKL3rNrV4zaA94aXEMWQkhYj84a8n5Nj55uM 0mXxoVfZ6whxJBGBeM9waA== X-Received: by 10.237.54.225 with SMTP id f88mr16967800qtb.240.1500127289741; Sat, 15 Jul 2017 07:01:29 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.165]) by smtp.gmail.com with ESMTPSA id b42sm9903862qkb.17.2017.07.15.07.01.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 07:01:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Sat, 15 Jul 2017 10:01:27 -0400 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: <6E53482A-0BDB-4118-92BD-EB82F7229477@sn3rd.com> References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> To: Rich Salz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 14:01:32 -0000 > On Jul 15, 2017, at 09:46, Salz, Rich wrote: >=20 > encrypting-SNI and DANE/DNSSEC draft-ietf-tls-dnssec-chain-extension is getting moved back to Monday = because that=E2=80=99s the only time Melinda can make. In Yokohama, I said encrypted SNI has occupied about 27 hours of WG time = so this will make it 27.5/28. The sessions are recorded and we=E2=80=99ll= obviously be taking it to the list. spt= From nobody Sat Jul 15 08:36:31 2017 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 64248129AD3 for ; Sat, 15 Jul 2017 08:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 0zbMPGgZnMVH for ; Sat, 15 Jul 2017 08:36:25 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 F3A381287A5 for ; Sat, 15 Jul 2017 08:36:24 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 18AF0C15E3 for ; Sat, 15 Jul 2017 10:36:24 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 13ECBC1598; Sat, 15 Jul 2017 10:36:23 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C6E8892057; Sat, 15 Jul 2017 11:36:22 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7FD1E92053; Sat, 15 Jul 2017 11:36:22 -0400 (EDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (unknown [216.32.180.56]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Sat, 15 Jul 2017 11:36:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+Fpisg3Nwi97yUc6gqh1J//LqXZ+PjSDGbeSwzpckRA=; b=Jz133VysMm4wKTDRDHfrBf6JVMH5tlBDpjwtjyAJYINtOuksc7NCjLlI2hKFihWt2Z2RTyecSCqc3Yt8wQPfYf3a2DM0OB8FFwP+bgZRuPb8/X4wtK8ba5T1Hx+pmVurPNShtO998yBNT/MeMRBou7P1kT8HG+EJU4r/h5Xr7ao= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 15:36:19 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 15:36:19 +0000 From: "Ackermann, Michael" To: Ted Lemon , "Dobbins, Roland" CC: IETF TLS , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIALriyAgAAVWACAAAFKgIAAAg+AgAADOACAAHw4YA== Date: Sat, 15 Jul 2017 15:36:19 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [2602:304:ce75:4b0:1414:401b:871e:f658] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 20:woSqI2KCHtJseaELPpXXSML71T8T7pXKl9jbXUrMSdH40zuJTGSBL9yoPjy+GDKCOUaLoc/K7vJN+MVBz63nuyiCuY3FfJCEP40JyZ09Xu8wCaWU3rwQuS9ZnH1VHI4c0a09OENSXyMr4MUcqtx47B4O5CYyJ1Fimw8y/9prcj8= x-ms-office365-filtering-correlation-id: 026a5d75-ffba-4f36-791c-08d4cb973d5b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1368; x-ms-traffictypediagnostic: CY4PR14MB1368: x-exchange-antispam-report-test: UriScan:(151999592597050)(278428928389397)(72170088055959)(26388249023172)(236129657087228)(192374486261705)(48057245064654)(148574349560750)(21748063052155)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1368; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39400400002)(39830400002)(39410400002)(51444003)(24454002)(377454003)(7696004)(9686003)(93886004)(3660700001)(53936002)(2906002)(53546010)(7736002)(77096006)(38730400002)(74316002)(229853002)(5660300001)(2900100001)(3280700002)(99286003)(54906002)(14454004)(478600001)(54896002)(6306002)(236005)(33656002)(50986999)(4326008)(8676002)(55016002)(6246003)(39060400002)(54356999)(76176999)(80792005)(19609705001)(2950100002)(189998001)(6436002)(6506006)(790700001)(102836003)(6116002)(230783001)(8936002)(81166006)(72206003)(25786009)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB136850FD3287DEAD0CD44C78D7A20CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 15:36:19.4737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 59cd3b86-d3f0-4e49-aeff-6122df43a09b X-VPM-MSG-ID: d3f08915-8f0d-424c-bd64-ee6e79f1c15a X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 15:36:27 -0000 --_000_CY4PR14MB136850FD3287DEAD0CD44C78D7A20CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGVkDQpZb3VyIGZpcnN0IHNlbnRlbmNlIGlsbHVzdHJhdGVzIHRoZSBkaXNjb25uZWN0IGJl dHdlZW4gdGhlIEVudGVycHJpc2UgcGVyc3BlY3RpdmUgYW5kIHdoYXQgbWFueSBhdCBJRVRG IGFyZSBzYXlpbmcuDQpUaGF0IGJlaW5nIHRoZSB1bmVuY3J5cHRlZCBzdHJlYW0gaXMgYXZh aWxhYmxlIHRvIHRoZSBlbmRwb2ludHMuICAgSVQgSVMgTk9ULiAgICAgV2hlbiB5b3UgcnVu IGEgcGFja2V0IHRyYWNlIGF0IHRoZSBlbmRwb2ludCwgIHlvdSB3aWxsIHNlZSBlbmNyeXB0 ZWQgcGF5bG9hZHMgYW5kIHdpbGwgbmVlZCB0aGUga2V5cyB0byBkZWNyeXB0Lg0KU28geW91 IGNhbiBjb2xsZWN0IHBhY2tldCB0cmFjZSBpbmZvcm1hdGlvbiBhdCB0aG91c2FuZHMgb3Ig bm9kZXMsICBvciB5b3UgY2FuIGNvbGxlY3QgcGFja2V0IHRyYWNlcyBmcm9tIG5ldHdvcmsg dGFwcy4gICBZb3Ugc3RpbGwgbmVlZCB0aGUga2V5cyB0byBkZXJpdmUgbWVhbmluZ2Z1bCBk aWFnbm9zdGljIGFuZCBtb25pdG9yaW5nIGluZm9ybWF0aW9uLg0KDQpQZW9wbGUgdGhhbiBy dW4gYW5kIG1hbmFnZSBuZXR3b3JrcyBhcmUgUEFJTkZVTExZIGF3YXJlIG9mIHRoaXMgZmFj dC4gICAgIFRoaXMgaXMgd2h5IHdlIG5lZWQgd2hhdCB0aGlzIGRyYWZ0IHByb3Bvc2VzLg0K DQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFRlZCBMZW1vbg0KU2VudDogU2F0dXJkYXksIEp1bHkgMTUsIDIwMTcgNDowNiBBTQ0KVG86 IERvYmJpbnMsIFJvbGFuZCA8cmRvYmJpbnNAYXJib3IubmV0Pg0KQ2M6IElFVEYgVExTIDx0 bHNAaWV0Zi5vcmc+OyBNYXR0aGV3IEdyZWVuIDxtYXR0aGV3ZGdyZWVuQGdtYWlsLmNvbT4N ClN1YmplY3Q6IFJlOiBbVExTXSBkcmFmdC1ncmVlbi10bHMtc3RhdGljLWRoLWluLXRsczEz LTAxDQoNCkkgdGhpbmsgdGhhdCB5b3VyIGZpcnN0IGFuZCB0aGlyZCBwb2ludHMgYXJlIGFj dHVhbGx5IG5vbi1zZXF1aXR1cnM6IHRoZSB1bmVuY3J5cHRlZCBzdHJlYW0gaXMgYXZhaWxh YmxlIHRvIHRoZSBlbnRpdGllcyBjb250cm9sbGluZyBlaXRoZXIgZW5kcG9pbnQsIG5vdCBq dXN0IHRoZSBsb2cuICAgVGhlcmUgaXMgbm8gdGVjaG5pY2FsIHJlYXNvbiB0aGF0IGluLWZs aWdodCBjYXB0dXJlIGlzIHJlcXVpcmVkIHRvIGFkZHJlc3MgdGhvc2UgdHdvIHBvaW50cy4N Cg0KUmVnYXJkaW5nIHlvdXIgc2Vjb25kIHBvaW50LCB0aGlzIHNlZW1zIHRvIGJlIHRoZSBy ZWFsIGtleSB0aGF0IGlzIG1vdGl2YXRpbmcgeW91IHRvIG1ha2UgdGhlIGZpcnN0IGFuZCB0 aGlyZCBwb2ludHMuICAgSWYgSSBtYXkgcGFyYXBocmFzZSwgdGhlIHByb2JsZW0geW91IGFy ZSBhdHRlbXB0aW5nIHRvIGFkZHJlc3MgaXMgdGhhdCBpbiBzb21lIHNpdHVhdGlvbnMgdHdv IHN1Yi1vcmdhbml6YXRpb25zIGJvdGggb2Ygd2hpY2ggYXJlIGluIHByaW5jaXBsZSByZXNw b25zaWJsZSB0byBhIGxhcmdlciBvcmdhbml6YXRpb24gbm9uZXRoZWxlc3MgYXJlIHVuYWJs ZSB0byBjb29wZXJhdGUgZHVlIGVzc2VudGlhbGx5IHRvIGEgZmFpbHVyZSBieSBvbmUgc3Vi LW9yZ2FuaXphdGlvbiB0byB0YWtlIHNlcmlvdXNseSB0aGUgcmVzcG9uc2liaWxpdGllcyBv ZiB0aGUgb3RoZXIgc3ViLW9yZ2FuaXphdGlvbiwgYW5kIHRoZSBmYWlsdXJlIG9mIHRoZSBv cmdhbml6YXRpb24gdG8gd2hpY2ggdGhleSBhcmUgYm90aCBzdWJvcmRpbmF0ZSB0byBzdWNj ZXNzZnVsbHkgZW5jb3VyYWdlIGNvb3BlcmF0aW9uIG9uIHRoZSBwYXJ0IG9mIHRoZSBpbnRy YW5zaWdlbnQgc3ViLW9yZ2FuaXphdGlvbi4gICBEaWQgSSBwYXJhcGhyYXNlIHRoYXQgY29y cmVjdGx5Pw0KDQpPbiBTYXQsIEp1bCAxNSwgMjAxNyBhdCA5OjU0IEFNLCBEb2JiaW5zLCBS b2xhbmQgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj4g d3JvdGU6DQoNCg0KPiBPbiBKdWwgMTUsIDIwMTcsIGF0IDE0OjQ4LCBUZWQgTGVtb24gPG1l bGxvbkBmdWd1ZS5jb208bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20+PiB3cm90ZToNCj4NCj4g SW4gdGhlIGV2ZW50IHRoYXQgaXQgaXMgbm90IGZlYXNpYmxlIGZvciBhbiBvcGVyYXRvciB0 byBvYnRhaW4gdGhlIHBsYWludGV4dCBvZiBhIG1lc3NhZ2Ugd2l0aG91dCB0aGUga2V5LCBp c24ndCB0aGF0IGJlY2F1c2UgdGhleSBkb24ndCBjb250cm9sIGVpdGhlciBlbmRwb2ludD8N Cg0KRmlyc3Qgb2YgYWxsLCB3aGF0IGdvZXMgb24gdGhlIHdpcmUgaXMgb2Z0ZW4gY29udGV4 dHVhbGx5IGRpZmZlcmVudCAgKGFuZCBwcm9iYXRpdmVseSBzbykgZnJvbSB3aGF0J3MgcmVj b3JkZWQgaW4gYWJzdHJhY3QgbG9nIGZpbGVzLg0KDQpTZWNvbmRseSwgYWRtaW5pc3RyYXRp dmUgZGl2aXNpb25zIHdpdGhpbiBhIHNpbmdsZSBvcmdhbml6YXRpb24gb2Z0ZW4gaW1wZWRl IGNvb3BlcmF0aW9uIGJldHdlZW4gdGhvc2UgdGFza2VkIHdpdGggc2VjdXJpbmcgJiB0cm91 Ymxlc2hvb3RpbmcgY29tbXVuaWNhdGlvbnMgYW5kIHRob3NlIHdobyAnb3duJyB0aGUgYXNz ZXRzIGluIHF1ZXN0aW9uLg0KDQpUaGlyZGx5LCBmb3IgYm90aCBzZWN1cml0eSAmIHRyb3Vi bGVzaG9vdGluZyBhcHBsaWNhdGlvbnMsIHRoZSBoYXJkIHJlcXVpcmVtZW50IGlzIGZvciBy ZWFsLXRpbWUgdmlzaWJpbGl0eSAmIHBvc3NpYmxlIGludGVyY2Vzc2lvbiwgbm90IGV4IHBv c3QgZmFjdG8gYW5hbHlzaXMuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmlu c0BhcmJvci5uZXQ+Pg0KDQoKClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBj b21tdW5pY2F0aW9uIGlzIGhpZ2hseSBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29t bXVuaWNhdGlvbiBpcyBkaXJlY3RlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29w eWluZywgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBp cyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMg bWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFueSB1bmludGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0 ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRob3V0IG1ha2luZyBhbnkgY29waWVzLgogCiBC bHVlIENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hpZ2FuIGFuZCBCbHVlIENhcmUgTmV0d29y ayBvZiBNaWNoaWdhbiBhcmUgbm9ucHJvZml0IGNvcnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRl bnQgbGljZW5zZWVzIG9mIHRoZSBCbHVlIENyb3NzIGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lh dGlvbi4K --_000_CY4PR14MB136850FD3287DEAD0CD44C78D7A20CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WW91ciBmaXJzdCBzZW50ZW5jZSBpbGx1c3Ry YXRlcyB0aGUgZGlzY29ubmVjdCBiZXR3ZWVuIHRoZSBFbnRlcnByaXNlIHBlcnNwZWN0aXZl IGFuZCB3aGF0IG1hbnkgYXQgSUVURiBhcmUgc2F5aW5nLiZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U aGF0IGJlaW5nIHRoZSB1bmVuY3J5cHRlZCBzdHJlYW0gaXMgYXZhaWxhYmxlIHRvIHRoZSBl bmRwb2ludHMuJm5ic3A7Jm5ic3A7IElUIElTIE5PVC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgV2hlbiB5b3UgcnVuIGEgcGFja2V0IHRyYWNlIGF0IHRoZSBlbmRwb2ludCwmbmJzcDsg eW91IHdpbGwgc2VlIGVuY3J5cHRlZCBwYXlsb2FkcyBhbmQgd2lsbCBuZWVkDQogdGhlIGtl eXMgdG8gZGVjcnlwdC4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TbyB5b3UgY2Fu IGNvbGxlY3QgcGFja2V0IHRyYWNlIGluZm9ybWF0aW9uIGF0IHRob3VzYW5kcyBvciBub2Rl cywmbmJzcDsgb3IgeW91IGNhbiBjb2xsZWN0IHBhY2tldCB0cmFjZXMgZnJvbSBuZXR3b3Jr IHRhcHMuJm5ic3A7Jm5ic3A7IFlvdSBzdGlsbCBuZWVkIHRoZSBrZXlzIHRvIGRlcml2ZSBt ZWFuaW5nZnVsIGRpYWdub3N0aWMNCiBhbmQgbW9uaXRvcmluZyBpbmZvcm1hdGlvbi4gPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlBlb3BsZSB0aGFuIHJ1biBhbmQgbWFuYWdlIG5l dHdvcmtzIGFyZSBQQUlORlVMTFkgYXdhcmUgb2YgdGhpcyBmYWN0LiZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDtUaGlzIGlzIHdoeSB3ZSBuZWVkIHdoYXQgdGhpcyBkcmFmdCBwcm9wb3Nl cy4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5UZWQgTGVtb248YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1bHkgMTUsIDIw MTcgNDowNiBBTTxicj4NCjxiPlRvOjwvYj4gRG9iYmlucywgUm9sYW5kICZsdDtyZG9iYmlu c0BhcmJvci5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFRMUyAmbHQ7dGxzQGlldGYu b3JnJmd0OzsgTWF0dGhldyBHcmVlbiAmbHQ7bWF0dGhld2RncmVlbkBnbWFpbC5jb20mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBkcmFmdC1ncmVlbi10bHMtc3RhdGlj LWRoLWluLXRsczEzLTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgdGhpbmsgdGhhdCB5b3VyIGZpcnN0IGFuZCB0aGlyZCBwb2ludHMgYXJl IGFjdHVhbGx5IG5vbi1zZXF1aXR1cnM6IHRoZSB1bmVuY3J5cHRlZCBzdHJlYW0gaXMgYXZh aWxhYmxlIHRvIHRoZSBlbnRpdGllcyBjb250cm9sbGluZyBlaXRoZXIgZW5kcG9pbnQsIG5v dCBqdXN0IHRoZSBsb2cuICZuYnNwOyBUaGVyZSBpcyBubw0KPGk+dGVjaG5pY2FsIDwvaT5y ZWFzb24gdGhhdCBpbi1mbGlnaHQgY2FwdHVyZSBpcyByZXF1aXJlZCB0byBhZGRyZXNzIHRo b3NlIHR3byBwb2ludHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHlvdXIgc2Vjb25kIHBvaW50LCB0aGlzIHNlZW1zIHRv IGJlIHRoZSByZWFsIGtleSB0aGF0IGlzIG1vdGl2YXRpbmcgeW91IHRvIG1ha2UgdGhlIGZp cnN0IGFuZCB0aGlyZCBwb2ludHMuICZuYnNwOyBJZiBJIG1heSBwYXJhcGhyYXNlLCB0aGUg cHJvYmxlbSB5b3UgYXJlIGF0dGVtcHRpbmcgdG8gYWRkcmVzcyBpcyB0aGF0IGluIHNvbWUg c2l0dWF0aW9ucyB0d28gc3ViLW9yZ2FuaXphdGlvbnMgYm90aA0KIG9mIHdoaWNoIGFyZSBp biBwcmluY2lwbGUgcmVzcG9uc2libGUgdG8gYSBsYXJnZXIgb3JnYW5pemF0aW9uIG5vbmV0 aGVsZXNzIGFyZSB1bmFibGUgdG8gY29vcGVyYXRlIGR1ZSBlc3NlbnRpYWxseSB0byBhIGZh aWx1cmUgYnkgb25lIHN1Yi1vcmdhbml6YXRpb24gdG8gdGFrZSBzZXJpb3VzbHkgdGhlIHJl c3BvbnNpYmlsaXRpZXMgb2YgdGhlIG90aGVyIHN1Yi1vcmdhbml6YXRpb24sIGFuZCB0aGUg ZmFpbHVyZSBvZiB0aGUgb3JnYW5pemF0aW9uDQogdG8gd2hpY2ggdGhleSBhcmUgYm90aCBz dWJvcmRpbmF0ZSB0byBzdWNjZXNzZnVsbHkgZW5jb3VyYWdlIGNvb3BlcmF0aW9uIG9uIHRo ZSBwYXJ0IG9mIHRoZSBpbnRyYW5zaWdlbnQgc3ViLW9yZ2FuaXphdGlvbi4gJm5ic3A7IERp ZCBJIHBhcmFwaHJhc2UgdGhhdCBjb3JyZWN0bHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEp1bCAxNSwgMjAxNyBhdCA5OjU0 IEFNLCBEb2JiaW5zLCBSb2xhbmQgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJv ci5uZXQiIHRhcmdldD0iX2JsYW5rIj5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQomZ3Q7IE9uIEp1bCAxNSwgMjAxNywgYXQgMTQ6NDgsIFRlZCBM ZW1vbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20iPm1lbGxvbkBmdWd1 ZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiB0aGUgZXZlbnQg dGhhdCBpdCBpcyBub3QgZmVhc2libGUgZm9yIGFuIG9wZXJhdG9yIHRvIG9idGFpbiB0aGUg cGxhaW50ZXh0IG9mIGEgbWVzc2FnZSB3aXRob3V0IHRoZSBrZXksIGlzbid0IHRoYXQgYmVj YXVzZSB0aGV5IGRvbid0IGNvbnRyb2wgZWl0aGVyIGVuZHBvaW50Pzxicj4NCjxicj4NCkZp cnN0IG9mIGFsbCwgd2hhdCBnb2VzIG9uIHRoZSB3aXJlIGlzIG9mdGVuIGNvbnRleHR1YWxs eSBkaWZmZXJlbnQmbmJzcDsgKGFuZCBwcm9iYXRpdmVseSBzbykgZnJvbSB3aGF0J3MgcmVj b3JkZWQgaW4gYWJzdHJhY3QgbG9nIGZpbGVzLjxicj4NCjxicj4NClNlY29uZGx5LCBhZG1p bmlzdHJhdGl2ZSBkaXZpc2lvbnMgd2l0aGluIGEgc2luZ2xlIG9yZ2FuaXphdGlvbiBvZnRl biBpbXBlZGUgY29vcGVyYXRpb24gYmV0d2VlbiB0aG9zZSB0YXNrZWQgd2l0aCBzZWN1cmlu ZyAmYW1wOyB0cm91Ymxlc2hvb3RpbmcgY29tbXVuaWNhdGlvbnMgYW5kIHRob3NlIHdobyAn b3duJyB0aGUgYXNzZXRzIGluIHF1ZXN0aW9uLjxicj4NCjxicj4NClRoaXJkbHksIGZvciBi b3RoIHNlY3VyaXR5ICZhbXA7IHRyb3VibGVzaG9vdGluZyBhcHBsaWNhdGlvbnMsIHRoZSBo YXJkIHJlcXVpcmVtZW50IGlzIGZvciByZWFsLXRpbWUgdmlzaWJpbGl0eSAmYW1wOyBwb3Nz aWJsZSBpbnRlcmNlc3Npb24sIG5vdCBleCBwb3N0IGZhY3RvIGFuYWx5c2lzLjxicj4NCjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KUm9sYW5kIERv YmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPnJkb2JiaW5z QGFyYm9yLm5ldDwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCgoKPEJSPgo8aHRtbD4KIDxwPlRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGhpZ2hseSBjb25m aWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBkaXJlY3RlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29weWluZywgZGlzY2xvc3VyZSBvciBkaXN0cmli dXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFueSB1 bmludGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRo b3V0IG1ha2luZyBhbnkgY29waWVzLjwvcD4KIDxwPkJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQg b2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25w cm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJs dWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLjwvcD4KICA8L2h0bWw+Cgo= --_000_CY4PR14MB136850FD3287DEAD0CD44C78D7A20CY4PR14MB1368namp_-- From nobody Sat Jul 15 08:46:22 2017 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 B925B12F28B for ; Sat, 15 Jul 2017 08:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 owy6z-nJC6I1 for ; Sat, 15 Jul 2017 08:46:19 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 14852126BF0 for ; Sat, 15 Jul 2017 08:46:18 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 4302E1C190A for ; Sat, 15 Jul 2017 10:46:18 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 6F7151C181B; Sat, 15 Jul 2017 10:46:17 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3ABAB92057; Sat, 15 Jul 2017 11:46:17 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0E6F092053; Sat, 15 Jul 2017 11:46:16 -0400 (EDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (unknown [207.46.163.119]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Sat, 15 Jul 2017 11:46:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rX/O4AGdTUoAIlLezES2P6l/JaNHbJmCi0Ow17agGVg=; b=p39zNHqbCCKR++CNYlHJsen4tvqoAB3+RY8Vz7WVbaAS8apgJ5K2VmnebXi/rQcvgTvkfrTUpsxtt8Js01pB4iC4otkmENl10YCQKpVZuQVLZlwLPW0O/GeiSIYV2hnAVJYyQpTfpi5qcLiLcGtL552a5ycZ06q73epKrqg2k2Y= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1367.namprd14.prod.outlook.com (10.172.158.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 15:46:15 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 15:46:15 +0000 From: "Ackermann, Michael" To: Daniel Kahn Gillmor , Ilari Liusvaara , "Dobbins, Roland" CC: IETF TLS Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIALriyAgAAW3oCAABLOAIAAKBQAgABKGMA= Date: Sat, 15 Jul 2017 15:46:14 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <20170715085544.y3hozzzpqzrfacd7@LK-Perkele-VII> <87379yrlqp.fsf@fifthhorseman.net> In-Reply-To: <87379yrlqp.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [2602:304:ce75:4b0:1414:401b:871e:f658] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1367; 20:VlzvHm/L4/HmbA62DBmD5hvn+2AZup4xntApC+AYrFU2pGr+8Kik7AtFY7Ec8B+sqGnz/LFSF+Iqo1+iGP4H6m/RVQZbEi0hGn4x0daMSloD68KGZ5ZY/B2/xOWrvfAr7I0Tx4G9hrJksmr2sP3D9ZRDsLejthKFRmUA9XIxZAw= x-ms-office365-filtering-correlation-id: 1a2d7c86-b593-4071-1c09-08d4cb98a04d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1367; x-ms-traffictypediagnostic: CY4PR14MB1367: x-exchange-antispam-report-test: UriScan:(125551606395959)(236129657087228)(192374486261705)(48057245064654); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1367; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1367; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39830400002)(39450400003)(24454002)(13464003)(377424004)(377454003)(5660300001)(77096006)(33656002)(3660700001)(3280700002)(6116002)(102836003)(86362001)(189998001)(74316002)(7696004)(4326008)(6506006)(25786009)(230783001)(53936002)(9686003)(55016002)(305945005)(38730400002)(93886004)(6436002)(6246003)(2950100002)(99286003)(7736002)(2906002)(2900100001)(8936002)(8676002)(81166006)(53546010)(478600001)(50986999)(54356999)(14454004)(76176999)(72206003)(80792005)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1367; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 15:46:14.8770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1367 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 1fa7ee1b-abdb-459c-a83a-cbbef801a6e7 X-VPM-MSG-ID: 87e47b48-224c-44c6-a12b-6e78eacd9649 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 15:46:21 -0000 Most of us have Key Vaults and related management systems that are so = (OVER in my opinion) secure, that this has never been a problem for us (in = reality ---- NOT in theory or conversation). =20 -----Original Message----- From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Daniel Kahn = Gillmor Sent: Saturday, July 15, 2017 7:19 AM To: Ilari Liusvaara ; Dobbins, Roland = Cc: IETF TLS Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 On Sat 2017-07-15 11:55:44 +0300, Ilari Liusvaara wrote: > Oh, and like any backdoor, this backdoor too has variety of security=20 > problems. And your adversaries would absolutely love to be able to=20 > exploit _you_ using these problems, as that would make their lives=20 > much easier. I'd like to hear from the people who are doing full-take network capture = within their datacenters about how they protect the security of the = internal decryption systems. It certainly sounds like a tempting target = for any adversary interested in datacenter operations. --dkg The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Sat Jul 15 09:19:19 2017 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 616C0131562 for ; Sat, 15 Jul 2017 09:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 o5UI9WhGeVgn for ; Sat, 15 Jul 2017 09:19:15 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 907E91293E1 for ; Sat, 15 Jul 2017 09:19:15 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id v190so1289462pgv.2 for ; Sat, 15 Jul 2017 09:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cV7S4UKGJT2fPt/FVJ9Z4sILGZReRGgJp2cqOqpj3MY=; b=JRdNT1iO4i9l4qm1lFCN6ra89W0mgkWbKXvqPI1zL/+duW0SnA9FIZ2YlwXQFu9Ss4 GB8ZLwYmUCPTdvA8WS3rmgBf23sdRHzRzo3doF9TY0CW4bQxoQK3N5n1Tz6l0Eg34EJb EGORSAfxNWkDOP13Ge5qBj+X389+FwfxAlxra47XqXwxznzGqEG3/RaluZmyUit3qqwQ sTwp8lCvDrF8OKKvHu5JtvU+ffoXrKZgYmtdD3BPfYJEytdRav18LRuhWRlT3H2on/Qf VGJeHjUe9EczWK51SZiOfkzK3b437HYBSYkJRLwiZje5fR7QOq1YZCFA6DRbqTUJI1pL 4rdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cV7S4UKGJT2fPt/FVJ9Z4sILGZReRGgJp2cqOqpj3MY=; b=GfZTkDDB9cORrQ8a+LUP6RQvpskf1H3O9ahxpII/amVctfvqOZUHWO2/ak9sTnNijH eJLZQDnUkKXMw7IDaOY0IxJsK2qKANo77qLlaYFzYlPhmab1vnUBjNDSxSvhIonlZ68C qcsTRFBnVubVDn/gCSE2OfnQ8DKrcLMxDQ9Z93I2tuI4UduPE7cuYgbAo75kdcb6i9Ga cd4BBnrn5xcAoW2+GrShaCATjFT9P+A3UkNJgCnebo+YimGEkt1e6Ry4B+mL/J09tS7v WZUix4vMagP3+3JvmLOtLtZ9Ns++letEbHU3Tp6Sy3NyHbVkW8LikfEM0ZPXzYEcgAQe pKJQ== X-Gm-Message-State: AIVw1103VKUqetl/o7TYHbOK/mY6zGFvW1LtbkbqhiYhM5TxXvE0p3m8 CB+NYJL5YGXHIneGR8V7C214c30JQw== X-Received: by 10.84.215.135 with SMTP id l7mr21898024pli.194.1500135555143; Sat, 15 Jul 2017 09:19:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.193 with HTTP; Sat, 15 Jul 2017 09:18:34 -0700 (PDT) In-Reply-To: <31358CD2-0913-4CA5-88A2-89AB8C4FBF88@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <20170715085544.y3hozzzpqzrfacd7@LK-Perkele-VII> <87379yrlqp.fsf@fifthhorseman.net> <31358CD2-0913-4CA5-88A2-89AB8C4FBF88@arbor.net> From: Kathleen Moriarty Date: Sat, 15 Jul 2017 12:18:34 -0400 Message-ID: To: Roland Dobbins Cc: Daniel Kahn Gillmor , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 16:19:17 -0000 On Sat, Jul 15, 2017 at 7:56 AM, Roland Dobbins wrote: > On 15 Jul 2017, at 18:19, Daniel Kahn Gillmor wrote: > >> I'd like to hear from the people who are doing full-take network capture >> within their datacenters about how they protect the security of the >> internal decryption systems. > > > Firstly, they generally aren't storing everything, forever. Most of the > time, they feed into collection/analysis systems, and most if not all of the > actual packets are discarded. > > In many cases, they're only enabled on a situational basis - say, a security > incident or a troubleshooting session. Most if not all of the packets are > discarded afterwards, in most cases. > > In most cases, they're running on completely out-of-band management > networks, using transparent taps or SPAN ports or equivalent. In some > cases, they can be used to intervene in the cryptostream - but even in that > in-band case, all the management functions are still isolated on out-of-band > management networks which are not interconnected with the production > network, and are further isolated as necessary by implementing > situationally-appropriate network access policies. When I have done this in the past in environments I've managed, I always used a one way cable (receive only), set up the interface for receive only, and then use the same protection mechanism offered by the switch. > >> It certainly sounds like a tempting target for any adversary interested in >> datacenter operations. > > > I guarantee you that your bank, your hospital, your insurance provider, your > credit card processor, your retailer, and/or your government welfare agency > are doing this, and have been doing it for a long time. > > It's quite common in the national security space, as well as other > governmental bureaux. > > I'm not saying everyone has implemented this perfectly, or optimally - but > it is a common practice which has been going on for many years, and the loss > of the ability to perform these functions would result in a net security > loss for these organizations and for their customers and constituents - > i.e., proles like you and me. > > It isn't new, it isn't unique, it isn't a case of a small group engaging in > special pleading. What's amazing is that very few engaged in this > discussion seems to understand all this. > > ----------------------------------- > Roland Dobbins > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Best regards, Kathleen From nobody Sat Jul 15 09:20:06 2017 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 004B51293E1 for ; Sat, 15 Jul 2017 09:20: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RGpne9J5lQHu for ; Sat, 15 Jul 2017 09:20:02 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 C000B128CFF for ; Sat, 15 Jul 2017 09:20:02 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id k14so59390657pgr.0 for ; Sat, 15 Jul 2017 09:20:02 -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=qJRBgTzT01OVfHzlDnfTywK/Y4Y7H6LDInfmNTCgwuw=; b=JhM614cMLkhNcK8l27lsYPfH2e3hTtVjdUH0gRQK9GEqqE1ZPsBn4J51wUcSONxFiz bFS7Il2JbX02mVR8yC7mHChyOSCQzahCdAJJilmuogmRDGZMZWOI70C3YnMuyOyhrbXw PfAkC39Kz7KwQnYKkUFNGWUGKzjiwfne4d/bgdluN//JbZNUmv+nTBJoxiNdOruiVzIq pU4XuM/ZVi99QQdR0Ho4EGxhKDgpYqxdftqs/aEDOM1tvoNqUQ4+O/aoXHVHRLbDv3If BcSSQcO9wdQgsJ1Wa3ukVm0NQsB7c9D47EzoeP2OjV4RPtVTdIM1lXZ+/JU0lCtVtRs9 RI5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qJRBgTzT01OVfHzlDnfTywK/Y4Y7H6LDInfmNTCgwuw=; b=iEsBbM6UskDgW6PEHUTPBxcIV8ft11KkzMl3cNyIbdxD8up21ccSARsUSu4RBt2Gxn BJ3aHQ8LOCLgo1cvUUqVgAJzb3Fr59EuVDf0HiS+sU88+nLxlMhdqpd5dt5JqsbazCom ZDE37Oneq51wcvI+oyb1bKYsdT3h2UEHjz0SCx+Vqci6y2Y3pNwW6ClXLm8RMb93pX93 AaFKcHxC08e5DqglJklL91aQURLjKmrYG9zit570fXTQtCF2b4vP1aJQo9/04qp/LNAR 7d/zgTWU+9m0M3WDipzVf2MT91oxtSN2NDNx42LoW57CxVtSnTfCbNmJ2uvo+GZIifDG qrzA== X-Gm-Message-State: AIVw112OwQvpJ3HYdIUoYscuVz3kfemMWaVqofOPp7GuEdsRvDiroiId 4+O9GVjdsujhRhs5AbI6qE5qzHTMOjOL X-Received: by 10.99.167.79 with SMTP id w15mr20407155pgo.22.1500135602125; Sat, 15 Jul 2017 09:20:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Sat, 15 Jul 2017 09:19:21 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> From: Ted Lemon Date: Sat, 15 Jul 2017 18:19:21 +0200 Message-ID: To: "Ackermann, Michael" Cc: "Dobbins, Roland" , IETF TLS , Matthew Green Content-Type: multipart/alternative; boundary="94eb2c1bdaa4ae107805545d89f9" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 16:20:05 -0000 --94eb2c1bdaa4ae107805545d89f9 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael wrote: > Your first sentence illustrates the disconnect between the Enterprise > perspective and what many at IETF are saying. > > That being the unencrypted stream is available to the endpoints. IT IS > NOT. When you run a packet trace at the endpoint, you will see > encrypted payloads and will need the keys to decrypt. > > So you can collect packet trace information at thousands or nodes, or you > can collect packet traces from network taps. You still need the keys to > derive meaningful diagnostic and monitoring information. > I agree that we have illustrated the disconnect here, in some sense. However, from my perspective, what I see is that there is a problem: you need to be able to look inside the stream. I think we agree that this is the problem. There is a further problem: you have a set of tools that solves this problem in a particular way, and for the moment, you are stuck with those tools. This is where I think the disconnect starts. I am not disagreeing with you that, for the moment, you are stuck with these tools.m But, I *am* disagreeing with you on the conclusion that this situation leads to. To me, it leads to the conclusion that you need two things. First, you need a plan for how to survive the situation you're stuck in right now. Second, you need a plan for how you're going to approach this when next you upgrade your infrastructure. If I were in your position, my plan for the first part would be to use TLS 1.2. You already have what you want, and you control the endpoints. If it ain't broke, why fix it? What I think is urgent, though, is that you be planning for how you're going to handle this going forward. There are a number of ways of doing it. One way would be to keep an appropriately-scaled log of keys. If you just need to look at active streams, it would be a rolling log, and your snooping device would, when asked to snoop a stream, get the key. This is an improvement over TLS 1.2, because it increases accountability: you have to ask for a key to decrypt a particular conversation, so it is known that you decrypted that conversation. Of course, if you are decrypting _every_ conversation, that's not so great. Of course, key exfiltration is an attack surface, but so is the static key. Better get that right. The other thing you can do is to do proper tooling on your servers, so that you *can *access the raw stream. This would require different tooling than you have now, but there's no technical barrier to doing it. Now, it's possible that either of these solutions would be less secure than using a static key. But I don't hear you arguing that. You're still back on tactics: how do I do what I need to do with the tools I have. The answer is, use TLS 1.2 until you upgrade. Put the time in to shave off all the attack surfaces from your TLS 1.2 installations that TLS 1.3 shaves off--disable the deprecated algorithms, for example. It's your site, you control the endpoints, this shouldn't be a problem. But basically, just keep doing what you are doing for now. Maybe this is a naive suggestion on my part, but what I haven't been hearing in this discussion is serious consideration of the tactical problem and the strategic problem. What I've been hearing is "forget about strategy, we want tactics." --94eb2c1bdaa4ae107805545d89f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 15, 2017 at 5:36 PM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:

Your first sentence illustrates the disconnect between the Enterp= rise perspective and what many at IETF are saying.=C2=A0

That being the unencrypted stream is available to t= he endpoints.=C2=A0=C2=A0 IT IS NOT.=C2=A0=C2=A0=C2=A0=C2=A0 When you run a= packet trace at the endpoint,=C2=A0 you will see encrypted payloads and wi= ll need the keys to decrypt.=C2=A0 =C2=A0=C2=A0

So you can collect packet trace information at thou= sands or nodes,=C2=A0 or you can collect packet traces from network taps.= =C2=A0=C2=A0 You still need the keys to derive meaningful diagnostic and monitoring information.


I agree that we have illustrated the disconnect here, in some sens= e. =C2=A0 However, from my perspective, what I see is that there is a probl= em: you need to be able to look inside the stream. =C2=A0 I think we agree = that this is the problem.

There is a further probl= em: you have a set of tools that solves this problem in a particular way, a= nd for the moment, you are stuck with those tools. =C2=A0 This is where I t= hink the disconnect starts. =C2=A0 I am not disagreeing with you that, for = the moment, you are stuck with these tools.m =C2=A0 But, I am=C2=A0d= isagreeing with you on the conclusion that this situation leads to.

To me, it leads to the conclusion that you need two thing= s. =C2=A0 First, you need a plan for how to survive the situation you'r= e stuck in right now. =C2=A0 Second, you need a plan for how you're goi= ng to approach this when next you upgrade your infrastructure.=C2=A0 If I w= ere in your position, my plan for the first part would be to use TLS 1.2. = =C2=A0 You already have what you want, and you control the endpoints. =C2= =A0 If it ain't broke, why fix it?

What I thin= k is urgent, though, is that you be planning for how you're going to ha= ndle this going forward. =C2=A0 There are a number of ways of doing it. =C2= =A0 One way would be to keep an appropriately-scaled log of keys.=C2=A0 If = you just need to look at active streams, it would be a rolling log, and you= r snooping device would, when asked to snoop a stream, get the key. =C2=A0 = This is an improvement over TLS 1.2, because it increases accountability: y= ou have to ask for a key to decrypt a particular conversation, so it is kno= wn that you decrypted that conversation. =C2=A0 Of course, if you are decry= pting _every_ conversation, that's not so great. =C2=A0 Of course, key = exfiltration is an attack surface, but so is the static key. =C2=A0 Better = get that right.

The other thing you can do is to d= o proper tooling on your servers, so that you can access the raw str= eam. =C2=A0 This would require different tooling than you have now, but the= re's no technical barrier to doing it.

Now, it= 's possible that either of these solutions would be less secure than us= ing a static key. =C2=A0 But I don't hear you arguing that. =C2=A0 You&= #39;re still back on tactics: how do I do what I need to do with the tools = I have. =C2=A0 The answer is, use TLS 1.2 until you upgrade. =C2=A0 Put the= time in to shave off all the attack surfaces from your TLS 1.2 installatio= ns that TLS 1.3 shaves off--disable the deprecated algorithms, for example.= =C2=A0 It's your site, you control the endpoints, this shouldn't be= a problem. =C2=A0 But basically, just keep doing what you are doing for no= w.

Maybe this is a naive suggestion on my part, bu= t what I haven't been hearing in this discussion is serious considerati= on of the tactical problem and the strategic problem. =C2=A0 What I've = been hearing is "forget about strategy, we want tactics."
--94eb2c1bdaa4ae107805545d89f9-- From nobody Sat Jul 15 09:23:07 2017 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 1D03312ECC6 for ; Sat, 15 Jul 2017 09:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ruWptZxE1pFB for ; Sat, 15 Jul 2017 09:23:03 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 79EB7128CFF for ; Sat, 15 Jul 2017 09:23:03 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id c73so58697140pfk.2 for ; Sat, 15 Jul 2017 09:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jqAa8SGi01qhci/3973RO/J+c2+fe8vuTfKTaLndJ+0=; b=Wcxw7n+/OpH1Zr4gtO7AohsL5iIWzxcakqIUVqsjeOp6Z7kMySHVjJ/cZ+0wYg3Kgp VrbG8BADvtxJxXL9Qc8K66bGQX3RG6EHfC4+4tpbKHK4ioUog23ImajeMAbQecG1pSjo YOIlTaXgJW7jVk2oflbJYTKwiHEvD+Q2afD02Il9IryHQLAqPjgfcWooRDjPvBG5CU4g /DYz5UqmvvScTn5GeRiR+Zn3Ejmubev4XTHidzNp+dZ2CknSp9gFoiesBeU4xWG3307Q krO5xj7yF+uAS02mr8/R5vAzJJ11cRv9BYoVU8Yj2uutMPbKnS0tq/vSahnStafLmMmZ MI7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jqAa8SGi01qhci/3973RO/J+c2+fe8vuTfKTaLndJ+0=; b=WxkrKksh/0NT2sw9LBUn4g6881Cp9bvjXNjIfM7wER12zIbWQ2q8g2YN+YtTDX2LGR B8INxMZUy8vbfH76hPLDnYddNbGTVSUsErDqOI2z10mFpk8UbFCNwAmtcqbzc/I99kVK 2Cxc77QW+tBddm7Q3tGVfmR+iWumfTYy7GTg7Dbcs+Z7tDWLlhCQsu3VMF6ALWSOD0Il yCP5Nff55szH1Zq4ptBzAt9iOYbY65raOLNT7tZ/ppIz1z1YlWDEjrQhPPbRCg70Xf2o e8E+TqKAmOHygTyJKku/zbrpx1IOLtOrIrhAplW7VUXrFjpqhsMieegRSlEleryJ64OJ TmHQ== X-Gm-Message-State: AIVw1112CD011Q5gurw9mKOdSQbIWZK7E1j76Aj7CoTbUUYUaLVnysov NBzunVICDNUtIZGxqEQ9TLkJrdWtCg== X-Received: by 10.98.201.75 with SMTP id k72mr10641538pfg.99.1500135783158; Sat, 15 Jul 2017 09:23:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.193 with HTTP; Sat, 15 Jul 2017 09:22:22 -0700 (PDT) In-Reply-To: <14403761-47B4-4F6C-BF89-2553D180E776@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <871spirljc.fsf@fifthhorseman.net> <14403761-47B4-4F6C-BF89-2553D180E776@arbor.net> From: Kathleen Moriarty Date: Sat, 15 Jul 2017 12:22:22 -0400 Message-ID: To: Roland Dobbins Cc: Daniel Kahn Gillmor , Matthew Green , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 16:23:05 -0000 On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins wrote: > On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote: > >> Whether it justifies a loss of security is a separate question. > > > It isn't a loss of security - it's actually a net gain for security. > Network visibility, independent of any end-host, is a key requirement for > network security. Visibility, yes, but I don't agree that you can't protect the network if traffic is encrypted. Many incident response teams are able to use indicators of compromise (IoCs) for encrypted streams. > > As to the specific regulations, folks from the appropriate verticals will > need to speak up. I know vaguely that there are regulations in the > financial sector and the defense contracting sector which apply, but can't > cite chapter and verse. > > I'm sure someone on the list can, however. > > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Best regards, Kathleen From nobody Sat Jul 15 09:39:16 2017 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 7916F127078 for ; Sat, 15 Jul 2017 09:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 mbGWFl0dknlL for ; Sat, 15 Jul 2017 09:39:10 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 575E8124D37 for ; Sat, 15 Jul 2017 09:39:09 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 57DCA1C191B for ; Sat, 15 Jul 2017 11:39:09 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 4E50D1C1905; Sat, 15 Jul 2017 11:39:08 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ECF2EFE054; Sat, 15 Jul 2017 12:39:07 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A9E67FE055; Sat, 15 Jul 2017 12:39:07 -0400 (EDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (unknown [207.46.163.51]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Sat, 15 Jul 2017 12:39:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XS0zFYhUOxUU6fsj44vJvWDlb8rXSof1mGRx7XcTKVM=; b=4ycCgIc9LeCJhzhA07T+JbnPMPwQ3amEUISbnrkKyYevVVQ5W+1/y5StbHqYUBQ9BpTltWWayYHGCh89jEpKjltg3z6O+b1gtJekLSczomTcfvwHCEq52+GM4KVgAOFR84+Ic9Mx4COUdxpt6vIvHOCd17HmDlBpyysJaniVirU= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1367.namprd14.prod.outlook.com (10.172.158.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 16:39:05 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 16:39:05 +0000 From: "Ackermann, Michael" To: Ted Lemon CC: "Dobbins, Roland" , IETF TLS , "Matthew Green" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIALriyAgAAVWACAAAFKgIAAAg+AgAADOACAAHw4YIAADX2AgAABOSA= Date: Sat, 15 Jul 2017 16:39:04 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [2602:304:ce75:4b0:1414:401b:871e:f658] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1367; 20:4DzE/qV5NHCIMbn8kP4q44xtHCEe9WpBXM9y2TgMJDTkuLC1CXDsfxG2VfEULNGCnrayvsLAY6YRZLb8IgnvNxS21h1hzZqklVVXuesCLlVJexSI1wU2xngIPtBG8RRbrRBBieLC3NUtrovNLb1qPbtRzsj0e0LTcK5/teJZkcs= x-ms-office365-filtering-correlation-id: 0f3ba92a-c211-4056-cf47-08d4cba001c1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1367; x-ms-traffictypediagnostic: CY4PR14MB1367: x-exchange-antispam-report-test: UriScan:(151999592597050)(125551606395959)(72170088055959)(26388249023172)(236129657087228)(48057245064654)(148574349560750)(21748063052155)(86572411397741)(209349559609743); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1367; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1367; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39830400002)(39410400002)(39400400002)(377454003)(24454002)(76104003)(43784003)(345774005)(99286003)(7736002)(2906002)(2900100001)(38730400002)(93886004)(110136004)(6436002)(39060400002)(236005)(9686003)(55016002)(6306002)(54896002)(54906002)(2950100002)(6916009)(6246003)(229853002)(80792005)(72206003)(19609705001)(8676002)(81166006)(50986999)(53546010)(76176999)(14454004)(478600001)(54356999)(8936002)(6116002)(790700001)(102836003)(189998001)(86362001)(5660300001)(3660700001)(77096006)(3280700002)(33656002)(4326008)(6506006)(230783001)(53936002)(25786009)(7696004)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1367; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368A2ED677C83E02D10432ED7A20CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 16:39:04.8892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1367 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 48ba760d-b317-4782-9ae7-4bf190bedf41 X-VPM-MSG-ID: b2568042-fcf6-4856-aa9a-f211cbbeb72b X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 16:39:13 -0000 --_000_CY4PR14MB1368A2ED677C83E02D10432ED7A20CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGVkDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2Ugd2hpY2ggYXBwZWFycyB0byBiZSBh biBvYmplY3RpdmUgYXR0ZW1wdCB0bw0KDQogIDEuICBVbmRlcnN0YW5kIHdoYXQgc29tZSBv ZiBvdXIgaXNzdWVzIGFyZS4NCiAgMi4gIFRyeSB0byBzdWdnZXN0IG9wdGltYWwgc29sdXRp b25zLiAgIEJvdGggbG9uZyBhbmQgc2hvcnQgdGVybS4NCg0KVGhpcyB0eXBlIG9mIHBvc2l0 aXZlL2NvbnN0cnVjdGl2ZSBhdHRpdHVkZSBoYXMgYmVlbiBtaXNzaW5nIGZyb20gdGhlIG1h am9yaXR5IG9mIHRoZSBMaXN0IGV4Y2hhbmdlcyBvbiB0aGlzIHRvcGljLiAgICBJIGhhdmUg Zm91bmQgdGhhdCBmcnVzdHJhdGluZy4NCg0KSSB0aGluayB0aGUgRW50ZXJwcmlzZXMgaW52 b2x2ZWQgd2FudCB0byBmaW5kIHRoZSBiZXN0IHNvbHV0aW9ucyBwb3NzaWJsZSBhbmQgZG9p bmcgdGhpcyBwcm9hY3RpdmVseSB0aHJvdWdoIElFVEYsICBpbiBhcyBtdWNoIGEgU3RhbmRh cmRzIGJhc2VkIGZhc2hpb24gYXMgcG9zc2libGUsICBzZWVtcyBtdWNoIGJldHRlciB0byB1 cyB0aGFuIHdhaXRpbmcgc2V2ZXJhbCB5ZWFycyBhbmQgdGhlbiByZWFjdGluZyB3aXRoIGN1 c3RvbSBzb2x1dGlvbnMsICBhcyBoYXMgb2NjdXJyZWQgaW4gdGhlIHBhc3QuICAgICBJIGJl bGlldmUgdGhpcyBpcyB3aHkgRW50ZXJwcmlzZXMgYXJlIG1ha2luZyBhbiBhdHRlbXB0IHRv IHdvcmsgd2l0aCBJRVRGLiAgICAgIEkgaG9wZSB0aGUgSUVURiB3YW50cyB0aGlzIGFzIHdl bGwuDQoNCg0KSSBoYXZlIHNldmVyYWwgcmVzcG9uc2VzIHRvIHlvdXIgc3VnZ2VzdGlvbnMg YmVsb3cuICAgQnV0IHJhdGhlciB0aGFuIHRha2UgdXAgbW9yZSBsaXN0IHRpbWUgYW5kIGF0 dGVtcHQgdG8gZGVzY3JpYmUgaW4gd3JpdGluZyBzb21lIG9mIHRoZSBpc3N1ZXMsIEkgYmVs aWV2ZSB0aGVyZSB3b3VsZCBiZSB3aXRoIGEgY291cGxlIG9mIHlvdXIgc3VnZ2VzdGlvbnMs ICAgIEkgdGhpbmsgaXQgbWlnaHQgYmUgc3dpZnRlciBhbmQgY2xlYXJlciB0byBoYXZlIHlv dSBzcGVhayBsaXZlIChhbmQgZHJhdyBwaWN0dXJlcywgZXRjLiAgIOKYuiksICB3aXRoIGEg Y291cGxlIG9mIHRoZSBFRENPIHBlb3BsZS4gICAgSSB3b3VsZCBnbGFkbHkgYmUgb25lIG9m IHRoZXNlLg0KDQpKdXN0IHNvIHlvdSBrbm93IHdoZXJlIEkgcGVyc29uYWxseSBjb21lIGZy b20uICAgSSBhbSBhIFNQTFVOSyBhZG1pbiwgIHNvIEkgYW0gYSBiaWcgRW5kcG9pbnQgYWR2 b2NhdGUuICAgIEhvd2V2ZXIsICBJIGtub3cgZnJvbSB0aGlzIGV4cGVyaWVuY2UgdGhhdCBF bmRwb2ludCB3aWxsIE5PVCBnZXQgdXMgYWxsIHRoYXQgd2UgbmVlZC4gICAgICBIZW5jZSBt eSBpbnRlcmVzdCBpbiB0aGlzIHZlcnkgaW1wb3J0YW50IHRvcGljLg0KDQpQbGVhc2UgbGV0 IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsuDQoNClRoYW5rcyBhZ2Fpbg0KDQpNaWtlDQoNCg0K RnJvbTogVGVkIExlbW9uIFttYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbV0NClNlbnQ6IFNhdHVy ZGF5LCBKdWx5IDE1LCAyMDE3IDEyOjE5IFBNDQpUbzogQWNrZXJtYW5uLCBNaWNoYWVsIDxN QWNrZXJtYW5uQGJjYnNtLmNvbT4NCkNjOiBEb2JiaW5zLCBSb2xhbmQgPHJkb2JiaW5zQGFy Ym9yLm5ldD47IElFVEYgVExTIDx0bHNAaWV0Zi5vcmc+OyBNYXR0aGV3IEdyZWVuIDxtYXR0 aGV3ZGdyZWVuQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBbVExTXSBkcmFmdC1ncmVlbi10 bHMtc3RhdGljLWRoLWluLXRsczEzLTAxDQoNCk9uIFNhdCwgSnVsIDE1LCAyMDE3IGF0IDU6 MzYgUE0sIEFja2VybWFubiwgTWljaGFlbCA8TUFja2VybWFubkBiY2JzbS5jb208bWFpbHRv Ok1BY2tlcm1hbm5AYmNic20uY29tPj4gd3JvdGU6DQpZb3VyIGZpcnN0IHNlbnRlbmNlIGls bHVzdHJhdGVzIHRoZSBkaXNjb25uZWN0IGJldHdlZW4gdGhlIEVudGVycHJpc2UgcGVyc3Bl Y3RpdmUgYW5kIHdoYXQgbWFueSBhdCBJRVRGIGFyZSBzYXlpbmcuDQpUaGF0IGJlaW5nIHRo ZSB1bmVuY3J5cHRlZCBzdHJlYW0gaXMgYXZhaWxhYmxlIHRvIHRoZSBlbmRwb2ludHMuICAg SVQgSVMgTk9ULiAgICAgV2hlbiB5b3UgcnVuIGEgcGFja2V0IHRyYWNlIGF0IHRoZSBlbmRw b2ludCwgIHlvdSB3aWxsIHNlZSBlbmNyeXB0ZWQgcGF5bG9hZHMgYW5kIHdpbGwgbmVlZCB0 aGUga2V5cyB0byBkZWNyeXB0Lg0KU28geW91IGNhbiBjb2xsZWN0IHBhY2tldCB0cmFjZSBp bmZvcm1hdGlvbiBhdCB0aG91c2FuZHMgb3Igbm9kZXMsICBvciB5b3UgY2FuIGNvbGxlY3Qg cGFja2V0IHRyYWNlcyBmcm9tIG5ldHdvcmsgdGFwcy4gICBZb3Ugc3RpbGwgbmVlZCB0aGUg a2V5cyB0byBkZXJpdmUgbWVhbmluZ2Z1bCBkaWFnbm9zdGljIGFuZCBtb25pdG9yaW5nIGlu Zm9ybWF0aW9uLg0KDQpJIGFncmVlIHRoYXQgd2UgaGF2ZSBpbGx1c3RyYXRlZCB0aGUgZGlz Y29ubmVjdCBoZXJlLCBpbiBzb21lIHNlbnNlLiAgIEhvd2V2ZXIsIGZyb20gbXkgcGVyc3Bl Y3RpdmUsIHdoYXQgSSBzZWUgaXMgdGhhdCB0aGVyZSBpcyBhIHByb2JsZW06IHlvdSBuZWVk IHRvIGJlIGFibGUgdG8gbG9vayBpbnNpZGUgdGhlIHN0cmVhbS4gICBJIHRoaW5rIHdlIGFn cmVlIHRoYXQgdGhpcyBpcyB0aGUgcHJvYmxlbS4NCg0KVGhlcmUgaXMgYSBmdXJ0aGVyIHBy b2JsZW06IHlvdSBoYXZlIGEgc2V0IG9mIHRvb2xzIHRoYXQgc29sdmVzIHRoaXMgcHJvYmxl bSBpbiBhIHBhcnRpY3VsYXIgd2F5LCBhbmQgZm9yIHRoZSBtb21lbnQsIHlvdSBhcmUgc3R1 Y2sgd2l0aCB0aG9zZSB0b29scy4gICBUaGlzIGlzIHdoZXJlIEkgdGhpbmsgdGhlIGRpc2Nv bm5lY3Qgc3RhcnRzLiAgIEkgYW0gbm90IGRpc2FncmVlaW5nIHdpdGggeW91IHRoYXQsIGZv ciB0aGUgbW9tZW50LCB5b3UgYXJlIHN0dWNrIHdpdGggdGhlc2UgdG9vbHMubSAgIEJ1dCwg SSBhbSBkaXNhZ3JlZWluZyB3aXRoIHlvdSBvbiB0aGUgY29uY2x1c2lvbiB0aGF0IHRoaXMg c2l0dWF0aW9uIGxlYWRzIHRvLg0KDQpUbyBtZSwgaXQgbGVhZHMgdG8gdGhlIGNvbmNsdXNp b24gdGhhdCB5b3UgbmVlZCB0d28gdGhpbmdzLiAgIEZpcnN0LCB5b3UgbmVlZCBhIHBsYW4g Zm9yIGhvdyB0byBzdXJ2aXZlIHRoZSBzaXR1YXRpb24geW91J3JlIHN0dWNrIGluIHJpZ2h0 IG5vdy4gICBTZWNvbmQsIHlvdSBuZWVkIGEgcGxhbiBmb3IgaG93IHlvdSdyZSBnb2luZyB0 byBhcHByb2FjaCB0aGlzIHdoZW4gbmV4dCB5b3UgdXBncmFkZSB5b3VyIGluZnJhc3RydWN0 dXJlLiAgSWYgSSB3ZXJlIGluIHlvdXIgcG9zaXRpb24sIG15IHBsYW4gZm9yIHRoZSBmaXJz dCBwYXJ0IHdvdWxkIGJlIHRvIHVzZSBUTFMgMS4yLiAgIFlvdSBhbHJlYWR5IGhhdmUgd2hh dCB5b3Ugd2FudCwgYW5kIHlvdSBjb250cm9sIHRoZSBlbmRwb2ludHMuICAgSWYgaXQgYWlu J3QgYnJva2UsIHdoeSBmaXggaXQ/DQoNCldoYXQgSSB0aGluayBpcyB1cmdlbnQsIHRob3Vn aCwgaXMgdGhhdCB5b3UgYmUgcGxhbm5pbmcgZm9yIGhvdyB5b3UncmUgZ29pbmcgdG8gaGFu ZGxlIHRoaXMgZ29pbmcgZm9yd2FyZC4gICBUaGVyZSBhcmUgYSBudW1iZXIgb2Ygd2F5cyBv ZiBkb2luZyBpdC4gICBPbmUgd2F5IHdvdWxkIGJlIHRvIGtlZXAgYW4gYXBwcm9wcmlhdGVs eS1zY2FsZWQgbG9nIG9mIGtleXMuICBJZiB5b3UganVzdCBuZWVkIHRvIGxvb2sgYXQgYWN0 aXZlIHN0cmVhbXMsIGl0IHdvdWxkIGJlIGEgcm9sbGluZyBsb2csIGFuZCB5b3VyIHNub29w aW5nIGRldmljZSB3b3VsZCwgd2hlbiBhc2tlZCB0byBzbm9vcCBhIHN0cmVhbSwgZ2V0IHRo ZSBrZXkuICAgVGhpcyBpcyBhbiBpbXByb3ZlbWVudCBvdmVyIFRMUyAxLjIsIGJlY2F1c2Ug aXQgaW5jcmVhc2VzIGFjY291bnRhYmlsaXR5OiB5b3UgaGF2ZSB0byBhc2sgZm9yIGEga2V5 IHRvIGRlY3J5cHQgYSBwYXJ0aWN1bGFyIGNvbnZlcnNhdGlvbiwgc28gaXQgaXMga25vd24g dGhhdCB5b3UgZGVjcnlwdGVkIHRoYXQgY29udmVyc2F0aW9uLiAgIE9mIGNvdXJzZSwgaWYg eW91IGFyZSBkZWNyeXB0aW5nIF9ldmVyeV8gY29udmVyc2F0aW9uLCB0aGF0J3Mgbm90IHNv IGdyZWF0LiAgIE9mIGNvdXJzZSwga2V5IGV4ZmlsdHJhdGlvbiBpcyBhbiBhdHRhY2sgc3Vy ZmFjZSwgYnV0IHNvIGlzIHRoZSBzdGF0aWMga2V5LiAgIEJldHRlciBnZXQgdGhhdCByaWdo dC4NCg0KVGhlIG90aGVyIHRoaW5nIHlvdSBjYW4gZG8gaXMgdG8gZG8gcHJvcGVyIHRvb2xp bmcgb24geW91ciBzZXJ2ZXJzLCBzbyB0aGF0IHlvdSBjYW4gYWNjZXNzIHRoZSByYXcgc3Ry ZWFtLiAgIFRoaXMgd291bGQgcmVxdWlyZSBkaWZmZXJlbnQgdG9vbGluZyB0aGFuIHlvdSBo YXZlIG5vdywgYnV0IHRoZXJlJ3Mgbm8gdGVjaG5pY2FsIGJhcnJpZXIgdG8gZG9pbmcgaXQu DQoNCk5vdywgaXQncyBwb3NzaWJsZSB0aGF0IGVpdGhlciBvZiB0aGVzZSBzb2x1dGlvbnMg d291bGQgYmUgbGVzcyBzZWN1cmUgdGhhbiB1c2luZyBhIHN0YXRpYyBrZXkuICAgQnV0IEkg ZG9uJ3QgaGVhciB5b3UgYXJndWluZyB0aGF0LiAgIFlvdSdyZSBzdGlsbCBiYWNrIG9uIHRh Y3RpY3M6IGhvdyBkbyBJIGRvIHdoYXQgSSBuZWVkIHRvIGRvIHdpdGggdGhlIHRvb2xzIEkg aGF2ZS4gICBUaGUgYW5zd2VyIGlzLCB1c2UgVExTIDEuMiB1bnRpbCB5b3UgdXBncmFkZS4g ICBQdXQgdGhlIHRpbWUgaW4gdG8gc2hhdmUgb2ZmIGFsbCB0aGUgYXR0YWNrIHN1cmZhY2Vz IGZyb20geW91ciBUTFMgMS4yIGluc3RhbGxhdGlvbnMgdGhhdCBUTFMgMS4zIHNoYXZlcyBv ZmYtLWRpc2FibGUgdGhlIGRlcHJlY2F0ZWQgYWxnb3JpdGhtcywgZm9yIGV4YW1wbGUuICBJ dCdzIHlvdXIgc2l0ZSwgeW91IGNvbnRyb2wgdGhlIGVuZHBvaW50cywgdGhpcyBzaG91bGRu J3QgYmUgYSBwcm9ibGVtLiAgIEJ1dCBiYXNpY2FsbHksIGp1c3Qga2VlcCBkb2luZyB3aGF0 IHlvdSBhcmUgZG9pbmcgZm9yIG5vdy4NCg0KTWF5YmUgdGhpcyBpcyBhIG5haXZlIHN1Z2dl c3Rpb24gb24gbXkgcGFydCwgYnV0IHdoYXQgSSBoYXZlbid0IGJlZW4gaGVhcmluZyBpbiB0 aGlzIGRpc2N1c3Npb24gaXMgc2VyaW91cyBjb25zaWRlcmF0aW9uIG9mIHRoZSB0YWN0aWNh bCBwcm9ibGVtIGFuZCB0aGUgc3RyYXRlZ2ljIHByb2JsZW0uICAgV2hhdCBJJ3ZlIGJlZW4g aGVhcmluZyBpcyAiZm9yZ2V0IGFib3V0IHN0cmF0ZWd5LCB3ZSB3YW50IHRhY3RpY3MuIg0K CgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBo aWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGly ZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUg b3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25l LCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1l c3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGllcy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNo aWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJl IG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0 aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uCg== --_000_CY4PR14MB1368A2ED677C83E02D10432ED7A20CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4NDQ5MjkwMDQ7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zNzExMzM3MTYgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+VGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFuayB5b3UgZm9yIHlvdXIg cmVzcG9uc2Ugd2hpY2ggYXBwZWFycyB0byBiZSBhbiBvYmplY3RpdmUgYXR0ZW1wdCB0bw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3Rh cnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlVuZGVyc3RhbmQgd2hhdCBzb21lIG9mIG91ciBpc3N1ZXMgYXJlLg0KPG86cD48 L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VHJ5IHRvIHN1Z2dlc3Qgb3B0aW1hbCBzb2x1dGlvbnMuJm5ic3A7Jm5ic3A7IEJv dGggbG9uZyBhbmQgc2hvcnQgdGVybS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5UaGlzIHR5cGUgb2YgcG9zaXRpdmUvY29uc3RydWN0aXZlIGF0dGl0dWRlIGhhcyBi ZWVuIG1pc3NpbmcgZnJvbSB0aGUgbWFqb3JpdHkgb2YgdGhlIExpc3QgZXhjaGFuZ2VzIG9u IHRoaXMgdG9waWMuJm5ic3A7Jm5ic3A7Jm5ic3A7IEkgaGF2ZSBmb3VuZCB0aGF0IGZydXN0 cmF0aW5nLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgdGhl IEVudGVycHJpc2VzIGludm9sdmVkIHdhbnQgdG8gZmluZCB0aGUgYmVzdCBzb2x1dGlvbnMg cG9zc2libGUgYW5kIGRvaW5nIHRoaXMgcHJvYWN0aXZlbHkgdGhyb3VnaCBJRVRGLCZuYnNw OyBpbiBhcyBtdWNoIGEgU3RhbmRhcmRzIGJhc2VkIGZhc2hpb24gYXMgcG9zc2libGUsJm5i c3A7IHNlZW1zDQogbXVjaCBiZXR0ZXIgdG8gdXMgdGhhbiB3YWl0aW5nIHNldmVyYWwgeWVh cnMgYW5kIHRoZW4gcmVhY3Rpbmcgd2l0aCBjdXN0b20gc29sdXRpb25zLCZuYnNwOyBhcyBo YXMgb2NjdXJyZWQgaW4gdGhlIHBhc3QuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYmVs aWV2ZSB0aGlzIGlzIHdoeSBFbnRlcnByaXNlcyBhcmUgbWFraW5nIGFuIGF0dGVtcHQgdG8g d29yayB3aXRoIElFVEYuJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0kgaG9wZSB0 aGUgSUVURiB3YW50cyB0aGlzIGFzIHdlbGwuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGhhdmUgc2V2ZXJhbCByZXNwb25zZXMgdG8g eW91ciBzdWdnZXN0aW9ucyBiZWxvdy4mbmJzcDsmbmJzcDsgQnV0IHJhdGhlciB0aGFuIHRh a2UgdXAgbW9yZSBsaXN0IHRpbWUgYW5kIGF0dGVtcHQgdG8gZGVzY3JpYmUgaW4gd3JpdGlu ZyBzb21lIG9mIHRoZSBpc3N1ZXMsIEkgYmVsaWV2ZSB0aGVyZSB3b3VsZCBiZQ0KIHdpdGgg YSBjb3VwbGUgb2YgeW91ciBzdWdnZXN0aW9ucywmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aGlu ayBpdCBtaWdodCBiZSBzd2lmdGVyIGFuZCBjbGVhcmVyIHRvIGhhdmUgeW91IHNwZWFrIGxp dmUgKGFuZCBkcmF3IHBpY3R1cmVzLCBldGMuJm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj5KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+KSwmbmJzcDsgd2l0aCBhIGNvdXBsZSBvZiB0aGUgRURD TyBwZW9wbGUuJm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd291bGQgZ2xhZGx5IGJlIG9uZSBvZiB0 aGVzZS4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5KdXN0IHNv IHlvdSBrbm93IHdoZXJlIEkgcGVyc29uYWxseSBjb21lIGZyb20uJm5ic3A7Jm5ic3A7IEkg YW0gYSBTUExVTksgYWRtaW4sJm5ic3A7IHNvIEkgYW0gYSBiaWcgRW5kcG9pbnQgYWR2b2Nh dGUuJm5ic3A7Jm5ic3A7Jm5ic3A7IEhvd2V2ZXIsJm5ic3A7IEkga25vdyBmcm9tIHRoaXMg ZXhwZXJpZW5jZSB0aGF0IEVuZHBvaW50IHdpbGwgTk9UIGdldA0KIHVzIGFsbCB0aGF0IHdl IG5lZWQuJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0hlbmNlIG15IGludGVyZXN0 IGluIHRoaXMgdmVyeSBpbXBvcnRhbnQgdG9waWMuJm5ic3A7IDxvOnA+DQo8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlBsZWFzZSBsZXQgbWUga25vdyB3aGF0IHlvdSB0aGluay4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MgYWdhaW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVkIExlbW9uIFttYWlsdG86bWVsbG9uQGZ1Z3Vl LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVseSAxNSwgMjAxNyAxMjox OSBQTTxicj4NCjxiPlRvOjwvYj4gQWNrZXJtYW5uLCBNaWNoYWVsICZsdDtNQWNrZXJtYW5u QGJjYnNtLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IERvYmJpbnMsIFJvbGFuZCAmbHQ7cmRv YmJpbnNAYXJib3IubmV0Jmd0OzsgSUVURiBUTFMgJmx0O3Rsc0BpZXRmLm9yZyZndDs7IE1h dHRoZXcgR3JlZW4gJmx0O21hdHRoZXdkZ3JlZW5AZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW1RMU10gZHJhZnQtZ3JlZW4tdGxzLXN0YXRpYy1kaC1pbi10bHMx My0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gU2F0LCBKdWwgMTUsIDIwMTcgYXQgNTozNiBQTSwgQWNrZXJtYW5uLCBNaWNo YWVsICZsdDs8YSBocmVmPSJtYWlsdG86TUFja2VybWFubkBiY2JzbS5jb20iIHRhcmdldD0i X2JsYW5rIj5NQWNrZXJtYW5uQGJjYnNtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPllvdXIgZmlyc3Qgc2VudGVuY2UgaWxs dXN0cmF0ZXMgdGhlIGRpc2Nvbm5lY3QgYmV0d2VlbiB0aGUgRW50ZXJwcmlzZSBwZXJzcGVj dGl2ZSBhbmQgd2hhdCBtYW55IGF0IElFVEYgYXJlIHNheWluZy4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VGhhdCBiZWluZyB0aGUgdW5lbmNyeXB0ZWQgc3RyZWFtIGlzIGF2YWlsYWJsZSB0 byB0aGUgZW5kcG9pbnRzLiZuYnNwOyZuYnNwOyBJVCBJUyBOT1QuJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFdoZW4geW91IHJ1biBhIHBhY2tldCB0cmFjZSBhdA0KIHRoZSBlbmRwb2lu dCwmbmJzcDsgeW91IHdpbGwgc2VlIGVuY3J5cHRlZCBwYXlsb2FkcyBhbmQgd2lsbCBuZWVk IHRoZSBrZXlzIHRvIGRlY3J5cHQuJm5ic3A7ICZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5TbyB5b3UgY2FuIGNvbGxlY3QgcGFja2V0IHRyYWNlIGluZm9ybWF0aW9uIGF0IHRob3Vz YW5kcyBvciBub2RlcywmbmJzcDsgb3IgeW91IGNhbiBjb2xsZWN0IHBhY2tldCB0cmFjZXMg ZnJvbSBuZXR3b3JrDQogdGFwcy4mbmJzcDsmbmJzcDsgWW91IHN0aWxsIG5lZWQgdGhlIGtl eXMgdG8gZGVyaXZlIG1lYW5pbmdmdWwgZGlhZ25vc3RpYyBhbmQgbW9uaXRvcmluZyBpbmZv cm1hdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0 IHdlIGhhdmUgaWxsdXN0cmF0ZWQgdGhlIGRpc2Nvbm5lY3QgaGVyZSwgaW4gc29tZSBzZW5z ZS4gJm5ic3A7IEhvd2V2ZXIsIGZyb20gbXkgcGVyc3BlY3RpdmUsIHdoYXQgSSBzZWUgaXMg dGhhdCB0aGVyZSBpcyBhIHByb2JsZW06IHlvdSBuZWVkIHRvIGJlIGFibGUgdG8gbG9vayBp bnNpZGUgdGhlIHN0cmVhbS4gJm5ic3A7IEkgdGhpbmsgd2UgYWdyZWUgdGhhdCB0aGlzIGlz IHRoZSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhIGZ1cnRoZXIgcHJvYmxlbTogeW91IGhhdmUg YSBzZXQgb2YgdG9vbHMgdGhhdCBzb2x2ZXMgdGhpcyBwcm9ibGVtIGluIGEgcGFydGljdWxh ciB3YXksIGFuZCBmb3IgdGhlIG1vbWVudCwgeW91IGFyZSBzdHVjayB3aXRoIHRob3NlIHRv b2xzLiAmbmJzcDsgVGhpcyBpcyB3aGVyZSBJIHRoaW5rIHRoZSBkaXNjb25uZWN0IHN0YXJ0 cy4gJm5ic3A7IEkgYW0gbm90IGRpc2FncmVlaW5nIHdpdGggeW91IHRoYXQsIGZvcg0KIHRo ZSBtb21lbnQsIHlvdSBhcmUgc3R1Y2sgd2l0aCB0aGVzZSB0b29scy5tICZuYnNwOyBCdXQs IEkgPGk+YW08L2k+Jm5ic3A7ZGlzYWdyZWVpbmcgd2l0aCB5b3Ugb24gdGhlIGNvbmNsdXNp b24gdGhhdCB0aGlzIHNpdHVhdGlvbiBsZWFkcyB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gbWUsIGl0IGxlYWRzIHRv IHRoZSBjb25jbHVzaW9uIHRoYXQgeW91IG5lZWQgdHdvIHRoaW5ncy4gJm5ic3A7IEZpcnN0 LCB5b3UgbmVlZCBhIHBsYW4gZm9yIGhvdyB0byBzdXJ2aXZlIHRoZSBzaXR1YXRpb24geW91 J3JlIHN0dWNrIGluIHJpZ2h0IG5vdy4gJm5ic3A7IFNlY29uZCwgeW91IG5lZWQgYSBwbGFu IGZvciBob3cgeW91J3JlIGdvaW5nIHRvIGFwcHJvYWNoIHRoaXMgd2hlbiBuZXh0IHlvdSB1 cGdyYWRlIHlvdXINCiBpbmZyYXN0cnVjdHVyZS4mbmJzcDsgSWYgSSB3ZXJlIGluIHlvdXIg cG9zaXRpb24sIG15IHBsYW4gZm9yIHRoZSBmaXJzdCBwYXJ0IHdvdWxkIGJlIHRvIHVzZSBU TFMgMS4yLiAmbmJzcDsgWW91IGFscmVhZHkgaGF2ZSB3aGF0IHlvdSB3YW50LCBhbmQgeW91 IGNvbnRyb2wgdGhlIGVuZHBvaW50cy4gJm5ic3A7IElmIGl0IGFpbid0IGJyb2tlLCB3aHkg Zml4IGl0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XaGF0IEkgdGhpbmsgaXMgdXJnZW50LCB0aG91Z2gsIGlzIHRoYXQgeW91 IGJlIHBsYW5uaW5nIGZvciBob3cgeW91J3JlIGdvaW5nIHRvIGhhbmRsZSB0aGlzIGdvaW5n IGZvcndhcmQuICZuYnNwOyBUaGVyZSBhcmUgYSBudW1iZXIgb2Ygd2F5cyBvZiBkb2luZyBp dC4gJm5ic3A7IE9uZSB3YXkgd291bGQgYmUgdG8ga2VlcCBhbiBhcHByb3ByaWF0ZWx5LXNj YWxlZCBsb2cgb2Yga2V5cy4mbmJzcDsgSWYgeW91IGp1c3QgbmVlZCB0byBsb29rDQogYXQg YWN0aXZlIHN0cmVhbXMsIGl0IHdvdWxkIGJlIGEgcm9sbGluZyBsb2csIGFuZCB5b3VyIHNu b29waW5nIGRldmljZSB3b3VsZCwgd2hlbiBhc2tlZCB0byBzbm9vcCBhIHN0cmVhbSwgZ2V0 IHRoZSBrZXkuICZuYnNwOyBUaGlzIGlzIGFuIGltcHJvdmVtZW50IG92ZXIgVExTIDEuMiwg YmVjYXVzZSBpdCBpbmNyZWFzZXMgYWNjb3VudGFiaWxpdHk6IHlvdSBoYXZlIHRvIGFzayBm b3IgYSBrZXkgdG8gZGVjcnlwdCBhIHBhcnRpY3VsYXIgY29udmVyc2F0aW9uLA0KIHNvIGl0 IGlzIGtub3duIHRoYXQgeW91IGRlY3J5cHRlZCB0aGF0IGNvbnZlcnNhdGlvbi4gJm5ic3A7 IE9mIGNvdXJzZSwgaWYgeW91IGFyZSBkZWNyeXB0aW5nIF9ldmVyeV8gY29udmVyc2F0aW9u LCB0aGF0J3Mgbm90IHNvIGdyZWF0LiAmbmJzcDsgT2YgY291cnNlLCBrZXkgZXhmaWx0cmF0 aW9uIGlzIGFuIGF0dGFjayBzdXJmYWNlLCBidXQgc28gaXMgdGhlIHN0YXRpYyBrZXkuICZu YnNwOyBCZXR0ZXIgZ2V0IHRoYXQgcmlnaHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvdGhlciB0aGluZyB5b3UgY2Fu IGRvIGlzIHRvIGRvIHByb3BlciB0b29saW5nIG9uIHlvdXIgc2VydmVycywgc28gdGhhdCB5 b3UNCjxpPmNhbiA8L2k+YWNjZXNzIHRoZSByYXcgc3RyZWFtLiAmbmJzcDsgVGhpcyB3b3Vs ZCByZXF1aXJlIGRpZmZlcmVudCB0b29saW5nIHRoYW4geW91IGhhdmUgbm93LCBidXQgdGhl cmUncyBubyB0ZWNobmljYWwgYmFycmllciB0byBkb2luZyBpdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm93LCBpdCdzIHBv c3NpYmxlIHRoYXQgZWl0aGVyIG9mIHRoZXNlIHNvbHV0aW9ucyB3b3VsZCBiZSBsZXNzIHNl Y3VyZSB0aGFuIHVzaW5nIGEgc3RhdGljIGtleS4gJm5ic3A7IEJ1dCBJIGRvbid0IGhlYXIg eW91IGFyZ3VpbmcgdGhhdC4gJm5ic3A7IFlvdSdyZSBzdGlsbCBiYWNrIG9uIHRhY3RpY3M6 IGhvdyBkbyBJIGRvIHdoYXQgSSBuZWVkIHRvIGRvIHdpdGggdGhlIHRvb2xzIEkgaGF2ZS4g Jm5ic3A7IFRoZSBhbnN3ZXIgaXMsIHVzZQ0KIFRMUyAxLjIgdW50aWwgeW91IHVwZ3JhZGUu ICZuYnNwOyBQdXQgdGhlIHRpbWUgaW4gdG8gc2hhdmUgb2ZmIGFsbCB0aGUgYXR0YWNrIHN1 cmZhY2VzIGZyb20geW91ciBUTFMgMS4yIGluc3RhbGxhdGlvbnMgdGhhdCBUTFMgMS4zIHNo YXZlcyBvZmYtLWRpc2FibGUgdGhlIGRlcHJlY2F0ZWQgYWxnb3JpdGhtcywgZm9yIGV4YW1w bGUuJm5ic3A7IEl0J3MgeW91ciBzaXRlLCB5b3UgY29udHJvbCB0aGUgZW5kcG9pbnRzLCB0 aGlzIHNob3VsZG4ndCBiZSBhIHByb2JsZW0uDQogJm5ic3A7IEJ1dCBiYXNpY2FsbHksIGp1 c3Qga2VlcCBkb2luZyB3aGF0IHlvdSBhcmUgZG9pbmcgZm9yIG5vdy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5YmUgdGhp cyBpcyBhIG5haXZlIHN1Z2dlc3Rpb24gb24gbXkgcGFydCwgYnV0IHdoYXQgSSBoYXZlbid0 IGJlZW4gaGVhcmluZyBpbiB0aGlzIGRpc2N1c3Npb24gaXMgc2VyaW91cyBjb25zaWRlcmF0 aW9uIG9mIHRoZSB0YWN0aWNhbCBwcm9ibGVtIGFuZCB0aGUgc3RyYXRlZ2ljIHByb2JsZW0u ICZuYnNwOyBXaGF0IEkndmUgYmVlbiBoZWFyaW5nIGlzICZxdW90O2ZvcmdldCBhYm91dCBz dHJhdGVneSwgd2Ugd2FudCB0YWN0aWNzLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCgoK PEJSPgo8aHRtbD4KIDxwPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21t dW5pY2F0aW9uIGlzIGhpZ2hseSBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVu aWNhdGlvbiBpcyBkaXJlY3RlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29weWlu ZywgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBw cm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFp bCBvciB0ZWxlcGhvbmUsIG9mIGFueSB1bmludGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0ZSB0 aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRob3V0IG1ha2luZyBhbnkgY29waWVzLjwvcD4KIDxw PkJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3 b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVu ZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29j aWF0aW9uLjwvcD4KICA8L2h0bWw+Cgo= --_000_CY4PR14MB1368A2ED677C83E02D10432ED7A20CY4PR14MB1368namp_-- From nobody Sat Jul 15 09:46:16 2017 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 8C3A4124D37 for ; Sat, 15 Jul 2017 09:46:15 -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, 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=nomountain-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 mmzQ6TFxMtke for ; Sat, 15 Jul 2017 09:46:14 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 563F91242F7 for ; Sat, 15 Jul 2017 09:46:14 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id q4so7308707oif.1 for ; Sat, 15 Jul 2017 09:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=kXleNnt4UueZhRQq6lRpLZyhoDE6m4V9A5sOq6qwJLs=; b=n/kv+hae2U/2mUcjaDufu/SZ1qvT2VGSczrcg7ibZBaoCrpyx4po2bblbBfgQRtEkm X8T/h9oku+PiKBzOUcts5NpmPcZ2/GLSLCXVXpfl0odZfVcFPp1Yum5lp2ZDnkfGr/Ao dxcI/n92bhGYuS7knbHm/Ijrdwb3ciCkjBqprYQl7mPu4E1yIT19jRC1Ai8+3hbqY/90 8EuzEkKH0GcDW7R4U8M1b5pETbxR9vr/CdaXwwbtRPqoVP8CWDvpsEZe+gSRYonJjQu9 y2+zVrBoOyFP/BxSu2vMDbExbwSD98flHwYfGYc74kByTtzCHQ/VHJsCPr3MgWyGRVEK xOrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=kXleNnt4UueZhRQq6lRpLZyhoDE6m4V9A5sOq6qwJLs=; b=fltjxP0GMb77wSrpVT79hMyHaelkNYofvnYIOqQ7ZQNS37ZzG9lhRkeHXObNzEsk1X tuVVofkOFs4iZtRXYHi0oM/JKHCMydkG/4m1vQbxCyVAu9yltcjjJ4vyK6ON4HZ3STq4 yRiy8+vLB48RJ4wqFSK2ksYQom+v+2rWTt4FhMLWS0EUP2HDEgieS5XiadMxu4LEcuZY 3Hz0XBJKC+5tEs1xonuIpWKUFU7qA/zICynbDwOVEih9bmK5NoG1QCw4A66Hq3Ub6nZ4 qWD2LYG+KOSap773v5hQtZd0p1eaWXJTXISqq1jDKRrId+xxNTk2za1+qxk12kUBmOPP 1pdQ== X-Gm-Message-State: AIVw110RVNoJRFUyV3Wylkv6s6UWmVy2uIrIcRtK01BUTo8gBTTbGnuP uZcUchh7zC6zNRwkPBCwqw== X-Received: by 10.202.102.158 with SMTP id m30mr8070519oik.149.1500137173421; Sat, 15 Jul 2017 09:46:13 -0700 (PDT) Received: from dhcp-9730.meeting.ietf.org (dhcp-9730.meeting.ietf.org. [31.133.151.48]) by smtp.gmail.com with ESMTPSA id c1sm16399445oih.5.2017.07.15.09.46.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 09:46:12 -0700 (PDT) To: tls@ietf.org References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> <6E53482A-0BDB-4118-92BD-EB82F7229477@sn3rd.com> From: Melinda Shore Message-ID: Date: Sat, 15 Jul 2017 18:44:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6E53482A-0BDB-4118-92BD-EB82F7229477@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="atlNCcUgdthTJHJnpXfU0tTjbBU7XHXAv" Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 16:46:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --atlNCcUgdthTJHJnpXfU0tTjbBU7XHXAv Content-Type: multipart/mixed; boundary="0VndpAu3x6egQ5AtXHmrtraRXhDXqBic7"; protected-headers="v1" From: Melinda Shore To: tls@ietf.org Message-ID: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> <6E53482A-0BDB-4118-92BD-EB82F7229477@sn3rd.com> In-Reply-To: <6E53482A-0BDB-4118-92BD-EB82F7229477@sn3rd.com> --0VndpAu3x6egQ5AtXHmrtraRXhDXqBic7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/15/17 4:01 PM, Sean Turner wrote: > draft-ietf-tls-dnssec-chain-extension is getting moved back to Monday > because that=E2=80=99s the only time Melinda can make. No, I'm afraid that I *cannot* make it Monday, and need to have our slot stay on Wednesday. Melinda --0VndpAu3x6egQ5AtXHmrtraRXhDXqBic7-- --atlNCcUgdthTJHJnpXfU0tTjbBU7XHXAv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZakaHAAoJELiGRpM6HoEu7KMP/RXSjvl9QkSiuUTDtb8ERV5F HkmZr6IADGNVoMTI7f/3C43WWPrxYWLXubTQ+CWw/isY7ULSi57YZn4rHpD/dUu0 u1XIaf2SfNoZ/HYNsWLdb4E/gC9HYkb+RCj/Noh4kxOi/CLb+daTzzX0ab9VfdIF 9uhmeYt/mbIX2K3GwNJEyf2Vhrust3v1wYmPHUSHw05eED2+mhw3qZdUT7isPSoP wkaOT1mpHayYLCxayZ2yPn9pe0rsCDs0d9lehU539C7qAiAkvQ3hxkpUpspwjVre rriAJ+myXVT2XEcM9OxEhKQv1uytRxH52jpv0QFq+3IIznXzGjlBZSEjpdYzZnF6 tx+XNZLoVE8F5nOzNIL2cZPjV3V/AuYEWsPEmWb4KcFeEj+aL3Oloj/+QSVSBDX+ mmIRlqoU96g5MghQ9dWUfQobi7g5kTxpIMN3fveo1zkwA0RTnMv1Tx2bA4oCzaMY dMkJ2iBywOuyDLtBqtukthffNwdo4SZHre5rZRcAEAsM9Fq80/bBKm7kNcb6qAoZ Mld/ESpjpd8VHGqWOAsnGatpLfCliB3DdLnk+CbdK1flQ4XLPa2vbJ/LTh9FJXRT apnrc/vg0KzlMVFs4LZUyNF9CccpcuJuWqoT9yrfMA8TxxpxtKHzdqTmu2yUN5o/ 1Vq4S1FC5NCb8oD2AZIF =Ahw6 -----END PGP SIGNATURE----- --atlNCcUgdthTJHJnpXfU0tTjbBU7XHXAv-- From nobody Sat Jul 15 10:34:07 2017 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 2FD7712702E for ; Sat, 15 Jul 2017 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 kyU646iiDWu5 for ; Sat, 15 Jul 2017 10:34: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 87D9F126C2F for ; Sat, 15 Jul 2017 10:34:03 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v193so35455697ywg.2 for ; Sat, 15 Jul 2017 10:34:03 -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=b/u7nDIImQYOuzSAmVjwODkw5D6TZnpRRn1ZAo6gWUY=; b=KMWRmnXIAzloxtUF/fv3LcPj3mzh0o2ehgvRrl+5R4A/alw+Hw+wXBgPQpU5kNM2w1 dbxHU5ur6BAQVpweOaB/suWBFwtSkk24yd1FHNSntUrTBMhM2IEg9dPZT3cdyXUMD5ug GnMBND5eRcCRM+uTLP/yNW1cNRcmUaxLdikxu8AD0juEFrBrJlcYlfY5oVu+2G4GIzSp ttjRZA53LNodtnWee4PAFn6g+RlHLl2NUcyVw10lBYz7+HNmdGYBWGOOUAwgHUY4XAVI jtBA5pef9iowmesptkIQlVCuEyV9QY6U2DLCUZp1H5ENC6Fj7YUnbYLPm3lG7BA1tCxC QP4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b/u7nDIImQYOuzSAmVjwODkw5D6TZnpRRn1ZAo6gWUY=; b=HoT3DcPiPvx2rdJY7KgQ7jHrx1YTTN0sbVmzjryPai035vPxzXnR2/IDSnKOrdU2kt dZgVeQMyxCLQuUxJZQv8CwelYQ1q3bz2O0/JZyiieJB7YNXzj4z/Qs+jtWz5YZnHhyJ4 DSPooU+bBdl465277uXdtg96THj3YCKRii93Y1aPGB9M3svJlk+6o4JRyX+KLdW1TfcN MbzM/C7BjyEenWuO+CIzVLxuNH9uIqIBadL+3UmDScn7gqBHvU1WolQeLDnMywYJMEFI SyWxpsoFmX9nnSuiqLe5IMhkjssxUhcl9lEqSR+Q4RtECnrpsxfNci9MqMUD3fqHdSzd r2SQ== X-Gm-Message-State: AIVw111pTFj4OZMZGgBX+YMALvTa8DAnUIkBuAcK6kYT+dkHNx2ueMBm Ic0+XCjDa+1mMpOcTGm/YMWc+781aO8i X-Received: by 10.129.90.85 with SMTP id o82mr5287408ywb.251.1500140042599; Sat, 15 Jul 2017 10:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.27.4 with HTTP; Sat, 15 Jul 2017 10:34:01 -0700 (PDT) In-Reply-To: <87o9smrzxh.fsf@fifthhorseman.net> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sat, 15 Jul 2017 10:34:01 -0700 Message-ID: To: Daniel Kahn Gillmor Cc: "Salz, Rich" , Joseph Lorenzo Hall , Matthew Green , Nick Sullivan , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114924265a78c405545e92b3" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 17:34:05 -0000 --001a114924265a78c405545e92b3 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor wrote: > * This proposed TLS variant is *never* acceptable for use on the public > Internet. At most it's acceptable only between two endpoints within > a datacenter under a single zone of administrative control. > > * Forward secrecy is in general a valuable property for encrypted > communications in transit. > If there's anyone on the list who disagrees with the above two > statements, please speak up! > I agree with the second statement, but I don't really follow the logic of the first. On the public internet, it's increasingly common for traffic to be MITMd in the form of a CDN. Many commenters here have also responded "Just use proxies". I don't get how that's better. A proxy sees all of the plaintext, not just selected amounts. All of the same coercion and compromise risks apply to a proxy too, but since it undetectably sees everything, that would seem objectively worse from a security/privacy risk POV. Or put another way: if these organizations need to occasionally inspect plaintext, would I prefer that it's the kind of system where they have to go pull a key from a store, and decrypt specific ciphertexts on demand offline, or do I want them recording plaintext *all* of the time inline? It seems utterly bizarre that we would collectively favor the latter. We end up recommending the kinds of systems that are an attacker's dream. Here's what I'd prefer: * Don't allow static DH. In fact, forbid it, and recommend that clients check for changing DH params. * For the pcap-folks, define an extension that exports the session key or PMS, encrypted under another key. Make this part of the post-handshake transcript. * pcap-folks can do what they want, but clients will know and can issue security warnings if they desire. Forbiding static DH enforces this mechanism, and we can collectively land in a better place than we are today. -- Colm --001a114924265a78c405545e92b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor <dkg@fifthho= rseman.net> wrote:
=C2=A0* T= his proposed TLS variant is *never* acceptable for use on the public=
=C2=A0 =C2=A0Internet.=C2=A0 At most it's acceptable only between two e= ndpoints within
=C2=A0 =C2=A0a datacenter under a single zone of administrative control.

=C2=A0* Forward secrecy is in general a valuable property for encrypted
=C2=A0 =C2=A0communications in transit.

If there's anyone on the list who disagrees with the above two
statements, please speak up!

I agree wi= th the second statement, but I don't really follow the logic of the fir= st. On the public internet, it's increasingly common for traffic to be = MITMd in the form of a CDN. Many commenters here have also responded "= Just use proxies". I don't get how that's better.=C2=A0
<= div>
A proxy sees all of the plaintext, not just selected amo= unts. All of the same coercion and compromise risks apply to a proxy too, b= ut since it undetectably sees everything, =C2=A0that would seem objectively= worse from a security/privacy risk POV.=C2=A0
=C2=A0
= Or put another way: if these organizations need to occasionally inspect pla= intext, would I prefer that it's the kind of system where they have to = go pull a key from a store, and decrypt specific ciphertexts on demand offl= ine, or do I want them recording plaintext *all* of the time inline? It see= ms utterly bizarre that we would collectively favor the latter. We end up r= ecommending the kinds of systems that are an attacker's dream.=C2=A0

Here'= ;s what I'd prefer:

=C2=A0* Don't allow static DH. In fact, forbid it, an= d recommend that clients check for changing DH params.=C2=A0
=C2=A0* For the pcap-folks, define an extension that expo= rts the session key or PMS, encrypted under another key. Make this part of = the post-handshake transcript.=C2=A0
=C2=A0= * pcap-folks can do what they want, but clients will know and can issue sec= urity warnings if they desire. Forbiding static DH enforces this mechanism,= and we can collectively land in a better place than we are today.=C2=A0
=C2=A0
<= br>
--
Colm
--001a114924265a78c405545e92b3-- From nobody Sat Jul 15 11:03:07 2017 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 5BE3F128B8D for ; Sat, 15 Jul 2017 11:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 7RUIu_T7Cdo5 for ; Sat, 15 Jul 2017 11:03:04 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0136.outbound.protection.outlook.com [104.47.34.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0653A120721 for ; Sat, 15 Jul 2017 11:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B/ABhs5lHarP5iOpkXlHxkjPQw2BXmOFfY8nRv9BOv4=; b=lGJpu1gJfNCqOkz7x4TZmDGwvBsSchebKNNIdD3jFgNEbzmSpgimAAS6FaIC0HThWQk9dMv18PfZdAQm1DyYWM99uk+0T1qHjFiU6XbToHzOSZ/zB7G5KQ0EvpaOUgvL7VA92KVfISsijbUDrcf16EMCJqeVLxrJWXwM5Eel4IA= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 18:03:02 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.023; Sat, 15 Jul 2017 18:03:02 +0000 From: "Dobbins, Roland" To: "Ackermann, Michael" CC: Ted Lemon , IETF TLS , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/TNOetAoAc0WMUGwvSG+0rIljKJUgY1igAABS4CAAAIPE4AAAzcAgAB9sICAACj9Zw== Date: Sat, 15 Jul 2017 18:03:01 +0000 Message-ID: <46888EEF-750B-46CF-BA77-1827DD6D3607@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bcbsm.com; dkim=none (message not signed) header.d=none;bcbsm.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [27.55.7.59] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 7:Fsbe22VT+QjE162Tpy9fsarUnNTvwDikFACe3TcacH2mvPlZo3QM7PCTYiZNOtLK/TgSyFG5tj0SqnffqQbco68AmeBPvc9EwYv2YwK99PHlGXXOlif+BDUj4zzOG6a6ZbwmjXN28XopGIUqJjxIbkxOyEckmix3e95L7uQQL/HRfHF53B5OPs08XMDqQVJ5ByMbOKxSMl4/5cFNXrWowHjtoBzWram3WgIbrMeo4wAD+iGhf7Wd/fQI9fNAPTSQkY6ejlIeLpWTANwhsSDvdbJeLTmeombDWuQQbKPRmKSM6pUa6soQgbJUx1tGt/Ryj7V/HVQQ65NTMaOuVvkpkTVfSKuehjklIkHrpaU0/shNCg3y4YV0IYQJNb1Fq9xWBrLmNumNUwe5ZwFU2L936NKQo3oNeBb4EOVs0jILCEykausl/n8RSLpvxG3LE7ZE/QjkyvMbzs/fXr5/iDhNhEmapFpzAZ3Y9/cYe2vFAraX9RYll4spDBZV4yETzekxR+WsY0wkrQf8lzbxUnjBpqSOZIQvF3qlgXDDx1GmKqF4GVXsO9xwMdEvUwsEpPssNh+6FHAtxBAXZ3tbhNuqY6LFJDshy+kBDnqOu9JOzQT5cXoVj6k7KLkbvDKCVfc9kNAzmvKrMB8wbj9LDSaqjHs1dJZqZ8URo5mifL0Jog4RqXaRUp5SaK9RKCO36rcnPioOkAPoYT8qV5NlSIxPhag8rp4+LubvJEcPKNOvM7qwnn4TtCtUWix/MXYJtMnYFyn7BKJ+/eozCEFzteAuptp/Ycaup0CRqC5qryK3f3Y= x-ms-office365-filtering-correlation-id: 740820b6-af29-4033-93f0-08d4cbabbc07 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; x-ms-traffictypediagnostic: DM2PR0101MB1039: x-exchange-antispam-report-test: UriScan:(236129657087228)(86572411397741)(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39400400002)(39450400003)(39410400002)(39840400002)(24454002)(236005)(229853002)(6512007)(6486002)(3660700001)(76176999)(54356999)(50986999)(478600001)(33656002)(6506006)(7736002)(54906002)(54896002)(99286003)(5250100002)(2906002)(86362001)(82746002)(53936002)(5660300001)(3280700002)(83716003)(230783001)(110136004)(6246003)(38730400002)(39060400002)(6436002)(53546010)(6116002)(102836003)(3846002)(189998001)(8676002)(6916009)(2950100002)(8936002)(81166006)(14454004)(93886004)(66066001)(4326008)(25786009)(36756003)(2900100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_46888EEF750B46CFBA771827DD6D3607arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 18:03:01.5385 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 18:03:06 -0000 --_000_46888EEF750B46CFBA771827DD6D3607arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNSwgMjAxNywgYXQgMjI6MzYsIEFja2VybWFubiwgTWljaGFlbCA8TUFja2Vy bWFubkBiY2JzbS5jb208bWFpbHRvOk1BY2tlcm1hbm5AYmNic20uY29tPj4gd3JvdGU6DQoNClRo YXQgYmVpbmcgdGhlIHVuZW5jcnlwdGVkIHN0cmVhbSBpcyBhdmFpbGFibGUgdG8gdGhlIGVuZHBv aW50cw0KDQpFdmVuIHdoZXJlIGl0IGlzIGV2ZW50dWFsbHkgYXZhaWxhYmxlLCB0aGV5IGRvbid0 IGhhdmUgdGhlIGhvcnNlcG93ZXIgdG8gY2FwdHVyZSAmIGZvcndhcmQuDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3Iu bmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KDQoNCg== --_000_46888EEF750B46CFBA771827DD6D3607arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE1LCAyMDE3 LCBhdCAyMjozNiwgQWNrZXJtYW5uLCBNaWNoYWVsICZsdDs8YSBocmVmPSJtYWlsdG86TUFja2Vy bWFubkBiY2JzbS5jb20iPk1BY2tlcm1hbm5AYmNic20uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+VGhhdCBiZWluZyB0 aGUgdW5lbmNyeXB0ZWQgc3RyZWFtIGlzIGF2YWlsYWJsZSB0byB0aGUgZW5kcG9pbnRzJm5ic3A7 PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZGl2PkV2ZW4gd2hlcmUgaXQgaXMgZXZlbnR1 YWxseSBhdmFpbGFibGUsIHRoZXkgZG9uJ3QgaGF2ZSB0aGUgaG9yc2Vwb3dlciB0byBjYXB0dXJl ICZhbXA7IGZvcndhcmQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48c3Bh biBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxzcGFu IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0 LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJy IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0 LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyI+DQo8c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFs OyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPlJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVm PSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVl IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5cGU9ImxpbmsiIHgtYXBwbGUtZGF0YS1kZXRlY3Rv cnMtcmVzdWx0PSIyIj5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozwvc3Bhbj48L3NwYW4+PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_46888EEF750B46CFBA771827DD6D3607arbornet_-- From nobody Sat Jul 15 11:05:21 2017 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 D09281241FC for ; Sat, 15 Jul 2017 11:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 zHv6VT-PRWzk for ; Sat, 15 Jul 2017 11:05:18 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0130.outbound.protection.outlook.com [104.47.32.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27760120721 for ; Sat, 15 Jul 2017 11:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DJsj1OaQmlNvp56VzZM0kpmIH2k5m4aZluzwXzbu/mM=; b=e6YCXSri65bfHvNIzlW0DCofeyCzAPBVYy+wI52111uv62W1sVmYfXBCcQ1y3e4B8h1k33iRWV1UxgKdfiknTa3CRZZyw2zVQn8cpNBO0QkeDgYnFx8ycWbEY79FstpE3RfPWzvbHfqEw4I1JRGeVGOymbGRd2FqRRcR0xg1/kg= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 18:05:15 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1240.023; Sat, 15 Jul 2017 18:05:15 +0000 From: "Dobbins, Roland" To: "Ackermann, Michael" CC: Ted Lemon , IETF TLS , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/TNOetAoAc0WMUGwvSG+0rIljKJUgY1igAABS4CAAAIPE4AAAzcAgAB9sICAACmdiw== Date: Sat, 15 Jul 2017 18:05:15 +0000 Message-ID: <793335AE-31BC-4219-A4FB-286D9C874C73@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bcbsm.com; dkim=none (message not signed) header.d=none;bcbsm.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [27.55.7.59] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:COHJHIc7czj7rCbwzRDYPZgASqU/sYPcbJcSbnyDrcFQxef4kY4JPW+F3/loIBt1F89UWziv69nEkRj1Yof98swoOgRlqajQuo/LTBDi7umjHuWmtvgXwZL/6hYcsBHBzxAVGaWvvV/efF0XaJqNFLUj4nbjQuIV5XKTgHz2se+4mozLCTRQPb+MQm6JsLqlUro6RKyoOFqRA9DEqqwxBk/V1tPWx59R7Wx4ptopxogcwSYpTwDclOvzviohnMkKvNTPYp3v9QSHhHfrOeGM48PsoiPNmBfVjJqKh/N3kRosXrC1WYX2wjpEzfEop087dku3A9m46i+RBA3BLCeaJlbaBZ2yXpTaxNtKR7jyh6b1fTP0yhNtGW5/1A58xA/fsQBVAkKaPa92OWDFaWeukFCRn6T1qIqj8Q5nqWYSz8wmuHCAdlqkJiKqa/TT9CNhVlL3R/2FqX1nCogukOV4aFq9/jfw7uiInIcWI6Jm3JDltbBgjzP/ZbrXkv4+Kedbowq+tLze8patz7N7pHmCtsT6eyEbBFVqln9FeAx9Kgvm0hg2K9rJ3Yl88A5ilXZKzljQL2huTYuXjUT69H/dhBUpSAyXIbH7avosh3OsjPbcBPo/+NUlVqdOv8AG2eSs5aTeA2FpnkXB2y6bfXRYIqLHKlRmgBpIXcEsK8IkHg1x2sqPO6fZncrv0Fnf2DLa3UM8RtZ17STcNcM3i9NGpkvHM4Hq2p/4VK6h3DPYjOuoRuA2SRgaZ0/EG6kqXNqljrlqoDKFswIywj46gg7aJ/JVAzEeNL7JhKJpHNZNR5Y= x-ms-office365-filtering-correlation-id: fcba5d70-75ed-4045-1ad7-08d4cbac0bc5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(236129657087228)(86572411397741)(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39410400002)(39400400002)(39450400003)(24454002)(66066001)(6486002)(229853002)(2900100001)(25786009)(6506006)(5250100002)(39060400002)(230783001)(93886004)(53936002)(189998001)(36756003)(14454004)(82746002)(86362001)(38730400002)(2950100002)(6916009)(478600001)(6246003)(83716003)(110136004)(7736002)(6436002)(3280700002)(3660700001)(54906002)(6512007)(236005)(99286003)(54896002)(5660300001)(33656002)(2906002)(81166006)(53546010)(76176999)(4326008)(8676002)(8936002)(50986999)(54356999)(102836003)(3846002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_793335AE31BC4219A4FB286D9C874C73arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 18:05:15.6800 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 18:05:20 -0000 --_000_793335AE31BC4219A4FB286D9C874C73arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNSwgMjAxNywgYXQgMjI6MzYsIEFja2VybWFubiwgTWljaGFlbCA8TUFja2Vy bWFubkBiY2JzbS5jb208bWFpbHRvOk1BY2tlcm1hbm5AYmNic20uY29tPj4gd3JvdGU6DQoNClNv IHlvdSBjYW4gY29sbGVjdCBwYWNrZXQgdHJhY2UgaW5mb3JtYXRpb24gYXQgdGhvdXNhbmRzIG9y IG5vZGVzDQoNClRoaXMgaXMgcHJlY2lzZWx5IHdoYXQgaXMgYmVpbmcgcG9zaXRlZCwgd2hpY2gg aXMgb2J2aW91c2x5IHVud29ya2FibGUuDQoNClRoZXJlJ3MgYSByZWFsIGxhY2sgb2YgdW5kZXJz dGFuZGluZyBvZiB0aGUgY2hhbGxlbmdlcyBvZiBzY2FsZSwgaGVyZS4NCg0KV2hpY2ggaXMgcmF0 aGVyIGlyb25pYy4NCg0KOz4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9y Lm5ldD4+DQo= --_000_793335AE31BC4219A4FB286D9C874C73arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE1LCAyMDE3 LCBhdCAyMjozNiwgQWNrZXJtYW5uLCBNaWNoYWVsICZsdDs8YSBocmVmPSJtYWlsdG86TUFja2Vy bWFubkBiY2JzbS5jb20iPk1BY2tlcm1hbm5AYmNic20uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+U28geW91IGNhbiBj b2xsZWN0IHBhY2tldCB0cmFjZSBpbmZvcm1hdGlvbiBhdCB0aG91c2FuZHMgb3Igbm9kZXM8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjxkaXY+VGhpcyBpcyBwcmVjaXNlbHkgd2hhdCBpcyBi ZWluZyBwb3NpdGVkLCB3aGljaCBpcyBvYnZpb3VzbHkgdW53b3JrYWJsZS4mbmJzcDs8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXJlJ3MgYSByZWFsIGxhY2sgb2YgdW5kZXJzdGFu ZGluZyBvZiB0aGUgY2hhbGxlbmdlcyBvZiBzY2FsZSwgaGVyZS4gJm5ic3A7PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGljaCBpcyByYXRoZXIgaXJvbmljLiZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+OyZndDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDAp OyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJp YW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwv c3Bhbj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJp YW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1w b3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+Um9sYW5kIERvYmJpbnMgJmx0 OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiIHgtYXBwbGUtZGF0YS1kZXRlY3Rv cnM9InRydWUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtdHlwZT0ibGluayIgeC1hcHBsZS1kYXRh LWRldGVjdG9ycy1yZXN1bHQ9IjIiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PC9zcGFuPjwv c3Bhbj48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_793335AE31BC4219A4FB286D9C874C73arbornet_-- From nobody Sat Jul 15 11:16:19 2017 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 3567012F5DB for ; Sat, 15 Jul 2017 11:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 Dk-tMBikz7ty for ; Sat, 15 Jul 2017 11:16:16 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 986DA126C7A for ; Sat, 15 Jul 2017 11:16:14 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 7CBEE1C18E6 for ; Sat, 15 Jul 2017 13:16:13 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 86C9E1C176C; Sat, 15 Jul 2017 13:16:12 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 506679206F; Sat, 15 Jul 2017 14:16:12 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 10DB99206A; Sat, 15 Jul 2017 14:16:12 -0400 (EDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (unknown [207.46.163.22]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Sat, 15 Jul 2017 14:16:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nQH9kYlOwm648GvmtF0WMG2Tqx5Cx5SUNgQLyT4YQgo=; b=TWfaLofbaVqT9LN/kr5+psEDL+Fb/1mP9vBxko7MsEcfbfx23Dm6Y8Lmv91abLpqWZGKBB094XEDJ1Q5QvFsHokkXAOlzOA6sWQyO6gHHWOQ0bcpTnDjBgTbmsII0yoZNUvwJTbxNwSXbwVVtw+N1d9dx8DUAspquHS3omJtHEQ= Received: from BN6PR14MB1361.namprd14.prod.outlook.com (10.172.149.135) by BN6PR14MB1362.namprd14.prod.outlook.com (10.172.149.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Sat, 15 Jul 2017 18:16:10 +0000 Received: from BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) by BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) with mapi id 15.01.1261.020; Sat, 15 Jul 2017 18:16:10 +0000 From: "Ackermann, Michael" To: "Dobbins, Roland" CC: Ted Lemon , IETF TLS , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIALriyAgAAVWACAAAFKgIAAAg+AgAADOACAAHw4YIAAKnSAgAADSxA= Date: Sat, 15 Jul 2017 18:16:10 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> , <46888EEF-750B-46CF-BA77-1827DD6D3607@arbor.net> In-Reply-To: <46888EEF-750B-46CF-BA77-1827DD6D3607@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arbor.net; dkim=none (message not signed) header.d=none;arbor.net; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.0.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1362; 20:YpYCK1Ggnx6bTVpNOo6cAb8y4eukQ17J3HoNnYRMdHpfnJsZymUhbGjQmMT0VNmrQ3X6Np6dtL0cIDQhl/9nKXZ6Ip4kZZl5giIjR6dbalTooLJhFFgwvuOkCmF5IDYftiegQCvAxjQ1dxV8PL/DmQf0TQTK7mmrb7t1ZVDS1Rg= x-ms-office365-filtering-correlation-id: 710865df-0a04-4a7c-31f0-08d4cbad91fb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR14MB1362; x-ms-traffictypediagnostic: BN6PR14MB1362: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(148574349560750)(21748063052155)(86572411397741); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR14MB1362; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR14MB1362; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39400400002)(39410400002)(39830400002)(377454003)(24454002)(14454004)(6436002)(53546010)(2900100001)(2906002)(229853002)(99286003)(54906002)(77096006)(7696004)(55016002)(478600001)(6506006)(93886004)(80792005)(6306002)(54896002)(9686003)(236005)(19609705001)(25786009)(8936002)(53936002)(8676002)(66066001)(230783001)(72206003)(33656002)(39060400002)(3660700001)(3280700002)(790700001)(4326008)(102836003)(3846002)(6116002)(74316002)(189998001)(81166006)(6246003)(7736002)(54356999)(2950100002)(6916009)(50986999)(76176999)(38730400002)(110136004)(5660300001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1362; H:BN6PR14MB1361.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR14MB13612896CAA0EA9AB34BA390D7A20BN6PR14MB1361namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 18:16:10.3459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1362 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: fba002b9-3626-4e49-ad4d-027cda1cd9ce X-VPM-MSG-ID: d9508ab4-b7a3-4d62-b65f-390f1881f9b6 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 18:16:18 -0000 --_000_BN6PR14MB13612896CAA0EA9AB34BA390D7A20BN6PR14MB1361namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WUVTIQ0KSSB0cmllZCB0byBzYXkgaW4gbXkgbWVzc2FnZSB0aGF0IGNvbGxlY3RpbmcgdHJh Y2VzIG9uIHRob3VzYW5kcywgIG9yIGh1bmRyZWRzIG9mIHRob3VzYW5kcyBvZiBob3N0cywg IGlzIGp1c3Qgbm90IHByYWN0aWNhbCBvciBwb3NzaWJsZS4gICBOb3QgdG8gbWVudGlvbiB0 aGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGJhcnJpZXJzIHRvIHRoaXMuDQoNCg0KDQpGcm9t OiBEb2JiaW5zLCBSb2xhbmQgW21haWx0bzpyZG9iYmluc0BhcmJvci5uZXRdDQpTZW50OiBT YXR1cmRheSwgSnVseSAxNSwgMjAxNyAyOjAzIFBNDQpUbzogQWNrZXJtYW5uLCBNaWNoYWVs IDxNQWNrZXJtYW5uQGJjYnNtLmNvbT4NCkNjOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5j b20+OyBJRVRGIFRMUyA8dGxzQGlldGYub3JnPjsgTWF0dGhldyBHcmVlbiA8bWF0dGhld2Rn cmVlbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1RMU10gZHJhZnQtZ3JlZW4tdGxzLXN0 YXRpYy1kaC1pbi10bHMxMy0wMQ0KDQoNCg0KT24gSnVsIDE1LCAyMDE3LCBhdCAyMjozNiwg QWNrZXJtYW5uLCBNaWNoYWVsIDxNQWNrZXJtYW5uQGJjYnNtLmNvbTxtYWlsdG86TUFja2Vy bWFubkBiY2JzbS5jb20+PiB3cm90ZToNClRoYXQgYmVpbmcgdGhlIHVuZW5jcnlwdGVkIHN0 cmVhbSBpcyBhdmFpbGFibGUgdG8gdGhlIGVuZHBvaW50cw0KDQpFdmVuIHdoZXJlIGl0IGlz IGV2ZW50dWFsbHkgYXZhaWxhYmxlLCB0aGV5IGRvbid0IGhhdmUgdGhlIGhvcnNlcG93ZXIg dG8gY2FwdHVyZSAmIGZvcndhcmQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9i Ymluc0BhcmJvci5uZXQ+Pg0KDQoNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhp cyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5n LCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0 aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ry b25pYyBtYWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQg ZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMu CiAKIEJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBO ZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRl cGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFz c29jaWF0aW9uLgo= --_000_BN6PR14MB13612896CAA0EA9AB34BA390D7A20BN6PR14MB1361namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WUVT ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SSB0cmllZCB0byBzYXkgaW4gbXkgbWVzc2FnZSB0aGF0IGNvbGxlY3Rp bmcgdHJhY2VzIG9uIHRob3VzYW5kcywmbmJzcDsgb3IgaHVuZHJlZHMgb2YgdGhvdXNhbmRz IG9mIGhvc3RzLCZuYnNwOyBpcyBqdXN0IG5vdCBwcmFjdGljYWwgb3IgcG9zc2libGUuJm5i c3A7Jm5ic3A7IE5vdCB0byBtZW50aW9uIHRoZSBhZG1pbmlzdHJhdGl2ZQ0KIGRvbWFpbiBi YXJyaWVycyB0byB0aGlzLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5k Q29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERvYmJpbnMsIFJvbGFuZCBbbWFpbHRvOnJk b2JiaW5zQGFyYm9yLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVseSAx NSwgMjAxNyAyOjAzIFBNPGJyPg0KPGI+VG86PC9iPiBBY2tlcm1hbm4sIE1pY2hhZWwgJmx0 O01BY2tlcm1hbm5AYmNic20uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVGVkIExlbW9uICZs dDttZWxsb25AZnVndWUuY29tJmd0OzsgSUVURiBUTFMgJmx0O3Rsc0BpZXRmLm9yZyZndDs7 IE1hdHRoZXcgR3JlZW4gJmx0O21hdHRoZXdkZ3JlZW5AZ21haWwuY29tJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW1RMU10gZHJhZnQtZ3JlZW4tdGxzLXN0YXRpYy1kaC1pbi10 bHMxMy0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24g SnVsIDE1LCAyMDE3LCBhdCAyMjozNiwgQWNrZXJtYW5uLCBNaWNoYWVsICZsdDs8YSBocmVm PSJtYWlsdG86TUFja2VybWFubkBiY2JzbS5jb20iPk1BY2tlcm1hbm5AYmNic20uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYXQgYmVpbmcgdGhlIHVuZW5jcnlwdGVkIHN0cmVhbSBpcyBh dmFpbGFibGUgdG8gdGhlIGVuZHBvaW50cyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIHdoZXJlIGl0IGlzIGV2 ZW50dWFsbHkgYXZhaWxhYmxlLCB0aGV5IGRvbid0IGhhdmUgdGhlIGhvcnNlcG93ZXIgdG8g Y2FwdHVyZSAmYW1wOyBmb3J3YXJkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NClJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86 cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0OzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQoK CjxCUj4KPGh0bWw+CiA8cD5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29t bXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11 bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlp bmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMg cHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1h aWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUg dGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGllcy48L3A+CiA8 cD5CbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hpZ2FuIGFuZCBCbHVlIENhcmUgTmV0 d29yayBvZiBNaWNoaWdhbiBhcmUgbm9ucHJvZml0IGNvcnBvcmF0aW9ucyBhbmQgaW5kZXBl bmRlbnQgbGljZW5zZWVzIG9mIHRoZSBCbHVlIENyb3NzIGFuZCBCbHVlIFNoaWVsZCBBc3Nv Y2lhdGlvbi48L3A+CiAgPC9odG1sPgoK --_000_BN6PR14MB13612896CAA0EA9AB34BA390D7A20BN6PR14MB1361namp_-- From nobody Sat Jul 15 12:12:33 2017 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 49187127B73 for ; Sat, 15 Jul 2017 12:12:31 -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 (2048-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 cOYFKuSBrIbp for ; Sat, 15 Jul 2017 12:12:30 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 65CBD1243F6 for ; Sat, 15 Jul 2017 12:12:30 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6FJBwPt030792; Sat, 15 Jul 2017 20:12:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=72kRdUj8RhPwOam9OI2NJ7anQOnItNB7Q+Evc285dAM=; b=NsOgMfk9VJny2WRFS962eX5gBE4j7u3DB7XbguKInxTApisPfq2jwPFRL5NlTJXU6KYJ hmxJbQdEpvaV/pUMO9rLhbqQJgV9vIedNYwxwPXkXGKr0FF71MOC0R4KYZlUrHZJSZjx Qn2wGGibRDTnkWuOFFSuxJea3HJTr3D/0UGnpHgH6Xeq3XOB9HTZ7DTqMgjQDmOkwihr /4oT3rzipOC6C8wiC3mtO4sXRXPoXA+MtXuSLovinGhv5XjQ00kWL32QGm5mTKr50Ksx RGX6EP38plpIHUvKaerlxzapO19OVs6k3ki7Fns8cSFtCVEWSRN4VHGruDoO6TFL/x4y Rg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2bqaarja46-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 20:12:25 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6FJAakQ001266; Sat, 15 Jul 2017 15:12:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2bqecus65f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 15:12:24 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 15 Jul 2017 12:12:23 -0700 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.1263.000; Sat, 15 Jul 2017 15:12:23 -0400 From: "Salz, Rich" To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , "Daniel Kahn Gillmor" CC: Joseph Lorenzo Hall , Matthew Green , Nick Sullivan , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEA== Date: Sat, 15 Jul 2017 19:12:22 +0000 Message-ID: <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707150321 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707150321 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 19:12:31 -0000 PiBPbiB0aGUgcHVibGljIGludGVybmV0LCBpdCdzIGluY3JlYXNpbmdseSBjb21tb24gZm9yIHRy YWZmaWMgdG8gYmUgTUlUTWQgaW4gdGhlIGZvcm0gb2YgYSBDRE4uDQoNCkEgQ0ROIGlzIG5vdCBh IG1pZGRsZWJveCwgaXQgaXMgbm90IGEgTUlUTS4gIEl0IGlzIGEgc2l0ZSB0aGF0IHRoZSBvcmln aW4gaGFzIGhpcmVkIHRvIGFjdCBhcyBhICJmcm9udCIgdG8gaXQuDQoNCg0K From nobody Sat Jul 15 12:24:21 2017 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 39629124D37 for ; Sat, 15 Jul 2017 12:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6_eHEzEafI6Y for ; Sat, 15 Jul 2017 12:24:18 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 A01A11288B8 for ; Sat, 15 Jul 2017 12:24:16 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id q86so59590807pfl.3 for ; Sat, 15 Jul 2017 12:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yqDn9cFOsBvzcCLbMAttSaaa5ybTN8m8hZHwM2wMgCk=; b=Sg92vQ1m7CIEGYLUsfj3Dnc++Hp7K1TNUGuucBz3Qo/1h0C8BsQjRWQXBDTCVE6Goy /VQue2NQilJES9HZ7xbtvU8aULIdmsGAWYShRpSgbIHet2/px8P6Q0KTX58eeVmWk5f0 /FFxaniEKv8NYPN7Xs/MQAdhigNR/VRqRZZyIJ4HSm3sUnJNfzzQrFCYMukjF6XQEXIF hv/WSlxVMVhqkjERWbLXyDwXo4BuEpLbzWnGHF9WI6rcm9oii2diDgdCUpYFMhfzLGxr etl/6TJhEEcCA4R+cUyuX+lmw8iGEdcEvVBaUV6bWP3dkKMctELXa4XWka4hiWnwKBJ9 Bq2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yqDn9cFOsBvzcCLbMAttSaaa5ybTN8m8hZHwM2wMgCk=; b=WDo9vEjxzG3kc+35hrudaQRxsSJtMp65/mLnGDUiWQ2VHAKcx+y+urKqJmLZ8fOBll CXlN0/rESgqTGwikVuQyvisC63vx4HL7khHKdH+ty0XoP1BGNwrEP0PHJk4+zcRWG8YZ KsBf79gGYR7KNid2pBtkwBE5SfM7Y8YzAKTZl3/up4SmNUwUCJZ8CttMASkvOQWd0rx/ KUtFXTrnqJZ8G9u8cn0OdYP7vXEVWSJ4qhQf+MN6XSDCVrvRELTdbaWONwGp1Z8tn+ka fFuD7lWYzYMHSgHqZ+sVGqd2YJ8O2m4/RV6W9LN062/E+MCLf8c4hkiE7MPCNpy7aAot VQkQ== X-Gm-Message-State: AIVw113jdSsPd8DkVd/pu7Km55P8DtsN1Tlrmonq5GC23bACrqMqCJaA PF4j+5I9LCAvLz0+xe3ztPnb6SZalQ== X-Received: by 10.84.230.134 with SMTP id e6mr22370221plk.2.1500146656268; Sat, 15 Jul 2017 12:24:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 12:24:14 -0700 (PDT) Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 12:24:14 -0700 (PDT) In-Reply-To: <46888EEF-750B-46CF-BA77-1827DD6D3607@arbor.net> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> <46888EEF-750B-46CF-BA77-1827DD6D3607@arbor.net> From: Watson Ladd Date: Sat, 15 Jul 2017 12:24:14 -0700 Message-ID: To: "Dobbins, Roland" Cc: Matthew Green , "Ackermann, Michael" , IETF TLS Content-Type: multipart/alternative; boundary="94eb2c13e36e8ed9100554601c26" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 19:24:20 -0000 --94eb2c13e36e8ed9100554601c26 Content-Type: text/plain; charset="UTF-8" On Jul 15, 2017 11:03 AM, "Dobbins, Roland" wrote: On Jul 15, 2017, at 22:36, Ackermann, Michael wrote: That being the unencrypted stream is available to the endpoints Even where it is eventually available, they don't have the horsepower to capture & forward. It is always availible. How do you process when it isn't? As for forwarding that doubles bandwidth: no more. ----------------------------------- Roland Dobbins _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --94eb2c13e36e8ed9100554601c26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jul 15, 2017 11:03 AM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:


On Jul 15, 2017, at 22:36, Ackermann, Michael <MAckermann@bcbsm.com> wrote:

That being the unencrypted stream is available to the endpoints=C2=A0<= /div>

Even where it is eventually available, they don't have the h= orsepower to capture & forward.=C2=A0

It is always availib= le. How do you process when it isn't? As for forwarding that doubles ba= ndwidth: no more.


-----------------------------------
Roland Dobbins <rdobbins@arbor.net>



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


--94eb2c13e36e8ed9100554601c26-- From nobody Sat Jul 15 12:25:41 2017 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 74DA2126B7E for ; Sat, 15 Jul 2017 12:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OdyKCA5OwEjl for ; Sat, 15 Jul 2017 12:25:37 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 745B8124217 for ; Sat, 15 Jul 2017 12:25:37 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id q85so59633787pfq.1 for ; Sat, 15 Jul 2017 12:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tgX/ZNatIzHbLylLupk/bcXFZ0nl1Br4BchGriWWEl0=; b=quMH1TnZBD0ZfHwO8J5RpBSbYYMoRJ0vd3AyhyHQmY33RmtZmgukw8uqfJ94umElO6 PLVgqFYNZhjHLY+Wtm/oqWIT1EGBdPru8boIBWugd1KHLPltychFiaLk5XTBTpN3loa4 y7JIXwLhdpMfgedZpRKwC1iQhDPMXVQOq0HEvMliwEtkmLk0X7kM7dA+M9CWpmK0/oQa Fn7ZaP6bs2oZYQXV8iJ1kH484xG6G0WcVLnQcPpAcu+Wt3Bb6Mv7PLiRMZgokRSbfbV3 /N2ZXAGqfgbeqFLlh2tE2KAeR9a8g/3aRGSWAHUha2Sgy8EYkOFLHsP8H0Sr6dHPVlx+ +v4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tgX/ZNatIzHbLylLupk/bcXFZ0nl1Br4BchGriWWEl0=; b=IOwohi/+u4bZHRXi1K7Cr63oqgTZywpW5XAfIZz9oE8b1jy7f/vELreZCTq9k2XyF5 zfCLLwhmHD2Qb3CgXeuIPW7CliD8ayEggQp45yu6fxBwTAbgpCbbTrGHQ2JiIx7IjlYj aIiLLBJqEpS0/kb4uz88bmcH1YG6EmVmKb1JLCe5gGZ1MslT+JWpKbYbjXH9XOyC0Qyw 9/9uKf4xkFtqUC6vc99ESSquT6ToSkAjGb+jkMsiEoxsYIHJS7pov88AklJy85PppO9r O8NWSGQMdXMiZGcDfcsFKCrB2OosnaG4oX+e3opMEq7pnt3IsywUlWsNwq1tHa6p1l4w NL2w== X-Gm-Message-State: AIVw1124n/RtY3sDtkMtQqRlVxnNosMPWel2EEVuAmOyLE0YOXthMRRq 0yeQ3d1m7Fr0IpTN5TI06oaXN3r7kA== X-Received: by 10.84.229.79 with SMTP id d15mr22768912pln.4.1500146737098; Sat, 15 Jul 2017 12:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 12:25:36 -0700 (PDT) Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 12:25:36 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> <46888EEF-750B-46CF-BA77-1827DD6D3607@arbor.net> From: Watson Ladd Date: Sat, 15 Jul 2017 12:25:36 -0700 Message-ID: To: "Ackermann, Michael" Cc: Matthew Green , "Dobbins, Roland" , IETF TLS Content-Type: multipart/alternative; boundary="94eb2c19ecb460342e055460211b" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 19:25:39 -0000 --94eb2c19ecb460342e055460211b Content-Type: text/plain; charset="UTF-8" On Jul 15, 2017 11:16 AM, "Ackermann, Michael" wrote: YES! I tried to say in my message that collecting traces on thousands, or hundreds of thousands of hosts, is just not practical or possible. Not to mention the administrative domain barriers to this. We do it every day at my current employer. Guess we do the impossible. *From:* Dobbins, Roland [mailto:rdobbins@arbor.net] *Sent:* Saturday, July 15, 2017 2:03 PM *To:* Ackermann, Michael *Cc:* Ted Lemon ; IETF TLS ; Matthew Green < matthewdgreen@gmail.com> *Subject:* Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017, at 22:36, Ackermann, Michael wrote: That being the unencrypted stream is available to the endpoints Even where it is eventually available, they don't have the horsepower to capture & forward. ----------------------------------- Roland Dobbins The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --94eb2c19ecb460342e055460211b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jul 15, 2017 11:16 AM, "Ackermann, Michael" <MAckermann@bcbsm.com> wrote:

YES!

I tried to say in my message that collecting traces= on thousands,=C2=A0 or hundreds of thousands of hosts,=C2=A0 is just not p= ractical or possible.=C2=A0=C2=A0 Not to mention the administrative domain barriers to this.=C2=A0



We do it every day at my current employer. Guess we do the imposs= ible.

=C2=A0

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= =C2=A0

From: Dobbins, Roland [mailto:rdobbins@arbor.net]
Sent: Saturday, July 15, 2017 2:03 PM
To: Ackermann, Michael <MAckermann@bcbsm.com>
Cc: Ted Lemon <mellon@fugue.com>; IETF TLS <tls@ietf.org>; Matthew Green <matthewdgreen@gmail.com>=
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01=

=C2=A0

=C2=A0


On Jul 15, 2017, at 22:36, Ackermann, Michael <MAckermann@bcbsm.com> wrote:=

That being the unencrypted stream is available to th= e endpoints=C2=A0

=C2=A0

Even where it is eventually available, they don'= t have the horsepower to capture & forward.=C2=A0

=C2=A0

-----------------------------------
Roland Dobbins <= rdobbins@arbor.net>

=C2=A0

=C2=A0


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this commun= ication is directed. If you are not the intended recipient, you are hereby = notified that any viewing, copying, disclosure or distribution of this info= rmation is prohibited. Please notify the sender, by electronic mail or tele= phone, of any unintended receipt and delete the original message without ma= king any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan ar= e nonprofit corporations and independent licensees of the Blue Cross and Bl= ue Shield Association.

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


--94eb2c19ecb460342e055460211b-- From nobody Sat Jul 15 12:33:37 2017 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 415A3127B73 for ; Sat, 15 Jul 2017 12:33: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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55JEWRrWcQqr for ; Sat, 15 Jul 2017 12:33:34 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (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 E30EE126D46 for ; Sat, 15 Jul 2017 12:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500147211; l=3149; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=r94Upeg+DdwmxLC9CxqXZvjU/IN5FosA0znmjkHHBlY=; b=j67Ow1n/86CqTIwrtUO9+jwvUYwekVi+9aTVE27yXjTBnD8XcGt/JkSSAM707CmzLh ig44fXZK11t6D4qnhGZU9Bx2UhliqHMt9wkS5KLSnKSD4RdViMVi4u6tKEWzqhb0W8cq LWl2nlmpKA3C9Cs2Lqkj0Oa6wKkZ501pTgvDM= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JphITAP X-RZG-CLASS-ID: mo00 Received: from [10.10.10.91] (p5DCF5B04.dip0.t-ipconnect.de [93.207.91.4]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id 6091c1t6FJXVpxJ (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 15 Jul 2017 21:33:31 +0200 (CEST) To: tls@ietf.org References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> From: Roland Zink Message-ID: <860cd103-4e40-3f6f-1a3e-be9a6513c86c@zinks.de> Date: Sat, 15 Jul 2017 21:33:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 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] Fwd: draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 19:33:36 -0000 see inline Roland Am 15.07.2017 um 03:40 schrieb Watson Ladd: > On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins wrote: >> On 15 Jul 2017, at 1:01, Melinda Shore wrote: >> >>> It might make sense to kick it over to ops for a discussion with people whose meat and potatoes is monitoring, management, and >>> measurement. >> >> As someone who is ops-focused, I think this is an excellent suggestion! >> >> There have been several assertions posted to the list recently regarding various aspects of security and their intersection with encryption. It may be useful to take a moment and clarify a few of them. >> >> With regards to DDoS mitigation as it relates to encrypted attack traffic, only a subset of attacks in a subset of situations can actually be adequately mitigated without full visibility into (and often the ability to interact with) the traffic within the cryptostream. There are various ways to approach this issue, including full session termination and 'transparent' detection/classification, the latter of which isn't of course feasible in a PFS scenario. Each of these general approaches has its advantages and drawbacks. > > DDoS mitigation can be done at endpoints, and indeed has to be given > that other tools do not know which endpoints need to be rate-limited > or are expensive. A lot of distinct things are being crammed together > into DDoS, and the fact is endpoints can deal with application layer > attacks via rate-limits, CAPTCHAs, and other techniques, while > not-application layer attacks don't require visibility to defeat. What > can a middlebox do that an endpoint cannot? Globbing a bunch of > distinct things together is not helping the debate. One thing which can be done is identifying the sources and notifying the owner of the devices so they can be cleaned. > >> In many scenarios, one form or another of network-based visibility into encrypted traffic streams within the span of administrative control of a single organization is legitimate, vital and necessary. It is not 'wiretapping', any more than tools such as tcpdump or telemetry formats such as IPFIX and PSAMP can be categorized as 'wiretapping'. The fact is, the availability, confidentiality, and integrity of systems, applications, and networks that everyone on this list relies upon is highly dependent upon the ability of organizations to have visibility into encrypted traffic streams within their own networks, for purposes of security as well as testing and troubleshooting. >> >> >> How this can be accomplished is a matter for further discussion. But it's important that everyone focused on this topic understands that it is simply not possible to successfully defend against many forms of DDoS attacks nor to detect and classify hostile network traffic in the context of encrypted communications without visibility into the traffic in question, via some mechanism. The same goes for troubleshooting complex problems. > Which DDoS attacks specifically? And if the traffic isn't hitting > endpoints, does it matter? Yes, DDoS cause damage to dumb networks in between as well. From nobody Sat Jul 15 12:39:36 2017 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 1A2F812942F for ; Sat, 15 Jul 2017 12:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 ZL7rmHflyrpV for ; Sat, 15 Jul 2017 12:39:32 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 828B1126D46 for ; Sat, 15 Jul 2017 12:39:32 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 772441C18EF for ; Sat, 15 Jul 2017 14:39:31 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 755AF1C18B6; Sat, 15 Jul 2017 14:39:30 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3885DFE04E; Sat, 15 Jul 2017 15:39:30 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E604DFE048; Sat, 15 Jul 2017 15:39:29 -0400 (EDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (unknown [216.32.181.176]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Sat, 15 Jul 2017 15:39:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LBxbXI5Q10AT3Sf7pet97CIND4ZUkCTBKiasRODnQjQ=; b=Fkjke1w6wtF29tGirOQ4OJK2ndfh2b5XjnxZzPpvLcHbw5OnyBMcivjzmE97tSRF7NVvk/0Rn2t70LP5oWZenBTKyeFj/cG9wm4OsPWSbuIc5+JeauMP0sAhM097CiJOAT6EZK8Cmm372Ugj4XkJhBlKS+PtWjr93GpuiluEloI= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1367.namprd14.prod.outlook.com (10.172.158.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 19:39:27 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.023; Sat, 15 Jul 2017 19:39:27 +0000 From: "Ackermann, Michael" To: Watson Ladd CC: Matthew Green , "Dobbins, Roland" , IETF TLS Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIALriyAgAAVWACAAAFKgIAAAg+AgAADOACAAHw4YIAAKnSAgAADSxCAABPIAIAAAzvg Date: Sat, 15 Jul 2017 19:39:27 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> <46888EEF-750B-46CF-BA77-1827DD6D3607@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.39.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1367; 20:zAiHvhxMxfI6hx9TT2Ebe168MxQldy2PPK1ijbf2Lit1ji9dEarR6hq+BsBGywLFifWpJUMfIYoz8ZGyM6OR/j8IMYITJ1uBr3zI1no5Ok4jUmsnffQeqjoKeJ0bncxGTz4fHtHCQViv/5c7clNdjmi6jOoTE4oDsHOflA5e9Vk= x-ms-office365-filtering-correlation-id: c5a990a0-e7db-4609-14d4-08d4cbb93439 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1367; x-ms-traffictypediagnostic: CY4PR14MB1367: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(90097320859284)(148574349560750)(21748063052155)(86572411397741)(266576461109395); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1367; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1367; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39830400002)(39410400002)(39400400002)(377454003)(24454002)(85714005)(8936002)(99286003)(7736002)(2906002)(606006)(1411001)(93886004)(110136004)(6436002)(236005)(39060400002)(55016002)(6306002)(2900100001)(38730400002)(54896002)(9686003)(54906002)(2950100002)(6916009)(6246003)(229853002)(72206003)(80792005)(966005)(19609705001)(81166006)(8676002)(54356999)(76176999)(53546010)(478600001)(14454004)(50986999)(102836003)(790700001)(6116002)(3846002)(189998001)(86362001)(5660300001)(3660700001)(77096006)(3280700002)(33656002)(6506006)(4326008)(66066001)(230783001)(53936002)(25786009)(7696004)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1367; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368B4DD5D3B4EF22C8195D6D7A20CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 19:39:27.1001 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1367 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: d9761940-842f-4919-bff1-c0ca090c193b X-VPM-MSG-ID: 817851cb-55a4-4339-b948-392a4b5898f1 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 19:39:35 -0000 --_000_CY4PR14MB1368B4DD5D3B4EF22C8195D6D7A20CY4PR14MB1368namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGhvdyB5b3UgaW5pdGlhdGUgdGhlIHRyYWNlcyBh dCBhbGwgdGhlICBodW5kcmVkcyBvZiB0aG91c2FuZHMgb2Ygc2VydmVycyBhbmQgY2xpZW50 cyBhbmQgaG93IHlvdSBjb250cm9sIHRoZSBmbG93IG9mIHBjYXAgZmlsZXMgYmFjayB0byB3 aGVyZSB0aGV5IG5lZWQgdG8gYmUgcHJvY2Vzc2VkPyAgICAgSG93IGFyZSB1c2VycyBhbmQg YXBwcyBub3QgaW1wYWN0ZWQ/DQoNCg0KDQpGcm9tOiBXYXRzb24gTGFkZCBbbWFpbHRvOndh dHNvbmJsYWRkQGdtYWlsLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBKdWx5IDE1LCAyMDE3IDM6 MjYgUE0NClRvOiBBY2tlcm1hbm4sIE1pY2hhZWwgPE1BY2tlcm1hbm5AYmNic20uY29tPg0K Q2M6IE1hdHRoZXcgR3JlZW4gPG1hdHRoZXdkZ3JlZW5AZ21haWwuY29tPjsgRG9iYmlucywg Um9sYW5kIDxyZG9iYmluc0BhcmJvci5uZXQ+OyBJRVRGIFRMUyA8dGxzQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtUTFNdIGRyYWZ0LWdyZWVuLXRscy1zdGF0aWMtZGgtaW4tdGxzMTMt MDENCg0KDQoNCk9uIEp1bCAxNSwgMjAxNyAxMToxNiBBTSwgIkFja2VybWFubiwgTWljaGFl bCIgPE1BY2tlcm1hbm5AYmNic20uY29tPG1haWx0bzpNQWNrZXJtYW5uQGJjYnNtLmNvbT4+ IHdyb3RlOg0KWUVTIQ0KSSB0cmllZCB0byBzYXkgaW4gbXkgbWVzc2FnZSB0aGF0IGNvbGxl Y3RpbmcgdHJhY2VzIG9uIHRob3VzYW5kcywgIG9yIGh1bmRyZWRzIG9mIHRob3VzYW5kcyBv ZiBob3N0cywgIGlzIGp1c3Qgbm90IHByYWN0aWNhbCBvciBwb3NzaWJsZS4gICBOb3QgdG8g bWVudGlvbiB0aGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGJhcnJpZXJzIHRvIHRoaXMuDQoN Cg0KV2UgZG8gaXQgZXZlcnkgZGF5IGF0IG15IGN1cnJlbnQgZW1wbG95ZXIuIEd1ZXNzIHdl IGRvIHRoZSBpbXBvc3NpYmxlLg0KDQoNCg0KRnJvbTogRG9iYmlucywgUm9sYW5kIFttYWls dG86cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+XQ0KU2Vu dDogU2F0dXJkYXksIEp1bHkgMTUsIDIwMTcgMjowMyBQTQ0KVG86IEFja2VybWFubiwgTWlj aGFlbCA8TUFja2VybWFubkBiY2JzbS5jb208bWFpbHRvOk1BY2tlcm1hbm5AYmNic20uY29t Pj4NCkNjOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb208bWFpbHRvOm1lbGxvbkBmdWd1 ZS5jb20+PjsgSUVURiBUTFMgPHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPj47 IE1hdHRoZXcgR3JlZW4gPG1hdHRoZXdkZ3JlZW5AZ21haWwuY29tPG1haWx0bzptYXR0aGV3 ZGdyZWVuQGdtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogW1RMU10gZHJhZnQtZ3JlZW4tdGxz LXN0YXRpYy1kaC1pbi10bHMxMy0wMQ0KDQoNCg0KT24gSnVsIDE1LCAyMDE3LCBhdCAyMjoz NiwgQWNrZXJtYW5uLCBNaWNoYWVsIDxNQWNrZXJtYW5uQGJjYnNtLmNvbTxtYWlsdG86TUFj a2VybWFubkBiY2JzbS5jb20+PiB3cm90ZToNClRoYXQgYmVpbmcgdGhlIHVuZW5jcnlwdGVk IHN0cmVhbSBpcyBhdmFpbGFibGUgdG8gdGhlIGVuZHBvaW50cw0KDQpFdmVuIHdoZXJlIGl0 IGlzIGV2ZW50dWFsbHkgYXZhaWxhYmxlLCB0aGV5IGRvbid0IGhhdmUgdGhlIGhvcnNlcG93 ZXIgdG8gY2FwdHVyZSAmIGZvcndhcmQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpy ZG9iYmluc0BhcmJvci5uZXQ+Pg0KDQoNCg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hv bSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZp ZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5m b3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBl bGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0 IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNv cGllcy4NCg0KQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBD YXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5k IGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGll bGQgQXNzb2NpYXRpb24uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRM U0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz DQoNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24g aXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlz IGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9z dXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQu IFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVw aG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5h bCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUgQ3Jvc3MgQmx1 ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2Fu IGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMg b2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLgo= --_000_CY4PR14MB1368B4DD5D3B4EF22C8195D6D7A20CY4PR14MB1368namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBob3cgeW91IGluaXRpYXRl IHRoZSB0cmFjZXMgYXQgYWxsIHRoZSAmbmJzcDtodW5kcmVkcyBvZiB0aG91c2FuZHMgb2Yg c2VydmVycyBhbmQgY2xpZW50cyBhbmQgaG93IHlvdSBjb250cm9sIHRoZSBmbG93IG9mIHBj YXAgZmlsZXMgYmFjayB0byB3aGVyZSB0aGV5DQogbmVlZCB0byBiZSBwcm9jZXNzZWQ/Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhvdyBhcmUgdXNlcnMgYW5kIGFwcHMgbm90IGltcGFj dGVkPyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv YT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9z cGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gV2F0c29uIExhZGQgW21haWx0bzp3 YXRzb25ibGFkZEBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1 bHkgMTUsIDIwMTcgMzoyNiBQTTxicj4NCjxiPlRvOjwvYj4gQWNrZXJtYW5uLCBNaWNoYWVs ICZsdDtNQWNrZXJtYW5uQGJjYnNtLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hdHRoZXcg R3JlZW4gJmx0O21hdHRoZXdkZ3JlZW5AZ21haWwuY29tJmd0OzsgRG9iYmlucywgUm9sYW5k ICZsdDtyZG9iYmluc0BhcmJvci5uZXQmZ3Q7OyBJRVRGIFRMUyAmbHQ7dGxzQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gZHJhZnQtZ3JlZW4tdGxzLXN0 YXRpYy1kaC1pbi10bHMxMy0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBKdWwgMTUsIDIwMTcgMTE6MTYgQU0sICZxdW90O0Fja2VybWFubiwgTWlj aGFlbCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1BY2tlcm1hbm5AYmNic20uY29tIj5N QWNrZXJtYW5uQGJjYnNtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPllFUyE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0cmllZCB0byBz YXkgaW4gbXkgbWVzc2FnZSB0aGF0IGNvbGxlY3RpbmcgdHJhY2VzIG9uIHRob3VzYW5kcywm bmJzcDsgb3IgaHVuZHJlZHMgb2YgdGhvdXNhbmRzIG9mIGhvc3RzLCZuYnNwOyBpcyBqdXN0 IG5vdA0KIHByYWN0aWNhbCBvciBwb3NzaWJsZS4mbmJzcDsmbmJzcDsgTm90IHRvIG1lbnRp b24gdGhlIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBiYXJyaWVycyB0byB0aGlzLiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldlIGRvIGl0IGV2ZXJ5IGRheSBhdCBteSBjdXJyZW50IGVtcGxveWVyLiBHdWVz cyB3ZSBkbyB0aGUgaW1wb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxhIG5hbWU9Im1fLTY1NjY1MDIxNTI2Mzg5Njc5ODRfX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBEb2JiaW5zLCBSb2xhbmQgW21haWx0bzo8YSBocmVmPSJt YWlsdG86cmRvYmJpbnNAYXJib3IubmV0IiB0YXJnZXQ9Il9ibGFuayI+cmRvYmJpbnNAYXJi b3IubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVseSAxNSwgMjAx NyAyOjAzIFBNPGJyPg0KPGI+VG86PC9iPiBBY2tlcm1hbm4sIE1pY2hhZWwgJmx0OzxhIGhy ZWY9Im1haWx0bzpNQWNrZXJtYW5uQGJjYnNtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1BY2tl cm1hbm5AYmNic20uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFRlZCBMZW1vbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tZWxs b25AZnVndWUuY29tPC9hPiZndDs7IElFVEYgVExTICZsdDs8YSBocmVmPSJtYWlsdG86dGxz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzQGlldGYub3JnPC9hPiZndDs7IE1hdHRo ZXcgR3JlZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYXR0aGV3ZGdyZWVuQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1hdHRoZXdkZ3JlZW5AZ21haWwuY29tPC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIGRyYWZ0LWdyZWVuLXRscy1zdGF0aWMtZGgtaW4t dGxzMTMtMDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDE1LCAyMDE3 LCBhdCAyMjozNiwgQWNrZXJtYW5uLCBNaWNoYWVsICZsdDs8YSBocmVmPSJtYWlsdG86TUFj a2VybWFubkBiY2JzbS5jb20iIHRhcmdldD0iX2JsYW5rIj5NQWNrZXJtYW5uQGJjYnNtLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBiZWluZyB0aGUgdW5lbmNy eXB0ZWQgc3RyZWFtIGlzIGF2YWlsYWJsZSB0byB0aGUgZW5kcG9pbnRzJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5FdmVuIHdoZXJlIGl0IGlzIGV2ZW50dWFsbHkgYXZhaWxhYmxlLCB0aGV5IGRv bid0IGhhdmUgdGhlIGhvcnNlcG93ZXIgdG8gY2FwdHVyZSAmYW1wOyBmb3J3YXJkLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpSb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5l dCIgdGFyZ2V0PSJfYmxhbmsiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+VGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZp ZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLA0KIGRpc2Nsb3N1cmUgb3IgZGlzdHJp YnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkg dW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0 aG91dCBtYWtpbmcgYW55IGNvcGllcy48bzpwPjwvbzpwPjwvcD4NCjxwPkJsdWUgQ3Jvc3Mg Qmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hp Z2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNl ZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExT QGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCgoKPEJSPgo8aHRtbD4KIDxwPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGhpZ2hseSBjb25maWRlbnRpYWwgYW5kIGlzIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSB0byB3aG9t IHRoaXMgY29tbXVuaWNhdGlvbiBpcyBkaXJlY3RlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdmll d2luZywgY29weWluZywgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBpbmZv cm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIsIGJ5IGVs ZWN0cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFueSB1bmludGVuZGVkIHJlY2VpcHQg YW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRob3V0IG1ha2luZyBhbnkgY29w aWVzLjwvcD4KIDxwPkJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJs dWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25z IGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUg U2hpZWxkIEFzc29jaWF0aW9uLjwvcD4KICA8L2h0bWw+Cgo= --_000_CY4PR14MB1368B4DD5D3B4EF22C8195D6D7A20CY4PR14MB1368namp_-- From nobody Sat Jul 15 12:43:21 2017 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 57112128B8F for ; Sat, 15 Jul 2017 12:43: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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6C9mFXZLV2Ug for ; Sat, 15 Jul 2017 12:43:17 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (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 A097E127B73 for ; Sat, 15 Jul 2017 12:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500147795; l=629; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=kdkWdzXlF62eI39PVY14RjrTOy0MIPyUwi4eUsq3cL4=; b=bkogzL/plHXJsiD4X9dPKmZd9rJRWnwm+njKJH9JlJ+w1lFQrrpPF2PuwGXA/RdD++ HP1DD0NHie51Iz/Y/XqQfmTWRH2ckcSmv842q5r2CWYh81tUcsae+Y4mCHykUWsIH9B8 cIjlOteJfovRVO6j7kNdkj/Bvcs62/FmIv2xQ= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JphITAP X-RZG-CLASS-ID: mo00 Received: from [10.10.10.91] (p5DCF5B04.dip0.t-ipconnect.de [93.207.91.4]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id i04634t6FJhFoSn (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 15 Jul 2017 21:43:15 +0200 (CEST) To: tls@ietf.org References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> From: Roland Zink Message-ID: <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> Date: Sat, 15 Jul 2017 21:43:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 19:43:19 -0000 A cache may be hired by a user, origin or even a network operator to act as a "front" to the origin. Is it not a middlebox because of this? It is a question of definition if a CDN is in the middle or the endpoint :) Roland Am 15.07.2017 um 21:12 schrieb Salz, Rich: >> On the public internet, it's increasingly common for traffic to be MITMd in the form of a CDN. > A CDN is not a middlebox, it is not a MITM. It is a site that the origin has hired to act as a "front" to it. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jul 15 12:49:42 2017 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 A3634128990 for ; Sat, 15 Jul 2017 12:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1mBRs4ye4Fm for ; Sat, 15 Jul 2017 12:49:39 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (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 61B7E1270A7 for ; Sat, 15 Jul 2017 12:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500148177; l=7542; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=tQvieZUgycHuq4b72SA4OC5z+FjEF6D24L+0ZdYbd/Y=; b=kBuYe4000P1rIbIzm6CAyB+zzl0ZKOTa4s3v4sle+BzXWRjjxm0RsPB8kP5fcRzyY1 rThNDMHRngF3nFXxIEEUr3C2Db7PZ9h2bpRVz2KFtJYUyy2ScP82H4e6fgeH2TuemH1u o3r6vdCdMqBY31zWvthnFMlIDAuOtLjMKNKjQ= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JphITAP X-RZG-CLASS-ID: mo00 Received: from [10.10.10.91] (p5DCF5B04.dip0.t-ipconnect.de [93.207.91.4]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id K02271t6FJnbqQ1 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 15 Jul 2017 21:49:37 +0200 (CEST) To: tls@ietf.org References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> From: Roland Zink Message-ID: Date: Sat, 15 Jul 2017 21:49:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5912835029BAEA893F7A1607" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 19:49:42 -0000 This is a multi-part message in MIME format. --------------5912835029BAEA893F7A1607 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit TLS is a two endpoint protocol. It looks like many of the use cases describe problems with more than two endpoints but are using TLS because it is commonly available. So should TLS be extended to be an n-party protocol (or is this always considered wiretapping?) or should be there another protocol or something else? Regards, Roland Am 15.07.2017 um 19:34 schrieb Colm MacCárthaigh: > > > On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor > > wrote: > > * This proposed TLS variant is *never* acceptable for use on the > public > Internet. At most it's acceptable only between two endpoints > within > a datacenter under a single zone of administrative control. > > > * Forward secrecy is in general a valuable property for encrypted > communications in transit. > > > If there's anyone on the list who disagrees with the above two > statements, please speak up! > > > I agree with the second statement, but I don't really follow the logic > of the first. On the public internet, it's increasingly common for > traffic to be MITMd in the form of a CDN. Many commenters here have > also responded "Just use proxies". I don't get how that's better. > > A proxy sees all of the plaintext, not just selected amounts. All of > the same coercion and compromise risks apply to a proxy too, but since > it undetectably sees everything, that would seem objectively worse > from a security/privacy risk POV. > Or put another way: if these organizations need to occasionally > inspect plaintext, would I prefer that it's the kind of system where > they have to go pull a key from a store, and decrypt specific > ciphertexts on demand offline, or do I want them recording plaintext > *all* of the time inline? It seems utterly bizarre that we would > collectively favor the latter. We end up recommending the kinds of > systems that are an attacker's dream. > > Here's what I'd prefer: > > * Don't allow static DH. In fact, forbid it, and recommend that > clients check for changing DH params. > * For the pcap-folks, define an extension that exports the session > key or PMS, encrypted under another key. Make this part of the > post-handshake transcript. > * pcap-folks can do what they want, but clients will know and can > issue security warnings if they desire. Forbiding static DH enforces > this mechanism, and we can collectively land in a better place than we > are today. > > -- > Colm > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------5912835029BAEA893F7A1607 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

TLS is a two endpoint protocol. It looks like many of the use cases describe problems with more than two endpoints but are using TLS because it is commonly available. So should TLS be extended to be an n-party protocol (or is this always considered wiretapping?) or should be there another protocol or something else?


Regards,

Roland



Am 15.07.2017 um 19:34 schrieb Colm MacCárthaigh:


On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
 * This proposed TLS variant is *never* acceptable for use on the public
   Internet.  At most it's acceptable only between two endpoints within
   a datacenter under a single zone of administrative control.

 * Forward secrecy is in general a valuable property for encrypted
   communications in transit.

If there's anyone on the list who disagrees with the above two
statements, please speak up!

I agree with the second statement, but I don't really follow the logic of the first. On the public internet, it's increasingly common for traffic to be MITMd in the form of a CDN. Many commenters here have also responded "Just use proxies". I don't get how that's better. 

A proxy sees all of the plaintext, not just selected amounts. All of the same coercion and compromise risks apply to a proxy too, but since it undetectably sees everything,  that would seem objectively worse from a security/privacy risk POV. 
 
Or put another way: if these organizations need to occasionally inspect plaintext, would I prefer that it's the kind of system where they have to go pull a key from a store, and decrypt specific ciphertexts on demand offline, or do I want them recording plaintext *all* of the time inline? It seems utterly bizarre that we would collectively favor the latter. We end up recommending the kinds of systems that are an attacker's dream. 

Here's what I'd prefer:

 * Don't allow static DH. In fact, forbid it, and recommend that clients check for changing DH params. 
 * For the pcap-folks, define an extension that exports the session key or PMS, encrypted under another key. Make this part of the post-handshake transcript. 
 * pcap-folks can do what they want, but clients will know and can issue security warnings if they desire. Forbiding static DH enforces this mechanism, and we can collectively land in a better place than we are today. 
 

--
Colm


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

--------------5912835029BAEA893F7A1607-- From nobody Sat Jul 15 13:23:29 2017 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 F358B129B47 for ; Sat, 15 Jul 2017 13:23:26 -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 (2048-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 E22hgzFFlqFu for ; Sat, 15 Jul 2017 13:23:25 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 D47D4126BFD for ; Sat, 15 Jul 2017 13:23:25 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6FKLMwj028569; Sat, 15 Jul 2017 21:23:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=8dd28r3su1a3efZeq14nKy8DMVTrOGPQONznoh4drfQ=; b=a5MGMYa3CGwsGbxhNzQoIFloyoY269NiYoGvplNFRUBgc6U7r1CpNYMjucMPVV87kuKu bZxtnd0ZRTye5sKXirLn6U38yBtIB9u3g81Wcr3ToJ85AW9l/SewVHuQUEk46kEGGZbK oZNQvtLunFso/Q3y/nxaQSDmU2Vc5wDiCjwpbHcMEuw7W5LHy6YyqLKBDKmqs36fpbsw ScTFFIQcwmyVbfGf4Wdaz3VMDA3IfMl3cflWdWKSOQs3Iu8DZvJEHuIUCjmy+SM/GV0g fEMw47XXPivicVq/isU+urxayr4RCa9CyxcUo33RSHFPmY1gsneUU1tnDWqvD70pLsjj ew== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bqak4jckn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 21:23:23 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6FKLD0Y021835; Sat, 15 Jul 2017 16:23:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecu0yfs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 16:23:22 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 15 Jul 2017 16:23:21 -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.1263.000; Sat, 15 Jul 2017 16:23:21 -0400 From: "Salz, Rich" To: Roland Zink , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAATAIA///H2zA= Date: Sat, 15 Jul 2017 20:23:21 +0000 Message-ID: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> In-Reply-To: <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> 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.152.222] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707150342 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707150342 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 20:23:27 -0000 > A cache may be hired by a user, origin or even a network operator to act = as a > "front" to the origin. Is it not a middlebox because of this? It is a que= stion of > definition if a CDN is in the middle or the endpoint :) Yes. And I am saying that the definition doesn't include a CDN as a middle= point. Do user-provided reverse proxies have official TLS certificates with a SAN = field claiming to be the origin? From nobody Sat Jul 15 13:39:24 2017 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 EA19512EA95 for ; Sat, 15 Jul 2017 13:39:22 -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=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEN-MWpn0lBa for ; Sat, 15 Jul 2017 13:39:21 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (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 49565129B06 for ; Sat, 15 Jul 2017 13:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500151159; l=684; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=YXipul+7OU3IFVU5E9BUauxdrnsm2cYvMho1EwoCyuM=; b=BBeJd2X4NvNXclLhv9BljYUDi8BUMEgQ+Isep9lY9bCN2JDZcPAuexaQAUO9oNhLot Qb2BH0EjrDXqg574UOMEUIAHb2G8v7Qi2PSUUivg0D35VgJzup8Bg+lvZvJj/RVOLKrk r5z6ic8RAqxlkZk46DWr2G0btsbCRUq9QEvrk= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JphITAP X-RZG-CLASS-ID: mo00 Received: from [10.10.10.91] (p5DCF5B04.dip0.t-ipconnect.de [93.207.91.4]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id 60273et6FKdGr94 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 15 Jul 2017 22:39:16 +0200 (CEST) To: "Salz, Rich" , "tls@ietf.org" References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> From: Roland Zink Message-ID: <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> Date: Sat, 15 Jul 2017 22:39:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 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] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 20:39:23 -0000 I think reverse proxies are middleboxes regardless if they have official origin TLS certificates. From the TLS viewpoint they may be the endpoint although from the HTTP viewpoint they are not. Roland Am 15.07.2017 um 22:23 schrieb Salz, Rich: >> A cache may be hired by a user, origin or even a network operator to act as a >> "front" to the origin. Is it not a middlebox because of this? It is a question of >> definition if a CDN is in the middle or the endpoint :) > Yes. And I am saying that the definition doesn't include a CDN as a middlepoint. > > Do user-provided reverse proxies have official TLS certificates with a SAN field claiming to be the origin? From nobody Sat Jul 15 13:47:15 2017 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 52D5012EAA5 for ; Sat, 15 Jul 2017 13:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 77ou94Vy4ykQ for ; Sat, 15 Jul 2017 13:47:12 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2655D1274D2 for ; Sat, 15 Jul 2017 13:47:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id B7C21654C2; Sat, 15 Jul 2017 23:47:10 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id Nwqi7NPoTqgr; Sat, 15 Jul 2017 23:47:10 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 63E7D21C; Sat, 15 Jul 2017 23:47:07 +0300 (EEST) Date: Sat, 15 Jul 2017 23:47:07 +0300 From: Ilari Liusvaara To: Roland Zink Cc: "Salz, Rich" , "tls@ietf.org" Message-ID: <20170715204707.qum4gjcatqbw6tct@LK-Perkele-VII> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 20:47:14 -0000 On Sat, Jul 15, 2017 at 10:39:16PM +0200, Roland Zink wrote: > I think reverse proxies are middleboxes regardless if they have official > origin TLS certificates. From the TLS viewpoint they may be the endpoint > although from the HTTP viewpoint they are not. CDNs go much farther than most reverse proxies, and seem more like full-fledged origins than intermediates. For example, partially processing POST requests. -Ilari From nobody Sat Jul 15 13:47:56 2017 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 100E912EC23 for ; Sat, 15 Jul 2017 13:47:55 -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 (2048-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 NjT1DGw6sjzG for ; Sat, 15 Jul 2017 13:47:54 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 20F36126BF3 for ; Sat, 15 Jul 2017 13:47:54 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6FKlIpm013543; Sat, 15 Jul 2017 21:47:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+Kc0Yz/sPOxwfN+3V508bDpFIJzCdKIyp9GxQS2V7QY=; b=oGcNVtGtlUG6SD1h+S/GlCM1jg1gNyFE3CiYICw06Se+2eIOeTaSRglTDe+7AV07ThZd 1iNRNYpKEd7ZzTn3Ul8bbAHyjfkgCTwzMy2uRwtLVvBtOUumQhPfHM+BFYllqZuPvu9a sPqB1w309ECYEVyJFhV0jbc2atmabRCQLwdkcNE8KG6zFNn/hJInl1s+PSEXY3XOCDNd V7BzOh6bFac/N7Z3fmjE5m8VuKQ5Y5Mw8fPfSN3cP+nuL7n59Xy6ZYhSFb0EWl+/IliP ts7H1hQJlqYM2o9hh6QQWruv+3I8X2HZKWrLli8oB7ot2YredK8noLd5ZEvDXjSJO0BP og== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bqak4je7y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 21:47:52 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6FKjrJT003460; Sat, 15 Jul 2017 16:47:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecu10dk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 16:47:50 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 15 Jul 2017 16:47:49 -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.1263.000; Sat, 15 Jul 2017 16:47:49 -0400 From: "Salz, Rich" To: Roland Zink , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAATAIA///H2zCAAEfKAP//vwrw Date: Sat, 15 Jul 2017 20:47:48 +0000 Message-ID: <378188bd982947e1b14f8234cf1bc6b4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> In-Reply-To: <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> 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.152.222] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707150349 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707150349 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 20:47:55 -0000 > I think reverse proxies are middleboxes regardless if they have official = origin > TLS certificates. From the TLS viewpoint they may be the endpoint althoug= h > from the HTTP viewpoint they are not. This is wrong. >From the HTTP viewpoint -- of the origin! -- they are not middleboxes., no= t intermediaries. It is no different from a load balancer sending you to a different data cen= ter. From nobody Sat Jul 15 14:04:08 2017 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 D729112F4EA for ; Sat, 15 Jul 2017 14:04: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, 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=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmCxB7ukzTiq for ; Sat, 15 Jul 2017 14:04:02 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (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 BA70712FEE2 for ; Sat, 15 Jul 2017 14:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500152639; l=1071; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=qV1H1fRm4jcjN7T0WWhWFv7dOfGdljrVxhxwwxlqhWw=; b=Se/0XfM671SoSJ9i3wHOTi39/gc0D8uwsi+XmS2QBS5Mu7nhdl7nO1lBruHxoRdyAP PwDIDI1CrCYKUiQqwqMwPZIqR+bgNeG+sy+Ysm8oWO5Ihe0rXxToTjCuoHLElLSEBG5k bjfEVCiPjsciFTdnpVXSuULnXsiSyxkqZVJuU= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JphITAP X-RZG-CLASS-ID: mo00 Received: from [10.10.10.91] (p5DCF5B04.dip0.t-ipconnect.de [93.207.91.4]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id 30a9e8t6FL3ut8F (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 15 Jul 2017 23:03:56 +0200 (CEST) To: "Salz, Rich" , "tls@ietf.org" References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> <378188bd982947e1b14f8234cf1bc6b4@usma1ex-dag1mb1.msg.corp.akamai.com> From: Roland Zink Message-ID: <2fafd0d8-fbdd-efe2-60ae-2646bc10c355@zinks.de> Date: Sat, 15 Jul 2017 23:03:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <378188bd982947e1b14f8234cf1bc6b4@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 21:04:07 -0000 RFC 3234 "Middleboxes: Taxonomy and Issues" says: 1.1. Terminology The phrase "middlebox" was coined by Lixia Zhang as a graphic description of a recent phenomenon in the Internet. A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host. Even a load balancer may considered "middlebox", see section 2.8 of RFC 3234. Anyway it just depends on what you call middlebox and doesn't matter much regarding draft-green-tls-static-dh-in-tls13-01. Roland Am 15.07.2017 um 22:47 schrieb Salz, Rich: >> I think reverse proxies are middleboxes regardless if they have official origin >> TLS certificates. From the TLS viewpoint they may be the endpoint although >> from the HTTP viewpoint they are not. > This is wrong. > > From the HTTP viewpoint -- of the origin! -- they are not middleboxes., not intermediaries. > > It is no different from a load balancer sending you to a different data center. From nobody Sat Jul 15 14:14:28 2017 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 9208E131448 for ; Sat, 15 Jul 2017 14:14:26 -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=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 LT-bj5D5zgAE for ; Sat, 15 Jul 2017 14:14:25 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 F2F30130134 for ; Sat, 15 Jul 2017 14:14:24 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6FLCWXW007853; Sat, 15 Jul 2017 22:14:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=YKzXVR750Sqz3hdkfuz3TQl80LxpvJi2Np32NzV1MiA=; b=fNQPFk4PKRYOPGOslRfLAbN/7lrCwF4cCaq7sGFOpGCgCJnmHzNTNv/xljwg/LP+dUnE W13CgJGBqGHfsFoh/8Qp49h42OcniQYIYWloivdYbth0va9fGT83wMSo+Ruro40Ym1/M S3l1qqNC+hWpIAExHODWBAD1+ZncH2J8wnQOkBBxEnkRKrm6MQAmdOwzGIryzaeUOfuW im7q7jEA/4OllIRi/sgxFByL1nAQ+DNCv7CG1coPOv9RnYuX81YUWDs5Y2sG08iD9qis zfbBfPLJFkgkvUK3ndhNGEVZQLja3nmX0hF5AN90uEEhGkdM43LbQ5EgEVOIkGvJ3cb8 0g== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2bq84d2qxp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 22:14:22 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6FLAhhp002586; Sat, 15 Jul 2017 17:14:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bqecv9ctv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 15 Jul 2017 17:14:22 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 15 Jul 2017 17:14:21 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 15 Jul 2017 17:14:20 -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.1263.000; Sat, 15 Jul 2017 17:14:19 -0400 From: "Salz, Rich" To: Roland Zink , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAATAIA///H2zCAAEfKAP//vwrwAAj7iIAACAwB0A== Date: Sat, 15 Jul 2017 21:14:18 +0000 Message-ID: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> <378188bd982947e1b14f8234cf1bc6b4@usma1ex-dag1mb1.msg.corp.akamai.com> <2fafd0d8-fbdd-efe2-60ae-2646bc10c355@zinks.de> In-Reply-To: <2fafd0d8-fbdd-efe2-60ae-2646bc10c355@zinks.de> 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.152.222] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707150357 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-15_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707150357 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 21:14:26 -0000 The terminology in RFC 3234 has evolved; language has a way of doing that. > Anyway it just depends on what you call middlebox and doesn't matter > much regarding draft-green-tls-static-dh-in-tls13-01. I believe it does. Words matter. From nobody Sat Jul 15 14:16:07 2017 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 BFCAC13144E for ; Sat, 15 Jul 2017 14:16: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, 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=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EktDIWGkrpb0 for ; Sat, 15 Jul 2017 14:16:04 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (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 72BF6131467 for ; Sat, 15 Jul 2017 14:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500153361; l=349; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=9d2xHKGb/JTQ2r/smD3dZbmEPIuBOAIQWvsZBvYx0jA=; b=Z5fA1Y8UbakB4slAYAHVoHI2Fnnb4a/CE+uys0h8dA0Kvl7vDRl79V1JP9ZMoxWPLp NhDIUbjyp9yZYf4/1zxhfAhgkQme5sK+8L77O07FSiifA75H5D3/kZyz2beWN6X3/PP0 R1qyhaoKwVjK5/kIVjDFvn9FVOUXUMsqOgGR0= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JphITAP X-RZG-CLASS-ID: mo00 Received: from [10.10.10.91] (p5DCF5B04.dip0.t-ipconnect.de [93.207.91.4]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id 901cf4t6FLFwngV (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 15 Jul 2017 23:15:58 +0200 (CEST) To: "Salz, Rich" , "tls@ietf.org" References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> <378188bd982947e1b14f8234cf1bc6b4@usma1ex-dag1mb1.msg.corp.akamai.com> <2fafd0d8-fbdd-efe2-60ae-2646bc10c355@zinks.de> From: Roland Zink Message-ID: <6433d186-9a6f-0c58-ee96-556d11aac958@zinks.de> Date: Sat, 15 Jul 2017 23:15:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 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] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 21:16:06 -0000 Am 15.07.2017 um 23:14 schrieb Salz, Rich: > The terminology in RFC 3234 has evolved; language has a way of doing that. > >> Anyway it just depends on what you call middlebox and doesn't matter >> much regarding draft-green-tls-static-dh-in-tls13-01. > I believe it does. Words matter. So what is the definition of "middlebox"? Roland From nobody Sat Jul 15 15:07:54 2017 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 BD85D12EA74 for ; Sat, 15 Jul 2017 15:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xvxz1R7wndW1 for ; Sat, 15 Jul 2017 15:07:49 -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 4388D129B19 for ; Sat, 15 Jul 2017 15:07:49 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id e7so60436736pfk.0 for ; Sat, 15 Jul 2017 15:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SJg+/PKEkgTKbwTDrktXYgp3BF3In2f9BDi33VQ+TdI=; b=bGJao5SUG1jcPP8akp3tosZmR/VIWj2pM0a72imeuZEQtDD05u9QDjkxTwxhnzJQX6 1mo/WJoxO/J1clQ/m49UMnlS72xul3M9+EnuUW5Viv0hB3NJk7n80Wv7cIaFS5WERmXh QZJgAgmac+NkdnDKeDFoIgCiavTYb72ZEpmLoqNEEiwOvx/Gyh54tBDCDNZp+zeD8MAK IM/9HvDlir1iNJMgkjHzsGKiEIMtSfGhctRCX7CpDgu2DoC0nsLemswmXX31LWSjQG2A uaIzv8XY7AWBKVBKsMY5YrBy7QwUr/XAMt9R/IiEEelG2+HKDzQTUczv4gl6XVGB02OR ylGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SJg+/PKEkgTKbwTDrktXYgp3BF3In2f9BDi33VQ+TdI=; b=jfcPf+IBBNIlg81ShYqRxDxF7z7u7vEuNqut7S6SE4dhQHi7P6ic9fchwwsDxvhWR3 Zba+YS+e11LAW2IB77sEPL/Ce1bvqfLyfbIskMdfJAdjisMuWVZXOTaUnBcUo9PdJoYE iKnSOskN8ihD3YHPeqr3BEKqIrhh33jsVvT1I4FH2c+t/eXcnqdD0EjYhHoNyXSrRVAH yQeq6WfYRnyMg5I33cKhzH8Hetj0mcXpS9Y3dLBhXurHOamonzo5pgW3/Nh09wBHR2Vd ygWUQwInwUsSBjU/xMfK3fb24QLQOpGDk3skS9Sz8tvUA0RIVpOe9vnOp9iL8OlTPb4y H8yg== X-Gm-Message-State: AIVw111K1FGNoGH+lnqGoL7BbNZk1THPLvuNHf5YAbI7wZ9LwJf2i8x6 VDBHfVFtx+KWxkwQl/KMe3xDBhOpp5dX X-Received: by 10.84.229.79 with SMTP id d15mr23242648pln.4.1500156468819; Sat, 15 Jul 2017 15:07:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 15:07:48 -0700 (PDT) Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 15:07:48 -0700 (PDT) In-Reply-To: <860cd103-4e40-3f6f-1a3e-be9a6513c86c@zinks.de> References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <860cd103-4e40-3f6f-1a3e-be9a6513c86c@zinks.de> From: Watson Ladd Date: Sat, 15 Jul 2017 15:07:48 -0700 Message-ID: To: Roland Zink Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19ecb46e7ca10554626598" Archived-At: Subject: Re: [TLS] Fwd: draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 22:07:52 -0000 --94eb2c19ecb46e7ca10554626598 Content-Type: text/plain; charset="UTF-8" On Jul 15, 2017 12:33 PM, "Roland Zink" wrote: see inline Roland Am 15.07.2017 um 03:40 schrieb Watson Ladd: > On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins > wrote: > >> On 15 Jul 2017, at 1:01, Melinda Shore wrote: >> >> It might make sense to kick it over to ops for a discussion with people >>> whose meat and potatoes is monitoring, management, and >>> measurement. >>> >> >> As someone who is ops-focused, I think this is an excellent suggestion! >> >> There have been several assertions posted to the list recently regarding >> various aspects of security and their intersection with encryption. It may >> be useful to take a moment and clarify a few of them. >> >> With regards to DDoS mitigation as it relates to encrypted attack >> traffic, only a subset of attacks in a subset of situations can actually be >> adequately mitigated without full visibility into (and often the ability to >> interact with) the traffic within the cryptostream. There are various ways >> to approach this issue, including full session termination and >> 'transparent' detection/classification, the latter of which isn't of course >> feasible in a PFS scenario. Each of these general approaches has its >> advantages and drawbacks. >> > > DDoS mitigation can be done at endpoints, and indeed has to be given > that other tools do not know which endpoints need to be rate-limited > or are expensive. A lot of distinct things are being crammed together > into DDoS, and the fact is endpoints can deal with application layer > attacks via rate-limits, CAPTCHAs, and other techniques, while > not-application layer attacks don't require visibility to defeat. What > can a middlebox do that an endpoint cannot? Globbing a bunch of > distinct things together is not helping the debate. > One thing which can be done is identifying the sources and notifying the owner of the devices so they can be cleaned. How does an endpoint not know the source? > In many scenarios, one form or another of network-based visibility into >> encrypted traffic streams within the span of administrative control of a >> single organization is legitimate, vital and necessary. It is not >> 'wiretapping', any more than tools such as tcpdump or telemetry formats >> such as IPFIX and PSAMP can be categorized as 'wiretapping'. The fact is, >> the availability, confidentiality, and integrity of systems, applications, >> and networks that everyone on this list relies upon is highly dependent >> upon the ability of organizations to have visibility into encrypted traffic >> streams within their own networks, for purposes of security as well as >> testing and troubleshooting. >> >> >> How this can be accomplished is a matter for further discussion. But >> it's important that everyone focused on this topic understands that it is >> simply not possible to successfully defend against many forms of DDoS >> attacks nor to detect and classify hostile network traffic in the context >> of encrypted communications without visibility into the traffic in >> question, via some mechanism. The same goes for troubleshooting complex >> problems. >> > Which DDoS attacks specifically? And if the traffic isn't hitting > endpoints, does it matter? > Yes, DDoS cause damage to dumb networks in between as well. I'm not talking DDoS. I'm talking attack traffic. You need to talk about specifics you cannot solve other ways. DDOS isn't specific enough. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --94eb2c19ecb46e7ca10554626598 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jul 15, 2017 12:33 PM, "Roland Zink" <roland@zinks.de> wrote:
see inline

Roland


Am 15.07.2017 um 03:40 schrieb Watson Ladd:
On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 15 Jul 2017, at 1:01, Melinda Shore wrote:

It might make sense to kick it over to ops for a discussion with people who= se meat and potatoes is monitoring, management, and
measurement.

As someone who is ops-focused, I think this is an excellent suggestion!

There have been several assertions posted to the list recently regarding va= rious aspects of security and their intersection with encryption.=C2=A0 It = may be useful to take a moment and clarify a few of them.

With regards to DDoS mitigation as it relates to encrypted attack traffic, = only a subset of attacks in a subset of situations can actually be adequate= ly mitigated without full visibility into (and often the ability to interac= t with) the traffic within the cryptostream.=C2=A0 There are various ways t= o approach this issue, including full session termination and 'transpar= ent' detection/classification, the latter of which isn't of course = feasible in a PFS scenario.=C2=A0 Each of these general approaches has its = advantages and drawbacks.

DDoS mitigation can be done at endpoints, and indeed has to be given
that other tools do not know which endpoints need to be rate-limited
or are expensive.=C2=A0 A lot of distinct things are being crammed together=
into DDoS, and the fact is endpoints can deal with application layer
attacks via rate-limits, CAPTCHAs, and other techniques, while
not-application layer attacks don't require visibility to defeat. What<= br> can a middlebox do that an endpoint cannot? Globbing a bunch of
distinct things together is not helping the debate.
One thing which can be done is identifying the sources and notifying the ow= ner of the devices so they can be cleaned.

How does an endpoint not kn= ow the source?


In many scenarios, one form or another of network-based visibility into enc= rypted traffic streams within the span of administrative control of a singl= e organization is legitimate, vital and necessary.=C2=A0 It is not 'wir= etapping', any more than tools such as tcpdump or telemetry formats suc= h as IPFIX and PSAMP can be categorized as 'wiretapping'.=C2=A0 The= fact is, the availability, confidentiality, and integrity of systems, appl= ications, and networks that everyone on this list relies upon is highly dep= endent upon the ability of organizations to have visibility into encrypted = traffic streams within their own networks, for purposes of security as well= as testing and troubleshooting.


How this can be accomplished is a matter for further discussion.=C2=A0 But = it's important that everyone focused on this topic understands that it = is simply not possible to successfully defend against many forms of DDoS at= tacks nor to detect and classify hostile network traffic in the context of = encrypted communications without visibility into the traffic in question, v= ia some mechanism.=C2=A0 The same goes for troubleshooting complex problems= .
Which DDoS attacks specifically? And if the traffic isn't hitting
endpoints, does it matter?
Yes, DDoS cause damage to dumb networks in between as well.

I'm not ta= lking DDoS. I'm talking attack traffic. You need to talk about specific= s you cannot solve other ways. DDOS isn't specific enough.


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

--94eb2c19ecb46e7ca10554626598-- From nobody Sat Jul 15 15:55:28 2017 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 980A1129B5B for ; Sat, 15 Jul 2017 15:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 LIoaQBQ8qyrK for ; Sat, 15 Jul 2017 15:55:25 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 DEB54129B34 for ; Sat, 15 Jul 2017 15:55:24 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id j80so27701830ybg.2 for ; Sat, 15 Jul 2017 15:55:24 -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=7JCVyxjMZgrZBCcVurR0sJkzyyTz3hZik8GpOgI7bbQ=; b=OnwkyJwjLDT3w+rVb2osu4wNDmHRaa3U8mPUe473Pzq05LjuBOK5BpRMh8YkW63cWm GzfLMj404O8zNOeOxjNguu41KcuF161O3CtOUjPTllR9lLzmOij4cL7LuQwl5KDzYmvZ YDLnGm3HLuPkU8I42O5M4Mf272BW0Q56f61VZ6kl7uaiEiwLnEIIzNqayw5155E8T+Bw 7ALcwo2RJzVpKY8gKqlVm9N9madBqp1QUsvXemsEXKUW2onmD15mxZF+wSBib2FGZFg8 ZFvJOJAStKPyV5BK9xox16UgYjuSM/CTlLOXuZaGxlQ9/zp1sjFLNXFVQCnUHgwxivUC MWPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7JCVyxjMZgrZBCcVurR0sJkzyyTz3hZik8GpOgI7bbQ=; b=hMumoYdrKTHvRX/jZVDWEih0W2VB1T45YVWdPwtlXhXYyUQJva08FA/Qam8FIbHYQt F4ADOEVFkTVEu3YW+kUyVOnqZGGraICcufAGUm7deZ/zFysoBYmitcVtNjZBxDL5zt1y 2NvU3bWtj3gGBScmJphsWqPa19AjRZD+cCsZQMl2cc+eBAhiSPELoA3xdBM29u86C0Kt 1AMxg7J5K0azi4hC/fTa6WJEzXJILZE0iyajt8FI9Yo5qNuiodH8QCG6X9d7CiVvvv2s rWNzlMfuJH136LtUb0pAsj3LaIm309FvrSKVVVnKp1ufqojZO+GgSSojlILy/UrubYzQ EoUA== X-Gm-Message-State: AIVw1101Ewn/2jCKidFduCKXPIRz68SBa2EkJGTrcOSVmB1xQ6smcrzo IV1D42/Y9O0vuIz8a44mWKgRIfAJi61E X-Received: by 10.37.42.4 with SMTP id q4mr2122267ybq.204.1500159323946; Sat, 15 Jul 2017 15:55:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.27.4 with HTTP; Sat, 15 Jul 2017 15:55:23 -0700 (PDT) In-Reply-To: <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sat, 15 Jul 2017 15:55:23 -0700 Message-ID: To: "Salz, Rich" Cc: Daniel Kahn Gillmor , Joseph Lorenzo Hall , Matthew Green , Nick Sullivan , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11441e9a9c62120554630fca" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 22:55:27 -0000 --001a11441e9a9c62120554630fca Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 12:12 PM, Salz, Rich wrote: > > On the public internet, it's increasingly common for traffic to be MITMd > in the form of a CDN. > > A CDN is not a middlebox, it is not a MITM. It is a site that the origin > has hired to act as a "front" to it. > Don't take it as a criticism; I've built two CDNs, and I think they are an awesome and important part of the internet. But CDNs certainly are middle boxes; they sit between the origin and the client. A box, in the middle. What I'm trying to get it is the inconsistency of logic we are applying. So far responses on the mailing list have been saying "Don't use pcap, instead run proxies". For some reason we find proxies less distasteful, even though they have unbounded capability to destroy forward secrecy, even though they must be in-line and hence subject to exploit, even though it comes at massive cost (in my opinion), even though it's much harder to use proxies to examine plaintext in a forensic and selective way. Not only is this very unlikely to be an answer that will work for the enterprise network folks, if they did take our advice, it would actually be /worse/ security than what they have today. That has to be a bizarre outcome to promote. For what? moral purity? With regard to CDNs, that's more illogic: why are we so against a key being shared to decrypt session keys, but fine with a key being shared to facilitate total impersonation? I can't make sense of it. PS: I expect everyone who argues against facilitating PCAP decryption on the ground of "Forward secrecy is a must have" to make identical demands of 0-RTT, which can do much more damage to FS. -- Colm --001a11441e9a9c62120554630fca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 15, 2017 at 12:12 PM, Salz, Rich <rsalz@akamai.com><= /span> wrote:
> On the public internet= , it's increasingly common for traffic to be MITMd in the form of a CDN= .

A CDN is not a middlebox, it is not a MITM.=C2=A0 It is a site that the ori= gin has hired to act as a "front" to it.
Don't take it as a criticism; I've built two CDNs, and = I think they are an awesome and important part of the internet. But CDNs ce= rtainly are middle boxes; they sit between the origin and the client. A box= , in the middle.=C2=A0

What I'm trying to get = it is the inconsistency of logic we are applying. So far responses on the m= ailing list have been saying "Don't use pcap, instead run proxies&= quot;. For some reason we find proxies less distasteful, even though they h= ave unbounded capability to destroy forward secrecy, even though they must = be in-line and hence subject to exploit, even though it comes at massive co= st (in my opinion), even though it's much harder to use proxies to exam= ine plaintext in a forensic and selective way. Not only is this very unlike= ly to be an answer that will work for the enterprise network folks, if they= did take our advice, it would actually be /worse/ security than what they = have today. That has to be a bizarre outcome to promote. For what? moral pu= rity?

With regard to CDNs, that's more illogic= : why are we so against a key being shared to decrypt session keys, but fin= e with a key being shared to facilitate total impersonation? I can't ma= ke sense of it.

PS: I expect everyone who argues a= gainst facilitating PCAP decryption on the ground of "Forward secrecy = is a must have" to make identical demands of 0-RTT, which can do much = more damage to FS.=C2=A0

--
Colm
--001a11441e9a9c62120554630fca-- From nobody Sat Jul 15 16:01:57 2017 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 F072612EC14 for ; Sat, 15 Jul 2017 16:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 aGOIfwUFT1zU for ; Sat, 15 Jul 2017 16:01:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id C7D7C1205F0 for ; Sat, 15 Jul 2017 16:01:54 -0700 (PDT) Received: from fifthhorseman.net (38.200.broadband6.iol.cz [88.101.200.38]) by che.mayfirst.org (Postfix) with ESMTPSA id 713C4F9A0; Sat, 15 Jul 2017 19:01:52 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9EBC120DA4; Sun, 16 Jul 2017 00:34:33 +0200 (CEST) From: Daniel Kahn Gillmor To: "Dobbins\, Roland" Cc: "Salz\, Rich" , Joseph Lorenzo Hall , Matthew Green , Nick Sullivan , "tls\@ietf.org" In-Reply-To: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> Date: Sun, 16 Jul 2017 00:34:30 +0200 Message-ID: <87pod1qqh5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 23:01:56 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat 2017-07-15 07:38:57 +0000, Dobbins, Roland wrote: >> On Jul 15, 2017, at 13:14, Daniel Kahn Gillmor w= rote: >>=20 >> * This proposed TLS variant is *never* acceptable for use on the public >> Internet. At most it's acceptable only between two endpoints within >> a datacenter under a single zone of administrative control. > > I would strongly attempt to dissuade anyone from using it across the > public Internet. I agree that it is best-suited for use on networks > within a single span of administrative control, & that's the use for > which it is intended. How strongly would you attempt to dissuade its use across the public Internet? Strongly enough to support a proposal that would require this to be opt-in from both sides, with an explicit and verifiable exfiltration authority, so that no standard implementation of the proposed mechanism could be accidentally turned on unilaterally without detection by the unwitting peer? Because the current proposal isn't nearly that strong at dissuading its use on the public Internet. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAllqmHYACgkQFJitxsGS MjfP6g/+KFL4Dk5+poFDuv9ofl6Gc27n8J05TGMBsWhoXl0y3rtdIm3IoVxYgEGN R3RFqadOLSHdrYKS6JIIv9G+TD3C5luW0ghqc2kku9lAEPdB5tpjLqyKko9ZbIPS V4eJkkgAkK1bLKC/G6WbjqwJ8vzHTY3QgG1tiMUqAwv8+/2UEjVdThZcNsGi6dsM jpAF1QKFkAfCaAjT41I6/SoOY9P3V8E1Au8vd4JqjlsVvseZJaBhzTXG17+sWHAV z7oXWBJbUZb9+A6sGJjGLUMAi51WAcg4rrty08MOB3vgL69WlnA7TYbYQTTwc31F NoL0m0BNMgc/Ofrxne9RiWLqLfD6/FmkHvFs93bArgOH5ZOcKgO2Gz5nDipwzRlh 8S3NyT7DPcNMK6xTpUipgS1VTeyrtgEmZOYb8XqM63Ke3rTIY/4FB9dtngboPVIC Apyub0KByKy3Ep0wjhXuu+QsnoFW2gPLEz3pENEZqEt4g58YYh6K/7VbI9kPTMyD VGwgwXO/VqzSNymutN0Zuoot0dcHY7HqhbzdwA86s0GudkzqpMBpNxvNS/tjZsJi K+8cSk1+9SF+ry0oBocq+1PHf3Y+3BhNbbFrzGr8pXKafR9BhHTqVJ/Meh3sCw1Q yR+VpkylLLEX+TDCUgWV4YbNnl7DqJLoJSCHtAwB66raWXIlIxg= =iJO1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 15 16:08:04 2017 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 E0A6B12F547 for ; Sat, 15 Jul 2017 16:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 P_VDEbS3jdYr for ; Sat, 15 Jul 2017 16:08:00 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B6712EC2B for ; Sat, 15 Jul 2017 16:07:59 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id k14so61722459pgr.0 for ; Sat, 15 Jul 2017 16:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wIB/zstwDXSGDkOvuyA/EIafFl6jal9Uw5Q9o7ot6Z8=; b=PF0lkaSOhvRsTvGq9ASnDUhwl1Wnd8y1Y9bmVJegYcO9PLCfNDJNoMc5ro0ctRRRep dyKovtFw3OcvgaUtftC4MkGYF9SazPAYiLBOFw/XjQTLVvWZYCUu3ZAfZq97gQD5FeOj qucO3hvU6DZ7oy0Q3LG8hr7B+4GvIYwLkI+Cydhpz9eDaQgOgYtYLc9ZlQC16WVxNQ2K fwka1OxjKbFwmfOYPG4F11uWu4P8sPv1bV6VyYdGAISrepRxQD8Iu+1YJ4aWlSVd4GV6 O6pYMMOSI+fG2J5u89+4+3PNi9Bg3ed8yd/vQ3UaimPw/Puvmn6PyiyOrOr1WoaKOZAq +OGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wIB/zstwDXSGDkOvuyA/EIafFl6jal9Uw5Q9o7ot6Z8=; b=I7W0dDqOpvtPVSCYGM+9Mqzcs3bGzbVUMYqBBV9xDnlhFLqo414+6nj+3RemFnXlxj CEaCiBBzVL/I0fDdEiqmREpuASKhSIOoUYq6+Y6PX0kKqATBc/c0DHjwWe/FCgcQlVps hiZluKG79PE3H1aY+hKyXzAIyRR2NNN+7GvaSBb4QQPAkFc4WOYjN+35iYBzcNLtC7sN 4araHpB1/cKftQEVE0oT8l3rLYSmB/6Hq+jlgxhUi6neWqmwi6q5Y+HO6tsPAsCtRbUI /wC27fYcKvgUS+aOiEZAP1ByWylw8T7ugdd77E4TjJ5OgH1DBYGYZW7Kkihk9ycppg9N louA== X-Gm-Message-State: AIVw110YsnnBSky6qaOrUZFQ79aPR6OapX8cJUmzF8yLQT+cOZ5XEAsh YHitZkvjpZGwwBRZlYIPODxDMVl8nQ== X-Received: by 10.84.132.13 with SMTP id 13mr22807059ple.42.1500160079504; Sat, 15 Jul 2017 16:07:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 16:07:58 -0700 (PDT) Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 16:07:58 -0700 (PDT) In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> <46888EEF-750B-46CF-BA77-1827DD6D3607@arbor.net> From: Watson Ladd Date: Sat, 15 Jul 2017 16:07:58 -0700 Message-ID: To: "Ackermann, Michael" Cc: Matthew Green , "Dobbins, Roland" , IETF TLS Content-Type: multipart/alternative; boundary="94eb2c1254e6a5298a0554633cc6" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2017 23:08:02 -0000 --94eb2c1254e6a5298a0554633cc6 Content-Type: text/plain; charset="UTF-8" On Jul 15, 2017 12:39 PM, "Ackermann, Michael" wrote: I would be interested in how you initiate the traces at all the hundreds of thousands of servers and clients and how you control the flow of pcap files back to where they need to be processed? How are users and apps not impacted? Currently I work at Cloudflare, not in ops. It's possible some of what I say is wrong. We don't collect all traces if I understand what you mean by trace as a packet capture. I misread your email. No technology I know of would make that possible at our scale. We do log a significant amount of information on requests and our responses include headers that indicate the path taken through the system.(the cf-ray you see when some sites fail behind us) We can quickly determine what went wrong if something did through internal inspection tools starting from those id's and problematic requests. This works to identify, isolate, and fix problems in a complex system with multiple internal services. This architecture scales to what we estimate as x% of all HTTP requests. Not x% of what we see, but of all of them. ( the x is sizeable) The logging is done with open source log collection software. Because packet capture and later decryption was not an option we created other tools. I don't know about internal app troubleshooting. Maybe we are talking at cross purposes, because I don't see why apps cannot log to local disk/ have a good idea of situations where pcap is really necessary and you can't log the keys. If you can log pcaps, you can log to disk somewhere. *From:* Watson Ladd [mailto:watsonbladd@gmail.com] *Sent:* Saturday, July 15, 2017 3:26 PM *To:* Ackermann, Michael *Cc:* Matthew Green ; Dobbins, Roland < rdobbins@arbor.net>; IETF TLS *Subject:* Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017 11:16 AM, "Ackermann, Michael" wrote: YES! I tried to say in my message that collecting traces on thousands, or hundreds of thousands of hosts, is just not practical or possible. Not to mention the administrative domain barriers to this. We do it every day at my current employer. Guess we do the impossible. *From:* Dobbins, Roland [mailto:rdobbins@arbor.net] *Sent:* Saturday, July 15, 2017 2:03 PM *To:* Ackermann, Michael *Cc:* Ted Lemon ; IETF TLS ; Matthew Green < matthewdgreen@gmail.com> *Subject:* Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017, at 22:36, Ackermann, Michael wrote: That being the unencrypted stream is available to the endpoints Even where it is eventually available, they don't have the horsepower to capture & forward. ----------------------------------- Roland Dobbins The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. --94eb2c1254e6a5298a0554633cc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable





=C2=A0

=C2=A0

=C2=A0

From: Watson Ladd [mailto:watsonbladd@gmail.com]
Sent: Saturday, July 15, 2017 3:26 PM
To: Ackermann, Michael <MAckermann@bcbsm.com>
Cc: Matthew Green <matthewdgreen@gmail.com>; Dobbins, Roland <rdobbins@arbor.net>= ; IETF TLS <tls@ietf.o= rg>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01=

=C2=A0

=C2=A0

=C2=A0

On Jul 15, 2017 11:16 AM, "Ackermann, Michael&q= uot; <MAckerma= nn@bcbsm.com> wrote:

YES!

I tried to say in my message that collecting traces= on thousands,=C2=A0 or hundreds of thousands of hosts,=C2=A0 is just not practical or possible.=C2=A0=C2=A0 Not to mention the administrative domai= n barriers to this.=C2=A0

=C2=A0

=C2=A0

We do it every day at my current employer. Guess we = do the impossible.

=C2=A0

=C2=A0

=C2=A0

From: Dobbins, Roland [mailto:rdobbins@arbor.net]
Sent: Saturday, July 15, 2017 2:03 PM
To: Ackermann, Michael <MAckermann@bcbsm.com>
Cc: Ted Lemon <mellon@fugue.com>; IETF TLS <tls@ietf.org>; Matthew Green <matthewdgreen@gmail.com>=
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01=

=C2=A0

=C2=A0


On Jul 15, 2017, at 22:36, Ackermann, Michael <MAckermann@bcbsm.com> wrote:=

That being the unencrypted stream is available to th= e endpoints=C2=A0

=C2=A0

Even where it is eventually available, they don'= t have the horsepower to capture & forward.=C2=A0

=C2=A0

-----------------------------------
Roland Dobbins <= rdobbins@arbor.net>

=C2=A0

=C2=A0

=C2=A0

The information contained in this communication is highly confidential a= nd is intended solely for the use of the individual(s) to whom this communi= cation is directed. If you are not the intended recipient, you are hereby n= otified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notif= y the sender, by electronic mail or telephone, of any unintended receipt an= d delete the original message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are= nonprofit corporations and independent licensees of the Blue Cross and Blu= e Shield Association.


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

=C2=A0


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this commun= ication is directed. If you are not the intended recipient, you are hereby = notified that any viewing, copying, disclosure or distribution of this info= rmation is prohibited. Please notify the sender, by electronic mail or tele= phone, of any unintended receipt and delete the original message without ma= king any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan ar= e nonprofit corporations and independent licensees of the Blue Cross and Bl= ue Shield Association.

=20

--94eb2c1254e6a5298a0554633cc6-- From nobody Sat Jul 15 17:39:26 2017 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 D3FFF12F253 for ; Sat, 15 Jul 2017 17:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8TKp5wb4xD7 for ; Sat, 15 Jul 2017 17:39:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A01D13144D for ; Sat, 15 Jul 2017 17:39:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5AFCBE50; Sun, 16 Jul 2017 01:39:19 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY0JtE51gBS0; Sun, 16 Jul 2017 01:39:18 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8F5F6BE38; Sun, 16 Jul 2017 01:39:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500165558; bh=aOrYwF4SunGbdayUFU+wYkXuj7bAVqWnrKnlw3D2n/0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eKFpR18X/iW7t2qhc8E1q9Sn1dLa0vM+aibVNp6wc+a9rSaukFOeLiyU9ePNZqFlK o2KGDemXMCoucoc0plppvh+aGskwMMPU6wjVxrfLpccCx6zAShov6UyTNU+hBh8qIT ruLzVEaoqZzU4HjXBjdYU2HTPp7s3+XHnWQXCFAg= To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , "Salz, Rich" Cc: "tls@ietf.org" , Matthew Green References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> Date: Sun, 16 Jul 2017 01:39:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GdbIrI2kkkhnbLS89IE43oWKD5AldlUtA" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 00:39:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GdbIrI2kkkhnbLS89IE43oWKD5AldlUtA Content-Type: multipart/mixed; boundary="kfUPS0jcidx6Ghu270Jgm7f2wTReXdX1s"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , "Salz, Rich" Cc: "tls@ietf.org" , Matthew Green Message-ID: <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: --kfUPS0jcidx6Ghu270Jgm7f2wTReXdX1s Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 15/07/17 23:55, Colm MacC=C3=A1rthaigh wrote: > So far responses on the mailing list have been saying "Don't use > pcap, instead run proxies". Sorry, but that is incorrect. Some list participants have said "we need pcap" and others have said that "no, we do not need to use packet capture." And others, myself included, consider that there is dearth of evidence. The only reason to point that out is that it's one amongst a pile of statements from the proponents of drafgreen, that make assumptions that are pretty clearly counter-factual. S. --kfUPS0jcidx6Ghu270Jgm7f2wTReXdX1s-- --GdbIrI2kkkhnbLS89IE43oWKD5AldlUtA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZarW2AAoJEC88hzaAX42ii0oIAKjNvXl77Efq3LdgtpD/mPR/ jjRSprFG5KuhA2lM0SGoIwqI+G9dx7agJmnpWvCw+xOu88wx/bjciY4KGGTZQlB7 E0bRmj6jGDyklgoPLLIYzTcSMVrNjSj+ygl6zLWvrgikltLxgDn+Q6cvVmflGcUO yTIXVyNkeH4PJN8qpZtHzB6NL9+0giJQ/GDJktNDgzCWAIcfya1iH16ARrWnsGUG cHgw3qeArkLKP8+CrxtZVm9xUdJKsQXoho2EgjFsLIsMr1dcOzmgYep7KGE7Xrt8 B/Nh7haqQ6pDuUE188+VAD6TCOGWyPZVyRwaWxD5xMtb2BaCpdPvoeU6xUkZQ9E= =InA5 -----END PGP SIGNATURE----- --GdbIrI2kkkhnbLS89IE43oWKD5AldlUtA-- From nobody Sat Jul 15 21:04:07 2017 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 3D9F8127869 for ; Sat, 15 Jul 2017 21:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 BISrU1IuyZK6 for ; Sat, 15 Jul 2017 21:04: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 CFEBC127735 for ; Sat, 15 Jul 2017 21:04: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=1500177843; x=1531713843; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=isD3Kwgt1pgF8SEy9a7wRjXxpKqi2dlezZljAEHcYGA=; b=fWOQlzf9t2nPnLwMYFsb/tVjFw0KHGtUFldoK03swgY2PrndI4dQy5qb yN2EVAkZrwJYu1SS4rsJjPB4wGwf5JDLwDy/+b7F64WqAWezIzzrpp7+B 3fK2OBdf7NvItHsjxsCW9R6hFS8uvTCqkawHOb5JTIu0ld8lnNLg12ha9 hnWU5wSCXTYe0F3JriQNnhLIL+6GFUAqApqON+4aY4z7KiPVM/3Jkt2FD kdTWyB2mXjtBSWSpY/85nFe6gGCUIZUcTZbJGdG0+KqNVJ7mu73G4m/Ml NG25Ff/1fURUj0IsVAfspLfxPnzY6ZBGpitNpX5frSRL0Np3AzCALt6dy Q==; X-IronPort-AV: E=Sophos;i="5.40,367,1496059200"; d="scan'208";a="165620923" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Jul 2017 16:03:57 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.28) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 16 Jul 2017 16:03:57 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Sun, 16 Jul 2017 16:03:57 +1200 From: Peter Gutmann To: Nick Sullivan , "Dobbins, Roland" , Ted Lemon CC: IETF TLS , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8WfZRzCSd0QUCONEJhviFEL6JHi20AgAA7kwCAAB2SAIAABXAAgAABDgCAABZXAIALri2AgAAVVwCAAAFLgIAAAg6AgAADOACAAASTAIAAB0QAgAAEhACAAAMcAIAAHD8AgAHnA4s= Date: Sun, 16 Jul 2017 04:03:56 +0000 Message-ID: <1500177825613.70567@cs.auckland.ac.nz> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> <6770F4F3-3793-46F9-B47C-25EBE2E7DF5A@arbor.net>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 04:04:06 -0000 Nick Sullivan writes:=0A= =0A= >the Elliptic Curve variant has recently been identified as troublesome as= =0A= >well (see recent JWE vulnerability=0A= >https://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-= in-json-encryption.html =0A= >and CVE-2017-8932).=0A= =0A= Which sorta begs the question, why was it put in the standard (or at least = an=0A= addendum to the standard) in the first place? Misusing DH as if it was RSA= =0A= was a dumb idea [0] when it was made a part of S/MIME twenty years ago - th= e=0A= entire S/MIME implementer community ignored the X9.42 MUST and kept on usin= g=0A= the RSA MAY as if it was the MUST, and PGP used it as Elgamal even if they= =0A= labelled it DH. Given that JWE quite sensibly specifies RSA-OAEP, why was= =0A= ECDH-ES also given as an option, and why would anyone then actually use it= =0A= rather than just ignoring it like X9.42?=0A= =0A= Peter.=0A= =0A= [0] I was going to say "bad idea" but it was so obviously wrong to pretty m= uch=0A= everyone involved that I've upgraded the epithet.=0A= From nobody Sat Jul 15 21:41:05 2017 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 BF0A21316DE for ; Sat, 15 Jul 2017 21:41:03 -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 9FgSpncAgOpo for ; Sat, 15 Jul 2017 21:41:02 -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 C0A8C1316B4 for ; Sat, 15 Jul 2017 21:41:02 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id x125so37828358ywa.0 for ; Sat, 15 Jul 2017 21:41:02 -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=cS+qiDMY60nSPNbLjBr5lxqK18jV4nGJPBFIsKAFeYI=; b=zwl6qIriRtxjU0rwudMf2unpOTzVQFVztrgk3GXzxl4j3WiSyT2ipB7eI+taIpKOO3 E7ZIXWGV5FDKqY09uFp/l+TqbO8VtoQQK63M8gJdylNlwAkWAy+yexiKH/eRQsTPh7lo 5VG4AxGS+97ACNoHXZAyPhkPuX7vKXA8sXCh+MVH9hFBkXqGBOYObnXjXZN4lNSXU7By clBIqTMANj8HxScPH0RPHS8827zTpGmXpRAB3VclWhBecT0MfsDPIxSue24n9TNqCJqA DEexJXSZl2BYEKpgqbnxAiztTgSTgv9KKBdS0S9ws5tkwQqEeWAmsxO/pykWLXUXH4Q2 cQ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cS+qiDMY60nSPNbLjBr5lxqK18jV4nGJPBFIsKAFeYI=; b=fgQCI+ZIcPzcGOFtk8qNITJ1XV8ZQJbcAfYygJ1INuydr6OdVqgJQwYUnggqmWWygw NxeUgCIuTMND+H+jvamzTDfBfKzgB1eyIQw7bDdI8VWeiVk5s9iJ0EBtCZaRrA+rzrAd YbNmIlAUiQnrYMx0D9BRc48S3fQdcvq11meVgFYUJIeWHwPfasSIaiiGVgO7yoaCnc9P irHVSxUCHsIWslvU+W3Au8qOze897GtOT5C3AiiWrPLSIbMN9zpYiC7dUoJojuUPz8c+ Xe4Op9wLglYQfjJ7D1AqGVid8LKqzJgOL0C1bzowPi5qIiLvupj//a8xai4j5M3s8wpq j9dg== X-Gm-Message-State: AIVw1125nDDE2zzPr5E0BJlln9tuBXxt2zFwdY3RRCO2LJfoLEE6nosd fR1j6sg4jnHobPfmcUyT6zQnuB9ye7FQ X-Received: by 10.13.251.71 with SMTP id l68mr13227298ywf.182.1500180061830; Sat, 15 Jul 2017 21:41:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.27.4 with HTTP; Sat, 15 Jul 2017 21:41:01 -0700 (PDT) In-Reply-To: <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sat, 15 Jul 2017 21:41:01 -0700 Message-ID: To: Stephen Farrell Cc: "Salz, Rich" , "tls@ietf.org" , Matthew Green Content-Type: multipart/alternative; boundary="94eb2c07e78aaf5aa2055467e362" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 04:41:03 -0000 --94eb2c07e78aaf5aa2055467e362 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell wrote: > On 15/07/17 23:55, Colm MacC=C3=A1rthaigh wrote: > > So far responses on the mailing list have been saying "Don't use > > pcap, instead run proxies". > Sorry, but that is incorrect. Some list participants > have said "we need pcap" and others have said that > "no, we do not need to use packet capture." And others, > myself included, consider that there is dearth of > evidence. > Can you be more clear what is lacking in evidence? Are you skeptical that existing network operators don't do this kind of decryption? There's support for it in tools like Wireshark. Is that sufficient evidence? Are you skeptical that there's no evidence that using proxies instead would be a burdensome change? I'm not skeptical of that at all, but would be interested in what acceptable evidence would look like. Though I'll point out again: TLS 1.3 is the new thing that we want to gain adoption, so really we should be looking for evidence that it's /not/ a burdensome change. --=20 Colm --94eb2c07e78aaf5aa2055467e362 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:
On 15/07/17 23:55, Colm MacC=C3=A1rthaigh wrote:
> So far responses on the mailing list have been saying "Don't = use
> pcap, instead run proxies".
Sorry, but that is incorrect. Some list participants
have said "we need pcap" and others have said that
"no, we do not need to use packet capture." And others,
myself included, consider that there is dearth of
evidence.

Can you be more clear what is= lacking in evidence? Are you skeptical that existing network operators don= 't do this kind of decryption? There's support for it in tools like= Wireshark. Is that sufficient evidence?

Are you s= keptical that there's no evidence that using proxies instead would be a= burdensome change? I'm not skeptical of that at all, but would be inte= rested in what acceptable evidence would look like. Though I'll point o= ut again: TLS 1.3 is the new thing that we want to gain adoption, so really= we should be looking for evidence that it's /not/ a burdensome change.= =C2=A0

--
Colm
--94eb2c07e78aaf5aa2055467e362-- From nobody Sat Jul 15 22:48:18 2017 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 A867C12700F for ; Sat, 15 Jul 2017 22:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 H-tgAal5cjnR for ; Sat, 15 Jul 2017 22:48:15 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id F30F0120726 for ; Sat, 15 Jul 2017 22:48:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 2ACD62280A for ; Sun, 16 Jul 2017 08:48:12 +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 wiYdW9_w7NYv for ; Sun, 16 Jul 2017 08:48:11 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id D04D421C for ; Sun, 16 Jul 2017 08:48:10 +0300 (EEST) Date: Sun, 16 Jul 2017 08:48:10 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20170716054810.5lyb3butdcvwqsrh@LK-Perkele-VII> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 05:48:17 -0000 On Sun, Jul 16, 2017 at 01:39:17AM +0100, Stephen Farrell wrote: > > > On 15/07/17 23:55, Colm MacCárthaigh wrote: > > So far responses on the mailing list have been saying "Don't use > > pcap, instead run proxies". > Sorry, but that is incorrect. Some list participants > have said "we need pcap" and others have said that > "no, we do not need to use packet capture." And others, > myself included, consider that there is dearth of > evidence. > > The only reason to point that out is that it's one > amongst a pile of statements from the proponents of > drafgreen, that make assumptions that are pretty > clearly counter-factual. The architetures I have seen proposed, and some quick characteristics of each (each has its good sides, bad sides and security impacts, minor or major): No visibility at all: - Rely on IoC for malware (can be highly effective in low-background networks, high-background networks are a lost cause anyway). - Debug network by TCP correlation (can be highly effective if issue is within networking). - Application looging for debugging endpoint problems. - No visibility infrastructure to exploit. Packet captures with OoB key logging: - Can have visibility at both sides. - Can be high data amounts, but pcaps are much larger. Trigger jointly to reduce storage. - Can asymmetrically encrypt the key data (and possibly also transport- encrypt for additional layer of security). - Can give additional very-low-background channel w.r.t. malware. Packet captures with in-band key logging: - Can have visibility at both sides. - Needs opt-in from both sides for server-side logging (client-only for client-side logging). - Asymmetrically encrypts the key data. - Can't easily use transport-encryption for additional protection. - Automatically triggers jointly with packet captures. Proxies: - Can archive full visibility. - Potentially heavy processing for lots of connections. - Central point of attack in well-visible place. - Required anyway in certain kinds of networks. DH secret sharing (draft-green type): - Visibilty on server side only. - Needs proxies for external connections to avoid static or shared DHs from leaking. - Pull leaves visible central point of attack visible. - Push has self-vulernabilities. And then there is major difference between _architecture_ (specify the parts, requirements on them and analyze the results, without specifying anything concretely implementable), _framework_ (specify places to plug parts, but do not specify enough to make it interoperable) and _protocol_ (specify something that is implementable and interoperable). The difference between last two is especially large. If draft-green had been about architecture and did the analysis well (and had appropriate status for such draft, informational), it would be much much less controversial than the current one, which is a _protocol_ and labeled standards-track at that. My opinion is that if the WG wants to work on "TLS 1.3 visibility", it should be about various architectures, part requirements thereof and analysis of results thereof. Good analysis of impacts is a goal (something desriable to archive), interoperability is an anti-goal (something _undesirable_ to archive). The WG sure as heck should not work on interoprerable attack protocol (like one proposed in draft-green). Of course, such "visibility architectures" document would be quite a bit of work, especially considering that it would actually requires analysis, which is much harder than just specifying something interoperable. However, I don't care too much if "visibility" architecture work is done here or not. I do very much care that attack protocol work is _NOT_ done here, nor anywhere else within IETF (can't do much about various industry SDOs filled with industry hacks, I am sure there is plenty of those to go around). -Ilari From nobody Sat Jul 15 22:55:23 2017 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 6C278127180 for ; Sat, 15 Jul 2017 22:55: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, 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=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 gZM3RVTcAWGY for ; Sat, 15 Jul 2017 22:55:19 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 BD05C120726 for ; Sat, 15 Jul 2017 22:55:19 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6G5qHIR029221; Sun, 16 Jul 2017 06:55:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=PisGtEAHsWAU5E41cFlWG3izwuBCkw5ylk+mXpIlo5k=; b=K9xN4G9RcXCngrVew8cF6RxLikQtD/UmbGwQST/OOXC5DROZ3L74X4dL/JZUbrbCpZXc pQEUQahv/Lg89EtaS0dAZbilKI1uZkPCURhosOg5wq5krcOGYJl6Z/ZlLEX6xC5xQtSG aYx5Btb4MTlGWsJtKWf/QDzQlG0kdM0W0lQTN0jqG+mhuQSdKwgVfGcVeRT0oNiYme6L 5JQ8SqIfr+HqkoDeJCprfUka7KWicM6UewUDybnLHVaTfwNypMYoDRR7wrG0ZI7aBmnU CwotJKxTXKEwMrido/bonVvbjs0/iqDYLuFza8HSJLsPOZTQm6Xa3mLRXQ+chy8Oqdb7 xA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2bqak4kgj1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Jul 2017 06:55:15 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6G5omJb015784; Sun, 16 Jul 2017 01:55:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2bqecut7pj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 16 Jul 2017 01:55:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 15 Jul 2017 22:55:13 -0700 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.1263.000; Sun, 16 Jul 2017 01:55:12 -0400 From: "Salz, Rich" To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= CC: Daniel Kahn Gillmor , Joseph Lorenzo Hall , Matthew Green , Nick Sullivan , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAAga+AgAAyCMA= Date: Sun, 16 Jul 2017 05:55:11 +0000 Message-ID: <0440b89a494c4c7eaf5f5a905790e36d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.147] Content-Type: multipart/alternative; boundary="_000_0440b89a494c4c7eaf5f5a905790e36dusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-16_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707160095 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-16_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707160095 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 05:55:21 -0000 --_000_0440b89a494c4c7eaf5f5a905790e36dusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3Qgb2ZmZW5kZWQuICBJIGFtIHNheWluZyB0aGF0IGlmIGl0IHRlcm1pbmF0ZXMgdGhl IGNvbm5lY3Rpb24gaXQgaXMgYW4gZW5kcG9pbnQgbm90IGEgbWlkZGxlYm94Lg0KDQo= --_000_0440b89a494c4c7eaf5f5a905790e36dusma1exdag1mb1msgcorpak_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYW0gbm90IG9mZmVuZGVkLiZuYnNwOyBJIGFtIHNheWlu ZyB0aGF0IGlmIGl0IHRlcm1pbmF0ZXMgdGhlIGNvbm5lY3Rpb24gaXQgaXMgYW4gZW5kcG9pbnQg bm90IGEgbWlkZGxlYm94LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0440b89a494c4c7eaf5f5a905790e36dusma1exdag1mb1msgcorpak_-- From nobody Sat Jul 15 23:02:57 2017 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 20B2F126B7F for ; Sat, 15 Jul 2017 23:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-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 KdaiI7HA5sjQ for ; Sat, 15 Jul 2017 23:02:54 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 C4AEE120726 for ; Sat, 15 Jul 2017 23:02:53 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id v60so16762891wrc.3 for ; Sat, 15 Jul 2017 23:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=DWoSeWEcUp1Oa5NPmqcAo4jgI06ADvm9ZLUIjeJVSvk=; b=NFPJM/c5MNH8bzEgnEiNf8BZp5mM2FxsaFmKmYRKQI9NctVWcUPqSJxKoJZVFJCVkP nOU0lmhM3zpP0j7bojP3PVK694m102f39XpGUERpdKeJ9zlntFWk0IWHALwysSd+00rq P7f+GSB1QHoKtYaREc7qZ82+CQPSZAzjYm8r88aTrTRD7Y0Srwdk48QXSmAot2dHo9Vb PD/IXYpxHR+JEj0GDDKf/wHZ+UaoR71R43ALDLxpPeyjyzt/KyHHfUSKrkvWClEdMKbM JnxrltEEEK/pmIEk3HIfelD53c88K+MyDqh66hUza3CaWAvgHQNVlLS5Zb+wery9Bwiw NvvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=DWoSeWEcUp1Oa5NPmqcAo4jgI06ADvm9ZLUIjeJVSvk=; b=KkmI2phrpopdo9SpwwX87aLXNX1bZwkxJ5JP73O/KsUlc6TNyXtTniX7XbYaIhm/SW tDxbaueYEygQjWIM3h13t0VYTf1Ntt/G6EtgQ5PWT8Bl4EMp2INJLCbXOk6xmX6eElti RHrKMzDFJQmzLXYQUrcekzkCfGm0YkQvZUhFFkKynJSV1vjE0OSZ6wbAZsYfLBXg+lGU s+w69h05L8tcvDDtxrUmIqcc21CSkBosXekLjRRVaEGk7/x7odBB/ga/3BtTCq3du1nG rC1vGeA3UiFZq7XSqsc+KvqtVA2mdai6JzelFyb+Cn/EnVcVCgC/Box/M40aHtwt5/2Y MRXw== X-Gm-Message-State: AIVw110IhHq2bQ9O1v6NrRlEgwQX+LMycFX4z9nqugk+xe6aqza9rJIB I5CczgN2W5GsxZFXx7l1Og== X-Received: by 10.223.131.225 with SMTP id 88mr8261455wre.51.1500184971916; Sat, 15 Jul 2017 23:02:51 -0700 (PDT) Received: from dhcp-9730.meeting.ietf.org ([2001:67c:1232:144:e80d:3c44:1d6e:df40]) by smtp.gmail.com with ESMTPSA id c131sm8972114wmh.2.2017.07.15.23.02.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 23:02:51 -0700 (PDT) To: tls@ietf.org References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <0440b89a494c4c7eaf5f5a905790e36d@usma1ex-dag1mb1.msg.corp.akamai.com> From: Melinda Shore Message-ID: <491983ae-3d6d-d302-aa2f-f13e166407c0@nomountain.net> Date: Sun, 16 Jul 2017 08:02:50 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0440b89a494c4c7eaf5f5a905790e36d@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mW9SL0A2aAAoES66eRIVQ9LFmeSq4rapC" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 06:02:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mW9SL0A2aAAoES66eRIVQ9LFmeSq4rapC Content-Type: multipart/mixed; boundary="2rx7viM2WWXqKJwEkQGDaJDExoqgKb0lc"; protected-headers="v1" From: Melinda Shore To: tls@ietf.org Message-ID: <491983ae-3d6d-d302-aa2f-f13e166407c0@nomountain.net> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <0440b89a494c4c7eaf5f5a905790e36d@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <0440b89a494c4c7eaf5f5a905790e36d@usma1ex-dag1mb1.msg.corp.akamai.com> --2rx7viM2WWXqKJwEkQGDaJDExoqgKb0lc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/16/17 7:55 AM, Salz, Rich wrote: > I am not offended. I am saying that if it terminates the connection it= > is an endpoint not a middlebox. Well, maybe. That's certainly the general understanding of middleboxes (i.e that they they are not directly addressed [well, NATs, but] and that they don't terminate traffic) but even way back when we did the original midcom work and produced 3234 (hard to believe it's been 15 years) there was some mushiness around transparency being a requirement for being considered a middlebox. For example, from 3234: Note that HTTP proxies do in fact terminate an IP packet flow and recreate another one, but they fall under the definition of "middlebox" given in Section 1.1 because the actual applications sessions traverse them. However, that's not really a description of the behavior of CDNs - HTTP sessions really do terminate on cache nodes. That said, I'm not sure how this helps sort out the question of what (if anything) needs to be done to satisfy monitoring requirements in some deployments. Melinda --2rx7viM2WWXqKJwEkQGDaJDExoqgKb0lc-- --mW9SL0A2aAAoES66eRIVQ9LFmeSq4rapC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZawGKAAoJELiGRpM6HoEuvd0QAMiXdbxsuLE7j5+RAXMWYkM+ lqKva5NbpUclP3togV3EpGfOKznghHnJC6LQiaDCScG3b8vlb76f3Enqm0h+lTRM 3/q0PCRi093PwYZtCbOqPEgTtQy2AZcWnvrfw5cv6x59qZM2Tp3ZbochE53plm9B U/LxR5G5nnoCl0VPOw8guJLkGHXsfQ0YEbmXddUq2TtPav2QbeDEu+NUqB/aD4pj fUOzKuJgprHJuX8ZiTd96UjGe3ACQm89CjHppbFU2mytPICfaTF8IW3PE34lGab2 zm41M+5P5Bo9d1di/Gbta/EZW4M1324/ByKahOe0gVQQKpEo765u0Fms6q5z+U+T yG49OVTv1SaWvgH98p18c9Y788uaXZ0hnMgjwsIPH/An5g49Tg1HYw/+yNk8hz5J w7L1mTNX1scXI5cpHND/LQCL+0QOUM1EQMMzHWJ2MnoIyi1m5pVjv4qQ+WJyBk26 Ql+EeFU1v9UEhX52rw3f5S9Ogeox0G62AitMbSdr9cic/sNYdwdXSvSQ0MccikoB f9ovwDRkoyc3aU87h5d8A0x/yGDd/lJdeAz77uXQSdZtjtK6jMXssa7Mqu1Y9gZb iymMy4rOvwaSf6craFAipaqNmthgWIZlfBtao1ocKOSrUSd7jU9jvtW7BnkV06t8 lrGuxenT76uIvYUom5K6 =lQEF -----END PGP SIGNATURE----- --mW9SL0A2aAAoES66eRIVQ9LFmeSq4rapC-- From nobody Sun Jul 16 01:00:03 2017 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 6B416131771 for ; Sun, 16 Jul 2017 01:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYwRSmycVUF3 for ; Sun, 16 Jul 2017 01:00:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861BD127180 for ; Sun, 16 Jul 2017 01:00:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7D355BE58; Sun, 16 Jul 2017 08:59:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR6jg0t1mz43; Sun, 16 Jul 2017 08:59:57 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E1DBFBE56; Sun, 16 Jul 2017 08:59:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500191997; bh=FkhrmzYaKsZKSAc90CP9618b6WNl7B+bxM067NQu0/w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KNw69Ps2stKZ/fUFWlff8iJXg5+VGZUGPz446zGW5GlaO6e+G9kX1an5lzF+5tfbe 3VImXHIHCEM/lIRw7b6PNTrnTj58lE25UxNBv9HyuKZ9QCva1LkwxSXkSorP3MDbjP KxLUBrmOXqvX1brDJXA0jTsmAE7cRlvI99Db5C4Y= To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= Cc: "Salz, Rich" , "tls@ietf.org" , Matthew Green References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> Date: Sun, 16 Jul 2017 08:59:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wJW6KX956kiq8k94Q7StTt8o0RnhMDnSL" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 08:00:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wJW6KX956kiq8k94Q7StTt8o0RnhMDnSL Content-Type: multipart/mixed; boundary="vagMVSIq0bfT3GppS8igj8xsmwCd20KDK"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= Cc: "Salz, Rich" , "tls@ietf.org" , Matthew Green Message-ID: <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> In-Reply-To: --vagMVSIq0bfT3GppS8igj8xsmwCd20KDK Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 16/07/17 05:41, Colm MacC=C3=A1rthaigh wrote: > On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell=20 > wrote: >=20 >> On 15/07/17 23:55, Colm MacC=C3=A1rthaigh wrote: >>> So far responses on the mailing list have been saying "Don't use >>> pcap, instead run proxies". >> Sorry, but that is incorrect. Some list participants have said "we=20 >> need pcap" and others have said that "no, we do not need to use=20 >> packet capture." And others, myself included, consider that there=20 >> is dearth of evidence. >>=20 >=20 > Can you be more clear what is lacking in evidence? Sure, sorry for the late-night terseness:-) In this debate, there is a fairly complete lack of evidence being offered as to: - the (in)effectiveness of proxies or key-leaking vs. one another and vs. not doing either - the precise scenarios in which pcap+key-leaking is the only possible (*) answer, and how commonly those scenarios occur (*) I am not asking that people tell me that "pcap+key-leaking" might work, but for them to describe when that works but nothing else works. And that has to include the details of what it is they can only find in the recovered cleartext that cannot be detected without access to cleartext using this particular method. > Are you skeptical that existing network operators don't do this kind > of decryption? I believe that people do this kind of key-leak+pcap decryption. People do all sorts of other unwise things too (myself included, and fairly frequently;-), that is not a reason to encourage more of "it" for any "it." > There's support for it in tools like Wireshark. Is that sufficient=20 > evidence? Yes and no. That is sufficient in that yes it says that people can use this tool. It is nowhere near sufficient evidence that the IETF should standardise (an API for) such a tool. The existence of a wireshrark dissector for a protocol is also fairly weak evidence as to the importance of such a dissector - it seems to be fairly common for folks to write those for lots of other reasons, e.g. during protocol development, as student projects that require no thought from the prof etc:-) > Are you skeptical that there's no evidence that using proxies > instead would be a burdensome change? No. All changes are burdensome, and it's clear that that one would be. (My own belief is that adding proxies solely to help with possible network debugging would be dim anyway - I'd argue there ought to be a functional reason for each proxy added.) I would also note that the "use a proxy" argument seems to me to mostly be offered as a strawman counter-argument by folks who would like to break TLS via static DH, and doesn't seem to be a common argument offered by those against breaking TLS. (Adding proxies is of course another way to break TLS, depending on how and where it's done.) > I'm not skeptical of that at all, but would be interested in what > acceptable evidence would look like. I'm not sure of the phrase "acceptable evidence" but regardless of that: TLS is an important protocol, extremely widely used. For any attempt to weaken or break TLS, I think the onus is on the proponents of the break-TLS proposal to produce convincing evidence that their scheme will at least be a net positive, considering the entire ecosystem that is dependent on TLS. And even if there is evidence that a scheme would be a net positive, it may still be a bad idea, if the negative aspects of the scheme have serious enough impacts in some use-cases for TLS. That's a pretty high bar, yes. And so it should be. I'm not at all clear it can be cleared, ever. > Though I'll point out again: TLS 1.3 is the new thing that we want > to gain adoption, so really we should be looking for evidence that > it's /not/ a burdensome change. Sure, that is another fine thing to do. It'd be helped along if we had evidence about the precise scenarios in which the pcap+key-leak wiretapping is the only possible usable approach. That hasn't been described on the list. (It has been asserted that such scenarios exist, and it has been claimed that we should all know and accept all this already, but those were TBBA non-arguments.) Cheers, S. --vagMVSIq0bfT3GppS8igj8xsmwCd20KDK-- --wJW6KX956kiq8k94Q7StTt8o0RnhMDnSL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZaxz8AAoJEC88hzaAX42i+skH/0h7NqVT2D83ickv7oB333An PDaOHpMrEoUaCQvE/uBgY4EZzhfdcyMbEeXd8faciP9j18YkvhT1FiQ1vTfIAHio jssOSIzEnYB+yYPwgA2OMFV3M06NvofmQxUyc0wBHaI7djtMjbyP2P3xHyXUZDMy wHOPUA7yfVDJv5cpxVkArrLpOf9o8IaQLH8DlcpPk6n0sozsWaBI5kHyGjqAkaGj YiEVlF7rAYLtaNInKGA53FNEqGZbelJyA5W/gOI/pN8PU2v4UW3WQmBm5NAh2V5g JJ8z9wtKdk42tyf6tE5o4h8UK47oP57hM8pjTrSmCM6o6HD5ituRNLT9Jkon6Do= =mzIv -----END PGP SIGNATURE----- --wJW6KX956kiq8k94Q7StTt8o0RnhMDnSL-- From nobody Sun Jul 16 01:20:48 2017 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 65607131787 for ; Sun, 16 Jul 2017 01:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7a5aty-pJDO for ; Sun, 16 Jul 2017 01:20:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122D712EC57 for ; Sun, 16 Jul 2017 01:20:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 455C7BE58; Sun, 16 Jul 2017 09:20:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ8z-Gu0ysK4; Sun, 16 Jul 2017 09:20:40 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92D09BE56; Sun, 16 Jul 2017 09:20:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500193240; bh=FkJPlqAlpa8bK5xcVPOavF9Py5z2TIEuKqltA9QH/og=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EQVvJYcXx5OWxT9ZLAo5EvtOiONcVOTyoeNbwHwxKQSmHJmSOFokSYbZNLBtm73qy /KkoJdXcGwLcNEb7PCr0tSLur4Q/Zurc+LdtR0M4U5AhRnXX/m2wcZ9PhfDqXLv/cM /Cb9ayWWXvVUn/88SQuRNVGDwKtIxS8qNmEQeP8Q= To: Roland Zink , tls@ietf.org References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 16 Jul 2017 09:20:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GoBuCxPteAlrwjfrdfM8bjEO7W7DMqX3L" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 08:20:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GoBuCxPteAlrwjfrdfM8bjEO7W7DMqX3L Content-Type: multipart/mixed; boundary="eBcIveCkn0I01E4Fta0fffo8FlfpNFAru"; protected-headers="v1" From: Stephen Farrell To: Roland Zink , tls@ietf.org Message-ID: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> In-Reply-To: --eBcIveCkn0I01E4Fta0fffo8FlfpNFAru Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 15/07/17 20:49, Roland Zink wrote: > TLS is a two endpoint protocol. It looks like many of the use cases > describe problems with more than two endpoints but are using TLS becaus= e > it is commonly available. So should TLS be extended to be an n-party > protocol (or is this always considered wiretapping?) or should be there= > another protocol or something else? Yes, if one wants different semantics than TLS and needs an entirely different interface for applications, (which all N>2 party protocols do need) then one needs to define a different protocol that is not TLS. Of course, that's impractical, so people will continue to ignore the fact that they're doing bad engineering and will come along now and then and try convince us to break TLS. Cheers, S. >=20 >=20 > Regards, >=20 > Roland >=20 >=20 >=20 > Am 15.07.2017 um 19:34 schrieb Colm MacC=C3=A1rthaigh: >> >> >> On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor >> > wrote: >> >> * This proposed TLS variant is *never* acceptable for use on the >> public >> Internet. At most it's acceptable only between two endpoints >> within >> a datacenter under a single zone of administrative control. >> >> >> * Forward secrecy is in general a valuable property for encrypted= >> communications in transit. >> >> >> If there's anyone on the list who disagrees with the above two >> statements, please speak up! >> >> >> I agree with the second statement, but I don't really follow the logic= >> of the first. On the public internet, it's increasingly common for >> traffic to be MITMd in the form of a CDN. Many commenters here have >> also responded "Just use proxies". I don't get how that's better. >> >> A proxy sees all of the plaintext, not just selected amounts. All of >> the same coercion and compromise risks apply to a proxy too, but since= >> it undetectably sees everything, that would seem objectively worse >> from a security/privacy risk POV. >> Or put another way: if these organizations need to occasionally >> inspect plaintext, would I prefer that it's the kind of system where >> they have to go pull a key from a store, and decrypt specific >> ciphertexts on demand offline, or do I want them recording plaintext >> *all* of the time inline? It seems utterly bizarre that we would >> collectively favor the latter. We end up recommending the kinds of >> systems that are an attacker's dream. >> >> Here's what I'd prefer: >> >> * Don't allow static DH. In fact, forbid it, and recommend that >> clients check for changing DH params. >> * For the pcap-folks, define an extension that exports the session >> key or PMS, encrypted under another key. Make this part of the >> post-handshake transcript. >> * pcap-folks can do what they want, but clients will know and can >> issue security warnings if they desire. Forbiding static DH enforces >> this mechanism, and we can collectively land in a better place than we= >> are today. >> >> --=20 >> Colm >> >> >> _______________________________________________ >> 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 --eBcIveCkn0I01E4Fta0fffo8FlfpNFAru-- --GoBuCxPteAlrwjfrdfM8bjEO7W7DMqX3L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZayHYAAoJEC88hzaAX42i7A8H/j3wuEH19VgHgtGHfpfjngOT dsxiQNUG4uj7AovSmjMLLdG9Sw/Gp+Y/1HWc0fzd13JsGZQk3nWUN5fPnN7V8s4M kXG/iJZ0vXsGMvKbRghlEyeQjPIOMNSeCZwhYxux8VUOaA0LuVA7BmETB31QnoGP twRLVdrdPSN8OUnRNVtrXge7u8mQ120ma+VIOlTCLna5CofIVeyr1CX7ta29EjjF u2o3xgJIzTIlNbunps9ZQppcSZVwskXQuRFkjqIGit77SYCrAoJO23G+hmQyDilL CEAkc/TtE8RMCjqydSjfLa8rfm8GNgPm+TmLLPVRfHro72U4AoeDyIYm9KsYhrw= =H4ee -----END PGP SIGNATURE----- --GoBuCxPteAlrwjfrdfM8bjEO7W7DMqX3L-- From nobody Sun Jul 16 01:37:35 2017 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 C7DAE1317CC for ; Sun, 16 Jul 2017 01:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 h_eZPZmtYqjM for ; Sun, 16 Jul 2017 01:37:32 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002: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 ECF3712EC57 for ; Sun, 16 Jul 2017 01:37:31 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id k7so719141ybj.3 for ; Sun, 16 Jul 2017 01:37: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=pcuuO1bETmJBonIjZveXfKUqZ12cIHweQJavUG8Gevs=; b=SCkutVS3y/szXWlL7Y185NVrR8kPmvTLcWF0BQvKBXflByQdXStGrJ8/2vngDeLj+0 0VHdKeIxwrgyXctBkEPObqJGqqzFXD5Sx62dBAKVCqYMxnAQLabkcfrX7b/tLYxsfBhT 0OGOPswDuMf9RvJlNDuH6nNY2HZP+qARfAQOki0ZmKLfSKrfO7OF8zHNm4AojY5rGcCM 57TcoHquqwHAYbWa/BTTHyKgqWLKBzQe0yJCPBVzp0R4ZudlGOCBC6XSx9Bua4iwxBYW Qux6w6oHYPBUF+aMoQm1YXA7XBv0PAk4K6DVp7lz8ZytyzDBS8X3awJWT6iHdDG9CMeu Hr4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pcuuO1bETmJBonIjZveXfKUqZ12cIHweQJavUG8Gevs=; b=SRP9vL7mbmzJbrVvomDSxj8zfZNOo2rLg0OmylaQZ7z/+kD0AhawYCC9JyCiIzQY/T CVqq1x+ZHVeyNsMlkYwEpoJ518ia1kPTh2RxCiRBY8l1Pt8JxTZVhk0cmbeFnz8FEPqS V9jVBeRkflo19Zf0niRF+pcmNn9UVCJbV1PbE+UUaGpKlIS7C2nXjUMSeF4FxCrDBMzG Q1WOt0weeQy01mvn6Esa7RBE6gkut7JnJY4d8bd20zeNeJc82e9Sx8qc6E1K//oFY/q/ 4R6dk2YgwKUyATW6OYi5BSP7hFSrZG8i6xUGquz84TnzI4tw7lZsRjs+iv4l8kNr4JOa DBBg== X-Gm-Message-State: AIVw110qt+nwnnFVXBLNYpSAUwZfVmOMnN9m2m6JCmzyZSdFjBECNuLC elJn1HU4xfoG3EhtScqPhn1Ba+HeqnuUt1s= X-Received: by 10.37.76.193 with SMTP id z184mr12946899yba.34.1500194251137; Sun, 16 Jul 2017 01:37:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.27.4 with HTTP; Sun, 16 Jul 2017 01:37:30 -0700 (PDT) In-Reply-To: <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sun, 16 Jul 2017 01:37:30 -0700 Message-ID: To: Stephen Farrell Cc: "Salz, Rich" , "tls@ietf.org" , Matthew Green Content-Type: multipart/alternative; boundary="001a113e7df46efbca05546b31ca" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 08:37:34 -0000 --001a113e7df46efbca05546b31ca Content-Type: text/plain; charset="UTF-8" On Sun, Jul 16, 2017 at 12:59 AM, Stephen Farrell wrote: > > (*) I am not asking that people tell me that "pcap+key-leaking" > might work, but for them to describe when that works but nothing > else works. And that has to include the details of what it is > they can only find in the recovered cleartext that cannot be > detected without access to cleartext using this particular > method. > Of course other techniques could work, every system involved from the network devices to the endpoints is practically Turing complete. For me, the more interesting question is really whether the providers/users are likely to take on the costs of doing it differently, or wether they are more likely to block TLS1.3 and stay on legacy crypto. Given everything I've read, I think the latter is more likely. > Are you skeptical that existing network operators don't do this kind > > of decryption? > > I believe that people do this kind of key-leak+pcap decryption. > > People do all sorts of other unwise things too (myself included, > and fairly frequently;-), that is not a reason to encourage more > of "it" for any "it." > Well, they have the keys, and they have the desire, so I expect them to do it by some means. The question then becomes not about promoting or encouraging it, but how we may limit the damage and achieve the best outcome. I don't understand how proxies are a better solution, as I've outlined; they have drastically worse security properties. I would also note that the "use a proxy" argument seems to me > to mostly be offered as a strawman counter-argument by folks > who would like to break TLS via static DH, and doesn't seem to > be a common argument offered by those against breaking TLS. > (Adding proxies is of course another way to break TLS, depending > on how and where it's done.) > I can't make sense of this paragraph. A static-DH solution has no need for proxies, so I'm unclear on why a static-DH proponent would suggest using them. If proxies aren't the alternative, then what is? are you suggesting none? That's the brinksmanship approach, which is valid of course, you can risk TLS1.3 adoption. And the pcap operators may flinch first, or you may. But is it really wise to ask your opponent for the evidence that they won't flinch first? > > I'm not skeptical of that at all, but would be interested in what > > acceptable evidence would look like. > > I'm not sure of the phrase "acceptable evidence" but regardless > of that: > > TLS is an important protocol, extremely widely used. For any attempt > to weaken or break TLS, I think the onus is on the proponents of the > break-TLS proposal to produce convincing evidence that their scheme > will at least be a net positive, considering the entire ecosystem > that is dependent on TLS. And even if there is evidence that a scheme > would be a net positive, it may still be a bad idea, if the negative > aspects of the scheme have serious enough impacts in some use-cases > for TLS. > > That's a pretty high bar, yes. And so it should be. I'm not at all > clear it can be cleared, ever. > Real world: They have the keys, so they can break FS by using proxies if they want. If they do that, and they likely would, everyone is much /worse/ off because now there's less FS, more plaintext floating around, and more exploitable software floating around. Is that really a sensible outcome? > > > Though I'll point out again: TLS 1.3 is the new thing that we want > > to gain adoption, so really we should be looking for evidence that > > it's /not/ a burdensome change. > > Sure, that is another fine thing to do. It'd be helped along if we > had evidence about the precise scenarios in which the pcap+key-leak > wiretapping is the only possible usable approach. That hasn't been > described on the list. (It has been asserted that such scenarios > exist, and it has been claimed that we should all know and accept > all this already, but those were TBBA non-arguments.) > Imagine you're blindfolded, with your finger on a button that fires a gun. The gun might be pointed at you, it might be pointed at your opponent. Your opponent has no blindfold. Your argument is "Tell me if the gun is pointed at me or I'm going to push the button". Now if the gun is pointed at them, can you really trust them? And if it's pointed at you, why should they care to help you out? -- Colm --001a113e7df46efbca05546b31ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 16, 2017 at 12:59 AM, Stephen Farrell <= ;stephen.far= rell@cs.tcd.ie> wrote:
(*) I am not asking that people tell me that "pcap+key-leaking" might work, but for them to describe when that works but nothing
else works. And that has to include the details of what it is
they can only find in the recovered cleartext that cannot be
detected without access to cleartext using this particular
method.

Of course other techniques coul= d work, every system involved from the network devices to the endpoints is = practically Turing complete. For me, the more interesting question is reall= y whether the providers/users are likely to take on the costs of doing it d= ifferently, or wether they are more likely to block TLS1.3 and stay on lega= cy crypto. Given everything I've read, I think the latter is more likel= y.

> Are you skeptical that existing network operators don't do this ki= nd
> of decryption?

I believe that people do this kind of key-leak+pcap decryption.

People do all sorts of other unwise things too (myself included,
and fairly frequently;-), that is not a reason to encourage more
of "it" for any "it."

Well, they have the keys, and they have the desire, so I expect them to = do it by some means. The question then becomes not about promoting or encou= raging it, but how we may limit the damage and achieve the best outcome. I = don't understand how proxies are a better solution, as I've outline= d; they have drastically worse security properties.

I would also note that the "use a proxy" argument seems to me
to mostly be offered as a strawman counter-argument by folks
who would like to break TLS via static DH, and doesn't seem to
be a common argument offered by those against breaking TLS.
(Adding proxies is of course another way to break TLS, depending
on how and where it's done.)

I can&= #39;t make sense of this paragraph. A static-DH solution has no need for pr= oxies, so I'm unclear on why a static-DH proponent would suggest using = them. If proxies aren't the alternative, then what is? are you suggesti= ng none? That's the brinksmanship approach, which is valid of course, y= ou can risk TLS1.3 adoption. And the pcap operators may flinch first, or yo= u may. But is it really wise to ask your opponent for the evidence that the= y won't flinch first?=C2=A0
=C2=A0
> I'm not skeptical of that at all, but would be interested in what<= br> > acceptable evidence would look like.

I'm not sure of the phrase "acceptable evidence" but r= egardless
of that:

TLS is an important protocol, extremely widely used. For any attempt
to weaken or break TLS, I think the onus is on the proponents of the
break-TLS proposal to produce convincing evidence that their scheme
will at least be a net positive, considering the entire ecosystem
that is dependent on TLS. And even if there is evidence that a scheme
would be a net positive, it may still be a bad idea, if the negative
aspects of the scheme have serious enough impacts in some use-cases
for TLS.

That's a pretty high bar, yes. And so it should be. I'm not at all<= br> clear it can be cleared, ever.

Real wor= ld: They have the keys, so they can break FS by using proxies if they want.= If they do that, and they likely would, everyone is much /worse/ off becau= se now there's less FS, more plaintext floating around, and more exploi= table software floating around. Is that really a sensible outcome?
=C2=A0

> Though I'll point out again: TLS 1.3 is the new thing that we want=
> to gain adoption, so really we should be looking for evidence that
> it's /not/ a burdensome change.

Sure, that is another fine thing to do. It'd be helped along if = we
had evidence about the precise scenarios in which the pcap+key-leak
wiretapping is the only possible usable approach. That hasn't been
described on the list. (It has been asserted that such scenarios
exist, and it has been claimed that we should all know and accept
all this already, but those were TBBA non-arguments.)
=
Imagine you're blindfolded, with your finger on a button= that fires a gun. The gun might be pointed at you, it might be pointed at = your opponent. Your opponent has no blindfold. Your argument is "Tell = me if the gun is pointed at me or I'm going to push the button". N= ow if the gun is pointed at them, can you really trust them? And if it'= s pointed at you, why should they care to help you out? =C2=A0
--
Colm
--001a113e7df46efbca05546b31ca-- From nobody Sun Jul 16 01:52:48 2017 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 4DB7E12EBFE for ; Sun, 16 Jul 2017 01:52:46 -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 (2048-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 frak7duGrxwk for ; Sun, 16 Jul 2017 01:52:45 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 5E43F127180 for ; Sun, 16 Jul 2017 01:52:45 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6G8puAY009332; Sun, 16 Jul 2017 09:52:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=TN/rQiWyJeNWH7QJWM/GdXx355PPAfI1kGR9TMk4tlY=; b=bqr8Np0gNCsjes5C/UBJhLxwB6Jx2aEVscwkfi+sG8JrxFYWWFU0XH0CIodSVOc2UYmF H4E3OwsvKSzzPyUf3rFBbQszMPSdiVXYupVU/AEBMpOvAy/0IkcSZWU7LKINMdbrXy7q SWS7GQZxt63H6qHdE9XqQo+5d+NhujgaCiwqYwDy+G4SBY4pLP2rLCHcMj/pV6dKFHiR O4zK9EOw95nM1G75nwtQHD6SpKuxoMRqomqyn6ql7hHBVoXaltWdlvaKnzYuFZi+j8Om 0yEHqkXJ8Z7Abgp+XGTIaZDscTi2BJ/C8YyK8pt91+PO5fofbmX1TbT7qvi/PJAU2w+G vg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bqaarkwxh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Jul 2017 09:52:38 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6G8pCeN032428; Sun, 16 Jul 2017 04:52:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecuhvuk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 16 Jul 2017 04:52:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 16 Jul 2017 04:52:36 -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.1263.000; Sun, 16 Jul 2017 04:52:36 -0400 From: "Salz, Rich" To: Stephen Farrell , =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= CC: "tls@ietf.org" , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAAga+AgAAdCICAAEOKgIAAN5MA///LkJA= Date: Sun, 16 Jul 2017 08:52:36 +0000 Message-ID: <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> In-Reply-To: <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> 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.152.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707160146 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707160146 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 08:52:46 -0000 SSB3b3VsZCBhbHNvIGxpa2UgdG8gdW5kZXJzdGFuZCB3aHkgVExTIDEuMiBpcyBub3Qgc3VmZmlj aWVudCBmb3IsIHNheSwgdGhlIG5leHQgZml2ZSB5ZWFycy4NCg0KDQo= From nobody Sun Jul 16 02:04:37 2017 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 6B2CF127180 for ; Sun, 16 Jul 2017 02:04:35 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 xfAvYK6jwjHf for ; Sun, 16 Jul 2017 02:04:34 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130DD127058 for ; Sun, 16 Jul 2017 02:04:34 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id k7so780750ybj.3 for ; Sun, 16 Jul 2017 02:04:34 -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=AaSrcgkhuwQaeLdzF9Oe4WxuOGcDh7jXY1KXJkZyR6g=; b=uWGgUU+StPI3dxIgBJ8PlsQFWaEo+2lXbSloS/7swtf/kiSqIuD0lFo6skgx/UukJN X0NaHLqPQmuw3lzHLsC8v1gshmtLUI4HiL15Rv645LalTkpMwbcKT6zP6f+AwoaxCArl amZRwaqn1Lav+KkPeyzVVwWZ5QPkoMpXsGPnU3up00gSUFKPx5HxWgqtkCe6bpFxAKY+ qVbEoUq9pPTFQVlOVRxOrpJsNjWb8NBebXjCr2fYWLd1nljyGBUSmpIqkj1IusSv7BgU GpgIhC511bavZhqNWpmm+4/FlB+OAovYlw85xdz6775z/A+KE1/n7IE8BLIhX+hQHucN vnTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AaSrcgkhuwQaeLdzF9Oe4WxuOGcDh7jXY1KXJkZyR6g=; b=FtiAM9EKRjNl6ISPcozMu3x109O09i0+4LqCIUH1j5bx5TlydxdtFU5AKlVPVQPCQs 9nQsmuw0h+AYsz+uoQN7SVE8Bc1LKuNlRuxlgf8fW6ozydRb6cgKfwXNDx7oxpgtjc/w KV/sPgNV/AygSBuICfrSQ8TLcEKFTBNSwDx1RIpSNRHeF4wkQigPoJpWBrLcLeuNzP4u u3CWaakrbEXQR52OsnmEJVSkgW6BZzOtW49bQ62ssn6zqL/d6+E6lpMc8oxOAHXz8XEl AvasnucQBexpNdDIEBi6aEaSiY9JaW91bCzD0Z7LIE1qA2wHe/mUcZXU1rooyrugM1+e 2BAg== X-Gm-Message-State: AIVw1119iSAg3/I/YIoqSKi5GGFd8WtEoUe4sDz8hFyXa/352NHvTCAV kMebejxCEDdWjjjsEmcie1bnPKJiGuf/ X-Received: by 10.37.112.4 with SMTP id l4mr13654333ybc.205.1500195873253; Sun, 16 Jul 2017 02:04:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.27.4 with HTTP; Sun, 16 Jul 2017 02:04:32 -0700 (PDT) In-Reply-To: <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sun, 16 Jul 2017 02:04:32 -0700 Message-ID: To: "Salz, Rich" Cc: Stephen Farrell , "tls@ietf.org" , Matthew Green Content-Type: multipart/alternative; boundary="001a114bb0161e859205546b9273" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 09:04:35 -0000 --001a114bb0161e859205546b9273 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 16, 2017 at 1:52 AM, Salz, Rich wrote: > I would also like to understand why TLS 1.2 is not sufficient for, say, > the next five years. > It probably is ... but isn't that the problem? If the answer is "Just let them stay on TLS1.2", I find it very hard to interpret the arguments against all of this as resulting in anything other than grand-standing. Clearly the users would be no better off, and also end up denied the other benefits of TLS1.3. This seems self-defeating, when there is so easy a path that may improve things for all cases (forbid static-DH, add an opt-in mechanism instead). -- Colm --001a114bb0161e859205546b9273 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 16, 2017 at 1:52 AM, Salz, Rich <rsalz@akamai.com> wrote:
I would also like to underst= and why TLS 1.2 is not sufficient for, say, the next five years.

It probably is ... but isn't that the problem= ? If the answer is "Just let them stay on TLS1.2", I find it very= hard to interpret the arguments against all of this as resulting in anythi= ng other than grand-standing. Clearly the users would be no better off, and= also end up denied the other benefits of TLS1.3.

= This seems self-defeating, when there is so easy a path that may improve th= ings for all cases (forbid static-DH, add an opt-in mechanism instead). =C2= =A0

--
Colm
--001a114bb0161e859205546b9273-- From nobody Sun Jul 16 02:09:09 2017 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 2159313192D for ; Sun, 16 Jul 2017 02:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 z5j96BO4sX_x for ; Sun, 16 Jul 2017 02:09:06 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 8C0BD13191C for ; Sun, 16 Jul 2017 02:09:04 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id v190so7105179pgv.2 for ; Sun, 16 Jul 2017 02:09:04 -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=U1AIinp0A8xoX74IyI0nF/rFnyPuDZs9xWhJI+1jseU=; b=HmuXOsLymWrv9OemQVUOY99Qi5qadIqronQDQWt/v4HPjetEM1fwz/5qIsny9tLNYN tu04YYz2FGXqLv/8sYyByGmxSEb6nT4d7MVlVcD5xmtZ0hYhbiCPfGFwTiG0ASXEp8AO RymvpP67XR8sJolpURTnYj0UjLBYbxMNOTMqAeXTBNUU4g5UA8bl0Y4/YAcFZ0uTiLTa cxeLgIQEbYCilL1NcuezZXhLqrZk4h6OrY+duAlHMefKLaZG7b2+Q6OdqKkBdRU5D4ZY TjgD46rgFSi5qRLTSkWdL9ZtkMD/FQJXKIAze9yQI7JNphPb14sEOBdrudVpd13p6NqN OGyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U1AIinp0A8xoX74IyI0nF/rFnyPuDZs9xWhJI+1jseU=; b=ljgl0DI4zCoJ5YiyEx/cj0p9SlZGAOeB8sQNY2AHPybMUoqljdK8RWRMb6Mq6mun29 yxra9PldfYsDEUwKcwmtuhL2Sl0Uw8NIyR0qXkjy35QfXaWid2JO9CwOIhqcFCiN6VR/ g/XmoSmiOyhkX+9I5aaqfQ6mBb4OCotChJKSPbE05PGmUZb8Ox+HUFPBMnyU8HaXEcM5 q4AJ+gTen+NWKPms5PLpVVS58mgV/IGjBzHhUN3X7MTvsNsJfYToa19tPHuEENbA5A9Y p6GATJVxmB/0ornjDkP0D2tcyZMZWyGcUCDIFC3jD3it4jqchzpxIBoA/ItIXfWz8uxM 4taw== X-Gm-Message-State: AIVw111X+nBwMfTZtd6LvKLwiaaajql24J3Pf3KP+5NMdVUTbIsEj+x8 /QKleDCo1ZH7JCrbrFsAH51rZ3xfq0gY X-Received: by 10.84.231.16 with SMTP id f16mr24877208plk.131.1500196144146; Sun, 16 Jul 2017 02:09:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Sun, 16 Jul 2017 02:08:23 -0700 (PDT) In-Reply-To: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ted Lemon Date: Sun, 16 Jul 2017 11:08:23 +0200 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: "Salz, Rich" , Matthew Green , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403043601824400cb05546ba272" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 09:09:08 -0000 --f403043601824400cb05546ba272 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What it means for users to be denied the benefits of TLS 1.3 is that they don't get, for example, perfect forward secrecy. Since the proposal was to do away with that anyway, but for all users, not just some users, that doesn't seem like it is better than just continuing to use TLS 1.2. It's already possible to configure both TLS 1.2 clients and servers to not use obsolete encryption algorithms. Most of the other improvements in TLS 1.3 probably don't apply to the use cases you are talking about. So no, it's not self-defeating to say "continue using TLS 1.2 for now in your use case while we study this issue and try to figure out if there's a way forward that doesn't break TLS 1.3." On Sun, Jul 16, 2017 at 11:04 AM, Colm MacC=C3=A1rthaigh wrote: > > > On Sun, Jul 16, 2017 at 1:52 AM, Salz, Rich wrote: > >> I would also like to understand why TLS 1.2 is not sufficient for, say, >> the next five years. >> > > It probably is ... but isn't that the problem? If the answer is "Just let > them stay on TLS1.2", I find it very hard to interpret the arguments > against all of this as resulting in anything other than grand-standing. > Clearly the users would be no better off, and also end up denied the othe= r > benefits of TLS1.3. > > This seems self-defeating, when there is so easy a path that may improve > things for all cases (forbid static-DH, add an opt-in mechanism instead). > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f403043601824400cb05546ba272 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What it means for users to be denied the benefits of TLS 1= .3 is that they don't get, for example, perfect forward secrecy.=C2=A0 = Since the proposal was to do away with that anyway, but for all users, not = just some users, that doesn't seem like it is better than just continui= ng to use TLS 1.2.=C2=A0 It's already possible to configure both TLS 1.= 2 clients and servers to not use obsolete encryption algorithms.=C2=A0 Most= of the other improvements in TLS 1.3 probably don't apply to the use c= ases you are talking about.

So no, it's not self-def= eating to say "continue using TLS 1.2 for now in your use case while w= e study this issue and try to figure out if there's a way forward that = doesn't break TLS 1.3."

=
On Sun, Jul 16, 2017 at 11:04 AM, Colm MacC=C3= =A1rthaigh <colm@allcosts.net> wrote:


On Sun, Jul 16, 2017 at 1:52 AM, Salz, R= ich <rsalz@akamai.com> wrote:
I would also like to understand why TLS 1.2 is not sufficient for, say, = the next five years.

It probably= is ... but isn't that the problem? If the answer is "Just let the= m stay on TLS1.2", I find it very hard to interpret the arguments agai= nst all of this as resulting in anything other than grand-standing. Clearly= the users would be no better off, and also end up denied the other benefit= s of TLS1.3.

This seems self-defeating, when there= is so easy a path that may improve things for all cases (forbid static-DH,= add an opt-in mechanism instead). =C2=A0

--
Colm

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


--f403043601824400cb05546ba272-- From nobody Sun Jul 16 02:15:05 2017 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 7C884127180 for ; Sun, 16 Jul 2017 02:15:03 -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, HTML_MESSAGE=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=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 qxnOR2nBUHUz for ; Sun, 16 Jul 2017 02:15:02 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2C59C127058 for ; Sun, 16 Jul 2017 02:15:02 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6G9DFqJ025473; Sun, 16 Jul 2017 10:14:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=MxeH66MZikvWe6IclLskO2rgYNYuMUrcmG2HFOyh64c=; b=caghYhZWA2NRs3WRGgD+yBboBFl6Xp8+ToK5MVZCzTy3jcz23qm7ny3OfIPNiW0WBego ik0AWOMQ0x3GR4xnjuOJ/0BtsgXUMk0wc9CUoZKJTg/diZaKoBW06jLzG+/fegOllM+O lmgDaXyQzx7/jJhWSgiEMhDp/zcJDCT2305nNE1rJojJ129l/ht8/nxoJgjI7Lz237Qw MeyK39iD8dxhMoGckCKdX3U/Za9G2Zt2n5cr8k+ihjRdbAJxQzcVK7OdG9UQOATxSE7L AtyZxVOaM6WYmozOWd6xypMzCqB/4tuzt2buPyt+9WUmnhDshScqKdQrQCVXmZWRJFwG aA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2bqbf93kth-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Jul 2017 10:14:55 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6G9B4BE011223; Sun, 16 Jul 2017 05:14:54 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecuhwq8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 16 Jul 2017 05:14:54 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 16 Jul 2017 05:14:53 -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.1263.000; Sun, 16 Jul 2017 05:14:53 -0400 From: "Salz, Rich" To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= CC: Stephen Farrell , "tls@ietf.org" , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAAga+AgAAdCICAAEOKgIAAN5MA///LkJCAAEZ9AP//vjvA Date: Sun, 16 Jul 2017 09:14:53 +0000 Message-ID: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.147] Content-Type: multipart/alternative; boundary="_000_a22d69c80d8d4cd2981cd6ede394c96fusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707160152 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707160152 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 09:15:03 -0000 --_000_a22d69c80d8d4cd2981cd6ede394c96fusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aGluIGFuIGVudGVycHJpc2UgdGhhdCBiZWxpZXZlcyB0aGV5IG5lZWQgdGhpcyBraW5kIG9m IHBhY2tldC1jYXB0dXJlLWRlY29kZSB0aGluZywgd2hhdCBhcmUgdGhlIG90aGVyIGJlbmVmaXRz IG9mIFRMUyAxLjM/ICBUaGV5IGNhbiBhbHJlYWR5IHVzZSBnb29kIGNpcGhlcnMuIFRoZXkgc2F2 ZSB0aGUgY29zdCBvZiBub3QgdXBsaWZ0aW5nIGV4aXN0aW5nIGluZnJhc3RydWN0dXJlLiBUaGV5 IGxvc2UgMFJUVCBlYXJseS1kYXRhLCB3aGljaCB3aGVuIHZpZXdlZCBnbG9iYWxseSBzZWVtcyBs aWtlIGEgcmVhc29uYWJsZSB0cmFkZS1vZmYuDQoNCkkgYW0gbXVjaCBtb3JlIGN5bmljYWwgYWJv dXQgdGhlIHZhbHVlIG9mIG9wdC1pbi4gIEkgbWVhbiwgd2hhdCBhcmUgeW91IGV4cGVjdGluZyB1 c2VycyB0byBhZ3JlZSB0bz8gIEFuZCBnbG9iYWxseSwgd2hhdCBpbmZpbml0ZXNpbWFsIHBvcnRp b24gb2YgdGhlIFdlYiBwb3B1bGF0aW9uIGNhbiBtYWtlIGFuIGluZm9ybWVkIGNob2ljZT8gIEFu ZCBvZnRlbiB0aGVyZSBpcyBubyBjaG9pY2Ug4oCTIG9uZSBvZiB0aGUgYWR2b2NhdGVzIGhlcmUg aXMgZnJvbSBhIHN0YXRld2lkZSBpbnN1cmFuY2UgY29tcGFueS4NCg0KU28gd2hhdCBpcyBjb21w ZWxsaW5nIGFib3V0IFRMUyAxLjMgYWZ0ZXIgeW91IHRha2UgYXdheSBmb3J3YXJkIHNlY3JlY3k/ ICBJIHJlYWxseSB3YW50IHRvIGhlYXIgYW4gYW5zd2VyIHRvIHRoYXQgcXVlc3Rpb24gZnJvbSBm b2xrcyB3aG8gc2F5IHRoZXkgbmVlZCBUTFMgMS4zIGJ1dCB3aXRob3V0IGl0Lg0K --_000_a22d69c80d8d4cd2981cd6ede394c96fusma1exdag1mb1msgcorpak_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldpdGhpbiBhbiBlbnRlcnByaXNlIHRoYXQgYmVsaWV2ZXMg dGhleSBuZWVkIHRoaXMga2luZCBvZiBwYWNrZXQtY2FwdHVyZS1kZWNvZGUgdGhpbmcsIHdoYXQg YXJlIHRoZSBvdGhlciBiZW5lZml0cyBvZiBUTFMgMS4zPyZuYnNwOyBUaGV5IGNhbiBhbHJlYWR5 IHVzZSBnb29kIGNpcGhlcnMuIFRoZXkgc2F2ZQ0KIHRoZSBjb3N0IG9mIG5vdCB1cGxpZnRpbmcg ZXhpc3RpbmcgaW5mcmFzdHJ1Y3R1cmUuIFRoZXkgbG9zZSAwUlRUIGVhcmx5LWRhdGEsIHdoaWNo IHdoZW4gdmlld2VkIGdsb2JhbGx5IHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHRyYWRlLW9mZi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+SSBhbSBtdWNoIG1vcmUgY3luaWNhbCBhYm91dCB0aGUgdmFsdWUgb2Yg b3B0LWluLiZuYnNwOyBJIG1lYW4sIHdoYXQgYXJlIHlvdSBleHBlY3RpbmcgdXNlcnMgdG8gYWdy ZWUgdG8/Jm5ic3A7IEFuZCBnbG9iYWxseSwgd2hhdCBpbmZpbml0ZXNpbWFsIHBvcnRpb24gb2Yg dGhlIFdlYiBwb3B1bGF0aW9uIGNhbiBtYWtlDQogYW4gaW5mb3JtZWQgY2hvaWNlPyZuYnNwOyBB bmQgb2Z0ZW4gdGhlcmUgaXMgbm8gY2hvaWNlIOKAkyBvbmUgb2YgdGhlIGFkdm9jYXRlcyBoZXJl IGlzIGZyb20gYSBzdGF0ZXdpZGUgaW5zdXJhbmNlIGNvbXBhbnkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNv IHdoYXQgaXMgY29tcGVsbGluZyBhYm91dCBUTFMgMS4zIGFmdGVyIHlvdSB0YWtlIGF3YXkgZm9y d2FyZCBzZWNyZWN5PyZuYnNwOyBJIHJlYWxseSB3YW50IHRvIGhlYXIgYW4gYW5zd2VyIHRvIHRo YXQgcXVlc3Rpb24gZnJvbSBmb2xrcyB3aG8gc2F5IHRoZXkgbmVlZCBUTFMgMS4zIGJ1dCB3aXRo b3V0DQogaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_a22d69c80d8d4cd2981cd6ede394c96fusma1exdag1mb1msgcorpak_-- From nobody Sun Jul 16 02:16:27 2017 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 EBA52127180 for ; Sun, 16 Jul 2017 02:16: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=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 XD13bnHnfMar for ; Sun, 16 Jul 2017 02:16:25 -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 0E5A3127058 for ; Sun, 16 Jul 2017 02:16:24 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id a12so38383884ywh.3 for ; Sun, 16 Jul 2017 02:16:24 -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=4tGNUnSaiK6fqAkBqsEttaQl1jD/BpiWCa7sVQgnpxk=; b=13fVcy0DpDXDTLuKcnpDFmwCfFQyZumy3nQWPRjwYnR2PYA2OUAlCROV7BoJa3aW2L 8zKK6z+CF+IvkERpllidDPlG1o+PgQC9rbDMQGV9ZzAFKEeKY1FuqGadoGtVvF6IxI0P WePn8Rlmf0HOfioTzoZ3ROM2EliwdL9gqkRZRWb/oaTTksvWuE6aERffv6fhKUQqUFyN XvxZbFhyORUeeQLJstTIpAaNZm3+8JyzrgJ2ZedIoU+oCi0WbIa9Hc6MMRuer/opXu2W RWb5Si9CBDQzAF955QWG8s1piYNAInuDbdjqjGjm1aQcXBbdo6wFFaUIomuVlZZ/IBlo 8uBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4tGNUnSaiK6fqAkBqsEttaQl1jD/BpiWCa7sVQgnpxk=; b=oujNPK9AOT+CVUngZVN/Gc4VL+ZZtUiyOqYZ5wwtaGY0Y8TsUcWPTROS0f21iE2RZy 2j1DRZvj/C0oF4TZTPUuRau9i6gAOiiYGu4z3fEYeUgzzhNP36f0bR7DdeWdH2u+Nq+m Zv8Gu7fii4u38ePvGlSs27pdMwmU/6XQy6HJIaSZqcRNHt83nMvH88UzbHiUdR6/uqLG IsChPLia/XVmjbC7V3AFX50HwEADmSFziwwdQMVl4dWfYCE2gqO6i5TZ1n6MttT8qcAg hBz8gCvaauhXPy35K42195/FSYlmjFHmGAr3NO+r9dzlLOkxhgXPPJfCKbEMLbqDlpBh 0dag== X-Gm-Message-State: AIVw112aU1vv100FPTQdMx85kSFh8AKvCq1J6Sci6UfNK/LORudr/2Ni 2U4pCE8p7yL/9/K4znJqSVkjSvuZj638 X-Received: by 10.129.57.212 with SMTP id g203mr13466566ywa.101.1500196584254; Sun, 16 Jul 2017 02:16:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.27.4 with HTTP; Sun, 16 Jul 2017 02:16:23 -0700 (PDT) In-Reply-To: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sun, 16 Jul 2017 02:16:23 -0700 Message-ID: To: Ted Lemon Cc: "Salz, Rich" , Matthew Green , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114c856e7f9f8d05546bbc04" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 09:16:26 -0000 --001a114c856e7f9f8d05546bbc04 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 16, 2017 at 2:08 AM, Ted Lemon wrote: > What it means for users to be denied the benefits of TLS 1.3 is that they > don't get, for example, perfect forward secrecy. Since the proposal was to > do away with that anyway, but for all users, not just some users, that > doesn't seem like it is better than just continuing to use TLS 1.2. > DH by default is just one benefit of TLS1.3, there are many others or else we wouldn't be shipping it with so many changes and improvements. Otherwise there would be no TLS1.3, and only a deprecation of the non-PFS cipher suites. But that plainly isn't the case. The main one I'm concerned about is me having to support non-TLS1.3 clients ;-) 1RTT key exchange is worth it alone. -- Colm --001a114c856e7f9f8d05546bbc04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 16, 2017 at 2:08 AM, Ted Lemon <mellon@fugue.com> wrote:
What it mean= s for users to be denied the benefits of TLS 1.3 is that they don't get= , for example, perfect forward secrecy.=C2=A0 Since the proposal was to do = away with that anyway, but for all users, not just some users, that doesn&#= 39;t seem like it is better than just continuing to use TLS 1.2.=C2=A0

DH by default is just one benefit of TLS1= .3, there are many others or else we wouldn't be shipping it with so ma= ny changes and improvements. Otherwise there would be no TLS1.3, and only a= deprecation of the non-PFS cipher suites. But that plainly isn't the c= ase.=C2=A0

The main one I'm concerned about is= me having to support non-TLS1.3 clients ;-) 1RTT key exchange is worth it = alone.

--
Colm
--001a114c856e7f9f8d05546bbc04-- From nobody Sun Jul 16 02:19:19 2017 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 AF99712EC57 for ; Sun, 16 Jul 2017 02:19:17 -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=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 76vrix_k4UU9 for ; Sun, 16 Jul 2017 02:19:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 ABD43127180 for ; Sun, 16 Jul 2017 02:19:16 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6G9Hb1T009148; Sun, 16 Jul 2017 10:19:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Igk8RpHVGH4B/T1O+IuNDxAURJUBpnZWiyVnVZ7Sz/Y=; b=OvYEj53B33MWEXjuHXzt0LoCrZxiisf5jjD2tzPNPk3mot+NVJGgC/9SosXyCutWtbbW JqS7CJDLU8PKKucQ9FNF88JpR1wL2FU4Bk28/dT5LZyPzkITUToAMzxF/jQLngEWA+j2 cxGQwnBAS7KibOeHaHbB5hzrgT9RKewOhWNCtWSXyqtkwSxUKmwqem77myVmvF1FjPv4 us/ru5/aFz52XPqBNw0J3uwnobT90cq3smRXH2n3j+yqxbG8s0ioOTdS3yYkjOiX7E7X NPVkpLm/RatEUjQuVZ0oIrPtouWNcpE3inPInIz/h+Dugdl2XP168iyBs8vs5Mx7Vuwl 4g== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bq84d44n2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Jul 2017 10:19:06 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6G9G7pl014090; Sun, 16 Jul 2017 05:19:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecuhwvd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 16 Jul 2017 05:19:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 16 Jul 2017 05:19:05 -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.1263.000; Sun, 16 Jul 2017 05:19:05 -0400 From: "Salz, Rich" To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Ted Lemon CC: Matthew Green , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAAga+AgAAdCICAAEOKgIAAN5MA///LkJCAAEZ9AIAAAROAgAACPID//71PwA== Date: Sun, 16 Jul 2017 09:19:04 +0000 Message-ID: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707160153 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707160154 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 09:19:18 -0000 PiBUaGUgbWFpbiBvbmUgSSdtIGNvbmNlcm5lZCBhYm91dCBpcyBtZSBoYXZpbmcgdG8gc3VwcG9y dCBub24tVExTMS4zIGNsaWVudHMgOy0pIDFSVFQga2V5IGV4Y2hhbmdlIGlzIHdvcnRoIGl0IGFs b25lLg0KDQpUaGUga2V5IHBvaW50IGhlcmUgaXMgV2l0aGluIHRoZSBlbnRlcnByaXNlLg0KDQpU aGUgYW1vdW50IG9mIHdvcmsgb25lIGRldmVsb3BtZW50IHRlYW0gaGFzIHRvIGRvLCBjb21wYXJl ZCB0byB0aGUgd29ybGQsIGRvZXNuJ3QgbWF0dGVyLg0K From nobody Sun Jul 16 02:44:41 2017 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 BB826131898 for ; Sun, 16 Jul 2017 02:44: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 rDfUO0OCGLm7 for ; Sun, 16 Jul 2017 02:44:38 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01696127058 for ; Sun, 16 Jul 2017 02:44:38 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id u5so2913979pgq.3 for ; Sun, 16 Jul 2017 02:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MImuiroAmWDXdDkk2bPm0BElozieW8O/xb9kyN+Bnf0=; b=MJPh8twUCj/UMGZkTikliJBkpc59+9+ttgWgRutZ4OjSxrxx+EEiXPTan48p5honBu QNV2thJmgckr8mkHarRouLRdSqw6FYtCxtROANNK7HzDPsHXURYhyFKiqjxaiGcqwLSr I0B+0tKMtQJJJugYQS4yhYlAV0q0L/g4HZS4JBwCUdnN1VBdyudsGdkbSrt+I3kzF25G vFsOALXTxwVUdSJV/Dq2U2vH3mLHl4K+JTY6cCcoyRto1L45ezWO1IAERv2t+796Ey99 Icfsg3Bs2uvOPmaY+hac2qV/JTBCTDuhSqHlxNskO6bjJjXco/ZEnGBVh7r8U47C5DS3 YbCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MImuiroAmWDXdDkk2bPm0BElozieW8O/xb9kyN+Bnf0=; b=pOIUcwPESgq2oSQODiuh0GouuemZD7Dta8J+iV1zVj2uhbjcvAKsi11+HR+v2mk4LN v7DYTYRGe4yWKJkuogRblbDQ5lxsJ8UKHTBN5ov6cTRYoUgi0FJV/ljwagthrgBpzgzS Skso1fEOuGrKOGLczd9jMhZwT07/ArAg9QdVSImQmvviRrOKvzZa41TfPGgrx14fKzVS ggc9w26pZyfP5GtZyP/JpvmgwMLES+OEvYjuRI/eWBv4Z8RFKue4xwKbZAv1FStgyeW7 2Kyw3lpF/tSdRqeIEJky6JqXgce//ERlXBgayDJTxemsY71tyNClCy9kzo1Rah+jiIex ZpYA== X-Gm-Message-State: AIVw112C85vuIC8zL0S5TRZ5pJyRRy8Ip/XRIm8X2Ee/TFtn4itdSlB7 5p2OHoqNyo+OJoth6AEPsRGjHegM0Q== X-Received: by 10.84.149.139 with SMTP id m11mr12082115pla.266.1500198277609; Sun, 16 Jul 2017 02:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.193 with HTTP; Sun, 16 Jul 2017 02:43:56 -0700 (PDT) In-Reply-To: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> From: Kathleen Moriarty Date: Sun, 16 Jul 2017 05:43:56 -0400 Message-ID: To: "Salz, Rich" Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , Matthew Green , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 09:44:40 -0000 On Sun, Jul 16, 2017 at 5:14 AM, Salz, Rich wrote: > Within an enterprise that believes they need this kind of > packet-capture-decode thing, what are the other benefits of TLS 1.3? The= y > can already use good ciphers. They save the cost of not uplifting existin= g > infrastructure. They lose 0RTT early-data, which when viewed globally see= ms > like a reasonable trade-off. My guess is that industries interested in the DH key proposal would want 0-RTT. I think they would want to prevent replay attacks and might even see configuration errors of this as a risk (allowing 0-RTT inadvertently). > > > I am much more cynical about the value of opt-in. I mean, what are you > expecting users to agree to? And globally, what infinitesimal portion of > the Web population can make an informed choice? And often there is no > choice =E2=80=93 one of the advocates here is from a statewide insurance = company. > > > > So what is compelling about TLS 1.3 after you take away forward secrecy? = I > really want to hear an answer to that question from folks who say they ne= ed > TLS 1.3 but without it. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen From nobody Sun Jul 16 02:45:34 2017 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 B5332131761 for ; Sun, 16 Jul 2017 02:45: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, 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 0tgA1pB2mrda for ; Sun, 16 Jul 2017 02:45:32 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D538127058 for ; Sun, 16 Jul 2017 02:45:32 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id t72so72279974lff.1 for ; Sun, 16 Jul 2017 02:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fw8JMM0I11OmmTnt/Hu8LCqnL1N21Mnfbak7mwYPoLY=; b=gZTMWn0K/jsByiP/iUUaDt8lQgINuz9/1rM2axPW0Hf+1C5YV4lSuiqQbbZ//cWgJj ujC/XpBeEsIYeSQhqEVlKowCj4BeU15hTE9t+R1kv0VH0dB7EVfNXQ3HWlYUQIsvbYL4 2pz05FAoXGPkEpNk+BZefvVfYo+KtVLVCK9H6TTsHbDMJjMXNGrGglxajEu+kxnbnr4z ET720XIVvU7IZlFxsJlLP/7NXvX+FLW8mvsJtXSn19zz1M2vEuZoLjg64SnvcczdDA8g jpSmhUymK/dyV0ryjVzE7Zi7nH51g36GYJdpOsWKYY8J0loLupRbLmZ/baCP+rNi/+Pw x5Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=fw8JMM0I11OmmTnt/Hu8LCqnL1N21Mnfbak7mwYPoLY=; b=LnNKGovT7W/DOsd69wOOMw0skfP+gJD9xYhJWGvrrwJ6A/8HR0j8CBzMwE74+zSYo4 iVjXlGBMEWVxOB4VpWHhB4DJBLBGiMSDIS5ljz2gakNvTSr8IBmzLZr54AxQgXYMDdaX 8I0F6jS9JMEel70rLuUCENDM1tqOWzSaFCn7Pa2Ysh0rSt+ZlPnTYXR4RY1tgJVpe/qn ZOKLOaL3Tb5yZHA4na+fQnFQZfpUVfNdgY+lH1YltqS1yXZ+TJtAV/rlevYIMPVrDijU H7trnD18w77cAEeq0T+HJ7MzzqzkLMyq7JqQrkZSF0nfhWYY16GHEOdw3sdfYP8Mt5YN j26w== X-Gm-Message-State: AIVw110Jr0tDNXhbeyO9x7X6zjrCdPgoEW2ZTsPLn43Wf7ZNXUkRxkVv 2M2DwKZjfaaDnA== X-Received: by 10.46.83.14 with SMTP id h14mr3477122ljb.102.1500198330757; Sun, 16 Jul 2017 02:45:30 -0700 (PDT) Received: from localhost (95-161-3-159.broadband.spb.TiERA.org. [95.161.3.159]) by smtp.gmail.com with ESMTPSA id y10sm2982063lja.49.2017.07.16.02.45.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 16 Jul 2017 02:45:29 -0700 (PDT) Date: Sun, 16 Jul 2017 12:44:04 +0300 From: Wartan Hachaturow To: Daniel Kahn Gillmor Cc: "Dobbins, Roland" , Matthew Green , IETF TLS Message-ID: <20170716094404.sybnpu24l22uuaxb@minsvyaz.ru> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <871spirljc.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871spirljc.fsf@fifthhorseman.net> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 09:45:33 -0000 On Sat, Jul 15, 2017 at 01:23:35PM +0200, Daniel Kahn Gillmor wrote: > > Not to mention the security & troubleshooting applications which > > require insight into the cryptostream on the wire. > > I asked for examples of regulations that specifically require plaintext > from the network. Some countries has got that kind of requirements in the lawful interception context, in the sense that monitoring is explicitly required to be fully passive. However, this mostly means "network equipment that supports some kind of encryption on the link should be able to pass the traffic in plaintext for monitoring purposes". -- Regards, Wartan. From nobody Sun Jul 16 03:10:44 2017 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 31284120725 for ; Sun, 16 Jul 2017 03:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liQiFIG5hM2k for ; Sun, 16 Jul 2017 03:10:40 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (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 30F641300CE for ; Sun, 16 Jul 2017 03:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500199827; l=11559; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:Cc:To: Subject; bh=50vGd/bjuZLsAC5qWf05Rvsc+ybPfzPsiI4CalQ+gis=; b=lHxXvzWTn46w+KFk00O4QIrB2qwM5MsJXuZE62My6oeNcHRjNDKzm1acHmPhcjk+ot TH16f4i/B+wdYbvecLyCwB+PhzKQklXNfQPYmjCliOq6+iA9qk6+xUmqHwL0D6EMGT+o 2DrgbCEL3zN0kpOPOPDkZT6oNHYrhcPpoJALM= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JRiIT76qfE= X-RZG-CLASS-ID: mo00 Received: from [10.10.10.91] (p5DCF48F8.dip0.t-ipconnect.de [93.207.72.248]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id L01bc0t6GAAPqfy (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sun, 16 Jul 2017 12:10:25 +0200 (CEST) To: Watson Ladd Cc: tls@ietf.org References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <860cd103-4e40-3f6f-1a3e-be9a6513c86c@zinks.de> From: Roland Zink Message-ID: Date: Sun, 16 Jul 2017 12:10:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------82184637976CE07E747ECE38" Archived-At: Subject: Re: [TLS] Fwd: draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 10:10:43 -0000 This is a multi-part message in MIME format. --------------82184637976CE07E747ECE38 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Am 16.07.2017 um 00:07 schrieb Watson Ladd: > > > On Jul 15, 2017 12:33 PM, "Roland Zink" > wrote: > > see inline > > Roland > > > Am 15.07.2017 um 03:40 schrieb Watson Ladd: > > On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins > > wrote: > > On 15 Jul 2017, at 1:01, Melinda Shore wrote: > > It might make sense to kick it over to ops for a > discussion with people whose meat and potatoes is > monitoring, management, and > measurement. > > > As someone who is ops-focused, I think this is an > excellent suggestion! > > There have been several assertions posted to the list > recently regarding various aspects of security and their > intersection with encryption. It may be useful to take a > moment and clarify a few of them. > > With regards to DDoS mitigation as it relates to encrypted > attack traffic, only a subset of attacks in a subset of > situations can actually be adequately mitigated without > full visibility into (and often the ability to interact > with) the traffic within the cryptostream. There are > various ways to approach this issue, including full > session termination and 'transparent' > detection/classification, the latter of which isn't of > course feasible in a PFS scenario. Each of these general > approaches has its advantages and drawbacks. > > > DDoS mitigation can be done at endpoints, and indeed has to be > given > that other tools do not know which endpoints need to be > rate-limited > or are expensive. A lot of distinct things are being crammed > together > into DDoS, and the fact is endpoints can deal with application > layer > attacks via rate-limits, CAPTCHAs, and other techniques, while > not-application layer attacks don't require visibility to > defeat. What > can a middlebox do that an endpoint cannot? Globbing a bunch of > distinct things together is not helping the debate. > > One thing which can be done is identifying the sources and > notifying the owner of the devices so they can be cleaned. > > > How does an endpoint not know the source? An endpoint has information about the source IP address. It may not have an IP adress before NAT, email adress, postal adress or information about building / desk number. A middle box having more exact information about the source may notify the source owners which often are victims themselves. > > > In many scenarios, one form or another of network-based > visibility into encrypted traffic streams within the span > of administrative control of a single organization is > legitimate, vital and necessary. It is not 'wiretapping', > any more than tools such as tcpdump or telemetry formats > such as IPFIX and PSAMP can be categorized as > 'wiretapping'. The fact is, the availability, > confidentiality, and integrity of systems, applications, > and networks that everyone on this list relies upon is > highly dependent upon the ability of organizations to have > visibility into encrypted traffic streams within their own > networks, for purposes of security as well as testing and > troubleshooting. > > > How this can be accomplished is a matter for further > discussion. But it's important that everyone focused on > this topic understands that it is simply not possible to > successfully defend against many forms of DDoS attacks nor > to detect and classify hostile network traffic in the > context of encrypted communications without visibility > into the traffic in question, via some mechanism. The > same goes for troubleshooting complex problems. > > Which DDoS attacks specifically? And if the traffic isn't hitting > endpoints, does it matter? > > Yes, DDoS cause damage to dumb networks in between as well. > > > I'm not talking DDoS. I'm talking attack traffic. You need to talk > about specifics you cannot solve other ways. DDOS isn't specific enough. I was not talking about how it could be detected or prevented only that it matters before it is hitting the endpoint and if there is a way to avoid it then it should be avoided. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --------------82184637976CE07E747ECE38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 16.07.2017 um 00:07 schrieb Watson Ladd:


On Jul 15, 2017 12:33 PM, "Roland Zink" <roland@zinks.de> wrote:
see inline

Roland


Am 15.07.2017 um 03:40 schrieb Watson Ladd:
On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 15 Jul 2017, at 1:01, Melinda Shore wrote:

It might make sense to kick it over to ops for a discussion with people whose meat and potatoes is monitoring, management, and
measurement.

As someone who is ops-focused, I think this is an excellent suggestion!

There have been several assertions posted to the list recently regarding various aspects of security and their intersection with encryption.  It may be useful to take a moment and clarify a few of them.

With regards to DDoS mitigation as it relates to encrypted attack traffic, only a subset of attacks in a subset of situations can actually be adequately mitigated without full visibility into (and often the ability to interact with) the traffic within the cryptostream.  There are various ways to approach this issue, including full session termination and 'transparent' detection/classification, the latter of which isn't of course feasible in a PFS scenario.  Each of these general approaches has its advantages and drawbacks.

DDoS mitigation can be done at endpoints, and indeed has to be given
that other tools do not know which endpoints need to be rate-limited
or are expensive.  A lot of distinct things are being crammed together
into DDoS, and the fact is endpoints can deal with application layer
attacks via rate-limits, CAPTCHAs, and other techniques, while
not-application layer attacks don't require visibility to defeat. What
can a middlebox do that an endpoint cannot? Globbing a bunch of
distinct things together is not helping the debate.
One thing which can be done is identifying the sources and notifying the owner of the devices so they can be cleaned.

How does an endpoint not know the source?

An endpoint has information about the source IP address. It may not have an IP adress before NAT, email adress, postal adress or information about building / desk number. A middle box having more exact information about the source may notify the source owners which often are victims themselves.



In many scenarios, one form or another of network-based visibility into encrypted traffic streams within the span of administrative control of a single organization is legitimate, vital and necessary.  It is not 'wiretapping', any more than tools such as tcpdump or telemetry formats such as IPFIX and PSAMP can be categorized as 'wiretapping'.  The fact is, the availability, confidentiality, and integrity of systems, applications, and networks that everyone on this list relies upon is highly dependent upon the ability of organizations to have visibility into encrypted traffic streams within their own networks, for purposes of security as well as testing and troubleshooting.


How this can be accomplished is a matter for further discussion.  But it's important that everyone focused on this topic understands that it is simply not possible to successfully defend against many forms of DDoS attacks nor to detect and classify hostile network traffic in the context of encrypted communications without visibility into the traffic in question, via some mechanism.  The same goes for troubleshooting complex problems.
Which DDoS attacks specifically? And if the traffic isn't hitting
endpoints, does it matter?
Yes, DDoS cause damage to dumb networks in between as well.

I'm not talking DDoS. I'm talking attack traffic. You need to talk about specifics you cannot solve other ways. DDOS isn't specific enough.
I was not talking about how it could be detected or prevented only that it matters before it is hitting the endpoint and if there is a way to avoid it then it should be avoided.



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


--------------82184637976CE07E747ECE38-- From nobody Sun Jul 16 03:38:08 2017 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 DF0DC12EBF9 for ; Sun, 16 Jul 2017 03:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 5Fej4jQ1_ZJ1 for ; Sun, 16 Jul 2017 03:38:04 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 02EAB129B62 for ; Sun, 16 Jul 2017 03:38:03 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 214DB1C1886 for ; Sun, 16 Jul 2017 05:38:03 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id D9B051C183A; Sun, 16 Jul 2017 05:38:01 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A535B92057; Sun, 16 Jul 2017 06:38:01 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8023192053; Sun, 16 Jul 2017 06:38:01 -0400 (EDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (unknown [207.46.163.22]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Sun, 16 Jul 2017 06:38:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sA++iKV5mXjC6hgCVRuDK+IPnO3p8jfQFIcdB9Yc+G8=; b=7Xa0YLAanJ9QyjXi6jfJIQMIfN/lNYZbahfCZIIhtLj9YLKrNxb+ZT+7Z7w3EMppF9DYyOuEH9TBe77jgdOkWbTx90fe8FIj2jPiDkSGYFcwZ57+pHsePExdPh9kMzI2hqxotPI2DbdXlpbsjv7m76FzzFaaM2AlQh3FsOWp+HA= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1366.namprd14.prod.outlook.com (10.172.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sun, 16 Jul 2017 10:38:00 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.023; Sun, 16 Jul 2017 10:37:59 +0000 From: "Ackermann, Michael" To: Stephen Farrell , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , "Salz, Rich" CC: "tls@ietf.org" , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJKcO0AgAkO1QCAAPElgIAAA/YAgAC+XICAABt7AIAAPk+AgAAdB4CAAJSccA== Date: Sun, 16 Jul 2017 10:37:59 +0000 Message-ID: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> In-Reply-To: <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.0.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1366; 20:R0IbPxxUv9QL7EjnqX+MbdxT2OxYesmPI08kVILbnIin9YtbMnfQI5obQrqMQo/+sLKZYPMVyCPkDN+LJwI5+81kAfCBs0PypcJob9TOqlErTDcajWI9vP1Wamp7RSgGebOs8ZXRBEZRXsAzvM4XdyXEOZgIahji09yLej/BdeU= x-ms-office365-filtering-correlation-id: 878f6f74-596d-4ab9-2fac-08d4cc36baaf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1366; x-ms-traffictypediagnostic: CY4PR14MB1366: x-exchange-antispam-report-test: UriScan:(236129657087228)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1366; x-forefront-prvs: 03706074BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39830400002)(39410400002)(13464003)(377454003)(24454002)(54906002)(55016002)(99286003)(9686003)(102836003)(6116002)(4326008)(3846002)(50986999)(54356999)(25786009)(39060400002)(38730400002)(6246003)(230783001)(93886004)(189998001)(66066001)(53936002)(76176999)(6436002)(7736002)(2950100002)(33656002)(2900100001)(7696004)(3280700002)(6506006)(3660700001)(77096006)(229853002)(478600001)(8936002)(74316002)(86362001)(5660300001)(53546010)(14454004)(81166006)(8676002)(72206003)(80792005)(305945005)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1366; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2017 10:37:59.7104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1366 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 9744a140-ae6c-42ce-90e1-230ca6b71d64 X-VPM-MSG-ID: 260a293e-2c2a-43d7-87a5-d30869ca3b27 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 10:38:06 -0000 It seems that us Enterprise folks have not been clear. =20 Every Enterprise I know has invested HEAVILY in infrastructures that tap, = transport and process terabytes of packet trace or .pcap data every day. = =20 This is huge and omnipresent in all large Enterprise environments. =20 AND IT WORKS=21 For a number of critical functions. =20 The above is why Enterprises are interested in this issue and this Draft. = =20 I hope this is clear?=20 -----Original Message----- From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Stephen Farrell Sent: Saturday, July 15, 2017 8:39 PM To: Colm MacC=E1rthaigh ; Salz, Rich = Cc: tls=40ietf.org; Matthew Green Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 On 15/07/17 23:55, Colm MacC=E1rthaigh wrote: > So far responses on the mailing list have been saying =22Don't use = pcap,=20 > instead run proxies=22. Sorry, but that is incorrect. Some list participants have said =22we need = pcap=22 and others have said that =22no, we do not need to use packet = capture.=22 And others, myself included, consider that there is dearth of = evidence. The only reason to point that out is that it's one amongst a pile of = statements from the proponents of drafgreen, that make assumptions that = are pretty clearly counter-factual. S. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Sun Jul 16 03:56:01 2017 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 97C5012EC4B for ; Sun, 16 Jul 2017 03:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 Z4vmsaltJZSj for ; Sun, 16 Jul 2017 03:55:56 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 A0A86126B6E for ; Sun, 16 Jul 2017 03:55:56 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 5534AC15C3 for ; Sun, 16 Jul 2017 05:38:30 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 4136AC14EB; Sun, 16 Jul 2017 05:38:29 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 000F492057; Sun, 16 Jul 2017 06:38:28 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BDC6C92053; Sun, 16 Jul 2017 06:38:28 -0400 (EDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (unknown [207.46.163.17]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Sun, 16 Jul 2017 06:38:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2rQFo3Iq5xuhJ1yS9Chha8Fw3qtvlscuFl4b9/5/0VU=; b=yo1If/suPN3XpeVl3L6g5aWX0Xx6JFEGPSsBuFjcesF39FOd2oLws1WdyJteEokVXFurNhlari6M7EvXlo0j+YEhBchatVentxbztbYRi6hIGNQ9rKS+SIhllL+Yivfw/WvxM9yr1eyJq50Fuoc4ywjhaVPTuBsygBDijStdtsE= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1366.namprd14.prod.outlook.com (10.172.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sun, 16 Jul 2017 10:38:27 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1240.023; Sun, 16 Jul 2017 10:38:27 +0000 From: "Ackermann, Michael" To: Watson Ladd CC: Matthew Green , "Dobbins, Roland" , IETF TLS Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8RCuLDt7dBiEuHKxJZjnlNtqJIVJcAgAA7lACAAB2RAIAABXEAgAABDQCAABZYAIALriyAgAAVWACAAAFKgIAAAg+AgAADOACAAHw4YIAAKnSAgAADSxCAABPIAIAAAzvggAA65gCAAKvcwA== Date: Sun, 16 Jul 2017 10:38:27 +0000 Message-ID: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> <46888EEF-750B-46CF-BA77-1827DD6D3607@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.0.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1366; 20:Js7dOvHHbmLd2WAePwCpxsQXGWcKOLKqybS87ox1pPsd+u0ftmYhiO0nJys/GYZk5TgewFNlOVV85LakOOaQcspQSoZkb2a5duoX8/Rn/b+vRLQNxKvttC6ShkqA8O5gKL+abdA9elJ7lEwn4VdCA3eyRQPW5XCtn+XtqbAHHP0= x-ms-office365-filtering-correlation-id: dbd1e274-c737-4d91-341c-08d4cc36cb20 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1366; x-ms-traffictypediagnostic: CY4PR14MB1366: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(90097320859284)(48057245064654)(148574349560750)(21748063052155)(86572411397741)(266576461109395)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1366; x-forefront-prvs: 03706074BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39400400002)(39830400002)(39410400002)(51914003)(377454003)(43784003)(85714005)(24454002)(54906002)(55016002)(99286003)(9686003)(236005)(102836003)(6116002)(4326008)(54896002)(3846002)(6306002)(790700001)(50986999)(54356999)(25786009)(39060400002)(38730400002)(110136004)(606006)(6246003)(230783001)(93886004)(189998001)(66066001)(53936002)(1411001)(76176999)(6436002)(7736002)(2950100002)(33656002)(6916009)(2900100001)(7696004)(3280700002)(6506006)(3660700001)(77096006)(229853002)(478600001)(8936002)(74316002)(86362001)(5660300001)(53546010)(14454004)(81166006)(8676002)(72206003)(966005)(80792005)(2906002)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1366; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368F87EBDF64B2340535356D7A30CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2017 10:38:27.2076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1366 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: e6df6080-534a-4975-b405-31793bcd78e8 X-VPM-MSG-ID: 0340e731-28ab-4931-9b3a-3a5caccd5c2a X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 10:55:59 -0000 --_000_CY4PR14MB1368F87EBDF64B2340535356D7A30CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the clarification Watson. I am always looking to learn new tricks and was hoping you might had one = for distributed, large scale, remote packet captures. This is one area = we have yet to fully conquer. What you describe is something different, but also valuable and useful. But the best thing you illustrate, IMHO, is that none of these = techniques or tools is a panacea. We need many arrows in our quivers = to do an effective job of managing todays networks. Thanks again Mike From: Watson Ladd =5Bmailto:watsonbladd=40gmail.com=5D Sent: Saturday, July 15, 2017 7:08 PM To: Ackermann, Michael Cc: Matthew Green ; Dobbins, Roland = ; IETF TLS Subject: RE: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017 12:39 PM, =22Ackermann, Michael=22 = > wrote: I would be interested in how you initiate the traces at all the hundreds = of thousands of servers and clients and how you control the flow of pcap = files back to where they need to be processed? How are users and apps = not impacted? Currently I work at Cloudflare, not in ops. It's possible some of what I = say is wrong. We don't collect all traces if I understand what you mean by trace as a = packet capture. I misread your email. No technology I know of would make = that possible at our scale. We do log a significant amount of information on requests and our = responses include headers that indicate the path taken through the = system.(the cf-ray you see when some sites fail behind us) We can quickly = determine what went wrong if something did through internal inspection = tools starting from those id's and problematic requests. This works to identify, isolate, and fix problems in a complex system with = multiple internal services. This architecture scales to what we estimate as x% of all HTTP requests. = Not x% of what we see, but of all of them. ( the x is sizeable) The logging is done with open source log collection software. Because = packet capture and later decryption was not an option we created other = tools. I don't know about internal app troubleshooting. Maybe we are talking at = cross purposes, because I don't see why apps cannot log to local disk/ = have a good idea of situations where pcap is really necessary and you = can't log the keys. If you can log pcaps, you can log to disk somewhere. From: Watson Ladd = =5Bmailto:watsonbladd=40gmail.com=5D Sent: Saturday, July 15, 2017 3:26 PM To: Ackermann, Michael = > Cc: Matthew Green = >; Dobbins, = Roland >; IETF TLS = > Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017 11:16 AM, =22Ackermann, Michael=22 = > wrote: YES=21 I tried to say in my message that collecting traces on thousands, or = hundreds of thousands of hosts, is just not practical or possible. Not = to mention the administrative domain barriers to this. We do it every day at my current employer. Guess we do the impossible. From: Dobbins, Roland = =5Bmailto:rdobbins=40arbor.net=5D Sent: Saturday, July 15, 2017 2:03 PM To: Ackermann, Michael = > Cc: Ted Lemon >; IETF TLS = >; Matthew Green = > Subject: Re: =5BTLS=5D draft-green-tls-static-dh-in-tls13-01 On Jul 15, 2017, at 22:36, Ackermann, Michael = > wrote: That being the unencrypted stream is available to the endpoints Even where it is eventually available, they don't have the horsepower to = capture & forward. ----------------------------------- Roland Dobbins > The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. _______________________________________________ TLS mailing list TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB1368F87EBDF64B2340535356D7A30CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

T= hanks for the clarification Watson. 

I= am always looking to learn new tricks and was hoping you might had one = for distributed, large scale, remote packet captures.    = This is one area we have yet to fully conquer. 

<= o:p> 

W= hat you describe is something different,  but also valuable and = useful.    

B= ut the best thing you illustrate,  IMHO,  is that none of these = techniques or tools is a panacea.     We need many = arrows in our quivers to do an effective job of managing todays networks.

<= o:p> 

T= hanks again

<= o:p> 

M= ike

<= o:p> 

<= o:p> 

F= rom: = Watson Ladd =5Bmailto:watsonbladd=40gmail.com=5D
Sent: Saturday, July 15, 2017 7:08 PM
To: Ackermann, Michael <MAckermann=40bcbsm.com>
Cc: Matthew Green <matthewdgreen=40gmail.com>; Dobbins, = Roland <rdobbins=40arbor.net>; IETF TLS <tls=40ietf.org>
Subject: RE: =5BTLS=5D = draft-green-tls-static-dh-in-tls13-01

 

 

 

On Jul 15, 2017 12:39 PM, "Ackermann, = Michael" <MAckermann=40bcbsm.com> wrote:

I= would be interested in how you initiate the traces at all the =  hundreds of thousands of servers and clients and how you control the flow of pcap files back to where they need to be = processed?     How are users and apps not = impacted? 

Currently I work at Cloudflare, not in ops. = It's possible some of what I say is wrong.

 

We don't collect all traces if I understand = what you mean by trace as a packet capture. I misread your email. No = technology I know of would make that possible at our = scale. 

 

We do log a significant amount of information = on requests and our responses include headers that indicate the path taken = through the system.(the cf-ray you see when some sites fail behind us) We = can quickly determine what went wrong if something did through internal inspection tools starting from those id's = and problematic requests.

 

This works to identify, isolate, and fix = problems in a complex system with multiple internal services.

 

This architecture scales to what we estimate as = x% of all HTTP requests. Not x% of what we see, but of all of them. ( the = x is sizeable)

 

The logging is done with open source log = collection software. Because packet capture and later decryption was not = an option we created other tools.

 

I don't know about internal app = troubleshooting. Maybe we are talking at cross purposes, because I don't = see why apps cannot log to local disk/ have a good idea of situations = where pcap is really necessary and you can't log the keys. If you can log pcaps, you can log to disk somewhere.

&= nbsp;

&= nbsp;

&= nbsp;

F= rom: = Watson Ladd =5Bmailto:watsonbladd=40gmail.com=5D
Sent: Saturday, July 15, 2017 3:26 PM
To: Ackermann, Michael <MAckermann=40bcbsm.com>
Cc: Matthew Green <matthewdgreen=40gmail.com>; Dobbins, Roland = <rdobbins=40arbor.net>; IETF TLS <tls=40ietf.org>
Subject: Re: =5BTLS=5D = draft-green-tls-static-dh-in-tls13-01

 

 

 

On Jul = 15, 2017 11:16 AM, "Ackermann, Michael" <MAckermann=40bcbsm.com> wrote:

Y= ES=21

I= tried to say in my message that collecting traces on thousands,  or = hundreds of thousands of hosts,  is just not practical or possible.   Not to mention the administrative = domain barriers to this. 

 

 

We do it = every day at my current employer. Guess we do the impossible.

&= nbsp;

&= nbsp;

&= nbsp;

F= rom: = Dobbins, Roland =5Bmailto:rdobbins=40arbor.net=5D
Sent: Saturday, July 15, 2017 2:03 PM
To: Ackermann, Michael <MAckermann=40bcbsm.com>
Cc: Ted Lemon <mellon=40fugue.com>; IETF TLS <tls=40ietf.org>; Matthew Green <matthewdgreen=40gmail.com>
Subject: Re: =5BTLS=5D = draft-green-tls-static-dh-in-tls13-01

 

 


On Jul 15, 2017, at 22:36, Ackermann, Michael <MAckermann=40bcbsm.com> wrote:

That = being the unencrypted stream is available to the = endpoints 

 

Even = where it is eventually available, they don't have the horsepower to = capture & forward. 

 

----------= -------------------------
Roland Dobbins <rdobbins=40arbor.net>

 

 

 

The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please = notify the sender, by electronic mail or telephone, of any unintended = receipt and delete the original message without making any = copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.


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

 

 

The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please = notify the sender, by electronic mail or telephone, of any unintended = receipt and delete the original message without making any = copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

 


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB1368F87EBDF64B2340535356D7A30CY4PR14MB1368namp_-- From nobody Sun Jul 16 05:51:23 2017 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 DE9F11317A9 for ; Sun, 16 Jul 2017 05:51: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 (2048-bit key) header.d=mnot.net header.b=kNzz5agx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=juXJMrzM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb9ad5otpxd4 for ; Sun, 16 Jul 2017 05:51:18 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835C512EBF4 for ; Sun, 16 Jul 2017 05:51:18 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E4504206F5; Sun, 16 Jul 2017 08:51:17 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 16 Jul 2017 08:51:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=QQ+CI1h9kUVBVIwL7R Y6FQDh5WYiX51Fv262M1KWqUw=; b=kNzz5agx3alHBqfgx2+KMcqptGn0NYm0NY /LbXhnHYthH5mhWHCMkRqJLH4kLWk8sy0SBLVGXU1/paOKavQ4+mjufwez9yyTfi nRAR0NJ2NsThZbu4dvlcfBW9pqDaFemJtMI5vUD8ABy4gqlUiB5kMDVN2qaRCmyj 8Fb3J/vyBhFuBL5De3Wdv6LD2j7a3qyQIhmA+z0coyzJ4TB7nIR0KY2EvzZO+dMk dSco07czThw6lpDfY27SSyL3aeMIcmioTSpDxAaipWR7VuiM9LjY7UQbcX7xJ7i/ ULjE9e19uF6iQgA6Z+n1w1ffBmjK9yw0N+YShGrj2im2ZD8KoVpw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=QQ+CI1h9kUVBVIwL7RY6FQDh5WYiX51Fv262M1KWqUw=; b=juXJMrzM H3kv9TP0vXSYZuMpSqYA14c3Pfd2a5/umw92S/xfN/G1Ipu3xsyw84/7lEPa0FVH R3KGbwAGJgCuEeF1dLzWfoGpHovyEgdlDNSVVFfSOx7Da0x1CoPMeC9H01xvipYa tc5PQfuWTFDSeKIMEIvDecgBkenSOS3Kz5h3voRnapAMZfVR7dBPOxdQfdBFGlrx marcqRgi8uXFqOCHghr2GPvfwNPFp17ZihOGNIQvbMxuM4iIqz5x/b4k+7zNFe1/ NG0KF7g+0Gkg2XCsKOH1xxWzVLWHmCVGMjqEQlPDiBFQ2HjuiTIXsAT2ZsaUuIHH 6M7dEMNNRbdOlw== X-ME-Sender: X-Sasl-enc: 0GJJbkXr8UZyfPnXznHbjIpanJeHP7015+I/aYP6UnPk 1500209477 Received: from dhcp-813f.meeting.ietf.org (dhcp-813f.meeting.ietf.org [31.133.129.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 55A5324131; Sun, 16 Jul 2017 08:51:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> Date: Sun, 16 Jul 2017 14:51:16 +0200 Cc: "Salz, Rich" , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de> To: Roland Zink X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2017 12:51:21 -0000 =46rom a HTTP standpoint, they are the origin (i.e., endpoint). They = just happen to use HTTP "behind" them. > On 15 Jul 2017, at 10:39 pm, Roland Zink wrote: >=20 > I think reverse proxies are middleboxes regardless if they have = official origin TLS certificates. =46rom the TLS viewpoint they may be = the endpoint although from the HTTP viewpoint they are not. >=20 >=20 > Roland >=20 >=20 >=20 > Am 15.07.2017 um 22:23 schrieb Salz, Rich: >>> A cache may be hired by a user, origin or even a network operator to = act as a >>> "front" to the origin. Is it not a middlebox because of this? It is = a question of >>> definition if a CDN is in the middle or the endpoint :) >> Yes. And I am saying that the definition doesn't include a CDN as a = middlepoint. >>=20 >> Do user-provided reverse proxies have official TLS certificates with = a SAN field claiming to be the origin? >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jul 16 20:39:15 2017 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 369CD12869B for ; Sun, 16 Jul 2017 20:39: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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fxXtZwqu6LEZ for ; Sun, 16 Jul 2017 20:39:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6768A126B72 for ; Sun, 16 Jul 2017 20:39:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKQ09164; Mon, 17 Jul 2017 03:39:07 +0000 (GMT) Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 04:39:06 +0100 Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.151]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0301.000; Mon, 17 Jul 2017 11:39:02 +0800 From: yinxinxing To: Dan Wing CC: "tls@ietf.org" , Sean Turner Thread-Topic: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 Thread-Index: AdL2zV5W/HDgxBACQSqQFOyDPszOzQEDqAMAAASeQgAAH2kMQP//hj2A//9mI6CAANgkgP//MwQA//h4IcA= Date: Mon, 17 Jul 2017 03:39:01 +0000 Message-ID: References: <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com> <609E20D4-2430-4DE0-BF10-C3F44AA4A350@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.596C315B.00BF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 729de73786621886ca58b7311dfe0d2e Archived-At: Subject: [TLS] =?utf-8?b?562U5aSNOiAgU29sdmluZyB0aGUgTkFUIGV4cGlyaW5nIHBy?= =?utf-8?q?oblem_causing_DTLS_renegotiation_with_high_power_consumption_in?= =?utf-8?q?_DTLS1=2E2?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 03:39:12 -0000 SGkgV2luZywNCg0KSSBub3RpY2VkIHRoYXQgSGVsbG92ZXJpZnlyZXF1ZXN0IGlzIG9wdGlvbmFs IGJ5IHRoZSBzZXJ2ZXIgYW5kIHVzZWQgd2hlbiBET1MgaXMgdG8gYmUgbWl0aWdhdGVkLiANCg0K QnV0IGZyb20gcHJhY3RpY2FsIHVzZSBjYXNlcywgdGhlIElPVCBzZXJ2ZXIgbWF5IG5vdCBoYXZl IGRlZGljYXRlZCBhbnRpLURPUyBtZWNoYW5pc20uIA0KDQpJZiB0aGVyZSBpcyBhIG1vcmUgcG93 ZXItc2F2aW5nIHNvbHV0aW9uIHdpdGggdGhlIGZ1bmN0aW9uIG9mIERPUyBtaXRpZ2F0aW9uIHJl dGFpbmVkLCBhbmQgZG9uJ3QgbmVlZCB0byBib3RoZXIgdGhlIHNlcnZlcihjdXN0b21lcikgdG8g ZGVwbG95IGFudGktRE9TIGRldmljZXMsIHdoeSBub3QgaGF2ZSBhIHRyeT8gIA0KDQpSZWdhcmRz LA0KWWluIFhpbnhpbmcNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiB5aW54 aW54aW5nIA0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0N+aciDEz5pelIDE2OjU2DQrmlLbku7bkuro6 ICdEYW4gV2luZycNCuaKhOmAgTogdGxzQGlldGYub3JnOyBTZWFuIFR1cm5lcg0K5Li76aKYOiDn rZTlpI06IFtUTFNdIFNvbHZpbmcgdGhlIE5BVCBleHBpcmluZyBwcm9ibGVtIGNhdXNpbmcgRFRM UyByZW5lZ290aWF0aW9uIHdpdGggaGlnaCBwb3dlciBjb25zdW1wdGlvbiBpbiBEVExTMS4yDQoN CkhpIFdpbmcsDQoNClBsZWFzZSBzZWUgdGhlIGNvbW1lbnRzIGlubGluZQ0KDQpSZWdhcmRzLA0K WWluIFhpbnhpbmcNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBEYW4gV2lu ZyBbbWFpbHRvOmRhbndpbmdAZ21haWwuY29tXSANCuWPkemAgeaXtumXtDogMjAxN+W5tDfmnIgx M+aXpSAxMjozNQ0K5pS25Lu25Lq6OiB5aW54aW54aW5nDQrmioTpgIE6IHRsc0BpZXRmLm9yZzsg U2VhbiBUdXJuZXINCuS4u+mimDogUmU6IFtUTFNdIFNvbHZpbmcgdGhlIE5BVCBleHBpcmluZyBw cm9ibGVtIGNhdXNpbmcgRFRMUyByZW5lZ290aWF0aW9uIHdpdGggaGlnaCBwb3dlciBjb25zdW1w dGlvbiBpbiBEVExTMS4yDQoNCg0KPiBPbiBKdWwgMTIsIDIwMTcsIGF0IDc6MTEgUE0sIHlpbnhp bnhpbmcgPHlpbnhpbnhpbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGFua3MgV2luZywN Cj4gDQo+IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLg0KPiANCj4gUmVnYXJkcywNCj4g WWluIFhpbnhpbmcNCj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBE YW4gV2luZyBbbWFpbHRvOmRhbndpbmdAZ21haWwuY29tXSANCj4g5Y+R6YCB5pe26Ze0OiAyMDE3 5bm0N+aciDEz5pelIDg6NTINCj4g5pS25Lu25Lq6OiB5aW54aW54aW5nDQo+IOaKhOmAgTogdGxz QGlldGYub3JnOyBTZWFuIFR1cm5lcg0KPiDkuLvpopg6IFJlOiBbVExTXSBTb2x2aW5nIHRoZSBO QVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVzaW5nIERUTFMgcmVuZWdvdGlhdGlvbiB3aXRoIGhpZ2gg cG93ZXIgY29uc3VtcHRpb24gaW4gRFRMUzEuMg0KPiANCj4gDQo+PiBPbiBKdWwgMTIsIDIwMTcs IGF0IDU6MjEgUE0sIHlpbnhpbnhpbmcgPHlpbnhpbnhpbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ PiANCj4+IEhpIERhbiBXaW5nLA0KPj4gDQo+PiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQo+ PiANCj4+IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLg0KPj4gDQo+PiBSZWdhcmRzLA0K Pj4gWWluIFhpbnhpbmcNCj4+IA0KPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPj4g5Y+R5Lu2 5Lq6OiBEYW4gV2luZyBbbWFpbHRvOmRhbndpbmdAZ21haWwuY29tXSANCj4+IOWPkemAgeaXtumX tDogMjAxN+W5tDfmnIgxM+aXpSAxOjA5DQo+PiDmlLbku7bkuro6IHlpbnhpbnhpbmcNCj4+IOaK hOmAgTogdGxzQGlldGYub3JnOyBTZWFuIFR1cm5lcg0KPj4g5Li76aKYOiBSZTogW1RMU10gU29s dmluZyB0aGUgTkFUIGV4cGlyaW5nIHByb2JsZW0gY2F1c2luZyBEVExTIHJlbmVnb3RpYXRpb24g d2l0aCBoaWdoIHBvd2VyIGNvbnN1bXB0aW9uIGluIERUTFMxLjINCj4+IA0KPj4gDQo+Pj4gT24g SnVsIDEyLCAyMDE3LCBhdCA3OjU2IEFNLCBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+IHdy b3RlOg0KPj4+IA0KPj4+IA0KPj4+PiBPbiBKdWwgNiwgMjAxNywgYXQgMjM6MDQsIHlpbnhpbnhp bmcgPHlpbnhpbnhpbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBIaSBhbGwsDQo+ Pj4+IA0KPj4+PiBUaGUgTkFUIHRhYmxlIGV4cGlyaW5nIHByb2JsZW0gbWVudGlvbmVkIGluIHRo ZSAgZm9sbG93aW5nIGVtYWlsIHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQgaW4gRFRMUzEuMiBh cyBhbiBleHRlbnNpb24uDQo+Pj4+IA0KPj4+PiBUaGUgdmFsdWUgYW5kIG5lY2Vzc2l0eSBhcmUg YXMgZm9sbG93cy4NCj4+Pj4gDQo+Pj4+IDEuIEVzc2VudGlhbGx5LCBOQVQgZXhwaXJpbmcgcHJv YmxlbSBjYXVzaW5nIERUTFMgcmVuZWdvdGlhdGlvbiB3aXRoIGhpZ2ggcG93ZXIgY29uc3VtcHRp b24gaXMgZXhpc3RpbmcgaW4gRFRMUyAxLjIuIEV2ZW4gaWYgd2Ugc29sdmUgdGhpcyBpbiBEVExT MS4zLCB0aGlzIHByb2JsZW0gc3RpbGwgZXhpc3QgZm9yIHByb2R1Y3RzIHVzaW5nIERUTFMxLjIu DQo+Pj4+IEN1cnJlbnRseSwgbWFueSBJT1QgcHJvZHVjdHMgdXNpbmcgRFRMUyAxLjIgYXJlIGdv aW5nIHRvIGJlIGRlcGxveWVkIGNvbW1lcmNpYWxseSwgc3VjaCBhcyBpbnRlbGxpZ2VudCB3YXRl ci9nYXMgbWV0ZXIuIFRoZXNlIG1ldGVycyB1c3VhbGx5IGhhdmUgbGltaXRlZCBiYXR0ZXJ5IGFu ZCBsb3cgY29zdC4gVG8gYmUgbW9yZSBhY2N1cmF0ZSwgdGhlIGJhdHRlcnkgb2YgdGhlIGNoaXAg bW9kdWxlIG9mIHRoZSBpbnRlbGxpZ2VudCB3YXRlci9nYXMgbWV0ZXIgYXJlIHJlcXVpcmVkIHRv IGxhc3QgZm9yIDEwIHllYXJzLiBUaGVzZSBsZWFkIHRvIGFuIGV4ZXJjaXNlIHN0cmljdCBjb250 cm9sIG92ZXIgdGhlIHBvd2VyIGNvbnN1bXB0aW9uIG9mIHRoZSBjaGlwIG1vZHVsZS4gTkFUIGV4 cGlyaW5nIHByb2JsZW0gY2F1c2luZyBEVExTIHJlbmVnb3RpYXRpb24gd2l0aCBoaWdoIHBvd2Vy IGNvbnN1bXB0aW9uIGlzIGEgYm90dGxlbmVjayBvZiB0aGVzZSBJT1QgZGV2aWNlcy4gQWNjb3Jk aW5nIHRvIG91ciBleHBlcmltZW50YWwgZGF0YSwgdW5kZXIgdGhlIHdvcnN0IGNvdmVyYWdlIGxl dmVsIChFQ0wyKSwgcG93ZXIgY29uc3VtcHRpb24gb2YgdGhlIGNoaXAgbW9kdWxlIHdoZW4gRFRM UyBpcyBlbWJlZGRlZCBpbmNyZWFzZXMgYnkgbmVhcmx5IDYwJS4gVGhlcmVmb3JlLCB0aGVyZSBz aG91bGQgYmUgYSBzb2x1dGlvbiB0byBzb2x2ZSB0aGUgdXJnZW50IHByb2JsZW0gdG8gbWF0Y2gg dGhlIGxvdy1jb3N0IGFuZCBsb3ctYmF0dGVyeSBmZWF0dXJlIG9mIHRoZSBJT1QgZGV2aWNlcyBp biBEVExTIDEuMi4NCj4+PiANCj4+PiBJIGhhdmUgdG8gYXNrIHdoZXRoZXIgdGhlc2UgSW9UIGRl dmljZXMgYXJlIHVwZGF0YWJsZT8NCj4+PiANCj4+Pj4gMi4gRFRMUyAxLjMgd2lsbCBiZSBzdGFu ZGFyZGl6ZWQgaW4gMjAxOCwgYnV0IHRoZSBjb3JyZXNwb25kaW5nIG9wZW4gc291cmNlIGNvZGUg d2lsbCBiZSBhdmFpbGFibGUgYWJvdXQgb25lIHllYXIgbGF0ZXIgYWZ0ZXIgdGhlIHN0YW5kYXJk aXphdGlvbi4gQXQgcHJlc2VudCwgbGFyZ2Utc2NhbGUgY29tbWVyY2lhbCBJT1QgaW5kdXN0cnkg ZGVwbG95bWVudCBpcyB1cmdlbnQsIGl0IGlzIHRvbyBsYXRlIHRvIHdhaXQgZm9yIERUTFMgMS4z LiBUaHVzLCB3ZSBob3BlIHRoYXQgdGhlIGFib3ZlIHByb2JsZW0gY291bGQgYmUgc29sdmVkIGlu IERUTFMgMS4yIGFzIHNvb24gYXMgcG9zc2libGUuDQo+Pj4gDQo+Pj4gT24gdGhpcyBwb2ludCwg SeKAmW0gaG9waW5nIHRoYXQgeW914oCZbGwgYmUgd3JvbmcgOykuIEZyb20gdGhlIGxpc3Qgb2Yg VExTIGltcGxlbWVudGF0aW9ucyBmb3VuZCBoZXJlOg0KPj4+IGh0dHBzOi8vZ2l0aHViLmNvbS90 bHN3Zy90bHMxMy1zcGVjL3dpa2kvSW1wbGVtZW50YXRpb25zDQo+Pj4gYW5kIGFzc3VtaW5nIHRo ZXJlIGlzIGFzIG11Y2ggZW50aHVzaWFzbSB0byBpbXBsZW1lbnQgRFRMUzEuMyBhcyB0aGVyZSB3 YXMgZm9yIFRMUzEuMyB0aGVuIEnigJltIGhvcGluZyB0aGF0IHRoZSBEVExTIGltcGxlbWVudGF0 aW9ucyB3aWxsIGJlIHJlYWR5IG11Y2ggc29vbmVyIHRoYW4gYSB5ZWFyIGFmdGVyIHB1YmxpY2F0 aW9uICh0aGV5IG1pZ2h0IGJlIHJlYWR5IGJlZm9yZSB0aGUgUkZDIGlzIHB1Ymxpc2hlZCkuDQo+ PiANCj4+IA0KPj4+IFlpbiBYaW54aW5nLA0KPj4gDQo+Pj4gV2hpbGUgd2FpdGluZyBmb3IgY2lk LCBwZXJoYXBzIHRvZGF5IGRvIHNlc3Npb24gcmVzdW1wdGlvbiAoUkZDNTA3NyksIGFueXRpbWUg dGhlIGNsaWVudCBoYXMgcmVhc29uIHRvIHN1c3BlY3QgdGhlaXIgVURQIHBvcnQgb3IgSVAgYWRk cmVzcyBtaWdodCBoYXZlIGNoYW5nZWQgLS0gc3VjaCBhcyBpdCdzIGJlZW4gbG9uZ2VyIHRoYW4s IHNheSwgMzAgc2Vjb25kcyBzaW5jZSBsYXN0IFVEUCB0cmFuc21pc3Npb24uICAoVGhlIHByb2Js ZW0gaXNuJ3Qgc29sZWx5IE5BVDsgdGhlcmUgYXJlIHNldmVyYWwgSVNQcyB0aGF0IGNoYW5nZSBz dWJzY3JpYmVyJ3MgSVAgYWRkcmVzcywgPmFsc28gZm9yY2luZyByZS1uZWdvdGlhdGlvbiBvZiBE VExTIHNlY3VyaXR5IGFzc29jaWF0aW9uLiAgTGVzcyBmcmVxdWVudCB0aGFuIE5BVHMgdGltaW5n IG91dCBVRFAsIG9mIGNvdXJzZS4pDQo+PiANCj4+PiAtZA0KPj4gW1lpbl0gWWVzLCB5b3UgYXJl IHJpZ2h0LiBUaGUgcHJvYmxlbSBpc24ndCBzb2xlbHkgTkFUIGV4cGlyaW5nLCBidXQgY2hhbmdp bmcgZnJvbSBXTEFOIHRvIDNHUFAsIG9yIElPVCBkZXZpY2VzIHdha2luZyB1cCBmcm9tIHNsZWVw IG1vZGUuIEFsbCBvZiB0aGVzZSBjb3VsZCBsZWFkIHRvIElQIGNoYW5nZS4NCj4+IFNlc3Npb24g cmVzdW1wdGlvbiBpcyBhIGdvb2Qgd2F5IHRvIHJlLW5lZ290aWF0ZSB0aGUgRFRMUyBzZXNzaW9u LiBIb3dldmVyLCBhY2NvcmRpbmcgdG8gb3VyIElPVCBwcm9kdWN0cywgZS5nLiwgaW50ZWxsaWdl bnQgd2F0ZXIvZ2FzIG1ldGVyLCBzZXNzaW9uIHJlc3VtcHRpb24gbWVjaGFuaXNtIHN0aWxsIG5l ZWRzIHRvIGNvbW11bmljYXRlIDYgb3IgNSBtZXNzYWdlcyhiYXNlZCBvbiB0aGUgY2lwaGVyIHN1 aXRlIFRMU19QU0tfV0lUSF9BRVNfMTI4X0NCQ19TSEEyNTYpIGFuZCB0aGlzIHJlLW5lZ290aWF0 aW9uIG1lY2hhbmlzbSBzdGlsbCBjb3N0cyB0b28gbXVjaCBiYXR0ZXJ5IGFuZCBjYW4gbm90IGVu c3VyZSAxMC15ZWFyIGxpZmV0aW1lIG9mIHRoZSBJT1QgcHJvZHVjdHMnIGJhdHRlcnkuIA0KPiAN Cj4+IEkgc2VlIDMgbWVzc2FnZXMgYW5kIG5vIGNyeXB0b2dyYXBoaWMgb3BlcmF0aW9ucyBmb3Ig dGhlIGNsaWVudCBpbiBGaWd1cmUgMiBvZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTA3NyNwYWdlLTUuICBTbyBJIGd1ZXNzIHlvdSdyZSBzYXlpbmcgdGhlIElvVCBkZXZpY2UgY2Fu J3Qgc2VuZCB0d28gcGFja2V0cyBhbmQgcmVjZWl2ZSBvbmUgcGFja2V0IHdpdGhvdXQgaW1wYWN0 aW5nIGl0cyBiYXR0ZXJ5LiAgSSBhZ3JlZSAnY2lkJyBpcyBtb3JlIGVmZmljaWVudCwgYnV0IGl0 IGlzbid0IHlldCBzdGFuZGFyZGl6ZWQuICBJIHdvdWxkIGNvbnNpZGVyIGRvaW5nID5SRkM1MDc3 IGFuZCB0aGVuLCB3aGVuICdjaWQnIG9yIERUTFMgMS4zIGlzIGF2YWlsYWJsZSwgdXBkYXRlIHRo ZSBkZXZpY2VzIHRvIHN1cHBvcnQgJ2NpZCcgb3IgRFRMUyAxLjMsIGFzIFNlYW4gaW1wbGllZCB3 aGVuIGhlIGFza2VkIGlmIHRoZSBkZXZpY2VzIGNvdWxkIGJlIHVwZGF0ZWQuDQo+IA0KPj4gKEkg aG9wZSB0aGUgZGV2aWNlcyBhcmVuJ3QgdXNpbmcgdGhlIHNhbWUgcHJlLXNoYXJlZCBrZXkhICBU aGF0IHdvdWxkIGJlIGJhZC4pDQo+IA0KPj4gLWQNCj4gW1lpbl0gRmlndXJlIDIgaXMgVExTIHJl c3VtcHRpb24uIEZvciBEVExTLCB0aGVyZSBhcmUgImNsaWVudGhlbGxvIiBhbmQgImhlbGxvdmVy aWZ5cmVxdWVzdCINCg0KPiBIZWxsb1ZlcmlmeVJlcXVlc3QgaXMgb25seSBzZW50IGlmIHRoZSBE VExTIHNlcnZlciBpcyBkZWZlbmRpbmcgaXRzZWxmIGZyb20gYXR0YWNrLiAgSSB3b3VsZCBpbWFn aW5lIEREb1MgbWl0aWdhdGlvbiBjb21wYW5pZXMgd2lsbCwgb3IgaGF2ZSBhbHJlYWR5LCBidWls dCBEVExTIGRlZmVuc2VzIHRoYXQgY2FuIGF2b2lkIHNlbmRpbmcgdGhhdCBtZXNzYWdlIGluIG1h bnkgY2FzZXMsIG9yIHN1Y2ggbG9naWMgY291bGQgYmUgaW5jbHVkZWQgYXMgcGFydCBvZiBhIHF1 YWxpdHkgRFRMUyBzZXJ2ZXIgaW1wbGVtZW50YXRpb24/ICANCj4gSWYgdGhlIGNsaWVudCBkZXZp Y2VzIGFyZSBzbyBzZW5zaXRpdmUgdG8gc2VuZGluZy9yZWNlaXZpbmcgcGFja2V0cywgSSB3b3Vs ZG4ndCB3YW50IHRoZSBzZXJ2ZXIgdG8gY2hhbGxlbmdlIHRoZW0gd2l0aCBIZWxsb1ZlcmlmeVJl cXVlc3QsIGJ1dCBpbnN0ZWFkIGJlIHN1cmUgdGhlcmUgaXMgRG9TIGFuZCBERG9TIG1pdGlnYXRp b24gb24gdGhlIHNlcnZlciB0aGF0IGRvZXNuJ3QgcHVzaCBlZmZvcnQgYmFjayB0byB0aGUgY2xp ZW50cy4gIEFmdGVyYWxsLCB0aGUgY2xpZW50IHNlbnQgYSBwYWNrZXQgdGhhdCB0aGUgc2VydmVy IGNvdWxkIGhhdmUgdmFsaWRhdGVkLCANCj4gYXQgY3J5cHRvZ3JhcGhpYyBjb3N0IHRvIHRoZSBz ZXJ2ZXIuICBDcmVhdGl2ZSBlbmNvZGluZyBvZiB0aGF0IG5vbmNlIGNvdWxkIGFsbG93IHRoZSBz ZXJ2ZXIgdG8gcmVkdWNlIGl0cyB2YWxpZGF0aW9uIGVmZm9ydCBhbmQgcmVkdWNlIGl0cyBsaWtl bHlob29kIG9mIGNoYWxsZW5naW5nIHdpdGggYSBIZWxsb1ZlcmlmeVJlcXVlc3QuDQoNCj4gYmVm b3JlIHRoZSByZXN1bXB0aW9uIHByb2NlZHVyZSBpbiBGaWd1cmUyLiBBbnl3YXksIHRoZSByZXN1 bXB0aW9uIG1lY2hhbmlzbSBpcyBub3QgZWZmaWNpZW50IGZvciBiYXR0ZXJ5LWNvbnN0cmFpbmVk IElPVCBkZXZpY2VzLg0KPiBGb3IgdXBncmFkaW5nIHByb2JsZW0geW91IGFuZCBTZWFuIG1lbnRp b25lZCwgcGxlYXNlIHNlZSBteSByZXBseSBmb3IgU2Vhbi4gDQoNCj4gVGhhbmtzLCBJIGRpZCBy ZWFkIHRoYXQgcmVwbHkuICBUaGUgZGV2aWNlcyBjYW4ndCBiZSB1cGdyYWRlZC4NCg0KPiAtZA0K DQpbWWluXSBJIGRvbid0IHRoaW5rIHNvLiBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBzZWN1cml0 eSwgdGhlc2UgbWVzc2FnZXMgYXJlIG5lZWRlZC4gRXZlbiB0aGUgY2xpZW50IGRldmljZXMgYXJl IGJhdHRlcnktY29uc3RyYWluZWQsIHNlY3VyaXR5IGlzIG5lZWRlZCBpbiBEVExTIGFzIHJlcXVp cmVkIGJ5IG91ciBjdXN0b21lcnMuIA0KDQo+IA0KPiANCj4gDQo+PiANCj4+PiBzcHQNCj4+PiAN Cj4+Pj4gQW55IGNvbW1lbnQgaXMgYXBwcmVjaWF0ZWQuDQo+Pj4+IA0KPj4+PiBSZWdhcmRzLA0K Pj4+PiBZaW4gWGlueGluZw0KPj4+PiANCj4+Pj4gDQo+Pj4+IOWPkeS7tuS6ujogeWlueGlueGlu ZyANCj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0NuaciDI35pelIDE2OjI4DQo+Pj4+IOaUtuS7 tuS6ujogJ0VyaWMgUmVzY29ybGEnDQo+Pj4+IOaKhOmAgTogdGxzQGlldGYub3JnOyBUb2JpYXMg R29uZHJvbQ0KPj4+PiDkuLvpopg6IFJlOiBbVExTXSBZaW4gWGlueGluZyBqb2lucyB0aGUgVExT IFdHDQo+Pj4+IA0KPj4+PiBUaGFua3MgRXJpYywNCj4+Pj4gDQo+Pj4+IEkgaGF2ZSBzZWVuIHRo ZSBDSUQgc2NoZW1lLCBhbmQgdGFsa2VkIHdpdGggSGFubmVzKHRoZSBhdXRob3Igb2YgdGhlIHNj aGVtZSkuDQo+Pj4+IA0KPj4+PiBDSUQgc2NoZW1lIGlzIGEgZ29vZCBpZGVhIHRvIHNvbHZlIHRo ZSBwcm9ibGVtIEkgbWVudGlvbmVkLg0KPj4+PiANCj4+Pj4gSSB0aGluayB0aGUgbGVuZ3RoIG9m IENJRCAoY3VycmVudGx5LCBpdCBpcyAzMiBiaXRzKSBjYW4gYmUgbG9uZ2VyIHNvIHRoYXQgaXQg Y2FuIHN1cHBvcnQgbW9yZSBEVExTIHNlc3Npb25zLiBJdCBpcyBrbm93biB0aGF0IGZvciBJT1Qg c2NlbmFyaW8sIDEgbWlsbGlvbiBjb25uZWN0aW9uIGlzIG5vdGhpbmcuDQo+Pj4+IA0KPj4+PiBS ZWdhcmRzLA0KPj4+PiBZaW4gWGlueGluZw0KPj4+PiANCj4+Pj4g5Y+R5Lu25Lq6OiBFcmljIFJl c2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXSANCj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0 NuaciDI15pelIDIxOjMzDQo+Pj4+IOaUtuS7tuS6ujogeWlueGlueGluZw0KPj4+PiDmioTpgIE6 IHRsc0BpZXRmLm9yZzsgWGlvbmd4aWFvY2h1bg0KPj4+PiDkuLvpopg6IFJlOiBbVExTXSBZaW4g WGlueGluZyBqb2lucyB0aGUgVExTIFdHDQo+Pj4+IA0KPj4+PiBIaSBZaW4sDQo+Pj4+IA0KPj4+ PiBUaGUgdXN1YWwgc29sdXRpb24gdG8gdGhpcyBpcyB0byBhZGQgYSBjb25uZWN0aW9uIGlkLiBQ bGVhc2Ugc2VlOg0KPj4+PiBodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvZHRsczEzLXNwZWMvaXNz dWVzLzYNCj4+Pj4gDQo+Pj4+IC1Fa3INCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+ IE9uIFN1biwgSnVuIDI1LCAyMDE3IGF0IDI6MzMgQU0sIHlpbnhpbnhpbmcgPHlpbnhpbnhpbmdA aHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+IEhlbGxvIGV2ZXJ5b25lLA0KPj4+PiANCj4+Pj4gSSBh bSBZaW4gWGlueGluZyBmcm9tIEh1YXdlaSBjb21wYW55LiBJIGFtIGdsYWQgdG8gam9pbiB0aGUg VExTIFdHLg0KPj4+PiANCj4+Pj4gRm9yIHRoZSBETFRTIDEuMyBkcmFmdCwgSSBhbSBpbnRlcmVz dGVkIGFuZCBoYXZlIHNvbWUgaWRlYXMgdG8gdGFsayB3aXRoIHlvdS4NCj4+Pj4gDQo+Pj4+IERU TFMgaGFzIGEgbG90IG9mIGFwcGxpY2F0aW9uIHNjZW5hcmlvcyBpbiBJT1QgZmllbGRzLCBidXQg Y3VycmVudGx5LCB0aGVyZSBpcyBzb21lIGRpZmZpY3VsdHkgd2hlbiBEVExTIDEuMiBpcyBhcHBs aWVkIHRvIElPVCBkZXZpY2VzLCBlc3BlY2lhbGx5IHRoZSBiYXR0ZXJ5LWNvbnN0cmFpbmVkIElP VCBkZXZpY2VzLg0KPj4+PiANCj4+Pj4gRm9yIGV4YW1wbGUsIHdoZW4gdGhlIElPVCBkZXZpY2Ug d2FrZXMgdXAgZnJvbSBzbGVlcCBtb2RlLCB0aGUgTkFUIHRhYmxlIG1heSBoYXZlIGV4cGlyZWQu DQo+Pj4+IFRoZW4gdGhlIElPVCBkZXZpY2UgaGFzIHRvIGVzdGFibGlzaCBhIG5ldyBEVExTIHNl c3Npb24gb3IgYXQgbGVhc3QgbGF1bmNoZXMgYSByZXN1bWUgcHJvY2VzcyB3aXRoIHRoZSBzZXJ2 ZXIsIHRoZSBjb3JyZXNwb25kaW5nIHBvd2VyIGNvbnN1bXB0aW9uIGlzIHRvbyBoaWdoIGZvciBz b21lIHBvd2VyLWNvbnN0cmFpbmVkIGRldmljZXMuIA0KPj4+PiBIb3cgY2FuIERUTFMgcmVuZWdv dGlhdGlvbiBiZSBhdm9pZGVkIGluIG9yZGVyIHRvIHNhdmUgYmF0dGVyeT8NCj4+Pj4gDQo+Pj4+ IEkgaG9wZSB0aGUgY29udHJpYnV0b3JzIG9mIERUTFMgMS4zIChvciBEVExTIDEuMikgY2FuIGNv bnNpZGVyIHRoaXMgcHJvYmxlbSBhbmQgZ2l2ZSBhIHByb3BlciBzb2x1dGlvbi4gIA0KPj4+PiAN Cj4+Pj4gQW55IGNvbW1lbnQgb3IgaWRlYSBhYm91dCB0aGlzIHByb2JsZW0gaXMgd2VsY29tZS4N Cj4+Pj4gDQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+IFlpbiBYaW54aW5nDQo+Pj4+IA0KPj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBUTFMgbWFp bGluZyBsaXN0DQo+Pj4+IFRMU0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Rscw0KPj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IFRMUyBtYWlsaW5nIGxpc3QNCj4+ Pj4gVExTQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBUTFMgbWFpbGluZyBsaXN0DQo+Pj4gVExTQGlldGYub3JnDQo+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCj4+IA0KPiANCg0K From nobody Sun Jul 16 21:01:21 2017 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 10769128C81 for ; Sun, 16 Jul 2017 21:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592] 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 E7ISdhgIm2S2 for ; Sun, 16 Jul 2017 21:01:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E3126B72 for ; Sun, 16 Jul 2017 21:01:19 -0700 (PDT) Received: from fifthhorseman.net (38.200.broadband6.iol.cz [88.101.200.38]) by che.mayfirst.org (Postfix) with ESMTPSA id BE7D7F999; Mon, 17 Jul 2017 00:01:16 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 57DE2202EF; Mon, 17 Jul 2017 01:23:11 +0200 (CEST) From: Daniel Kahn Gillmor To: Wartan Hachaturow Cc: "Dobbins\, Roland" , Matthew Green , IETF TLS In-Reply-To: <20170716094404.sybnpu24l22uuaxb@minsvyaz.ru> References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <871spirljc.fsf@fifthhorseman.net> <20170716094404.sybnpu24l22uuaxb@minsvyaz.ru> Date: Mon, 17 Jul 2017 01:23:11 +0200 Message-ID: <87d190q84g.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 04:01:20 -0000 On Sun 2017-07-16 12:44:04 +0300, Wartan Hachaturow wrote: > On Sat, Jul 15, 2017 at 01:23:35PM +0200, Daniel Kahn Gillmor wrote: > >> > Not to mention the security & troubleshooting applications which >> > require insight into the cryptostream on the wire. >> >> I asked for examples of regulations that specifically require plaintext >> from the network. > > Some countries has got that kind of requirements in the lawful > interception context, in the sense that monitoring is explicitly > required to be fully passive. Could you point me (and the list) to those requirements, please? More specificity than "some countries" would be a useful contribution to this discussion. > However, this mostly means "network equipment that supports some kind > of encryption on the link should be able to pass the traffic in > plaintext for monitoring purposes". Is this quote taken from a specific regulatory context? or do the quotation marks indicate paraphrasing or something else? Regards, --dkg From nobody Sun Jul 16 21:47:23 2017 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 894C2129ADA for ; Sun, 16 Jul 2017 21:47:21 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-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 pTi947-UsJI4 for ; Sun, 16 Jul 2017 21:47:20 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 207E9126B72 for ; Sun, 16 Jul 2017 21:47:20 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id w4so16322450wrb.2 for ; Sun, 16 Jul 2017 21:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=HBnqGCMybY5RyuMRolRhSV/bW6VSZ4Tb53hLaWPm3Mw=; b=rMJO8k6CqKbKt9D3HK0Pz/j1yPYRrz1XrNORk0qWosvgIDYzAil3ooLpfukatJ1NO/ V7r6Riq0OhPe+crqKbj63b2E+WdzOZMhj8oZNRDs3fAjXmE+1MfMc4aMWPVVOrwVC5Jw qTWCDDmbIqvTgxOB+ty9fyfF7wFIazgou6EfadPS7Ro2NMNCkOWwJGfKB2lxTXEwS9+J mjq00BQ9/qQFAjnpk0oRtdYi2mBj9wkbK9vg64iHDW5LvEgg1fSYCTvokRlFxrEm9oKL By6in5RQLr71nj4ClivknU3eLK/g5keAP1CqDS1rCYG4SIOB+Yy10XtuA/hPnb05YMgY KOdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HBnqGCMybY5RyuMRolRhSV/bW6VSZ4Tb53hLaWPm3Mw=; b=pq/KQiZbp/Hb7KsY8v/Ni6A99/4Mk8VilP6vYllMTfO7fUsxIAmqqhDt0In1VnJPAz +KqWx4rqhq3armMijAupaNkycLKHfMaa3s4/17P00LLafKDMehZNUALC2g5QOejIcLNX UpSbRnW/zoLitW1RNSucouT5BvAXTAtwGbW6Qw5BI7nL/bXfXnpdz/MZJn7F7suq4j/Q DlTsk8pY1ADSK01ExF2q/fTK5N+ou9EzUTiRO8qVLJ4mZ9wQK1AUXk5XgXLfjCH8xNDC UfzHolra2UA1d71vgzReHboaI7cJHKM33lRneHTUocQ5BDOvfdW4o/UHr6DsCUQecKna nRkQ== X-Gm-Message-State: AIVw112MZfSHVBgvkxYTEigcSjBbrG1VNDJf5D6sKwhGB0QgSw7+mVUZ 2JEK/Cp0LB7oYc5vkv4jCg== X-Received: by 10.223.181.148 with SMTP id c20mr10084319wre.80.1500266838404; Sun, 16 Jul 2017 21:47:18 -0700 (PDT) Received: from dhcp-9730.meeting.ietf.org ([2001:67c:1232:144:29a3:303b:43a5:f0bb]) by smtp.gmail.com with ESMTPSA id 22sm17635547wru.29.2017.07.16.21.47.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 21:47:17 -0700 (PDT) To: tls@ietf.org References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <871spirljc.fsf@fifthhorseman.net> <20170716094404.sybnpu24l22uuaxb@minsvyaz.ru> <87d190q84g.fsf@fifthhorseman.net> From: Melinda Shore Message-ID: <3f446a36-7756-7225-6316-fee344eb6eea@nomountain.net> Date: Mon, 17 Jul 2017 06:47:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87d190q84g.fsf@fifthhorseman.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 04:47:21 -0000 On 7/17/17 1:23 AM, Daniel Kahn Gillmor wrote: > Could you point me (and the list) to those requirements, please? More > specificity than "some countries" would be a useful contribution to this > discussion. At the time when I was working on VoIP there were a few countries, such as South Africa, which required that any media streams collected as a result of a wiretap order be handed over in the clear. But this was 20 years ago and things may or may not have changed. That said, I expect their requirements can be met by having operators in those countries stick with TLS 1.2. There are things that would surprise me more right now than having proponents of weakening TLS 1.3 come back with a list of countries. Such as, for example, having representatives from service providers in those countries show up with requirements - that would surprise me, given that they haven't yet and that getting TLS 1.3 done has been a lengthy effort. At this point the request to add the static D-H proposal to TLS 1.3 strikes me as unreasonable, even given what are frankly vague references to countries requiring that data be decrypted before being handed off to law enforcement or the government. Melinda From nobody Mon Jul 17 00:05:18 2017 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 199EC130154 for ; Mon, 17 Jul 2017 00:05: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 KopYkjpMGi13 for ; Mon, 17 Jul 2017 00:05:14 -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 67B91120726 for ; Mon, 17 Jul 2017 00:05:14 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id v202so45335778itb.0 for ; Mon, 17 Jul 2017 00:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=7Uh2ijFoJOBJUihwBHWLXun7txQQGKa+nLJRe94cqus=; b=X6JooahWv74eUGOgSktAay4fkn6vQ/Dm5YqjKg7obeSW0ZStr+Q32Uqd/aMe9ABpmf qdbytSlAVnKd1jaXN+1FMgGO5Smz+mvub37ViXtKfgQAmmK/TGtdGcc2Svdm1gA/yn5a vGpqICs3QbrJU1y/ZScEGb6F/9pOXa1ZKZpko= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=7Uh2ijFoJOBJUihwBHWLXun7txQQGKa+nLJRe94cqus=; b=N5YP33wH4ZWdIZenbvxLrZsPa9TF0iJ3pNSccgoMGsepPZMugVV8KeEwZ32YS1mdnQ OsXNJ4kpwtGDABe9a4wuVWNIXmLHFoDuupG6w6bTrIc3HOpP6E3VfybVgpJBh2b6GB4z UuS7IMIjTVu1G6e1WQa0bBzizG5cDjpCJfiN+5cLJa2xRJY6+DxRYlFy7uMPv9yjau55 l/yvUlB/le05vTRuhEmPTMSdGb9N7X1F1skNiUbZdk8UZYE26ofKrWL7N+s0ORpruDm0 EDWfOF2oIqIXCwOQtte2mHNTiZu5sy890rVtewn3PRdvarc/dS/wgpqM8Y3LkZHYEV/2 TXsg== X-Gm-Message-State: AIVw113zdJH39PiXxs8PTlk+j2lwelSACMytIjr+9ZT036qy8LhodsGO n4zEBMvl305miRrQw8rXIA== X-Received: by 10.36.211.11 with SMTP id n11mr3304071itg.69.1500275113411; Mon, 17 Jul 2017 00:05:13 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:d12b:a982:883:c616? ([2001:67c:370:128:d12b:a982:883:c616]) by smtp.gmail.com with ESMTPSA id 65sm8075172ioc.24.2017.07.17.00.05.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 00:05:12 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Jul 2017 09:05:07 +0200 References: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> To: "" In-Reply-To: <7603A43F-62F7-486C-B2A7-48DD56231814@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 07:05:16 -0000 Chair slides are up: = https://www.ietf.org/proceedings/99/slides/slides-99-tls-sessb-chairs-slid= es-06.pdf Further bash: I talked to Nick last night and since we have time on = Monday he whipped up some slides on Exported Authenticators in TLS (aka = https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/). spt > On Jul 14, 2017, at 16:51, Sean Turner wrote: >=20 > The chairs have requested an additional time on the IETF agenda for = TLS. The Secretariat has allocated us the Monday @ 13:30-15:30 slot. = Because the main point of the TLS WG are the TLS and DTLS drafts and the = schedule was already announced, we want to leave those presentations on = Wednesday. What follows is a revised agenda; note that we=E2=80=99ve = alloced 40 minutes for further about draft-green-tls-static-dh-in-tls13. = Please let us know your thoughts. >=20 > Monday @ 1330-1530 CET: >=20 > - Administrivia (5min) > - Document Status (5min) > - A DANE Record and DNSSEC Authentication Chain Extension for TLS = (20min) > = https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ > - Record Size Limit Extension for TLS (15min) > https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/ > - SNI Encryption (25min) > https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ >=20 > Wednesday @ 0930-1200 CET: >=20 > - Administrivia (5min) > - TLS1.3 (20min) > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ > - DTLS1.3 (45min) > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ > - Data Center use of Static DH (30 min) > https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ > - National Cybersecurity Center of Excellence (NCCOE) project for > visibility within the datacenter with TLS 1.3 (10min) > aka implementing draft-green-tls-static-dh-in-tls13 > - Discussion about the previous topic (40min) >=20 > J&S From nobody Mon Jul 17 00:18:44 2017 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 E01E5131683; Mon, 17 Jul 2017 00:18:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150027591586.32620.1110391414163358418@ietfa.amsl.com> Date: Mon, 17 Jul 2017 00:18:35 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 17 Jul 2017 07:18:36 -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 : Example Handshake Traces for TLS 1.3 Author : Martin Thomson Filename : draft-ietf-tls-tls13-vectors-02.txt Pages : 36 Date : 2017-07-17 Abstract: Examples of TLS 1.3 handshakes are shown. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys and ivs are shown so that implementations might be checked incrementally against these values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-02 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 Jul 17 02:28:56 2017 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 D0305127337 for ; Mon, 17 Jul 2017 02:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PoFWhye5u3yJ for ; Mon, 17 Jul 2017 02:28:53 -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 58205129468 for ; Mon, 17 Jul 2017 02:28:53 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m84so49084833ita.0 for ; Mon, 17 Jul 2017 02:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Cz4rl8BxYDCvugbagZw5NE8EF48+sJagwO6nAmzcmb4=; b=gvS0Yzu20gEhLJcXR4ZRpu2VrBuJsJi/fgiK8DiLuFaqv9JMDmSQlpSXfZ8iTud71K rBkU88PS3texUZ6DbzMFBoetxGwD/VucGuMAk0PyM4KbSbM/O2tX4VXl0YVds7p2llZ3 5g6hwR/IRal7EObZCnKXuJqkvaiKDVnYJ26tVkATqhzQT79TMRw3iOmtpylPJ/SqEni/ Queq9nDqR4hGeKb7errp5NlSt4srTMA/1HHIJKkJ9yLOFF5tf9w2Gjk0q4z7m/JoZWo6 aBs7BWgseRk8KaCDvf7x59BaiGOqa9OLo/BLGVRmkBPWeYmBvMjfJKlhufIDM65qLeVi iXsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Cz4rl8BxYDCvugbagZw5NE8EF48+sJagwO6nAmzcmb4=; b=SF1qJAqKGvlrz1SL6/xDq4+HGh+ZiKOJtZcg0ihFm04J3H7uUE9HVbVP6FAJxqE9NH Ogtqx8Prye549RIS+WhdsPnnqsg6oz/N1zhH5orvzfG50EemDyhyAtv/0HLebMfRcPr7 QYlPnXKvbPRcctQGhtINuONUjmr634otJ29p8DOStRam+a4H93OnG/HnwlIcYMLYIDD/ PuqOZl2Td+NdkbGbArqhcMS2hNg7QsU+CDAltxh7XBpyCJRdp/vSxBf58G/q6s2flpDV gMo/fKKxooYne7o9x0HNKIdnQ+9UfEjynVQCCkOMxHRogIm78d5zwTkTgxG4lrvIto/U cFMQ== X-Gm-Message-State: AIVw113hpIAOAy+xszHx2rCMYFLwunqycmBMtHZmjqUKM6HtfS1ftew2 sH1XQntE2BQQKzRjvr0PvqKxfwNe+qFX X-Received: by 10.36.65.74 with SMTP id x71mr4732033ita.102.1500283732547; Mon, 17 Jul 2017 02:28:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Mon, 17 Jul 2017 02:28:52 -0700 (PDT) In-Reply-To: <150027591586.32620.1110391414163358418@ietfa.amsl.com> References: <150027591586.32620.1110391414163358418@ietfa.amsl.com> From: Martin Thomson Date: Mon, 17 Jul 2017 11:28:52 +0200 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 09:28:55 -0000 I've revised the draft. It now covers -21. I had to make a few changes to ensure that the changes to the resumption secret for tickets was exposed in the draft, you can now see the resumption secret being split based on the ticket_nonce. On 17 July 2017 at 09:18, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security of the IETF. > > Title : Example Handshake Traces for TLS 1.3 > Author : Martin Thomson > Filename : draft-ietf-tls-tls13-vectors-02.txt > Pages : 36 > Date : 2017-07-17 > > Abstract: > Examples of TLS 1.3 handshakes are shown. Private keys and inputs > are provided so that these handshakes might be reproduced. > Intermediate values, including secrets, traffic keys and ivs are > shown so that implementations might be checked incrementally against > these values. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-02 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 17 02:37:33 2017 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 EE56C129417 for ; Mon, 17 Jul 2017 02:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cfPVyUPXENrc for ; Mon, 17 Jul 2017 02:37:30 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 BCD1D127337 for ; Mon, 17 Jul 2017 02:37:29 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id q85so73842975pfq.1 for ; Mon, 17 Jul 2017 02:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8OfnI+sC7hJuaGJukclkxLt03+1rVxGn8x7r1v1NbLc=; b=XM4m4D12wofd/sbmthYf8pCq9cxxTiIs1u31rMxDf5OiVIrgVwyjqgQuhwHM/rJWHe dXsY5OV7ieuQul28iRb0ZdFsAWeIwHPbx6uXRrFrKuI+wXSVi/RZxpFd4dBoSBLvAo56 5XyXtA2HreylmkJIeW2DaugYMZTXln1rN+3IoG4d1pNPgu1L7dZZlZqj5pMtjvilzLNB bpu4P/1bwvWPajhQb8Y0YU8lEeyClJp87twrpK2RoZRyzJd7E47trrCl/5CNIJ7KUh/I Okp57o36s91nUIOWUUdajhDSD4DeBtBhIhK/8jpgkOw5H8YOzv7tgVZbJQyCxsw4JQ0K W8MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8OfnI+sC7hJuaGJukclkxLt03+1rVxGn8x7r1v1NbLc=; b=pb56DksOKZAvoPGOEHWh/fJTTa+/kiKZYOCMmuX8PD7J/9mcfJuhiXYv9Ll0bPZc3A xRjTtbVO0gNQJYN8WDOWOt6e2vf770tYZaHsxShdTINwJtR6h4MZ+dX2oHrPwOurAN5n VDYJWIpQTo2XUV7E0wPczATG4tfPiQcJvU0WDXZmG3dEynLJTar07x9NFRwItw3mzLJb NtsQ+LXLKZkovOwC1zVzSa4iJ6Vo0/xEly4jd+uOGEWedVrt9ZlskJTMmfxKpzgtMMyM yt1N50pb2UNZXjqSpmChPOk5gP4F9psaeVmpJxnPHg8ZejkSf8oXsnvmrqRF3zR+INjO PxNA== X-Gm-Message-State: AIVw1138R0EWLsnymx+CwH25sMhxzdG/HwpmQBEptl9tMyx2MaYNbn99 mV5s2urz2aM/JTwijncZzb9G4oHA3Q== X-Received: by 10.84.218.204 with SMTP id g12mr28836673plm.153.1500284249002; Mon, 17 Jul 2017 02:37:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Mon, 17 Jul 2017 02:37:28 -0700 (PDT) In-Reply-To: References: <150027591586.32620.1110391414163358418@ietfa.amsl.com> From: Kazuho Oku Date: Mon, 17 Jul 2017 11:37:28 +0200 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 09:37:32 -0000 Thank you for updating the draft. I really appreciate your effort to have the example vectors documented. It will be a great help to the implementers. One minor request: it would be great if you could add examples for the exporters. Bug in a exporter is hard to find unless you have an interop between applications that actually use it (however TLS itself doesn't use it). It wasn't until the QUIC hackathon that we found issues. 2017-07-17 11:28 GMT+02:00 Martin Thomson : > I've revised the draft. It now covers -21. > > I had to make a few changes to ensure that the changes to the > resumption secret for tickets was exposed in the draft, you can now > see the resumption secret being split based on the ticket_nonce. > > On 17 July 2017 at 09:18, wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Transport Layer Security of the IETF. >> >> Title : Example Handshake Traces for TLS 1.3 >> Author : Martin Thomson >> Filename : draft-ietf-tls-tls13-vectors-02.txt >> Pages : 36 >> Date : 2017-07-17 >> >> Abstract: >> Examples of TLS 1.3 handshakes are shown. Private keys and inputs >> are provided so that these handshakes might be reproduced. >> Intermediate values, including secrets, traffic keys and ivs are >> shown so that implementations might be checked incrementally against >> these values. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-02 >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-02 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku From nobody Mon Jul 17 02:50:57 2017 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 AD6ED131B81 for ; Mon, 17 Jul 2017 02:50:56 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 RTz6Cf--ErXg for ; Mon, 17 Jul 2017 02:50:55 -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 ECCB0131B15 for ; Mon, 17 Jul 2017 02:50:54 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id h134so40339973iof.2 for ; Mon, 17 Jul 2017 02:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c+41psir829CGwNm8stSr7EiM3CArM2h94HO0rVVv7I=; b=F3wPoTWCIHaxkXrI77QcNIMmfpf+kSpeCpmtGsCho92AsOplPVjtAIcHfOu22Nr3oH N7w7I3xRh/khZtNSweHzfZpPtTLOqOwgYklszHDgGt+N+ms+HY2zmBC/tsiQcou/qn13 sA8uz4gDGMyyFvmJL8YKg+M0eHMni9UWUO80OFpCnlF9OJ0qnAb/+6+GAe80skhaR2m9 ivAr5porjkZK78qwxA85+GDKrXN8gEBnorW0AxE/kuYiUv5+cbSZuNmZ9PD/8jzkCFTS EQC2WCuIrOyLnPOwhDgf6HTFZHfoElUutV+FnPMYVAVCcL0q0hSN9NaBUhHzvL9/EXVZ UIlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c+41psir829CGwNm8stSr7EiM3CArM2h94HO0rVVv7I=; b=JbrdZdIkWgGXCRxFUpfBfCh01n/etD1OwYpa+iV4GumEfsiwgpnT5fQOw3P1mPQzqx tDzxxVcok1+dpG+0+ZJJ4QY0PHe3bD0VCkKD+s6qxuKNStLST0pHjRAqroNiTJL7KQ6o 9ynuiPehydX0UTHgK6ZdEWa3SPP0jrq1S4wU7ze+g9IDIuhONgkS7dNRWfwMYmPxPioB 5duwQgqLLWkP4jOILR3EmABuVQG/nqCnSVlF3Hb9XrFD8cKUWOVvelazk1FozXQpwbTs 0WvgSwsH85jHVXxwnbPg4YltOa5jS+lkr5WvH2i73xDYLPJRdkteqKtHXaLFVnbDGrde MjAw== X-Gm-Message-State: AIVw113Lta53RCrNsfjDw4LJtanMWxjeDw07l4l+PzW+Z11UHY6VbpMy DHY6qerZCbRQFaV9FS3G5iSMaO5QeIfZw20= X-Received: by 10.107.12.18 with SMTP id w18mr17586327ioi.201.1500285054357; Mon, 17 Jul 2017 02:50:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Mon, 17 Jul 2017 02:50:53 -0700 (PDT) In-Reply-To: References: <150027591586.32620.1110391414163358418@ietfa.amsl.com> From: Martin Thomson Date: Mon, 17 Jul 2017 11:50:53 +0200 Message-ID: To: Kazuho Oku Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 09:50:57 -0000 On 17 July 2017 at 11:37, Kazuho Oku wrote: > One minor request: it would be great if you could add examples for the > exporters. Bug in a exporter is hard to find unless you have an > interop between applications that actually use it (however TLS itself > doesn't use it). It wasn't until the QUIC hackathon that we found > issues. This is actually quite tricky to do for a number of reasons, but it's a perfectly reasonable request: https://github.com/tlswg/draft-ietf-tls-tls13-vectors/issues/3 From nobody Mon Jul 17 03:42:35 2017 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 7A7FB131B56 for ; Mon, 17 Jul 2017 03:42:33 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 VfaDYXAvFj9R for ; Mon, 17 Jul 2017 03:42:31 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0128.outbound.protection.outlook.com [104.47.40.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B433013189C for ; Mon, 17 Jul 2017 03:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Bz0oxd7YSzfq4PS9/+XZ/jzwlgPdX5lP9oWdsVs27k=; b=dkaHxsxIBS3rjPTEN5Emue4DgJJFNQR3TMvQP9b5hxUJzEPWZV5F/DtYuJzyjpwCbcGnqRVBSh1g1km1g1c1GvYALVXiGVqoqIPTvRASNcGFVpnQpRD6azeO3kBM4AIkpSQN9S4/n+l4kPvIH+x9zu9HfgFhpLKEQQB6kwcDqvo= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by BY1PR0101MB1029.prod.exchangelabs.com (10.160.199.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 10:42:28 +0000 From: "Roland Dobbins" To: "Watson Ladd" Cc: "tls@ietf.org" Date: Mon, 17 Jul 2017 12:42:17 +0200 Message-ID: <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> In-Reply-To: References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: DB6PR04CA0014.eurprd04.prod.outlook.com (10.170.208.27) To BY1PR0101MB1029.prod.exchangelabs.com (10.160.199.154) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b75a0f6f-f794-46cb-8ac6-08d4cd0085a7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY1PR0101MB1029; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 3:N3EEfzNFdN2kFwnlNN74J/LuZEFP2fw5gg0j5JrD0s6q1Gj9/OIk/AVvycMrQY3XoJYBnVyZ7zWhyJzPHuWUg5DcueqZUxcnGFdZB9xNEd6EQQ3B3W1X9fWcNzUGcUfAVR5xOz8CtUZt4hzIKcT9KnaYSy0Y5ziKUob1hkWE7bnzn4RO9BTu/bf/DZUOdPk/NuEbhgoD2oxolgxQaUMyRxDRa742wBUeAh2SuTN4lI+hZpGkkJFD/peHAXw125n3CHIxIHunP+NG5rhRdm8ODAZ38qrddjsGavsY4WvnYSGtEYAjCOzH5YbuAxM6jA9pDqVKsWQtYp/qwyi2RtZpm6ekvWY41SGB3mkIHlkg47Jhir7g2daks/2bAHqwKcHOMeloK7mgZTHRCvJiQDbcxfZlrNeTs358vdgGJXld8sk+qlT+S50u84CMY8cehBGADp0xNwWYUrCpc62dfOxSbPGOgw1sAA6IYzuOFbklmR9Zx2/P6kfkFpIQMJFXiy4jDr/7kxRu54wdiTlcF3TLYaT2MeS34lQQejSAwWCZzlDLi0v3ES5/u3sFKPQbcEqRqZF0tgmtWtWUDVaiMSGgT8o0xZrbo4acPxwPNUIKRP0Pn13QgzmhnzyPwg7Om/3H3YOt6JxIfqaZLAQ3EZU6Vdte/zFIEJ8lbX2wMPIkkDAi5tvRV2tV7D3r8hAXNa8D7oSyVvWo/Jn19n+/Z4SGN5k5n9iuck1Tc4TNdmbWuzY= X-MS-TrafficTypeDiagnostic: BY1PR0101MB1029: X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 25:X/3DaR0WGspk+j85FHBIsQiy56ATkJ4S0g/emrtOvbGqgdySiPsini/dNilZrkCMV8RqSmTwZu6wCqO1LgPqv72CWU+WeUqoGH23MQS+TcHGdaiz15X+XKlwDcG/K5JefErk5FASG0jwul+jRpuOlTPxt7Q5O/nY0q6IzViGw3ywZWynRrdg5JNF2VCs/dNwNSqN41d23WUmim97QLLr5o8KV5xsCQ5/OYTpZ3WT2CCvfAGi+rbwZPkYYOQuRfdljzX0Zibnv3cYhD64rIya4h59Brd5rcy9MMQ1eGB1Sk3CVXIqtV+dabWRlH8d/wtVBALEFEcua9eH68sWqo3apUYszRFeCzSh5R/q9eZDGMzoPu7NPLTRIq9Fbg23S+ds+VkGsr0bAH0+hN4En9UiwLu6FqQ97nrIv+FlINDz/WNPaPlh310KlooyE7beCbQIx1EEKwUwh9AY9Kni0BWxLkhLdB3dafZWK8oqQBj7tS9mQGXOHgbm/uwK7Z1Fu95J14ez1LM1eQFMkFCs8f23TRLWJxkmFtLwsoWtKW/ujdZOQBtDRu46D+0kkek9to9iW74+S214OFPHefWyvsUrY1FK+rpIpnD76a+dSaHiOEI8zME17eXyzCcBoeViafpyGPkd5wBy2PGzfLuzOueGb5IRtfss3M8A2DIDAIZFDwlcqsx60qWorn/AmZUZ9t56gvd9lT48EA29I4dhXwN9HONcLkKg0vOCdR1a3Zsw+cZ1yVnbZqRsOsTUmW+Q8gFSRSMYATsdi027yeIucD2nfF/UGSgpAMnBDxjYBpcIHkSx3cc2qvKdVRvB1m0P+dub0ooKyevi+rBwe0ZbQtD0wSLtnz1tBVezgZVX0qlCnIWERSK0oeM4SrmZnBh7ldKSQV+2a5GFWh4QKTjgeT6V1kZqpDvskSyKc7nN9yT6HQ4= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 31:dpKYakIWOcz085fMogKWib1LYCul7W4nQbXOpiinDN6PiAYFRc9ZJyeT9WpxP71pEkTIdqzjNKnhWH8rk3pjtqNarZ0SOVwEp7OB65HOOUsD7qTJ1jKhfvyW4B9tX1X8Co+GUdLn+XJ62TB31/vu54m4H1T3AXxS4eN4jNxRY0+FWyf7jKDuF6xvwcgampByCCrdOGWdSqsgOj8cXpF7KWV2lV18qTe8a4LTui/nQ0gpxPAof95yqP+XXVX1wPZtitbuUML5ghGYbc3TOfNwNbrwLMnjrSMyxtGqY6vrCRryr8A2/63+DKZY9qEwEGisPvJoKnxHGtO0XKCCA39M8R3HqmiYrt1PvJMdoUtDD9WCcae06kBDtWXTQxp7On6ag209xdiCiNEDZFnVO+2euqRBW1esqqJOhibyb8zb8I1Not5dlAYTFErGd5S8iZV23B/IlsQW+fhTafF1xs/+BmXi6njx785SOPahrl5HLEjTaOFNeEHZc8Eu8TTLMK/ldXSOsBwSo2GCsOPmO4fAHpvXvzMGWvIFwr/rBLaoty+L4qT+qRGvKgP6o2kJVUyFbAc8ixhiD96Pv5lTahDWPSjZFMHcQOneY856DzdTxaImAA+jA9Btz5AxnF1Wu3PxFOb8vfCVYU3JLiCHQMv02rrl89Kk6J1oq7MDUvONOft2F01X/79k2z2hAtbqCQX3G1S6PEs3vIjTZXjiqV8ALw== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 20:xtYWROmoB+sdakaT7zQ3hhqDLzkRd03UJaECEdYG56aEQEt7Yt11IawluhSZ8EpQ7UlbceZsbw0EApv8VrJQIBSMRlzr1ERlLzKb/tQ8kx7W3/OOoqllWroUKE91zLM+sQNBEy41EYOYSEEowwj0FASLcW/lnN8hcxIKLFuUcoXNnQqr6w7RxcYbpj3U1Wrpv+FrXZ2eUSOilcR/ObZEJedV/CES63F8wV3mKTs+gddToWdf5CuJ7HHkK2TfMT+5F7yR+lYMBCjAfCKw4HsmXqUswzZDP8tOBDQtp0ehA/MNQ9OkQb64KlXcYAe1NaiW+/CR2DnWLYn/ao2Bd1BZmq0aTtrvdK40+o0kLlIIP4LGUyRdvd4qDsOLVzMhc2HnW7VA0dxL9EKrd1zCiZGr9GnmvuNbxbDeFFMTnSdqEEoHSeGOHK5c6kFTf93QjyYOsUSrjuB+ScMuGMcrGVf+z6IKHItjjILVwDnvrDaV81yL2Q43KjQwMWDZPigEXYF4 X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(266576461109395); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0101MB1029; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0101MB1029; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1029; 4:yjPVg3L7FfjqPxK6Gs9UtumKAZuBSyPoGWOETjA9?= =?us-ascii?Q?P95l5MTU4Edyq9pVFvF/x6Xm96T+/UpeLyoTqkkwh+XKwAAM3hpe8A2y/V/5?= =?us-ascii?Q?2Ka+1PpSyzncTzMvSR3YNMavVS9A0O4c1mZ5HfInmJD/IH0NXkaAtFlGGQU+?= =?us-ascii?Q?umSKdBpbS2Y01G3FpVWzhrw7556HH2jCobW1k8S1Il5eaFEu8cFnsPgZt4Qf?= =?us-ascii?Q?x1Tq9JWtpH5iBwK4xrv9lBURIcjchqRAnc16HgBxbECAkGXw+1V5bK5IQ7l0?= =?us-ascii?Q?xgTefPm9H1maiCMzVI4xFhiBvt7T5seafem2zAogHOPH/KRQxZHt2jk9vAdU?= =?us-ascii?Q?2sHFWCrJQmjkFD9zWcH5QLf2kH/7kABfk6ZhkHUBBCzA1KoFk8I0ta44HUHA?= =?us-ascii?Q?1cteXTNvavYSgBoDpLVJdcj41wrJS4UiTYfeBFus84tG0G7sNFwiy3p7Im1o?= =?us-ascii?Q?7GDmngYyCIy+kQzFfaH0Lwr7qtyFA1hQ53xuRH/AvTdFMzO+0PB8xTcOrazB?= =?us-ascii?Q?y8RpH5sWGUQjfIWiaZjKu0+ytEuiRWrby02wpMzfJj7Z0e6S04iDiwqtqod9?= =?us-ascii?Q?YJShf5vi8T+h+pxuSSaostV6cEp67wK1wg235UhvW1K5ei6IIp9n2JHD98Zi?= =?us-ascii?Q?BxjA9PCd7QEPDMjaZ9oiC/0NIvIupmCNLUi01paonBxx8p8X8YwSefs58Ew2?= =?us-ascii?Q?1c5LngedxX2ASestJic5lwejUUMvdTuRnnu2cnmBb267ywVbAgHHSxFTJ8uG?= =?us-ascii?Q?3ujKMxGJSQk1EM2K69wIHiQM/NuBjr/6dzLocTkMo3lUWvakqUFcxqfawgcA?= =?us-ascii?Q?VIXkxhVwz5gjUtle8bCtfkCs3UJ1AFGr6ZgtG3DTbKv6u8QDEl8KLygwckOi?= =?us-ascii?Q?4uNy0FwOXabmMElvAI6v1V/G+ZgGsXrtOHmJys2Mc3V6i3GGZ+E3yafe/TkW?= =?us-ascii?Q?UL38Rc0INzXlVp6gGN99En4G4MZq3UKbFteM/fww8dxba1QItRjdlou5PnDA?= =?us-ascii?Q?RbxEP/8d+aZs2Hn9qRF+vreskBFwgpPuC68JEcca2qpONatTam7G2Hs/pCw3?= =?us-ascii?Q?cGpPX6hMrdJmGSuDABudwefV23h+eTFIEGUbteH/cVTetg5al1VnxdWqIlGp?= =?us-ascii?Q?tXMgRoJo14ZDlNpDK7mG7fS3GInZHvTtLfpAieKEUzDmtG8jvpa60NSrZDZK?= =?us-ascii?Q?BJkB8V2D0ZbA6bFZzJvECDtoqUBzD7D807gMC88S4ipdon7l/+d0e6G70Ze7?= =?us-ascii?Q?KJAHR5AGAKej9ohpEnU=3D?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6049001)(6009001)(39450400003)(39400400002)(39850400002)(39410400002)(39840400002)(24454002)(6116002)(5660300001)(3846002)(53546010)(82746002)(6486002)(7350300001)(5003940100001)(229853002)(36756003)(93886004)(6916009)(2950100002)(478600001)(6666003)(86362001)(25786009)(77096006)(83716003)(305945005)(76176999)(33656002)(66066001)(50986999)(7736002)(1411001)(47776003)(189998001)(230783001)(6246003)(81166006)(53936002)(50226002)(38730400002)(110136004)(42186005)(4326008)(2906002)(8676002)(50466002)(90366009)(379384003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0101MB1029; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1029; 23:HB7/CrIzfANR16U+q5FwdNa7garVXj0hP4ya14i?= =?us-ascii?Q?VlJo3JQ9Cma4sxq1RGW6J7W4MuvmMo6z0RFns+wvVqoeAKJ8iS97AYLs7hcl?= =?us-ascii?Q?Cqn2aM4MvfDR0jNkgbmF9vrtL86tYDgjkYsV9k63RMkANp4OJDBOU34K/E8u?= =?us-ascii?Q?5OPjHZxTaR/IOFj/WamtbJcn8txcyiS+0ZaS67DM5NOtcubSRvkBGFMMZd06?= =?us-ascii?Q?Zgc8wu4zouQqfvdo401V6QmCZGwObBzQKK3NHkMTyQlUT1tfFPSXFWzxvwH8?= =?us-ascii?Q?uydbRViBBHzLCSFqXBFCIyGE+p+oxRzSndjCt38IXuc2azqOTsbs4dt2NyOs?= =?us-ascii?Q?z/SfZAFY0asCs/HY2MSP1mTN2vDsJ81dyqSxZ6IQUxQ3MjK7b4kFj9q9Z4iA?= =?us-ascii?Q?izGVR1kklvRKod3koZET/CELIqefgJ/sE5lwk47utIufAmZEb9m8jgUgjXkj?= =?us-ascii?Q?Px2Cgr81ga2AnryFX0rY5zroBAYaRMQfAtV6Ceh574OUxcQpkoy/7r9blaYv?= =?us-ascii?Q?UhTm5yHvvUSDMt54z420VKb9y6o+YQUcfdMQMkxyLOrT0EG1Vk1j21pDumn2?= =?us-ascii?Q?YNT4jaCXNMWRWspTYjz6hcP+VDWSngOdfmhvXqLGU7YFMFJRCdbYGUojk9fs?= =?us-ascii?Q?VeaW9RFJTdyiJ+jz6inhLDNxsJ3ZK40hc4+SDS1wwS+cydW1Vc0Pws5usCed?= =?us-ascii?Q?zFMELN0tl8njFF8FSXxpOmAZvmrzohiB+RFMMByVp3oZP8W/+4pUaBfGL2mD?= =?us-ascii?Q?k+8Pkk+7PcF9jCXZ25VYJOQgTFsDBTBqLYW+pWHaQ8aJKNJGby3ZI55rhrMb?= =?us-ascii?Q?jbblwNvhx0IKA0OF/N2LN+ntKuszSRoGbz+zq3eIQ/FKw5pLStzyXG+sx9ic?= =?us-ascii?Q?S+M505eDCNccpdIaMzWw29SlecQp1LiXDbXQgOk2KoQCACE0f+uSwB4m5l+8?= =?us-ascii?Q?b/zTBgUZP1h9bXOF1dSxg1VBbBBtPM2x/PG/GCj6BRLRfK98UlRp2WTYhs/w?= =?us-ascii?Q?JFU5Cu0hg0i4dfoq1dAzV3cP0jGwdlW+d0ezfy9UJju1DrpglWl8lJhegImX?= =?us-ascii?Q?3HtYi3XKnZWkZK3Ubuw2n2qAiegeEthhRg3NOAM60tTR/HxcW/JeiweN3zDH?= =?us-ascii?Q?ISmjgyZKdss1Hfe0/UG1Tw/R10iNCKiafFohX3ULWXNrZ6MBvI1nAcP28dEL?= =?us-ascii?Q?ZBpFcUE2GNfUFykDT1Vc0mVmID6eJzzR3K0l//vnu5cM1xj95YunsTZvcjoh?= =?us-ascii?Q?qHqvLA3c3GIk0RR8jzZ7EpqhSMK9l4gzNWpUdQPMyzflEz4+ZdvakfVcR3qB?= =?us-ascii?Q?5gQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1029; 6:Rx90VUhgdkW1c8UsHjCH4+bpg1jV8Q5l5g5MDZF1?= =?us-ascii?Q?FpKjql46sEN8VgbLu8lxZJtxV4kGYNCetBF1P/3v2TjvL9DCdAiYdLPVu4qC?= =?us-ascii?Q?zscrzIxpHUZOWiu/uI1N0REEVfXh1lzkvNNpO8SD0bSw8cfmuxgC8hfXsN9y?= =?us-ascii?Q?Sh1a5gR60m3m1AmuXxlOgMkQAGCKjVN+GDA9BzAQ2luT++RXcw/bbALsjHVm?= =?us-ascii?Q?tY08epTWNXJM79f2eosKA6XOPsoChFuyPATf/EZeFdb4wvzDsKOZjhRTMxlk?= =?us-ascii?Q?wpH7eXg2lm7oZ1MJOUCwIMpj7YN03OSQaIWLCz2gbxYHa+/AvWFdyjFsxssn?= =?us-ascii?Q?5x5b4qf1byvo0o/t9MxUYCQmDOfzoHUEg5Uwg7fQsK/oTY5+xAnOjrdIZK9V?= =?us-ascii?Q?ZCJwoJPcao+TdHs22UDKJeeMcv8WKG0FyfjO895iZ2hDw+E1HztFHgNPy6jF?= =?us-ascii?Q?B4iQd0OKEXt/DCJGGLZbTOTLCCaAcZcbkxLOMtD5Or8Np1k5CgN6pKgQPeV2?= =?us-ascii?Q?WgV1JwsKR10QUSKZhH6eJlMabzcsAn9CZPlf10ktUy5C48AmWsWI6SYRUQI9?= =?us-ascii?Q?ckMF/TjUIhdBlnyzRgADhkbCqBr77ss+JfvsMJmsPMluE81lVmN4KqUy74Q2?= =?us-ascii?Q?JfAAjIhBIYoZ8QjXKBM726h9UtZ9CsUpbqBl0O8M9k9SlWR04l+mNsvXtNb+?= =?us-ascii?Q?7FdR3G7gXR9TK1Vn+v+lB23olR8ehltof/YMpifdg0FC3aaxQxXmftTl82+z?= =?us-ascii?Q?LMK7PYVujC4MUArIT5EYzioJOxF8i0V4YNWR2tUbT0nczsgMKmSKqkfGzea/?= =?us-ascii?Q?fGNMmcAveBU2tnK6BNEqr1HbXOdRJNCK6+KS+n1gUItKrB0I6ExDN+wSwAO1?= =?us-ascii?Q?nU/TmTklMLBDIgZP6tblfgesrKMB72zMdjyaZDK3RlTrk9V7XO8TXg+PJNPv?= =?us-ascii?Q?BDT0ehvtckqKzC2/S0XYzNUBzzU0tHlli/xi98qYxSsu2jcx8cs4SrtW/HHY?= =?us-ascii?Q?W8g=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 5:rkv+zetrqBzO8DEdc3tpk5OC1EB0xk2K+5tjOKjmaX/VZ4rsy/FIOa+bxC8SSC92+D6zCtWmAmm06RBT7FlqbofQ/dW9MJJ9xTry8KuAjGlHqybAnuppe8Edfu7Jq70h8qlO8N94ErQw2fuWrXvKyEh8WuGI0rhOAp3+prjEvvOsjt+ba304oK021S7d9TUeeNQKCgjpItGtAsTsbRsUPBZAQubT1XwQnbw0LRBEXz/FWR8OO41TQ6C3Jr0ZCcWIcqRaMsllkxBou4ifRY53IeQp0LSfdyz8BxVVY/Azzz16KzVLV2oF58m2pcIi+cBdlesCkDYtsPT+F8asgOkcNzRPw8MpboIEEKKJ9AkYxTCtg0adA8vQgFc8YqO9efTW/GhXJ7IdSudIitdlSaO20kQ+Ra96H2JancrWppIGBigbVoweKJNd77cgH3V4QG544qpTP2UkVvu38nX9RwCLPalDzDfQWmwtMdK0yNb6ZpxD8EzEKgtUhKiCIe92cb38; 24:vmH0vLUxBJmvl9fTuCjVMXEFfEBJpIRDSZUuXkjzBB16c2szl1Z6t78VzHDKvlU0YBYx9miFzKTF7hSbF6IONRjVlZ38ywDvktZdRV0tONs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 7:YGnsT5n/jGux4lIgLiv2WC7EIf/p1ftWgVK920HhQvfOME0ltPheqTy/5V1vJbnKp/jMSKfJHyNholLV4ENifOvXEmhYx4PlSsD98l63x2LbkGToM/FldgjosAnrc72uA0rN+sVwXa0UgBpayhGbMqx4wP44UV48MW39DgN3O0Evp+M27/gakmazOZM2uUqJDDqCfpv2bk85L8aABn1WJWbHTOGeumM23rkvdrNxnFAdLaczrSjYnTeyR4wh2pyErSuqLGOkMUka7ge8xiNaC1LZSDkzTu89BlPSnvIY7SIo3CLXJbmhqrhvzyEI/jJpgcvlwDNN0/PPqBRvyk/texGlRvYmvo+vyyaIVnViZ4ZvLLGztN3wIgMIHp8I9wTQpvESPu2dYu7bXL6A8NRzRsLWWbwRzit+j/iuStEL394KrbmffR/ul47k4k8m/tODujXjIyCQ5ZaPQyT8aE/KB186RcMjgJM1aEz7RC2Uti+jChejx9p4H/DKJuMx3ZimAx7u6+jT68iGBcwJWvxOV8JSGsP5axLVYTjlMmU+5wANccRelglvEsePZ+0c5H1yRWv9HHeVTBhmDtpis9GlUsCg4jTEfd7XRJspLXNAU+u24tpCWaYxttUiqqR0Eu8IFRNIHXchl8kH26h/V0ozkFwqOTld9bPb2BMVpM6MdyR4KXoq7XeTsVcuB8O4G2nDZm2mg/7HCPsBNjr1ZlrtJCWAZfJo00FktK+xm9nDa2JGxonoUhpX1hkTeZdqnnoqREvOLVhK6gmu6Ze+wADzdgxyyngi+FAas6+0kU5TAKk= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 10:42:28.4860 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0101MB1029 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 10:42:33 -0000 On 15 Jul 2017, at 3:40, Watson Ladd wrote: > DDoS mitigation can be done at endpoints Not at scale. That's why it isn't done that way. I'm all in favor of things like mod_security. But they can't do the heavy lifting on boxes which are already burdened by handling legitimate traffic. > If you want to detect unauthorized access to a resource, having the > resource which determines access anyway log that is enough. This is incorrect. > Exfiltration detection based on looking for sensitive identifiers > doesn't work: Yes, it does. I know, because I've done it. > real attackers will encrypt the data and dribble it out slowly or > pretend to be videoconferencing. Believe me, real attackers do all kinds of things - and the most common exfiltration mechanism is to try and get lost in the http/s crowd. > As for attack surface why is "Press here to get plaintex of > everything" not a major, major increase in attackability? Because these are intranet-only systems on isolated management networks with strong access controls. > Which DDoS attacks specifically? Among others, application-layer DDoS attacks within the cryptostream. > And if the traffic isn't hitting endpoints, does it matter? Of course it matters. I've not personally had the pleasure of doing this, but I know it is possible because it is done every day. > Finally, most software can export the secrets from TLS connections to > a file. Logs are context-free and in no wise have the same value as being able to see the interactive traffic on the network in real-time. > The capacity being asked for already exists. Yes - and now folks are talking about arbitrarily taking this capability away without understanding its criticality to network operations, troubleshooting, and security. The fact that we're even having this discussion at this point in time is because of an astounding lack of due diligence on the part of those who are pushing to remove the capability to monitor standards-based encrypted traffic on intranets. ----------------------------------- Roland Dobbins From nobody Mon Jul 17 03:49:58 2017 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 00AAF1319B4 for ; Mon, 17 Jul 2017 03:49:57 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 7A2-X9Luefos for ; Mon, 17 Jul 2017 03:49:55 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0128.outbound.protection.outlook.com [104.47.40.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2527E120725 for ; Mon, 17 Jul 2017 03:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QQ57Hy38bj74FBtk9ryQATaz0oYzeiJEXpOg3RIV20U=; b=iSLcvr7xo0vMBxtRHwNNsaKqDeN+rm6wajg+HK0OXFvcEFohfjFftnw8tuTS0Ksfggh8iyOd4R3CXwbiNTK+Ov9RRcauKgKzpWNcS6+rGbTD8bGtNAlUxqKWa2Z8HjV9H3I98GJaWaFIV0W1ie40t2lrzuHR7/Q0+UzyD0F22ao= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by CY1PR0101MB1033.prod.exchangelabs.com (10.160.225.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 10:49:50 +0000 From: "Roland Dobbins" To: "Kathleen Moriarty" Cc: "Daniel Kahn Gillmor" , "IETF TLS" Date: Mon, 17 Jul 2017 12:49:40 +0200 Message-ID: <9CE7FE22-4D72-46EC-88EE-87BCEB467F61@arbor.net> In-Reply-To: References: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <87k23arzac.fsf@fifthhorseman.net> <20170715085544.y3hozzzpqzrfacd7@LK-Perkele-VII> <87379yrlqp.fsf@fifthhorseman.net> <31358CD2-0913-4CA5-88A2-89AB8C4FBF88@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: DB6PR07CA0062.eurprd07.prod.outlook.com (10.175.237.152) To CY1PR0101MB1033.prod.exchangelabs.com (10.160.225.13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ce3b9025-dfb6-422b-2cd2-08d4cd018d96 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0101MB1033; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 3:hisWMnOhX6gUUe0N+SkrchbafDVbCog/idQy3rhoZGMxvCRfAu7RrTtElNx1sg4LjElmseVvFgrNxVYqkaU2LqqyxPnkGZYtDNd0L4LpjS9GdKhNrX3yqUWDZLRpWG73ad8cwkNF9cSww1qIMgiuMlFEUnj95PA5V+dVSo4gSTB3CVothyN9aZ003ZctR1CnnsIRvKurzsku2aUPwXFPYhD5iW1pXbHb6RMPrAJnBd47mK5NWH6BhsxueP+TQWwufMH4T6biT0r3eatQr0+XzA4nKfEVE4hDwwrEPBb9JW8quI8euV+EPanmD6eMWB1YdaHRsYbtbkXj5sSJB7TkvrJXfCv0lPf5oKbFrs/27NucndlU7eJ9Svs2gWNF0XmM3zuPqP+xyR6u4lG3IsgEnEeG6dlBCdkQNPE0EVsDfS/GR44NHseQ7XEnOLGBKqXxjwWVXBwmIqwxR8z0kQsJL4FjbGuNSUuSBFuOCeGXc/+DlMDXwBp/+5e9TEoyRthIedA63cqy6ihMkIC8i/gkAkJX6+YhWUXs5ZUDc4To2ae1j6SA11otN4EDoWbYWdre8iTkgDGEn6Sw4hvtm1twoDBFJdrJv29et3ZqmcF2ELVeApU9SnRj2OkOslkVF58oh0qtxym3wvMnkjHBdnbWUGo50qqxuVPhbQrqd0j+AYdG8MXb0qC/dYWvd/VX67yQ4zEMrDOzM8tP4wQ6ZqfyTFmKj+iPvSso2W8f6HekOvQ= X-MS-TrafficTypeDiagnostic: CY1PR0101MB1033: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 25:cX9+7Xi5LjnDwoQy81QXWowMf844jQc91qPpUF8wimQe/xczTnsBr/B5Lf32erMHDIGTs+DkdYGnnRhGVpRB35svfiMmt4yd/Gv9IztzAbJokoUma4hyCmV+7FnMyWupirIieM6Y2zRUCPVJup3yLwOoBN3eWQ/95RCCfXUDbKGhO13x4iNc6Ey74z3MCw6BSWJZYOdqZvoljc/7051Kay/q12qu9vHfc7pN3a14i2eVJb3ii3ZmYWQPm1tm4iZfn9CkTaYrprfCK5rFgEt8La8l2fQ6HTCFWivvBVbTkicjcmbcSi5SxMo/i1rcGpG21SjbMb3TK7ZKUfDE9sSFmxf8BO+1mzqjWP4UjyhERGica8rTSe4sk0CW4ji1uqG0LkjYlu8Ubgwfx6CVYT2hgVCfzj9cPrQFYzlgSk8xbPn2DTiCIgRR51PXJqYjNC6PwR0nK7x6Ib0cT8ok2jANf2zfccJA3huudzZ5w+UinjNbbGzXR7+Ifgf6QpGnZ6VrgDD8FvP7sZKqpOVSeb7sXuO5tp+zhJ+Zv5v+5SFPYp6+MXhbxB+/aszSg6MO1uZkNgpes/c1+PvzgqUGidavhcrGvw+KiAvulsuLqsTQHWhKlERrMhIhEHK744TXDPgyQ+WxOwmKGWPDXPQSb1rd8dnwApUhvx4IcrTd68Zdy1VreYSC6OsbCuu8igCNCu9M7xYWp1obD08yNQ+WucaVVhx+ouQACaeV3+/sQAZtOs3wmhqTg3BojDm9B6GtgsMLImyXZ2c+/0fPjUVefGBw0QVidLmDUWz9wQA5/pXnRFkBRaXa9MerlP7b9sS2QYYo1NLI+vSFdPONFaZevQwnKb8vcVlVL2ww5YQTHKIf/FcyFRhHXjpkLk2YvPoxx2cwpGGWu1cPFBDTaVnkiuYbyNmCrboQkGFlUmfS7KESOeE= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 31:8YRmT8cq8CjWzf+G38PnAvVtiQDOYbQ5X1k+xmVTU8QQsmdEHeQwMAnwsELWmIO28XqhX1ICZlg8ae6fgX6Af/WCD1YVIiuH5wZOZNWMKq+obg/EM5XqbqixLc1g6cujwpPRvqnQSB4IGazy0SGywrUuqXu8DVygPGoqaURMmC+H8XOSo79j7Fcowah/sL548s8LCoE69JPGUXFugc8HhCjy4nxPXl9+6o7r3WjiVhBl8Iu0MxHZgLD8wboSLnNIGBGMLCZNEZew7K8qxj9ntfzQZbO3eshuHqFQ5kEQ5u8pFlbT1pXCL1lzeZi4uG/z524NudlzpYDYlj2jFDENmxti39h9zJyfHG4ajsS6PtF9VKEZ7cotS73U1SdMUDrZ6K/uhAoQC5wXm0WB8F+zda6kfQILLGWIN+pMZ3Gu6hmnons9iA3/qRrTtEaDHJF32v6uZLu9dufKGtXxUK3PCqm20x9qym5Ui41I8ia8GuHMC7IDivwyqqJfT4EYTXrgPS7FQjNdKaOCEM4Q8hq/4MrjsokI5dioi1h7LtggvGbj+TTvr+1LnuN+FJN6Ta1ZTCfNzl3/RHrmotXHboWokubu5KXi7qIxXPD2oL4XjyyEOX7Gqjj9OXchk6yi/XDALvcgCrHTjQmHAyG8wCjCtJ4jleh5+zE2AedO3cGUitl8H52imUbLtPYZSEwRJoZ2+l0lP9LGN089QTp4ZhocNg== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 20:1D4I8zL3caUcB1un8Eiq3dEAlnTg8K6UccIqiRTWbWASUGpBt0ndb+GXuoqLEX2JmLqV2iGUX6V9HMvOJr/d0amJkeufCchYnN12FzNBiSP523/zdDHiYPjG8Cw7H04KKqSD4LrQ9F+n/jtoYsVz2xw8Xg8mrCP1ylvuopmVwmdu/0MoFxFdLo9+Am+Bl2aDYMruRtLX6264oB0qZHZ2VR4ZzJ4WF73Rgvo3WbmWTwG2ttb+NhMWjR+KnhoshtWmFJgYtW4nysWWu5AEIqSr3ukf+MHmnJ0qz8FckDETth7uKXSjFqbdvfLLysw/BwvLWJnVEBj/7PERqdggxwoxR5QM4HkeuQsivXfBK6CCoW3fsweAQGgWJD5pxmsKnyj+5yzW6ZCGx/HJ/PdEm1fQOEQ3yXt3ap/2VAcEBB/7hIgOD2jnoFvDXdpbyINw+gJSzhUBnKv0+RdiTgtj5mmTFzneYoXOu9lwJlS+LP7VVHPAZe/depRDSnLB1jm24HeJ X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0101MB1033; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0101MB1033; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1033; 4:d6JhOe4gvvpmwU1QztAT3bert5CL0vGmfqa5yVSy?= =?us-ascii?Q?Y0uLQvk1FkRfzdGjcpiiyytTVbkGbZPX/aPleU0RRwwkhMX2+UZS4vMJ2rTu?= =?us-ascii?Q?bVJMRXLvAiFKVpvufGL/CjktqRo7VOae39VVnEaIBR5p5Z9Amr/5QM3Ctg2k?= =?us-ascii?Q?TNoNczgMUZuvOl8G2/HgwFnQfMxpKpfWYfVMSiu6J+ygAtAaMNW7JNrHx/wf?= =?us-ascii?Q?Q5I5aY8fHlRlCBuv4ykDr/rXFxYlhSXuoTOEZJ7umAlPwT8dten6YQci1Amy?= =?us-ascii?Q?X6z/IfT6PsTAT9Mn2RScMMz3GRowbw3K5+OvtPFVz1wltxcKUgQZjB8+vWB2?= =?us-ascii?Q?pk4yJLRISrHFXD2l16fv3BUZLcTsWtQYsC3fp7zmimmoWxBTRjN52lnFZ6uV?= =?us-ascii?Q?oOt3QOoB0bfWmHpfn02uyR+Ddg5q2xxwCJM5IENzNfnFZ/yRojdfA854ZkRp?= =?us-ascii?Q?dh4okdqftEKmCvJIAoD+UCSPffJi03hUKSnqtli3PtG379wBbst6Ekmv6Bh1?= =?us-ascii?Q?Yz9cZJFniXocer5USAFAO7coBYxOBbckKe1f/dy4Vx2IUoNOSiea7R/7dP/E?= =?us-ascii?Q?+3JPEOk+dQsRT8+WgUX0+3D/j3jhO66J7GyDh90ThP5tngY+NQ5mFK3lOoPh?= =?us-ascii?Q?uz1sfinfxc0r3/mlBo1OwLTJf4Y+ICmAwTSK4paPE/dGOGQ2XYnkPMv+EBTT?= =?us-ascii?Q?+mYnQ83xzT3tMSw+LXym906CIOihC7aqPTW7TuAWC0RRoscRuLcm0RvsHAyY?= =?us-ascii?Q?9YZgS9W4TdbUyXvIwv74kESRsuQJa4Opy0BHUN24M1K01tVo02wg3tQCEgp/?= =?us-ascii?Q?bYAdii6v76j9h4vWtGXdQq1F3uBnWenZmn7I8HADUIPcNMbtKxLSsSCp8T39?= =?us-ascii?Q?WPfRzAY0g11rz7IHhNllHFY2CR8PLK/JbUZQazsucQUfqNGj9GurhLDGWUoS?= =?us-ascii?Q?rZQGgZ3eLyejkGtJEk+/KReR7sEN2OP8sX9aqYdFqMsR9MYwmZtoDuHSzis2?= =?us-ascii?Q?uQ44AnRg/qJTtk3HfR46DZlC9dDvno2xawdhefU84O+j3qNyu6MoBJvm0bhJ?= =?us-ascii?Q?IVXMImKpEOI/o6dKVlpPBISjyM3ooaS2SnjmYB1YLlzIpbGj4/Bzket/sc2t?= =?us-ascii?Q?bJHtKC1sg0AGq1cEscXCcizOOcWfLIqxLl/8GGHzVU/cXcPWxruL6VXQG0ML?= =?us-ascii?Q?Vmur0aOjHFL4B2A+8F4Rq+KK9JgrnjpDMeDWomNlhO9L6Qk/BTwtYvDUmg8G?= =?us-ascii?Q?vfGCnNOfRLm38vohfYY=3D?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39400400002)(39840400002)(39450400003)(39850400002)(39410400002)(24454002)(50466002)(8676002)(5660300001)(86362001)(2950100002)(2906002)(83716003)(53936002)(6666003)(6916009)(478600001)(81166006)(77096006)(66066001)(82746002)(6486002)(229853002)(4326008)(50226002)(47776003)(5003940100001)(90366009)(76176999)(189998001)(50986999)(53546010)(25786009)(7350300001)(7736002)(42186005)(33656002)(6116002)(36756003)(54906002)(6246003)(93886004)(3846002)(305945005)(110136004)(38730400002)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB1033; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1033; 23:d0TKikJzhksU7NaRT2ZBp82iW6y2Dw3ygKQNS1T?= =?us-ascii?Q?D4Ah27zFDkfPejIHPmgGLw/9lYtIvQYn+kS+wSVDVHg09ZhsQo1AhguX0Rx1?= =?us-ascii?Q?sOjJqwpXZ8I5+Bn8XHHYnVb9Vi0YN71M5f/doguJ38c8avifVA6gkHPHwV9E?= =?us-ascii?Q?/LyNDpVg5cDLqzAXFKxGECaSNqu9jh4UTpWUzDz8Ax8hurePu2Cz4LV8Fs9B?= =?us-ascii?Q?Czylbnrv+ZAVs3U9IQlmARFfuB4F6gaKMa+M7amL5q/VWA6Tf3vNV/PPG+d7?= =?us-ascii?Q?XgXsD+xGdvhnoNUV8ZNicjQ7hMD+XA3YRAZU0uxVj6U0eLREAMS5SrXE01aU?= =?us-ascii?Q?4bP0TsTNU2Y2AYnelBg5OH2akVKAxedVNvM8Q3aVgjymdEKucYOh3/B5inta?= =?us-ascii?Q?bORif2fsssaGmQIDZL65meWvEamZ90fEMSmDkWqQ0xFzVIt1O02VN5cWOQg7?= =?us-ascii?Q?gF4EnX/0k0rpSTV/Laqvv5gtYTzNwMaXxzz0RLucGEHw8qrv7LhdLwNglFyy?= =?us-ascii?Q?KF8BpaH+twJLz6XWMzULynX2BejIDsJcfRaZCqyIkFBPMlqiaFhc4tFmxUDQ?= =?us-ascii?Q?Rw4vp1ohFDN5oYGEOSkvSifmEVjzYFb8MZ1taaDxo4neKukZPLvJynNqlBdt?= =?us-ascii?Q?VSvKlQOXcPiP186apV1VIdngH13RxnCMioM4ggOvqCxpMMxCNJNJmf9kLUzK?= =?us-ascii?Q?ZedIT6e0zJ27k7wC0RNdplDA7GMbueCJZsdsORCmjDBBVuY0faORqcKSptQY?= =?us-ascii?Q?/hreVs89wB2MvZ60AMP00Cc+H3bBz7a7fnzTn69K+iW0vfgfCCz6BIT5Ckgg?= =?us-ascii?Q?4256b2SjMWG9crlJKdX5/Azs0qiI9vBeFMT5l4sq3k9EPNCDrQR/o+aUVIH4?= =?us-ascii?Q?gNiCqC9dAS6AZ7v0ZLxmpG9PrQEBRbgF2tneVIcI00QoIaCt0YzU1P4gUreQ?= =?us-ascii?Q?qO5YI9sTp8/aLXcFyiFmWR4GbZRMD7bZJtv7bJSFRXBz52eHvmJ84XFH0zUz?= =?us-ascii?Q?T7zUPsNiuvwD/g08kIbR5RBzVLwrujsQzLSPx2p5ifk9Ip4NMhb4dzQFSHLA?= =?us-ascii?Q?AlrRqNPEt/+fam5LRdJWK/Q0RaadbsknchMbHmSUMUl7mJ2WtvG8uxUdQGrL?= =?us-ascii?Q?4s4aSf8QPSxcZwYWmhqRBGY0fxnrxrjXbQ74EAXi0Ih++puRFpi+P/SK0nSJ?= =?us-ascii?Q?ZrUS2yTa2GxTSZ184SPxo0RSPuVax+jCTg/LnPYAuftu9fUOdi2kMP5er3gJ?= =?us-ascii?Q?aTGmNakay7zXgWgGVGATN+sPEfODf3eBF6JDtb4TS?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1033; 6:36+RbMv0KgKYDiP/JPTmL9Wnf+YS99Nq1Za4n1Kd?= =?us-ascii?Q?N2iRKptdHjgfHw3rOcGcsQdf3osbDs0GBmnxou1HurQSO0V6FRmdMlEn1TzF?= =?us-ascii?Q?U4+W20jcsy6vS9xPm+nzhBQkyHMbwApRAJi0mMRVMeGSi9gtQ8WfgNrI8Tl2?= =?us-ascii?Q?eJd13khCh2/VU3Cc91URbEwkkvsgoV6c0cJKhNQhh9ALvhILiw/15bNMgoGm?= =?us-ascii?Q?0g3O22xgUIGhcm0lyXE7NZ77Wr2vLT9OghDu+P8DWYO2O7yf9F7wEFWjVZ7i?= =?us-ascii?Q?iTiX5KugPaJ7cAIHLadMIH67NzW2tF1CDeTnhVR5JegQDiRRILCSBQ6rqQK/?= =?us-ascii?Q?4cDjqzKYumEMoedtG2kbavYeYm4mkwY9Axkj9BP1ebjuyUfNSFC75FTB6VPw?= =?us-ascii?Q?cIEVy2j+uiA7NrEKr6ODGhgwZ4OWq+LREspKXrx1DXeizP7cFvdTcbxzG+b4?= =?us-ascii?Q?YTVuJm0WAjMRZO8YGjYhpSz/qrcc4ol7eR5Z5ZkrjIFRoh+B7toTNj0SuGbk?= =?us-ascii?Q?LsyMuMmn0TKhkR7YcbgPex2CT1EM2DQSiDDPZlmve7tqVMyFhJIn0kN3ArRg?= =?us-ascii?Q?9sxyHbkBEiC4deyY3zYTp/2HszO71Dsl/S4PTI507UWHyc2VZ9CpbhkDzdxZ?= =?us-ascii?Q?X93ITZjjNBEHhDRL4oNX/cc2SMY5BBm9z9I0L1EIhqtmcsCfiNIxUHITtjs0?= =?us-ascii?Q?fU1MNb+dC+tnjOgCtkM3n/uveWLFSqb/w92qms3gxZUyjIUjJYbdQIlXY0zr?= =?us-ascii?Q?7xgx/oN8l+MIRWA6YSQWFUP/2AKZfaGPh97i2AeRXxA/GPJUWQ4wqYo84g00?= =?us-ascii?Q?WbVfy34ot042WvXoV1aPnZOJAXLlhHz9q7dLD2pYzD2Gdd7W+rCgIK/D9TEa?= =?us-ascii?Q?YY1tTjeqDhn3lXT8DC/AMsPr5D8XAl7GqRqz6pfUkCpfyaDZBtwR5swsTAoW?= =?us-ascii?Q?sUx43nJIxLCWIIOo41xK/KeO7BjMbLeJ0zUApiyCI3RhSqm8DWHjZWjwnsOo?= =?us-ascii?Q?C1A=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 5:FSSuONLlMlBmn1OBLSv9hKodZmFsUP9zmGRIt9WzaNmD8m6tK2+utIKeEj2KCVgbPDb/vlUJ45FGgzesaFVKwTbqrX79RtU5G9UXC17WQjJm74DYW0vhenZmk/GvhS4M6MorQYvv7LKkMMNbOZzVwxczMApmZBkk4y0vmJN4xsa+Avp4eA1vKXljOK8NtRfid0P5aoCFsXN/u9oyn3YhiBYQ8chLV5CaIn5iv7GjhXUwPAEXqdCVel9DK5puXUfmY37vzKf5bLgsK2dLjPwV5MthgWRXnRuW4D5kW5/f2yJqgUJ8ewOhSQ3L9A8CXhNDj576sn7QhnR/9Vkq7eiOYB9KJjex/gga3xqklrqXDaGwQnmA+yuepbbrQrOABx4yNTC9Ty1GA8kQMNkAUS1ch7lMFNRVX0Q1tA/wlOvMbGgDlmDA9SsEUcT4pMYxw5K+9Pb0RPtn1W1PsEY3xadF7bIQOp5GZPayBoSPDSIwihywoqiZWtTLmzyTJohSHUqt; 24:9n947zEJXaM+lAelrI2J4sktdLY6wxdMdqWeyD3l8z+LV7bkExrGJpIPJ4QI7rVbjUhXNW+zp9WeXz8ltVaqGj9CFy/c8HJ/Z1JTSxoBT4c= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 7:53yP+ZZMNqmONGdD138OnsgopuNB40NTDXAR9Kyoab3DQx0f9AQoMh12m2qB5FO4o8g+RsgSy1kv95BNdlTEHmiZNGtQg9tlGkbU8ReVULi6XuwpqEoMDODLGJ5TQV8AW8F65XH0sEYFIR4Ewn1j9JRVlMlZkGgSyFq8cdWc2000rGzqqtMR89Edb0Tlser0M7jECvtdemicMJU9uC1EBFypa94j3g7roGK/dBNSbdVQxWHaSKVzIlQVjppR3dIwbt0wKkR2GLqBJ6vbhMgAgcCsxdxKnZMXQFgoulSB1SVORs5gg8HcU0CHQoi3TLQz00/SmSOQhSx4Xb5j2tavcEScaibeLlRAB00WZ04R96UdOA5p+mfgkuteJohSIFuuR0JvFu3qqaA5cEwIOQiBxatGNlG3pAqL8g4nsSttnf5BAyHoiUSc3K4W/kamGrJgdPYy0y6wcaYsD0v0z0cBlN7gj82wwvVO6Lw5SEQASA2NzE4NVzzLSgO74GpyPIkBbCcMmwaqc88yyWI9WPiW28XQEzTED/J8XShJEZU2CrW9tNGbTDlgpTNPXciWJID4XxDuenp/1vJlnudVdoe19SthSAKOWGHSAXvWhJGspIsdFaofxHowIDCXD6+rQoVGS2io4YfoVpKvlzfxR/d+rDcDEVoFWGFkpJ8Vy5lT+2x8gGuTRFOL4yDNsDzZJz1d46iankX71MVXRL9whVncuhhyXUH73g35UkRDOkyTl6EDG6UTvgWmf/yhvORdCzElp0VSmAXuJB6u4OtvWp+DHnVU5Zzix2OjTSLDlDVoSxA= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 10:49:50.9081 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1033 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 10:49:57 -0000 On 15 Jul 2017, at 18:18, Kathleen Moriarty wrote: > When I have done this in the past in environments I've managed, I > always used a one way cable (receive only), set up the interface for > receive only, and then use the same protection mechanism offered by > the switch. Yes! Back in the old days, when hubs were a thing, I used those for this purpose, with the appropriate connections diked out. I still carry around a small GigE switch with SPAN capabilities, just in case. ;> ----------------------------------- Roland Dobbins From nobody Mon Jul 17 03:56:16 2017 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 AE474131A83 for ; Mon, 17 Jul 2017 03:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 DizMQ4JJDA6s for ; Mon, 17 Jul 2017 03:56:11 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0096.outbound.protection.outlook.com [104.47.32.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55936120725 for ; Mon, 17 Jul 2017 03:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7foi/1Iy6IdLD09gs+3K9BsS33OAE8v4ibBMNqLc/r0=; b=KzPcoSl9Vsy9EUKpkp3y7NeWz2kvVLoiPlfizrTeoLbxprygxUvAJHeppHGlj/vXZ+jxcNMClzkiguyNP0emGNy/M/YGj8e0st2vTYxEPszp8hOy1SCvqaFU8JvREHquNEm4K+gwz3qQIBGvWXLpxD6DzpVCEpNE8Kw+GDvko5w= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by BN3PR0101MB1025.prod.exchangelabs.com (10.160.182.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 10:56:07 +0000 From: "Roland Dobbins" To: "Watson Ladd" Cc: "Roland Zink" , "tls@ietf.org" Date: Mon, 17 Jul 2017 12:55:55 +0200 Message-ID: <6B898DA4-9393-408A-9DD7-7DD44E26AFB9@arbor.net> In-Reply-To: References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <860cd103-4e40-3f6f-1a3e-be9a6513c86c@zinks.de> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: HE1P195CA0019.EURP195.PROD.OUTLOOK.COM (10.171.121.29) To BN3PR0101MB1025.prod.exchangelabs.com (10.160.182.154) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c10ac1bd-5b93-4891-6b0b-08d4cd026dbc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0101MB1025; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 3:3YojJAhscBkunW+2IdWROJ+2eYW97y/QzttfMU0GUifq1lpFxVGViCoRNnZ9q/5pLi/HFOlsv0zgk7+uhBfJ9rVBlKqb6+JIbsN2z2lsENXuqLejcBrxTUm30T8xgXH71yNPML6/oFRJikfnM07G6isw7KTLp7VM3CGdMXxYIegJDyuu8zbzOuCGkHf7teL2Q/Q4RBqRh9U6itjbPvGlJiWQnVndPuSJntWvWVrA5FfUQmH+FrVRXjMpMdf3E0nV4/SBFVse/1Ch1QJEEE1KluqgKgvil2UaZWf/9c6xzi172vvsDZYLDCOiVhs1/9PSvg2QP+3KYuYhKBR7gslaeSnCd5xwuVs44+dLRE+cgn5iHT+9+YOpsbIZMPJVDpeASlHa4JPA1cdb+YI3d+iw2sD8kk3qa6lVo7tQM+wAGaM8SiFHaWmKbS81AVrxam4Cq+MBIS2HAiVYX4uoTJL0/EDELbHKc4Nwz4V2J33dDN0QCkvGyyjEOl0WDJgtMOmAkE9Eu5gOPWobcsnwjxVwm/Qe9uq/BY/W5XUGzIuoJpEMvBixfDlVKwLAluE8Q7ZzkVZZG2wcGNN8O13r+quePTFtUHx+zENf7XrZTDCq/3UsWGWMD7jScl91kjT/cCyAyiB/JNlcoormxr700EyOVQkV155ptmM/r4DwX7jz6zb2IxdvK+KmnkRyl1D5TPiQWEcsRLd6visSZnIh5VyxXeWDpoyVk362RmdEdnA47yA= X-MS-TrafficTypeDiagnostic: BN3PR0101MB1025: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 25:ciStKo1PkzQjgAb227qpZBReDwyHpRQef5D7PI7lDIUFghl6n+TXh8HKlVXoCZVq11RDhMlgaYTxi1g3Tg9q53+HKyr+kcVOs4Blm+nL6a/bHu8KsH31MUlDbIm8Ju3kYq+UzkqTr5DYzKnbKq/cWDrQvfmywgsSI5UX3+IaW35MCtC+wzCm3gG7bAg6JjFsJdgX+aIiu7vND1Qr8qbuUCdqvAdaxUS4ub6OAR9rS5pUbr3jE+VXWOyksq9XbpzOWbg1MptbgpvT/S5noOrZ67wkaBmHSm8jdI052JjWMnfpOPXS6yA9CZItjL+GW0L6krx3NcPCtLRSRsESdDslNa/nwJyFoQFx440N3gMu9x5xQOgK0YPe3me0IhXSw0fB7VZmUy7cWvzE3HUg+UYTHGJAFFHDKYB/QXZUcvSl97nxGSu6q9JoGSvzIN5EO91/Wv8wFBkgwVNvGnQZWezZ9s5C4OdXvBJ9rJZt8ZVNTBdUZAcqTyS93VQ0dBcJ2yhxjqqYD4mYCohW3Jy36sbdeJqsvuHXQisUhjHQL/vXzeQi2Fyb4ALiKcKuqCWcpdxB5tRQILo/eBKA768Dcrg3HLTG7T3gGyksRxxBInfSImSUCsM8zUUt10kjumz0AWoWsyWEyTdXjFrxnX5VB+FALY3s45eZ4bkWwhbRxFvRP8t0/V3UuQ/ZO8VRP5uLAefUpUpfSnodN7p45HonXCpuGhKzQBA0JrI3ADpB/chheJX+W2p0jMSMFB/XOV5P3S3oUiJZFiQuYqkxpsqY6FMaxwNNcOvN50VhdBqxR4H+fSEU8mTHiCZZm6fWpVMT6s4XAYCRUfjvSxY4nDYgOZfD4/lUuKMH3dTwYon9/GUs+k6W+H5EosBa7Ewu2Z/UzV197hRKEVNhLk2vj41yNfgsWFoin678Z81Enr4g4MJlPDg= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 31:fKwbUEYJlXgp4p9mLi2P198RsBWDA2memGNKeuPnG1WfZt+eZrJlihaQIBIKCYpdOtkVV3YcY2gADzP8ETxi1NPSfIUNhW4fv/RmtjKcbNlMnn5rGFvK03mCFlSSBanYkCw25E687FzIr1kaa3XwZiskjbeuAr4Un1Ayj0OrXDm0ZUngmfEtoML9DsOOe4/K291fDmwCKzAIPSExhnZ3Za+rXtJRCb0rsCAOkFJknyq9gTGRyLhL29f+w1JQokq/NVH9kWlY8AaTwaxQP6QqlVSP4htAaDy9WlvWViNvsw+VHUdZlFkSoyS1wRHIMrT0EmYr8sp6fo62V0wuqJo+d3azDjc7yZ+wN3YG1i1KU9KcNYEgOJfykoRUbBcR+cc0zZ+9eNx/KmVxifDxCa8E6Wq6JCMNAwy9u/eexF3taJiFU06x11PcTaUJQF22p96dgrJUHdAbItGAC/ta46IO0Lw1Ik4S5M3U/S+eXrCEvb2XMBvI9XDHc1ieAht1vz/NpRY66Vky+3296s5H82YGtcMbwYL366VgkWeWwWqO0WVVgvs/rsjZeYtusaqEP6FeKzwXomon2GjFLdnctrBqYi80SJdnHXGmfihArCn3euwmX4NlyZNNOAYQvv5r2p/kOxrgU7uvizQjLKhImEprLqAS7Ro1+4AvBJj1mNKCAuakvnqXCguGr4xIFtDb2UzelZYAAug/Duz9lA563O+cXw== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 20:UDgQYXDsqX4ltaaJdeoimvuzeTKBr42fN9XK1JjhZ7NDdf8zM8xXoh1h3SOmX1eZBW/twi1VLWA/Ay0V84yFdfEb8cYeLNs26jV6+mpy05ZiI3jEFfTMhAnb4LJuuuTydRIBX9/kfihNUChU+MSZEKmBl+65Via3IHDmgMs+6qtxnstYHYc0OLf+ecxDTADDft6Lo75Y7LwEnfa0PnGdLZ1AB4fYtxuSA52qivGFB36QKYudPeVRkoApB40csc7JkwdKEu6IZU/H6Wen4BrKV1HKo4Rv58AqzwRe32X3N18OXzHiuN8a0DLVLWY9yEKMAEPEPrB5CrV8FcafyAlkBXyZ0+aOkS3mveN5oIJ+qB2xpF2fIpXVDZUUg/IDgiJgT3uzNJsxu/dhfmFTYLxMhT48BQ85TmKA/rAQ3yboLMugK5ru4+cCrXVPoRobv62MJ0/05VFZayT+AiKLuAVFMqZz/KL1Itt/2/6gWDjBO9CB8X88djANrxHvrF3SwQ0L X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(266576461109395); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0101MB1025; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0101MB1025; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1025; 4:dkPKcWNahM1Sn6FqpSASimsf6wn4kHsUReOjtKGS?= =?us-ascii?Q?LZ76Z4tr+5Ji/QIyMcP/hyuPVnslrS5cLsOryyRpeC3PvOg8zdp1mbC895w6?= =?us-ascii?Q?nrVuYj/SDP5FV6eK1zIPOa+c+Otf7XywewUdPyasd6vfGYv4RuMHhRn2cTaQ?= =?us-ascii?Q?FWMNfCpi+394AW8Vek1/iKRcUmZFNyMCNv01VIjChYEVCU0ls4avYUlJCfAp?= =?us-ascii?Q?ZQXivc04jD5Ka/j9IU9yNvR7VFQjgfMwHjExOjaSn2NJczwPESPkioO+B59K?= =?us-ascii?Q?grXhwvL/kgbYtUdxuI1pbH44aDlHkpvfwjXpjfGIaxIpbGlnRu94ePRjxYCt?= =?us-ascii?Q?xOjW7KoBJsA8md6l5Ws++/3Fc86Njkok1MVI0qqP3Wabeu7jSFoggHi1NEFQ?= =?us-ascii?Q?elcspJi3FMUWUIL55pUj1b344zPUu+9XtkVXSCuIeKlDIOsLbxWQOHcOffNx?= =?us-ascii?Q?Nck5J9SDJAgZV1oVkR4oseMsbEsDYPYY76HcIl/YM4T7lTS9IwcdDGFIX9fj?= =?us-ascii?Q?+kDjicArGev6o5q12Ue9Fveli23Nfp2S3T6vh8TgzRd1zV355FHxQv8ZNQVU?= =?us-ascii?Q?oDCJlKElbW25mO80v8bLLtlkRDWkXIrYyWYaWberYmog8vpVeO/DkrQw7hEh?= =?us-ascii?Q?RiJ0X+OA0MxN+RxemS8HZN4gYxOcU0ifFMb/zqUUieBrl5exadrER6/5v8Y+?= =?us-ascii?Q?pUuVBz4BZfs53ARR7t+kG52y4x9Rn3aq+R8GzaKtxHUXtrDJFn+A9igpRE+6?= =?us-ascii?Q?p+4PHZPg8st6Qp4Bg4tPFGB6du6O0d89CPOjOzp484nFRyPFQu2QAPe0tn7m?= =?us-ascii?Q?eaJi3uTG2QaaZ4aPmtJ6+NvzxXKhi3h+rcJdGYB2rQI0MDZjLD2Ey0x1AYok?= =?us-ascii?Q?1QCw3Kmf9GfRCWGKrTvG0+BWHUsZh8UrluvUg9RW/F+YcC9BFlm+NCOQmeWp?= =?us-ascii?Q?Gmnrl7yMjE5xy6qc2mH3Kobmfz1AT3Jobkgksgm6RxfJHst+N6CMTOtmAZ6R?= =?us-ascii?Q?tENxgaoxXRO2Twudnniw/Ok0WlWiwJi5kTmWQOfkY2X9whoM44uNnaWAbuaj?= =?us-ascii?Q?puYBvfil8SuuGHB4Vc5NZ0RIq8iT/PtmEU2OevzX+BCHwIgreIKs5nC7jamY?= =?us-ascii?Q?1Yym7GqCGrP0ar/Q/vQlJwo/xjU3T2fLB07ph/mBlkX9P0LbHZmd7cTD9gAs?= =?us-ascii?Q?litEhO4cpd8IRJFQX2S5zec8vmrUu5+o3gjlhjvt1I0HP82TpkUHIgSyDR1u?= =?us-ascii?Q?kYPGdLgVNdxxaleIjVE=3D?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39850400002)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(2950100002)(86362001)(305945005)(229853002)(36756003)(189998001)(8676002)(2906002)(81166006)(6916009)(83716003)(42186005)(1411001)(66066001)(50986999)(76176999)(82746002)(50226002)(90366009)(6666003)(47776003)(5660300001)(25786009)(6486002)(77096006)(110136004)(38730400002)(6246003)(54906002)(3846002)(6116002)(7736002)(53936002)(33656002)(478600001)(5003940100001)(53546010)(50466002)(93886004)(230783001)(558084003)(4326008)(7350300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1025; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1025; 23:25bOlfjPwTTbXtGCOMc1SGJQHDMXw2315wFixZL?= =?us-ascii?Q?4e36SmfZhDuFn/MFCZZeaup6sIBwt7Ic+T2CdAXtD2pbHHQSKHt68Wxfh+J1?= =?us-ascii?Q?yf58bOPK4aqEP2dhoALs0lcK0K/4DCx9mELNCUMhTM/rKD+jeH5jLocA18pH?= =?us-ascii?Q?orrpLCB08joLpury+zWfBaa3px+V7kvIIj/HeZYVlmT30JRuvQ0wqq2FdJr/?= =?us-ascii?Q?cQ9JRuq6kvBqDdzwfclC/cMZKvkGNYkwjVXajbcnzjmarWPlKXtTqbYYZgsF?= =?us-ascii?Q?lVrBwlb4m8RVoQmyIhA8R6czZ4j3410WKkwEZvOSeFuhmnoghoxCgEF+d6Z5?= =?us-ascii?Q?xFX04pb1iSQueQ73xTYYIP+fqATHERar8i1r9fQa6PEjzTkmtEn/AUmSj4HZ?= =?us-ascii?Q?dVXv8YOwvIv+TMWr/8MHKNWoxadjDJhcEk3t7vE1Y+j03Sug/g2gUfyWffuM?= =?us-ascii?Q?6AU8RkZl6mHpqxjAkSm5dd/ZWydZP518BGpSAldqjvHfniyt6O+qasJZRO/l?= =?us-ascii?Q?osdr2e3lNRnndfqJLZa8G/w6Np4edFp6c/6UKBbjXqjPfQdxrrhPW9xZZClG?= =?us-ascii?Q?Xr0nUQDrox/COKsJtszuppdYRIB3GGC8cDbajyQm+JsGyV6rPjA7mx91mxCN?= =?us-ascii?Q?2qZdLm2w9Qi/NxO8Qq1rA9vKLKpFhgHOANKbIaGxwnK5xxzwxlcZhJySeULp?= =?us-ascii?Q?rm7C0NWxyttKz1q5N5PWHsVV1b/qLplyq1Wj1RTJRjcsIJ6iHkanb+XPQPGi?= =?us-ascii?Q?YCO4IYbDqDADnx6dJV9EwGQ3MOHS8SRHscyLoy95h/55XqN3z/wBtkv7m9K9?= =?us-ascii?Q?4yXkKLwFXFIBXO6qdkQP0XGlVF+hIVY7g0gQ4UylDyJ8B7Zqs9tljyWY/HA8?= =?us-ascii?Q?hMIL9/rRsl9HeWkuHS3EImuAnPQyKRmjcU3U+3ljkkSAJh/9PaB+c0JfsDzc?= =?us-ascii?Q?mXftCrHVXUKBJBI1zb+3wvxQ6INRmNofDGSK08e5yyIRtbrWfmnc96eJDHq2?= =?us-ascii?Q?Rf3QsEbCQ61fHbVWrC+4iUpU6j08ZY4TilMIdqv8zi4qlpNOCH9yjvnzUuye?= =?us-ascii?Q?tG3a3Wf3fM1Pv2EFmelaoZSWUB1NT/ZGY+DzfMLEjro3OVMH9i53jyEUxSnI?= =?us-ascii?Q?v/LugokHvzP//diIccWxvr0kNPfZDB1LS4qkNZ6cJdmTyxVrSmAVVyxbdvHA?= =?us-ascii?Q?6Id4OXCGHheVlbgTWTfTwUe9s+njks69ziJBwjp5FskURGcTeudg17x+EvHL?= =?us-ascii?Q?Y8uAF08dPcOKkahLI7Xnnb8/3avVFgvELgf0c52HgwQB3ShMxdz399Ik6pll?= =?us-ascii?Q?VvmvLWGsE1BdlqW39aZp74M4=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1025; 6:0TNurKjkAfHFJqYiH5NOd86T7jYVdbENInTGLSq3?= =?us-ascii?Q?J7yqaEMs/IY9Xfnvgg6aJTBHF+MJKx4kojR68peb3zXgg+5rIdurToGpgYwE?= =?us-ascii?Q?qCr4CwpPqV0dTRYffEkk3b67x01Ido+KSvC3jZhToEOMsOaT4lZZrXO7g1dH?= =?us-ascii?Q?UnYjpjaI1u1zGSuWTk5xZM8vIG7Wei0SXzQ9IgVosJkDTkAkEzKobhIRW0F5?= =?us-ascii?Q?LQ5ZWA/RwrAZ/sE2ypUoWNNaSNGJ8yJ80gPpCFxrwcmus2YZO74XMp/xrV7u?= =?us-ascii?Q?simHn86WFRFriV0dy2o3dOxmG128CpzAArQE8dHMMZmaJHrmPXjHtWbimE0n?= =?us-ascii?Q?pggdaRoC7rWLz1kqXwhWsSPwjNF6jbmj3a+tWjbHdgeUrtx3qVbq6BMUiu4f?= =?us-ascii?Q?CuIS3u72806pZov/LWgUZGgndpRSemIt7nJCAdUO+ecs6IP9dJlbi0mIsYZ5?= =?us-ascii?Q?QNGWuTJ+1gXolreGwGYodRNe/mRXFfTZyKgj6V84nEtHftHzP3nFIXPWMrJ8?= =?us-ascii?Q?+gTgeLvuoezP0Bah9eRcnyrerZPKsQGqXGxOxqnZnAAsmOTkOMWMcRTbyNmG?= =?us-ascii?Q?QrAlQXRNKrAXxltGNQi5US/5feFvJBH+hrlNIbuhYuX6EI1xY+kGL4bJaxy7?= =?us-ascii?Q?5FD+lacqNWJbeGxUQcvia1CbaypUMbWPTwqmwdNT0Sy/UsIVr0tdNIqfvu7C?= =?us-ascii?Q?kSfNj1Efn0opqQJyZXNgsdqaMX2pdum6MM2ynd9Gxi1ObZoJ3pavo5WS1+rv?= =?us-ascii?Q?LDgFSj3RVRhii32Fl5nvFqjWfDT/HLNU1T/bvg0Fg24pal+XSe+VFq8A7atx?= =?us-ascii?Q?bdw0/o8W6pPqkpvC92RsxhFbE4NK7aUkWC1a8h7LxFI9JlaQEA9zhziY+Lki?= =?us-ascii?Q?KILHdywcNQxG4RdM4FJQPggqR8Y4uTxSF0+gPvHBimamxGNu3JvvdmN4v/i0?= =?us-ascii?Q?cz1oKSIsRxctRx+edZTSbLw4I/zLJKPJMd3soTMpJkIt7n8fGnUGjpciwxk8?= =?us-ascii?Q?Mbc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 5:YHpFumiuZfNLq/oGk4azu6NsjfaZIHwk2c+GAmMZd3UnrCDUAt8v0UchBedk5MzUrJKsUmuedYWDNoBgPRHKuM19RT2gQPEHF6b+dVox0AV/VKAMNh+tINrbQCTphUSZR/f10TFaxdmn39ZmtIwGg4+Uec4Bes1sdujJHj+WYSLebRomO0g5gY5VsxiS6dIq3Qz2F+UbkHPeqxiSc8udpTEfAkoYJrB8z5Wz15LaYKJnLBrObW64eEkwmyH4fbkc/V9RIe7l4+J5QVIM7SCt/aClgaIGS461Mc4INhfP3LTs+eOLwkyP49Ch/1v2n+bbTHWB5Ca2pFbeakh199jBpLsGcZn3fIMiomjtT9K+i8spJapVx33gJqG6ItTkXlhNvSmG1x8ZLdMr7gjn//fSX4AmkISkfElm7FTw0MlS6sKfdjrXuICiNrS/tJs8gIfjiYyevCNuMJ+DC1XM5d8Gf0Zz4YhNThA09rg/vvJ6zm3ZGqzWODljsFcLQEzaJvPy; 24:QDeinBmTCcvmYx+6gPnEIsvs+PErtBQVnP+N8sfev3XjfbslUkQwjbTeW6sMW2JCcjeXd/OKr7zLHDRj55Hl+bo8kjuKf1+vxYrZyAKGScQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 7:SJqWk3XoZ146QC86yfJ6mreZ9Z1zgxJ42fpYRyGPRQeSGTgeI4yPItadJOqkQdCwdJiUMsOLtfvrtWWfLxo+1Tuy+/qBRukfsTWBUGgWQBx7Ic48GxRxUXmEbZct0UuVFW8/1+kcvfrQNgNcX0Ruzgep82gqzGTTbrlvDbicCS2zn74E+IoIamE1iZpxbDcRi4t9zColHHjYo5va4VvIeuT5IV2mQ38lwxjYIBXMIhJi9oQG854B2/f3DUfAK84R/7pp8K2lu1KnyrRjBAhtLXV31kIvhOBsblxT2/iBlx7B47s16EJbzF3falNBWmz/LbDNxrPIJIi8l4kFDx9X2Vqv8AjiCMlsOeB0lVfP+wcc8EwYcAKmA0LWNkEP5SF+/MeXK6QpDLL01Hh61rNGGOGnzNXuRBeNjZ6WjVQmQohfPqJrUzwmAh5CGLFtpN0FTNaNFtfrR+xNkOafhVbFOJQe21VtzfQ/hwiBlile0cCp56EXCBtXItSdbzzmvrqogk7EcRaoBLe8nfuSIkuOhJ0hfY11Rne2wbTZEy37ssCe+SPnsGgJywavAhJAqdPGiJwV68Bxv/gqBpYzeqUzm2neJb2WZCLpRTP/xgxsaZia3cLETpW7N2Rst4qAHTWnfeaxqM39UI35iwDErr4xLFfXIAdKbZCCtm5RfotlF1EOuXKJQP32MXVO152z4/5iw+wrA8YSBD+NjJgIcfTuUaSi0TzcUJneoCqnH0I6v6RJxWss4m516uKImNanMcbzn+kzAo5iDziQUFLXsrkTcmyDUco0THnt2UguKBN0PhE= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 10:56:07.0307 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1025 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 10:56:15 -0000 On 16 Jul 2017, at 0:07, Watson Ladd wrote: > How does an endpoint not know the source? You do not seem to have a good grasp of Internet operations at scale and necessary division of functions. ----------------------------------- Roland Dobbins From nobody Mon Jul 17 03:59:15 2017 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 1D3B613189C for ; Mon, 17 Jul 2017 03:59:13 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 fjA2jTb1hwHE for ; Mon, 17 Jul 2017 03:59:11 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0112.outbound.protection.outlook.com [104.47.42.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33A1120725 for ; Mon, 17 Jul 2017 03:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IFQ4DRaKItet/AH9GJshYnSc8z7Y2Y2rfPm6mdk9P/g=; b=BWwcp2wr5gX1Gwh0/vM4ubXyqXR4Jl+2mq0qXvKv+Un7eYRpybvk/F0r15zqBZ5eR17k6lciR3SEyI93GZgr8X8ZHk9xPE8mNRep7ba3Bm2ZEeo7aGaWho5+QckUmsa3pbE7DNlcYxCX9/T0VOD8KUtCdjGSCm06Xq/Po3Cq6EE= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by BN3PR0101MB1028.prod.exchangelabs.com (10.160.182.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 10:59:10 +0000 From: "Roland Dobbins" To: "Martin Thomson" Cc: "Kathleen Moriarty" , "tls@ietf.org" Date: Mon, 17 Jul 2017 12:59:00 +0200 Message-ID: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: AM3PR05CA0136.eurprd05.prod.outlook.com (10.161.139.14) To BN3PR0101MB1028.prod.exchangelabs.com (10.160.182.16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 43f7a01a-efb9-4371-97d2-08d4cd02dacc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0101MB1028; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 3:3K46fzH1K5lD7zNQhBpqVZwWSCn/XhskAluHTSU2XTv7JWSCA9Jw1H7Dk/afZjiZv4eGn8Y9mepENdck0yGt8b3vcLHsd7G1xU0YsK+lIBU4x9p0QOBd4v4FAFetmej/VJ4JhG+BjeHjWOClFmrTT2z8Yy3gHKWRMxYmg+XpZo2+bZbvg/jWA/jeyXEnPqDRZ5pTSogsXdQAaJoU3dfFTlfReSIh7v3s13osH7o27z+BhLTRkGONfXC+7/bc/c6iHSesKij0pw/kV6U+2myhg8ft2FHVNCI6M2fMEz98M1F1s3MjQ+VlUimffnJsqoW2USaDS/WRXTB/+RaMVTAjWFWdRANX+seNMmiK0wR8pIJIP+5+iUbu3yhbpHJtIdVNWL179YL1GB9URNcMgE3BmgAO/ZOPztbrDmKOb+lSMS2Y/nkdlooi6BGvaeC/BSvk+cjnyRsySZ2tLI6qzYZe4HVRaAE8ti2d77QFt0addHbKCptiftOZwrHbvaegM7Aa0tM1QsS3EviW1nKfc+I0RaheulmQSiD8WUz8Z07Ko5jwfFdhd8VHrrh70lO2MJBASJMYdgLZMq8CmAyNLDo3hhSHbPr88k2JCDIT7xs4yn6amfJr/Mbq9kik7CalJE2IqLIEn5aKR4ndHn3qAP91DBGCGpKfeyzBp6qkKpYULFHURoLAf+GZA+lsdcV6n99Yn18jw7gRVLQX8V22aYD7CFdpFGSEfwqHfFKvKfCgvRw= X-MS-TrafficTypeDiagnostic: BN3PR0101MB1028: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 25:d3NBArYAY7k5zJvy+hFOpd2miq7ervsN0tLDe6A6VQRIWHjtVhfo05/zQvxxH1Y+a6yGKC6p2FOpdJiOKmQTPi87tRygvQOI+BVFexRp5Z2ePUrRI5WSbNVvT68Th+S7+k03kYL0rwPVHjQel0SKZE6VH5m8DBcqLdC3r4xacj3f+3zK432eFOdJCwV2+E4IDkaI6xuKKHZTaL/Y/rpOKYz6D4QJzkhwLTvIBgoatJQ8YgelLnhJ7CwBPlzvCTb6ARSMSUJJtSXVrmvr0pQQvV7MkbYnOhKpE6VnvKEn4UVDb2jTT8tk1Toz6BHXTPo22irxemv1sJsWCe+8KwrmR+S2yIvLHpI9TVQL4pIIpuo/e26EQtnln4YTOb97fIpX1toibp2YKun3E/eClzma2vdYt/Y7KYHP7I9OIKKpkJ2aANwjxf1yFpKU8aWNmlEMpNj+NxW/+J7hb6Uvz0Pbihs7Lec+d7guEC1uOgr9q2/kFcVmI25Gm7Ph8nZ4r/Vk6JHhEH+J7WS0hTg+JOqkeb2wcPnxZc8opZLbBpjMeP1OxxDgyjnEckvC2O2qj5tLZbvjS2iXLrgrgVGS4SoTh4SMOgOb/RUyevNgE6KpD3kgbaX1OB+Sb+mRD8xZ6akQ7zQGhcpuoR482EoMbysht4jiL/QT4vwgaLarpaPFGrcsDFh1nXMuN7reQje9hzVSnxuLkLzhOrGW7tDROghc387YhQwcJldd4LNUEBw5yZHCtvP6+RepZbUJ8belGQ9MwtCN1zIIYEOtp+s42xoE0sD6S72sgLDs9ytjwSfsWURKeTQMysv4K/qmHXeFKta9YwA2SRjmReFmPpf6cnHrBD/GRTgwASqK/CKrBIoFH42d+aY+60h74/JQGLb2t6FIVsYvoAN8neRrgP+Ii3dp5RJIz/US/8rGsymhV0S0SUk= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 31:OXlDVEE0qw+TV2c1HEmBz+6M8n6oB+y9DbaBIIuyz3a5Xn6qa4C73gMQdJnCyh6BYL3xwaC5xvYPOhhReyzCyMlTVaAS/I5z3t+F/gdR9B7tqg0IvPQX6Od64OcqeHYwf7wjvGO7ysK0apzcz9aMC+wNAUcQiHQFuNmekJMrnvUGJPOREJhdjo+Zwp5IfbcSF/1PXrrNDWkT4At+E0jbqeKVDOV4KqeONmZmZWlyly0BeAMNhRzO/+Qbi9EBtUCWxyYhWrw1Up+fYjSZ8yfr9sDBr1g7eu5dX/WfDVDNQw93nf5RKnVB+gL0WKmIx8gKp3b/gTPBDvncN/M/RNk6hXDWHjqtnh1Rf2kTIb+Mc8UekDjgT6D5iIXxRQgwa5D5PzFdtozYvyZmxFNUtgscA/k9Ltuc6cv6QuWB9PnOLoq+ZtzVMr2NH/Vewyaqw8XaZRQg3BODnq5FLyDuCSBQgIieMPTLWZI1H0VB2CX68rUYgeJbV/7/G3ur9bX2LXhi1mflxJv+0eUaAeLMwTH7v9Qts/lughBBTdBdbcE0yKa3/Zn2vWa6NcbOxvSEM7XeV+vkbnuEEq8F8A9bWHQDbYiISaTMiWCnZsN8hOSXdo/DTySH7uYGhlyAcyG9ftKFlIPwUA9hCGwSSNPbnc14XB0gy4dLFt95eUwnBabdCL4E2F11D0a2QXNAYxBQJzqLPjd6nPO6lONudMcl/5W4/g== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 20:TPLhKPpcidrOiQzv0jpnn/phExIx70qtRBZzdEe3xyj2Nou7W9pgUCwxlNOP2g3B70nI5sokI3Oj9B7tsxpb7qiEJgMDb2vIedRomTV9q+pzmUEjnX8AIkhXqygiJBi8bHp3si78lMhWsiiNtKZrXrkfXh41eqQeP9pqMOCpwRA4KF2sEtp8YOd15wf8EEED6q4vpCRQjsvEUaGnOSWGnfVS08FnGJfS7kkfU7qu7nmleQ1px35HQNTM+C52TXs87vKmn9NR+BTLqnbkztZPBfqaGRWQumT2q26NEUTaBGyrlw3k9YqcEJQhVU3pQgJGYTuJPe+IXsOVeHL3ruTiMZe+kbqT4y3MCyMz9rtDMrvZzJxkbGG1TqanKb4gij2sCMSGx0FqfzzTfLXzUt+C5sbfpsq8s5gvKFHpPWYmzZ6eJkHtvjX8QJ7xIqT51hDdJnURTkoLkMrlMeotLRjmuNr5vn7A+xQhjgn2dFDD9iiGEeYwNseGFhbcjcDF3JXB X-Exchange-Antispam-Report-Test: UriScan:(246478575198768)(236129657087228); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0101MB1028; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0101MB1028; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAxMDFNQjEwMjg7NDpxQ2VnQ2FRWEE5RkhlZ21MTWlqOFFUb2h1?= =?utf-8?B?Nml1ekJrUkJOQXJHdUdjNzJpMXdXSGR2cUJ0VjhURGw1UWlzQzZOQW5rNlFy?= =?utf-8?B?elJvMVRmL3lnQkFLSlFsN0REYXZMWmRzR3oxUFZHdExSQ28yNUNzbFFwSjNE?= =?utf-8?B?TmpJeHhLVTdqZThZQ3ZHbFI4RUpBTEdScU1sNVNYQUF4bzJSM0d2eWV0SVpr?= =?utf-8?B?T1ZmK21SWG1iYjJScTIzbjVlMStoM0dQb0s3WE9hQnh6UEMzYWhjRm9aYlMr?= =?utf-8?B?QkZrZksrdnp5RDJ4UUhyMjI4U2wzSHpybDhSMnVybndNNjNUMDg2Nkk1ZjFJ?= =?utf-8?B?WUs5dFFNcUQ2SmdpTFZCaCtRWWltK0VXN0V3RHhoOXhIamFqK2VNOHdvbUdG?= =?utf-8?B?TGwwV2tyYnZ2K1BhdUV5czdaWDFWVXNsYlRLYmtoQ3d4VXJ1QTJIaUFUcHZh?= =?utf-8?B?QlVFK0tDeVhuaGVVdWdlZUkyelZRbGU2VEE0ZC9NUUx4a0JIVWFydkNsRmsy?= =?utf-8?B?R1h0WG9Yc25Mb29adkJwQ0wvTStMTW5tcUFuU0VCcm44OVpoTHh6bXJjY2Vo?= =?utf-8?B?VjQyTzBTdGFySkYwYmZhQ2R0cElZOGhXNXdvZGdSdHV0R2lvV2JoTHJBdFBJ?= =?utf-8?B?YkRxTnJVTGl2Y2RnUW5TREtxWmpxcGpMR3k3c3IxTGo5Rzl1d3I2bWM5aHJK?= =?utf-8?B?VTVzWW5BUWduT0RaaHdVQTdEdEVtOGI0bFVNd1orcGx3OVNTQWI2SHE0Vk0v?= =?utf-8?B?WDNnN3JLUnp6dUZQaFdBMnFaMDFsQ3RVZDFNT3Y1dHdFZFN3WkFmVmFMTkZZ?= =?utf-8?B?UW96c1paQloxYmtSWnZmaldMYlAvY0Zvbjgrb3QxSHRnbjZkQngycHRLa1B6?= =?utf-8?B?a1pFTEFQQlcxNmxlbHhIOXhsTndacXJLSnRaWktiV3pJSDllRXUzbmpGbDVB?= =?utf-8?B?ZVBoZUVEYjJ5dW1xa25yYzZ2dFd2ZHowaEkrRTVsMXhXeGhVelllUkFnUzBY?= =?utf-8?B?R3FCSTczRlRLRzNFU2xWanhyNFVkSXVXNWhubkpZdHVLMXpCSFVtZk5VWTR1?= =?utf-8?B?amlIV1dsMVl0ZHNIanRHQXBHVzkwM2xUaXpjU1ZCN0lsS3RmbVJ4ZzlDdExY?= =?utf-8?B?NEdGeFZrK2ZsU2MyMUQ4SlFBd1gwcHdIODNiK2ZpcTZWN1JqUitjTm45WkNN?= =?utf-8?B?Tk9xbmZUV3JzRk1CUE5sN0UxYklISXR3YmJjTXpuQW9kbmhuTS9VY216QzBw?= =?utf-8?B?OXQwdGRNalkyVzlqdi85T24zaXFrZjk4ZmM2ZzlzaXVua1MvRW1vMFBDc2k0?= =?utf-8?B?R0x4T3BhRVI0K3FRTGpuazNOa2lXYkN0S0tNQjF5Q2VEWXhoY2QwVEw3bCt1?= =?utf-8?B?Tlp1a0Q2a3FqVHFvNjdueUFkRGtGQmNaZXZBTnlWY1FqZGF2SjY2VHZOY2tG?= =?utf-8?B?M2dQa0VPL3RDWEh3b1RpRnVDb0IvUTBQMm5NVDhPMFBHaWxJK1g5ZE82azdY?= =?utf-8?B?Wk14MG1rVjZnZVlIYXJKamgrQ285aThCWGFSWXJyRUptaTl4M0duKzdZVkFI?= =?utf-8?B?YTMyZEUrZkttcWsySC9YNEQwYnljUWVPUTlabTJCVG14TkhvbGlSc00ybm5o?= =?utf-8?B?a1VYQ3VvV3lheHVyeldnb1pYY2JNTUxlUWJwOXJ1bnRURjdUcmFlajZ1aXJ6?= =?utf-8?Q?szT6lu2CgCn1XaDuMIg=3D?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(6049001)(39410400002)(39400400002)(39840400002)(39450400003)(24454002)(81166006)(189998001)(50986999)(8676002)(42186005)(229853002)(50466002)(76176999)(2950100002)(6916009)(6666003)(82746002)(23676002)(6116002)(25786009)(3846002)(230783001)(83716003)(50226002)(86362001)(2906002)(7736002)(5660300001)(33656002)(478600001)(47776003)(54906002)(36756003)(7350300001)(53936002)(90366009)(110136004)(38730400002)(77096006)(6486002)(2870700001)(6246003)(305945005)(53546010)(4326008)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1028; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAxMDFNQjEwMjg7MjM6UGtUTDBrZWdIZHdWYjV0V29yT2Qxbytr?= =?utf-8?B?WFptM0VnUEhxanZUdy9EempjMXAzTTVGWnRWVWQyZWNRR2NLSzN0TTJQK0J3?= =?utf-8?B?bktMU05NbjU5WXhQMFRUQk5FQU5odjdhdkd3YUNxcTNUN2JGNFBHMzZYeUl6?= =?utf-8?B?N08zcDdBL2I0SVIxM1RPU1EzRGcxMSt2dHk1V2JCTzNlUzNkVDFHNDdpb2x4?= =?utf-8?B?MlJmVnlYRVY0VDFGUU1MTkxjaDl6eUVUdVpqMFJySC83QUMvRUY4M2RxNUlO?= =?utf-8?B?VWdXSHlFSEVCOUdQSTl0NjJ1elF4NXRIYzQwdThvUjUwcU11UmJOV2lvREhs?= =?utf-8?B?VGl0WVdSaERLYy9sVmc5cHAycmR4Z2pNVnJJOE84ZzdITHNQTXRwWFphWDVW?= =?utf-8?B?VHY4YW1jcHZhaFJ2YkFTV3UrRnNOOUxZVXhyRmRhUHphLzgwN3VKVWpPOEZE?= =?utf-8?B?N1lXVDB2bzJOWmRCMnd2dS9QNDU0M3NCY2FaaEZYQkZieFlYWkxTNVlyRG1s?= =?utf-8?B?bzhINGtzaFdZOVA2RWxpVEZtc1N1dWJNTFdCeUpSaGIyZ0JNNTNTUGRpaTlp?= =?utf-8?B?WjhhN3IwekJRZEFBcHlLcW1hdEkzSXB1SU1CZS9yWE1oaXZpMGw4OWU5WWtB?= =?utf-8?B?ZWFuNzcwV3o2dmtIeSttZEVmUUIyeG1xRGZwYWRhOHVkS2lmT1VVZzBvQ1Zv?= =?utf-8?B?aFJURTZJMUNneFhSZ1BwRzlsSHgrOTJCVzN0REwxWHh5dS9yRytyMHI1M3Z1?= =?utf-8?B?S1JIcEJJUE0xWFFLRXF4UEhZcTkwZUZ5VU9XWmJRQTZlNWUzTmh5RTJNMGJT?= =?utf-8?B?WEFmNTNCUEZIc3ozU3ZrTk5yeDBYbTdZUGhsMjU2WVpkeDVJWnlXUEtqRWtU?= =?utf-8?B?cmlYMVk3eVByc2V6Uzg1ZGhvSUt1Rjlvd0cwNXdMTnZ5aHBrTVI3dFhoZ1JJ?= =?utf-8?B?WklNdVJhMDRNUVJSN1NaMGgzZW8rTElqcHV0OFNsdEROblNVU3p6NjArS000?= =?utf-8?B?enQwWm8xQTljNWQ2MkZQR2tMK0VYSEFTQ3l0bHJmSUhHNnZKSE9mck45VkNY?= =?utf-8?B?Mi8rNmxBSmNmMHVJR3l4UFZHbU1yRjU0SnVRYlNnUDlOVFhOelB1VVlGQmJP?= =?utf-8?B?ajBQdytGVG9GTDZVM1FsVGJSYndFNW1ZM0FTVENDbDRlWEtnak5Rb05JVUU3?= =?utf-8?B?a3hjZ2ZyaWpWR2wvQ0lDR043WGJwejQwTHJFbWwxREFlc0doM0tFSDBBYkMx?= =?utf-8?B?dXZNWXBTTEpUTkZ1aUJ4c2x2eGEyZkV5dVZEcG9GUVltbGR2R0VkczN5MkxC?= =?utf-8?B?TTJHL2Y3ODZLVUI2bEZ0a3ZSbXE4eXF1NVlnS29NajBMc3IxcW40TkdLa0ZO?= =?utf-8?B?NkRPSEtsaXlYVFplbmdVbmd4dnFXbWs5Q0RqbGFKb3E3YWFxMCs2QitkSlND?= =?utf-8?B?VWd4cFp6bFAyazBNUG91WmpVNmxqaUMvYUIwNEJUbHJsZW11YWhQcVgrdTE2?= =?utf-8?B?eXZYWndxOVJLSFVxVnhmN0syQ05RYldyOHZLUnRvWVdYU3BNZ1JRTHQzWlZU?= =?utf-8?B?ZnhDMXJlM2RkTFN2K2M5OXZKY0NxTGRnaFhzQ3hJalpYNVBNYU83akdqd09m?= =?utf-8?B?bnE0UmRpNmpFNnNHcTQwZGx3eVRMS2RMamRrNVYwL1V3OStQYTlCOUs3R0J0?= =?utf-8?Q?Z4TSTzyQLZAaUcrwposQ=3D?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAxMDFNQjEwMjg7Njo1SXM5TWhMR252d2dIUE1ZVi9XSDBnT0FJ?= =?utf-8?B?bUpwNmdyaXlBeU1PRFFRWTVETE12NXM1MTkyUkxOVVJXZkM3RnBFUDRhd0E1?= =?utf-8?B?Y3RJblFDQ01jdVhoY0tuRFFqV3NuQ1B3UmxaeVg3ZGUxQTFpeG9la0EyWWgx?= =?utf-8?B?YXk3MjNuQTdtTjNmbHRCKzR2Yms1ZjdYdXVBZDV4OGczWFNVeUFJY1h0eFdJ?= =?utf-8?B?YUtEYTllem9KelpUSmZDRmxNTC8zc0xOTjEyU1pFNTR2emFPMGhidFBMSXdh?= =?utf-8?B?dGtmQy9uUnIxSHh2VEpTNHlKUUVISG9IYzlwY05aNDdQYzVySm4yRXorM1lT?= =?utf-8?B?dDNVVkhCV3pXQ0ttcURhdlNTaDFyMXBNTi9IVjYxRERZQUZjYTV3UDQxTWFU?= =?utf-8?B?Y2VNcC8rNFI5OTFmaUJ3UXBGYnNSQ0U1V1YyQ2ltWkFwWmovM2ZHbUFrb1Nh?= =?utf-8?B?VlR2UjVHSW0rNXYvVUhsQ1VoQlNQcFdyQ3ZyRzhCMUhVOTY1T3N6enovRGVF?= =?utf-8?B?c01RRW95ZUczaUhTN2gydXg2cVc4bnNGcFpWYlRERTlSanFVaU56Wk9Hcnpx?= =?utf-8?B?SlFvcS9uL3MzOVg1ZmkxaytMNVdmU2NzcVBqODd0WHl5WS9Bdk91bUY2Tlp2?= =?utf-8?B?RXEwOTUzdDJERzlFOU9WdWhKUlNCK0dOQ0FoR0puUlZlaElzSjhnMlQxcmhH?= =?utf-8?B?b0hqTWIzamxPSDFMdHR6bytUQU1BRk8wbTdIVXRFd0E0T1FkVmpYUXFkYW9o?= =?utf-8?B?QVhHRExra2hray9JQThuZ2xpTUlFcGpTYXlFNHpncHE5TkZFQ3ZxRjRqaUw5?= =?utf-8?B?R0ZES3lSWHY1eTU0MnFQS0R6OXZxVzJTcHBIMGpuSTN2QXBMNFBneEx0ZFIw?= =?utf-8?B?WWo0UklGb3FlV0JZM0J2eHBRYm1henVuMmI5OUZvYVlvRUVLTm1XaGx5UnQz?= =?utf-8?B?RmJBRVd4Q1RLZ3hLc21Qclg4RTVMbWt5NzAxelQ0TkhOMzdhNXNYNFVrcXJP?= =?utf-8?B?cFphaHNTUWhQVVEwWmtEU2ZkTjgrVzFGeDZtZGI2VmRSMkVCL1U0NUQ2M0pu?= =?utf-8?B?ZEYrc3ZwN0NqOC80QWdSZHR1TFczWmRZK2ZQSjVmL3FrNW5DKy9ZNmdNVUhX?= =?utf-8?B?V1NjQklrNitHRkdLMlg1aHdiWkF3bVZxVTZFZ1ZTOGxSRlNCRGJPQUtYZnVp?= =?utf-8?B?TzlFeklkOW10d29jMlo0OWRmMVV0cll0VG1ncXgvbk56UTZjak1Vc3BNNlk3?= =?utf-8?B?Y2lCY0F6Z1JabHkzQ1BhakpNWlE1TGlFOGFCVGIxQlk2bTRRWmlrdFEwQVMy?= =?utf-8?Q?eX0wT3llVd/an/YeSqY99baJP1L9DJpZ4=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 5:DqR2D6/+y4+8zMZwjoa/lVlETAOdItIcPXPy82hNfs7YRxWDKIs0aNVZP5IRkTg6swkeZ7AKzf6cJ9KrDc7rN8WcbkaRmwwE0Jhh9NdKOE4n4KBSt6bpzO4lIGU4Or1sm8207zkB7j3eqhav+kOQkM+dt97RqiIIl00vjbwwI8vywjLI428Zi0YjV1/zsKPP48aJQlW7NWPJVWVR5iHCphHm8p00P93zxzhQuwVVt2Fivx1UP2A4q5KhQEJbgTNRM4mhPz0sv4z2QX1UQ+cMM2xGdJHqkjMxao8xR0n5bF42dygNhT/y/1HSgeFYG1Rn0bJJ1khVOOFYivyxdTr0uyHZ7fKt32prvP8VVTdwJor+lql8XoLsd0Fj8pNFMLQ1v9IRYIy9KZncYLOLQPQvEM/bC1HpVhRVqx9q00NXzotlRHLT4zl6my5cEi2HCw6+h2ZHfg4y1QXhQOfOuKCtSXmFVQiHEsm961GVC0AsCC0d1j6BKDjPAxJsvUYq5yh3; 24:iwRQl0Qf/EK9VlJtRiA79NM9NsCMA2CjozWTVjtGXb+XzEC8izUGBzvHWyhbTO9YYxTaHPUfUiGIN7bFpPsf2pE/jQooNG8EHcgQdMO/bmg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 7:RRjfRawuGJNtfJFy5Osbntng2tZ4/Yzyd8To3AX1NTX2w1hVOhirFrHCReZ3OAE2pcAp3z9GNbqOXxnS1lQY8qRPb9Y4GR1pNI2qCuWSr4FcDL6Gvi9O4UuH1Z5emIu36DA7tZ9K7HRH6Fu+MhVDjKusG7dNnJnBLW77d4p4W/TUKTMo9eRc/AAQ6J9mWD81CuCXGtgzI4KF3+uDQYgd3J7Cmucu7bkbcj6n8NayF7qUIu3WKAP4e0p+om1YUdAl1s2pFnIs6c5drUZgxLLcZp7YOd22T1GMf1OkUyNFjqC1PDx4sZJJJmBZS19HvkVsbAEo9SDMYrzJQHZnqXuQrzF0ttmHCnO6WMKTsae/PYb9PYm7qvmv2ahA/o5bgRmNK1l73rN2+YAL6OV4KgLI2zTl4HN13fOuRiWJV4us98F/1rtMJTIDLHhM47EXj0eTJExw3YkM1kZUvhm14enwqEBMocmuJitZ7vYhvU/EWo0OZQs5e/QoqVoZBZ2Sx2jLqfvGfxAbpIjmfWg0NCiZBOCzzHPYUPxXQUavIBWCQooHFfj2QFAkEd+PEGZFRbKc73wopE1dPi8N5uqBeoXrHtApCZlW+g1W1aqPJxoV75Ay0V10b3y/q8oFdp/2E0K0twSsGBRpxb0tl5pgA2AMsQIooEq4bgbW+XY/8fvoTKDDroYmHxjq3mMl/4eeD4iZxaHd45q8J1IHy8q60/3cyMzA7acFsKDDXQ1nw0bqHOjgwmNGD3SUWZwJsuUv7+Sko64VfGFa6ksgerS+3kQzwIdYzlAOxGh8nZDEzoBMSB8= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 10:59:10.4927 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1028 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 10:59:13 -0000 On 14 Jul 2017, at 8:02, Martin Thomson wrote: > Just an aside, though I think Kathleen already made this point:  If I > were writing malware, I would use TLS.  It's pretty good at what it > does and it's hard to distinguish from legitimate uses (there are some > trick's suggested by McGrew's research on this point). The bad guys make use of TLS all the time, including lateral movement within intranets. > > At the point that I have sufficient control over a host that I can run > my software, then I would pin certificates and the best you could do > is block me.  None of the advice about configuration of trust anchors > (pinning, overrides, etc...) helps at that point. Correct. Which is why it's critical in the intranet context, within a single span of administrative control, to have visibility into the actual cryptostream. > Most discussions regarding breaking TLS focus on the breaking of TLS > to *prevent* malware from infesting machines. Correct - and that's the wrong emphasis. The emphasis should be on having the ability to monitor the crypto stream within the intranet in order to detect and classify compromised machines, because that ability is used very heavily for that purpose on intranets, and has been for many years. ----------------------------------- Roland Dobbins From nobody Mon Jul 17 04:01:27 2017 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 1D09D131B01 for ; Mon, 17 Jul 2017 04:01:26 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 T57t8n5DizI7 for ; Mon, 17 Jul 2017 04:01:24 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0127.outbound.protection.outlook.com [104.47.36.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D18D120725 for ; Mon, 17 Jul 2017 04:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7p+E/iCFzwSYmL/VhmfJDcsakZ6DxsT7l0RrecHDhu4=; b=nXtW2ab5bPK2lILubsKKTdhnA8uUY9FkerYsFzMX2Xcu4G3KIJOl6wCa2bLbDEhYCzHmUZY0pC4KhCqWXGGhivB9AHnpKjSp8yTCT0qYsP6Ja05P+w+PnVKL7Kj62omXw3YPEjhuDru+IUDnAm3mlTKSVSjPWzMs57DNHvGpozU= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by DM2PR0101MB1040.prod.exchangelabs.com (2a01:111:e400:3c18::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 11:01:21 +0000 From: "Roland Dobbins" To: "Kathleen Moriarty" Cc: "Martin Thomson" , "tls@ietf.org" Date: Mon, 17 Jul 2017 13:01:10 +0200 Message-ID: In-Reply-To: <20E2D146-07BC-40DA-9DE2-031503916F52@gmail.com> References: <20E2D146-07BC-40DA-9DE2-031503916F52@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: DB6PR0601CA0012.eurprd06.prod.outlook.com (2603:10a6:4:7b::22) To DM2PR0101MB1040.prod.exchangelabs.com (2a01:111:e400:3c18::16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ed2d7910-095a-42aa-3242-08d4cd03291a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1040; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1040; 3:o1elYRvEhF4bqqEG9gPwjSDvNNa0ZKO3/alLEZJnpI6gnaca7PjDsN9rCyWrM/IOvVJS3I658aWTbUSeKDCOV1xCZlL0Rir/NIONaFAkBPw74Q0npuKkxiK5cz+cnhnFDM6eM3I1svfrtHGBtpMWFY6o8GUpN53ekb8CVjWMe687EiFZyPfda1hn32SGZyCFypRKZvsABLUVTHUGKT9+IMip8rPjUKEZ2QlVXJHzTYIALsrzw2D/RQii44yKKsYh/AGVMQ/CMyx6FEVZsqmVhUaGL8mcU0Q6JlQRJrFJIvp0jmuz7FGAx5xdC74fQaiia1eYfM77KmAGS3EFb7RxAADncLf2JLf2a87PHb8SB/WNFtELNN2XtPWBdXUjSMfVG6uGNtIjHCaaz5p/k9EHk1OigKa9y1Op4crP/Xd2MLVozDgUjfVG2WI1ltn9wLl77XTne4uBMd3nXmZx27MIWbqrwRvPuOp9WnjkY1/FvoVHps9H57nMCgVzfKEmZ06XpkNIc0HWi0XcLy7IS3m9i5blMz36e2UgJuPqMZlwWcfAqWUh4AcmikwWFAMBIQEODiXMhq+2/wDFqfH2yH5w8WZeUPYOLDsUB+ctkakll/4N2nDCnBVEzxRgaQSYMip50/xeLjTQlbb+sRsCBGemIc1uNo5UvMbBoT3FNNNCOIqjbvtmGfTCU7uLOuJlclAGrmA+Eiyg9nouMkCfTUoV1k9n1hu9wm37/WXVAPLVnkQ= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1040: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1040; 25:L90w+rUYNrJjqXMGcKYTh3lqbDLC0hS++DPcV7L9ymiYotW05Hlv92JFgScb61R+Hilv/w6gNkMuTBOzp5Uaf5baImfj86PRwfNoB82vx+KWmsFu6grICGrSgZAv+zjoWrDxjeY/FEPZkPG9kAxhe/a1HDDS1WAOTmde1/Y0PDgIuRijceKpIbxHcZPGHJvkElktIZDHQtwesWrrJv49nsn4PPgLoLgC4c5NsN0wbvg/yyJgI3uoQX5RZ4DkLG1MjKCBoKPfcgTy4TXBi8qwNiilXXjVSUOH2oo851ip2j1MjblArIBVbjtsVV3YVdEGz+dMI9JMYlVePC+TgJegL7P5OMTLr4BhxXZDzE8M/Y6/p6ABufrVOVaEHqlsnFrGITLrd8/0Bm/IANoWKUzuPTmIZEj863Iuc6i5HpTQzdQlKCOo7zoyNAaHKdxT3pq825FGLuN58DakdT+5UKlo+aCVSnn234eDyxB40TmEPsWte5Orwg3UBYhjdXed6Hx25NaORE68quYzmXKZlXJRgLxkT0HVtAGEuXKC8wTyJD4FfN9GhesSwjNF+pX+Zp1Exi6uQQyv4triG9qo8XEqPDm9LZSuhcjLKQovsm6Dfs/GXukLVC6NJzG70usw6hcWeaz0IdZ8RvBK9yqnGh8O4efHyb/6qhZ4li8pizhRj03CAxsNuYtfelfprSDG63eEeGLyVf/0TR6RJ4yyAIwLZjZA4aCcDnyyMPLyFPbzsNACGpUv0VJHH4Pe40svSCExuxUwVqYz78k3GJ7SMOttx3NYj1OFGNrrcinN4mdd1pPFlDCQj4WVHdmEYAjVI7ZgQlouWXHUiylv2czDZok3YKe5LBs4dJh/fOHZbiRNpFYrbt8UhNNFcZNSWGqDLy4gx0cdJlI/OPi6fix0LBILt7u2bTUMTkyVV3VPOB+pyic= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1040; 31:xde0HeSqWfV1kn9+nya9RXuC1cb/t1eFz1MLqK/4R4ABSKgKIj0OlhcKlU8BopDQhtS7NyzGo1hepsiNcfki4hPGdwjF0JMhRK+V6QBbVaBjGGhsYiIb1W1W0Vk8cVsUVFW9Zl/kckN4Sgj5nLI16EVuZgKUDnQY03D+hZMEUeSjYE8cPUbFyGJ2vd99AU8dDwV+1imoU0ZR/sW4B31JLcc2ybxzgY+/2xohWmPYZKvboLm/sMo5VBttbF62iADnvmEVN/Wh6Vl2tPaqNNAg78x1f74V8hqCXkXsR8GUnb1A07b4gC1jrV9m3N6sagJs72Yjz//FrlfSASvNLwFTsO7wx5fs/vbuxsjAccDBW7xfQg+4dixyPeT3Gz2g6tGNilFTrXCEi4Gung9SD4P+UlAbJTYM2wKuHgQqQu8w6Xme4RucKwS/btj5pugL5J5sJ2A7f89nYakD0WfcfxDAuAe/qX6STdQop1ZJXue1k7os2CjWn35DLwzArDa6qu9lt79LEsrM1zaYlEoAplNAQAuo1cLC1ouNIrF1TuYI6A8h4JXxaGCc48vBjQeMm09q5tu1S7xF99xk6bCA59CKE4RGTzioTPK8b0C3hH2COAjUzKtc1sOJy+yJL9mNg960GQ+uDlS7YAqxs/vu82kVo60BcFTeZN6usntwAKoCI4dX/gpVpismNylh7mWAb/zl7VyrQfmZeJkkEcVl6GiYWQ== X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1040; 20:yaDp2g/M7Mn2Z55Ia6NuxcC4EjfNd/ER9rKZKFsq7nKXIwuoBSA+GgfVxqMyEDN1ZNeHHnEZH+mx8cNlECshsE5B2f5+gzhTPEn2gmROlQr1UrAopI+8B9A22fWbAp9rhfTYOncyrDxZvDVoSZP9Jfj5euzzF+iSG0du0b01aKBKxzG+TwAJWAKwZnb+IutHdru9mRt3M7Tmsau9g5kK+EiF/PxtB1Nn3PJiT6+kE0/X2ITDtPSg0+WBc91moawNiLlYYxaW76keUinMWJWN9HhrNKS38MZ+1QruE521dfTHI4QqxogaqfE70l6JxBmTgm2KYWr2m/28Blr/gU+xA6nZi7gbuIM+WrkPFfb2ESFbAtf+MhL+thJk3NESuvtBDrEV4daMZLn1Y/DyP2sE9F8zTfqE6FlMdR3WVXPuXIcbz4iDDF+VdbDKCQb7suL3XW59nwt5/qiB1eQHnJRnxYg+pJEAw7PE0QCeUWQW+3fHccmbTNd6bq3LvbxP1Kur X-Exchange-Antispam-Report-Test: UriScan:(246478575198768)(236129657087228)(48057245064654); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1040; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1040; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1040; 4:lQg7cOr0Wk0q5TLkfyCOBpxmBmSH8RzwLy04w3We?= =?us-ascii?Q?hVCeVYnkxDCYHZV64d0hpAqz+jxY04ZvHlmxxLQy9B/FsCaVyAQcTBkpGljX?= =?us-ascii?Q?t5UZ2f5LHBEHrTXvO8TTNWIJO/Jldxdi2FVaOES2IybIHhQPBt6jaNXirO9G?= =?us-ascii?Q?V/MWUbB+2eqifQhaOkcGduNbD/dHPZLAS4lWS2SXxMyR5H+mlBv7tqjNq4mN?= =?us-ascii?Q?gEKYeFWIT20pMDkbMrb8/r+MpPXmma+b++CVkfWD+Ywk1SK5EJqapnpLE+Im?= =?us-ascii?Q?5AFICRbxaZ54NgG8vtXVpJhHSUfehQ4FGIUXA9QXJY/JH8AjA0pjrm2C+QLc?= =?us-ascii?Q?ixFpHWdaSvAPWnpXEm6VpQo/r/6ERJEFUPmLkaljU+oYKF6Xa11ot2SVNs+i?= =?us-ascii?Q?g++tzAKPFIZ+QRRId3qH8p+23TIiM0zTWCTayoqia1BiKviRabevYpMIPYBU?= =?us-ascii?Q?RKMhvKudCHmV4nRdOXDFyqxv2QnqHcWm47JFsl+vajgx+/bT4C3rquhbxVq0?= =?us-ascii?Q?Tb65bU8LKKOatzwx8Zc2cpUZM4WcLLJEJeiGi4mKDZvEmEsyHvb95AYOuIZl?= =?us-ascii?Q?GoK3X9QdWpC1ML4Iw0Mx5PuN6PD8bp+OUJ27ir2V3cTj8EXmCM2xNd3kuoPn?= =?us-ascii?Q?igpDJMTR61fIo2wDqM50m+JGFIvMPQ5d7M0EdpoLlZzOdwUA654W3tUcQM/1?= =?us-ascii?Q?1rA44DgaUXcMWkYFIGd51KHpdpReF7WEDU+LxouGt5P9Brf0GVsAdErSIDgl?= =?us-ascii?Q?wxfSz2cDF8ay1LbpOOHvb6yTyWyTfWqQC3UGkYEz/PccTuvy1m06eruOQmdX?= =?us-ascii?Q?Cfcof85UZzOn4Jazwkwxj4tK19NSRzWIuct0GvLJtdAH9+bJIPT6U2eKA3Ht?= =?us-ascii?Q?zzkV8dbAWEdTBl4FnB72Nu5yqEy3GXVa7p5Mggaj4Wi3bX3ae5G/wJ03LPms?= =?us-ascii?Q?3j16hYNUfnJP0Pur1m1fz9DQSbgLspOv0nOAqje3xvO/iaUZpB+ZWTYAOQ3l?= =?us-ascii?Q?XwQbHe6X8xtYyQQqZ6g4qoqily+ryU1utALW0oau5HXdxnXeBi/Oh5z9WUfO?= =?us-ascii?Q?eZFZdjj/9qTAOqDdlyaFEpfHygPicc1GPC8ZV5l8bRkmjGancFlsPgLIhbpH?= =?us-ascii?Q?WQ5+nKsyXwt9EjXqQTJYCLAahNc8A5CcAzS1bHath9x1rs/BxSnDJEwWo2RJ?= =?us-ascii?Q?f6g+jw+eWyhvUKnJXCDDgMUx7JExNkGbI6PWErU6svebRLO52yJFpRP42ahG?= =?us-ascii?Q?oorc7z32AKO9BFqmOT2pPNvhGxWqWtJY816jK8EQ?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39450400003)(24454002)(3846002)(5660300001)(86362001)(50466002)(33656002)(4326008)(478600001)(6116002)(305945005)(2906002)(7736002)(42186005)(50986999)(76176999)(230783001)(110136004)(6246003)(7350300001)(38730400002)(47776003)(53936002)(229853002)(53546010)(6486002)(83716003)(77096006)(6666003)(189998001)(81166006)(25786009)(8676002)(5003940100001)(66066001)(36756003)(2950100002)(6916009)(82746002)(50226002)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1040; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1040; 23:crzP48dxzNad+3pWZcaORku/tusVZA3FbWYQr4S?= =?us-ascii?Q?efyR9/7IPsqqwO0sjUaheo3ppAKkS5/YYH/xeBiYPg87ZKiIUJqIKihbLpJC?= =?us-ascii?Q?iUHpb/hBBnZ/eYlucltQ68vnEAoFNf6lpHWbN/erpjmZ/d1vY/RtQVn1W8P+?= =?us-ascii?Q?WmWihFwm0iETl75pMGO7jWhtViE+2LJcpSXnTWbtyDC/i+148CKmDYn3QGI+?= =?us-ascii?Q?XQI98t/xFZ2ZiQool9jueImRIVlNriwUjLlj//5LSuD9DKdAAc21dI8IeTBp?= =?us-ascii?Q?hN4OJ5xUBQzLidYUogoF0q5sCYHbJDou6gdh7KYSRzS3YnrhUrXKJOfCXa7c?= =?us-ascii?Q?RXcDL+Kt06xtcGlTclblQG128O1iqWARio1NHKsaK9g/WSf+8sye/iwwpGTx?= =?us-ascii?Q?y/LkEH03uIn52GTlrMnPHIvjfOM0SacknWhyTk4obBB71FtZUmsxK6iNRj0p?= =?us-ascii?Q?zHKlhaNvKzm7IJQ9Y5iJLIJ/gLDn1vZM2XDBNCTAYjI9t7aSnVpc6xVMZoaI?= =?us-ascii?Q?MI8EO+IrGP3Zp7zBwakyvHcvIBD1kyFrzLVfbMf76+m+AUxaE/gt3mZgrjlZ?= =?us-ascii?Q?nQxcPveQQOnCTgAaqBDBZ1RFDRLaoSJWpzKbThe00lnqqjFDzDkI28DCP3WK?= =?us-ascii?Q?5L8kJiGhaedAvzQJlrNZRh66DvSyTHxgkT8xQQbdcIfRFvKAsA36c9liCcOu?= =?us-ascii?Q?jWb+X/PU+r+m930Uo2TeOw82pXNmJf9HbNMUhySgh9hrZ1ISrnQTFy/kdit+?= =?us-ascii?Q?lDRveIj8lJ+h+G8NlwqJGM1GGOVpp3iQDIo0aWz6u+TIna2fB2uo0eFgu0k+?= =?us-ascii?Q?tU6o+7gnfCDWPy3XCrJRLS0+ec/UVWaSMVDIt6T0Mm3jgvIvuHOnwDa5QAzr?= =?us-ascii?Q?tbMfigkPdz3gvuIGSEUoUiyo/gFKCOHV29EtwtUFa9CxkCPcGZoJJT39NPtw?= =?us-ascii?Q?dmFwBVr+tNuFUuOKSDEWZS39cw2AyPRwVHeQZ100UczYXGuiheSy3QJ0jw3X?= =?us-ascii?Q?awUnclBGFjAaaSNKJ3NT9feEZy+l+t7vNGrl9xBzT48a6YJv6z0SKO2jpKor?= =?us-ascii?Q?FO+5rbbASeDpoELvC7OQc8DUYjLFm7du7y0MBaf/zRSwjelgKX5ZOnX+ddYv?= =?us-ascii?Q?tinniXw+mCvvrr7l1QzK4lC1hjb8Wh4dVZK0vPm5iKVqxKEUFjwJVqkT1siP?= =?us-ascii?Q?mG5RP/y9j/9kproSDiJV1oJbKXqDUfvtBfihd2hguawXF4qUcgW1X91Nu1w?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1040; 6:kUy7UHN7jjlmdpgtdc0nh44b8gfQ9NXG+R+uMpF0?= =?us-ascii?Q?nUmsmUHTlf/ZZUJ0Dey8QR+xtYq2glRYpZyYEAdiwDv4F9lcV1XFhrLXWyUt?= =?us-ascii?Q?mvc6mdi5iowi61O3ZaATMIvSFZ2mPAqhmxmWpFTiEfJJIOVebmdqFMpX/3c4?= =?us-ascii?Q?i0XaUtFFoW5BEq5GgIuqeIFLg7CLYANZLYNV5+gY24m0xmx7HH7JexGBJ1QT?= =?us-ascii?Q?ct2Afj5CeMDDyqvxwoSMBDOsEqJ7YvSo90Mk+fGX53KdcqxzKiyUwq0bYMAA?= =?us-ascii?Q?HhLuwYVY3pZHMrcnll7AC1ihxepkfKcOF3NqRjM8JWkSVfa0KRnEYh5tGIX7?= =?us-ascii?Q?l1E285Ran+ncuyjoXAcXixSHRGFOLQ6HnzBkC7h3jW4GunjGHAxUZcP85TRo?= =?us-ascii?Q?esbygAJL9pT0kO8bWAzUGm1XHMwOs+q7Kw1ft+ejY0LIzIFTBeq8L+6s9zZe?= =?us-ascii?Q?T/aigIiW4sHwvGv7OrumRPoY859dDvqA8j3IhuCFip7fzRvYZqQ9x5RtWybl?= =?us-ascii?Q?9kMIaPo93qyh/SJGVQbnQbi5Q6mUgdfSy3t328Js59k3duCPPbGkZDkCBu2+?= =?us-ascii?Q?HgoK4ek0wm7VBqLdWCOPihvgvV0L6x4P8rpLv9YmjJHKoNTEl5cu6S36iYzS?= =?us-ascii?Q?H0M5LafPppLQ25HWYjxFHRDvjtFYZiwc0VuCWvyxNndR/FxaABvsj/5jOQ6p?= =?us-ascii?Q?9LYfhQh00RDug+1ZCvcu/THt7fUVFepqlKWlBDh7B9aE3Qrm8n2jkfODjcs6?= =?us-ascii?Q?GgoFsmzZK2kHUlwzj4at8/K7YVWZro9qVQBHR/z20e0cbXeJmMYD0bssI/XA?= =?us-ascii?Q?uSzx93D/E+64bBEHhLMsQMHW4uf9u04xmlrWCPUiAK0wQi2y20WU4IGH8idv?= =?us-ascii?Q?EXIke5+U9+lAuooRjGYfLRpGTTpo2cfbSaIc4C8vBZWZk/kWU4ur4aJ4EG9L?= =?us-ascii?Q?9LVRCBTHiQXBeo9QOeMiloJSGCHfsktPgDXy25eeSFm3sBn3hVyN3J3PVor+?= =?us-ascii?Q?L1Q=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1040; 5:QYCtuLXtB0KDr+FfGdE38Eq5tJ/xu4dYVYl46W02LfHUMvyOIRmrYkY62wPhRqLb92sskSZzrqSFyq/wT22rZNEBZgK3B5KKqiY+Af2dSJMXB1ypBHcsEtWOmRYBVooogrVh9DdE7gNMmlrl/drRh+VBRxbIeZjssa1m2lMYijLy7ABICDpv9kJj3NSqyaAam+PrNwXjVlTY8DtDWZQKzeyrf/b8UMam0pKfl5g2si3w6HtNuf0fiS2Wz40ijtFPPJtyxY9cGFRT06QtDzxF8J+qA+v1iEEYxxvplhi7UsUprmb0OOMpNY2NeTUkzoQX+eq8FXqnjRPP/d6yynncCxeqSFxrJwcFhHJLb+WNW2BA0+a3JyOyyPz9MuSoo30kKEOa+CUIwXekHKo6BOw2BM8gU7UdEX8wUtb9EtoP6WfrEhjiYzm3KkL4DFoCKv793ZvcNA0N8w62JN2W5nZNlDAuvyLSRM9cbavw+Vdmb3Og8Q3aAvA88X4MlBVflAAS; 24:rHbApxIGBVPTR8FIy4/8zP5QHHHVkhdA82xOweN3zRCmLdvC0KXNfEdOK8Jy1bdCwBFEFtiKVI/EEB8w8VxLgHVmfsXnmTRMnVXeQkc6qKY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1040; 7:icdZ/CR3tMZN6sA2MqpMUaOFWvRpS0MQzzGVat2xsoyrzenOSda0wWZ8sww/UFY+QZnvYmJ0DoJGY+zOzj2H1/IsCH/A/zPG3XBB+dgM+t0/SWexVLIuZBap3Vthqm8fQ3i2AeGDI2wpnTNUujoTJViF7QskL3hivy8WyU8/zhh85D+5Atbx3KKIAsdK2TgoVkSMZ8DzLGi9s0I4bOaW0KcdrI/Q3YpkMv5xW3FbR32Ziw/56F42lPVAhcQj2NoUWq7Qgq+teMZw09c37TQzJ9QVRJIbyXZ2Hh4H1/ipvwRHLlkanu3fSwWbYITp5fXaninmhhHlRHgPSqTz9lbU9x0grDjm48U5Za2S/BFOvQdXGpnvvYOEmQfzbuJYB6gG+kp8ebMi/i3eHnG6XjihT7AzxeMwZQMGjadFYQDiAZvZDbOiiDWK0zskar9IEAQIIkbGjol/Qntzs3kL5eiPtmMj0euRu7+9QGH7GQ+xqN1RzJ+sRcGfRipswr669erHxFOnLByyA19zWZ0YhqrkS4aucCtdvDUikkpLJP8XX1DHqJxX3hbVJV6rlUK9eJkt8NQUX3Gz1ezQpP7nf+WJwgdU7xzCS4DOrJBcLKlA9VIMdqpUXYQFxps3/uWJ5HVHJALOJljPFw2JtTkePrPNB/veUFoONtwQLxTQcLjASvN1di5Zohgi3VowT1SI0nhXdOXxI0in9bot0ucxRClmNo74FOvHDq18BIYB4t4ikf6IeSRhucwUbNttLDhITRHLRE1nr2PuqUmRasNahyqXw7/bpc/sfkOeQaLtGTqxz54= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 11:01:21.4093 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1040 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 11:01:26 -0000 On 14 Jul 2017, at 12:17, Kathleen Moriarty wrote: > Otherwise, with the proposed solution, your still relying on > indicators of compromise that can be detected using the encrypted > traffic. Actually, it's often important to have visibility into the intranet cryptostream in order to detect and classify aberrant behavior which can't otherwise be detected/classified standing outside the tunnel. Organizations do this to identify compromised/abusive machines on intranet networks all the time. ----------------------------------- Roland Dobbins From nobody Mon Jul 17 04:05:06 2017 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 658EB127599 for ; Mon, 17 Jul 2017 04:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 0lPpa1-xGFX4 for ; Mon, 17 Jul 2017 04:05:02 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0124.outbound.protection.outlook.com [104.47.34.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C85126C83 for ; Mon, 17 Jul 2017 04:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/cmIpg1llAOfiqbe3dqJlI6gyCP3TgEtyNPRIUzvPCs=; b=mKobX7Th06YAcpUoscvfPyGwQ5EvQZ1HZtduftAbb0tT40k2t6ppVE59G+b23dtuGzrphOTi7Jh52N6km2ciT2ATd+krJR7bXR00XXHDslcmprHjYi3fanFApeXfDKnF4QiXncRZ+gdTy6CdKANWqv/cMvkDES4+xHugXxwDwjw= Authentication-Results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by BN3PR0101MB1027.prod.exchangelabs.com (10.160.182.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 11:05:00 +0000 From: "Roland Dobbins" To: "Salz, Rich" Cc: "Colm =?utf-8?q?MacC=C3=A1rthaigh?=" , "Matthew Green" , "tls@ietf.org" Date: Mon, 17 Jul 2017 13:04:50 +0200 Message-ID: In-Reply-To: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: DB6PR07CA0179.eurprd07.prod.outlook.com (10.166.153.161) To BN3PR0101MB1027.prod.exchangelabs.com (10.160.182.156) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1bbc191f-8beb-4d3e-54aa-08d4cd03abb8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0101MB1027; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 3:XIH6td7BjTj8E+J5vFMCb1SzErPN8KGDPFqJ+Uq4lpy0oSo2dSxRw0ge3TSUYsj4xPM/9uHSCanlgGvcq2z+vNcficptvFNx1tAUzguV8dxBvEpIyyCGebKHH+3V6eq/WYBD4i6wy4WXxzQILlp/EuCDKjM1l+9m/6L5vks5WKdPhhMco2Pj2LLrnzevw4+pmuPr/ApOb8tCyeO6ppS/Vo2KTTS+RJmsYMv0scWWof2RHkPgEl0wB3s+8uIIgU1vM/Zhuk3I2ZF+/VBM5S84nkq/nX2XUAvYDPu2YZ8ojNyMo92NiDazmB0eD7USp5xqz3XJw+AUurcYZRDC8Ths+DSkeRnjWDowPwkam8ibyZ6ozJEyX+5ywxh+pfnIGEbm+tSMQtosFsSmh04H4yhMP152az1RCgVhzt6tyhyg/KFgSlcVCTAAZCgNqfjagX+MmxqtxZRyMM5H/INRXLeYm3P7PqLClA57tIDITARdwAOWYSoNHe7eV3Dy3llRl1h30myLnWrheQYxhKlo3MRnPvUw7LCS9Isbxyg34qJNq1HlCuAAU7dln2yPm8Y1opdHB5gYKJQedvxzbJqFkZPxCOcmV31BSJgM9Qq7oKrEkAyC6npXhu6+z7A+nFLrQBPfkkIKec3ewOGZE3JM3ZBapDKOu0FpuChH0vkK7PP0NQXcsAaTmugVZcxU0oLCs6zWH9f5QHKLFNQFDNXnw4IIrxoLOd60cBJN5Ev/2TtmSS4= X-MS-TrafficTypeDiagnostic: BN3PR0101MB1027: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 25:j468B3Rrk5b2BR3El3Kp8pnTjGl6sek6i5bqu+MUy89epw56cvZ/lAce28Fx7X+aXAOnUh2yHtGKyQNTmLWs7ptYUESPFhdr9rb+rvNgGHht8ZFzy/SSLFHe9l01p4k2tyM7JExct0lIjji2b5x76Bp38leKjtxJld7cFZyiajV/9M3DTgW97jnQCk/s1zK++P5umNEriH5UxQLRzZuejkmZ2hhZTKINsAx7qNl+fPSlI22rL+fGAxCEQFioUMdzTNWXxbnh++k+oScNGl1l7A5RRmoCCzb3gpRiT1BvWw7Sg4VRE+NCSlL30i8ISOUEbg/j4XG9mrhSNUyjKYbeC64ZE382lhZqp7Q72jgb4llqEFkJ++OgwaLT2FWvBtJyE8hk/mCq/xmVPGc4siN7Rji2QWvB1bXR3QxKOirObROKu9JdMMEWNosGmXPZXAfFdce6tLfMLjAsUvCqnBEpC7Y7lZB/bkuWNwJXGGXCqOOtRM49vu1mPUTYS3WWmnJDR4djh/3Km0pXvOD3X9LKjxepAzx6cWgULikY63uUkgNDCJ2Keuffcs6a/L64/p0lNLm3fHe7XvWMFHUMOeKqk9e74ECKB913+U3IHjCMZ1SX9PH8ApqkuRhyyjDRXjiF4uUqB97Yig0azhgxavMd1rbzsL5BfR2dzFugXUC3sfVxMAeghKzx8NjvVOztpfRRCRHc7RvoxpjIs4Bgd9u4AHI0Ck/LnQwtLc/ps7lKIqRpBpP0TKzkCkj+MgDBc39+ZZjHnlCzvkdFTftrlRsYncAT3znoK5sAlZod4AHv7jN0/HHfZt8Mw8U1KNrUODFnebnvqzAujEaSocQTiJbKl0lNnnXePTv1b7SbQBN7104/+JLhnt3FdVA+Es/onNGzpQsGQicWIukpbojxLOreRcZ/k7DQTyHW2XPHa0mou3U= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 31:5NAnTZlPcGcJ1Pnj/xFEodUnT1I1LJBLrSPqHNEYdwFxSZI1xbUbfuNjnb5zYqnsUqYTWjRC2FEblZjzbx7sc4Vc5fcrLu3O4Rzvga0qbK+noS6Jk3QXNxR2NpzT/u0vf3FCfbSGO1IKmBCTB/CPjiS5o/FDFegH3x1YeZpQrL3eHMeaVsEHvogf7+NzhlfvaiJJvNsW8nPdh5tGqPHiyvdH1C+pfiOKQb06RfqVWEUz2r5l/q/yQ9Kfb94qmxOcqTbBkswGMLoWC9wNXCDiWNy3Br3llVHJ+Uz7NQ4CJts924AMEyIqCHPC0QoDJaS+kC19Fq2Uqjoe4pxt3C2wlsHt1SN+4LdqS0RBHHEudEytEoVfK2bdOYikJ4B7aGfJgpDUabQQwJ+N0Y6hHyKZugFVB9FZDqkGDMyHxuHUEEyG9XrbnC5Em4Z3Jg5epmTWEfie/ct2aFDdTOuLgmS0oZ7M4ypmp0iyYX/LJR+aMTvek0ry/Ol1N+EEWO7mqI+5yCnhxwMDYRr1jQ3acaZpvvxj1mI1/cyIOjHRj7zoaKNRWCwxHlF87pj/+AZQpa9L6gPDyrb3WiwYGBdHF2F6RwywWJdzW7bt7UV4eL9KmI2fWGFKPDXcg8uR2aAmo724eYWLN+rtU7IGTPz+voo+lBjGILIuGmHw6B+q3T5Q7KJt08zRY1AFBdoTZHLLAXF5/h2zd+Tx9B9OYVi7SU1csA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 20:aiwjr0+5IZyVtR9JhYADE3k0SB68DO89+VA+/fCbr37OVE0WVNwrm0tze+CBk1l8rd00kBJXgRjl7VTBmSqPJN49wK1z8u4ZlVwV6Rs4L/SqrSzECL3VcnzdO7TVDPf+Xxihnzwe1XVahsfNLkwh+UjjDwv8YLffxHfF9elE1qVXZ+P6e6+5B7ermfRGIWgiy2st3tgKNo8H3Rgxi2t88WcfE6/cIOV1hlJa7Va9t525RQOsVBmjHa7jl9njxjrpEsybCcXHv20TYCqHbtJJ4DC6VdL8a9udDtyi1PPWBM9GQlxj6cHQxy/PJJoimM+7WRMGIrSc0j0tEDhJ7/E5tSaV145UBWRCLY0Ps+ut5qdISreQ7fer+izkmKPujnJ3jK9+1a/VPshn7b+XENru2u9UtKETz5lfk4P3YbGSWaJno9hny1xAOFdCTmynVrJqV0/3xsXwxAKOQC4aHKPXyAWG2GBsnOfiPRXJvXIPsDp7g3DwTa87B9jcpiy6oiY+ X-Exchange-Antispam-Report-Test: UriScan:(236129657087228); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0101MB1027; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0101MB1027; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1027; 4:DEpIKQclzToXzx2drIVh8HQLQs66Fg5yklvwQce2?= =?us-ascii?Q?uRC+tRiuViqKgNkyd6nucJfuC1Q38V+EJC11rbfPD0qgKaWgb180RetdsY7+?= =?us-ascii?Q?WGzmGzoTHXUnGTP7lnNW4zR+j2D/lWwlw+GUJTN8Z1SfOGIUpJWJ6585/w9+?= =?us-ascii?Q?XUER9ZJtC/GKR9ifHUHrI3dqc12AichgA36BLh2RVGNjZ7PAAO8Bt0AZ7vAE?= =?us-ascii?Q?JhPGgPJqvl6eJ45oZfavhgS4qe7M7KChZWdfjlNM/i2uN5mIAJnFCq++QJHh?= =?us-ascii?Q?RnQS48TD2g9L/HsGwi/2g4dV4SZ1niF09Ewc9gP3305zYj/pb5mac9P1KBZr?= =?us-ascii?Q?pWuCeyahcvuBhR28D3tHIE4L0ijJm4ZjuqYLuVi+ATqmcCwEtHkjreeCLuuf?= =?us-ascii?Q?jdrP5WAxufl36xMZsNnA84aXN+bC2+/oYxH3in4nmUEiKep8zO+4O/U8N8UP?= =?us-ascii?Q?8qmhzW83eanMaWe2tADuPeXU2S/7USsYQTGpIDwqUqjwJYsYlE8zgoZ0SDk4?= =?us-ascii?Q?G7dObtSl0wO3ZFewF6n4SWzWNjj4h/GumdAB/CO4Kcszq/1WUewTNYIflF7T?= =?us-ascii?Q?Ofmg2klBlRaR155QQfKHungRyx1YYsUR6RZZdsJsgzqnpLTNQQKXPXZr5E9L?= =?us-ascii?Q?Xd+Rm41vm5QRYMuGbenDbNMJVEr1RbLLoii0DQyLdm+69bOCY/512hPNgwK1?= =?us-ascii?Q?s461jxTM93B57G7dWT36K+m2sPy0+m/EZdcRu9tkagsGP5PSVJfabZEp2ezx?= =?us-ascii?Q?iKoTU4sz/3FTylq0buQAEqsEiZx/iez7RJ7wDYas9CpycbPeoHmN1JWRgMBv?= =?us-ascii?Q?wZ266ZYMLDYJ0cS1jM2rHiQlEhty3DPDlLxyKYl6YJs+sZxPQnSBbFmZr9ZH?= =?us-ascii?Q?czC/ymi/pGa1aydURSzCBTEMrEySwECP6IqpEc5TP/lU/rQyhtjrYKeB0bmS?= =?us-ascii?Q?oAklUdOeL9CudzMJnk0pGyhKwCbLe3f9HTKb7cuya3sC/5VqA+rWwADl7eKn?= =?us-ascii?Q?2JbveC/NXQGyJMUTegli35MlImVmiRTUndKYgOEOCQvjJJZdgS6Z7HoGF88v?= =?us-ascii?Q?oNwjHXdXO+S9y3w39lDxAKNSRCp87Roi4LoEL5/eyUNX8xXv0T04LidhFx3B?= =?us-ascii?Q?1BHB3qQE293KWYbwgBqXu2F85reNteIQns24TYhhyR6+cjKtl7Mvfm59SU22?= =?us-ascii?Q?bv0SduGTlSgEfMRX9TAV26s3PAeVNZxyTn+p?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39840400002)(39850400002)(39400400002)(39410400002)(39450400003)(24454002)(54906002)(478600001)(5660300001)(4326008)(53936002)(38730400002)(3846002)(90366009)(50466002)(230783001)(7736002)(76176999)(86362001)(6116002)(8676002)(5003940100001)(6486002)(6246003)(77096006)(2906002)(93886004)(33656002)(50986999)(110136004)(53546010)(229853002)(25786009)(83716003)(2950100002)(36756003)(66066001)(42186005)(82746002)(6666003)(47776003)(305945005)(189998001)(7350300001)(50226002)(6916009)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1027; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1027; 23:lA6RNPUGUpYGbkSAp5DMqQjH531DVXcnSVj3qF7?= =?us-ascii?Q?u8xVGk9YUwj4UpHgreyG68Sxk7BcWvyonxnB16fYmrWVKkXkoQYg91L57pf/?= =?us-ascii?Q?nf6bT/pRahBdsP/2JT10SSC8mxU5uITIzUmPWpWYGpYSqCv+nOW/J4NC0MrC?= =?us-ascii?Q?2EmhIMhmHkCcq3AqCQm30feM7TQkt8GGZFZ3cqUJtmepHd/9/UROu385WoE0?= =?us-ascii?Q?Srsb0P+Srfrzi4mpN6GZX3cLvGENU2ozn8mgEFW/BOhbxT3bP3fk6IRL9pLV?= =?us-ascii?Q?2ao0Fa9s+3VPfCt4fGihfNEvRlGeZ09dOWxZmVourNbaZgniACUYbHJ9vwsp?= =?us-ascii?Q?qMo2oVXEoKpk9/zPVo2FuCzoeBNtn8o0wQUPiT46LCp3lkv5CtCHulJ1tMPy?= =?us-ascii?Q?sojBFVuE4sugoGU7GkooVYuDVbIuUlyoYTarHtAIQ2YcLtb5hklCicGbkcRk?= =?us-ascii?Q?CQQY2sgeIS7Fh85vyj9NocIWlmYulI0JisaS5rNi2NHituaeBJDP4S9E03jn?= =?us-ascii?Q?+nBrfDxh7R4sEX5QdxLt+6e945bMc8ReQvvAHucP9fBeMQ7IAauvgXZvqR3N?= =?us-ascii?Q?TnbQzs0YvzHor4J9tqsInMdC2pfu+TfyX/exMGKclRH+7ZyCrqM2QkdvAWgH?= =?us-ascii?Q?f+fWTX17opJSAPgk/EewUik4lJvOSop247PBfHSqkmRn2TzGXDotD2olNmzz?= =?us-ascii?Q?0Mf3B0SZPdtE2cCGPbdDs7NqNpYBwSDS+cymdRmt40sdVsP9LHPWGbAEmLI+?= =?us-ascii?Q?5lqBif4v0UW3TQPgsOF/sAQCxfLxfrpNW2DIUp5I/wtw4Al9NAJ3Cz1qg/1E?= =?us-ascii?Q?FnilTw//uC/+cmAGteykKkNsQUYTOg9pQ0ukRS/j5epqrT+bq7EP/bsrXlnd?= =?us-ascii?Q?aqDinHRUCVhosvz/aoY5tw0DFNz0b4tHqfFExzdkCoeSkvIbXE1dARcEEs7G?= =?us-ascii?Q?eEs+U+o1W3mIuOBKp6dTCRdiSEYdgFo0DXT9DaFGuU9AhENOopvN9QPH/VOr?= =?us-ascii?Q?qUClX9C3rpa5iuXs/YvpHLjmWBi3lJ0X17yilZ8PBtn+XMntQWhYTaJpp8xn?= =?us-ascii?Q?jV0UA/dskzz82q37rEStpkLj93qIUQDB9Iz4ktHJkkBrOlj7AM6CK3lRIR/o?= =?us-ascii?Q?BKOoA+wWk/tGAufDzkqonA0zKdCI9iWUyFycKh+/fVbkpkNQvG+LMXkNUiwH?= =?us-ascii?Q?rNYl6mMqkL3bsJAdJ1umayhUI5rHrJ2seeKYwlaC5ubCiz2swUIkzJnJ6NvA?= =?us-ascii?Q?Qx2DgjKY4I0Zd3o1ml+HkfsWRzlKn2pmV9ctVS+H2?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1027; 6:HcIXt4aAnGUKN9dp61I/WEYULYjMeZA+fUoddhta?= =?us-ascii?Q?k9QoKAaxjIdIe6tekGZBqZjDLpRVG92Y0nB0Dcx7lh2Egzopw/ddlU4j/FLF?= =?us-ascii?Q?FYZ5Vm0I3AzsRoJ6RTjuah58amalClst9EqNQybVWPP+6tQs31vI12yumW7c?= =?us-ascii?Q?HXZ9ZKcNQ1is7LZnx7lXTcVFABS5fz3r7yeHEPMZA8fL5ZMV7SKMqdU0NScC?= =?us-ascii?Q?1S/NtcOhfK/fT3cMPgkeHv82m5A9hHzQMSXu25o0ppQCPQX3n0ci+KWKnO6o?= =?us-ascii?Q?8iAkQz0nXlOieZa+VAuQhKFwLGEnJH3bFWznUj28J1xOtH8ALKPFWMy3Sh1K?= =?us-ascii?Q?KBNyHl2V1GsbQOweaJMlPnPgFl49Aaz1iuDDjS19XHgxCZw9s+dcDQGB5ycT?= =?us-ascii?Q?GHATZlZUeOWkvcxFEfG1kZApvh1zRqypYKOisyNAeRh3Ybqoh0ho0gqwFUn+?= =?us-ascii?Q?DRNcWuH2pCOuEsKbYQNK/89fptSxFhMuDb4Xh79GSBgBt+B7x9wjqr7AcB5a?= =?us-ascii?Q?gCWpM4HDqk1MS7TIfLh6bxx3tiksuzhXyjkqVp7FjYWzg3UnFtprSQjE8xIM?= =?us-ascii?Q?2gMFIpaNqtsRiXuhvxRygXRyNru8Ng9sZ2j8WsdQY8bFCZy+nVdGxWa6ddY4?= =?us-ascii?Q?zOPvwCE0hnzuShrPGPhQZWmOXFYsESyDQm4OWzSEXczhW+abRWYrTo5XatSp?= =?us-ascii?Q?rrM6o/7c4lntI6jOCv/tmT3xjU6z8hNmvWdiiPDKczudB0YXl11r0+KDyh9T?= =?us-ascii?Q?Y2hAnhKv/WQ+zM69ow+9Psc61/Ap78UQrnF/uOgNOLjbPGDPVKfUq0LmjJK0?= =?us-ascii?Q?N7iEYPTlRPYpqznsd3eo/8SA1sq4qw8NYlR/Z8ifUnWmZpesIIyd20W7qYgf?= =?us-ascii?Q?XO4dDZodHXZ8sFAnn7/OccSJvve2W5JYzCOdl8LLsfGSMEPzqzcpwQez6lKZ?= =?us-ascii?Q?GAJdiIkreemfx6gxdHK0Ft8jA99T07n8spiwuxHTvefJQjwk9WGOPBZA2AxX?= =?us-ascii?Q?/os=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 5:lEMD37axf4TGWCDJy7u8AsLsCMtOzqX3nQwBp639gBNL+YHHwsOdOfUH5ks5CsGPq7h8lrjnVtQ8kghTR9hUC+I3RUsETqY68Ie2D2DkYcWrbswQZFgB1CDE9k2Hz0Q0HU6qB22jzR1DMnRbcT/6jkSlV57kVXsLKxucVccqM0kT49uYfi7KWDi4mc7AbBhL7uZ29Av2k7hbgBfayqQZCc/UIOGKQwbjEvO3g3Fg4mG0NX1kcMYPNMNIZLognPTakrjNtPHctZfrerpEk35PE1WYwl7rB8fY/PmeaoOoWMtjKDfht6uN+SsWPLOqQ5bOAu2Il9CT31AYNnbiZmDgeR+Pk1+ZarDZJ0uJAx8Be6GfRvfIXQTUMuk0WvQxG8E4jh3UGD7oJs03Z51yZea3LpmJk1S8YS8pHRra/ExSRn6wF8a8w25o5m5nX5chQKbCY2z7LaEUAC31WbUTdQOVDCalS6IxyB57fxaKG1ykpkEayV0+V32RmvX6rt2Q3NRA; 24:GqRS8Mgf96chG0X/9q8GMcYwzM12O3JuuH3GYgAc2+E0YVAjFvwb9J2RYla0pgvkTfM5rC+KIs9R1e5VpLWl3gfWxAXlj+owRpr9N4kP2rA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 7:mifw97CprW8TMPpHd4Ss/mKWAXI0qgSFuit3wN1mzc0OUgn6fyDqQkjca8BZgWjPyZ+kaNi0eAouPZYQjUqJ6TC3zAWGYyd+U772gmMtV4P/3XKypdljbBa2DEUo0Lkdtpl+uVmF2CYU47dXjdorjRkE2GOS4RttP/CFLd7S3rILOoJMunLZtIDaW9IcQ1bgkbjrMS76ttYB7JTbyKfeec21Y+hjRo94qtbhxZ3Q++QECLM+AyW7qdfM/W3u6P13qUwqXyQF2d5reABArB0plnwmfiFxCnUTQ6fSKKcK1z7VQ7QJHl6ZGaM2YsdEjUZM7yc78l3vtc7exp0s30UqROYSo+SiX95XzOT65Od3iXD2q4z30duF75NpqnFAJqTvv2DnjmYgo+3gXe0/Cy6bvXioKqlFDPZQiunbuTIwApJTjq7gxSVXEnJ8LDsVLQUHjyU9PIrCStaYkKHxQRg65fz7n4q/Qzt46GxqWyhS5HonDBy4qYCNeXXf/No/PA5HEdE7PAoRenFBQy6QEoZZhBN4URGwDdj/t9Eg3JP9UJ7UqFdbsDiDeLQYeUzrrLtZRBYUOcYe+lqkxfjj3Cxcx6ugfIc5Ck0gMMbfobGiQcoBdQ1YIQkToFzVnwrlDuO4OL9BEK5FLri3Z9eshguN0UuPVYHLy3ZvJqwL0oLwgqGH9fA1Ngq33RxgQkJDIrvozFiUjfVk0dEVer2w4B2hZAeB1sQdEuJH+BeNyIjzF1GvuSbEfLMM/LPco8ZUE3ysvUXpdh+OhZI5Lq2uob4G7JwUauozkd+jGKspTtOf6jM= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 11:05:00.8162 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1027 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 11:05:04 -0000 On 16 Jul 2017, at 11:14, Salz, Rich wrote: > I really want to hear an answer to that question from folks who say > they need TLS 1.3 but without it. Being able to continue to utilize vetted, well-understood, standards-based cryptography on intranets once regulatory bodies such as PCI/DSS mandate TLS 1.3 or above - which will happen, at some point in the not-too-distant future. ----------------------------------- Roland Dobbins From nobody Mon Jul 17 04:06:14 2017 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 2A88412785F for ; Mon, 17 Jul 2017 04:06:12 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 WSFCUbFMWMV7 for ; Mon, 17 Jul 2017 04:06:10 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0113.outbound.protection.outlook.com [104.47.42.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912FC126C83 for ; Mon, 17 Jul 2017 04:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+/mpF9F0W5JPjKnoQlYaqWMTYxDf0Uhm4FtGX6rVmAM=; b=naOLFH0OaAfULtktZRZf9EH/vy9t0if07/1acVrdymYr9NVFqwbYB7mKLqZWNZw17dJO4m5GGPKACHkSvPtx/8fBd3yhIxGV4GQvMQmybd4BBHBsyjYEQJAGkLu7wLhNDIwxDyuHbU6LAQzMRRRK5XnfSylyMCMo1LG3rt/PB1k= Authentication-Results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by BN3PR0101MB1028.prod.exchangelabs.com (10.160.182.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 11:06:08 +0000 From: "Roland Dobbins" To: "Daniel Kahn Gillmor" Cc: "Salz, Rich" , "Joseph Lorenzo Hall" , "Matthew Green" , "Nick Sullivan" , "tls@ietf.org" Date: Mon, 17 Jul 2017 13:05:57 +0200 Message-ID: In-Reply-To: <87pod1qqh5.fsf@fifthhorseman.net> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <87pod1qqh5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: HE1PR02CA0117.eurprd02.prod.outlook.com (10.170.249.46) To BN3PR0101MB1028.prod.exchangelabs.com (10.160.182.16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: eaa20999-8802-4ab1-2736-08d4cd03d463 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0101MB1028; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 3:Gh14AeYkmRDnRoEa5cd8HgJpyiaxbmGtSpwNQmnJ9OX9Df/cfNTqpZUUi6OsNyyPXenKmTmK7ogi5DLUMmUVHgD+k56IVpaYjqfxnTfM0vCa5/dF/320IBGlpVLRn/LS1cvfO2F7LKii3vwbXxMAAqDjteeKju7dVaFrOt8rVARWz0fn1B6k/crywz+W3UB6NZr5iAeIDgBURhl1kV3u484qtz7Gp3Xk3FsKdZxLO/eXQvTLzSF6Ts8fYpyjxDbQ8HyAczG4uzbBx3Jm4ZKoVP1rN5A4fyJkvImNr6dl9Hq2CBOGl33ELd1JZe4Qxy/yLvnaWo4FDmZ6VwZHei/1s5nDhWkJFn+ptUyMNb1LIieZtFYQkLK/iUbMzfgL3RnZbZUi58w7VFlwpHxcN2KguCkJCN7GTbLDXW9/3vU9ERNyw5WZHOoa0yCLSWMbb5ObndpqA1WIQGBRp8cibLPbQKdCQcdR4xyTgsMeZb/Hn4DE/TVMWSMTx4ko7kuiaE7BmK0WrTrnbvQwq1JKzJykp8nELMOZ6QuH3AAskik6ERhqSTb9cJwds3ssYq50ebWfTHZKiI52mtUmEyAh76BkVj45HGN+loK9JCnOs54vDMg1g+PDgKMfki40YkpNH4BxgCShHmcNAEv9uFkaIvB0NgKa5MC2rXOMorAm8GOLR5HMTTUoeg0U9Yd3Fa+pvb4s9yyh5pEFuFjq/ZQfC1gfXTHipHAFYAT+az1xALYHTnU= X-MS-TrafficTypeDiagnostic: BN3PR0101MB1028: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 25:D98RFQSFQ9ORtFuNQAatAvgmG8kOSPOCmuFB6qPP0COlvxBwfD3JwJqzePO9Rsd+yMgc6XL9Zp2fP/nUxWRHZoK6N4O6cKz0VB4QwyCEBFBCTvz+KsHgVA1iDOHvGa/53tbuL6yN4K0PGUX0ncHy9MzbFMWzNFtLyE7/mhN0ph6P/8iL/jzI0a+aVp9AMHlws1lELEt6e4M2UKcmBVOigcWQQGA7ktRFHg99O2ckeSVHQhtTlQs//ASmgsAuHsWiYzVCmhjpFJtqvyYqbMD4e8hbGruRFlgS4WZQjcVsMV9fiC3QaEZGUAY8hM0iJwN4Uxeh2aEUeJn7/fzfQgXn5k4nRG890G9AUrABjDNH5gGFQU0Ic4Jra4eyx2UQOSaej3B2tQT61HgFqjuTgq0vbpggwtiWCY80uAPGxiQK1uNM22zM1YM2wqjYRzwz3OSYY3eubIMYlnWfOPH5t+qrnVb5lhwLU4xRoZo5blXRW1IsvKGlWmqi/lbk15yT0Ys4CE7pCXTOZwnftZB9ilLZ3g1/EB7Li9evDSXm4+jzKi9+el8bKLJKN0zQbg5c7K/aX2993lrQKqW7KV70addTNVZzpRdq0nhpxJgAGwQfC39pKR9nkLVJYfmbyuXOLBxsbS3Bnq09mOZQgWmT40ecQ1mIuYazoh0mi+Yad81vCDwwiCQnaG+7PJLn1Nd6WQKXN9Mm2BD8m5AsPfdLzygedSCdFoxE9zhCC4nm2EYkvwh0wxQAXJpHQKSgRgKsRXsnYFjwU6kclKUjEBFZ/ypq+L4UFQRzknyjPVO5to/h/jK1iFu6T/AkaUTwYpPS8GaFLpeYmQCBRkMfMUNuEvOj+9kSUZzW0c1Vz24xI99cGEk0hPzN9QZ36uCho7OuZS4w5V1F7f4/lWuRBbIFqfeddmUcznsbpAp4It1uPQwH31s= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 31:rLD8Tv4wYtAtvTDBmFXlw1KLQscjx5oGkd7f/dquk/5D2Z6x6q+9SDQ1OxNLEfyKKA3auBAvN8GicI5aP+iU6ZmkE+lIN+xNf8s1hGoSYZlfDq0SCrRulDzO/iQgDbkPtvvenVQC7Qq0HOHc9cHyoHRFrapBNqlGFgUTbo5pNi/UsykAsqQStsKoiO9lq2kem+rfgEXbsl/yszCT4MbOEkEGfRBtGmaNn87nrtobcx3bUDYOkMM+emEFtC6fMuVHx2TuenHaHfi2MpUiaG07/1y6CyVRERPxgA2f6+Bq1hemJEewQP60B4/SGCbByrjugFaLpzXvF3GgEBrOGbE2yFv7NFHPJ3RmMWz/EEJRbp44oOOW0r1qxDTSA8upAu54yPyiSvGkHvbNmBmKM+Wwizjput3E0eoQtW2wXD81qOeXLV06RQ8KmVjXOgXG4+iCtGXQ81crfJnuSA1GfGX4TeNlnChUNlxS4mffLfqGGnoSIw0egH1RPRXZChK4PLyH/AEsExnuQHOQchng+g66Okl2duyWOu+OOh/D7R3a72qkdnmebfYsuSFzUF4iyBljN0hIev9Z0croyduGdCqaffiaPyCGYwSnFYwRQS5XY0T2w7rfqgVIyY6i06VL7lCJe5pDH7b/NvrzKGgEn5vj+L/ft0/3T+0NV7zcrKauE3W3QPjlpWx+/KYkQudJ0gGbJHeoP72aEpRDWPfVosng6Q== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 20:pfd4meNn1isxnpms/VaVYXKdVGsaDjaIrmCPQdz5u98/KJDQVC+GjBJRd0aZ7iyvYSFffFtJ0OhlFAFebxxK869rFB98DorFoUZAnzy1rt8SRRSzxlewreW+lWQcRmeKQ/M8Z7mSvppKwMa54Cyx4hH/OYxMmje6AELzAkaK9091ujo4iT3Idm6lFu4RzL4qZwxzcUXNdz6B6+kulD5Pz9KM/0furkqHFfJoXDMZmWxZC//kkubnUN4azU+D5gWiA6sO1xcWFxVUTAl9dkMuB+RX3de1uqWRQejvaYu/SIwa0XvJINYBT5VtLd9ucHARfZY5xIk/leCGOU2B4eSWOf1F8rxb81ARH5pKI7H8MAGtHxKElog0IOHDz2WwUxXI5ezRd+333HoDWvZ8qnPnaAXjNCHms9gF07W0VA9PJzw/poT7EmlLZnX1Va1cl223kRvIpbM07aNqg/vxp9ebTHg1nasQgMuON7C05mqrGO8sbCTxgcOw43GivzbI8py8 X-Exchange-Antispam-Report-Test: UriScan:(133145235818549)(236129657087228); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0101MB1028; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0101MB1028; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1028; 4:vP4uu46M6I+kOSitgnKFGTljNDvhnh4KW8v0mL1i?= =?us-ascii?Q?RXdTJjHBD2ZXRfi04mMDUALSYT+2JWi6r46kT9UB1OzTllOseaRDDiRiaaPc?= =?us-ascii?Q?oeVwbLPpEb9uRXbqmFFNm7E8zB/TmfN+9kUydH4PRbhvyC/xI9PuNiFtfJmZ?= =?us-ascii?Q?Q/CbO8sDPgiPYK9eq1LGD6pTEfsiz/SS2F1G2+pD5wkf5b+ATET53w6TemeN?= =?us-ascii?Q?PnYfuf2+5+6N6CKWPoJiHveDVFAViPD1UCc8ZtQsnHdb38C35gK3W+RmC/fn?= =?us-ascii?Q?kHrvkyuxQAlTaqhqK9N902xCHJtl3ZYc+gOBcUortfdpdOYtb5gyMU+ipJ0/?= =?us-ascii?Q?VfQzID2qQ64qaTuVnSEzTTPoGCF/L6vTnXg2vrz6BpP9kIFz3J8A0SulWx55?= =?us-ascii?Q?28Q26B9+CVgWgd325Ry9AG/tfNvu1azUvKSDzavYdnTO2mSJNZ5nQGGVOU8S?= =?us-ascii?Q?1bpZww+8qPeU0UNKih2fXCaytnZQESoKccM/HwyUq97NXQAaXhFg+rK1jEta?= =?us-ascii?Q?FeIe0Z98EIusYiKQ1+EJ20K9i04O/Q8AVj7cF+5cEqLRASbhfi43ek5t5k89?= =?us-ascii?Q?s8a12Hsdxewc3d7Czpb8hs6rZA6FxYtICmLG56CZKK2a5rT2PIukTqX7ORWI?= =?us-ascii?Q?rOTL9cy6a8YMvGpgrV2QcsQGGjeiqK913FiIriG+9lFgyrYtTvhgJvFUyvAp?= =?us-ascii?Q?XO+UpOdUxGzaPDRxMVWdcqQhwWKArCjZNynvrIo4CnmgYd2YRsr9ZngWQmVT?= =?us-ascii?Q?DQTNmGiBxQFU70GHLpC+Hzh1DdJ0MmWnl8Rwphj+U1+mFeN8KsTkedWeEPmd?= =?us-ascii?Q?YSSkRvsAx8f9VqiznCz8xU4oK/FYQIZC0Eh9qms1N1lmK9mzKgB9WtWjsHjL?= =?us-ascii?Q?gvjxmvW3+ic9seZfHBYBVAzrCyPZQtFLf6hAo1IVSJpRW7gtH2xMuwCEov2y?= =?us-ascii?Q?Hq0U3PgNMMczhZJDUsaZ+bNv0fwbYlP5zVap5ssAAqWOXkagQ4r9hDwJvq4J?= =?us-ascii?Q?2o35LZj140l6JnvMvoQACKPnBNgfReikcAjRur24DdN+XSqfFLa9/b9NG9ZI?= =?us-ascii?Q?V3+i5/DP9F965i5IdkKVOz0lpSHw4+VL+ajBbVdC5Xv44j38qvx8gHspc2BH?= =?us-ascii?Q?XUMUVX/3bI3uSj3nfu17wjoAV/+ac0O2EWeHBjwD24qdHRjoMVpWES8IcG63?= =?us-ascii?Q?dLorslteyAqiQzRHirbO05W3QtM5pmjHe/GKb8WWbVa0A0s+RvI8J+xhh4m/?= =?us-ascii?Q?j2p48SqVMVGjcx5EPuI=3D?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(6049001)(39450400003)(39410400002)(39400400002)(39840400002)(24454002)(5660300001)(7736002)(2906002)(33656002)(36756003)(54906002)(478600001)(47776003)(86362001)(53546010)(305945005)(6246003)(6486002)(77096006)(66066001)(4326008)(7350300001)(53936002)(110136004)(38730400002)(90366009)(561944003)(50466002)(76176999)(93886004)(6666003)(2950100002)(6916009)(50986999)(189998001)(81166006)(8676002)(42186005)(229853002)(230783001)(83716003)(50226002)(5003940100001)(25786009)(82746002)(6116002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1028; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1028; 23:jC/twBOppbVDPQ8/rEikeVfsDN/+evxe7QqDR2S?= =?us-ascii?Q?O+IkNWtuyelMZdiCbdk5p9rs99mRSXW9vv6k9PRxvMkNl6apmjgg/nVYU0Sl?= =?us-ascii?Q?H86IfrdeEUoIA7xigDkwL+rauPxhWsSafostwBS/sSoWA+EMvO+2dvT2BG+J?= =?us-ascii?Q?1Jt0VxIwfw0yysjcubjwRCTf2PqhZ19ufMskb1xvQjw7gDPf+at47s7AowiE?= =?us-ascii?Q?W6HGm7x0f8LscLKqpKC6r5/3eneaBxNQzbz619hlFUZwl2wqDGXMXTVyGnWw?= =?us-ascii?Q?5g+aXNajb4UVkpdoj9/oFzDJU03u63D0L6MQr6fSQWhU5jFb/kiFKpFluptv?= =?us-ascii?Q?HdqfAs05Fv2+EmcFcfI82HQ0mVUfFDo4R3BSYF3tCzjMXPHZpb6qVLVMTOLn?= =?us-ascii?Q?nTX790bd5UC/IxY3R/oTgpf0cZxtB/c7SQOXNol5mZ/KXU3Pu0YuDUGBkYX0?= =?us-ascii?Q?yceQdiLxVPXq0N0SGhFCIceksshmKM05RkgaKn/bOCjpTmmWwkEOE0wU/pAX?= =?us-ascii?Q?PWk9DicRfn6ME8SenLGCtrSM3rxi4SCZ2OiKAdURadg8BQl7hlocof7apiGZ?= =?us-ascii?Q?1NzdiIKgK+wAdLg0fX8N6elGZ+rCBixr/chz3PCMFMmuTfsaOBqegYsSJI3T?= =?us-ascii?Q?KvQFuyx0ZDWpBkshv3ymuuE5xDs3lbH2Vz77W80Y7R82IS7nUlQONI8bXGb9?= =?us-ascii?Q?nqMro/6Cv3EeguB0+vhXdF5meJ5zQ7759pbY8ZuHOw2n/NxvfkjozUsTdUiA?= =?us-ascii?Q?Db9c9BF0m6QuKw1E2fbalQ6TQGulUZvXUnYUhdlRTjMM7uWpxqsewytRm+yN?= =?us-ascii?Q?hE+pJ4Hfh9y6XpQQ3L/OxVPm7h6H/OV6CgJbtAlBZVtqgJ95qEzLTA5cL5e7?= =?us-ascii?Q?PVTU8Iz0D42oOXuOPcgUqYKX0eF6LVNCc8yi58gZAJ184msFGqXgRo3+p3YE?= =?us-ascii?Q?kSZJ7d2siNbYb1z53oWereR+7rb2mCrtyc73tePZ24uPFEibiv9f62EdghiD?= =?us-ascii?Q?ynPVJl1LqyzixIjQ+zE7iqa28Lq+13qDRIA0XzUrv8TLj+lrW7g1RmjPY2wA?= =?us-ascii?Q?EBuM4+C9cYOxvQw2aWE6RfcZeB2fpLo9ecv69zjmck3gV0K1oIkD8YJhzAPv?= =?us-ascii?Q?IhVSyJGTttqOGAXnoDFADrSD5jdX4tbZa4AdBdvfaDafGmJ01/QDUPQYskZ3?= =?us-ascii?Q?PijO9a2Ks42hKGA9yZstncBE8UXHjzmasD7XT7/NztBIJH7qiD9M7csFvn94?= =?us-ascii?Q?m5afpdgw/wr1boKgFp14C2gLOs+KxG2pYgtMmPGN9?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1028; 6:R9DrK0joPMlXX0G4obpLk3iE2Dvcs/XHUi6W+2X8?= =?us-ascii?Q?EEbbvQKoUi4jF4Fz4FhlQa9UlU3Pa48348A86EaVMVAxBTq4J1NkuYdV0CBi?= =?us-ascii?Q?wkEvwSZbn8fOFAJfL6H4j7HFULqQDn2kjMx1g/a8e+Ian69ciBrZY+DADyzh?= =?us-ascii?Q?TAIgoUzqLdzWXlOhhpjHRUNmLvfEx9aGErZfAB3BHI4mN5tiMWO0p4m3Vdxg?= =?us-ascii?Q?3P0Q30UYkt74mGTVgRmxAH2tevcnl1UHoZY3QDettIeP8+h4+0k3BPJKQsU7?= =?us-ascii?Q?5qfHgD3X5hTiGEwwDeeIQlnipjkfG8CdmnwLhN98f8PSKtT/aR89dxqxgoG4?= =?us-ascii?Q?umeh7W7Li76ZtrePqa2yyDKlyvA3hUnFVlJNA1jzLy17pALy7BRb5Jqco4Fe?= =?us-ascii?Q?rVkIM3TY32RHMq7ypCYPWF6oC9Y9uHxpIqgtFhOPntMx8fHys8TJzM9pyAB5?= =?us-ascii?Q?4CNr6FxYbYDQ2IXdNnuSAjM4azpjrMJ9Al3LsiP8rken726V+pY+CCeiHf21?= =?us-ascii?Q?1FgnO6OEJ+Yh2QGP9ZTMcfbnT6L7VnzJ6wdmn77nKEAmScCbwC3hdt3vWmLj?= =?us-ascii?Q?JX031kP3GmKr6GWX6Oe+cchtwc678jo1tD9/biGoQhh0MbpVyPAxULAXQxil?= =?us-ascii?Q?/FuWXTwO1W6CGsAq0SCSlCEXBG9B/Vwow9JVxcgpglpm+XwOKsCl7hTPDXIB?= =?us-ascii?Q?VGZMPvTZ/9n3LEagwXdatkLSgCAP4oZt6+tWOfGj/KPEpP1e7+5TjO/99JJ3?= =?us-ascii?Q?N0Im86Vxk7cBKqP1zv0GUAvbHksD975ADu3xI7rk+ku/ey0K8IPNXKn80sAP?= =?us-ascii?Q?WtVbgVrnzHY+WsTPBUa6oHxnPMIQ0uUcLjvy7dIEMENRPQHGondZX7ZOtZFP?= =?us-ascii?Q?dkSZwzmtnCONp0jhGb1nZEPQPcW+beveqMZmTm8IH/XZ+e3nTxXwKWWtWzw5?= =?us-ascii?Q?kkKuP3OYHLI8ymMADrU/pnTwjcgEhpQKxM3XuVeQfKmzgtWP7++PmJIJBeFy?= =?us-ascii?Q?lzg=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 5:GCUeF6/fZpAORFNIHq6zHpSnNpnonLyLkYW3j9/r/a471RKZe96l2qQWMnacqIbXrSKxzjo0Haa6zkEqTgvSvMIz9Y/iy9AAZEMN4g4e2+I+PddI8+rhfEG8ILKYE+06HKcxyW36tsqFZJRNcpNZAwhRKNB1euo6FzdPlCpIDR0rAvYba322xhorjr9ch3+HzFSM1t8XzlB596WaXctUfHld98UpoQi9kQsVs55pH5VaHqhDEzx91feCG9WefCucbZgojW1g/H6MsJDf/Vkf0y6kFBZ/WeCcF0GJtHnBLv29cMxO2wbkp8bTDRX//tpO8xCHuEXZ/32Hqd/vTdgEZ5lxMSqTjOJ8tRp5Q6Erx8ec7yBWj17kAxJpPcNmOAbJI8bTRXLxtDPo4c1TizQyFkAoKcpyjTc2Y9cTR20wMtAfcvGUiOqhaQXCh/U9ua0cJsgEQZ4O/xqDvul/HZ/bEgnfgZRUjefWhouNT1eD/v9RC02r9Q/X3AFMAZZiwPLi; 24:OZSnCpmmjeUNrk3z819937/3TP018S7VcExxWKf8TiG1BN3Nyb860sByadLKRkWWF7t8BDJKLXlMKNOxmIwA9TquxuB6RWhB8tomdtUOzIs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1028; 7:I+rz5TTKK/eSWznSyX93n28CMDnzR0eIezaZkDuQ/+PG3maQVj52vW6JgyCAQsnrBjgmHnHgexJ0dyS9pRL+PK9/8o2uKd6FFszu2ja6YuNwAdOqXeOzNV5L2x05Keb7x5yTsc1nAqvKxudQKTYY6mGvO9daSGwtqd+bzuyianPg9iTcnu2CAiXS/09dQBLW+pM9Ug/ZM0gbmnyJA+wVdjLmsWp71fufi1eWrLZ+o8kaO0Pxcr5t/P7PTO6K/tZg9/bIttzMQW0ITSUfjib+5bUxL5512Kv9W9sRiFvBfBpnCbOweMhTyT3+TyfHaupVgYLIPfDOt9SgwrD5+Eue+rgoYAibLz2PeOy3SjdzUyADhDg61s+kap2qGUhp0mingCfSsPSciDaaopU50sNxm533Vi/OhNOJmRVrNiHX5EqGiyCs3ghGSP7QZm7oofRln5b6ScZMq34RcleEtGWfFHzLeZUaLKaYfyFgkga2p7JUgAfjlmvuxcXwxhL5hmMewTYkTao5zt4UIx/ohSE0WLCJ8meRwgUyn+41xinXrz44bBgViGou2d2M9j32ZpqdIw3udTca/gYyTnT9Trb7VrEIvE3PE0M/pfiRDWDr5LfWPQQduG90K5otnP8l+MBIZwcdlShUqBr1iUeitbdrI490LQfUwGICSOi5VGpjs306EK+ZqaCXEkBtxoEgFZy7gLISYYCVL6b4DgYA+HxCdumWn+N8fYWoRrMJiUDENrh3DyIFGa4tVOit0y2GbEYWdaxTM1WZwi8nAaZeO2ScNzQ+CHiHsXm468LRJrzAqxM= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 11:06:08.5133 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1028 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 11:06:12 -0000 On 16 Jul 2017, at 0:34, Daniel Kahn Gillmor wrote: > Strongly enough to support a proposal that would require this to be > opt-in from both sides, with an explicit and verifiable exfiltration > authority, so that no standard implementation of the proposed > mechanism > could be accidentally turned on unilaterally without detection by the > unwitting peer? Quite possibly, yes - the devil will be in the details, but the concept is perfectly valid, IMHO. ----------------------------------- Roland Dobbins From nobody Mon Jul 17 04:48:36 2017 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 0437213146E for ; Mon, 17 Jul 2017 04:48:34 -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 (2048-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 v8eqp4taxp67 for ; Mon, 17 Jul 2017 04:48:33 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 E932B131746 for ; Mon, 17 Jul 2017 04:48:32 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HBlOek001444 for ; Mon, 17 Jul 2017 12:48:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=eyz5RdrlHzTai6pm34dEdiiY5GW+Y0j4iX4IFkQJ6O8=; b=RclrYUtJR+7bOZqxgv1WY5NZgUqyEtw+e5EnjcXDY0S3C99egO3cEJwyLGGVLIeUqQBl 795ULVf6KFAw7KprxnSy3h39f3pC1f2iZous0RSE3eqtpx2Tt+ZlmZOXbBG0gj6tGHGZ 69OOuwx2MxJzNRSxhDuqLY4VWDZbV7hguUkUEAkuMsXOAh/zt4+gPG1ehbYPPveJMang q0ASh3tCB3ENJESuBGNBt8iJ3npORvbX+okVGME+GoQOuzLD+tK9ai9TlfpVl92TB0SV 20uXziUZTZJF6/GBFhib7YpBz4Ir8+ZUbk/Y3DbDyKBt+AeRwjp5Zz+S5eZVwu4Jriab Nw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bqak4qn0t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 17 Jul 2017 12:48:31 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HBk3RI020149 for ; Mon, 17 Jul 2017 07:48:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecum579-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 17 Jul 2017 07:48:30 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 07:48:28 -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.1263.000; Mon, 17 Jul 2017 07:48:28 -0400 From: "Salz, Rich" To: "tls@ietf.org" CC: "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/ulq2ZwSnSRPzEiyaKC371R3laJX5yCw Date: Mon, 17 Jul 2017 11:48:28 +0000 Message-ID: <3847dfbfb9f5497a8aababb665e18ea8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> In-Reply-To: <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> 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.153.37] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170186 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170187 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 11:48:34 -0000 > > DDoS mitigation can be done at endpoints >=20 > Not at scale. That's why it isn't done that way. Sometimes it is. Can we stop making definitive declarations like this? There are more things in the world, Horatio, then are dreamt of in your phi= losophy. From nobody Mon Jul 17 04:50:23 2017 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 A6E7012F257 for ; Mon, 17 Jul 2017 04:50:20 -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=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 CNpKqJQW4_1c for ; Mon, 17 Jul 2017 04:50:19 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 844B21287A5 for ; Mon, 17 Jul 2017 04:50:19 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HBlPmx010162; Mon, 17 Jul 2017 12:50:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=/wZlARhjr7qLcQRr9x2R+42EdScmN+qh++wKFo8xg2g=; b=iIo2O6CpoPkmAgGS2mT/zd+Nzuh2qGdgyNIFR/XpPgjZ7CUw9CqNe+IioLLx3tENbFDx TSJUDdU/3T8IOlc8Am+i3SjjU8CcfwD9uENAn5T1f+AVzoIPXIuZcSuTBLIUSg9LQfJh odrtMsV8sBmy7D4D1iwekFFHRDnKkv6EvL6mpDxfuOVFRh6Xe1rtZVJU2ncJgsAohrth SDPaqw06VXjDmTtZGNnGZoWeqA1z20wHP/2zCsyY3c+u6yYrrHwB+CbFnKxf0uy6pO0N XN+BnlkWNLAwPAvUTaMy8v+NQpxQ3e4b7bWSibjYzFyAMOH+KlJZCjaHr+HWJWu+b1w3 Rg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2bqbf97abd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 12:50:13 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HBk3Rl020149; Mon, 17 Jul 2017 07:50:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecum5aq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 07:50:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 07:50:11 -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.1263.000; Mon, 17 Jul 2017 07:50:11 -0400 From: "Salz, Rich" To: Roland Dobbins CC: =?Windows-1252?Q?Colm_MacC=E1rthaigh?= , Matthew Green , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAAga+AgAAdCICAAEOKgIAAN5MA///LkJCAAEZ9AP//vjvAAD621wAABtHVAA== Date: Mon, 17 Jul 2017 11:50:10 +0000 Message-ID: <057af2f23acc450a9b896f9f0c81b06d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.153.37] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170186 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170187 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 11:50:21 -0000 > Being able to continue to utilize vetted, well-understood, standards-base= d > cryptography on intranets once regulatory bodies such as PCI/DSS mandate > TLS 1.3 or above - which will happen, at some point in the not-too-distan= t > future. Which brings me to my second question (or first, depending on how you read = email). Will this be needed within five years? Within three? From nobody Mon Jul 17 04:53:12 2017 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 7FEDF131B30; Mon, 17 Jul 2017 04:53:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150029238448.14965.3363103739165630058@ietfa.amsl.com> Date: Mon, 17 Jul 2017 04:53:04 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 17 Jul 2017 11:53:04 -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 : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-03.txt Pages : 7 Date : 2017-07-16 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-03 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 Jul 17 05:01:21 2017 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 5A11313146E for ; Mon, 17 Jul 2017 05:01: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 bIHZnPKYhIyh for ; Mon, 17 Jul 2017 05:01:19 -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 870DB13145A for ; Mon, 17 Jul 2017 05:01:18 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id h134so41798223iof.2 for ; Mon, 17 Jul 2017 05:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oKV+bo+IXMDqakVpg93RuBzslsFS/OI7rqVY67KoBi4=; b=bVmi8BQTbn+6vVTMl1DkpDzy635I0WL+moa5zrUQ6ArnPdZ8xDso7qaf+unyPPnm2g u9pGuGbLXjsuI0OpfnADBOybmpNxB8Fbfi0IrV7Tw9GYb5R7DDXB6ipDs1JBf1jRzwcd WLzDDlfOkbcaTfK2/d3HRy4UwJ86CYpTJsvGGjpkztRebuRHkd35MF5tl3ysucw/Bg9L Y8bVYWBmiQgxnXNslZillv39pqFjMOgjfcGt/1IAljzkOQscD/cQNqbUnzJI0+Hq0kBk ZkjyXC3/EG3C10wHOU5kOWvvk2NcNNA3mg+pYKCqDRPkKPff63SPG+g0YnsSpzS3Ar1Y /JFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oKV+bo+IXMDqakVpg93RuBzslsFS/OI7rqVY67KoBi4=; b=gkNtLqFwzpdOeG/1s4qaPhR6W7caLpBvD6nDhv7Sk6AVu7nCQKMHS2qonCP+f+O5xO 7bE6KDpuzlG0dk+uZh39iDHa5eLtifyGAHhmklr5AUUnx5NIoZo24oG7Cp5XoWZV02cl 8B1XXU5k9d9Jr4xdKJC+S2Q5dM60B+EcyxpkZel2cPQRT2ra0yOEnKNpveO8xMjOUT13 B9bAPTvGj/pdRX8aZylDg03wtX8p2pjQCptexTAP4C8DOANQZbOBmGgUhDAztSVmUSUU bcT7rZJhC+qftqVHMXN0xYRIF6knevmLRSZ7vK4xHZiZcKvuwvmNqAbOgQOS5I/n0eIv JTWg== X-Gm-Message-State: AIVw110aV9EWvoaokd4xE6lJwFhhWj8iPjeIlFZRrS7Zs1mi9RktAzOt JTb7hJnNQWaHA//4FYZVpxiqMmy6akfs X-Received: by 10.107.39.205 with SMTP id n196mr18479058ion.37.1500292877926; Mon, 17 Jul 2017 05:01:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Mon, 17 Jul 2017 05:01:17 -0700 (PDT) In-Reply-To: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> From: Martin Thomson Date: Mon, 17 Jul 2017 14:01:17 +0200 Message-ID: To: Roland Dobbins Cc: Kathleen Moriarty , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 12:01:20 -0000 On 17 July 2017 at 12:59, Roland Dobbins wrote: >> At the point that I have sufficient control over a host that I can run >> my software, then I would pin certificates and the best you could do >> is block me. None of the advice about configuration of trust anchors >> (pinning, overrides, etc...) helps at that point. > > Correct. Which is why it's critical in the intranet context, within a > single span of administrative control, to have visibility into the actual > cryptostream. Roland, I think that you missed my point here. My point was that you don't get that visibility when it is malware at both ends of the connection (assuming a modest amount of competency from the authors). From nobody Mon Jul 17 05:07:56 2017 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 4CD0212EC46 for ; Mon, 17 Jul 2017 05:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 TX1Mz2fSZ4X1 for ; Mon, 17 Jul 2017 05:07:53 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0133.outbound.protection.outlook.com [104.47.41.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720F6126B6D for ; Mon, 17 Jul 2017 05:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Mrzo0FXgunHAv/6bTz4Idr7kQJ0zkvjsjvijjtYyhoA=; b=UMV+3tUhgEQRRzklsQ7G7WYI5uJDx/6DrnoJCDlgiPkzORUtCpTr63in++MmIxIlXPZpmYUWpKat97tu4vnhlfyh0mklhwsk1JeIZJPQc6t1YepG/SRsYKCnfYzLWEJScNJnvQ/G6S9/fW3tZ5o85Ta8jDOK1kUpV+K2kkbIiEw= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 12:07:50 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 12:07:50 +0000 From: "Dobbins, Roland" To: Martin Thomson CC: Kathleen Moriarty , "tls@ietf.org" Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) Thread-Index: AQHS/vRnKFRxxE429kKncr36no97/qJX7LVn Date: Mon, 17 Jul 2017 12:07:50 +0000 Message-ID: <72166F26-D9C4-4A6D-9007-E68C61688CA6@arbor.net> References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:R5EJwI2kqgl2Ceo3d9gz8o52G6mwKLae9ZpujQj0VG9pvdMmoZexYKndBmZ/q4+ec5fR0Hb8ckvd1xVgENDajLUACzUXmKapAbQBDIfnfXcCDG/MDCJ0EtjlTWjTqiTbE9Eb+r/iKxcLSwDX/8a5SyYHnQ1gU/Bm8Sbt9c4wDWINEhSzBQak5pJ/7oSn3yehCI8Cs7OSJ09vxFsscX6MkCapw3IIBRe0haI5sfOGSyh3GEvkeHdhW4lH/tIcw3vjzadL2hTZFRwmtcK23JwBobGeYC/kAM/dm6ZZvasGJHJhmqRB9vhiKADWrIxzc8rWZbenVU1K4ZQkT+7ohNGk9c5o3sAV0Y4D6zrMqMNXq8ck0B8OiQyR08mWS3OjknUmp5CAt2v8w3dkdy3I5MHr2Gahw77jJCVuqNhXbATPGbCVlYwQQfJ7nJRYVvVyt29c5nFyApsyoxYK1Xf4m5+kf0wWkIJC2l7LK5Gz1xbTzGjetVRfzZnkVc99fdLoO3cuP1iggmyib6FCnnN9O+3E5UIOIpA5crBoLvq8X7wquTNbztCSEzamZQwcb28d6ah8jTi27Is15eO/6oCJIb4cILJE5J6jgxXBdvO0Du4v/VNthfCObZ9L0li0r9cJH4lYvtjYZF7gPaBsTPjLG2tlIR05ku7bYrsYHiIWn2XojvdgSgdcyiI2RNJrbVblMWgfILL+NbgL5hOQ6c+U/mRehHwoB75UoXHZqh7zS6wqk5LgMZxmAQRiKTZ7roXZkl2arnV73TIJOfMNpeJWMQY+3KW73shKD+Iv2bPRbWltcnA= x-ms-office365-filtering-correlation-id: 13a29bba-36f2-4503-cb24-08d4cd0c7217 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(236129657087228)(50300203121483)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39450400003)(39400400002)(39840400002)(39410400002)(24454002)(5250100002)(81166006)(7736002)(8676002)(53546010)(2950100002)(6916009)(4326008)(189998001)(82746002)(2900100001)(83716003)(33656002)(6486002)(6506006)(14454004)(38730400002)(478600001)(6436002)(110136004)(3846002)(6116002)(229853002)(39060400002)(25786009)(102836003)(8936002)(2906002)(86362001)(50986999)(5660300001)(230783001)(6246003)(53936002)(54356999)(66066001)(76176999)(54896002)(3280700002)(54906002)(36756003)(99286003)(3660700001)(236005)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_72166F26D9C44A6D9007E68C61688CA6arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 12:07:50.1046 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 12:07:55 -0000 --_000_72166F26D9C44A6D9007E68C61688CA6arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTQ6MDEsIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhv bXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0K DQogTXkgcG9pbnQgd2FzIHRoYXQgeW91DQpkb24ndCBnZXQgdGhhdCB2aXNpYmlsaXR5IHdoZW4g aXQgaXMgbWFsd2FyZSBhdCBib3RoIGVuZHMgb2YgdGhlDQpjb25uZWN0aW9uIChhc3N1bWluZyBh IG1vZGVzdCBhbW91bnQgb2YgY29tcGV0ZW5jeSBmcm9tIHRoZSBhdXRob3JzKS4NCg0KU2VlaW5n IGl0IHdoZW4gaXQncyBvbmx5IGF0IG9uZSBlbmQgaXMgcXVpdGUgdXNlZnVsLg0KDQpBbmQsIHll cywgb25lIGRvZXMgb2Z0ZW4gc2VlIGl0IGF0IGJvdGggZW5kcy4gICBBc3N1bWluZyBjb21wZXRl bmNlIG9uIHRoZSBwYXJ0IG9mIHRoZSBhdXRob3JzIGlzIHVud2FycmFudGVkLg0KDQpXaHkgZG8g eW91IHBlcnNpc3QgaW4gdHJlYXRpbmcgdGhpcyB0ZWNobm9sb2d5IGFzIHRoZW9yZXRpY2FsICYg aW5lZmZlY3RpdmUsIHdoZW4gaXQncyBiZWVuIGluIHVzZSBxdWl0ZSBlZmZlY3RpdmVseSBmb3Ig bWFueSB5ZWFycz8NCg0KTmV0d29yayBvcGVyYXRvcnMgaGF2ZSBiZWVuIGRvaW5nIHRoaXMgZm9y IGEgbG9uZyB0aW1lIC0gYmVjYXVzZSBpdCB3b3Jrcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRv OnJkb2JiaW5zQGFyYm9yLm5ldD4+DQo= --_000_72166F26D9C44A6D9007E68C61688CA6arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3 LCBhdCAxNDowMSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuPiZu YnNwO015IHBvaW50IHdhcyB0aGF0IHlvdTwvc3Bhbj48YnI+DQo8c3Bhbj5kb24ndCBnZXQgdGhh dCB2aXNpYmlsaXR5IHdoZW4gaXQgaXMgbWFsd2FyZSBhdCBib3RoIGVuZHMgb2YgdGhlPC9zcGFu Pjxicj4NCjxzcGFuPmNvbm5lY3Rpb24gKGFzc3VtaW5nIGEgbW9kZXN0IGFtb3VudCBvZiBjb21w ZXRlbmN5IGZyb20gdGhlIGF1dGhvcnMpLjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi cj4NCjxkaXY+U2VlaW5nIGl0IHdoZW4gaXQncyBvbmx5IGF0IG9uZSBlbmQgaXMgcXVpdGUgdXNl ZnVsLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5kLCB5ZXMsIG9uZSBk b2VzIG9mdGVuIHNlZSBpdCBhdCBib3RoIGVuZHMuICZuYnNwOyBBc3N1bWluZyBjb21wZXRlbmNl IG9uIHRoZSBwYXJ0IG9mIHRoZSBhdXRob3JzIGlzIHVud2FycmFudGVkLiZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2h5IGRvIHlvdSBwZXJzaXN0IGluIHRyZWF0aW5nIHRo aXMgdGVjaG5vbG9neSBhcyB0aGVvcmV0aWNhbCAmYW1wOyBpbmVmZmVjdGl2ZSwgd2hlbiBpdCdz IGJlZW4gaW4gdXNlIHF1aXRlIGVmZmVjdGl2ZWx5IGZvciBtYW55IHllYXJzPzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+TmV0d29yayBvcGVyYXRvcnMgaGF2ZSBiZWVuIGRvaW5nIHRo aXMgZm9yIGEgbG9uZyB0aW1lIC0gYmVjYXVzZSBpdCB3b3Jrcy4mbmJzcDs8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1 NSwgMjU1LCAyNTUsIDApOyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5v cm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0 aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5v cm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0 aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXZh cmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+Um9s YW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiIHgtYXBw bGUtZGF0YS1kZXRlY3RvcnM9InRydWUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtdHlwZT0ibGlu ayIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9IjIiPnJkb2JiaW5zQGFyYm9yLm5ldDwv YT4mZ3Q7PC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_72166F26D9C44A6D9007E68C61688CA6arbornet_-- From nobody Mon Jul 17 05:14:03 2017 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 B54E012F257 for ; Mon, 17 Jul 2017 05:14:01 -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 4rOzeyeTEtsa for ; Mon, 17 Jul 2017 05:14:00 -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 AA07413172B for ; Mon, 17 Jul 2017 05:14:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2138E30050A for ; Mon, 17 Jul 2017 08:14:00 -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 U5gww4D1pGWE for ; Mon, 17 Jul 2017 08:13:59 -0400 (EDT) Received: from dhcp-88c4.meeting.ietf.org (dhcp-88c4.meeting.ietf.org [31.133.136.196]) by mail.smeinc.net (Postfix) with ESMTPSA id 686D5300098; Mon, 17 Jul 2017 08:13:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Mon, 17 Jul 2017 08:13:56 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 12:14:02 -0000 Martin: >>> At the point that I have sufficient control over a host that I can = run >>> my software, then I would pin certificates and the best you could do >>> is block me. None of the advice about configuration of trust = anchors >>> (pinning, overrides, etc...) helps at that point. >>=20 >> Correct. Which is why it's critical in the intranet context, within = a >> single span of administrative control, to have visibility into the = actual >> cryptostream. >=20 > Roland, I think that you missed my point here. My point was that you > don't get that visibility when it is malware at both ends of the > connection (assuming a modest amount of competency from the authors). I think that the IDS is trying to detect the an infected server trying = to migrate to another server. Malware often includes a series of = exploits that are tried in sequence to infect a neighbor, and this = activity provides a detectable signature. Russ From nobody Mon Jul 17 05:21:44 2017 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 0E698131B46 for ; Mon, 17 Jul 2017 05:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Og26n2JMovn for ; Mon, 17 Jul 2017 05:21:41 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 476AE131B3F for ; Mon, 17 Jul 2017 05:21:41 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id z22so92173238uah.1 for ; Mon, 17 Jul 2017 05:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gBVtNTdzap0tHzLyi8wKwSUsXui9ZErN/K0B7c3TXrQ=; b=TnId/WckcFG4RMGydmK7FofVwhuXJVzJpsUXmP+it3g0f8HSD11GiNH4tyBDU1y6Sy qfCx7md6P8rjGG4MN5RrHd2ErqkckCkPz1vg0QAMBrrkz8xedaYdr/20Cys9hQS2y8vl Dj84velQygIXInwHO9R0J3kT7MjtTkPLsWBxY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gBVtNTdzap0tHzLyi8wKwSUsXui9ZErN/K0B7c3TXrQ=; b=AIsBib1kebBIm0kEi+Vz59xZlf5FCsakypmlY1QzUQWA6z8z3zq4+eHJTm9jSuJ6O9 pWzj+0DuRlYssFcGGU1OZWeCp9RUUHLOzQbI3lzNEYBXx1tZfK1cSBYsMhi+LM9BBK4J H8ZnQMT6eJ85yI5PAGBUfy5SWozkioK5+TWo76HeX5WPTbZDrFbtRmMFD/p6ienVfYV4 96nVC0HGkArOlenvIea6rIWPs9+p0fQbVQRgfauadEqHDdHvi1i23LnIRWkmMVbed8pl +fc7kYQwqr7zgkghorCME2iLBl97d3587wXqPSK02hF68Fq0YYVRNudJ6D85DHAG7ND2 0gqg== X-Gm-Message-State: AIVw112+Il+75bYau7ul1E//7jQY/5Q7PcevAQ35eLOMzhfd9c5QZp7N +/m5yoe6nbD3Lmh4YzivDFEQ/LD3Hw0D X-Received: by 10.31.220.199 with SMTP id t190mr12091911vkg.132.1500294100167; Mon, 17 Jul 2017 05:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.195 with HTTP; Mon, 17 Jul 2017 05:21:39 -0700 (PDT) Received: by 10.176.65.195 with HTTP; Mon, 17 Jul 2017 05:21:39 -0700 (PDT) In-Reply-To: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <87pod1qqh5.fsf@fifthhorseman.net> From: Tom Ritter Date: Mon, 17 Jul 2017 07:21:39 -0500 Message-ID: To: Roland Dobbins Cc: Matthew Green , dkg , tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c07cc7ee641c2055482705d" Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 12:21:43 -0000 --94eb2c07cc7ee641c2055482705d Content-Type: text/plain; charset="UTF-8" On Jul 17, 2017 6:06 AM, "Roland Dobbins" wrote: On 16 Jul 2017, at 0:34, Daniel Kahn Gillmor wrote: Strongly enough to support a proposal that would require this to be > opt-in from both sides, with an explicit and verifiable exfiltration > authority, so that no standard implementation of the proposed mechanism > could be accidentally turned on unilaterally without detection by the > unwitting peer? > Quite possibly, yes - the devil will be in the details, but the concept is perfectly valid, IMHO. I've read or skimmed much of these threads. I support an opt-in mechanism like the one I think dkg is imagining. It should be visible on the outside on the connection, so middle boxes that don't break TLS can see that TLS is being broken. (Is that irony? After Alanis I'm never sure anymore...) I don't know enough minutia to have a well considered opinion about what track such a doc should be, but not-Standards seems good. -tom --94eb2c07cc7ee641c2055482705d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jul 17, 2017 6:06 AM, "Roland Dobbins" <rdobbins@arbor.net> wrote:
On 16 Jul= 2017, at 0:34, Daniel Kahn Gillmor wrote:

Strongly enough to support a proposal that would require this to be
opt-in from both sides, with an explicit and verifiable exfiltration
authority, so that no standard implementation of the proposed mechanism
could be accidentally turned on unilaterally without detection by the
unwitting peer?

Quite possibly, yes - the devil will be in the details, but the concept is = perfectly valid, IMHO.

=
I've read or skimmed much of these threads. I s= upport an opt-in mechanism like the one I think dkg is imagining.=C2=A0

It should be visible on the= outside on the connection, so middle boxes that don't break TLS can se= e that TLS is being broken. (Is that irony? After Alanis I'm never sure= anymore...)

I don't= know enough minutia to have a well considered opinion about what track suc= h a doc should be, but not-Standards seems good.
-tom
--94eb2c07cc7ee641c2055482705d-- From nobody Mon Jul 17 05:22:01 2017 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 A1E52131B52 for ; Mon, 17 Jul 2017 05:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 9x-X4KHKJkJE for ; Mon, 17 Jul 2017 05:21:53 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0116.outbound.protection.outlook.com [104.47.36.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE09131B50 for ; Mon, 17 Jul 2017 05:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O6Ff89rZ/g3OffFvz0SvFLBzPOpWvlCDMxp+egYjsQI=; b=bn5bPfLD3iHoNVUV8K4xvIzpQ/k56Jt9s6DDsXchm4N2JLSmB2/ffx7xCt8r/+UPSL1bs0TA+SElPN9cfiSdbJBJYPOazw+yIknj3io3S9kW2157BemMD2453gzqYGNLRGuVjHTfwfukcOeyt/BpEvy8NeomyxrAQc3ewOi/4D4= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 12:21:51 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 12:21:51 +0000 From: "Dobbins, Roland" To: "Salz, Rich" CC: "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/ulnreU48MdBA0WwDcIvwebnRKJX52IAgAAJVe8= Date: Mon, 17 Jul 2017 12:21:51 +0000 Message-ID: <52AE5A8E-CD75-450D-B143-F886B3B08991@arbor.net> References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>, <3847dfbfb9f5497a8aababb665e18ea8@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <3847dfbfb9f5497a8aababb665e18ea8@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:PmZYHeS9L0dt9yWCIXtVcuLULJ8l62X55rxmx2Y9vmmvieGW7QsO4QID3wEN78eLJvf2LxSTgzOcBMhwCYHs2USZWdSPejyes58BwJ4yYPJuIhorhqM/QfTzDJbaSGhJXE/q8+0UTtxR0LpyiNuM110etr/oaSiLbUUg07dxEGFitzTYA2RdFNzn9XKDaJt8oW1tQNB8Yny0SpS/QzYQJ8m7KW0TAGtN0PsvKyCw1RVMxxlvsuWvsjIfRCQn+1NsXzqEepj/kaqlNY4ullrdcf/YMu+y5+BCoevaEseGiB5aVDme9I9tZxDBF0VfaBb8C2AoHWpeUjq/7R5PmR/faCdSo/XM7NN2SN0dRVRtDQRV2knPV0a2YGee+Y0njymwxpNfCs8YYJhmqObGGXsHdY915XSxtkbqaR/dXwtWEDGClGJWAw0MluDhrMbZrJjCDB6iOFqcm7MliHuR7QxySeVNbv5CtfTwrkak4tlKRVXW9/Kjw/BQiur+jS39LGvd1XVXOy+pekn5wut/hbdzMkb11r6IAAmiYWJVemxkq3ki/vlZdFb4xLuS8EpiTfoHYEXd8k/rDHNX4yPGu4WMl20Z/mavChVe1XtZc8lJuYYGPxkq3iBR9dHqMPgsnkzEPd64y5QiRnLDwkMxheYtB98psufo3dSZmt1ZBs21eYqdRaTTFi35eXUlIZCZfeJV1utr9uYleqRLG7EhzLU7AZ57zCeNjm2MpQsqt0JXpIye7dkxU7UgTr2ypkjBg4tLW3zW9PXplOLcnyu1b+HMMCUX32a9mP8nGbRL+qJZVRA= x-ms-office365-filtering-correlation-id: f79064ae-d563-4fa1-267b-08d4cd0e679d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(246478575198768)(236129657087228)(48057245064654)(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39850400002)(39840400002)(39400400002)(24454002)(53936002)(6246003)(230783001)(50986999)(5660300001)(76176999)(54356999)(66066001)(3660700001)(36756003)(99286003)(236005)(6512007)(54896002)(93886004)(3280700002)(2900100001)(82746002)(83716003)(189998001)(4326008)(14454004)(6506006)(33656002)(6486002)(81166006)(7736002)(5250100002)(8676002)(6916009)(53546010)(2950100002)(102836003)(8936002)(229853002)(25786009)(86362001)(2906002)(6436002)(478600001)(38730400002)(110136004)(6116002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_52AE5A8ECD75450DB143F886B3B08991arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 12:21:51.6108 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 12:22:00 -0000 --_000_52AE5A8ECD75450DB143F886B3B08991arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTM6NDgsIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5j b208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90ZToNCg0KU29tZXRpbWVzIGl0IGlzLg0K DQpOb3QgYXQgc2NhbGUsIGluIHRoZSB2YXN0IG1ham9yaXR5IG9mIGNhc2VzIC0gYXMgSSdtIHN1 cmUgeW91J3JlIGF3YXJlLCBoZW5jZSB0aGUgJ3NvbWV0aW1lcycuIENvcm5lci1jYXNlcyBhcmUg anVzdCB0aGF0Lg0KDQpDYW4gd2Ugc3RvcCBtYWtpbmcgZGVmaW5pdGl2ZSBkZWNsYXJhdGlvbnMg bGlrZSB0aGlzPw0KDQpBYm91dCBmYWN0dWFsIG1hdHRlcnMsIG5vLCAnd2UnIGNhbid0LiAgSSdt IHRpcmVkIG9mIHNlZWluZyBlc3RhYmxpc2hlZCBvYmplY3RpdmUgZmFjdHMgYWJvdXQgaG93ICYg d2h5IGludHJhbmV0IG5ldHdvcmsgb3BlbiBuZWVkIHZpc2liaWxpdHkgaW50byAgY3J5cHRvc3Ry ZWFtcyBvbiB0aGVpciBvd24gbmV0d29ya3MgYmVpbmcgdHJlYXRlZCBhcyB0aGVvcmV0aWNhbCAm IHN1YmplY3RpdmUuDQoNClRoZXJlIGFyZSBtb3JlIHRoaW5ncyBpbiB0aGUgd29ybGQsIEhvcmF0 aW8sIHRoZW4gYXJlIGRyZWFtdCBvZiBpbiB5b3VyIHBoaWxvc29waHkuDQoNCkxpa2V3aXNlLg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8 cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0K --_000_52AE5A8ECD75450DB143F886B3B08991arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3 LCBhdCAxMzo0OCwgU2FseiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1haS5j b20iPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5Tb21ldGltZXMgaXQgaXMuPC9zcGFu Pjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+Tm90IGF0IHNj YWxlLCBpbiB0aGUgdmFzdCBtYWpvcml0eSBvZiBjYXNlcyAtIGFzIEknbSBzdXJlIHlvdSdyZSBh d2FyZSwgaGVuY2UgdGhlICdzb21ldGltZXMnLiBDb3JuZXItY2FzZXMgYXJlIGp1c3QgdGhhdC4m bmJzcDs8L3NwYW4+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1 NSwgMjU1LCAyNTUsIDApOyI+PGJyPg0KPC9zcGFuPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg cHJlb2Zmc2V0dG9wPSIyNzQiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkNhbiB3ZSBzdG9wIG1ha2lu ZyBkZWZpbml0aXZlIGRlY2xhcmF0aW9ucyBsaWtlIHRoaXM/PGJyPg0KPC9zcGFuPjwvZm9udD48 L2Jsb2NrcXVvdGU+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1 NSwgMjU1LCAyNTUsIDApOyI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImJhY2tn cm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5BYm91dCBmYWN0dWFsIG1hdHRl cnMsIG5vLCAnd2UnIGNhbid0LiAmbmJzcDtJJ20gdGlyZWQgb2Ygc2VlaW5nIGVzdGFibGlzaGVk IG9iamVjdGl2ZSBmYWN0cyBhYm91dCBob3cgJmFtcDsgd2h5IGludHJhbmV0IG5ldHdvcmsgb3Bl biBuZWVkIHZpc2liaWxpdHkgaW50byAmbmJzcDtjcnlwdG9zdHJlYW1zIG9uIHRoZWlyIG93biBu ZXR3b3JrcyBiZWluZyB0cmVhdGVkIGFzDQogdGhlb3JldGljYWwgJmFtcDsgc3ViamVjdGl2ZS4m bmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiBy Z2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGJyPg0KPC9zcGFuPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgcHJlb2Zmc2V0dG9wPSI1MTQiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHls ZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPlRoZXJlIGFyZSBt b3JlIHRoaW5ncyBpbiB0aGUgd29ybGQsIEhvcmF0aW8sIHRoZW4gYXJlIGRyZWFtdCBvZiBpbiB5 b3VyIHBoaWxvc29waHkuPGJyPg0KPC9zcGFuPjwvZm9udD48L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxz cGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGJy Pg0KPC9zcGFuPjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1 LCAyNTUsIDI1NSwgMCk7Ij5MaWtld2lzZS4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGJyPg0K PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgy NTUsIDI1NSwgMjU1LCAwKTsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9 ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48c3BhbiBzdHlsZT0i Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjog bm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxiciBzdHlsZT0i Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjog bm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12 YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij5Sb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJkb2JiaW5zQGFyYm9yLm5ldCIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBs ZS1kYXRhLWRldGVjdG9ycy10eXBlPSJsaW5rIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3Vs dD0iMiI+cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjwvYmxvY2txdW90ZT4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_52AE5A8ECD75450DB143F886B3B08991arbornet_-- From nobody Mon Jul 17 05:24:14 2017 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 A4B92131B14 for ; Mon, 17 Jul 2017 05:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 8JBL68EwY308 for ; Mon, 17 Jul 2017 05:24:09 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0A713145A for ; Mon, 17 Jul 2017 05:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aV7YJN6G2zdZyX4rDsfOQbosQW7TWZcd2PrlP+1mdbw=; b=gXVHeGl07HOgurAn6rXIohi4M7mN8YzNp4r5cucpEAUFKipGWbxhpZRwI1NfUj/srVFxWxcd7XiGpxaHAoeg8274w6yfBiRrTYTDW9RLvceZYBg8i63fkLWQ98iGrvAlZQQFae7WirpKvwz4CXvZEwzm1KLo9Se8HdI/58WxWEA= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 12:24:07 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 12:24:07 +0000 From: "Dobbins, Roland" To: "Salz, Rich" CC: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Matthew Green , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/LbQetAoAc0WMUGwvSG+0rIljKJUZVeAgAAD9wCAAL5cgIAAG3oAgAA+T4CAAB0IgIAAQ4qAgAA3lACAAA63AIAAA1UAgAAC5YCAAiZlAP//l1IAgAAJfdU= Date: Mon, 17 Jul 2017 12:24:07 +0000 Message-ID: <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> , <057af2f23acc450a9b896f9f0c81b06d@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <057af2f23acc450a9b896f9f0c81b06d@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:OAAjLfWR6mdZQ+Rj4PcANt8F0QfUGefK9bYaMOKFTtGLdGqolWIHdGFKGm/squSWpWxaG21NJT6azkaaIOBGq+N1Z+5f9tnqiymBIf0wArFBQ+6XHAsUMe8zHuDFFDhrhSbVSrD7cR4cRempqxPnum5qYn0wL+ZHycSkBZ8Oai/8EApChCepqMslNL4A+vgMV1t+/FVvvXfP2/UAO84QB+14eT7XxY5hDCKmAVWCRxIHhvLSuoGSaH1NOekp4nL0D0EqhW+AiFMEieMtHk0sQEJJ1zwJ/xv86GBsY9yHwoyyIaqsmWWDYY6GIfXsqfQiLzM/wKcKz5XJK3pb1ghjYBpMYeGcQC5GuLUNhz3Z+rjduFaBXCfPyNO0c0VMEm7HzxD4pmI5rl8+cxo2z1qtHGBWkhEvPn6F27kyhNAAF31xIMxZoZwRYODf+Ph8oJqC592B3hsyeE30c+tlMqiCzk40leElQ+EvlzIcLJv2hGbYDaizmrEooqAQrFvFpPw/w+fMfEpSZ1+ExJ0EqYADmClyzm8mEsvuERtdZ+2X9ZHBptaPapSrp1ljqCFWUnN8IVnUH4gYI4xGWWCvLOGW/vuWDgNMkgOJKCKLglrfla05AgJSEEM9UHTkOKvWmNjSS3Wse/KDZJL6UVT2GDw1DbPjGeialTle+7WbJXuuM0BjzJKEnWJxTpIIAzbwdZJ4ZwV6rK1qapgXdOYUXl1cmpj+7En43NaI56M5YQSmFgWc64t0NSJQXTB/ADvb1F3WbmWkiCI80inHLdtgXCcJXmB/4I7K5kqi3qgvIP5ojZQ= x-ms-office365-filtering-correlation-id: bb64acaf-7b42-4163-edf3-08d4cd0eb8a0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39850400002)(39840400002)(39400400002)(24454002)(53936002)(6246003)(230783001)(50986999)(5660300001)(76176999)(54356999)(66066001)(3660700001)(36756003)(99286003)(236005)(6512007)(54896002)(93886004)(54906002)(3280700002)(2900100001)(82746002)(83716003)(189998001)(4326008)(14454004)(6506006)(33656002)(6486002)(81166006)(7736002)(5250100002)(8676002)(6916009)(53546010)(2950100002)(102836003)(8936002)(229853002)(25786009)(39060400002)(86362001)(2906002)(6436002)(478600001)(38730400002)(110136004)(6116002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_96E48B74B7184F9EA12EE43E6A5147ABarbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 12:24:07.4842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 12:24:12 -0000 --_000_96E48B74B7184F9EA12EE43E6A5147ABarbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTM6NTAsIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5j b208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90ZToNCg0KV2hpY2ggYnJpbmdzIG1lIHRv IG15IHNlY29uZCBxdWVzdGlvbiAob3IgZmlyc3QsIGRlcGVuZGluZyBvbiBob3cgeW91IHJlYWQg ZW1haWwpLiAgV2lsbCB0aGlzIGJlIG5lZWRlZCB3aXRoaW4gZml2ZSB5ZWFycz8gIFdpdGhpbiB0 aHJlZT8NCg0KVGhhdCdzIGEgdmVyeSBnb29kIHF1ZXN0aW9uLg0KDQpVbmZvcnR1bmF0ZWx5LCB3 ZSBkb24ndCBrbm93LCB5ZXQuIEJ1dCB3ZSBkbyBrbm93IGl0IHdpbGwgaGFwcGVuIGF0IHNvbWUg cG9pbnQgYXMgYSBtYXR0ZXIgb2YgY291cnNlLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRv YmJpbnNAYXJib3IubmV0Pj4NCg== --_000_96E48B74B7184F9EA12EE43E6A5147ABarbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3 LCBhdCAxMzo1MCwgU2FseiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1haS5j b20iPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5XaGljaCBicmluZ3MgbWUgdG8gbXkg c2Vjb25kIHF1ZXN0aW9uIChvciBmaXJzdCwgZGVwZW5kaW5nIG9uIGhvdyB5b3UgcmVhZCBlbWFp bCkuICZuYnNwO1dpbGwgdGhpcyBiZSBuZWVkZWQgd2l0aGluIGZpdmUgeWVhcnM/ICZuYnNwO1dp dGhpbiB0aHJlZT88L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZGl2 PlRoYXQncyBhIHZlcnkgZ29vZCBxdWVzdGlvbi4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PlVuZm9ydHVuYXRlbHksIHdlIGRvbid0IGtub3csIHlldC4gQnV0IHdlIGRvIGtu b3cgaXQgd2lsbCBoYXBwZW4gYXQgc29tZSBwb2ludCBhcyBhIG1hdHRlciBvZiBjb3Vyc2UuICZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48c3BhbiBzdHlsZT0iZm9udC12YXJp YW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBm b250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxiciBzdHlsZT0iZm9udC12YXJp YW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBm b250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPg0KPHNw YW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVh c3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7Ij5Sb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5z QGFyYm9yLm5ldCIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBsZS1kYXRhLWRl dGVjdG9ycy10eXBlPSJsaW5rIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0iMiI+cmRv YmJpbnNAYXJib3IubmV0PC9hPiZndDs8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_96E48B74B7184F9EA12EE43E6A5147ABarbornet_-- From nobody Mon Jul 17 05:32:31 2017 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 D81A8131B56 for ; Mon, 17 Jul 2017 05:32:29 -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=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 cl_tZkgjA91u for ; Mon, 17 Jul 2017 05:32:29 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 D459C131B50 for ; Mon, 17 Jul 2017 05:32:28 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HCMUps015903; Mon, 17 Jul 2017 13:32:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3+kZe8YlsJ4V+VmThYQVYHEiB/zVok1PdvQjXO0oizo=; b=gPrjQ9wxfN7hZkkZJrKaJC90DNJY/GXKWoYI7ECzT6n7rLKcfrGMATBeeTfhg3u3gVFA SVe/Gq2+khoLUpvaiM62zOLaejLQ8WyILZpm/lBGYIxcJJH3rTl42QsTie1rfyu2h/Br m+yvchSsNPMccM1DY34czHqywm6zeualiOd09w68WSH9Jt8HZfQLUUOj0q7YDjajSS+r v0y/csuds/WzUThKpAt29sHYfRpy2xNXTcMwJDrCKCTWWJ0Lw4fCh+Q+s6TBP818beVF yst0o5J+jPWD/raYvS0AGyqaliUcSummm2GJFDGi8a+RdSE9369yGMp4ti7EITigw43T tQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bq84d809j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 13:32:23 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HCVL8H027491; Mon, 17 Jul 2017 08:32:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecu4arj-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 08:32:22 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 08:32:19 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 08:32:18 -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.1263.000; Mon, 17 Jul 2017 08:32:18 -0400 From: "Salz, Rich" To: "Dobbins, Roland" CC: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Matthew Green , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAAga+AgAAdCICAAEOKgIAAN5MA///LkJCAAEZ9AP//vjvAAD621wAABtHVAP//35iAgABBG3A= Date: Mon, 17 Jul 2017 12:32:17 +0000 Message-ID: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> , <057af2f23acc450a9b896f9f0c81b06d@usma1ex-dag1mb1.msg.corp.akamai.com> <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net> In-Reply-To: <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net> 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.153.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170198 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170196 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 12:32:30 -0000 Pj4gV2hpY2ggYnJpbmdzIG1lIHRvIG15IHNlY29uZCBxdWVzdGlvbiAob3IgZmlyc3QsIGRlcGVu ZGluZyBvbiBob3cgeW91IHJlYWQgZW1haWwpLiDCoFdpbGwgdGhpcyBiZSBuZWVkZWQgd2l0aGlu IGZpdmUgeWVhcnM/IMKgV2l0aGluIHRocmVlPw0KDQo+IFRoYXQncyBhIHZlcnkgZ29vZCBxdWVz dGlvbi7CoA0KDQo+IFVuZm9ydHVuYXRlbHksIHdlIGRvbid0IGtub3csIHlldC4gQnV0IHdlIGRv IGtub3cgaXQgd2lsbCBoYXBwZW4gYXQgc29tZSBwb2ludCBhcyBhIG1hdHRlciBvZiBjb3Vyc2Uu IMKgDQoNClByZWRpY3RpbmcgdGhlIGZ1dHVyZSBpcyBoYXJkLg0KDQpEb2VzIGFueW9uZSBoYXZl IGEgY3J5c3RhbCBiYWxsIHRoYXQgc2F5cyB0aGlzIE1VU1QgYmUgZG9uZSB3aXRoaW4sIHNheSwg dGhyZWUgeWVhcnM/ICBGb3IgZXhhbXBsZSwgYXJlIGFueSB2ZW5kb3JzIGNvbW1pdHRpbmcgdG8g ZG8gdGhpcz8NCg0K From nobody Mon Jul 17 05:47:42 2017 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 E98FA131B59 for ; Mon, 17 Jul 2017 05:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 Bhp-udbZR0nJ for ; Mon, 17 Jul 2017 05:47:38 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0097.outbound.protection.outlook.com [104.47.38.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE73F13146E for ; Mon, 17 Jul 2017 05:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8wxMwGBG4REUh2nbJsrVI4N5s9Rb5lVr5Nd86AU2mt0=; b=TUZFN4YpI3M6V2Mb0e/g/SpqzSQTgkMynYI/v4vTw/IX3B8oAI+HAlKy5NDID8Mq+s49H7oa0JwP8n0ds390urbtQ/rKKP5cctvnxUmZOBYdwTr6djaFf9S/2VkGgLG+ad9PIMHxQict8fEQ7v8PzDoKkgcWGEbWpj7OYIHTPrA= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 12:47:35 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 12:47:34 +0000 From: "Dobbins, Roland" To: "Salz, Rich" CC: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Matthew Green , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/LbQetAoAc0WMUGwvSG+0rIljKJUZVeAgAAD9wCAAL5cgIAAG3oAgAA+T4CAAB0IgIAAQ4qAgAA3lACAAA63AIAAA1UAgAAC5YCAAiZlAP//l1IAgAAJfdWAAAJIgIAABEUl Date: Mon, 17 Jul 2017 12:47:34 +0000 Message-ID: <2C2FDE20-F5C0-47C0-BF0B-387960CF096B@arbor.net> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> , <057af2f23acc450a9b896f9f0c81b06d@usma1ex-dag1mb1.msg.corp.akamai.com> <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 7:ZSUppn341bgmbcZVXbvYUuPOn1+W8zZ1biwuISTaCgKceiIP47Uv5xKAyqxXw69/jQBarBXZyMG52mV6uJIHQ5sN+YE/rulaXwBFjedGd91F/aDt7CukPZcb5CcJIUPsdkS5lWj3Z7hlzkWZdxa0SQFmGkn7LpVyJbKpKWugaJqz0wlyEJ6y/Zl0r/558nSQEEYAMSJ6vJOeVvDLhkdq1hw1V5f6yvaVOo9XcEUBZou71jfGbyY/XBoq98hOzjs2xhbqm/JVOMAVdeyyBEaZ3rG68ejf7VY6jx4KlH433sI92UxgIFi9Kg+E0sm0EnE3yqkd0clYmc1kNtlOLdjZok4Gs8GWFHpHu0jzXYC0+FwOHyBFhW2fUwI+ibJutwXzaR/XGy5u5rUS8H9Njnuzqqdf3lMYxI4Z9Hm8No7dkQHWlqubnQbuQs6u+23G0qKvSvF12iiGpO3YvYkYDDL+LPxZ2Z6D9CigsGiTAgfGoFnfe/TmA+fMDXERpMuyb2gj56ciBWp3uL+Db8KRFPJOXrRPYzAfTUSX180+XDiHhaMkfS+8lxDJojeRzEZyibUyJMOKjCdV/QLGNNZF6ZTsFdA0bRU1lffFPVKKkFhtX5FSgW80bDrjE2WCK/87K0jdoPcEwKkTR0TDGb+iRH1vM66g+jZa0EeKwcykenoBHIgDcTsRd4NeYzIvKOiVGUu8BxNIQ6iFKCUL3wALGipgGDjmHTlGDWWRzb53I55EztO9pa3+iqa8ljxCI3CJ+ZvCnLDLhC4D+4pzMr0kaaMBS8IKgN2ni83HYvO57p0IkS8= x-ms-office365-filtering-correlation-id: b9b92000-1545-4cac-4717-08d4cd11ff70 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; x-ms-traffictypediagnostic: DM2PR0101MB1039: x-exchange-antispam-report-test: UriScan:(236129657087228)(155532106045638)(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(6506006)(6436002)(478600001)(8676002)(189998001)(7736002)(33656002)(2906002)(8936002)(229853002)(54356999)(76176999)(50986999)(6512007)(236005)(99286003)(54906002)(4326008)(54896002)(66066001)(53936002)(14454004)(39060400002)(6486002)(81166006)(6916009)(2950100002)(36756003)(6246003)(25786009)(110136004)(38730400002)(2900100001)(5250100002)(86362001)(83716003)(3280700002)(82746002)(3660700001)(102836003)(230783001)(5660300001)(93886004)(3846002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2C2FDE20F5C047C0BF0B387960CF096Barbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 12:47:34.7737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 12:47:40 -0000 --_000_2C2FDE20F5C047C0BF0B387960CF096Barbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpQcmVkaWN0aW5nIHRoZSBmdXR1cmUgaXMgaGFyZC4NCg0KRG9lcyBhbnlvbmUgaGF2ZSBhIGNy eXN0YWwgYmFsbCB0aGF0IHNheXMgdGhpcyBNVVNUIGJlIGRvbmUgd2l0aGluLCBzYXksIHRocmVl IHllYXJzPw0KDQpXZSBjYW4gbG9vayBhdCB0aGUgUENJIERTUyB0aW1lbGluZSBmb3IgcHJldmlv dXMgcmV2cyAtIHRoZXJlJ3Mgbm8gZ3VhcmFudGVlIGl0IHdvdWxkIGJlIHRoZSBzYW1lLCBvZiBj b3Vyc2UuIEFuZCB0aGVyZSBhcmUgb3RoZXIgcmVsZXZhbnQgcmVndWxhdG9ycywgYXMgd2VsbC4N Cg0KUGVyaGFwcyBzb21lZW9uZSBmcm9tIGEgcmVndWxhdGVkIGluZHVzdHJ5IHdobydzIG9uIHRo aXMgbGlzdCBjYW4gZ2l2ZSB1cyBzb21lIGluc2lnaHQ/DQoNCkZvciBleGFtcGxlLCBhcmUgYW55 IHZlbmRvcnMgY29tbWl0dGluZyB0byBkbyB0aGlzPw0KDQpWZW5kb3JzIHdpbGwgZG8gaXQgaWYg dGhlaXIgY3VzdG9tZXJzL3Byb3NwZWN0cyAgcmVxdWlyZSBpdC4gIEJ1dCBtYW55IHZlbmRvcnMg aW5zaXN0IG9uIGVpdGhlciBTdGFuZGFyZHMtdHJhY2sgb3IgV0ctSW5mb3JtYXRpb25hbCAoKm5v dCogSW5kZXBlbmRlbnQgU3RyZWFtKSBiZWZvcmUgdGhleSB3aWxsIGNvbW1pdC4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0Bh cmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQo= --_000_2C2FDE20F5C047C0BF0B387960CF096Barbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxz cGFuPlByZWRpY3RpbmcgdGhlIGZ1dHVyZSBpcyBoYXJkLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3Nw YW4+PGJyPg0KPHNwYW4+RG9lcyBhbnlvbmUgaGF2ZSBhIGNyeXN0YWwgYmFsbCB0aGF0IHNheXMg dGhpcyBNVVNUIGJlIGRvbmUgd2l0aGluLCBzYXksIHRocmVlIHllYXJzPyAmbmJzcDs8L3NwYW4+ PC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCldlIGNhbiBsb29rIGF0IHRoZSBQQ0kg RFNTIHRpbWVsaW5lIGZvciBwcmV2aW91cyByZXZzIC0gdGhlcmUncyBubyBndWFyYW50ZWUgaXQg d291bGQgYmUgdGhlIHNhbWUsIG9mIGNvdXJzZS4gQW5kIHRoZXJlIGFyZSBvdGhlciByZWxldmFu dCByZWd1bGF0b3JzLCBhcyB3ZWxsLiZuYnNwOw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGVy aGFwcyBzb21lZW9uZSBmcm9tIGEgcmVndWxhdGVkIGluZHVzdHJ5IHdobydzIG9uIHRoaXMgbGlz dCBjYW4gZ2l2ZSB1cyBzb21lIGluc2lnaHQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPkZvciBleGFtcGxlLCBhcmUgYW55IHZlbmRvcnMgY29tbWl0dGlu ZyB0byBkbyB0aGlzPzwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZGl2PlZlbmRv cnMgd2lsbCBkbyBpdCBpZiB0aGVpciBjdXN0b21lcnMvcHJvc3BlY3RzICZuYnNwO3JlcXVpcmUg aXQuICZuYnNwO0J1dCBtYW55IHZlbmRvcnMgaW5zaXN0IG9uIGVpdGhlciBTdGFuZGFyZHMtdHJh Y2sgb3IgV0ctSW5mb3JtYXRpb25hbCAoKm5vdCogSW5kZXBlbmRlbnQgU3RyZWFtKSBiZWZvcmUg dGhleSB3aWxsIGNvbW1pdC4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwg MCk7Ij48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZh cmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PC9zcGFuPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZh cmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50 LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij5Sb2xhbmQgRG9iYmlucyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCIgeC1hcHBsZS1kYXRhLWRldGVj dG9ycz0idHJ1ZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy10eXBlPSJsaW5rIiB4LWFwcGxlLWRh dGEtZGV0ZWN0b3JzLXJlc3VsdD0iMiI+cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8L3NwYW4+ PC9zcGFuPjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2C2FDE20F5C047C0BF0B387960CF096Barbornet_-- From nobody Mon Jul 17 05:57:07 2017 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 E497412EB8C for ; Mon, 17 Jul 2017 05:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 jdfqnhv3bWm9 for ; Mon, 17 Jul 2017 05:57:03 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0138.outbound.protection.outlook.com [104.47.32.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA2E131B5E for ; Mon, 17 Jul 2017 05:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aOdjcvUqui3m8LLV8qeP9dhgMf8htbAcJKWKvQQEm6A=; b=WLl9UO57ZIO3Rd9JXvVbcfsWbmVpMK6HuXDkEz6DuLs/NFgwwyErflZCyBqhjpIaOoktx8tLxHEE0v+pXDV853OUprGX0sfLGrbU6Hl8U6EOHGwe1j6w/H7fgJBhYA+/kKsC25Gm6LyYCruKtf3VEpx0iPCHCrNc8RWAz0ycawU= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1040.prod.exchangelabs.com (10.160.129.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 12:57:01 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 12:57:01 +0000 From: "Dobbins, Roland" To: Tom Ritter CC: Matthew Green , dkg , "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS/LbQetAoAc0WMUGwvSG+0rIljKJUZVeAgAAD9wCAABgasIAA+jYAgALZoYD//5/OgIAACeFK Date: Mon, 17 Jul 2017 12:57:01 +0000 Message-ID: <3A53E183-BD69-4A31-A2DB-ABA7838082B5@arbor.net> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <87pod1qqh5.fsf@fifthhorseman.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ritter.vg; dkim=none (message not signed) header.d=none;ritter.vg; dmarc=none action=none header.from=arbor.net; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1040; 7:nuIWzwM/8X6kl+t22Hq673QPps4+8s5QSdxZ6keNIBDFc6cmnSCg46e5eXe7YHTKZdPYHEPYuPfodQDxwIo4WMjHPA3Kqr0aFvHAl5Gq8UuhaiIe4rGavMXcX9DpCcsoR4fUuNIgUWxnI02NHxISU3lPOCOmVFIQKGhio5HFI47CfwoFZHEl9tJQsqWSVQkEByWe8XE816P0LVFjjM1+8iBMVXSbC2ZXOSou42dQf13TooB2WsS3BebxMA7SRZ2A027Hj0aIlEq9VccdHGItfFQYbcQ/qPohaev4uXdY6+QQY9b95dWIhy9Av+EgnvEFVfnh5+hdsPb8uM0B7EhJTsSe+1wleq5KHq5syj8aoxy1Fhp6eNBTCeEhPWgYcVnw1do9cE4b907UOVIOJ/88K/g3BXRw9YDJ1RilGCbjL0oUmPtm4EA3xqYqCW1qcXMzOEMckkL5Uvp8wsRzAjMIr1ONRLZ6dCnnlr7BEeNLn5H4OFcO+KKNkZSeM744UkjEdClmavLOh0iBMNAj+hefHXHdDOXqz+t/mCopCcnV+S+Q8mUXsRmpD/si3aYcGMPnIeiyGfzja4CNzYVCOniFtCMh60t8c8DF6e9gSWDgKUnGarwNxv7rJiIIA1NPZw3ZmlS3Q0tLcELS4pOB6gEBZhMN+oYiYZOswnluY650y3Q96xDxn9m9/I6gB6+BEaigFcHsp6/XGQ3+uyk1JdX2a2n8l9IgSYHLBh7xquSXUn15gFqpM8UD8sAG+x0dE66Xj9VV8q/NWLBUSho/A0DZWvO34hmI77SFMcYT+lmMAUc= x-ms-office365-filtering-correlation-id: c409b91b-ec83-46c5-bf53-08d4cd13511a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1040; x-ms-traffictypediagnostic: DM2PR0101MB1040: x-exchange-antispam-report-test: UriScan:(236129657087228)(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1040; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1040; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39410400002)(39850400002)(39400400002)(39840400002)(39450400003)(24454002)(3846002)(5660300001)(86362001)(54356999)(3280700002)(38730400002)(33656002)(4326008)(3660700001)(478600001)(102836003)(6116002)(2906002)(7736002)(50986999)(76176999)(230783001)(39060400002)(6246003)(110136004)(93886004)(229853002)(6486002)(53546010)(6506006)(53936002)(83716003)(14454004)(189998001)(81166006)(236005)(25786009)(6512007)(66066001)(54896002)(8676002)(36756003)(2900100001)(2950100002)(6916009)(82746002)(5250100002)(8936002)(99286003)(6436002)(54906002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1040; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3A53E183BD694A31A2DBABA7838082B5arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 12:57:01.3612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1040 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 12:57:05 -0000 --_000_3A53E183BD694A31A2DBABA7838082B5arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgMTcsIDIwMTcsIGF0IDE0OjIxLCBUb20gUml0dGVyIDx0b21Acml0dGVyLnZnPG1h aWx0bzp0b21Acml0dGVyLnZnPj4gd3JvdGU6DQoNCkl0IHNob3VsZCBiZSB2aXNpYmxlIG9uIHRo ZSBvdXRzaWRlIG9uIHRoZSBjb25uZWN0aW9uLCBzbyBtaWRkbGUgYm94ZXMgdGhhdCBkb24ndCBi cmVhayBUTFMgY2FuIHNlZSB0aGF0IFRMUyBpcyBiZWluZyBicm9rZW4uDQoNCldpdGggdGhlIGNh dmVhdCB0aGF0IHRoZSBkZXRhaWxzIG9mIGhvdyBpdCdzIGFjdHVhbGx5IGltcGxlbWVudGVkIGFy ZSBrZXkgKHBhcmRvbiB0aGUgcHVuKSwgSSB0aGluayB0aGUgZmVhc2liaWxpdHkgb2Ygc29tZXRo aW5nIGFsb25nIHRoZXNlIGxpbmVzIHNob3VsZCBiZSBjb25zaWRlcmVkLg0KDQogIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJi b3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0K --_000_3A53E183BD694A31A2DBABA7838082B5arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T24gSnVsIDE3LCAyMDE3LCBhdCAx NDoyMSwgVG9tIFJpdHRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbUByaXR0ZXIudmciPnRvbUBy aXR0ZXIudmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPg0KPGRpdj5JdCBzaG91bGQgYmUgdmlzaWJsZSBvbiB0aGUgb3V0c2lkZSBvbiB0 aGUgY29ubmVjdGlvbiwgc28gbWlkZGxlIGJveGVzIHRoYXQgZG9uJ3QgYnJlYWsgVExTIGNhbiBz ZWUgdGhhdCBUTFMgaXMgYmVpbmcgYnJva2VuLg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+ DQo8ZGl2PldpdGggdGhlIGNhdmVhdCB0aGF0IHRoZSBkZXRhaWxzIG9mIGhvdyBpdCdzIGFjdHVh bGx5IGltcGxlbWVudGVkIGFyZSBrZXkgKHBhcmRvbiB0aGUgcHVuKSwgSSB0aGluayB0aGUgZmVh c2liaWxpdHkgb2Ygc29tZXRoaW5nIGFsb25nIHRoZXNlIGxpbmVzIHNob3VsZCBiZSBjb25zaWRl cmVkLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7PHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48L2Rpdj4NCjxzcGFuIHN0eWxl PSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFu OiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+Um9sYW5kIERv YmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiIHgtYXBwbGUtZGF0 YS1kZXRlY3RvcnM9InRydWUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtdHlwZT0ibGluayIgeC1h cHBsZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9IjIiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7 PC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3A53E183BD694A31A2DBABA7838082B5arbornet_-- From nobody Mon Jul 17 06:02:23 2017 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 2BA76131B72 for ; Mon, 17 Jul 2017 06:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 OAPhDLo11PTl for ; Mon, 17 Jul 2017 06:02:16 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0096.outbound.protection.outlook.com [104.47.34.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71793131B74 for ; Mon, 17 Jul 2017 06:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8Mg/JQpNfpd9ev+COylvK9qvef0m4m8/SEOc1JhxzoE=; b=WoEHf7nblG4GFZrVoVvGiAS9lprBdblXyuuFOjA28B/Szk7hN1HoJuJyGPK7wrnw4bPQA78aP9Ga653PokaCIn7h75HB686wWrwRJYZSOEQ7002wP4eeIf+Fx//+4cdqjH8z2obP5lSxIbH3u6obi93qhBGcOsjhEv0N98GB14w= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 13:02:15 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 13:02:15 +0000 From: "Dobbins, Roland" To: Russ Housley CC: Martin Thomson , IETF TLS Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) Thread-Index: AQHS/vRnKFRxxE429kKncr36no97/qJX7moAgAANgG0= Date: Mon, 17 Jul 2017 13:02:15 +0000 Message-ID: <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=arbor.net; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:EXzE2ZgDm9w9Qrhz3bWjTL6bjApmK2NjQDxBYxQUr0/tHWF7IZYMOvjrBwUxziBzWYyaoBgNUDSvWqtphgV/dXTck0V7SrABdPFaHqbA1pdaOuG1bd0G4Y9T8aVKHJ/RJogxiAWJXJ1g6S4JuBsVzFdQC+4V9yYGu7tWVODqh7tqW6mzzfAnL5g5Xd56tMXlHa4vJt6gEFmVMBGUQC5yDpmop6qrVvi8d/QWFpJ4BFNY6gjnUeFF0M23K24Com5z2jRwKBaMEHxPwhNpmxYj+nQ7AnlHs7tY40iTj/WPFiKOFxr3NKfvBvn941lP1Pf71aLemoJWlRZbluan4ygBHaJVWmAmJK+ZIP5M1qzNSA/YAhktH7OZ/jr2rP8hldN6ZF7u3zqdIZutAPKVq1MlIGTeg4q2Wvb6yysfzJE8WXk0hu+iWfrJ9xsIElYTE+KplYuBkFh9XQaEvo/AFa+SCjKwnTmiS5caG2ju16iPtMzYEo7cDuNOOqW+Rhv+NwCl9qwsxll5dxYOqbhb6+c7420og6G2GFPlCdSo2xoVjro2ghQGnfbNNknnXQlFr0+IPiWb1JnCyAnbZnYqcQ7tUJpn5607QxOLIPAUpXGHu+3CQKtrCLpD+FwHf1m4Fmv2zAJE0EDn8souLuiR2YPURNbqYOOCRq13ux1d8a9q9Gf8Paoc8gVlnr3Mc5gmDohX+47ko7Zg7zGlKgeOMDgM6IqPapryJqLt4BDrKHBSSN+rOwMv8CYQfYD57J1oufYWzxZ0P1nGWFg0Ojz0BWGWdRvZblsdH38/bj3N1MKEO0s= x-ms-office365-filtering-correlation-id: 9a89b6c0-712a-463b-d171-08d4cd140c37 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(158342451672863)(236129657087228)(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39840400002)(39400400002)(39410400002)(51444003)(24454002)(5250100002)(81166006)(7736002)(8676002)(53546010)(2950100002)(6916009)(4326008)(189998001)(82746002)(2900100001)(83716003)(33656002)(6486002)(6506006)(14454004)(38730400002)(478600001)(6436002)(110136004)(3846002)(6116002)(229853002)(39060400002)(25786009)(102836003)(8936002)(2906002)(86362001)(50986999)(5660300001)(230783001)(53936002)(6246003)(54356999)(66066001)(76176999)(54896002)(3280700002)(93886004)(54906002)(36756003)(99286003)(3660700001)(236005)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9C81BE7B7C214504B60D96BA95C3D2FDarbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 13:02:15.2076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 13:02:18 -0000 --_000_9C81BE7B7C214504B60D96BA95C3D2FDarbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTQ6MTQsIFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdp bHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPj4gd3JvdGU6DQoNCkkgdGhpbmsg dGhhdCB0aGUgSURTIGlzIHRyeWluZyB0byBkZXRlY3QgdGhlIGFuIGluZmVjdGVkIHNlcnZlciB0 cnlpbmcgdG8gbWlncmF0ZSB0byBhbm90aGVyIHNlcnZlci4gIE1hbHdhcmUgb2Z0ZW4gaW5jbHVk ZXMgYSBzZXJpZXMgb2YgZXhwbG9pdHMgdGhhdCBhcmUgdHJpZWQgaW4gc2VxdWVuY2UgdG8gaW5m ZWN0IGEgbmVpZ2hib3IsIGFuZCB0aGlzIGFjdGl2aXR5IHByb3ZpZGVzIGEgZGV0ZWN0YWJsZSBz aWduYXR1cmUuDQoNCkNvcnJlY3QuIEFuZCBub3QganVzdCBiZXR3ZWVuIHNlcnZlcnMuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJp bnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0K --_000_9C81BE7B7C214504B60D96BA95C3D2FDarbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3 LCBhdCAxNDoxNCwgUnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdp bHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0K PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+SSB0aGluayB0aGF0IHRoZSBJ RFMgaXMgdHJ5aW5nIHRvIGRldGVjdCB0aGUgYW4gaW5mZWN0ZWQgc2VydmVyIHRyeWluZyB0byBt aWdyYXRlIHRvIGFub3RoZXIgc2VydmVyLiAmbmJzcDtNYWx3YXJlIG9mdGVuIGluY2x1ZGVzIGEg c2VyaWVzIG9mIGV4cGxvaXRzIHRoYXQgYXJlIHRyaWVkIGluIHNlcXVlbmNlIHRvIGluZmVjdCBh IG5laWdoYm9yLCBhbmQgdGhpcyBhY3Rpdml0eSBwcm92aWRlcyBhIGRldGVjdGFibGUgc2lnbmF0 dXJlLjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPGRpdj5Db3JyZWN0LiBBbmQgbm90IGp1 c3QgYmV0d2VlbiBzZXJ2ZXJzLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48 c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQt ZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFu PjxiciBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQt ZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5v cm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0 aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij5Sb2xhbmQgRG9iYmlucyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycz0i dHJ1ZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy10eXBlPSJsaW5rIiB4LWFwcGxlLWRhdGEtZGV0 ZWN0b3JzLXJlc3VsdD0iMiI+cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8L3NwYW4+PC9zcGFu PjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9C81BE7B7C214504B60D96BA95C3D2FDarbornet_-- From nobody Mon Jul 17 06:15:15 2017 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 8AB22131B74 for ; Mon, 17 Jul 2017 06:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cem.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvZAL-9ZcX6O for ; Mon, 17 Jul 2017 06:15:12 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 733CD131B72 for ; Mon, 17 Jul 2017 06:15:12 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 64so16149772uae.2 for ; Mon, 17 Jul 2017 06:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L1mV/MBh2JMCV12fAAp+QqMKIZMfClaJvR2hqVzLnDs=; b=Q212b+mvJl+AkyvJK/clkpc5eV6xMghMU3k3IgIcbNXgicBvxJcXH53OzvnH4opvoz +CyB0UwKAFnmNk6M5b6Bd9IVwyLo1gWDElq1L7tjU68//Pqds0QiqUWXwnu+XQQkjNdI RTJcvti8Vn5+uIr0wTNGYGxcsfhY8PritywSc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L1mV/MBh2JMCV12fAAp+QqMKIZMfClaJvR2hqVzLnDs=; b=Q1qjRVNfoGfV5YSO/F1ytEhO8cp4ISVmbJgWYltEk6bNjM/TYhlwilgqJ0DakaJ8vA pjKdwXPtCcixHwzZHGnWbgpOpQZco9DaMkMPJCtIpO569h04d+KXtvQ53ZK/uGOQurRu J6cumR7/0ndsZWP7OVPXSy+pL0VqoGtWNddYwC2MKpYU/sswHuMFdBkj5W2d3b5XE2DH mky7+NTk2YEHlx7Q2vKlpI/V0bHqXFnMzCWDidamF6IKlJjWShqysB0iHAFaMzK+amdI knknD09b/Kvi/YYbgdPjKF7J3oviAGj+BFpMJcFEd9i9Ua7cqrpmUY97ipuya8VOVHBd mhTw== X-Gm-Message-State: AIVw111oHtQe00z6gdzNsbWAssuwVcF81/c7Q/YuAEnFNn512SfV/TBM MqEd4CwhKU1d8FH0oniyVvNh1jhe7sdDjzA= X-Received: by 10.31.217.130 with SMTP id q124mr10623946vkg.130.1500297311389; Mon, 17 Jul 2017 06:15:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.174 with HTTP; Mon, 17 Jul 2017 06:15:10 -0700 (PDT) X-Originating-IP: [172.8.175.41] In-Reply-To: <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> From: Carl Mehner Date: Mon, 17 Jul 2017 08:15:10 -0500 Message-ID: To: "Dobbins, Roland" Cc: Russ Housley , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 13:15:14 -0000 On Mon, Jul 17, 2017 at 8:02 AM, Dobbins, Roland wrote: > > > On Jul 17, 2017, at 14:14, Russ Housley wrote: > > I think that the IDS is trying to detect the an infected server trying to > migrate to another server. Malware often includes a series of exploits that > are tried in sequence to infect a neighbor, and this activity provides a > detectable signature. > > > Correct. And not just between servers. I think the point that Martin was making (and if he wasn't, I will): that malware is becoming increasingly aware that IDS/IPS and TLS proxy boxes are looking into TLS traffic, and they're beginning to encrypt traffic inside the TLS tunnel. That pushes the problem back into the application layer, and on the endpoint to be dealt with by antivirus tools. From nobody Mon Jul 17 06:32:04 2017 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 733D4131B99; Mon, 17 Jul 2017 06:31:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-tls-ecdhe-psk-aead@ietf.org, Kathleen.Moriarty.ietf@gmail.com, Joseph Salowey , tls@ietf.org, joe@salowey.net, tls-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150029831646.14969.17938697879292829404.idtracker@ietfa.amsl.com> Date: Mon, 17 Jul 2017 06:31:56 -0700 Archived-At: Subject: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 17 Jul 2017 13:31:56 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-07-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines several new cipher suites for the Transport Layer Security (TLS) protocol version 1.2. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES- CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 17 06:35:35 2017 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 A662C131BA1 for ; Mon, 17 Jul 2017 06:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 OKChDvTD85sH for ; Mon, 17 Jul 2017 06:35:33 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0098.outbound.protection.outlook.com [104.47.33.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C0E131BB4 for ; Mon, 17 Jul 2017 06:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KSFI2FSYvtqfIFHg/MMGoA+1bHnRkLRahQUFRsbvfWc=; b=D2k7gKkv2W0/P7WvWsBbp5TmQeBhHonUnEhfoETnFvy2G5AQEOqer+V9VLHwRFLA9BIGQeZ+uSkqG8s8fjV7DVJf5qyMXepkzOTvjXNFm0rjsdAU9B7JiKWS0cTTWgFi9GyEKPhUlxEsXLcf5qnuTWbURBXqms8SycW4JdYK26A= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 13:35:24 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 13:35:24 +0000 From: "Dobbins, Roland" To: Carl Mehner CC: Russ Housley , IETF TLS Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) Thread-Index: AQHS/vRnKFRxxE429kKncr36no97/qJX7moAgAANgG2AAAOcAIAABadK Date: Mon, 17 Jul 2017 13:35:23 +0000 Message-ID: References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cem.me; dkim=none (message not signed) header.d=none;cem.me; dmarc=none action=none header.from=arbor.net; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:kjbDrg3OXRUzQGn3jy6Y2B33P9wEI4j/0/QcOWTJIXOd2ate1MU5yClHt331gY+8J0Di9E8wDKN4fGpufTR28KdlROBP+vC3ZUqpxmNaPMkGYjaMIFWEC60QUBV33yUS1KoetNwAqCqM7GOz2xDpUo5OWri6gBVJhbDlqNr15gKJbAELUa6Qe7mkbHULeT59k6kBpUdXTZI/oJwnI/fi1QZhTJoLYWgkZSQxYQyd5xmLq4WTVyDXo6x2haQdg+a5RpxzBP4e3Q1cW68l6QsDlGwPpOKgvmjOVzumjJDW/xibltRv9K5xtdZPkw8W8XvTFK+K9erQK41k18bO5hSMns3NbOLJSwq23zvmSVanqW8xPZHEr9/rA0BqQz7CZtS5x8DrYdPEQ/kjK3xjGW03yH/Elv6SNd3sK9cYTzugYt9HcR8bkL1k44RaWcf1J5H1R45cQuPxWGgXLKIY6aPjGSkGfWXLKz6PrtUPuoXxULLEkTEFxIqNIGRZTdd6abKxGiqrCg7mWueFRBZRO+vu50JuKjYSMRbWX7pAHFQ9jMn+wW1cszwkEfFYW1b+B6rK6BfqidTvpVjNTQ3MW/KE2r6y54b7Zk2JThAMG/ou8nVgMnMOnVOWBPDUoH3cApmziR9W1CZwhJUg55VEUqQepmTDrPT8BVDPNOHAFbP/XS45v7K3HfvpY623AmdJKpTSR34J1PUpuADvGbd0fynmRvSxHTfKD1JyWuvbJlRSyDyV0WjG5XyezypYEjVKZ9Uj9tlDdBqHX6gUKcFyStXIsqGrotjYxb3gy143XkcggYE= x-ms-office365-filtering-correlation-id: 2732e163-be11-4558-895e-08d4cd18ad98 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(236129657087228)(50300203121483)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39840400002)(39450400003)(39410400002)(39400400002)(24454002)(5250100002)(81166006)(7736002)(8676002)(53546010)(2950100002)(6916009)(14454004)(4326008)(189998001)(82746002)(2900100001)(83716003)(33656002)(6486002)(6506006)(38730400002)(478600001)(6436002)(110136004)(3846002)(6116002)(229853002)(25786009)(102836003)(8936002)(2906002)(86362001)(50986999)(5660300001)(230783001)(6246003)(53936002)(54356999)(66066001)(76176999)(54896002)(3280700002)(93886004)(54906002)(36756003)(99286003)(3660700001)(236005)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CC3CE5F8C8C24A70829D483E26D20733arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 13:35:23.9884 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 13:35:35 -0000 --_000_CC3CE5F8C8C24A70829D483E26D20733arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTU6MTUsIENhcmwgTWVobmVyIDxjQGNlbS5tZTxtYWls dG86Y0BjZW0ubWU+PiB3cm90ZToNCg0KYmVnaW5uaW5nIHRvIGVuY3J5cHQgdHJhZmZpYyBpbnNp ZGUgdGhlIFRMUyB0dW5uZWwuDQoNClllcywgc29tZSAoYnV0IGJ5IG5vIG1lYW5zIGFsbCkgYXJl IC0gd2hpY2ggbWVhbnMgdGhhdCBpbiBzdWNoIGNhc2VzLCB0aGUgYWJpbGl0eSB0byBsb29rIGlu c2lkZSB0aGUgVExTIHR1bm5lbCBzbyBhcyB0byBiZSBhYmxlIHRvIGRldGVjdCB0aGUgcHJlc2Vu Y2Ugb2YgYW4gYWRkaXRpb25hbCBsZXZlbCBvZiBlbmNyeXB0aW9uIGFzIGEgcG9zc2libGUgaW5k aWNhdG9yIG9mIGNvbXByb21pc2UgaXMgZXh0cmVtZWx5IGltcG9ydGFudC4NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJv ci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQo= --_000_CC3CE5F8C8C24A70829D483E26D20733arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3 LCBhdCAxNToxNSwgQ2FybCBNZWhuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpjQGNlbS5tZSI+Y0Bj ZW0ubWU8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdj48c3Bhbj5iZWdpbm5pbmcgdG8gZW5jcnlwdCZuYnNwOzwvc3Bhbj48c3Bh bj50cmFmZmljIGluc2lkZSB0aGUgVExTIHR1bm5lbC4gPC9zcGFuPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YnI+DQo8ZGl2Plllcywgc29tZSAoYnV0IGJ5IG5vIG1lYW5zIGFsbCkgYXJlIC0g d2hpY2ggbWVhbnMgdGhhdCBpbiBzdWNoIGNhc2VzLCB0aGUgYWJpbGl0eSB0byBsb29rIGluc2lk ZSB0aGUgVExTIHR1bm5lbCBzbyBhcyB0byBiZSBhYmxlIHRvIGRldGVjdCB0aGUgcHJlc2VuY2Ug b2YgYW4gYWRkaXRpb25hbCBsZXZlbCBvZiBlbmNyeXB0aW9uIGFzIGEgcG9zc2libGUgaW5kaWNh dG9yIG9mIGNvbXByb21pc2UgaXMgZXh0cmVtZWx5IGltcG9ydGFudC4mbmJzcDs8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2Jh KDI1NSwgMjU1LCAyNTUsIDApOyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6 IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBv c2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6 IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBv c2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+ Um9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiIHgt YXBwbGUtZGF0YS1kZXRlY3RvcnM9InRydWUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtdHlwZT0i bGluayIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9IjIiPnJkb2JiaW5zQGFyYm9yLm5l dDwvYT4mZ3Q7PC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CC3CE5F8C8C24A70829D483E26D20733arbornet_-- From nobody Mon Jul 17 06:40:21 2017 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 9FAEA131BC8 for ; Mon, 17 Jul 2017 06:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cem.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHTgElS-JQlg for ; Mon, 17 Jul 2017 06:40:18 -0700 (PDT) Received: from mail-ua0-x241.google.com (mail-ua0-x241.google.com [IPv6:2607:f8b0:400c:c08::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCD1131B5D for ; Mon, 17 Jul 2017 06:40:18 -0700 (PDT) Received: by mail-ua0-x241.google.com with SMTP id z22so10069709uah.0 for ; Mon, 17 Jul 2017 06:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+6N6X32+9t4ifuMMOpZsS1hEYe+PBcm+QBz4PIgNFkU=; b=M39nyEC2ChlGXehM81etLxbmQB4ch3zAf85Svs7qw5XUHjUNRGqx2PnIxUSq4LBBGz N1vgGRGi68N68g4G0w7x+LHjxMhmwL+ikoJ3JoJeLpCIIDk+ItNXBTxf2RxehXZff0JT 57QVLz6TvCGZlOCbMbDGAarREn8h+I2z0eBwY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+6N6X32+9t4ifuMMOpZsS1hEYe+PBcm+QBz4PIgNFkU=; b=clkZaYHD2wUjENyP00bUNHJc9PQlkKQwepmRBeiW2rUTnNdM9tqoyuRZozv+wUnCjl 8VcAac/vDBzoy2Jv6QXWqdlJc3uqvh6RqmsfNdT+/SUqbeqxLnGrMaf32UmVXMK6IX09 eBxQJl5s/1HnvMKRLVym+a5ErpMzlYv1CXtjzHKUQpoVFbnob7BywO4y9DQoODn2IRg3 iz/Td4Dc+JGvcAc6oixX4GTpupmRlIKeREXcXH2JGodZPKVmiQoLFT5sxLuY+DHSxwOl zpd1OPToW/EBq6UygHOsnCrZ02b2N43/f499NBUiZHI5FbNbKsDKKeHnvKFgI+kvK1Rv RXhQ== X-Gm-Message-State: AIVw112zqmTTPPHVwzl5K5XtHh836RqysdcIsYOMU1cRzvfcphQOukpu 401YDXGGn50EtUQjRLAG+ckASQZ434Ji X-Received: by 10.176.24.80 with SMTP id j16mr13035227uag.120.1500298817311; Mon, 17 Jul 2017 06:40:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.174 with HTTP; Mon, 17 Jul 2017 06:40:16 -0700 (PDT) X-Originating-IP: [172.8.175.41] In-Reply-To: References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> From: Carl Mehner Date: Mon, 17 Jul 2017 08:40:16 -0500 Message-ID: To: "Dobbins, Roland" Cc: Russ Housley , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 13:40:19 -0000 On Mon, Jul 17, 2017 at 8:35 AM, Dobbins, Roland wrote: >> On Jul 17, 2017, at 15:15, Carl Mehner wrote: >> beginning to encrypt traffic inside the TLS tunnel. > Yes, some (but by no means all) are - which means that in such cases, the > ability to look inside the TLS tunnel so as to be able to detect the > presence of an additional level of encryption as a possible indicator of > compromise is extremely important. Are you worried about malware encrypting traffic between nodes in an intranet communicating with servers on that intranet you control which would use this draft? that seems very unlikely. Why would malware use this draft? Malware would use either it's own server, or basic utilities provided by the system (i.e. wannacry's use of SMB). From nobody Mon Jul 17 06:54:24 2017 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 2365F131BBA for ; Mon, 17 Jul 2017 06:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 zrExS7FJy1tY for ; Mon, 17 Jul 2017 06:54:20 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0103.outbound.protection.outlook.com [104.47.38.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C96B131BAA for ; Mon, 17 Jul 2017 06:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aj+zlCGkGjMWWOLvb3NS8fWKJkanhtwCy6oL7gH6deY=; b=ZuB0qQ9cDdids6Qj6X7guf0pTyGpvZxmfSrcX5bF7AIi0TlpB2XJZst2xZ6SGQnm2av2IUM/Pe6+la2x44iiwpuRH9Hqk7BbUlAblmbWso1Q7HXxjfzkH5AfKJYV96GE4gKmkSIrDjwySZYWE9DTCjhak+rD7i177e6t1BRh0OU= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1040.prod.exchangelabs.com (10.160.129.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 13:54:17 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 13:54:17 +0000 From: "Dobbins, Roland" To: Carl Mehner CC: Russ Housley , IETF TLS Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) Thread-Index: AQHS/vRnKFRxxE429kKncr36no97/qJX7moAgAANgG2AAAOcAIAABadKgAABXACAAAPrLg== Date: Mon, 17 Jul 2017 13:54:17 +0000 Message-ID: References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cem.me; dkim=none (message not signed) header.d=none;cem.me; dmarc=none action=none header.from=arbor.net; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1040; 7:JZYnF1cXHxJC9aHjcFJFuIqiDMQLizgmmEdi/TnQXrFPjBsz6UyDO9++eRiINXsZhFdqA+HXu/X2wzF0Q9wR3nhzrAY6YcWgkAe/4ArYDUJPCmyEnI1DQ8FvKrtRezwBrPnYLN1MAIg48KY+WKmgZjTkiFDE1LbDa/tzmaTgohlUaAX3ItQtD8FwVvCdOFg3eoYwlRDxU30FH5DX0CpUHJXYR0YTMtv/B1I28HtstZ666QpI5AxCdnWb445yP5RV+s9hav1NZc98bzpRTPAUND5QSGe7AYbheOIhz3NIWbTR1RNvNGkR4KUYZYrELxCrKanIiDdyqHaROC847dGiPH9RcD6hVXyAXrtuRRUAjGLQEuNqJqRpOpZV0opaYvf2r80RkpBaeWE6KDFG1IqpJstOTmGFIRy9neK6s+GGDfSvJCPNZyfHs54RyckSZEgffg+GyfGU7dyvc6xeLSj8+t1BlIC4/Wu68aOiB8xRj4M44qnBUqvu3C0u6A5TGmJ1gYhPxs0fElr+eEXQXZZYLGqMVMy1/AL5hyWk7241wWN3Rt1Cf09BnTEMdFANX0ifLKJtH+e2c8UI+QUE0ZBrwjf3+DJc2FDtxUKKMqMsXoPR1XbhJNLdYTA6Ahl+dlCtWZOpNvGqpSbfQ1o64VkQE1hVW/Yd/h/39RBYkj7IX3IF9afBaU/7hm5z9+vFgtg7ZV9tWKI4VXInB5NAZebTl55+ieRmsgrqRr/rLiaDqppj4MLzwLH7H6B9EmPBuF1WXsrA7hj8W6gzOtHQbh5toZokdhos5FaIYFxPNuxuhm4= x-ms-office365-filtering-correlation-id: c8350d8e-8032-46a8-d799-08d4cd1b515f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1040; x-ms-traffictypediagnostic: DM2PR0101MB1040: x-exchange-antispam-report-test: UriScan:(236129657087228)(50300203121483)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1040; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1040; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39410400002)(39840400002)(39450400003)(24454002)(3846002)(5660300001)(86362001)(54356999)(3280700002)(38730400002)(3660700001)(4326008)(33656002)(478600001)(7736002)(102836003)(6116002)(2906002)(50986999)(230783001)(76176999)(6246003)(110136004)(93886004)(229853002)(6486002)(53546010)(6506006)(53936002)(83716003)(14454004)(81166006)(189998001)(236005)(25786009)(6512007)(66066001)(54896002)(8676002)(6436002)(36756003)(2900100001)(2950100002)(6916009)(82746002)(5250100002)(8936002)(99286003)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1040; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C3B01C35E3A24A8B9DD7D6E4153ED39Farbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 13:54:17.6785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1040 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 13:54:22 -0000 --_000_C3B01C35E3A24A8B9DD7D6E4153ED39Farbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTU6NDAsIENhcmwgTWVobmVyIDxjQGNlbS5tZTxtYWls dG86Y0BjZW0ubWU+PiB3cm90ZToNCg0KV2h5IHdvdWxkIG1hbHdhcmUgdXNlIHRoaXMgZHJhZnQ/ DQoNCk5vYm9keSBzYWlkIGFueXRoaW5nIGFib3V0IG1hbHdhcmUgdXNpbmcgdGhpcyBkcmFmdC4N Cg0KV2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgdGhlIGFiaWxpdHkgdG8gbG9vayBpbnNpZGUgdGhl IFRMUyB0dW5uZWwgJiBpbmZlciB0aGUgcHJlc2VuY2Ugb2YgYW4gYWRkaXRpb25hbCwgdW5leHBl Y3RlZCBjcnlwdG9zdHJlYW0gLSBldmVuIHdpdGhvdXQgdGhlIGFiaWxpdHkgdG8gZGVjcnlwdCBp dCAtIGlzIHF1aXRlIHZhbHVhYmxlLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNA YXJib3IubmV0Pj4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJvbGFu ZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+ DQo= --_000_C3B01C35E3A24A8B9DD7D6E4153ED39Farbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3 LCBhdCAxNTo0MCwgQ2FybCBNZWhuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpjQGNlbS5tZSI+Y0Bj ZW0ubWU8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdj48c3Bhbj5XaHkgd291bGQgbWFsd2FyZSB1c2UmbmJzcDs8L3NwYW4+PHNw YW4+dGhpcyBkcmFmdD88L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZGl2Pk5v Ym9keSBzYWlkIGFueXRoaW5nIGFib3V0IG1hbHdhcmUgdXNpbmcgdGhpcyBkcmFmdC4gJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGF0IEknbSBzYXlpbmcgaXMgdGhhdCB0 aGUgYWJpbGl0eSB0byBsb29rIGluc2lkZSB0aGUgVExTIHR1bm5lbCAmYW1wOyBpbmZlciB0aGUg cHJlc2VuY2Ugb2YgYW4gYWRkaXRpb25hbCwgdW5leHBlY3RlZCBjcnlwdG9zdHJlYW0gLSBldmVu IHdpdGhvdXQgdGhlIGFiaWxpdHkgdG8gZGVjcnlwdCBpdCAtIGlzIHF1aXRlIHZhbHVhYmxlLiAm bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFy aWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsg Zm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtdmFy aWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsg Zm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxz cGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1l YXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhl aWdodDogbm9ybWFsOyI+Um9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmlu c0BhcmJvci5uZXQiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnM9InRydWUiIHgtYXBwbGUtZGF0YS1k ZXRlY3RvcnMtdHlwZT0ibGluayIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9IjIiPnJk b2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1 LCAyNTUsIDApOyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsg Zm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsg Zm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQt bGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQt dmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+Um9sYW5kIERv YmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiIHgtYXBwbGUtZGF0 YS1kZXRlY3RvcnM9InRydWUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtdHlwZT0ibGluayIgeC1h cHBsZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9IjIiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7 PC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C3B01C35E3A24A8B9DD7D6E4153ED39Farbornet_-- From nobody Mon Jul 17 06:59:56 2017 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 3E87B131BE6 for ; Mon, 17 Jul 2017 06:59:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cem.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlKJKhADAFsP for ; Mon, 17 Jul 2017 06:59:52 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 8835A131BE0 for ; Mon, 17 Jul 2017 06:59:52 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 35so48792424uax.3 for ; Mon, 17 Jul 2017 06:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EApRPU7e3P701RC235Sv/IsVrE5c38/ULHJm1g5Us/c=; b=E0pbB+JvfdcbPQ9DZ7RWNN5nSYiKgQmTL1pWDG7CIICsqtfBaa1IIrYlgR4maq3Zkc WZ6WGQS2opg6vpnOAWHEx9XO6e/t/I9MJMqXcnb9t9FiksRAiqPTpDTUTwDaHumSgIRk Xz6J2ckMSa0Em9VjAfucCpZXpJ0gh/+Ts/AUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EApRPU7e3P701RC235Sv/IsVrE5c38/ULHJm1g5Us/c=; b=PY+WbMpDAShC6CvpWPD0Q3LBBiPyjaye7CGeRl9HJBrUuAsyRBVO15XlLzIfp04T1F 0H9L+w9l4qc84wyEF0I7VQsV0xGwcKH32S3fsynT4+b1WTa6y0Tbp8A7uWxCLE5E++B/ eydlNTZk2LX2/FhyggUdc1glsqXHjXk7rypfOSzZlJiWquOb0arssoAPWkcsJJM8e0Ds F/YQc04RfvhiXgRZojhM66btJsqoJ6SgxBgkvLmugkOUEfCR7To8SPJZFo83CLaouvtC +MkWUo8Yq8ZioAVo9jE9R6H5PWY0Z0k/Uzq3NATzP5XKacPuS0loQw7qCJ9D0fwqUdkP pb4A== X-Gm-Message-State: AIVw1124UrwOZt2UD1aBMZHXv1R17YfbRBkPSI+PWnk4BOexnMm3Assw Z4TIZ5vtRWXmW3sKVU0dGA003KX1X7QmXMLgHA== X-Received: by 10.159.58.204 with SMTP id q12mr2244974uag.7.1500299991533; Mon, 17 Jul 2017 06:59:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.174 with HTTP; Mon, 17 Jul 2017 06:59:51 -0700 (PDT) X-Originating-IP: [172.8.175.41] In-Reply-To: References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> From: Carl Mehner Date: Mon, 17 Jul 2017 08:59:51 -0500 Message-ID: To: "Dobbins, Roland" Cc: Russ Housley , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 13:59:54 -0000 I have not heard any assertions that looking at unencrypted tls traffic is not valuable. I agree that there are cases that it is. What I and others have disagreed with is that the examples provided on the list and in the draft of where it is necessary are either not applicable, or simply 'easier' rather than necessary. In the email below, I was trying to find out which case malware would fall into. do you have an example of where malware would be on your intranet using this draft (the only way that this draft would help you with malware analyzing), if you do not, let's remove malware analysis from this list of arguments for this draft. On Mon, Jul 17, 2017 at 8:54 AM, Dobbins, Roland wrote: > > > On Jul 17, 2017, at 15:40, Carl Mehner wrote: > > Why would malware use this draft? > > > Nobody said anything about malware using this draft. > > What I'm saying is that the ability to look inside the TLS tunnel & infer > the presence of an additional, unexpected cryptostream - even without the > ability to decrypt it - is quite valuable. > > ----------------------------------- > Roland Dobbins > > ----------------------------------- > Roland Dobbins From nobody Mon Jul 17 07:04:44 2017 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 F3EB2131BB0 for ; Mon, 17 Jul 2017 07:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 cbEF3stY1QjB for ; Mon, 17 Jul 2017 07:04:36 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 755B3129482 for ; Mon, 17 Jul 2017 07:04:36 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6HE4ZfX009776 for ; Mon, 17 Jul 2017 10:04:35 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8cSScAhmTiiEWvrRLNt+JsyqJKs/sAgAkO1QCAAPElgIAAA/YAgAC+XICAABt7AIAAPk+AgAAdB4CAAEOLgIAAN5MAgAAOtwCAAANWAIAAAuSAgAGxDQCAAAyrAIAACXyA///ZAwA= Date: Mon, 17 Jul 2017 14:04:34 +0000 Message-ID: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> <057af2f23acc450a9b896f9f0c81b06d@usma1ex-dag1mb1.msg.corp.akamai.com> <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net> In-Reply-To: <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.0.170702 x-originating-ip: [172.26.150.37] Content-Type: text/plain; charset="utf-8" Content-ID: <850C772FEB4F7A4ABA48E6F95E1A259A@ll.mit.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170220 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 14:04:43 -0000 QSBoaWdoZXItbGV2ZWwgdmlldyBvbiB0aGlzIGlzc3VlLg0KDQpUTFMgaGFzIGJlZW4gZGVzaWdu ZWQgYXMgYSBwcm90b2NvbCB0aGF0IGFsbG93cyB0d28gZW50aXRpZXMgdG8gY29tbXVuaWNhdGUg c2VjdXJlbHkgb3ZlciBhIG5ldHdvcmsgY29udHJvbGxlZCBieSBhbiBhZHZlcnNhcnksIGluY2x1 ZGluZyBhYnVzaXZlIGF1dGhvcml0aWVzLg0KDQrigJxCdXQgd2UgKHRoZSAobmV0d29yaykgYXV0 aG9yaXRpZXMpIGFyZSB0aGUgZ29vZCBndXlzLCBhbmQgd2UgbmVlZCB0byBicmVhayB0aGUgZ3Vh cmFudGVlcyBUTFMgcHJvdmlkZXMgc28gd2UgY2FuIGNhdGNoIGNyaW1pbmFscyDigJMgYW5kIGhl cmUgaXMgaG93IHdlIHByb3Bvc2UgdG8gYnJlYWsgVExTLTEuM+KAnS4gDQoNCkNvbnNpZGVyaW5n IHRoYXQgdW5sZXNzIGF0IGxlYXN0IG9uZSBvZiB0aGUgZW5kLXBvaW50cyBjaG9vc2VzIHRvIGNv bXBseSB3aXRoIHRoZSDigJxydWxlc+KAnSBpdCB3aWxsIG5vdCB3b3JrIOKAkyB0aGUgY2xhaW0g dGhhdCB0aGlzIG1lYXN1cmUgaXMgdG8gaGVscCB0aGUgZ29vZCBndXlzIGRvZXMgbm90IHNvdW5k IHZlcnkgY2FuZGlkLg0KDQpXaG8gaXMgdGhlIGludGVuZGVkIHRhcmdldCBvZiB0aGlzIG1lY2hh bmlzbT8gV2hhdCBraW5kIG9mIGNyaW1pbmFscyBpcyBpdCBzdXBwb3NlZCB0byBjYXRjaC9kZXRl Y3Q/IFN1cmVseSBub3QgdGhlIG1hbHdhcmUgdGhhdCBwZW5ldHJhdGVkIHlvdXIgaW5mcmFzdHJ1 Y3R1cmUgYW5kIHRyaWVzIHRvIOKAnGNhbGwgaG9tZeKAnT8NCg0KSGlzdG9yeSBzaG93cyB0aGF0 IGNyaW1pbmFscyB2aW9sYXRlIGxhd3MsIHJlZ3VsYXRpb25zLCBhbmQgZXZlbiBuZXR3b3JrIHBy b3RvY29scyAoOi0pIOKAkyB0aGF04oCZcyB3aHkgdGhleSBjYWxsZWQgY3JpbWluYWxzLiBDcmlt aW5hbHMgYWxzbyBwcm92ZWQgY2FwYWJsZSBvZiBjcmVhdGluZyBxdWl0ZSBzb3BoaXN0aWNhdGVk IG1hbHdhcmUuIFRoZSBwcm9wb25lbnRzIG9mIHRoZSDigJxicm9rZW4gVExT4oCdIHNvbWVob3cg ZXhwZWN0IHRoYXQgdGhvc2UgY3JpbWluYWxzIHdvdWxkIHVzZSB3ZWFrZW5lZCBjcnlwdG8gZm9y IHRoZSBjb252ZW5pZW5jZSBvZiB0aGUgbmV0d29yayBwb2xpY2UuIEhvdyBtdWNoIHNlbnNlIGRv ZXMgdGhpcyBtYWtlPyBFeHBlcmllbmNlIHNob3dzIHRoYXQgY3JpbWluYWxzIHVzZSBub3QganVz dCBjdXR0aW5nIGVkZ2Ug4oCTIGJsZWVkaW5nIGVkZ2UgY3J5cHRvLiBGb3IgZXhhbXBsZSwgY29u c2lkZXIgQ29uZmlrZXIuIFBsdXMsIHRoZXJlIGFyZSBtYW55IHdheXMgdG8gZm9pbCB0aGlzIHBy b3Bvc2VkIG1lY2hhbmlzbSDigJMgZm9yIGV4YW1wbGUsIHN1cGVyLWVuY3J5cHRpbmcgdGhlIGRh dGEgYmVmb3JlIHRyYW5zbWlzc2lvbi4NCg0KVGhlbiB0aGVyZeKAmXMgYW4gaXNzdWUgb2YgdGhl IGFidXNlcy4gRmlyc3QsIG5vdCBhbGwgb2YgdGhlIOKAnGxlZ2l0aW1hdGXigJ0gYXV0aG9yaXRp ZXMgYXJlIOKAnGdvb2QgZ3V5c+KAnSAoYWxsIHRoZSB0aW1lIDopLiBTZWNvbmQsIEnigJltIG5v dCBhd2FyZSBvZiBhbnkg4oCcbmV0d29yayBzZWN1cml0eeKAnSB0b29sIHRoYXQgaGFzbuKAmXQg YmVlbiBzdWJ2ZXJ0ZWQgYXQgc29tZSBwb2ludCBpbiB0aW1lLiANCg0KVGhlIGxpa2VseSByZXN1 bHQgb2YgdGhlIOKAnHN0YXRpYy1kaC3igKbigJ0gcHJvcG9zYWwgaXMgaW1wcm92ZWQgbWFzcyBz dXJ2ZWlsbGFuY2UgYnkgYXV0aG9yaXRpZXMsIGFuZCBleHBsb2l0cyBvZiB0aGlzIG1lY2hhbmlz bSBieSB0aGUgb3JnYW5pemVkIGNyaW1lLg0KIA0KVG8gdGhvc2Ugd2hvIG5lZWQgdGhhdCBzdXJ2 ZWlsbGFuY2U6IHN0YXkgd2l0aCBUTFMtMS4yLiBBbiBpbXBvcnRhbnQgZ29hbCBvZiBUTFMtMS4z IGlzIHByZXZlbnRpbmcgdGhlIHBvc3NpYmlsaXR5IG9mIHRoaXMgc3VydmVpbGxhbmNlLg0KDQpU byBldmVyeWJvZHk6IHlvdSBjYW7igJl0IGhhdmUgeW91ciBjYWtlIGFuZCBlYXQgaXQgdG9vLiAN CkVpdGhlciB5b3UgaGF2ZSBQRlMgYW5kIHRoZSBiYWQgZ3V5cyB3aWxsIGJlbmVmaXQgZnJvbSBp dCB0b28gKHNvIHlvdSBuZWVkIHRvIGRldGVjdCBhbmQgZmlnaHQgdGhlbSB1c2luZyBvdGhlciBt ZXRob2RzKSwgb3Igb25seSB0aGUgYmFkIGd1eXMgaGF2ZSBQRlMgYW5kIHlvdSBtaWdodCBbMF0g ZGV0ZWN0IHRoZW0gYmVjYXVzZSB0aGVpciDigJxwcm90ZWN0aW9uIHF1YWxpdHnigJ0gc3RhbmRz IG91dCBhbWlkc3QgdGhlIG9jZWFuIG9mIHRoZSBhdXRvbWF0aWNhbGx5LWluc3BlY3RlZCAmIGNl bnNvcmVkIHRyYWZmaWMuDQoNCg0KWzBdIOKAnE1pZ2h04oCdIHJhdGhlciB0aGFuIOKAnHdvdWxk 4oCdLiBCZWNhdXNlIHRoZXJlIGFyZSB3ZWxsLWtub3duIHdheXMgb2YgaGlkaW5nIHRoZSBwcmVz ZW5jZSBvZiBlbmNyeXB0aW9uLCBhdCB0aGUgY29zdCBvZiBpbmNyZWFzZSBvZiB0aGUgY2lwaGVy dGV4dCBzaXplLiBUaGUgaG9wZSB0aGF0IHRoZSBlbmNyeXB0ZWQgdHJhZmZpYyB3b3VsZCBzdGFu ZCBvdXQgaXMgdW5mb3VuZGVkLiBDb25zaWRlcmluZyBob3cgZmFzdCB0aGUgYXR0YWNrIHNvcGhp c3RpY2F0aW9uIGlzIGV2b2x2aW5nLCB0aGUgbGlrZWxpaG9vZCB0aGF0IOKAnHRoZXnigJ0gd291 bGQgZW1wbG95IG90aGVyIGNvdW50ZXJtZWFzdXJlcywgYnV0IGlnbm9yZSB0aGlzIG9uZSBpcyBm YWlybHkgbG93Lg0KLS0NClJlZ2FyZHMsDQpVcmkgDQoNCg0KDQo= From nobody Mon Jul 17 07:11:31 2017 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 47309131BEF for ; Mon, 17 Jul 2017 07:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 TpLpGGlNz_5x for ; Mon, 17 Jul 2017 07:11:27 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0136.outbound.protection.outlook.com [104.47.37.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1420A131BE5 for ; Mon, 17 Jul 2017 07:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GG0TY7Bb1U6ROgH0AWm4exLKEhJYppOhSJoisXTlAwg=; b=lJfRxyfIADw1HtFFASo9z84RSYSnGyGvyutmiBEANu+KMptgX1JinrqEult+mTJvAoZvE6suKOsotkRYe4ktTqAKh35G3y3cJWvhqjvcws9mJYGfEhL9w8QHKwsQPttCchvpu4DprZlCGuC6vWY9VzpcZaf5yg4L4w9JnjbNcdA= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 14:11:26 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 14:11:25 +0000 From: "Dobbins, Roland" To: Carl Mehner CC: Russ Housley , IETF TLS Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) Thread-Index: AQHS/vRnKFRxxE429kKncr36no97/qJX7moAgAANgG2AAAOcAIAABadKgAABXACAAAPrLoAAAY6AgAADO3Y= Date: Mon, 17 Jul 2017 14:11:25 +0000 Message-ID: References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cem.me; dkim=none (message not signed) header.d=none;cem.me; dmarc=none action=none header.from=arbor.net; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:gKvJS5yFagwQL0h7cbCBbOixVmH0Weei2h8SrVnKvnoqJz3n7FA6f8Vk14fkFFDwLjhR58HWsTAea3WqiyrqHjcoKL5jEzM0ak3piiK84a4ZGFANsgiu/QyidqQWSf6ejBv74e1xGO66PkgwbSYIdFKWwHi1ffneQRaCb2pD9ewFC1XD3xduTtPRo0N4aqbT4aEv6WuqQwaZ/EjkrUTSCprszp+L59NPGC0zkasyscNt3sNs1xdg4Cix2s2LelvGD8gtiJGdBbPiRbC1v5yLuF0BDhaS2IgZDZpEvlxX3qbAj+5DRynf487hM8VM86LXru2UmAjDIHOTxUfNHu0u4VmfaphlqfgntGHQxvrVqK5V9qfmPUji078F0JllrY3Wuy7pqlX78SnPQp9oARh1r06pTwNB5BqI3mpNy8nx1urJkmZ1UR2k8jaPRuoF5pzGUdXGfFWOiDB+Wk67iAXdnqSbnMlSeMuviOOdvBeMkb+dNSOPTuZ9u6oApY+VV/Wl9eY7EoP+n4a3QRzOdgcxIICf7OnVS/pyPl5fG/+h6DMG5Fu9ooiX/VSy0mZDFl8TzJGKJg+zIWw6nxcSFdvhH+nlJwVcCmlkfgcUmKuWmyUxrwNheM/FrsIjjAK56xuzXGB3TugeXaoe5ML44N2D4VwAnsF+ONCThFRPeVtZdZBJlHatxH0O1bfXQqmkCCo9wAdmt3hVZAZxuKWjkbKqdPlCddsF+nUD+5TOE0czcYEQ+JM8HMVfo8JK6QmOsSVJdcJvwM2iV4wVUbq9YGDUVVj+W8gBFol3HHQ70jqn7e8= x-ms-office365-filtering-correlation-id: 85b275f8-5875-49b4-e62b-08d4cd1db617 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:(236129657087228)(192374486261705)(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39840400002)(39400400002)(39850400002)(24454002)(6246003)(230783001)(5660300001)(50986999)(53936002)(76176999)(54356999)(66066001)(3660700001)(99286003)(36756003)(236005)(6512007)(54896002)(3280700002)(93886004)(54906002)(2900100001)(6916009)(82746002)(83716003)(4326008)(189998001)(14454004)(6506006)(33656002)(6486002)(7736002)(81166006)(5250100002)(8676002)(53546010)(2950100002)(102836003)(8936002)(229853002)(25786009)(86362001)(2906002)(6436002)(478600001)(38730400002)(6116002)(3846002)(110136004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BE4E8E4A51FC4211A16FEBA8B3F01757arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 14:11:25.6972 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 14:11:29 -0000 --_000_BE4E8E4A51FC4211A16FEBA8B3F01757arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTU6NTksIENhcmwgTWVobmVyIDxjQGNlbS5tZTxtYWls dG86Y0BjZW0ubWU+PiB3cm90ZToNCg0KdGhlIG9ubHkgd2F5IHRoYXQgdGhpcyBkcmFmdCB3b3Vs ZCBoZWxwIHlvdQ0Kd2l0aCBtYWx3YXJlIGFuYWx5emluZykNCg0KVGhpcyBzdGF0ZW1lbnQgaXMg ZmFjdHVhbGx5IGluY29ycmVjdC4gIEl04oCZcyBub3QgdGhlIG9ubHkgd2F5LCBhcyBJJ3ZlIGp1 c3QgZXhwbGFpbmVkLg0KDQpBZ2Fpbiwgd2h5IGFyZSB5b3UgdHJ5aW5nIHRvIHByZXRlbmQgdGhh dCB0aGUgdXNlIG9mIHRoaXMgdGVjaG5pcXVlIGlzIG5vdCBwcmV2YWxlbnQgbm9yIGltcG9ydGFu dCBpbiB0aGUgc2VjdXJpdHkgY29udGV4dCwgd2hlbiBpdCBpcyBpbiBmYWN0IHF1aXRlIHByZXZh bGVudCAmIGltcG9ydGFudCwgJiBoYXMgYmVlbiBmb3IgbWFueSB5ZWFycz8NCg0KQW5kIHdoeSBh cmUgeW91IHVuYWJsZSB0byB1bmRlcnN0YW5kIHRoYXQgdGhhdCBpbiB0aGUgY2FzZSBvZiBhbiBh ZGRpdGlvbmFsIGxheWVyIG9mIGF0dGFja2VyLWdlbmVyYXRlZCBjcnlwdG8gbmVzdGxlZCB3aXRo aW4gYSBUTFMgdHVubmVsLCBhcyB5b3UgcG9zaXRlZCwgdGhhdCB0aGUgYWJpbGl0eSB0byBzaW1w bHkgZGV0ZWN0IHRoZSBwcmVzZW5jZSBvZiBzdWNoIGFuIGFkZGl0aW9uYWwgbGF5ZXIgb2YgdW5l eHBlY3RlZCBjcnlwdG8sIGV2ZW4gd2l0aG91dCB0aGUgYWJpbGl0eSB0byBpbW1lZGlhdGVseSBk ZWNyeXB0IGl0LCBoYXMgc3Vic3RhbnRpYWwgdmFsdWUgaW4gYSBzZWN1cml0eSBjb250ZXh0Pw0K DQpBcmUgeW91IHVuZmFtaWxpYXIgd2l0aCB0aGUgY29uY2VwdCBvZiB0cmFmZmljIGFuYWx5c2lz LCBpbiB0aGUgY3J5cHRvIHNlbnNlIG9mIHRoZSB0ZXJtPw0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWls dG86cmRvYmJpbnNAYXJib3IubmV0Pj4NCg== --_000_BE4E8E4A51FC4211A16FEBA8B3F01757arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3 LCBhdCAxNTo1OSwgQ2FybCBNZWhuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpjQGNlbS5tZSI+Y0Bj ZW0ubWU8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdj48c3Bhbj50aGUgb25seSB3YXkgdGhhdCB0aGlzIGRyYWZ0IHdvdWxkIGhl bHAgeW91PC9zcGFuPjxicj4NCjxzcGFuPndpdGggbWFsd2FyZSBhbmFseXppbmcpPC9zcGFuPjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPGRpdj5UaGlzIHN0YXRlbWVudCBpcyBmYWN0dWFs bHkgaW5jb3JyZWN0LiAmbmJzcDtJdOKAmXMgbm90IHRoZSBvbmx5IHdheSwgYXMgSSd2ZSBqdXN0 IGV4cGxhaW5lZC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFnYWluLCB3 aHkgYXJlIHlvdSB0cnlpbmcgdG8gcHJldGVuZCB0aGF0IHRoZSB1c2Ugb2YgdGhpcyB0ZWNobmlx dWUgaXMgbm90IHByZXZhbGVudCBub3IgaW1wb3J0YW50IGluIHRoZSBzZWN1cml0eSBjb250ZXh0 LCB3aGVuIGl0IGlzIGluIGZhY3QgcXVpdGUgcHJldmFsZW50ICZhbXA7IGltcG9ydGFudCwgJmFt cDsgaGFzIGJlZW4gZm9yIG1hbnkgeWVhcnM/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5BbmQgd2h5IGFyZSB5b3UgdW5hYmxlIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGF0IGluIHRoZSBj YXNlIG9mIGFuIGFkZGl0aW9uYWwgbGF5ZXIgb2YgYXR0YWNrZXItZ2VuZXJhdGVkIGNyeXB0byBu ZXN0bGVkIHdpdGhpbiBhIFRMUyB0dW5uZWwsIGFzIHlvdSBwb3NpdGVkLCB0aGF0IHRoZSBhYmls aXR5IHRvIHNpbXBseSBkZXRlY3QgdGhlIHByZXNlbmNlIG9mIHN1Y2ggYW4gYWRkaXRpb25hbCBs YXllciBvZiB1bmV4cGVjdGVkIGNyeXB0bywNCiBldmVuIHdpdGhvdXQgdGhlIGFiaWxpdHkgdG8g aW1tZWRpYXRlbHkgZGVjcnlwdCBpdCwgaGFzIHN1YnN0YW50aWFsIHZhbHVlIGluIGEgc2VjdXJp dHkgY29udGV4dD88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFyZSB5b3UgdW5mYW1p bGlhciB3aXRoIHRoZSBjb25jZXB0IG9mIHRyYWZmaWMgYW5hbHlzaXMsIGluIHRoZSBjcnlwdG8g c2Vuc2Ugb2YgdGhlIHRlcm0/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxzcGFuIHN0 eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFz aWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyIHN0 eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFz aWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyI+DQo8c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBm b250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPlJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJt YWlsdG86cmRvYmJpbnNAYXJib3IubmV0IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4 LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5cGU9ImxpbmsiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMt cmVzdWx0PSIyIj5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozwvc3Bhbj48L3NwYW4+PC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BE4E8E4A51FC4211A16FEBA8B3F01757arbornet_-- From nobody Mon Jul 17 07:15:23 2017 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 2F04E131BFC for ; Mon, 17 Jul 2017 07:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TT5lPEc7W77q for ; Mon, 17 Jul 2017 07:15:17 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 BF3BD131BF2 for ; Mon, 17 Jul 2017 07:15:16 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id y43so1645637wrd.3 for ; Mon, 17 Jul 2017 07:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rpwq/PnkAZFqE3VRODELIlyFuFwreVDWZIJTnzceSTM=; b=lyLfYvBf2AP9/fUkvEopLdpHSztM9OoMEbzPixU08WqhVoaAsdhJ/eF3tff9rnUUQl eNJX415m/1ylCr2p1a4xQB/FkLP7z1vPcOAtMcJ/MChJ+qrIvCHdxZ7sZ0NXLQt5uBst CzrB121gVUwuLlqk4zr+vy861iOezrvwjWnvxLeLRJeiCC+5LgOz1zup+xWrdUaZaqlx NwW51rIj9NYZCELoc94ik2sCq3RR4Q76E+BdpjVE2SQ8MxCDZuutIA75A0SPizU8OJwd MsMTVV3tdH3Io7CJu3N+QIqayp2/CZrWmOpKfIuoEupMwRHVY3IviW+VAn8kKUvka1Z1 DDxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rpwq/PnkAZFqE3VRODELIlyFuFwreVDWZIJTnzceSTM=; b=SnJXIGO2Txdli1EnzJZjtIdZJlLuc7csKdRJ+dTJXtKB5KtrJ8iSWl9nzg8sgo3v5B dOZ+gw/jWutaIp/+GmHwjfhdHB4JD661vfaHEGMwidcpTbSU143qdqoyqBp7qiZNQ/Ye 75W87mm529Qb06ZPFbV7ol/XiwP5bve3WxlWbYlvQmv582OXHpadRfV5zpa1JIGrHEQ2 FBUIVDq4usiSH2Fl8HgLUA9MIguLkwdv5OanMdlnIV+RHgea++jLuHRNJj5LiPUm/7v3 Iur2qVWFWFOs4w++IUfQM5CMgBJkhvjbo2ulVrSTDxRjuCOcON3r49cFFvNZwDkdWI46 OvBw== X-Gm-Message-State: AIVw112f6+rGo1wvY/edplhis2v2NenVYqC8M+TA5SPF2gAoY2ibA6I0 xl7BK4P0dvpuhQ== X-Received: by 10.223.134.207 with SMTP id 15mr11641735wry.127.1500300915325; Mon, 17 Jul 2017 07:15:15 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:4866:e216:9a2c:96a? ([2001:67c:370:128:4866:e216:9a2c:96a]) by smtp.gmail.com with ESMTPSA id 3sm10335076wrs.18.2017.07.17.07.15.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 07:15:14 -0700 (PDT) From: Yoav Nir Message-Id: <79DD9197-1ACF-4133-86CF-C2E121F6B2C2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C0C78552-83BF-4FE1-ACD4-98DE1EF5ECEA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Jul 2017 16:15:12 +0200 In-Reply-To: <3847dfbfb9f5497a8aababb665e18ea8@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: "tls@ietf.org" To: Rich Salz References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> <3847dfbfb9f5497a8aababb665e18ea8@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 14:15:20 -0000 --Apple-Mail=_C0C78552-83BF-4FE1-ACD4-98DE1EF5ECEA Content-Type: multipart/alternative; boundary="Apple-Mail=_D1A3A06C-076C-4C10-B1E1-BB30DF72F4D7" --Apple-Mail=_D1A3A06C-076C-4C10-B1E1-BB30DF72F4D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 17 Jul 2017, at 13:48, Salz, Rich wrote: >=20 >>> DDoS mitigation can be done at endpoints >>=20 >> Not at scale. That's why it isn't done that way. >=20 > Sometimes it is. >=20 > Can we stop making definitive declarations like this? >=20 > There are more things in the world, Horatio, then are dreamt of in = your philosophy. Obligatory XKCD link: https://xkcd.com/1737/ --Apple-Mail=_D1A3A06C-076C-4C10-B1E1-BB30DF72F4D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 17 Jul 2017, at 13:48, Salz, Rich <rsalz@akamai.com> = wrote:

DDoS mitigation can be done at endpoints

Not at scale.  That's why it = isn't done that way.

Sometimes = it is.

Can we stop making definitive = declarations like this?

There are more = things in the world, Horatio, then are dreamt of in your philosophy.

Obligatory XKCD link:

https://xkcd.com/1737/

= --Apple-Mail=_D1A3A06C-076C-4C10-B1E1-BB30DF72F4D7-- --Apple-Mail=_C0C78552-83BF-4FE1-ACD4-98DE1EF5ECEA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbMZxAAoJELhJCxUKWMyZ/+sIAIstyp/iZVhlItIgsXBh6Q3k 3mS1m6F/4cnqw65K4xbhKEYspdVZptE1XX9r3pZB2g6tKoNspEEdB3jtYN22ZWKU /8dY//SfGwsXM1sGlf+dSYJ2NaHgustnnVnAmmjmPP5x1gqiuFQ9CI3HP2rQDKhh g+6NSNXfgTzOFOyf855YHSOp8apeFsrg73MpfFaj4SA6ustTzUbpnjp/XRk2YdaP 3FWlxG7UYrfS5AUFXkV6sJu3ROkInNz9VAjhH4L1InVQ2duSsMPNAcz+aXGf5rm5 POwJBkkiNeno2WZCBVsnA7lMREwGgS8X7WE4eWIQC4wnHkmt7Z3LPSgL1voa06Y= =0jgU -----END PGP SIGNATURE----- --Apple-Mail=_C0C78552-83BF-4FE1-ACD4-98DE1EF5ECEA-- From nobody Mon Jul 17 07:20:40 2017 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 53782131BB0 for ; Mon, 17 Jul 2017 07:20:38 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 hDdN9mje6KQl for ; Mon, 17 Jul 2017 07:20:36 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0099.outbound.protection.outlook.com [104.47.36.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F58B131714 for ; Mon, 17 Jul 2017 07:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P8UmTAbF61EEqWACAgt18rolvXdRqbimHsgrsKVfCG8=; b=PS9eC0hlYvzjEDVjwAeEviq1SUR8YUZUcG7KkkF+s4f8yXmSroyqwnEI4IbCbTpqyWttdFDpuUZKu3qI3SBsAwfZfO9m1ORcmyRNbQRpqTOGW1aeKJGZRruXDoao6YsCBcZfDdJeCennkhXoG3CLVCo18oOP+8/XCPzF9CiDEv0= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by BN3PR0101MB1027.prod.exchangelabs.com (10.160.182.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 14:20:33 +0000 From: "Roland Dobbins" To: "Yoav Nir" Cc: "Rich Salz" , "tls@ietf.org" Date: Mon, 17 Jul 2017 16:20:22 +0200 Message-ID: In-Reply-To: <79DD9197-1ACF-4133-86CF-C2E121F6B2C2@gmail.com> References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> <3847dfbfb9f5497a8aababb665e18ea8@usma1ex-dag1mb1.msg.corp.akamai.com> <79DD9197-1ACF-4133-86CF-C2E121F6B2C2@gmail.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Content-Type: text/plain X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: HE1P189CA0002.EURP189.PROD.OUTLOOK.COM (10.160.72.15) To BN3PR0101MB1027.prod.exchangelabs.com (10.160.182.156) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e0b678c3-be34-4254-43b0-08d4cd1efcb1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0101MB1027; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 3:ojvwhe9q3+nVrIoQIG8aEEqcAZ4Okfcho1L0WlNhDGzOQNYo9Cbsi88ZiB4Deff4WjCzasoqvF13/8X+FHOFwh+EML9JqdfFCMf+Vkuk2BlOgFB3jfWqfr4gAI7F8wkbbe51nZ8EPEcEecIU1J6UqkCm62RgbAiLEVkrJwx9Reb7pCGnK+HmR7ywpaLPgfW3BFs8+8eRgBkkyJ+4i+H9oF0GjIgXbnBp9F42GKWV56CY/GIuTshpJD7FCrJmgheaQ+55HYWsTKH7Lx0yGvyc26e7uNY6mwM0XfSXPZU0eGRsLjKt1QxPzwkx5bATW6BhWLzIIbilv1V5sddX39AWcLwCkGE5aPfSSim7gYnPXqy8LhHKfq/BAuKHaGyDf8biRHuzLsiUO5jDo9jnSffnDcVtYgZ6/z9ziu54MGVVmYPzxkW3jYXvLA6xLgy6mwCo0olic8EAcocGnWnDPT2Nc8yMkINcjsDEompwJDRZHjQYow1eKAy0V4DQcv82sPpa2/uB7suDbOpwzZx/tvnKVmFcO4FUDBKUUubhplyUZf1zrJnXFIi/EFqqx1QjA1gLfsDcl/jTyCQSiRimJBC0YQeoj//ZGGz2kGCNKCWyAbj2xtP3YRjcsXWci44esK+1g9Lhkgltg672shFu7gNvxxx4c52N48IdpUZ2gJq7I2dBM4ptymSjQK4BkbIJ89Y1glFnLfGUsq3RPIm9luuYnAcd7BKMx8UjEdqmlN+AH2Y= X-MS-TrafficTypeDiagnostic: BN3PR0101MB1027: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 25:Mg1giv+1jnm9Qhx0QODSg7wEufsu2yfOU3QpXFJVEX7tYgLJmQPmYXufwk9K26OdxNKi/ffJBfXU2fCJwKl3fNGu7zkOpIpjGdC8HqNPjhE+fCnOJ4Sslkp6bJe4t30R0xCL7vzjOOdyotWn1j+Keb3gakbhlb8HfEhKCRMwIZxN6RQ/3DkxSr8mZqBjwXTeqFEr/ilWugcU+8ValasclWV9hz6NiYnAQwka+q/M5hn/aEKv9drAQX2HjTSCSDwg6bQ3NSrzvgYVFxMS34wjAgxLYWSjkMVZDS37hILwPz3eVy3iTC95qcBIn9GCHvSCXS4ns0uthDTxKLnQ6gKEYtsYtsmVZ5N5uNl6lTPzwBl0qa+pd2V3gSABDMFknnk987C0biyHuODdjHjBaig0tvoFiH3bauWShzvO7hJqlX34BpkBwk9t2liplBMZyopZJeoYHnBjZIeib8jtgzs7tc/MoVNrEf7vpNfsNvaSyHTwyCT2ZiLN9ytrqdLD4JveY38yFbnI81lbJEeCuIBut3XRDkGdNW15cBtsHpXbizh1jFpo3htNMTeeZEpqYhDnlmzTx1g9Q26Qs2Dr34X5Y7q0V7CQhSdIvutfZQWbXkkrmc+aAXJ+Dpf2ObH1PmhXtzu1CjUD+UttdeecQ7I2MJcwNFrhzJnzlNjy8CRTV0epkURdyIzoLPyiq6IvGbuuztzb/xV15FRpw7ferC0QG0s5eiGbyR9qdxPC5gIzAoHFbuQ+Sa3eXyjsNlWVZVkfgCW8ZhfQqxBeBLrfrZoVqHVpXXcJcnqn6tLQh9z4FE3Bgg6Jo9y1i+bkBvbBcAWQ+an9qIqCnlz89KlXbk7lh6XThE3TuhTN4vFam4fwpm+C7T2XWmftYBSj3fryy9sxjha9UM+o2HIxnlW2+rDe6QnjD+ZXuPtLTaqjubvwWYA= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 31:OBmhDDVGLGvsZIjL9Pm2gsW3W5QyzfJfqj0ckFo6U2hps/taI7wF1yGaQGcBRpCIcddOk8Qq5QTSggoMca5TkrDILGNb61ZwGzaYIdELlRyNaunL3HclizbG0w44GaeV2HqwnIzwBTqrFFGMcFJgsggjf5MNCgWBV3Q3mSTPlVOZMjf3EN/zS52DCUXTD4U7wXv9QV7fHjjYWzRwMmwr4qc7QwVnPDJBt98mvnF2ntJzAjUfNq/kvjyjBjYWk/yI8q75BycnPmtRwFYfpoymqaSJdJyh2r1foLWBKiX9EMXouF2hSg39gD2wIsObGoHW3KRXA4mgjY6xZX03jq8EPEV7lmu+j6GgXY+uwrZKX44njhwC8noateCfkpDnmCrPI8ekK6kGgtFn7KWOohwZp4G86BHHweR62sdHGJV6au0T/jzgfvS5yZoPRU2WOG+BRHWrePA1RcSsyBDPaGwfCWVtbQp4gj0PtyWp4RSLzJu6WPR4Ez/hGayrSIJh8b/Trn8aZfwsQznN32pXsgRrTZRPkVycwIZ6Z4xll7Z9KTtaFKDBMVwJ64KOq3OVfB2MtfrBIkNMuvf7qVpUrwhbGju6M5RjNmGfio4oBwI7aQyH5NbBRcYQBMrDcoQ3ZwqgEByNVf94mfVu2rlo0SrrdosAjW9mKc3YTah/4WPDl2k38JqxaYZphSpP1GoT3n96 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 20:IVl0oPhHjgtCuXpz7J+KZuOkr6sQ5ALyK+/xWnlWEzFI+GKHXSzSZzEbRrJLL5EBYPKy+5+CveFNSVb6zxPyt3cEbyMJaADptLm3XYBH5L8heoe3ZMEp4ruH8wCBh+E+pQrgY7i9XvIyHr4cFctD61u+ezW02i+arJ73QmI8u4e0zL6cRvGVkawQehGmRIi8zjwJO/qm3vAn7WTxhpXhqvdoBGOqCARf9sOjQ7X1x27xuEeqc/5fRLEfkknydDPSKW8Qhho1ZV9jrHnpdPsET+mSbqUn46MYXmsMlmuC/eFuqOHpg/6xYOAavgH6l/301RDeXfkzKYDboYXsXwHIey1wGVgcbtf/0y/+nG62Gp9Awh39S7+ULIXrOHelfKX4+GFaaeF4ZAPn2OPs+JYvsjdQLun2m7+yGH9Jf+3NxHBGEqHxXUXLq3HjkydmBfFYogSk5mGn8SbnJNTHL9AZIGD37VZuGMNo6DagefYTNhuR2FqKGqqoDypzFJUv8Z1T X-Exchange-Antispam-Report-Test: UriScan:(144208319314845)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0101MB1027; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0101MB1027; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1027; 4:gP4LWh+tLeOiaPALhub8Z5+6lt/HpodRfOh/UTec?= =?us-ascii?Q?rDVSJ3osw9IVb0KZk+yWf4v/eUXXQKk+cPuEkIJ2PUQZu9a85RcBoOHNRQVK?= =?us-ascii?Q?DxuG0J9c05gcQR2ABOQltdQAnPuSsvyIngDN3uM3HYDPbZ9BnqnnCYTWR71n?= =?us-ascii?Q?TI1uKjZd6nffYWa8r2uz0BhGZnRypIA+5sndd1/jNhn2rycP1/7WU7oXIwmd?= =?us-ascii?Q?cL+AWFXYhlJEmwXWR/J8ol82pj32vtDDyqF1LYtclwHx5kqlDLG9bV+bqrTX?= =?us-ascii?Q?29Ko0kfoP+ROf+wJm5aKjHRQYGUywzK7myaFVqFKIsUNLm82inUXYJQWWmCG?= =?us-ascii?Q?D6VFIRS8Gyqa0j0d7AsVWD9XM+1x8zTWf9YCn3S9UzyjDzWilAaoNo34pwKY?= =?us-ascii?Q?5FMarP9sq1ADkM2cZS28hAmXMdjKBvI8eyBKi2kw7mgGJ/pSKPEW6bQZTMdE?= =?us-ascii?Q?LI2Y4nRmBX0omS7D3wZhS7Rf4lf4alHjtocix53/Q/XVVXKXDaw48nH9XJaE?= =?us-ascii?Q?iMjbT6KyQ7G+SNuAfnPKli8AA7z/78TyJOBfHeWoq2ufoA5tU3C8FS1I6vgy?= =?us-ascii?Q?y/lLK+JHAf0ubK5+2oy4yTFePimJwum/XqRAvC/4fWt0+NH81C7vp6+0jYVY?= =?us-ascii?Q?Qb73i3b9aSo83wbeI9pd/GidBxu9IapGpx3Nex7doPftbO4teqq7VySQ3vLu?= =?us-ascii?Q?N89mRErTklmyIB1to++4KFonVwo9CD3Sol8Ftu9pk5zW/J7bFQajnh5ReYAr?= =?us-ascii?Q?Np3CQQsP310ZwXca/R9WP6BTkWC4VlSGKUmpElKSByfEsX822nEkwHxqFH0C?= =?us-ascii?Q?se/3tBZeR1FOf+WwAGgqfX0t2ABk35A2fg0cX6h5O5rVhnB1EgNfv2odf/x3?= =?us-ascii?Q?IhYJSD/3QLyQFScM8Gc906ISbMgFbtp8X7OR+/f7wxy4Y0ATI2l7Cc9qOPr5?= =?us-ascii?Q?VWzGTk/n4PJsGOfY3djiypkWCYMN2+bA0IL5DzSoLYf85T6E0/AJ1NuZ8eyU?= =?us-ascii?Q?u76Rqk68ljFHH3gd/h28DuDRLPyqDxljZypJniDtk7qEO/fhqH6J22H2PFGq?= =?us-ascii?Q?n9OQTVk1suVIzdX+iEtUe/QdAV+hDD27RqwT8cMCJQuSg/SLd1lo+DXNbeF+?= =?us-ascii?Q?XFakdqyjiHySw/fjzX4sE+/W3lTpr0QS6WaSlO391xXT2MX+16cT9ddS2Hrs?= =?us-ascii?Q?qrcF1pywWyNPTge/efVRWX48V9DE5oAqtG3sWBk2jhWNGj+mxRgObiVWuIyl?= =?us-ascii?Q?CpEB9QZ9B6tWK2eq0CY=3D?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(6049001)(39450400003)(39410400002)(39400400002)(39840400002)(39850400002)(24454002)(25786009)(229853002)(36756003)(2950100002)(53546010)(81166006)(6916009)(83716003)(42186005)(82746002)(66066001)(189998001)(50226002)(305945005)(7350300001)(47776003)(6666003)(558084003)(3846002)(6306002)(53936002)(38730400002)(48376002)(230783001)(50466002)(90366009)(478600001)(54906002)(5660300001)(4326008)(93886004)(77096006)(6116002)(6486002)(6246003)(2906002)(110136004)(50986999)(33656002)(8676002)(76176999)(86362001)(5003940100001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1027; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1027; 23:71glwq+S9muwO6Qwd40cF06+o3GGtgfhBW3/t9K?= =?us-ascii?Q?BH3KLrXGWhXRw6UkGa0MYHRmyCHLOHN1X4Wqw26ipYv1pZYDhxHA/1ypawF5?= =?us-ascii?Q?2QdP4/XyiK+RPOknsYMohkj6uw32ubBdKUmNzSzNSACATfQ03e+MNJ3WkjPX?= =?us-ascii?Q?foaOq6yAHRB4nJQw3eG/xxSEFhkReZGzblDJOGwv2v+21FDrb694JX730nv7?= =?us-ascii?Q?v0O/feC/991lYW+k3s6ZDb9FXzorywh5gQFEjcKXAghoIfkOpCUaQWT2x64S?= =?us-ascii?Q?cylPiRxED3mgFU7lKQjikBJKi3efmHE3RKXKU4VWSLfUKGcyYv7QvowEH+iJ?= =?us-ascii?Q?5IzcwkQcS+OD1xKnumk2TZnF/pg2GM0ZmiswFbJ9x0ztChWvULeLMBmeIdBT?= =?us-ascii?Q?eWU7iN1YVwVBX2ftFgl1lllrJzXMTj2iockcIKXqAYPkM6gZY/v2dqg5a2r9?= =?us-ascii?Q?bwXdGtzaoK7GbNgtdbF9iiNHBQiXPV83c+/jvWcVQhDsfnfBAmC+rvuUvyx5?= =?us-ascii?Q?tUWP735CPWJLQP4ymjv7gQbsBaZxLyNfiRMUFUmyyAZapJgJQdR2q8x77Rut?= =?us-ascii?Q?C/9f39rKSqZ+sLmplcFJrYT1x2ok/2fuh9rCt3uAmmZFmVu8KJugkAN834x9?= =?us-ascii?Q?tryahACdAjyvPmlBF2YFARMEkRjBrzCImALSqMBvpCdnfA7Hk5SYqdkBsC6m?= =?us-ascii?Q?hLQn4dKG0ignswhVD8d841wV+reTet5/BWPhnvrSORvMm7ijhzz4hiJAtodT?= =?us-ascii?Q?oN5O8w8XmVby36UXGVJcdYsjq1FnbTrVlylEZpG6bjhcQDNavmkFJJtuLZS+?= =?us-ascii?Q?uPd5i+QZ5KFn8XSfGSgH2OgcSGAFFuwrK85h0IXlmEb1eCOZPDHFfDi160J9?= =?us-ascii?Q?kYybLyIRyqg4aJCGQb14tVsysEeOi3WTshHa1wDMZI4zU3S+ef69lJTZKtFi?= =?us-ascii?Q?KqWc9v1pnpflykIr52OhdkJW1XMejt5ITq1VpNSlw1TPz+SdG4q2xLct+q4Y?= =?us-ascii?Q?ePYJcv7w3BGyhFM1F7mLRH/6VY5Qo6hJJjvonZ3uJczDdqR8EXKCTJyLQrf7?= =?us-ascii?Q?08UX4FOtHrfUhpgF3Aj8jryLBhMHOmVvlNJoxq4NQIUV+fyurgzbYel0Wp6z?= =?us-ascii?Q?pD17iLcbewlwRjJ794cgnBbWgqRbJaYwceOZkf5FMJTIhA08/mt02xAzdWEF?= =?us-ascii?Q?ZFY8VRe5rvtVWbCUtfgAjhXtlKtFJHYCIBqdACk23gv6emi19TUL7vb/z8sN?= =?us-ascii?Q?JoCHRrvpWi/kG9HgI59yUevmuFB4yJxattYgkH3HgM30h8V+cEc98vVq/vJA?= =?us-ascii?Q?kZDlq3i9T9Ttm4tIeeszbRVw0mQzNqD0/6kzfOQRL8X+a?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1027; 6:gmVuNdo4m1SPfEeq9UvqsaKJdydXUI+kqPDwVpJD?= =?us-ascii?Q?2M5vpg2tAm1f1c98OagNpIvp0p08Rnk4TgJrfFHrGyVFemcP8MUPswhvuPOF?= =?us-ascii?Q?2jjOMKrNZZ1knfLA53bJYGZo1MRCtKB2UdfqSH+GOp67Tovaj1g6wkcYQunp?= =?us-ascii?Q?5u/9c4eV8y3Y9CumurhjxbLR+mRWcyeBWW3P6IbfGYLg7hS92d65QFm8aQWo?= =?us-ascii?Q?EelHogW5ZK5Gqg6tcOb/uplCXTcd0/8+YKKAMLWU3FdkD0E1o4+O0BCDEmcM?= =?us-ascii?Q?sTKMWClL8JoKXk5fOx9Hiu+MOAfcQQLQKwqo6lI/UBgkkbTJeHJ/JSlwfLHu?= =?us-ascii?Q?alPPSLHleDqPCDHI0X5G6qq1J+nnnE00fMQWWCGT5+H4Gle4oLHQY4ClZCbs?= =?us-ascii?Q?QLL03Vvk64qSb9GbuEGXwuHtxagV5O7oy3O+B3VPkfQujBpR9Kfbkf5ngMYt?= =?us-ascii?Q?2r4Im6ZjLhwHZAhOq98FQGYBBixygyCmr9yU8VI8dwQyVU1QT09JZB8Dvh7J?= =?us-ascii?Q?58runYbUVX4iPgbjOLQVvuoGjlErw+Lc/zOng+cjMDKWVzrEvv7J5fTErRAK?= =?us-ascii?Q?jkdH81m4mIYR1OpyRk3+KQKQW53jn1FlJMk/fZQToICc6HnzYrpBx85ynnUO?= =?us-ascii?Q?ZwcMOMzJrTX9m7tbHL4WHLVKdZ4mr5e+aEDC5DOPUWNd0HCfOxRGnz+0neJB?= =?us-ascii?Q?Euf0G5+nYnyj35/FiQmSMRn2uh4glVgMY0ZOUWSfTeVXlSAscCmDbkK6qzT5?= =?us-ascii?Q?krenkbR3S0IKXWnM9Nl2FCqrG6Ftn/PrdeVd4OHVOiY349hHqN++QzXPaAB9?= =?us-ascii?Q?6ZilJi8Le+zwWYWmvnNt2rscDtsYIe669gwHxT9IBv8KvVSl4o1B6GFjN4Mh?= =?us-ascii?Q?RXdy9uTWdHnq/LBmVin3nzeRk5cBzwdBRrLRI7Sx0cmEditj9LC/37yDJNOv?= =?us-ascii?Q?aKsdGBXGIABURFehEHn2wqzrN5MwZp+OmQIdRigZ0vd0AXlsyoOsMQF7qy/G?= =?us-ascii?Q?EtQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 5:oCruqe6Suwk0k7SdIZLVSyxKqHSInfMxweY/AdxBt3/0TsdJMjlkA5uEsURMb35rTTIIVJN3FD6EPnDdVRQRuTaYP+1Pd3Z5ENpYyzVVBpaV0RLcXZ09vBMZa3qDan17J6/dtKgM+T7GV/me4/U3VdgokXHUog5LQUmkl912JHNX1wlV6m4mDHr6+2od5sRb5O//Pp32afr+eqm5myjiHfY+UdR38crqWtN34h65AjX+K3L3zxJDcvblFuer7CWkODqPE7Zc1EhonwYd8Tzvekzmoz3ZsJgoRXifkCHTVigadw0Ltk3hE7I/JZrfgvx4gMS8GKPXwtfKL0akmL5LylKzaJvrFTb5UbwS+Ua1pLAIZXOoeUULkqkHF9nI2OqBlh2xvFSfN/RHbK2yFZm3Gia/pi8NtPyo4TbOOIUQ8AeSpOVGRp2In7rolezH6RUew12GosneH3+6Jg4xpoRe8EDBtV8xXKYxgPxA2wp9U3gPLZeNHnIseyzwTJG5176Q; 24:WRqKzQcepCJWOF6jh8WuMMmqMOp6hEdMCfZSOOl0Vy4mTK5CFH7H66d8exbz9aQne/NlRGG46WBtpZKzysGZm93+FD5M0RtufnA7X/fnrxI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 7:NRtKN+hx6HvBiqTlsriAEqcDavzvqmfVfnsNfGV6vShc+FkFSCPyxaYRP9ueRwAzaMiwXq2A517ANt7HhYnTYvcpg2qv8AUbmG5KiG8AGQYBRL+S3aFpuNJwDmm4+BsDNqpOzOi4rCgH1dqUxFw7956hoH4SpNo2Zq1kewaxfQd//fML5agRwvN1SiNHqge1FUNzxRARQbanlQQG63HsWVfHGlx8Ddec7U/Kyjzr6uUMzA4FDTnA+iMpC/3/KwCxraBnC9GfXWiIg6JDyeyo3H3hn2J6ct9j99fyHLlOsFkMBaBz8LUc9p8tY8swHUMAPNiSBhFa8/DIEEpv8Inq/SIGN5Ugztt5quojeHFAA9bVJiuISBwyA/leLZNv5VgX6i0HMonEg9s3NZtyPG4LVnUU+e5l98B1osgRegSGugm7aWApGUCuweTsTJ20hBiWbCw8bUThrXuA7shR/2HUjOrkHFO+OR/8VOxSufyBRNmn9IVVHIKWaiEM3oTZrcIeZiJNm3ja17wxGd+UUoPOrYLuzeL9yi+llKjhJIZcAi83WSKmsMUa9so36cwmGU3z28tudYaOsIw+W2UOX4GMRcI0LhGVVecJz97zB6V0h3cOcZ/6yrtznlspkHYjmc/rsu0bG6vhGuWSNdBO5iSVR585YHNOtTqjnymkKJ7ndGHQvbm685hZR1RY87TcULX6iI8xT9cmDDouAPsyz78sbaXdTonpTrCD+ktZDFQ1wCq4HCweBcDX2ENAXwWI3yVjlfLnHntjY7sHkKNL8+RYzBR0pjzKYSihC9m0V5EH6hU= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 14:20:33.0145 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1027 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 14:20:38 -0000 On 17 Jul 2017, at 16:15, Yoav Nir wrote: > Obligatory XKCD link: This one is actually more relevant, IMHO: ----------------------------------- Roland Dobbins From nobody Mon Jul 17 07:23:40 2017 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 603D9131BE2 for ; Mon, 17 Jul 2017 07:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 nZBUL4_8mzQB for ; Mon, 17 Jul 2017 07:23:27 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id D6CF8131B5A for ; Mon, 17 Jul 2017 07:23:26 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6HENNR0021460; Mon, 17 Jul 2017 10:23:23 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Dobbins, Roland" CC: IETF TLS Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) Thread-Index: AQHS/vR5lF141oQzb0GeHnUlNx5L9aJYMXgAgAANgICAAAOcAIAABaaAgAABXQCAAAPqgIAAAY+AgAADO4D//8BIAA== Date: Mon, 17 Jul 2017 14:23:22 +0000 Message-ID: <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.0.170702 x-originating-ip: [172.26.150.37] Content-Type: text/plain; charset="utf-8" Content-ID: <03789D065190A74CBC4B021FFB120BBE@ll.mit.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170225 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 14:23:31 -0000 ICAgICAgQW5kIHdoeSBhcmUgeW91IHVuYWJsZSB0byB1bmRlcnN0YW5kIHRoYXQgdGhhdCBpbiB0 aGUgY2FzZSBvZiBhbiBhZGRpdGlvbmFsIGxheWVyIG9mIA0KYXR0YWNrZXItZ2VuZXJhdGVkIGNy eXB0byBuZXN0bGVkIHdpdGhpbiBhIFRMUyB0dW5uZWwsIGFzIHlvdSBwb3NpdGVkLCB0aGF0IHRo ZSBhYmlsaXR5DQp0byBzaW1wbHkgZGV0ZWN0IHRoZSBwcmVzZW5jZSBvZiBzdWNoIGFuIGFkZGl0 aW9uYWwgbGF5ZXIgb2YgdW5leHBlY3RlZCBjcnlwdG8sIGV2ZW4gDQp3aXRob3V0IHRoZSBhYmls aXR5IHRvIGltbWVkaWF0ZWx5IGRlY3J5cHQgaXQsIGhhcyBzdWJzdGFudGlhbCB2YWx1ZSBpbiBh IHNlY3VyaXR5IGNvbnRleHQ/DQoNCkl0IG1heSwgb3IgaXQgbWF5IG5vdCDigJMgZGVwZW5kaW5n IG9uIHRoZSBzb3BoaXN0aWNhdGlvbiBvZiB5b3VyIGFkdmVyc2FyeS4gSXQgaXMgbm90IGdpdmVu IHRoYXQgeW914oCZZCBiZSBhYmxlIHRvIOKAnHNpbXBseSBkZXRlY3QgdGhlIHByZXNlbmNlIG9m IGFuIGFkZGl0aW9uYWwgY3J5cHRvIGxheWVy4oCdLCBwYXJ0aWN1bGFybHkgaWYgbWVhc3VyZXMg YXJlIHRha2VuIHRvIGhpZGUgaXQuDQoNCiAgICAgIEFyZSB5b3UgdW5mYW1pbGlhciB3aXRoIHRo ZSBjb25jZXB0IG9mIHRyYWZmaWMgYW5hbHlzaXMsIGluIHRoZSBjcnlwdG8gc2Vuc2Ugb2YgdGhl IHRlcm0/DQoNClRoZSBzdGFuZGFyZCBkZWZpbml0aW9uIG9mIOKAnHRyYWZmaWMgYW5hbHlzaXPi gJ0gaXMgZGVkdWNpbmcgaW5mb3JtYXRpb24gZnJvbSB0aGUgbWV0YWRhdGEgYW5kIHRoZSBwYXR0 ZXJucyBvZiBjb21tdW5pY2F0aW9ucy4gSXQgZXhwbGljaXRseSBkb2VzIE5PVCByZWx5IG9uIGtu b3dpbmcgdGhlIGNvbnRlbnQgb2YgdGhlIHRyYWZmaWMgKHdoaWNoIGlzIGFzc3VtZWQgdG8gYmUg b3BhcXVlKS4gWW91IG1heSBsZWFybiBtb3JlIGFib3V0IGl0IGhlcmUgaHR0cHM6Ly9lbi53aWtp cGVkaWEub3JnL3dpa2kvVHJhZmZpY19hbmFseXNpcyA6KQ0KDQo= From nobody Mon Jul 17 07:26:05 2017 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 A152C131C06 for ; Mon, 17 Jul 2017 07:26:03 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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-ejNfqKxDo for ; Mon, 17 Jul 2017 07:26:02 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6BF131BFD for ; Mon, 17 Jul 2017 07:26:01 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id b134so49926135wma.0 for ; Mon, 17 Jul 2017 07:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hVQAR7uOkk+xz7wjvp+8sC5qyQmlspxwOxxQ7t8FJfA=; b=gVJx9Nth2fJZNbBAtfl0B44Z+NqULqjlxmAa7SmIFcw4cC7PEf5FhmA1avZjCZWmd1 DdLGonDSAwU1l9sg2NWMBPeZ4mfL29LzGIm91CsjsfDmfuJfpfRW3GlVTBgRztchXOce LKZUbNUdFB/mae5+AfwDTGTkQDqBY4zavjqgDXs50feM/NxxOW6t0f0S9MOclCDJBpzP l6JGsBxqxxwCBtkBliPNXJPkCk+vXmo3M/jRqbdym7ZeHDiC92G8JcZ01kzbrh7DoLmf /nJCccn/KKQLmpxNlogB+R3pRICaAjBilDw6VjCCxM0AEoKATGofeNNNxvbw9q4OlO51 Br7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hVQAR7uOkk+xz7wjvp+8sC5qyQmlspxwOxxQ7t8FJfA=; b=XGoAgLLotEVNMmjSPSWcfOO349vXAbpchLdoNoq/wREXpu+RbX36xnaSVFxQgjOVHu uHWifM9bWZE1asPyKkbnbHwjnQyqEtgnQkJT57mIqUCiOHqh1w8kju6pAe58Ln0GmXLx jiB3lcmRr9TmpmhfIITW7z/6DvW3BbCZGu4LxONLZjPie290G15Q5RmPIHrD+0zvy6Jx eacPl/JbvHVf7THd6MX+qSP+OW9i+9YAJe//fVyc0V8pnVaT7dni3dkwbg0Opw8c5i/v C2DYiKZJI0VAdNtWNt4JCZ2xb8lMF5RiwdPHk3IFJ8azoPPFs3wode6XrwoaJcDH3aKc +XYA== X-Gm-Message-State: AIVw111nAXbNMyaF29nxvpHWzY/EPd740/S0NhekLEpGeX+0weTnvwQt r2p9FenSpGx0bQ== X-Received: by 10.28.113.21 with SMTP id m21mr4546445wmc.80.1500301560392; Mon, 17 Jul 2017 07:26:00 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:4866:e216:9a2c:96a? ([2001:67c:370:128:4866:e216:9a2c:96a]) by smtp.gmail.com with ESMTPSA id 16sm14129005wmk.13.2017.07.17.07.25.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 07:25:59 -0700 (PDT) From: Yoav Nir Message-Id: <9D562446-7125-42EC-893F-CC6530818B9F@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_712E95F7-E8AE-41AF-A845-5B32E646D547"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Jul 2017 16:25:57 +0200 In-Reply-To: Cc: Rich Salz , "tls@ietf.org" To: Roland Dobbins References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> <3847dfbfb9f5497a8aababb665e18ea8@usma1ex-dag1mb1.msg.corp.akamai.com> <79DD9197-1ACF-4133-86CF-C2E121F6B2C2@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 14:26:04 -0000 --Apple-Mail=_712E95F7-E8AE-41AF-A845-5B32E646D547 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 17 Jul 2017, at 16:20, Roland Dobbins wrote: >=20 > On 17 Jul 2017, at 16:15, Yoav Nir wrote: >=20 >> Obligatory XKCD link: >=20 > This one is actually more relevant, IMHO: >=20 > ISTM that this is a great argument *against* allowing the administrators = in the data center to be able to access the plaintext. Yoav --Apple-Mail=_712E95F7-E8AE-41AF-A845-5B32E646D547 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbMj2AAoJELhJCxUKWMyZS5MH/0D1JIHR9Z4ZahD8bQCf0vFX fx8xydXYOkjKQ80Bb5xwYViubFwsdh2chxZv+OvsSESZtbRo/esr+oE82tclKFE5 Mn5GkwSA8+BAafIUbIXOGpGnVT/lBnExjoAVzrxZo8KsCje43HPNI65Z73YbNisT 45II51NEKs1DDwCHjiXF/3WKSUICkP3rPEdTjbONcw5GmLLJD+HsWw0lkPsZxFdn /0x8bLx4Tnj5tFD8CyXBXd3TGkadCcAIUcA12xYNYNu/H9hF3tDkiwgxOK1Gz5vQ AK6q5fnuKr1rO6mg0wfpfS1ICrLZqulMBXEWiFHd4ZmdpbGfssbThziklyZavZ0= =BNq8 -----END PGP SIGNATURE----- --Apple-Mail=_712E95F7-E8AE-41AF-A845-5B32E646D547-- From nobody Mon Jul 17 07:31:05 2017 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 A898E131C17 for ; Mon, 17 Jul 2017 07:30:58 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 81StNve7uMo2 for ; Mon, 17 Jul 2017 07:30:57 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50125131C10 for ; Mon, 17 Jul 2017 07:30:50 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id q4so34337775oif.1 for ; Mon, 17 Jul 2017 07:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=D/g/Hkj9m4L/f3G2y1/RdmNylQ5hxMM/sgQr9xTQOFw=; b=Lzg28Q2u3WynXh42cfKicg2ONOcIqI8HNYKKxcFjkkBbDzHkkaVGXNN26jaaQIzhhO GvkFtbKKgtPYdMJIy8kKtLyI1YUb0foLlP3DV97XWFAAQT4jTWVaRol+7Q61CTf1Mqwc +0g3JaVjMLWBoqg0JRucjWr66k6KgBcuTXHB+6H2WmgULr5R+pNsQaYUk4NEdxDy2v9i Hz1n66Xy0qDvFOk/aaZWLitzVKkVBGplLdsl5c9ipc4N4s5E+l7nLvrKWh1LHLPqUN/q PgDqbv2E1fDnbh8IWnn3dhvIX4EXrTV29VzBD3Qwb74AqafkVJLluKTPPEqtnm2VtYHK mgzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=D/g/Hkj9m4L/f3G2y1/RdmNylQ5hxMM/sgQr9xTQOFw=; b=uP2gRmtR3c7WZB3uuKjhy6vCcWD2ooJXE/Egw/999GrtZFLOPSIc+M7GdQtOU44Fyp G04hMMuLeINMYAKxf3rVIbLA3VSJsmqp8gwWYPiapybmRTFh/SSTVNl9m/imfmDMf8Zv G7ofqkqd+4mSd//+fSvVhLIAu+o9aeNSrZqY9XfsMbGldgnOHp3DbHZhwzD9lFMK8c8E xMJF4hzxW6/lE0DokSqIdCsSC8GqENodV1b69SMUcIXnCDZHdTutMgjpXdHyMb+RlB9x stmX4cZLp6VnOMipV2WK9NzrfhLnqUWx405mIZDIR4CCGwyX6ZE7pb3XHMqLDvO4ywT9 WAHA== X-Gm-Message-State: AIVw1133Y1ywDotYzGaQMTI4Spdw6ZOo4F5FQUtPiuN3nj/1GQYWq9fC +WkeCaxi7/D26FCpQWbKAypUcaTA0g== X-Received: by 10.202.75.84 with SMTP id y81mr522930oia.141.1500301849591; Mon, 17 Jul 2017 07:30:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.5.6 with HTTP; Mon, 17 Jul 2017 07:30:49 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> From: Jeffrey Walton Date: Mon, 17 Jul 2017 10:30:49 -0400 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" Cc: IETF TLS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 14:30:59 -0000 On Mon, Jul 17, 2017 at 10:23 AM, Blumenthal, Uri - 0553 - MITLL wrote: > And why are you unable to understand that that in the case of an ad= ditional layer of > attacker-generated crypto nestled within a TLS tunnel, as you posited, th= at the ability > to simply detect the presence of such an additional layer of unexpected c= rypto, even > without the ability to immediately decrypt it, has substantial value in a= security context? > > It may, or it may not =E2=80=93 depending on the sophistication of your a= dversary. It is not given that you=E2=80=99d be able to =E2=80=9Csimply det= ect the presence of an additional crypto layer=E2=80=9D, particularly if me= asures are taken to hide it. +1. For example, Rule of 2 in Fishbowl encryption: https://en.wikipedia.org/wiki/Multiple_encryption. And since WebCrypto is [mostly] standardized, sometimes it will happen as JavaScript is encryption applied to the protected stream that inadvertently gets TLS encryption applied. Its just a matter of time before it trickles into components like RabbitMQ. Jeff From nobody Mon Jul 17 07:52:35 2017 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 997E0131C3C for ; Mon, 17 Jul 2017 07:52:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cem.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiDzGrD34FWt for ; Mon, 17 Jul 2017 07:52:31 -0700 (PDT) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::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 A5702131C34 for ; Mon, 17 Jul 2017 07:52:31 -0700 (PDT) Received: by mail-ua0-x244.google.com with SMTP id z22so10358177uah.0 for ; Mon, 17 Jul 2017 07:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wQzgErvPN/jNHdqYLPfAUfQ6ZIIhtajbW9qpEAjKpeM=; b=UHTyGG5ya65/E1F8Y75WVwvEcjUMBsO8nO/krP1K3/Yrw0qliBF/rFQPVA3SyGz73y K8pSz1osEYqa0Bpmd5B9tEtLb9z6Fa5dZhrkaUgwhp9d+5d3t6W6LzSYpknwhRQRd/0T 7bhMziJc4T52hvosClrh7uFsW9GeQM6LOfs+Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wQzgErvPN/jNHdqYLPfAUfQ6ZIIhtajbW9qpEAjKpeM=; b=C5A6hj2P75ETLw4Jmg6yMVa1f/qQ7it1pNRuHS2RN88g69wUny9LKvvR2MyZOtxko+ PRYLvoHQdcscEzeHUiFOkoCc8tdk4X4gChczJNdfUvChIbnlPnPErZwiefOy6/WUC085 m9ged08L7xqBqTEEESy/4MZOatIC79zNXjtzO4sY7A7xS5YQ8bL+KDK55R2nZMW/D0a6 efdMupgFTcUR4HCNFKIbklFbSWWgDAMSlCr8SKDvflaOgDLIxNaX9fBIFt4xx9du13nl e4VECGOUDIc4WLkDnQTKDqSPff3LBFIC3wF17GJ2FOzuQPEaW1waKNVF7jfjLHriBerE /PvQ== X-Gm-Message-State: AIVw113Dr6oGpcwGTZZagKBYOqAzlS+lHqeX9lRaJzbFtzVH6NVAbBtg imt6G4A2PvZg7uGIQJw5KjI1IXIwRrgv X-Received: by 10.159.60.75 with SMTP id w11mr13262903uah.143.1500303150498; Mon, 17 Jul 2017 07:52:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.174 with HTTP; Mon, 17 Jul 2017 07:52:29 -0700 (PDT) X-Originating-IP: [172.8.175.41] In-Reply-To: References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> From: Carl Mehner Date: Mon, 17 Jul 2017 09:52:29 -0500 Message-ID: To: "Dobbins, Roland" Cc: Russ Housley , IETF TLS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 14:52:34 -0000 On Mon, Jul 17, 2017 at 9:11 AM, Dobbins, Roland wrote= : > > > On Jul 17, 2017, at 15:59, Carl Mehner wrote: > > the only way that this draft would help you > with malware analyzing) > > > This statement is factually incorrect. It=E2=80=99s not the only way, as= I've just > explained. Ok, sure, sorry for being imprecise. it's the only way that would help you if you were trying to use this draft. If you're not using this draft, then why are we talking about malware here? Do you have an example of where malware would be on your intranet where using this draft would help you? > Again, why are you trying to pretend that the use of this technique is no= t > prevalent nor important in the security context, when it is in fact quite > prevalent & important, & has been for many years? First, I was not the person you asked this to the first time, unless you were asking the list, if you were I think there has been a considerable effort to try and understand. Second, now that you have asked me... I have, that's why i'm asking questions, (that you haven't answered) Thirdly, just because something is prevalent and important and has been used for many years, doesn't mean that it should continue. Looking at HTTP-only traffic for debugging was prevalent and sometimes was even considered "OK" because, "we're in an intranet, not going over the Internet", now we understand that it is not longer acceptable to use plaintext traffic. Because of that tools changed, network designs changed. A similar thing is happening now. Non-FS was ok, because it's "intranet", now, it is not tools and designs will have to change. (And since we are throwing around PCI hypotheticals.. maybe PCI will mandate forward secrecy without static keys because it's more secure.. we just don't know.) The bar, as Steven pointed out earlier, is for you to prove. You should be proving that it is necessary, not just that it is prevalent or easier. > And why are you unable to understand that that in the case of an addition= al > layer of attacker-generated crypto nestled within a TLS tunnel, as you > posited, that the ability to simply detect the presence of such an > additional layer of unexpected crypto, even without the ability to > immediately decrypt it, has substantial value in a security context? I didn't say that I didn't understand that knowing nested crypto was occurring was beneficial. I do. I agree it is beneficial. I'm trying to get you to explain how this draft helps with that. > Are you unfamiliar with the concept of traffic analysis, in the crypto se= nse > of the term? I recently analyzed some malware that was sending encrypted traffic back and forth nested inside TLS. But we didn't need to open up the TLS stream to know that it was malware. Also, this draft did not apply to that strain of malware, it wouldn't have even helped determine that the crypto was doubled. From nobody Mon Jul 17 08:04:17 2017 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 6A263131C34 for ; Mon, 17 Jul 2017 08:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 3saHEP_9Gwf6 for ; Mon, 17 Jul 2017 08:04:15 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0111.outbound.protection.outlook.com [104.47.34.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30AB130019 for ; Mon, 17 Jul 2017 08:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LRkouCJqDGYMEcFGoasZSDNRB44JeFt+ew5UblgcjgU=; b=nYLKNL3dgiQW9V1RAcAShc7D8Gzv3HbzZ9WkRo4TROKGQ56oNJzyVWUzTqpu7q7b6fa+XDF1bLWSsn6jYopDF1gnfSy3xLVzXEjsoJXtynyb/p044OvSGL437PQtm6VyRGkTmQ1knisnbgq/RtzWZIqdchjlJUSgopBcxvtccPY= Authentication-Results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by BY1PR0101MB1029.prod.exchangelabs.com (10.160.199.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 15:04:13 +0000 From: "Roland Dobbins" To: "Blumenthal, Uri - 0553 - MITLL" Cc: "tls@ietf.org" Date: Mon, 17 Jul 2017 17:04:02 +0200 Message-ID: In-Reply-To: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> <057af2f23acc450a9b896f9f0c81b06d@usma1ex-dag1mb1.msg.corp.akamai.com> <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: DB6P190CA0002.EURP190.PROD.OUTLOOK.COM (10.175.240.15) To BY1PR0101MB1029.prod.exchangelabs.com (10.160.199.154) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 15433b10-a827-42f7-7fc3-08d4cd25166c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY1PR0101MB1029; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 3:Gby7eI02N4iu0I0poUS38OVufx8Z78AGr/kNwLGlFVeLBzMAX9ZPCBjdab1mHinKN241N6pHIGAQ65x6Dvb1Al4wVz5YTYwWd8VhNHtkc/4EBVzDo6bTYZjTkcK8iiaaqZKac8OrcrH/mp1XeR+t51/NGPRZH0S3+6NdnXH+w1JOX2vszefakOj92tLghdtITwkzJn5hn+vI8G6DCEmf2cxOqOYKh7xPJPsKIlSEuX8LbMC8LT/oL8HwS8tO3Waj4AvncPAkaqzqr3mVuoUrH9SMyPCWns+ed617yS4USZSeGD5fs3q9e4ebdBfCHx9A+Igo6DSYDNaSyJP0yXyqa7YFC+GgVmXGB7gXFnvj5a+Qe0o4+QxvT6ITjtBJV+ZrKF4lJ4revcK9PtMOBByA4v95E2Df38ad+uCc/nhmneI0SZpWJhdkfzxYO3aN9Vjjnv3YYYqdjmxRm8fvEb8n37LKgmTQei9YFt/zGRb+EZJUSEBUH9iGzslICK4bawFBfB+Wk5Cg27iTe6Hi7MKbILwYCyozk58v2/f3OWxIiBYpy51w+2Hn+1MsxWTjc5/GO6nbzhK/jmp0e7lrCWwfs1bSk3KyUign1v5auRqxDUrEONgb2T8zpK34IYjEy6V2DxS6e0AIvfYkTqhLVR4PQ18bhn8gw+eAYdrS0puxpxfv095W420EGeer6GQDXyuYGsyxxDe+L6zNvxWEfvEMDTSVAnqNJWQfDV8yG1CeU7c= X-MS-TrafficTypeDiagnostic: BY1PR0101MB1029: X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 25:FoFa79pOSSMz6+KLruMmUUTVby00u0YKdMfeymt59W+q89A3+kjPhwpKMxE9kPXkkyUrOyarRgVT4CPz4vST9PFPwgo+XygjCPjqHC/UwmbPvQ5fx/KvWDIr3L0zf3/BJRqKwGZsOVxnm6O7TWNVnSHKTjidnCm+vCagQcrpI4k2hQ4jOccDOCagknRHpJPZEV2OwuXZip6ohcMQHp5ecg9kWIVa6254FqjzBDkL+dF0OEqsPVrw2Xi6Ztpq7yd9W1YubW1DIE18qqMnEpVDfIFmpJht9bOg0ziqDW5NIq8TCkGvwVG+WA6PmWMSYQVXr+FgIvT0iG1Kkxd62Idk6A6ywyf5BnwVWBsoMByo3nL/wkupQOAuZkAwM5EF10Q/XZ5znuDeK1wuDSs1VQu3W8tM4ugwJCwwjnmqntvAqgtZnJ1vagSMg+ukoqyqnCS4SGB0ARc4R6Zyp8hGEQHlsGKHZM59fzr6K1N5kthro65T6TUsyzeL874Cj0Vtt8u1IJ4Bb79BBt6xJuHEQjBqFuQf4n1t9PkXYDU8t6gDZat2HK8SsfLOBfjMUr5a/R7kg03X7EFWfJCkxMnZrbcgHy8931MwK+LyXJRVFPyIpbEvCchBB89znoVEUTz9gR5Iw8xhdzGnh7Xggy7dJuvzKDpvecqMf4eRa3FOJBBy5pjp4RHelOngAaINqF12JTzQPi/Qaa2iXVF1Tu4rLkbsAzxvbi9NhF+YxJTrQs8clLhEn0REBxrnba/iNlEj3yKw0zi74v40FErpUgr8A0YrDGqkd4BVEp+BVJAXyf92zaPiUJajRlbp5UakVmg/HUSjk85dDJGzQgkJfJIu5qDbHUEfCvV221GjaiW68QzZYUojmjLvGvmLun6If6aRhTUmru3VxBwkVi+RwiWZIsSjgZDBiM9Kx7ZrLVlUjSNBmlQ= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 31:bvamb3+Xv6kgiBIS/Qr/39ZpItO0WPOkIUVoihbNOCfHOWDu1Tzz5ZQWHFrbEJZL5BBHkpQhwBZBwbwNPCivOj37hLIPlgEweZZpSuO89W3jlKkX9wMT5O4adtiQ728Bm7ebIRfQDeEqHpCDZ3X3BxSQlXLmI15Umhzp1E4pIXJK6dCNWvoQ5ZpBsMqu4IdDUN4UpHJ9kuekWeuMmRQUCVL1Q9W/ZXxA476rW+Boev2XyWtjg1+6c3tZobLf5jVppUzozS21XQ067FFRbwhF3oB0f0MDqLJzrTwU9CoqjhvmceqQuLax9r/u6baeBuRpYxTW68uwJc343XzT2VB4hVN1cg2FvvER+B//c7WUMOPGD1oi2EbTVsoyPGepsawHSbnPfkN69ChST0J5KUl6XVLuEis9HpX3gOeQZP6L6Gx4ZyoWUntA+N77PVts3lgC/iGksgn25JfX6oLms+DdT/LxDbmDwbshFY2MXUUQiIqQFPIBqimzL3fagBFipSEx3WWycHcJ3/18J3ISeAg2nivtCASlKYFLeyWEUlzFHTPDhDHpd8ryRVb8PjwjDdXX+9DG03xyalw8ZxAtWaargDtShS0DWqn1aezppz2SjtzoTHj+H48wJv4meSVnyx9mbXgYaHfdPjsIMUG/jpTl/4QR/TW7wipeTSpG/xTXv5Z9LSyNgWgP6iRg9kZn5oesnhCcxEibh4fHvSoi09l5YVNHgTnzsKrDGJkDZtBiof0= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 20:4nJy52lsHJj/vuoTY+qNYKZSmqgMvQjF0knUZiH2bbQ2m0L8nr/ONaj+0/cuC/LgD3C7RvyL95nhhIpVQ/NQhLkoieM2cect7fsX8AbjvBIc5mbQ2ZUr9yzEE1BHGILr1yLpIf/E+cMv19UlWoNc0lCxTePiSXCMH5ZHMu+zR+QLLXx9gBlHxmUhKFWFCp3ts2Sm7WlAqELkDaXVDvzoY+WqPWkm+Hqu3m311RUzyIaQ6Te9uvKeLb0kVqtFRDeHjBA6IIZ5iTsqWvAfVsRY6nxMRjo3YdWwR4lLru+wc2VNUv18WuYd7bW533dBcUuB3jyxGfg1Cjnw+zLCVmbIXm2073nA8IH8R9ggdvJ8vaMdnI5pjLtsdxt+lQvUOWcaIfOnIni+pRuGxndI/Xtpq0jZW4QRCV73SQ+Un80KrJcUl9fVaRq5nlaJdJpAMP6hCbw+tj/8ZKqW6TSniuK8wT9j5mHxcUD/s5rGE2APoKiukMhWrBNchI0paKaV+3CQ X-Exchange-Antispam-Report-Test: UriScan:(246478575198768)(236129657087228)(192374486261705)(48057245064654)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0101MB1029; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0101MB1029; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTFQUjAxMDFNQjEwMjk7NDprMGdJWHdxOTlVYTZhTWJlcDk0VG9JcXVl?= =?utf-8?B?Qit4SGZPNWVOMTZrNzZ4T240R2N3YUpDYzRKbDNyRzJtbndONFVtdXRLR3ZN?= =?utf-8?B?dG13M254Z2lLcVBESlBUTGtNcnZRcmNPcW9xUWZKeTBndnRhcFU2OXpHWS9a?= =?utf-8?B?UUZYSVBkVlMrWHNXTC9hWVhWRXRLNlVjYmFaejN5NnFPZkkzRVR3TnUvQ1VF?= =?utf-8?B?Vi8rWmp3RjdwT2duWklCd0hOc1cvbnRoSFRDYnU3WWdDWlVGZTkrWEcvQkti?= =?utf-8?B?VGdmZHgxUlo2UzgwdytjN2dnd3RYMTU5K3Nna0hkQUJqZWlNK291K1JCa01E?= =?utf-8?B?RlRzSjRGdVRpaGd1RmxVeVVZaU5md29kNGNEZE5vWXBqZm1sZnpESEg5NFBm?= =?utf-8?B?cW9vUjRybzJUaFpYb3ZqaVN1M09hcVFZTjMzeGQ5WUJDS2lkWVU1dmJnK3Ny?= =?utf-8?B?YkdvdVc3bEc2SCtPTkFtaEhGRXBOVldMaCtoZUIxTzV2dW04T2FWOVRFd3Vn?= =?utf-8?B?djFqNllKNGZWOXhzMk5WcGtHSzhPcVo4YjdMRVllaGVMSG9SbnJGUGo2TDRT?= =?utf-8?B?U0RsTmlsZ282WFFKeEc3aHVSWFZwMHVuVUlUZ2tFTnAyS0NOcng0R3B6NmIy?= =?utf-8?B?eTBvdzNtK3VwQ250eDRhYlM4d3ZxcDFyWmplZ0Z1eFdGbExsSDdvNzNGM1FZ?= =?utf-8?B?dStEUFJ5aWZpbHVmK0didG5RVjZUQmpDSlAzL1FtdWJKcTVwMGFtNW8zbURy?= =?utf-8?B?bFVkSG5PVjZ2M2VJempTcHNsenVoWmdYbGZhcmxiT01UYW1Bem91MFp5MzFX?= =?utf-8?B?QlllU21JV0o3L0krMklORUh0WDUzN3VMa1dhMlVXeXRGMzJHTFdXbHNoMzgr?= =?utf-8?B?cytxaVlLOFRDL3dlVGFHMTVJRnBYZlFrR0hCQlMxSklQK1lQSTc3Y1RvbzhI?= =?utf-8?B?ZDVCQzdIWnhYb2h5SWxKaTU4K0lTR1BTWWRQdS84SlY0VVM0eThrM2VOMHVr?= =?utf-8?B?YmpJelpOa0JLcWJkZnF1eDE5YnlGNnJNRnhkNWNqclhrbUo0YXFTcXYrRmZK?= =?utf-8?B?M1Z1MWErdlp5bm9rcUZxb1RIWG1US1cxNHFYbGROczFXUG5Ga21OS2xITFlz?= =?utf-8?B?VmxOYzc4bnpFZkhGNGp5eDVlR2xhY1lrbjd5MWduTUlMYU9WN0JpL0ZZN2I3?= =?utf-8?B?U24zWmV5WE16NTdHNmZ4S0lUN0xhdzlCZmtvMVFQak10ZVkydTdEcUIwc3dI?= =?utf-8?B?SGtBTENEelpGSy9hVDdlZnJTZWZ3V0hhL3N4dzIxQUl4QW1YM1VoVEFRL0ZL?= =?utf-8?B?b1pBY2FSRHFTQTQxc1RvT09BSnBwSUJEWUMyb1lDZEdnZ0I0cUtvUXpPSWly?= =?utf-8?B?cUFEbllQbC8raTdkMTJtWkdjbGFqcWVHMWMxYVpzTnIvcWYzNHhoMVFFNlFH?= =?utf-8?B?QTNNN3pJY1k5WE82d2RlYi9HbTBWN2RGZEMyZlArbW9EcUd6dVNvemhsY2xH?= =?utf-8?B?VHYxNVNzZFZPSEpOQnpJTUR6MWtETmxmSDBSckRVUzdTWWhaTVpta1JQREZO?= =?utf-8?B?OHBPY0I3L2hvcWRzckNwWUN0NVI5MTJ0RHk1U0Z2eW5UTlAxbU1RRGNwWjFF?= =?utf-8?B?dzFQaWpQZDdGWGtDQ3MrazZQdWNvcGF6TDQrREJnRmR6dERBdUZrZGJ3Mmlw?= =?utf-8?B?cTUzOTJxMG0ydVNURzY3VlJtRDNKTWhkamNhaUhYYnd3eDhPSzVNeWZxakFa?= =?utf-8?B?SnJiNWh1UWdseTJZMUZKeWtOWHluWnJMUmV3YTNDaFJNVDEzYk9xRHoxR29W?= =?utf-8?B?RWZlZW9lQ2dwcDRsVHpua0diVkMramg2Skw2bGhuUERJWE1BPT0=?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39840400002)(39850400002)(39410400002)(39450400003)(39400400002)(24454002)(47776003)(561944003)(7736002)(230783001)(189998001)(33656002)(76176999)(305945005)(50986999)(66066001)(2906002)(4326008)(8676002)(23676002)(90366009)(50466002)(50226002)(53936002)(110136004)(38730400002)(6246003)(2171002)(81166006)(42186005)(93886004)(36756003)(229853002)(6116002)(82746002)(3846002)(2870700001)(5660300001)(7350300001)(6486002)(25786009)(83716003)(77096006)(2950100002)(478600001)(6916009)(53546010)(6666003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0101MB1029; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTFQUjAxMDFNQjEwMjk7MjM6cTBxdWJzN1pudUtyZ1RrbnRmODE5ejNJ?= =?utf-8?B?NG41NkRlaVFCZm5MMG5CVDN2Zzhxb3hodks4WW9QV0xOOXVBbXBNWGsyMUVx?= =?utf-8?B?dXpoZWx0c0ZadDVEMnl5bjA4NGp1MmJJRWtJcEFnd1ZSTlJMcFFHc1UvNGZ3?= =?utf-8?B?UnF5L0lHeXRpZE9JK2FpVTFkb2VGYWVydXBVY0wvMmJDN3d2SmI2QzJjT1lO?= =?utf-8?B?aFpLa0h5M0Zyd044U2ZHK2NNclZTVE5ZMWMwdGRKUE5mZlFTRFQ5R3ZLZzAx?= =?utf-8?B?N1VuVFZxcWU3OTN6RnRvUVlvUExLVkkwL3c2VG05cm14RU10aTYrODVrM01D?= =?utf-8?B?Y2VaYmZEVmVjRFdxamRtellSdWpnMi9oUDd2Q214UjMyaUdHU3dBMEFINDJl?= =?utf-8?B?RmtQQi9lMWRmMEw4aFluZytJM0ZTWDRUOEJ4SFBnZVF6MFBxRTNHSksrcWpE?= =?utf-8?B?ZWxiSlRYZ3JoTThERFVQRXFRVmEzems5aHcvU3BKSS9NUWpobzdzRWtYODBY?= =?utf-8?B?blpDcENacUJaemgvQzBYM3B2U0E4eHBTK2JBTHpRUkM3cUJlQmV2akZJck8r?= =?utf-8?B?OEN2VytJK0VQR09YMXJlcjJwbEdURXdYeHo5WGkzbXpJNFFJYTVLQnlRaWlq?= =?utf-8?B?TjcxRjFNQ1V4dVBlYjc1bGdKQ210RnFrVnU0anMxK01GVUVpbFVuQkVBQXpL?= =?utf-8?B?aTQ1ajE3Z3gydWN5SFhsVHJRNjNXMFgvWVc2UHFXNzRrUzl3Z3QyK1lkc05F?= =?utf-8?B?TENIaCtPZkxQdHJ4aU1icHhqVWsrOHZWQkpETWovOEd2ZzJIY1ZnQnB2NnEx?= =?utf-8?B?eklBejYyVWtVTDFkY0dJeTNzOWdxY0xRVEQxdmFiejRyMjdxeU5wQTVWZnlU?= =?utf-8?B?M3NGK1pzWUliRDdoM2FkajhYcUhOVmJNMkFiMHo4OG91ZkRiQUd2V1o5Z2ZM?= =?utf-8?B?R0E3SFYzc09TS0Q1dlQ1cTg3UEVDWGhGaStsNjFWRTRwZEdzMUtDN2dqVmwx?= =?utf-8?B?d015QWVXTGJFZ05kYi9YQ1NKTXRQU0lHTEIvNDBCY002dTdXL0FReFQyWk82?= =?utf-8?B?SmNzTmVFc25WZDBodjNnRHVSV3hkTGlldUZFS1c4UXZ6cjVNTFNmT1NXUlU4?= =?utf-8?B?V01rTVR6Wjg2N3V2b3NpTjNycG93UFd1S2ttMXE2NktUZHNoNVNXaHc3UDdZ?= =?utf-8?B?Yk9LekVOYWZZTjdYSjhjT1IyemlYTVFnR0xVbTUyMmpQdE1vQjVhajR0Zldn?= =?utf-8?B?TSszZnJ0L1M1OXF3TkpRdjZ5RVZVNU05TlM1RW5TYk1US2hMMkNsVW5ScUpx?= =?utf-8?B?dDR6WFFoWGEzcEZuMHZpT2t5MXB0YlhJYnhXZWxxQUNRWUFrNDM1ZWFoWVZI?= =?utf-8?B?N1VFcmNLQ2ZMb0xmYlJKL3FqSnZDR256cGdZR09tSkk4OGxvZlJFS3I4T25p?= =?utf-8?B?aTBjM0FBekY4QTJabnY2bVdzQXh4UldYOTVnYXNhOE0wMEt3UFhEU29pQkhM?= =?utf-8?B?bUhLdk9hQTNJem5EMk53WXFyOVRNTGdnRDZuVFB5Sk5BdGV0UmQzbFNpd2hh?= =?utf-8?B?bFdtYVlZR1FtelVzVU9sOGZYTXEzL2VBeG50ZWZTcCt4aE4xQXpURWZSRUNG?= =?utf-8?B?VGVoMEdndUloVjAzNFVNT3ZWSm1FbmZubGxzalNMa1phRnZSU3hJOUxsMDF4?= =?utf-8?B?UWhCZnVkR2tWbmpEUnRsOGVlTkdtRERFcFVUdHFjUktqa2tDWFJvSUJwenVo?= =?utf-8?Q?gs7L+wdylGDB+YCcSAJtSHbZ7EZHn/23mUM83Zw=3D?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTFQUjAxMDFNQjEwMjk7NjpNaWhESVZnY2pCSU9Nc2ZZWm5WY1FtR0lk?= =?utf-8?B?eTMyd293N1ptblVtTmdhZ2RrRVhwZ1ErckQ0eWthT3BMd3VMUWtNVitnaXln?= =?utf-8?B?bGZiZVU3NkYreE5PQU43OVNoZTJ3YjJXYWNaNlR6RkpEcWdHRWo5czRuRVht?= =?utf-8?B?NVpZZ3RDUVVFcS9uZ29zVkZFSEx5UGNtczcrQmtlby9lWmx5SWp6OGVmRXA0?= =?utf-8?B?a2tjdXhiYWl6VEE4QzF3MkdXWUxjaStROFlwcGsrMTJacDhuaWhQNmJ3YUcy?= =?utf-8?B?anpYdjVkZWJmUUhzbmhQOFJ1YjMzWXFtVFdVa3F2bnF6ZVZKYysvZGpDNmR5?= =?utf-8?B?SzhhQjlTVHYxSFhSRlZ5MkVFZUJKd2F5L0NjaHByWEQzWFFlTDJxczJ4ZUZR?= =?utf-8?B?clRRTEJjZDZZc2tJeUxseGF5OHNqU0F3ZVc0ZjEyc1NoTHVCM2dsODBVSDNj?= =?utf-8?B?THZ5b0s4TTZDWW1kQ3hwRCtlbGxsUFI2enEyd3dQN0dEdnVYQnN0UE5IQ2ZM?= =?utf-8?B?U1Q4TVJONDJmTzcrdmphUjM2VGNGQVpEOTh3cWpiYzJEblBsV2RiaW1yVWYr?= =?utf-8?B?emJSODNzTXVqOFQwOGFXQ0dWOURIWGoyRS9nZ3B2TFN3dWZ2Y0JSK3lIeXh6?= =?utf-8?B?Z0w4bmhFbW1ZL3c4cG0vWW9zSmhXMzF5TTh5SUk5RldheVZVSHRTOTE0OXps?= =?utf-8?B?NDFHdlBTVkw2dzhJSnpTOTQxd0FHQzk0bnBVWU1Rd1RRNGNJWlMzY0hqNmZp?= =?utf-8?B?YXEzZkFuUDU3a1A3RHNLaU5OeHpvbktCbzUza1kxL0hENU9CZmgvTUloRTFX?= =?utf-8?B?YzRVdlg0ZmY2RjRaWnQ5ZjAvSUUvMm1DTzBtMXhzS3NCUi9KSUxKTTRhakt1?= =?utf-8?B?czg3c2dWNFhkYjdHdHBTdGd3R0lFSlNPS0NIRlQ4V1g3b3pHaXpaQUJ5ZTlP?= =?utf-8?B?eE1YZytUemVELzZDbUhpcFp0SGhKaE01VHJPclEwZnV4c3ZyOGhBcTZHb2xa?= =?utf-8?B?S0tYM1ppS3dSa3hheVBnRDFiY1FZYkJWMEFyeTBVQ3ArU25zMW51V0tjTWgv?= =?utf-8?B?S0s5QTl5WGpTT243NGFuR0RXYkthbHhxMy9rSUhqYmNKeWNGczFjUkJVbFpl?= =?utf-8?B?bWhXdVVhczFEYXdYaDh4WkFoQVJHLzBNc29jeWxiWno1bEhXZWJzYm15Z3g3?= =?utf-8?B?OEtVLzN4WTEvaHdGMmdOcGs4aWR0L2hOeGxYbEZ0MVFUeEV0WFYyVGpFZ21p?= =?utf-8?B?ejBqMDRib0dGYlJKN1dOcHBxYmMzU29RN2Jvd3ExbDI2RE5UUVovOEpDeWk4?= =?utf-8?Q?iP9FoEd0YiucFfcAkJ6VWu81RCr8o3oHE=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 5:flUiQ05PhAQ2dUH26rMNA3V2PTbu6Z3eejaDhhp5c39670/JKGT3eDQ2MNJYoFdI7J4X015zefqR4UpgtAJiMp35ezpOMJ6TFhFQufZxNXLrDPCXOgnyUFEav9ItejfFCG5ngVh+a1YMrfUKC366I4T2aZaO6apDW1MeeNNu7WEUA3VPnrBaWLxWh8Z7HPTUmyAE5d1c51fMFuNu20syfsxclwFeMyXCiHA4E0CAgBAtWCRW874pWIWoIxqWB+OwhlScSqJKBvbpZvyWUVWuTcJIZWpW9BZLO1iSMvn+0/GRzLv3UaOK9v3cUSLvKeb7lE75+oTQrKeiKf72SjP8dGjFK1j8NVTZlc3SagnAq9xkJ2wEobzeJDLhzdrDGHkUCSqt0zgjq0kA3+nLExL3MoepiEyevqhp7enwAs8Hykx3hglim3LhEAbaGN7XJEFHAvB9LiUGGE8F9VLFyd3+UzKhBcE/R0boIubXuCjRpKyyOtVe64HjJY+ijWF4/ble; 24:N+b16UVEw8i30WF0HhwHlPLjnF7DEZ7SQwLzdg0/Myw74UqQUuTnQlD3icYOLNWyaZ5s26hB4mGCLzXXLrEPtN/SrQxyCYtf13Ny1t9nA88= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 7:5vHdl6mhroHkd9PLeFeGnwg9r9RMoghAKMXZ7k9ng6VzoU55KBYNTUYKpDZBLbPb45BcsD1b3MnVtsj5CrjsgrrJlyw0YIjQQlmDzjEtblT7y9mWTrcBjrs0mimaTTrKV555wmAP275nBZAMlCk9Dwfzctxx605L9o0o+yxzj0JfoS1DWBfgyS/g+WU/a9Oeuy3f+A9H3gbvqNHd8PElqiFN+t6ohxxNcfXhZ+713qTyYWiAFHBv1WU3FeGl7tfPUdIXl71bbwODbYSsWbtNRw+9O3SBkPyRiBesuLyi0ZWtPu5M8Zf/SZgXZp2UD86q61NsjfnXb6vAmc1Sf6d1U8TQaNUuqce4gB3tQzb6zavCe5Mt6AsT92tknBCdMyM8TOUHqiuDIMcXa4v/FPb0GZwpAvD3T59iC3D7f9Yv7t9gWsfijhWn71oEXNx0fkHpDDd2JLRHsuf5uMbq2s7CWeRL6lcdkIakfxXrJ69DsPf4Vbig149DsCAP+JtEYDMswHlYQD8eSaTU0pHpQIJYtrYVni+23NOjOh6lmEtRfL8ZfmqRdo43VXfxsx69DzTomYTzO4omZaNqdfLvWkSdFykFHRmkL/jskbF7xETpGlNRetff+fEZz/IamJAgiW54sLXQ5NF2cO/wHwoMSWS87tOSLxuXm7BDIdgslv9Pv/NDq8xdO3HRu4a39v8n7KeV1s5ysw+bVV/hwfGvOPMFCo5WmhqFeZeRp6K4qY4tQpON0QPOuvZ6MOjY2V/aZNjR1y4f+UM4hgTkyXwlGhx4wXAuzjBggf+I4vStHJ7/bt4= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 15:04:13.2630 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0101MB1029 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 15:04:16 -0000 On 17 Jul 2017, at 16:04, Blumenthal, Uri - 0553 - MITLL wrote: > “But we (the (network) authorities) are the good guys, and we need > to break the guarantees TLS provides so we can catch criminals – and > here is how we propose to break TLS-1.3â€. The actual concern of intranet operators is the inadvertent breakage of an important mechanism used for troubleshooting and security in the context of TLS-encrypted traffic on their own networks, within their own span of administrative control. > Considering that unless at least one of the end-points chooses to > comply with the “rules†it will not work – the claim that this > measure is to help the good guys does not sound very candid. To clarify, this technique is for use on intranets, within a single span of administrative control. > Who is the intended target of this mechanism? What kind of criminals > is it supposed to catch/detect? Surely not the malware that penetrated > your infrastructure and tries to “call homeâ€? Actually, it's been used for this very purpose, quite successfully, for many years. It's also used to detect and classify lateral movement and propagation of malware and attacks within an intranet. And it's used to detect and prevent malware downloads by intranet user populations. > The proponents of the “broken TLS†somehow expect that those > criminals would use weakened crypto for the convenience of the ntwork > police. How much sense does this make? In most cases, the attackers don't use any additional crypto at all. When they do, it's most often poor crypto. > Experience shows that criminals use not just cutting edge – bleeding > edge crypto. You're absolutely correct that a few do - as you note, Conficker is a good example of that. > Plus, there are many ways to foil this proposed mechanism – for > example, super-encrypting the data before transmission. Sure. But the ability to infer the presence of superencryption is extremely valuable in and of itself. > Then there’s an issue of the abuses. First, not all of the > “legitimate†authorities are “good guys†(all the time :). > Second, I’m not aware of any “network security†tool that > hasn’t been subverted at some point in time. Again, to clarify, this mechanism for use on intranets within a single span of administrative control. Like you, I would work to dissuade anyone from using it across the public Internet. > The likely result of the “static-dh-…†proposal is improved mass > surveillance by authorities, and exploits of this mechanism by the > organized crime. Let's remember that this technique is in use on intranets around the world, and that's the focus, here. > To those who need that surveillance: stay with TLS-1.2. Unfortunately, this isn't possible due to regulatory oversight and plain old bit-rot. > Either you have PFS and the bad guys will benefit from it too (so you > need to detect and fight them using other methods), or only the bad > guys have PFS and you might [0] detect them because their > “protection quality†stands out amidst the ocean of the > automatically-inspected & censored traffic. The ability to infer superencryption is quite important, per the above. > Because there are well-known ways of hiding the presence of > encryption, at the cost of increase of the ciphertext size. We should also keep in mind that are also ways to counter-detect these obfuscation techniques, too. > The hope that the encrypted traffic would stand out is unfounded. Actually, it does stand out, in many cases. > Considering how fast the attack sophistication is evolving, the > likelihood that “they†would employ other countermeasures, but > ignore this one is fairly low. This technique certainly isn't a universal panacea, as you rightly point out. But it's an extremely valuable and important technique that's been in broad use for quite some time, so maintaining a mechanism for intranet operators to analyze TLS-encrypted traffic within their own spans of administrative control is important and worthwhile, IMHO. We don't want to inadvertently drive them into using proprietary, non-auditable crypto. That would be bad for everyone. ----------------------------------- Roland Dobbins From nobody Mon Jul 17 08:05:16 2017 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 9D19A131C62 for ; Mon, 17 Jul 2017 08:05:10 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 Ba_jio53qupA for ; Mon, 17 Jul 2017 08:05:08 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0136.outbound.protection.outlook.com [104.47.32.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8013131C43 for ; Mon, 17 Jul 2017 08:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fOnM3vAUYD8gWewS4Rxapl62Xf3PZw06SiWFe4JBMDQ=; b=er0Klk11GkFmZdKukb3WwobSg9RPf0wDelXV9YnXPWmUbssMdJ8fWSvZVO5FL/tvomr5Pdn9aXUI+xaOVM9tv6Wr/91ZgshpGcphi3GUDdTbvCjJNnZIdzYbiRZs2l7JE+4ww+N2u2yrCxK4EwHsgiySzgQE+uIDLGb/ua8DW6w= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by BN3PR0101MB1025.prod.exchangelabs.com (10.160.182.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 15:05:04 +0000 From: "Roland Dobbins" To: "Kathleen Moriarty" Cc: "Salz, Rich" , "tls@ietf.org" , "Matthew Green" Date: Mon, 17 Jul 2017 17:04:53 +0200 Message-ID: <4F7D0238-D6AB-4A56-9036-3DB2C8576C6A@arbor.net> In-Reply-To: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Content-Type: text/plain X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: DB6PR0601CA0020.eurprd06.prod.outlook.com (10.168.88.158) To BN3PR0101MB1025.prod.exchangelabs.com (10.160.182.154) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: da913456-fd8d-4b57-ce97-08d4cd253539 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0101MB1025; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 3:ZtP7TGvPy8vVy6OUz36eqqDcGKY9jy9xDLat04lKfDddnJsrESWG2OD4zX3JnwKoZtc5b++jSVb7eF4nXP6ARMdGLFzw4KIY4S/xbkzxDsjK6f6AkxWFyMLR1+FC/VoUXOeYFNhqapqep9bab38zEL5pGmGVZNuYc36hEtmuhwlTp0PZ7klDRkmccSMT2CFwMIVPj6hlaOWR6uijscgHWYLzBRw5E/zkxcBVZQaJi0ZeBceVkMovp8jyi+6n2qEpfpND09P6eZwAHMZQCv3qv6PbYTn+mBnnhQncuuqi3b98bLziz+fhjSyDYqoKj+GAKv8VmOIx94Y1xjSNzoRZIVYGTkszTRtGYxO9ZEdJG1RM3Wqnq8RilVUkYRGzDTnylEd0OlO9h8kuQgxwZrlPlueB9qFAvmmvVp4fhB2gcLnRNQLzbbav/jTp0OQg/uPxiEcjTFlP+Jmfea804pK4YC2TEv6R9CqYi4nroINB34lJfXmBSJKaVBBbhCD5mhtZIV+SZOf0dymva5LmI6BwcjpZMnKdJy68YdE4i37SKycUGbd5fROeXiI1vYCDe/cnoPbTrCqIAzP+8l8vE7GtPSgwljkjuOaerDASinQKvsC/BA6oVtokwoU0fmwcdOvuH8mIe3/kJhYEsbDu4Vsnr5dKfZt44FEy0IGVv6p4Sc23BqdIgQFa5MCmKKfS7yQAo3Hx6kjUv/fXZI9vQKvREYSNAitWQ2JpmXxA6ZWLgzw= X-MS-TrafficTypeDiagnostic: BN3PR0101MB1025: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 25:upZxoAub8UT3APt6akEkZjmbwhABYLYhWMDQDbmH1fapgUcL6eFF2AzzWc7EUIg0hhyGpXVyfOYkrqo0grhCsetSRJlinrKB0K6lUa3gY07X+0P48M9OHlZs4As+IM1UQx/LgtCosLehQcTZyP6jvf/8qcdisEGeC8Dvasyd/cMhxQG7SKoJGwWANs+MNwOg/ud930C+My6M1e3LUqGUhLL0N8bLoaYwFMh0WN+VFJBdRs6M2tlXDo2SwcGcVs5g1Gs/fOXJ/0ZOgy0E/iLHrGNOUQ1FDeu27VRnZp8FGnJnnqpWfwlXT9m1kGMLqGhRPpFbhfRXSPdPbK9Hk6RVo/mCdOG5SG+hA76di7H3LmitxCYC1q8sNhFZ1uS7S1822UoHEK/yzf6zRCLM0ZVt3xE7mMcqdKb9ZokeWexvvIeGhAqxEgFfdJlIYTRLYf0zXSEqkdUK75kJGeZ/4kWJMkvaQVJ5V0tTI3ZENrKwcIxIzr3l4lFXYJ987vDfs4zWzhzlKHofI3Msg9JSWDWgZBhiA11hTfroKcDCk5PJAfMySwRTgvLep3DeLp6hBOklXOSDAP9kxjf9dOFbJLfj9PKhOAu6lm0KGwxqWTJ2YDq2H6FKePSi0KZCQEsXyHeBly6WyRhNCCP8fV1s8Y/EQEfON36stfGLeSwpEPb8KjcaTNKeck7Q2qsDenFRBImsKLsOr7tk+ib09MuPbXfUxDUIkSBKT9dNkN75xlo8TYJGGSwfE3g6pqRN+OFI9q66j6+t16oG3aoVXlTO59aYJ39m4Zr3cpSp68L022hqhoQdKHVfRASrb2oAtc3T+ApciCasMGIq/4gNeC1vnbLaXLBVXEz2T3oNjuzS0H5lfPZl9cKua07de15S+HPiwX5oHe90C/XD3Vlxs5f4hbwTnooulFcKHqtbIp/AwvgOzjA= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 31:sua6al7F9GPB+G9pO4Qa4CzVuHqQ9waMxiDCy0QA1RoiswUewWaaxGotAJrij7MMwcfzMMNPOK6UpcmAwm6yQ7Ap1t0rCgqImnS8D9ZWIS9VTr3lWOZpUXis8QewHwTiwigrCHc+Y4EvucMplUTUWcErZ21Icyn7HlPaWxZNV4O9rRuDJ3VAfCoBiig00zV7zRVNAVpkVDhtyFdy5k/zgcYLClrml2xprksyWK+NN8q+ot5ARtXgASAYzXosDPeBT08/XT9B95p5EzYkMVt4JLTkvza3CTxgvE73rnuAcU01ixXKSoXmxO3SLOb0dBR9SLnF7n6K2AjzZK5cslJNRnLqXlQJE+TuLe57bYRg2l7mx1dd8wa3On23eShJvrKJ7NdoXB9mYMxDGwbOjr30crZvo8HYbpPWnZ3mQhRucfVme/iujhJXlIexCjg5zGAmy0QQHdB0M0XIsiYE/v+LuHrQCo1gSDJ/QsPlAMaxZmy6S8GtaF7xXjP0HTWG3VMpmQaIABq+PTgNWMJCJEDsyTO342IOHIuv7JKIxTpjGF7OUxffa6kvmYge0TzWJGcTmmmzern3rfjbHXZzGyaq9XEAAYe4EDeZd9XuqRn4tL8iJ8X9jIJx1Y0wPzFqgdjuzpqNuFHKIiqOtVnL2IdS/gZcxY2HGzwZ9ew8rrR1s5xNjc7jUGm8kKChYUMMlIAP X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 20:w8RLgcfPxFx+xzbVOLGGZwDV8a39O0Daqlw6adBlsz6cJrMIPHGzEFkuEPNt6i1yNh612PyOmzuxLRIsvovH2plT2jpNrymu7uINIUgtVUzLf1yAVSrAKChhQ/7mgCGSPmKICXD7ARYFMNk8bz1F5oT4ejCEAV5JfICP+joTAqOUIJXyJ3Po1Qmfi3juqALcqSvmUvwjNJmwWTsnKcueXfgQIH/n7YeNdVyDKvD0uxg9v3e8M8q/Ky8nRosUqNMsRwnQYY+bBoRGfzctRme7aphDDe2u+/u8z4LpymoRQ5iipid3d6lu8PKX/ZgER4bSI5kE6jEolEsKSDZlyntJW3/QDXTm21+Gfex07LCo1/kwN+WgRJv1JyjS3hxmlyvNzfCPkY0EVqRrRzdSRzNE3d2TPIf4A+NqfyJ6EhodTn5rTD8yc9ZJoZBVG+17pgPwiWZTRRubSktPq8zogBNrnFVbmCeg7et6ehlaBSsdIOZVporcZfGt1T+gPDYv0dUs X-Exchange-Antispam-Report-Test: UriScan:(236129657087228); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0101MB1025; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0101MB1025; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1025; 4:U2pZC3mSlvJFSvM1wVpvF8VsvIqnYuQraQfy3a8T?= =?us-ascii?Q?Zte3JQ3UvZ/RMUufY7vrDKssEp3jKdlHSgTrHNi35E/IaidGD0N+4mqUgWzg?= =?us-ascii?Q?yyI8Jysa9jGWaHhqwB8i65Dt0mFgL5erzF6u2q6pD17OqfzNbj5xvFJKq0hs?= =?us-ascii?Q?XvhhY1OkIOda/uTkbE/axOGt3gkF9M5GsV6S7Y1Sn4hUxnIURdU0GTywik6P?= =?us-ascii?Q?1z5QaE1nTp3TVxkvrYILCzJHPuFIgTeeneuT8j/eFf6WaOllEhvsk9WnoTOX?= =?us-ascii?Q?/HWgqr47epTbEeQwkdGyua4ejfx/xlroPAz2dFuylgh3HKEtvVcnWeU/Tj8e?= =?us-ascii?Q?f01Gcm13l+i1aVbcUvLuDJvxOx+EzSh2j0/nXt77CNbc5HK8/xGKAAFrMTDW?= =?us-ascii?Q?Nqqewk8ICze82UTGmschcjbTJg2DQFH7aeVs4Nf9ulhnuD901iOMcMl6IMLb?= =?us-ascii?Q?S/teecs9jVhtNMBggqduxB30pH8gi45DwY46cH4oluy3CKYtOGs5hf8jQ0DD?= =?us-ascii?Q?cltQ9nRe8c/GECpCezMnBrgLYff+/gUBUIe1mf8nLbv5z626hJRATQkCkwti?= =?us-ascii?Q?UEIQiC+SMOzi2cOMYZw9+nynMcr3vKJAgTZD8ZlFL6sbBH8oruTy3ICdKWH7?= =?us-ascii?Q?NsQnijh+0e7O9fxQUwbCPA9ySzK0n98ckJLAG28JW/M8wniBHLlPw+dhibMS?= =?us-ascii?Q?LUO834Qg3aaGnchHzYgrH1Pltz8PIBAmz6okbbzaJh7qU2F+pkrYV+bJL9+X?= =?us-ascii?Q?2UcQBuWn8vxwVyVoWxqXmKWEQbmTFFeMUdM2PYW26sv8J42LWcg2X1Q1CNID?= =?us-ascii?Q?XFWjZnZyRug/qBSvYM5dTXdfLzzXZpG/Qa6GVOipndGG8k3ebWm4CgJ/+480?= =?us-ascii?Q?SoP6DFVpk3eDTuRH5fimivFBGKpL7AdXKagP5eyXK/Bd0My6Ugkmp7HFOOkD?= =?us-ascii?Q?/DX3dBLj0e3H4CW/YIPlT9it5fGFXonG5wPcjSFLQHu6qmv037OogD/oHv4I?= =?us-ascii?Q?3isl1LJZLqIeReIG3TkN7SuGW/9Vdh2Dd2vX26MPmHpHJZShmiwLfFAHTtGe?= =?us-ascii?Q?QKi8E/pAb5gPEl0TEbqtw0G9p0UyQrLvI+V2MlYP/rUcBP8ycNeQRduVGxO3?= =?us-ascii?Q?Gszytf/A5bqSo/JJHELhiQrlFzsuQS1ojo1rAuvNdV2ncLPLMQgu1ao3hMBs?= =?us-ascii?Q?XH5Doxn4mSt12J9twVT6mevre0yWLCg3R9aM?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(6049001)(39410400002)(39450400003)(39840400002)(39400400002)(24454002)(25786009)(76176999)(53546010)(8676002)(478600001)(50986999)(77096006)(6486002)(47776003)(5660300001)(90366009)(229853002)(561944003)(54906002)(42186005)(38730400002)(6246003)(48376002)(66066001)(50466002)(305945005)(110136004)(189998001)(3846002)(230783001)(81166006)(82746002)(5003940100001)(6666003)(53936002)(93886004)(36756003)(7350300001)(83716003)(6916009)(2950100002)(2906002)(33656002)(7736002)(6116002)(4326008)(50226002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1025; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1025; 23:F8jksXIGBGAayb3vUMa/IsRnwMkvBJChngpXbHJ?= =?us-ascii?Q?lVlFADMBF1KNPAc8r2J3OEVPCbOsw9raSpL0HS7lbwUmynY8m67Jm1qT8pfX?= =?us-ascii?Q?u7ntLIkZobDlk/Uk+zBStJMCkfPnQVcd+ouentqDtMEh9DgDLRYkxH5gjtwX?= =?us-ascii?Q?rT+zrJfhjxszTmtDHmg9NvNr81iR2Sf890F4KSUT333+HFF7gGaETlikjIsc?= =?us-ascii?Q?1ZRGk1vpDHWmuZZWrTMYdhNUIXLcypTvVo8xkE5mh5q6tjp5rxQeDqfyDTp1?= =?us-ascii?Q?XqO5lXwZIY3UyGTb+RjQZgR+mo88lEFo5fXIuPQUrguavOCeh8+k/71Zq2lj?= =?us-ascii?Q?a13ifA4CDHqo4ctFHoLbLxVeWXKA5J31kqo1z2bT0CIBrt2XJ6w+MathDGed?= =?us-ascii?Q?TfrNcg4UZWrSVDFu3OkTlHCNbANPd5o3Z2YQ+niecaISria2xLYwi2O63xpL?= =?us-ascii?Q?/IysbKe5UodnVHURWAw9+mn4vo4o/f6ugPIeBHoJNgMAljbKqB/xdQGJGRUL?= =?us-ascii?Q?lJevUX0NgkDOhf+q++Kp3yxtWmTDgzA5ofMII+tcgD4/Dasbf/GvLJeLhTGj?= =?us-ascii?Q?fZzCfq/YLpSuHITY+wgXBZFligaGfUGsBKxSBiXKQAY1wocOW8p7YSvmRb12?= =?us-ascii?Q?FS+R3VVPu+MYSqccUyxnS+UNx+wNRnjWwtUnlB73+peGRUXofX+Aw8niyKyV?= =?us-ascii?Q?EOddW7ty+ETJVk2rGCu34aNNYQKVqmXymnGXTfALzMqD1WHta7BWfBjdEyv5?= =?us-ascii?Q?H2tjkn9ai54Jp/1wHl80TfjVNVtf2HFijp5BOyGc0yuTWzESly8Z0LTGAfvp?= =?us-ascii?Q?mtqcEyM980SnHEI3/z63WBRzRI9G+Y8j682GATBnY+rnmNNyRPj7mchhBNW5?= =?us-ascii?Q?9SOTF4LbDMrVuDYcgjuJMFr02wtvjPNsY9dbcUxIClZunqxD26UxCfFvdysK?= =?us-ascii?Q?XjfvcOi5mY1tLV2fL5DFYh4kr+irl2rBgR1LUa/1iQHRqXiZg0L+FIS0uknb?= =?us-ascii?Q?k3MoKmtD13vQOtr7sG5DDRVfQ+v8mWx7UPMJkZ2mYm4/A8CoKNgls/+W7J3A?= =?us-ascii?Q?Ji+dGVbB+npcZ6DHWKwE/EgYw+5VACGrPyai4GHRlw3bDb9YbiBFqxHs2Zkc?= =?us-ascii?Q?5FxmsO90cQ1tnw6wIs1nQF6GQlkdVphpq1mMCDOcQvqtcBwPsDxQb75nnoMZ?= =?us-ascii?Q?FCiWW7V3t8ZAHiYae//fvklFFMnoiv0jqXhcvctKJUxPZa2Lh6kgmK4vmu0l?= =?us-ascii?Q?6C8V6NaR+5J2WQVDS1i9DxIot8CLFJzlWDN48YMDCpJ0/+wwdXWO2uoHzo7K?= =?us-ascii?Q?hMQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1025; 6:UCLlwhGtYrv8o3EcTOYQ5BhcYi3YJQbuliKhWARx?= =?us-ascii?Q?Z9jKZOHsCOXTsLkU1W/FAJShMpR2ybVZwPypvhkVScCAFWHWkCQkgpxYPbu9?= =?us-ascii?Q?tHrXVXMnO2/bXT0Y3iyi2ThxnUInc/IzXaQJDX5bB8VOgotGYbFQKbb8YFVx?= =?us-ascii?Q?TCLIsTn41hlKGOyTL7uu874bQwvn7sd0LSwVmkh/Mzaujt9mFfSUwGT3KVeW?= =?us-ascii?Q?78CLJFIXox7+fwbNp/PATPI4y1bhk2hsulONr4N95AYSI4YUD19mO/ogv/Nx?= =?us-ascii?Q?OPIhHxvE7WDbsWLkFJYXoyV0/YRWPp8jvJkrbug0/aRLvJP6hOjnKv53ZYxn?= =?us-ascii?Q?bBB5EmFDHG8KwTeqdsSmYRJUGYKU9aCeBYpjweGkUBo1IR5Ibloxthp9gKoo?= =?us-ascii?Q?bk2ILx3E3A0kL4Dh8ttS9x6KsdXrFhT7Si3Qdt2WPmqItfLSJAmoxWL4SJnM?= =?us-ascii?Q?XMZ+pAg8vZfPVgUkahMSuDCk18eDcmV7NlTnN+V68yVO7dF5qEea7lliCuPr?= =?us-ascii?Q?I7xJrOU89J7Hx7ELYYe2PsDfIANbCdIzA6L0OAWgDHohGbGF+i2pFv+vxhr2?= =?us-ascii?Q?bFKELJ/xQqck+g2RTsOLPsLh0zzQH45x3U5uNII/GcYlHSAitTvo41oKHDSD?= =?us-ascii?Q?kBrszSO+uU2YqCMRE9w1VQjzcuziMLzbWVm8hDdUyaYdeTR4lNPwfqGZrWQv?= =?us-ascii?Q?mpPQC7wGBGrnkm0E6J7uGME/yizEkj2TJXmd3MSMHq6g1a+qo9z0gkWfWjTt?= =?us-ascii?Q?e1lSXB6tv9fNoO4aIYz53ornTqsviFuqtM+wWGMGG+MAx0qeIgnwe5ig0okC?= =?us-ascii?Q?ZhddP/Y7sYv8XAA8JL7kyIQX6oiARnWyVlYSMSN0r0+sQYH2bH4j3xdaTMoZ?= =?us-ascii?Q?1AZyFxpKSchuUnoLzuxJpK2jVhiYD9ei35GMMzT7rCB2KafSk41HMkWlsILu?= =?us-ascii?Q?DklWRYkHRv6C3UrAkpEX/mVX+7h9hyzi3GomZWugkC9+EBLpnKReytxqT0Ob?= =?us-ascii?Q?jQg=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 5:E1D+O2F6aLydp6Jh34C5uU8VOcyIe5g05TXeT9MY+I6kOeBkEMeAgVfZrhGL3VXajo70wV4S3lZ3QWBKxSYwTu+49TK6i/7Nh737LAkpiyuat//rs1OWJIBoiFCYo6xk6qAJYzfHy+aaKmEvi7N32HBDqmB8LhWzUJSCGkyDZOQGGI5UYvmBDg0QCXQ9/G8GnW9dleUxGAJNaIUS3P//H+NitBfNMGP9T6B0al7pYIHbYQKhZ58Mx6pio97w/RzY7dhXow9TUE5DTtd5aPITngzcbcgwU/lOS3OgKOgYCv7IgnEmSdkQWL0SLqoHCtuPP71Xa9272GdITI6Lc+m59YjsjvVVNdM9KAWrnbVTxHdtymveGjV21hin7DErPns/ySAjO5O6sO9aXr6ooiYSbw1s80JZNQ6a26Oj2L7jizejM6nyI1Rz4kWYRL+bKa1lW7XcD5HoqABHMR9dcW197UKEtpc09LCAu+3Jm2RsZFDB4iTiu7LZcF1VlDxx0IYt; 24:YLagCNCDec/LBmSkaKYb3Kk9rHJfU5Vq207dp9MM6MpQYkiE501jHQEaHCizwp505sMGpvfcuo39wLH9fcc46G3ezqwq/H2xgMoyVFWNuys= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 7:Md1yuIQ7WoPtRxUjpruAWWiYt4W33CuOZH2v/uLEhw3tDtNYHQgK49tc+Jc56l7D6O+XamegHwTA1y/3VyZHzS6d+5XlivjLngwTMMS22ws189UeNYnyJUSzpw1amdL3wfCSuX/VHJh/CGa42dnVd+MND7tUbYQnBoOsslQmQlzpd2xkydBq+DYd9fdaVbTD+TRC8+xmzfLD+arfS28srB0HUyBhtxQegx+kqLMYlsVCfLkK0u/CEhhwyYtGrOTzUxRLtzNlsHxxzCqjSBdWH5NffvIKXbuFNqEmRXR4DMoJ2k2bwczQOye29Cby9uwDaOCJIx+s7Fc0vJO+lwiOvRypky/3HG3H/R950C1WOgkEFsl/s6cb26Cad3EsmKOjq/vRAAZlAsoiwtv4vIwRwXd1FZ/p2171HIw2MZeStBs8CJExlB1fkpJPjT6W9Daux5HsdgTckW2Yv3dmM6/bTPBIsKDom/OolhNeUjURviGfek2eAJJVZNx0De3NhasWO1Fcx4aSEeKBlZMe1pZFXnKGWZ8svvMkIElC4dNmN4U0D/WIcEioXF+TmPg1HbbXk5duzfiu/k9XVA9nmIk7eB4e/4nIX7Bp169qW0Isx2jz4YmGyNZfQNIEnWn8k9wwzveYwT5n7NShov7LVES1gc3+llQzIX5bIDigyDO+E7BucWo0udBfzHbPwvvv8WQLfFplhf5cn1BoPcFaH2JE77J/Gldx344jU8g5e9tr+RxyjDkCVixD18AIo2nwc3maO3Q9fnLj5yhNAe4+Ach3bjKkQ9rl+39bf1r0f4Mv+bg= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 15:05:04.7172 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1025 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 15:05:11 -0000 On 16 Jul 2017, at 11:43, Kathleen Moriarty wrote: > My guess is that industries interested in the DH key proposal would > want 0-RTT. I think they would want to prevent replay attacks and > might even see configuration errors of this as a risk (allowing 0-RTT > inadvertently). Concur 100%. ----------------------------------- Roland Dobbins From nobody Mon Jul 17 08:07:05 2017 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 2127B131C34 for ; Mon, 17 Jul 2017 08:07:04 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 J3ZM_nirvWrX for ; Mon, 17 Jul 2017 08:07:03 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0124.outbound.protection.outlook.com [104.47.37.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DEC131C43 for ; Mon, 17 Jul 2017 08:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Guz+NCV7gDQgxsfFoDWuGR7sn3GkEmoQqCxxYRhp7h4=; b=RoBTrWU+BcjrKbo35dW2gH/BZ9oeoHTFN0im6B0Nbqg6P7J400SVMnuI9lnN3zdnZ+cgTGn9DCILDfkHb1nc28URI5tyaEHgcENZuvqWWozPzUZ8WaTQE3aaDbwG1iAMshhycgg6B75Acmp3uVDsOsh1+vQ7EatJTX0zPjkmE28= Authentication-Results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 15:06:56 +0000 From: "Roland Dobbins" To: "Salz, Rich" Cc: "Colm =?utf-8?q?MacC=C3=A1rthaigh?=" , "Ted Lemon" , "tls@ietf.org" , "Matthew Green" Date: Mon, 17 Jul 2017 17:06:46 +0200 Message-ID: <52C47C57-DFCB-4378-8C7C-6D8A5AFF3075@arbor.net> In-Reply-To: References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Content-Type: text/plain X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: DB6P18901CA0022.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::32) To DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b84e9d69-291b-481c-1011-08d4cd2577e4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 3:s3e6bFpAG+y7olgakrcyiTnmFi9GBHyh8se38PbXN7NTF1xCV6ewSXz4W0tv1DknhoaOUab+E6NdPi8m4IYruOwU5kFGSHODMyMuQIKRCWupXO4T6kMiMKccJUhCdtb0iTeHQ3azFwt0N5XzIikV3MP3GiuS/j+8XhN0n9aN1NGNpOktrg8Bs2uY6G8pSnOqynH3syRoP2Awq8FrlXcFoRcECRHZrF3clg6i3AhWbVsAmZoGz5Hoy0DOAdYGpuBY71QqnoUBlDJgLfgReyiAP3LDqGEjF4SJS8s+X1YM5yh1+EB+vJviYdmHy68n7YRm+5ohinazzVI/8UTEaAQ/kq7xnFUM//0GOlqIg9eqCiamflUg8qB6S1Rtrbn2W82Qqb05XndBC592+3RTFegXmHAIildQrIWnowmb5/pFeDJCtruT/nfu3C+7+LM9DUGT7WCsc+GzIH7V3wsSU3cBLH/G1/cNx/jSKqcISPFT/bn220Ce//nIuMg/kZ7O5b2BUCgZcmPy4HLYH/0DzgKTcEvqY5o5INkyROFPfe7ietX47vAQkt9m+Sssj1jEk15HXJKklVD3rbx8C616sMffiZwJsDOJpv1Cbpa8QvO0gg+1O3QEn0MdCCqwsEMCD6tnKH4K9kz3mKdEzHtbQwnWLg6ZA47AduJeP1duSx6XDA3RmRsyYOy2HI4fgMw0TUjv0VOQf424KWk5P4QkrF/9daxa6VdscstjPfgfGuWwXzQ= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1037: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 25:RPI3vj8sULPLmaLkIvVEhA5hnMrYD2JMUv14y+V2Jqx+sPCfbHlhSJVUgyTDlIkqlEL68UAltR1gGIZJ77fQbGgn4G65kzTXOz4ITOc6t8t0KY/lRozxO2EDYjoas2ofbh+wqJuUdDs7afyuCX8ghbVmz84yRffcYsKdnnGkJl3rxotKhbJ37gHEer83wNMB+4nDFqPqni54JUBhPjETqoNVoP9K9s/mv0ROh5ELvRLzne+pooHyTnC6gXt+13SgCmUTSTHs2tI5WqX48WiJ1yu5EQYW06y0MmOdlMgwbGYpvgVc1ZCypC+bfZO6Ztnl4NEtJgw188GFZNGSZEzig5JhimFqGpJ1CsZuHwZgFfEb76H80OAKMfgELGj3uqkQNR7TBS282eRV/jArV69J68lBTS/RfyYUwgJ5TKVmr5M0IeCP9xjr70KmteYUFOZ6vMT584FMeXYcY+/zycBwrnZ6WKUXzdZS8xse+GHqDa7oAs3EHwCjmsaYKx1tvA/D4fi1gC2bJgqktDEY0WcwFxGafNuj/lOhDdA9gPPF0Xz1dSExdHQSiAxLU1Is5JNg4cAsjbyAJlwCwAWb5if+vrIKpG7ulLVit/sXhFinzDjyMsKlVPjGaLzAXO29j2vHb4MEVEqkEnv0+qmcw6vSL+7fNi0LqJgXjxlW12a/W4Wq17qvDONftF0M9mdiXL4bQmt246ZQEhY5C9J3/Rh19+nYB+pAH896os0oakTzhsEeRrB2eaQUXq+7GrtMLiwHOksfxoFGBLn6Oh1SR0kYsXJX8BZ46oK1zTwA6ilFy1n5anM0b36ueRq//Y1/pOrRjdqowRMeXAyocAkDyjUInpdnkCJYl76AYA51Ghti3UeCYY0DMXmssss3qVn9VyUonsZ+D10j7AdPLss/OmvvuLTdR9Mkrxsid3//3D79PfU= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 31:rAnJhqXVc+LVCFVw5iDBIOMLgL90KcjfUgJ7m1Uj3vu5ss6YcGOpiudX03F7VS8SQ86VkBHwJOdFmF6PHT1doILEtoQQ/9gzkK1YzBDYTzkuXl0p05ANTd9injVq7bAX8iLmAc5EyDz5j9gkPLFNhukzD9VVz4rIbHfoBcgaGFDdeGxwZpXfsEXKbcEtq6u6flQCz1HpqLlZQACytaeQ2hSoaZsVCikqoO5Wf8mveZUmwF7OzuIQ+ZlKejoZmdE7nwpyNFI8E2EYM0Wb1zxMtL433Hg7Yze6syOLuj9H+SYUg7j0hGUUKGUzjyjytJ4uP+va9k2ViKMFmWtfFyo9nqsHlAtW2KfpMisLWmUpqAbnbUNkna4GezuMe/RunoYw+YY1O1kU9fICG/a0cb1nPkLb7opqyXeEbrbAvZ9DCHRUdAHhizyykYsKqPKRXHkGlz9AQAiy5mrATcJgoW4m2/aiQRZVJo9qXJIyaGJSQ+a1X+eGUtK/60/PKjH3ER046l2vjP+tKsdx/WqnkAv5Wl1RPXgFBiN1DbK1PDtGITEBLJqp6YgJwUvDIkP1NLlt7yVwMipd3bubKCTDrQflVmcFKwBa8ePtbvJ5lKCqS6QEdkzJYG9SaHojTvmRjkC8evn6Z+KFKgG2kawpk0+v6i2xLFKIb8c9o8u2wljA6TBNbTg6SgjlEr0IFVeYGiZRsBwyucfzoowXQOKxUm1WXQ== X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 20:xHyIlE9MU+JLQgMZylQFVI51SCDtnnzVp5yQxgMhVLiK6/rhPvl5N61LzHXwqOU5A0R1W1s4Pz+ReCo2k/UmgJd3O+AzoWG1cs6u0q0Am9tkthZbHm+n3dnhfgVby/wu/JZ5Tw+wiDfG2f1hEwZmUGoS2sTuOCmYqBfOAZtYRw+W5iHSUAh26zjVeLJUlWZ6IS0ErDQ/qPoGWBxU7w+qOXWd8H5lL0mZDm3szziIh/K/JdG9yCfkQGKktwNDcw9GnMF3A5ef4+3LBaEy8s4H6x7xmK3ouQftG4Kb6CADzzpx106bEr94Yoy8bL0FwnYSrmIkC1P0xJtn3P2Z+3wWOxJ8/nXgjfsXLOMrsAvV33dDxsRGNeW+EMAH3t1wI0v27wlKSo9iVwfltfP+XI690YswyJQkFL2RSjCDgFFvEb3wVFMkd+q7wr51V0+/szhKPxDCr/qVs5HaH5z5xepWwkfAFZmFZX2In++Q0W1nOnqNwXMbS0Afg1nhUyq6YQtN X-Exchange-Antispam-Report-Test: UriScan:(236129657087228); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 4:DyqrzYOSjdor/PodObhU+ljgcT8xY8Ii4rXhX7q4?= =?us-ascii?Q?zOGAYHcGekVkPaYNk8ESn3jLQhQgURGsbgFYwsJn/s3ghj8EutZX/Spu2Hm6?= =?us-ascii?Q?5BtjAyS9hx/LbEpY+eaMzWcRLXmybT6JFZniwEB1ZT3xgzvPvs1jLxaYrbmi?= =?us-ascii?Q?7EeSD/886FwJdl2fdg7Nt39k801PVwwSYRSz85NZdCKuX6BApDkSgL99flSs?= =?us-ascii?Q?gcoCb+sDvwDxAKn48xc2izFXmAhP0nzTJvHJHTUgtstrztFfS3Fs5BHhUwcm?= =?us-ascii?Q?yZDkhYg+bOAUPgrGEeJi5fQnkJ8gQTpnNIAt3cwK637lTN0g39pQomF+iQ39?= =?us-ascii?Q?OP2JsQ7c1N3U651POZ14JwDSQWY9bNsyi1EPm56hyPCC972UMue3PXzyxWAD?= =?us-ascii?Q?qZ0TG6O/Xyq4VT27TGhPSc5J0vHlgJlu0v0PNGL1wpMJEGRh8KOn0xQZneL+?= =?us-ascii?Q?Ox8cO+pGSXOKehm3m7FJ5uvfzLesjpAt2s089YLMrE71q+nD7LDTHa63L/0c?= =?us-ascii?Q?1yuZDIvStJQNOd/vk2rDPewcsCPFVn23kmsAXJOL6b6or3cIClcjP0yJN5oG?= =?us-ascii?Q?JEJ53WDdW3RVWqEMsvjnV8PEGJLvl8QgB8UG5cPYK8aUYtugrwQlS1owydIx?= =?us-ascii?Q?Oc4ccEcuz0in3ESUr7nR0vj2FnpyPkmvn17M/waVVlgHi9x0+VElvPKBa/bL?= =?us-ascii?Q?NXCedgwMQWyl4CdKxz0yYonD26WtvO4NG+tHSbhm6P55trHruEE4yLOeo6u1?= =?us-ascii?Q?dEsgeTFJoPU6lRQ2IkO3lXVspDOyG33NI33biAuXeJmgvjO4AD7Sn8zOsBRr?= =?us-ascii?Q?xqAQiQDgHuAecimZQseLiJ+395tGCpr7x5tym/KusOx4WzZoYjyvvOiLFNN3?= =?us-ascii?Q?7DK5+qB0eKTHgM4DangaQI3ZUL6CjMtzISvZkm1IMDKjM2350ioiidlUM1km?= =?us-ascii?Q?uxbwUbeCbr1El7wfheoWRf4NKJOUp5HKyzlY4PARAAsg0fQk/RFxEhgMKwG3?= =?us-ascii?Q?3pmmFUvmOQZCfQIyyGgCr0ZPAoBWU5svIahfN+i67kyg8okTGviB+Lizii/A?= =?us-ascii?Q?90m2gMjEC8TKySPjtcLElQ4vlfp3z7+wUl2nChSB85ojZ/K7lVaT3Y6antKR?= =?us-ascii?Q?e0jkogNFWZcm5FfZYuVItv/k7N7AZUbp5ptRKJY462qbHwt9ehWtXBKzpQ1R?= =?us-ascii?Q?Bs2QPYO0QoJ2Qo8XGy13AIjylGnzRFM1Lfa5?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39840400002)(39450400003)(39400400002)(39850400002)(39410400002)(24454002)(558084003)(81166006)(7736002)(50226002)(53546010)(2950100002)(6666003)(8676002)(189998001)(4326008)(82746002)(6916009)(83716003)(77096006)(33656002)(6486002)(305945005)(38730400002)(478600001)(110136004)(3846002)(6116002)(48376002)(229853002)(7350300001)(25786009)(5003940100001)(86362001)(2906002)(50466002)(47776003)(50986999)(5660300001)(230783001)(6246003)(66066001)(76176999)(53936002)(93886004)(54906002)(36756003)(42186005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 23:kv+/6tMZvTdlv4ocysK+QXoZM+OjrymT0+UIKA0?= =?us-ascii?Q?Dooo5BDIo2EsrB7x2cCMYyWNa6VPug4aTu5aO2mWLnYweJGL3ixEvx5NQi8m?= =?us-ascii?Q?FI7Uu9lKvSMU+ALTclo4/n9+3IvXOsT1Fwg6KE4juaHYw0wILGdz/9kMy1hL?= =?us-ascii?Q?pGKtGdLoXfSr3rsqui4n+Hxd3lDWQqYZqv9QVa24LzHc7md3a/55N6seYTKa?= =?us-ascii?Q?0qaARVMLpdmWhfMwrGcuh6Bdfn2Y0W1ofW5wBo+SK52+rTNlx3ixVRPxp+s8?= =?us-ascii?Q?DpHASzRuLcafC9PQ8yHkrywQynsPdIvkXaWIGTo+Q+2Ykq9eDydsHRapY0qe?= =?us-ascii?Q?70U32+MoipTNvYGATc11Asa/iwPtlshfEeUr+YopmkGTxeHUWEfxuU38KR7/?= =?us-ascii?Q?2cGZguaNBhpvIEGchbqdaEf/ySY6n+vADNLE34X1Vcq7ABJTQQbooMbmOWoA?= =?us-ascii?Q?rbGHbdSaEcQTSb1reG+uEmEhezzIIycDDRCW5PyPV/GUzugyVaMMmvFJOlJo?= =?us-ascii?Q?grEbwt5/P1B+zgf3duJCxsIqk7cZK/DZwMFtGRaA9LPMaHczirVuOjkFQhGW?= =?us-ascii?Q?8MJBlLbfPDENlXVmAzCmcB+RhEnD2jzQX4RfrOvjXMRCNrEOXR8PhO59gNox?= =?us-ascii?Q?pAYE4q3idjNus5pOKspGStd5IZeEB7/CkZ5eSP7D66qpINjW+lc7cAvtQynx?= =?us-ascii?Q?7I61gHi3tbkslyDdwX21jAmc1RWerATPDdeW1AAYOGodmK67NOIo+2PVKdM6?= =?us-ascii?Q?dFre2zswaUsLL27HHRsy2ScLrfGyMC0T6n67/dwJXPk366e/cLlbU91bNnLG?= =?us-ascii?Q?+Thl95w40FM70WJnk+ZAsZSdQJNbLxPqNJtutWDq1tAKs857szICTK8sQ8jy?= =?us-ascii?Q?gt9bNWXNZHZ+0Mgrcrdf8rk7ER05x+6H+AMUOYPj8yMKgJt6pO8tlZBcPWwX?= =?us-ascii?Q?LfatZDdB+sVlm0MEwYNNMTKff+hpkePUvNqYq3Y1nQCDSPQJ93hGAojS8o0/?= =?us-ascii?Q?8uvc2YQNt+z4rGKF0q7ZjuZb3HhQGfLgyceb8h7ShkhFQ7XCV8kquC6ZALkv?= =?us-ascii?Q?1ArvJDIDwjsgdxce42kvcGoxRj1QMWonEPTCiAXFaMfATp23ay3D8qPVuXpd?= =?us-ascii?Q?HjzcRmf0gbMzYxTTV888kVHgwjmrs6Kq1OmHS5Ct3lVtVaTM7sFfmgn3b7VQ?= =?us-ascii?Q?KHsOrYQPwMb9YXL6BYIRppfdxSjIS862/J3LL3jV3qlrh9MFJE1SHPrRHYBi?= =?us-ascii?Q?7JGX+OUYS6Wsz9qZZY5vX2mQVYy7sfd7AnQ/ETwxEH3+ZWDmaS20+rhIU9tm?= =?us-ascii?Q?FYA=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 6:NKgTfE+RtvZVNTEWe0XCe/JCP59CCaOxsVlel6pT?= =?us-ascii?Q?K7oBYnVUo/Fbgv1C0xaOlNvsn34qicSiIvcI0QsNnw/nYm9h+7a2xVvNn9DC?= =?us-ascii?Q?owNRnRqxZxK9Cy3g6TrIXBQwa997R2g4ez2WmVyk7oGjZb17S9lAuSIsg5m6?= =?us-ascii?Q?D0ApvvM7/C7EA1DiMnErbS3lt2QFS0KH4vhJTxziUL7LFhnCITQ/FY/r4/xh?= =?us-ascii?Q?ixlAagd7xkAhaHzoe96P3p0gtCRoHcVfpodNDGkvD4yOd1q9A2oe6OOyOk0h?= =?us-ascii?Q?m9dptyk11DGiSALlec5pX1c8JWYehccNnRDK7zHTtTDwUC2m6z0JDJns/yjC?= =?us-ascii?Q?VdiCcjvWtqlp3RaQJ8i3FdjsWm1tE0oSnLXawPE2xyI19NSFCq4IMzKn227E?= =?us-ascii?Q?o8/BYOFq03FZGJhwbIlgTI2w4XOXxOqKOYRvdavmVO5CbCmtToW2u/OsPd1c?= =?us-ascii?Q?uh2zzuX30s1iBCosVBNDGvD1tbr+YZ78HmAemeM/L6RrvZdztwuFB4VHUYBW?= =?us-ascii?Q?86mLS3afzYf0+KSfVmCwfmUMEccEq1TcAd8ubE+2SGk8jO/5HAfEp4o3BoSm?= =?us-ascii?Q?ISkohH/+xs/jX7t3WgmMBnPWtTtMnAL6tdoxVq0W2rRKm8kPsZKgqigAncwR?= =?us-ascii?Q?h99EYmlpYteO+M7KjngJK5b6rB5LXUdX0GQorTMbHlZAJwxgPMJRn34de+Xu?= =?us-ascii?Q?K+7klLYZ8fuGr4ZmVllY1pH7QxfjXCiq+Z0DBh475n6+uId2yZa/j08OPsVJ?= =?us-ascii?Q?NrUUDJHbPdOcsLnWfTZlWt+KGWDGbvz8lX+jLQVwDxy/6IHBbRsWkX4ti5su?= =?us-ascii?Q?j1ckUk3G3vebG/JoNPNFIHrzywZTsWgkj/+8prdX+t0t//ecg4rNMaY12BQv?= =?us-ascii?Q?Ob/9Rbm2ApzuwM+Kq4rpUMBeupjrHzmJ3c5mJLNK6TonbdY1U22Ure7ZLZ0d?= =?us-ascii?Q?+UZTM/axqi19A+NRhZGhN2wpa1F8khGJNOM//c0iiYUceoWObfs0Ck8C8bCd?= =?us-ascii?Q?cJg=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 5:FHp73L/RgIfQcEh/3A2lHlk10WYS8ybjJTmas2cxxjBAxBqpFGYHpVxO8gs/tiVzjsRw4oYA/6nPAwr5pofE+NeEyUNJT0VTByDSbmxC/1HwdNu7nlHN+T02AjGMzV9+wQ4DiN44A48ULCeIcIe+2wNZc8kMuCrmUFLXo8tjPcdPN8UDsKPWWunQyFA+Eca0yKbnuz/aSYkeTTxJ3F0QHXDChzKFG1urTNxGHbkyjtUugr0bq82MZL7PKLVGQ7/y+FZ7JThDQMy74vtYXEu2n0offx7+qHoJIWhKzBwrR82Cn4SjpqZeKVmczEu2ENvQ6h1ORfnQarspH3EAaBVEfUwHArT+UDTeXNhNGRUt5d/5AB7EYeOvQdgMOcnkNH2KeCWHCFK/v9gbKnA1Nhwdx3M4MGrnyA142qkWD+f4kDUUvmBIbLBGPCVH8wspitJWV3gg+ZW9DVZnPEHvMu/ZrMGV9FV8X+WOgKn4FfU32Bhb+416Ii+uidCOm3VWTO0X; 24:LiYHTA21nXd07oGRi4IoBZCx8hRfyqgq0/V8Z5zneSFJk8FX+jVfQIn5RfxxCgOgtocqjpMl6wnyYTYVYF+Bd7osBSSMTu5xp5AVrQ4TXw4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 7:uw7z+GfXOfQrrgUfdL8zvybv9Tq8yCfLppK+OHZqnDO3JR5pNV6DDNkR6eZ4AI9VdsndsIImwQa6o1oLxzzv8JzUa5TxVUzTssrbWrThj7Ay/MgN+pH+XiJq2NqO9J/dugCvEX3qL1QGlCNrz0uMbqjaQnjletW8CVf5wFwqvLlyYTmgT1cp9IRk8Iw/0JZRxM70r6Th3rMi5vN8X3TR4XgKOkUTDSfZddycHP+3wAVbUbDYm/uSpv/BPK/N4kPC3IUND4Uz21sN1nYCiA552RNtBxMImWtCcVNJjPwI8atQNLStI8aVETZz996UV6kY0Jg09kNZyvrhDXsIA2v/jF8XTW1I7ksre59Zv8BNsmwaAgOJtYbBMVigoBKHyKJw3668CtRvhKwqzyQij+bIc/pPO6EpGNFVIaIsx1qFioGbAgzVH+hiOUqsJ5EfMK6sjg4zmXA1BTe3oa1aLRMu/8v513YP0N6+aaNY2ucJGE8J4qCTRSuAqNMKlVeVikbjRTHKn4hCiUURJTbcgO6RbvsRFPpYv1nn6APSrdUvxWYGhcOR4E4IIfa2evBdwqaZOjI7f7K/ItMrxA0qL2rz1O6scDoP9UVNPb/TIO/yRoo9dr9muQKurqzdW2GFsbmbq42TigyoFh7jYkBkl07uSRYBrFWolRgM5UPsOVZmRJmsQkCDO8LwWk13vqTh27tZzGPIgMJrbSXo/TV5b76xSiOof45BsIWJ2YHE70/YvaOLUsMI3WoF3w5BZ+cmoIfQunU8qnd/kC7cAd/vSN1o+XwSaUQL2qwiWh7QG6sENKU= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 15:06:56.5001 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 15:07:04 -0000 On 16 Jul 2017, at 11:19, Salz, Rich wrote: > The key point here is Within the enterprise. +1 ----------------------------------- Roland Dobbins From nobody Mon Jul 17 08:08:41 2017 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 BFA6F126D73 for ; Mon, 17 Jul 2017 08:08:39 -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=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 LNDe2DBPt1-7 for ; Mon, 17 Jul 2017 08:08:38 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 69C0A1200FC for ; Mon, 17 Jul 2017 08:08:38 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HF2evx001255; Mon, 17 Jul 2017 16:08:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=rskbDacT6npWqu6a27PIDh6fL6+foUPug+aN2y6ytCA=; b=lw+i3q3SVLjVrV+sLD1C077CWpc2aUki1M2G3KMXAa/LRhFOpHbK7EL7M7KaXU2Sj4OA J8v2yWrtuyET0QO8fgn97EvtNHqQmQtYHeZo8q0PkXirkPKVr8xIvo/MlRKYnSlQ2k91 ZvzFL73o2vegYU67lXx1toMiIhd4bqvTpGx4cf6YPk3omykScmsYB35h+jHjhLbF1eof Izej0g+GRLb/fb57asnZpGMgBfkp0KbxMaZQtdsZVb/R4mtkzhTDU7uTFhfQpg7JmW7r 2/d4OuZGolYdk9xiRgbMZt/AOUnTSd63P0Sjn1kNQW8sz1A2eg3gJPTJColiUU8jBsnJ WQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2bq84d8mpj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 16:08:31 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HF5vhT021230; Mon, 17 Jul 2017 11:08:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bqecve766-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 11:08:30 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 08:08:28 -0700 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.1263.000; Mon, 17 Jul 2017 11:08:27 -0400 From: "Salz, Rich" To: Roland Dobbins , Kathleen Moriarty CC: "tls@ietf.org" , Matthew Green Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01 Thread-Index: AQHS9u8P86lPDndxlUiqCEzu895UtqJKs/sAgAkO1gCAAK3pYIAARzIAgAC+W4D//9gbEIAAga+AgAAdCICAAEOKgIAAN5MA///LkJCAAEZ9AP//vjvAAAmY7wAAPYAfgAAISzDg Date: Mon, 17 Jul 2017 15:08:26 +0000 Message-ID: <1b45a5082e71444a8042f97d7c980b69@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> <4F7D0238-D6AB-4A56-9036-3DB2C8576C6A@arbor.net> In-Reply-To: <4F7D0238-D6AB-4A56-9036-3DB2C8576C6A@arbor.net> 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.152.121] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170240 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170239 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 15:08:40 -0000 > > My guess is that industries interested in the DH key proposal would > > want 0-RTT. I think they would want to prevent replay attacks and > > might even see configuration errors of this as a risk (allowing 0-RTT > > inadvertently). >=20 > Concur 100%. We should not design this based on guesses. I think an Enterprise doesn't need 0RTT and early-data within its LAN. Let's not guess. From nobody Mon Jul 17 08:12:01 2017 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 235F0131C60 for ; Mon, 17 Jul 2017 08:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 yKiMNtrtDWKh for ; Mon, 17 Jul 2017 08:11:57 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0102.outbound.protection.outlook.com [104.47.42.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7227D131C65 for ; Mon, 17 Jul 2017 08:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6c0bHWqXST6YV1RosgW5B/AQ+VvnUMb3Fn7M3Jztccs=; b=l25FnNaJCh/0uo02BedS41bCofFahn+AdUt4HtvdFfkWI4urRufwBtXbmT16zBUsP+AQ1jqovu0/M2LyX8+hurTujGjIQ8feBWF+m5AKQ7mxsegw1CdF3IIZYYOeYW/fUYHMhqSWHcuRokIBasEdhjN3j1p5wpz/hDJofCyknng= Authentication-Results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 15:11:49 +0000 From: "Roland Dobbins" To: "Blumenthal, Uri - 0553 - MITLL" Cc: "IETF TLS" Date: Mon, 17 Jul 2017 17:11:41 +0200 Message-ID: <69018030-3157-42D4-A573-0E39E46EFAA9@arbor.net> In-Reply-To: <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: DB6P18901CA0008.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::18) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 64e53621-ca40-4d66-a519-08d4cd262694 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:l0+r/+Dfoh7DTLlGJgQxs9IlaNKK5JhEFTp7DR6P/ag9s2B2jMg/h1cxQgtb4FwTfvEgn7rC9yLt6blCXt4OkuD1WIOVW3NZ4gYzhftNNwrbSNZCdA0ewYtNpAzJwDGh7UBYwqfWy0TgSAqhCrVgdYubIuLQ43W37+6XAu+CM6g4Ua6zqL5t8KjkP0wJBnJOQRoZZt9vwwvKSrYIr7bkik6aBvUgLbm2C9MsMegWdCa411rPzXqovKexhXyhQeSHvrFLe7kJeQ0SzxbI/WYtRRq2fs+vWz9XvpY8Gpvoj60CQDlfQ2vat9/IlJ1SUr6zlvA0PiTZ6uq1GRbe80gL6kALdy6iC0jaexUT2/4tpUuNW0X1wDt0bJZv6sNc4HE1dK4nJPh76w7Bp1l9/+ewICKP1PebpSxUlBl63TampN9yR0xjaHzoey0l6BPM2fbeVDdbc81VxZVaASVSzw0AFHfty/a5cS67FGWA4A/3byVN8EQrdLmV8Hx8NRPxigf2wnpn2InhhUB8X1CObKkMsF+6O5sZkucd5jjlx0M0bcbRwX+Gg9aKfSGdp4hpY4weRDIwvVlYOGJC/rn2z4bKPiJT/hqjLlbWBAvb+fdXBTZqloSjwzdZfs6og8zxg1nobiF0yUh6FVvgJRXaBpDGgG79LVuQSvhia+GM8sSLDGvJisVk05Z6wcVRlc0aZEcnr/DzyfMJQt95fnKduq8JuP1DOxXaryMtRfzK5VjcliY= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 25:sns9fbj0FRqDETDH+8FiOd+J+B5IqD/1JJC4+FnhuqVMJ5fOlFYL9ghoQ+XprZAh7JXOvSQpQe5uC3282i3ZDJyw6MH2OZMc9SKgyb6HmfZ9dQUa3H2POnHcboVCRwSO576Bs/ljMTuv6YpRGXz2BkI8sS/FI9d3rTtt4Zm+cF7clnHUXv496VNdd2oA5uQpeExDCAw5tu4PIFXxAfb5IgEjCXSnfHx0WeGM/taTcze1dEtILD1obJn+VC/gnoGrj6k6P1cDSiBT2h4u2hcAK5dbi+rkPcfYuWN6yI3EiyrzswPGbSR1G1a+1Jp6r39oGw0okC2UsHTFiB+l2U7XMjTvT/u04RXotnEbvVhvBJg2bmvb9dqxKccC2/nLdiANUReZLfBi7Pz6AxU+/Q7xt7a4cIbkYVp4XIQhp3655BuZLNt8DVkrrJdwOGaVSgvayWYearzwuhVPJCK8GlmQ4ljddwrCfaxWoKuHPEHhUS59OcnuYJ5e5BTyzKJdhRTGSwZWXykLPrC9AtblYcpRB/b6QjolrchduBGOFJSnU/hlTYzCYb2gUrshNWZOVp+WqiVsQ+VNK3iLdpPA9npcA+9RBGef06I3afQsZw0/88aipe+DQQPgVHOi/P+5wp7jzeJ1utOqpW5yIW5gsDyrbdPAbSujjhDpGXFkJEAJR3ZT7960ANQ+4hapEmdvDrME/13eXls+eAT0tHyGSQPV7IeYusjJPDPQ3IczbelFPvMKU2zfXZe6W04Ug3AfT84I2npHIkqy0/l2kG78LA3F6pHrUENyZgUHGckwl9fdnFye8UlqUj7G8WrwgzPshCmqksCLnSX1wYqcquRiqq0+SRZkDJvkTIIvuZnF47Tc66g3weCZY3KBJB89wN4M20eb4vWQEbqZ7Yz+MIW/S3IMgOOV/DZJ4qHbNf5OcY8GTXU= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 31:Z+2RT7TN25rORT5sfLdkXXM44Lr6/2Xc3a3mkiDmuFhe1xaowVEPUd1FYQME8HKX+WvJ0Z/c/UwREVSE4wFVdycA4WMIACdQ64LPt+O2ClwVI27zywaIUdVzYxnPsZ53crnax/ccIs36iQ7x0FRp44jp4xg4PDREBKn9HZqsi2wkl797re/HKFGO+eK15hjhn5XpOkM0fkTj2c5+jiinR4DzfgLmsolyboiMFqL+FB19Z2v+hOSFdCgMC3P8cKcFq6/DemZDmzCyPNaAJqnAs7Zdw8o80l70NO0NrywKptGUMESEjFYQ4L++aIvjX8UvF842haqT05K5PqUnch+gYbgBeg/V9tPZV6erReH6ACqCCN+b8Z8bkKMv7jUwdhW+Y1IT0k8xkHfnkkqO5TaRGJyWP4VNXp+NU5VY9XCnoQMZsNGLSA/9Ly+iK3jCC5pUJmIn1V7BC5AyPBlCo8woaLejQZ5qg1B4qQKxyCsjHDGYcmgKNAKVJTPqpjSWvUZNdZvZDQ3a/mqbv9O6F59vYWO2aQsZ5J1ceSkjHxfqEpLElp07sr1zPWSNiDy56u30wZ0SH3u6btdC+lKs/COt112uOAVY9DbxiNaoVNzCMqu2ycIYO2YD1JdcIyfPgQjuUuKJDeiGNrB/ZQ61w9jxX9dx3CLcIY+yQSrdA8miyp+tdqqkgcx5dQJ1ZcZ+Z9lwcPWjfy6WOO/liZqNERsD5g== X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:fVtWaHSt2Ce6k6BTcvBpbkuKEAolJsCkSLnNX7GfixwJ1Wl6KPneHYpI6Hj9Yj8gOevt9dc9GGMhn8ZlRXq1PfOlgtKHBcJq+aBByLV7lTJIkllaeXQYoqOiVBQuZp3QKNkiRr3xp+QmuRnGqkioX/9QBYdjAAAQEO3zAHt2vWHtbqM27HmkVoZ+qFKBTM5SzG5V1AbTxvjglhaPpcuNKsmB9eGdrhuZOBxWQn3MBmQCaAFriAf8p6agGwLv3EtaZjnwuCZNgzPmpZLVZf5xoI94G/oKc6to10eULWxtk9G4bFWOd1PjAbUG5jNPXpB3RjYjE+1L1tfG8f0mtE5W+BicT3c8uWAsE4K8AQd+kyWpuq3o6PDe05IBbHFotzQQfUA7cW2zteO7IPUuCx1r/ADjwkx5PXUj1sfCd2I/tM3Jk/N9hKkr8cn+3azDfBI/lzpJe+CRrWZAOCRBOeWP3qrZSxPbO7DN1WuC3d5XGMQdaKbDxQCUH1jBPvlsWTmO X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(192374486261705)(48057245064654); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjAxMDFNQjEwMzk7NDpTcEtvcldnRmtPZ1FjVFFQUUN5ekQ1Yy90?= =?utf-8?B?QXRhdFo0UnZ1b3FhbE9aQ2pDY3BPN0VLUWU3WEMzeWI3aEwycm9QY00zTVhG?= =?utf-8?B?K3hNVFE5UWgyb05pMDlNY0llNzBCMER3a0JyUW5mYlhoRkJoRjdzdk4vRjRp?= =?utf-8?B?UjI5Skh1RGZib0RLRi9iMmpLeDhRcHdLQ3c2aXRkWHBqZWFBY3g2c3BMRFRl?= =?utf-8?B?V3NWeGlSS0YrVXdpcmxOamJ1cGFicUp4NWJyeWlZb2VuOHh3QkVDR2JsK2wx?= =?utf-8?B?Ky9MMWd1VzNoLzVkOE5DNHNMVXlocWhkZ0tXc1QzTithV3F1TENSZ1Zramk1?= =?utf-8?B?czBXbm9jZzloTDgwNGo0T01YUG1welVTVlIrNUtwOGxFNmhieDY3cXhlUEtE?= =?utf-8?B?d2tBMFM2VGZ3WUV5RjNGR1IvMzVRK090Tm5ibXAvZlJnOS9MTnVTV0t6RUdN?= =?utf-8?B?eGJNU3V1ZkNOZmNDa3NQdlVSak51ZUR3VjdZRUlJNmlNdFh5eEZ0MDBLZ0xJ?= =?utf-8?B?MGZWQnl6UXJ2K2Y3ZVhscnFsVlpiTzByODVMV3IyY0g1bVlIUy9SSkx6Y05C?= =?utf-8?B?UjhjVk5Gc1QrRXlDRkpGVVZhVFJLYjlpRlZrWko3ZS9VMG1SUnI5dW5DVXN3?= =?utf-8?B?Ukg4ck8yaEloQlJhdmtHd2VhK2YvcnJXZEwwZWluL0RlRnNuT2NUSGN5U01r?= =?utf-8?B?M3dNR1YzR0xhU2VVS2d1N2tFR2d1THRTTDJRVTVrTFVjdGUyZEtVa2tObHIz?= =?utf-8?B?U002Qm5YUnFvZ3MrMkR0Mi9ucWQwR2RSclc2UUpxeUxubFY0R2xpZm10V1JL?= =?utf-8?B?MmZ0YWVoQ0xtYmxaOEgwWS9wSHBaRklrcUdMMXEveTNYYlNzKzJlNkRhLzlZ?= =?utf-8?B?U2J2NHQxTTNiQXBiTXpkNE91Vk15OC8xVjNLZ1V1OTVWYzJJcGhvWjhJRStY?= =?utf-8?B?Ym0rZVRkQVhMWFRnM3NaRERmMEhtc0xaVzVJUytza2dwZGxRUWVGOVNNdjZp?= =?utf-8?B?NUhYQnAyNVpUa09za2pWUytQZzJzTHNLNW9EWnZ1aEdhMHk3L004bVJTM1JF?= =?utf-8?B?Qk1OdHpMR2NBZ0FjUnJLQ0lWZHdGZ1dQYzQ5eVpQRit4VmRremdiY0xsZC9Q?= =?utf-8?B?Zms2bERDNGFxR21UMzBnMTNqbUlGelJOTGo0Tlp0bzNNbXNkd3RzWjJHODNY?= =?utf-8?B?dHB2Ui9rRThoRXhWYVFnNHBNdkUxTEQ0Z3dMaHY0bVNkU2VQdkJ6dHhrMjNx?= =?utf-8?B?MTNpODhEN0VVT0lBZ2wwQmpDckpTUGx1Tm1nbDNXTmZxNnRWcEFSYU5HNGtT?= =?utf-8?B?TnBBLzJCWUFQdDFLZENCSXdrUjdOaHpKQXliUWFLYzhYekpPZzdUSTVvSVQx?= =?utf-8?B?OGdXK1FOcDFLQ1VkdUhaVk5yUmtKRjI4d2ltc3lGY0FQS1piaFJ2MGdkdStl?= =?utf-8?B?VWhhdTdKRlNObHhMK1J1OVNWL2NHcm5zRWhiQVVLSER4NVk2U3BCR0plKzNk?= =?utf-8?B?M3lQcXlnUTgvNWR0d0dTdFVOMjlRL0duNnY4dDdHVENRaEZMVXFQaFZ5N0k4?= =?utf-8?B?SlRabEZpWTBlY0Zna3lSdm5UeGszQVBrMlcvb21yWStBWGIzVDYzSmRodVFo?= =?utf-8?B?VGxRVFZFUlpocEp6dFFLckFkM3dHSjlhaDlFbnhQalRhTktEeXRYd0IrZGR0?= =?utf-8?Q?sQ/bN4N054Z2Rww9Ckfe4XaOYO80PwN9oqFjEo5m?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(24454002)(53546010)(478600001)(189998001)(7736002)(8676002)(33656002)(305945005)(50466002)(2906002)(229853002)(50986999)(76176999)(47776003)(66066001)(50226002)(4326008)(53936002)(6486002)(6666003)(23676002)(77096006)(2950100002)(6916009)(81166006)(25786009)(2171002)(36756003)(110136004)(38730400002)(7350300001)(6246003)(86362001)(83716003)(42186005)(2870700001)(82746002)(93886004)(3846002)(230783001)(5660300001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjAxMDFNQjEwMzk7MjM6Nk8xN0ZCK1MwVUU3MEpqZy92aU9OY3Jx?= =?utf-8?B?MjVJN3RCVk5hNXZlaWNld0NzOFVKNmc5aXFxOFNYNHcvZ0xuWHVMQVlJekhy?= =?utf-8?B?RUZQU1JLc0dwZWlRZUg0bGVMa3dmbCtEMGc4aDJZR2lmUHhrVHg2MFl6b1Jx?= =?utf-8?B?akVIRHg5YmFVN0EwcEVJdjlNM1craFRFUWg0cSsyR0lKY0tXaFR3TllENWF1?= =?utf-8?B?TGdpTnJTUjMwRGJjT0M1N2JxejVJVk1hbEJaeHBWOHRTb1FsSXFQWkZYd0ZU?= =?utf-8?B?L3BhSnlqZE1pcUR6c3hKY0U2VUsrMGZKcDZwT1kwcVBwNnNHbjh0KytIVkFt?= =?utf-8?B?NTZIdXVObTczSEtZZWhmK1pzZitZalU5VjVWVVpqa1V3R3ZYQy9BUVFnZE9q?= =?utf-8?B?enVUSzFNRmpSUEJOYlhybHNCV0JsVVh2eGNNei9md21sR2o4QmNYNjJYUXUr?= =?utf-8?B?TjdQeGJSY1hkclIrMTV5VDZ2aXRNdDA1RE56Tm1KZ3piK3RKeUJYNHBYWGxO?= =?utf-8?B?d2ZmY3k4U0ZacUtaeDErS1BDZ2w5R3EwUzh4SmRva1hZMERqaEh1ZFZSbmxm?= =?utf-8?B?NTRCeUJzQnVmWW43NHBsZzJPc2FONTFCVGZTWjlad25oMnp1eCs2MDJjNFBN?= =?utf-8?B?S0pZM1JSR2t1OWhhQ3VNa3hlS29VZXlmK2dKMzJLaThEVGxuWGQvTGNFdGNK?= =?utf-8?B?RjI0NDZvYXU0eGVTSXRtQ3lEVmxaOFh5aFRpUW1nZTFRdndnY3Y0L24ra1VM?= =?utf-8?B?UVdML09XYVVJVU5rTEttRDJMemR4VU5uOEV5eFRlc1BHczlpOHE3QVRZdk8x?= =?utf-8?B?WVF2V1hBTVJ1WWM4dnZSRDk0QlVzM012S1JkYkZVQmNlbUFrdEMzTFhaRFlY?= =?utf-8?B?L0NKejF3OW9FQm5adFFoYlhtQVdRWlNuZjBFT2ZyNEQ0dzZMQzIwdDNKUUJr?= =?utf-8?B?UGZUK2NzNHhMZU5ieTNmaHVhazdrSERqaVVFYU9HRGJvOTRHOTR0a3N5RU1j?= =?utf-8?B?dE52Q0NqMDZXT2pnUm9SVjhxc21ZWTBTSm5Ma1BhQ2s1N1o5ckZpNm41Ynla?= =?utf-8?B?aEZTTmRLblBsQzkvNGIvVTNWS2NTVmFKQ1J4Wm00QXc1NjdtZ3RTczVveVVv?= =?utf-8?B?VXd5N2cyenF5R2Zjb3JmejVHQ09pQlAxSmQ0NE9UUjM3c0s1WWRQTzQwd0dK?= =?utf-8?B?YXRaalVhL1ZzQnkyc2xvL3RlQkJWTHd4ME8rUU12bFAzelhyOVRlUDNTdFFn?= =?utf-8?B?b0tIbURURGc0Q0U1MDdMSmlDUHd0M3JZUTdMWFVoNEE1Wk9TNHFScVNFTGVq?= =?utf-8?B?Q08zQ2tPVlZNZldHOVhRa0N3NmY4S0ZSZFNNWER4dEhxMGxDMFJTYnJsaHM4?= =?utf-8?B?czJpWU14b1k3NWRwbTBRVy85SmNhTEs5Mmh5UHBhTG9NSmcyckM0cVZTWTFG?= =?utf-8?B?SmFBN2dnZkptb0xheHVPZktFZmF6TTRMc2Jpd3JZeUdTVWFKNlVmemR0SURH?= =?utf-8?B?M2h5NUdxSkNVd1lBVHdSWXhyOW1LTy9TRHEzNzEyVndxdXZTK0ZkdzlQSDZ2?= =?utf-8?B?aWk0S1BEbWVLSWNiVjJvU0ZWa3U3N3BsbUVHUzBZOUlTQlFoUnpKZ0VxSmNF?= =?utf-8?B?ZGphaW1lWW9RN3hqbm5acTB1WnI1b1AweDArYkhDcWRLdHNHNVV4NmNrYTRi?= =?utf-8?Q?xTeo07MCg/7RNEKLj3Td/Ii396dbabQXJz2O+n9Q/?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjAxMDFNQjEwMzk7NjorWGtmRVdhT00rVzV1dExyQjNHZmZ4eWk1?= =?utf-8?B?M2VOOFdsMVJqZzhCZ0pnZkFjUzcwQkdBdFQwbU44K2h6aitlRnEvUWN3QVFT?= =?utf-8?B?bEg1SkYxT0xycmc1d0l1UTJTYUkyUW44OWUyekpOM3pvYnNxOVF6cVRGcDdT?= =?utf-8?B?SDJnRUhIQWpmdUtNTHBVdW0xNy9CQ05IOWVXT1Q2KzFOR3RSMTZFT29pQ3cz?= =?utf-8?B?UUhQWnRRcElsNWpiaEhpZ2E0SGJkeHFGV0ZlUUtlM3NPWXQxN2NZV2JjbjRP?= =?utf-8?B?dkhhTXNuekhObFZ5QlprZzZkam5ReTRRQjgybitNUXdaaGkrSUYxOUdCQWZv?= =?utf-8?B?dlNtMmxGSlZJeW5paG5JYlFFbkZRQS9CbDZXdVJLWnN6dHFzWVNITnlKN3Np?= =?utf-8?B?aC9LU3FXaG5kd3BWU2kxVmFJLzJONlF6MUhBOGJzTnVQZ1FtclRiOW9DeW81?= =?utf-8?B?aGNJc1orMXAyZTF6Z1RUMUhDUjBjYXp5WE13c2RQOUtGV3phVGR1SjhMYVcr?= =?utf-8?B?MlFFWkFxV0tOT3JwaWpjdU9ZcXpadGdFMFBGRFRacmlwcGtPSFdrY0drR2JZ?= =?utf-8?B?MnFpQ2UyOXBSVjRaeHpGVlRzZzVKM25nK0dqWVc3ekFQemNmczRYZXRQclAy?= =?utf-8?B?bHNpa1hWMEZpTUFvT1JhTFM4TytKNElwYnFDektKNDV3SVcrem83aE1aRVZ5?= =?utf-8?B?SEpjQnNWdFUzdnoyU0t5ZVNEVzVBVTNGRHpjeVY5YVhqLzM3bzRzZUFnbFVl?= =?utf-8?B?bUJQa0ZEenJGaXgvdXkvUTdIb1FiYXNRN1FHM1FYL2Z4OTBoS0hKYU14c25K?= =?utf-8?B?dFdzTWpaVzdBWTgwS1JtRCtJV1dtOGh0OWZ1ZS9Sa1BoZTZVaXprTXR3SFpF?= =?utf-8?B?aXdSb0kwMk1OeVpCRTI3U3ZXdGtKZ2tDeTduVndBQ3B4UjB2a25ORXpqa2Jr?= =?utf-8?B?TTA0TUZyUGtLNkJtZTh4NmNEcGNPU04vTFBJdFQ4UEF0U0cvalh5OWpYUnFM?= =?utf-8?B?VzVqTGpYMThJd0pPT2I3RDNmSEw3amdEWEo1K3pDTWo4QUJINjE1V21TSUcw?= =?utf-8?B?ditCZllGKzdVZlhLNUVaRlQzVnNRVmpNb3k3UmE5dXNOdzQwSStBTkt6aWl1?= =?utf-8?B?N2YxMXZISEVrNHJPVnpLZGpEWFF1UGFZS1ZlOVQ3UmZ6U0xMRWFnd0FZTVFK?= =?utf-8?B?a2dudnpNYVp3YXI5Y3E3YkV4c0dXUFYyZno5djBYVXpwV2JWcnVORU1KMFMw?= =?utf-8?B?bjZ4RTl5LzRPOHdGaVg5RGVldDROVDRpdnZjaXp0SVA5MFFvdGhCQVRNZ1hn?= =?utf-8?Q?HFG4ygpaOlwcE2URH3WugTx7wcJSImqJc=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 5:YruFPnTnsQCE0r81Sy1sbnFw/CTsNYNIz9lv6H4D2J9+3qYymZvz9V6goxYuRhIRecFn/YmABo1tU3XSYn53jLVtzIa7Azr8CIbtkzBoWb5a5QFa5WolqObWYh0PR8Olq/pWEYC40xyun5/KeWst8qkR0UJ3fzh9bpiKXdiSNA2+dZD6bN1vJLM2C1oTgl/HTEiTl9gHaJ+L9JuOxxZWql0TgpfW54Jn6H1dIE5uQEfXe9p2B3qXqGTGe9U5993RLvoIA1M8f5HEVmiVbqpn/IKmhNOxalPVaVnwV19WhKHV+nXrj39pliZRjD5dVlFaaRbKt8TzlALunLEiyj6396PCndt6m2noTWpDEFOP0wztXradTl1EgnpjWbCpKIn+AWOTiXStyeAUWF1FRebaWFRmbb+08Gsg+nuYsgdN26q95HZm7J+6P0hnTtX5NqaDVDfm7aRHkFf8bdh4Da6MSs+9ho5XND6ZfaA10SzWg9V/j/D0tRsHqYMH0jpvTuu7; 24:+9B64H0p8qZ6tg+sCedn1o32rmPCt5GSuWLRLVFFtqwv4KduX3N8x1fx72M1iJrxmlZq+VxFoVBo1mkcKyqpOdCIGz/K+dE21sBwsYuyRCI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 7:OGBCa7heXnqOoxyOwJiFB03UcXt4v0q8ZiIxr1SH7Qk3isLavsZkiCTZnZ7ylUH6wnEMes450IouYETgzSHWKOAYwQqCOCK/ffpjjVGr3drO4DxpmwBJzZg/Wdi4Tflfijh2XApeqf6kEnEkmBmaj1349krduoOvS5jGT9lYYlK9iWo3/CCWffN2McIsH5ZUIRDt2ArrBGI6OqmwQowL1Nr7kcTveJYaV8caVNLrqHv1NxrMyN0uPm+Qn/B57rCnxb854yERKfBgywIWwnEjhcmbr3yZkQxen8nsvzgRDb8lveUfLOsUZhl4va/tmNmXFOOcIeXDaVyKcBS53gO0fUiC4aQq8+j0nYyWNM5YGrJ8a0TD2kYyLHP68JtS4EAYi1rcB12EB2fa4tF/tJUbLoeoHfxyv55e+mqaHnqmHgls+7bvYwuckOCtacCfbRpUs5utEV4lqHPTlElxrc/46j10kjVh8OfWiajoifHi273dVn981e4WDaS+WePAEeYA3wljd+8K7vWDZw3jT+fj+piI0yfVOmaqptzAJXt7WIrzxvSC0yusZzVvuicKE15JZ0JNaMxPChr92rWqChWkcdpSgSIYFFzJ1IV/xXFL3M0v7t67+8xhzkVpM9QlzPOKjw3f93ej3M44G7B++4csy6deVV6tDWwx04DsqGP5VjvpU9UprpA9Isn5XSgQO72Ku2mo7RngDzWHYhXQViwaNymTlzj/HQ8Pm9KVZV1x6dZ3yK6R+I4utBCLBwbQb16lJQKgi1V4v/q6alBLQ4sk/+ptKiy7dJwh9C0SiQG+TS8= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 15:11:49.9872 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 15:11:59 -0000 On 17 Jul 2017, at 16:23, Blumenthal, Uri - 0553 - MITLL wrote: > It may, or it may not – depending on the sophistication of your > adversary. It is not given that you’d be able to “simply detect > the presence of an additional crypto layerâ€, particularly if > measures are taken to hide it. Sure. I'm familiar with those counter-detection techniques, as I'm sure many (most?) of those involved in this discussion are. And of course there are counters to those counters . . . it's counters all the way down! ;> > The standard definition of “traffic analysis†is deducing > information from the metadata and the patterns of communications. It > explicitly does NOT rely on knowing the content of the traffic (which > is assumed to be opaque). That's what I was trying to get across - that uncovering an unexpected layer of encryption, even without the ability to decrypt it, is very useful in a security context. Sorry for being unclear! ----------------------------------- Roland Dobbins From nobody Mon Jul 17 08:18:24 2017 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 54B4C131C6C for ; Mon, 17 Jul 2017 08:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 aphXwhzCjg_k for ; Mon, 17 Jul 2017 08:18:22 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FBD131C6E for ; Mon, 17 Jul 2017 08:18:21 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id 65so3842756wmf.0 for ; Mon, 17 Jul 2017 08:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=31WscweSTr/xhGX+KI1vjg9tm3o2dED3od7pbVLTfwc=; b=Sx2qKIcjEHgj+j7V+isRQgYT2cb3VtmEDD/socR6/MLSS7WACBoOzw0sJ822kmDK1t HZg8EaX+UdtE5HTx8+k7ITk3JuWLyoByuNcPbqEDO8FwOwFYLiAhtl6T9W9OPjUO7QtK GBP8eL+3y/vv9rfQ6Hzed2Mwt7onncDPYxeU82BJZTN/q30aDLp+Qr1NTwQxWyJH0Jcd bpIByQ+Gxbq3wsB70NT+VO98wFgqHT6N7LXtmtWQsAg6vroLx3diYf416fV6nxk64eY3 iVwC8A1kSXjQYog6UcElJSe0oHvUJAjaiQdMV9RGnovcg/92WcfOOOyLwo6eJAADgNIS vVnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=31WscweSTr/xhGX+KI1vjg9tm3o2dED3od7pbVLTfwc=; b=LYbOacZcAB/TvFtwGTYz0o3/0mLunLTPAKh1H/7KxhY4vC5Y9WR9fHkfLL0CgpTdK3 sodE6UKJigQxt69JeWWaYfQ6YO4DVAqTQq7Lmk4Q7rspAFI37KSSASoTys9Nre3Gn/F/ erMZ83yjjOeoiaR3rjJVk8oe6H5UK5jBkhetqoefdHlVIz2F5BgEyalIP++CrKXb1uWH +dyY2CXgqcsm/4Gm2k0HGOYJZcU417+0PLTaV0W9ffbzofhcMnp+u+LiGqKqhVAlSZ3n 8Nb8ogKPnTS9B6cNs50kUZglLk1JrbQZS89aVv1nbO3NPOEoSMwSeovnfpA0TQ0qbGSU OaGw== X-Gm-Message-State: AIVw113lokxbeFsXnxF/KE4SMtK3ShVcgIv0SIGwo4HF/r1vOTRXRSUF Eg8wjEV5JXX5gA== X-Received: by 10.28.184.83 with SMTP id i80mr5212562wmf.98.1500304700104; Mon, 17 Jul 2017 08:18:20 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:4866:e216:9a2c:96a? ([2001:67c:370:128:4866:e216:9a2c:96a]) by smtp.gmail.com with ESMTPSA id j31sm11059426wre.67.2017.07.17.08.18.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 08:18:19 -0700 (PDT) From: Yoav Nir Message-Id: <09C9DBF3-75F3-4B59-8522-7ED0D0BA3AD5@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_94DF1173-58C1-45B3-A2C1-504A2F5AC088"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Jul 2017 17:18:17 +0200 In-Reply-To: <52C47C57-DFCB-4378-8C7C-6D8A5AFF3075@arbor.net> Cc: Rich Salz , "tls@ietf.org" , Matthew Green To: Roland Dobbins References: <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> <52C47C57-DFCB-4378-8C7C-6D8A5AFF3075@arbor.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 15:18:23 -0000 --Apple-Mail=_94DF1173-58C1-45B3-A2C1-504A2F5AC088 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Jul 2017, at 17:06, Roland Dobbins wrote: >=20 > On 16 Jul 2017, at 11:19, Salz, Rich wrote: >=20 >> The key point here is Within the enterprise. >=20 > +1 It=E2=80=99s an illusion that inside the enterprise uses different = technologies than outside the enterprise. IP was for outside, and yet = it=E2=80=99s all over the inside. In the end, either this is in OpenSSL (perhaps plus a patch) or it=E2=80=99= s not. Either it=E2=80=99s in SChannel or it=E2=80=99s not. Either F5 = have it or they don=E2=80=99t. If it=E2=80=99s not, it will be impossible to deploy in the enterprise = network. They=E2=80=99re not all going to implement it themselves. And = if it is, then it=E2=80=99s on the open Internet, and then at least some = people will have it turned on. The border between the enterprise and the = non-enterprise is pretty blurry. Yoav --Apple-Mail=_94DF1173-58C1-45B3-A2C1-504A2F5AC088 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbNU6AAoJELhJCxUKWMyZ80sH/1MvoelIHNE63WgXpWAVtONV i2JntFBRBALOKZ8OZiVksMlQhVpqxhL2x68iBFAnmk7qY+89v+SXTRchTHTGrBjb da27ZQzaCZkbeQgPQw5M5jtRV3kwoILNQS/9QyC1xV46puaAk3eXMGb9/AE/RnwP ugWZDy1yMWItpssWq4KDMQ/+My6m0jDlcGoJz42bCbNu0rGD/Xc+oFEhXRBH4UIb jm4+unhBzxtVoDY09HS2N1p+Ja8sIyyf/Tx3X7gN77EqvzYjOA8Thfn/rvHohb4o nIsogCz2sSTl5246XRsFz6FeWp7JuJiNcr9a+gxAJLUuNJUaSMvVT9Zhyk/OKbM= =t23B -----END PGP SIGNATURE----- --Apple-Mail=_94DF1173-58C1-45B3-A2C1-504A2F5AC088-- From nobody Mon Jul 17 08:32:50 2017 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 51D42131C55 for ; Mon, 17 Jul 2017 08:32:48 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 3cIJLWyX8tbC for ; Mon, 17 Jul 2017 08:32:46 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0098.outbound.protection.outlook.com [104.47.40.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD7A131C67 for ; Mon, 17 Jul 2017 08:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+6U4gjRrksSEvVJv6NkQETU7MTZHeAwbj31LZPpG2Lg=; b=H2PUYUc6U3H6D60M1t7SzPp4kSC6t6dIMd8kTT8vWfUnHGWzYNMTakkug/Bub+WfrnqH1rmsKk3pD0xn3TjjaeqBO1F+B/K+U8+xfgVqIleRX3iRatBatc6Q0n+Mi0xZ0jYjy56xkMnx5bRHs3GEnmJCA4MkjV2lRqT3j6sVpFw= Authentication-Results: cem.me; dkim=none (message not signed) header.d=none;cem.me; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 15:32:42 +0000 From: "Roland Dobbins" To: "Carl Mehner" Cc: "Russ Housley" , "IETF TLS" Date: Mon, 17 Jul 2017 17:32:13 +0200 Message-ID: <637C97B3-DA63-4F61-8EB5-D938136D520C@arbor.net> In-Reply-To: References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: VI1P195CA0005.EURP195.PROD.OUTLOOK.COM (2603:10a6:800:d0::15) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2152d758-a9aa-411b-69d3-08d4cd291194 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:4XKCBuhaf8NDZ4GczhETHY7rxurgzAFWC606ssEr22kgY781pOXiR2zCl+DfPJgNg+PHvbcHmXSSZOIh1oM0rS13wwjgpPUl50/bmZJwq2vJcNkBApPH7YrJQY+ieP/YdAuldJ5tAwEbS7jdEJVPIfkWeVkwukBQImCKdlRrQ7Qf+fg8+jiEj1lIYFzjQigaZimP9L6UHifznH87UJui9dc1Cj/wPwsAyLVBHKk6b2CYrJt6kn0hFRTDA68k+aUgPI6z1mb9hl3Uqld1jpxuxFkSQlvX65eSOfMG/3OGZ/IYNKsudUnpcMxsuRSsMfAmXq8PeewAS+Qu+b7M8HxdPxMeWXb5oMs+OqTitUzlelyGoIIOzcf/brqteagQ4hedPfZuVAoNve1PfDCp2MTwDRBT6bxZyO4KKcPe20GtNz17iKuPi342opptdkB+FlnEdHzvDzKnuXjGAsDyqFdhm1ffQglD9u5qxNWDbTdBNzG/YjcofgxH3vWmXGQwowCJYgfFRe6+KpsygR80gL3GW7e1/uG1jWqwVtRfzKwelwXmI1yF8JnDm29iRaNe8XK8/JSWefxqrf+5gLuFo+VyTc8acdTJPQkDoOke3ignNhlLzmskf+t3OoL2hxvWCsgoaB8UhlwEtuHHBOSfIUlclCC/1MmaLjsvbn7/J9iBSV2+mxYaJy/QZSQIwP/qzYhU0RHC8TUSp1oI4bmPaYo5uTy4lRiz0y995wI10wzlfK0= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 25:RvqHM740g6bF3hRruOG6K1wVZJSHT4+9hrwkYFFvokSEpYK6gvz2Ov9IWTnJkKF9zGsgyJKS4vSxl2x3l6eqR1/LkYNIvxzW5+AceC+8kKbC/Xt5rQPgeqxp5QK5DN/sL4OhM6k5wltdSFTMB4qRWEecppph41k+/TdnLV2C3sNhgLMrMJYAMQvOuGuJkr5mEX7KKU9NYucD9I4shoo9JC3LJ4Pev6nNSrzv4ols8BSkQle8pGZr2hbC0BxmzBdWVaRST0e8M0fX5GdCYLloKpDpT/FF/SbxS3RTpNWxD9KfhAt5pKTx261Jf0P6VqiXFZLLlyRZgz4rcyfSuDE3mMJZTkLFxX6qdyr99d3ayNNNOcIhiyV4E2Xlt4kwn2Hjx9Js0iIW3pd4FhvX0Kju5GNY01ViFNYYfxwCxEUhDPoLxUYAbUxe5qGAwC5Wk18+DxKJ69YmvZ5Rkt16hFhykJ5Ff/exx7eCAwzVG8XUO+qiQKsZpEB6xgmXXP2FKzwMvK26ZuKHLuwJEIbDlA/XtRiHNn1+AIbYbaj663AXQUrA5VXAWDh910pM5cM3MgyDZGTgVvYVy+Tue1Lm6ykCt0DvvcEbxDdpjksWlZalU6O60g9luNHV5Q30a7ylJky4YdoYcHpcg+7UCd1wDKyb+9FJ1hknbSHeYPcJQ7jh0g7koNQuey1M71ZpGAONXP9f0VftcQiOf9DNamKhXkvhXXGwHA58rLHQbHrMFFCRLWylYiruWknhrW4votSMsFf2Nqw8jssfLEbgVYD0OyOU5ihTsEQz28FtyPhJ55UHeTykqWmEjIp157lNBpE+N/AxZHBmyf714Y/ObfzmBkleQYeTNwd5V3kRpkiE/fVHX7xNeUTnKzmjRz1ItTwNfWidSOdpvbD/B6ugMVPyJUNdyYzuKrCYU8kgazKGO/DBCac= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 31:qFKBaKoMd9lmJa7SYNxGKcrgho+fWevao10gOvHAv2S4sBafamA4cmBJYWFai8RrMaeYsVzJ7vT6oNvNEO44FIbuemf7z1BuR8QzVI6Ld81s5fRChtQIo0uoHcEASJYmi+w49+P6uJ+0PR8bL1ETpXo6/a8RurOLGxLXABFU3ulVbsQWDB0Tvml4sG3hTRSIpER7mFPx9h2lSp7ZX/itViYGyZLQcSvz8UBKNahGjYMAFghlxcJGNONFXN/1MsDZLYppQFHosLX4ltWiz2Y85iopIstkodlWq6eIDdVnZibqMcHhPNxEdyON25pnG6T0ZgEQw8nK+i6BG1tcnqRqTK9tJigManZmDmAfp8+7cvTZwezjAfUR1SLxAlrWjmSVNob6sHSvw463uSqYMfNTXtBXrf1hFoHiUwFj8XAATd2YIcBRzCkBvqQB04O7b5t8LNC8CxsFJd8PrTD0Oad5T6CRvtvTWZSHswwnGLmS7gKYP5usGVuD6khyp7fdkMqIsT+miHyPnPtUOof9p7Ja3/6GdAF8HxMvSrVJllvwwxMy/YpHMGLfSZyIfATOtsz1DQtDSPLedDYH0OCzVk9CkIhqBnKZfpYeVb5bW7GVm16Jqu4oKv7hCGHzLFyHnD6eSI6EGNLR5wJGSG8eDOqMtB56ng9qrfmx/Ba71Fbo+5conQCa9hqtTiyeBEDq0xPWDJ6+MrRqL085Y6szPb1Sug== X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:FuAiSRMYiRtyM1P9ywfMqXvTDpE2tF+k5a6zcO6f4g37AbsdrPRbfEnYlj5VFpm1r5tsZogsRElFfWbeAEyC3n35JiXVgFiHOGRHSm+8pJORQmmEeMTyxZwUPUJgg0zijIFBrrP28lNUCpPtVVKgTjxjCG5ZizmdB/jtd34MVR1aWA2znGQhR919Q9SYaL6vertb1EKXKZRq9xg9vSEA5wKk07g/1FrGTeQArTz2kMmmkrSvasgCMI5KDC/Svq7CvLlO1X2q156emt8vboeWYkOtWWjWmS2OhLrjzQmD68a0llvhsEF+IvLPbnrZxPA+qTvruYAmDXIXsPFeuetzKUiV8KwIMG/ugl/fu9slHRy6fhrj0edFpNL5AD1PpwfIajYz1mMF+vfHiw20oZ7+WpGTuwthOOFHCK7txqGXfP6bsKhMSrEH34yjepOqSCJPtIh7sIo/C8qpfFWB4hlywv3ovo2yN0CiZ/qZ8KWV2XWuQaO0662P+tvzmLnHMiGC X-Exchange-Antispam-Report-Test: UriScan:(246478575198768)(72170088055959)(236129657087228)(192374486261705)(48057245064654)(17755550239193); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 4:mxCLiCE3bOe9/DkJOVTTH+tA5+k5G465qYuxyMy1?= =?us-ascii?Q?x8h06WncjKaypxWZtjjsuxmFok5ufRar5HryXmajbQ/X9tkMwehN0MUjQLO+?= =?us-ascii?Q?1h6Iar9BidpYSwmyC9tycorZl2jYx3F2LWLGHD9RiMrmEM7zVjuDnsBlQF4m?= =?us-ascii?Q?+1wNF30l80M/RLke6UiD6m8P2PVFMBTMWg9X6pRLX0SihOTHU3ZUj66hud0Y?= =?us-ascii?Q?zIZ40gMokEcGh3H2CRRxAhF6ILlgGkas2sgZ4XB7PSS3EN4xDQvdf1zInFPl?= =?us-ascii?Q?/pZ0WsEbOqgOM44Zpe9dRjmqErPzie9Fmkewy3AQ3UFBUOtdYPdIfxg9nQAL?= =?us-ascii?Q?/yg0fpfIbJezLvzFnA/thqhmBRgrqDjjYfGvQg8p0dFeU56nUz/FWYzX++iW?= =?us-ascii?Q?od6+OelVuLyW+e6AqB5SFScPBJRnRnd7Dcn58+CQ70uPHk0+iI9NY4L1nFxM?= =?us-ascii?Q?HVWQ+QNwgTpA501ytOwBlEd6ZL+EOakY7/N7feVIdzdNis0kWerRaZMpjT7h?= =?us-ascii?Q?lNfQtJqchbmv/vxOnqpZ9xPwPib0hYpLOFsg/7vSSqsef/BvixGVQ2LaRWzM?= =?us-ascii?Q?Lten6tIvnXRlwcRNwkqQWmEaj0F6Js5vG+FGCwDgqPAjn6xDnv/Kri9e51Xl?= =?us-ascii?Q?2UckkCASTj70cBdY1dVPkybnVdk9jSw5+t9kzn6N/UHu3nOOJrOUUp6mDjBm?= =?us-ascii?Q?36UmzMCi4FVdr1+bQwexm5j7u/UGM3wz1edtmybB3T4tSg66z9CDkK1yrHSZ?= =?us-ascii?Q?KtHszUaR7iMMtdrioijTKomeolrdIyOA2GjLCQBuUxUqPzvlmc/KE4FnC6of?= =?us-ascii?Q?kpp2S7pfSCEVvXiKZ4rT7VMBhzWuWTtnOLJ13+Wml1pwtEz2xUCxF6m5oseM?= =?us-ascii?Q?12BPtF0bLUOOsAkbWaJtqrXcErg8oweqai6sfzrYsfwGPP0cBJwrZ/c4C/ni?= =?us-ascii?Q?hskAgWLl6AD4fI6mK1O1yUknTjinG5eL6UMoFT11dMeglxqsuuKTvRBp86W2?= =?us-ascii?Q?WfeshI+WDwR3mOthK3g1AgLljRyzqQ6WoXrw2XgaAcogmRe95ULaHudA84nH?= =?us-ascii?Q?BrCPPRqNtIU8qhByudNsacbeyJI/K2NdLN5jnc8+uB0IbLgx3HxRndyRoy64?= =?us-ascii?Q?uTpb7rPI2yGOPPCUWOag3qlPsyQDKWLeYuxxEgM5bdFVScJ/1wCDKSj6iUAF?= =?us-ascii?Q?7sa0aGAYzY7IysuuscVYD+F7od1NPEjX2wuIVDBcxV00dXuU9ALp1EEA/mJe?= =?us-ascii?Q?CbCN5+gYqYdg6O//6H5h5PpivNv4vVX2EXZukVvkp4tmhtk2VFwCk1SFTevs?= =?us-ascii?Q?zkWkgB29LE0fNU94cYWNytDCOYxxUvcDEkwf9FL51ogMzfBKG6nI83bGGMJX?= =?us-ascii?Q?oX8ImceD6wP9R+74zULiwA1Ltw8=3D?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6049001)(6009001)(39400400002)(39410400002)(39450400003)(39840400002)(24454002)(7350300001)(86362001)(6246003)(25786009)(81166006)(6916009)(2950100002)(36756003)(38730400002)(110136004)(230783001)(5660300001)(3846002)(93886004)(6116002)(83716003)(42186005)(5003940100001)(82746002)(50466002)(33656002)(305945005)(53546010)(189998001)(8676002)(7736002)(478600001)(4326008)(50226002)(53936002)(66066001)(54906002)(6486002)(77096006)(6666003)(229853002)(2906002)(47776003)(50986999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:N/qn1aC0fzHQfi0YKjWe1/bkVZNBsCVkFUSdoPI?= =?us-ascii?Q?LCDnvOhMspoJrouf5Hd8hvql82eitykLvvI1BTTeegzrjtlPb2TpZIQuMpLI?= =?us-ascii?Q?egB6n+PEyAlGlRwJffoELIITHUWel1OhwTAq6NZw6gE8FEpwD3MHejdZ679/?= =?us-ascii?Q?ECUNOoqgV+wWGqAeMCsq2UJX2KT7prMLGCKCOsSd1gCiaxoGgVKq2dLNyKVv?= =?us-ascii?Q?ahtHCzgy4Dc12Ie5nkH3bugEYNxcAujvHdz2DqRgZlwsVx/f/8RmxqbmKrJb?= =?us-ascii?Q?QtRTX6w1Hdax4uwH2znc78PQNmzDD4PePQGMEhQUgxSgdgLfZF0mHsOW39S2?= =?us-ascii?Q?+4DMo9ksZ7/kC0lYu5fmBzjnPDhsGY7IWRGgmGTEZRSZNIBkEREej3FW9eWx?= =?us-ascii?Q?GDE6JB97pY9WA/OMP3x0sSXP5UWndPr2SZAFniX+ZFICIRZi4OVX/DpuSP5+?= =?us-ascii?Q?2J39eSnOd9HQ/ZPlNwjRmAYiDKfOu27u9HljZkh78gDMtddfBtLHQFl540q4?= =?us-ascii?Q?koCHDyGtWI88sPf72JCX8lmW6Vc8XLXAkVqYRhsLk+TpbzvS6Ad+H/D4RMCT?= =?us-ascii?Q?4rd7OdE8OFwdwXAlXltQ0x1pSHT0t4n67uMefCJRXa2CwHI6/86LpbvSuCDp?= =?us-ascii?Q?33YP4CMtS0b5i8QjbCKjkSMq0XxsbvRejIsqRESlc67HJXovNnK13E3M4pbL?= =?us-ascii?Q?ye/U2c5WUeQMO+ZgdUCU1YpH0of5rOpD3IV+xU8JOE1pWsQiBovTyBUmmWLp?= =?us-ascii?Q?TYMjL0JBOM9siv1/A0uAxOVcvcaBA51jdVuQI8dwCaV9LIE4OWCS+c5VxpU/?= =?us-ascii?Q?vxgNScR2VkT+r6Q5x/moBFiSzmabZB/kVpR9eqU5IX2SexMbdwimux2qU/9J?= =?us-ascii?Q?Hr1j9sQWaXlh6EBW1P4F7ryONepwZ412ltr7DEnUF+XPbRo366mE9PQCo1PA?= =?us-ascii?Q?0DmMKh0PuuaWOlJlbUL0ErOYjgWg2ovOf9FG1s3h+q02wT4CXwQjOK1E6aJa?= =?us-ascii?Q?5W6Is6DjdIA2AHPGF1yUzUBQL1+ulsNSDMEuSocp7Fl5jzHqzc4T1MrlTCVt?= =?us-ascii?Q?F6JJkrwDwfuRTBe9m2hcdTM4t+DDS+6XV6Oa+gVypqwIiE1fYj7qhlmx76qK?= =?us-ascii?Q?sY4m/k3WyXEFFS9xIjqsHWcGwhmc+Xd6QFAXRSM6bzfj9QT5Qm2TMcHPV0q1?= =?us-ascii?Q?SkF2QiHIDPoC2L/ZHYwIWcic5PF7m2n9JZpSQfzttFn8XbpL0KhQ4r7NaeA?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 6:oJQcqRMWT2pogtodIa0fEPwmTS67IDripyLeVG6Z?= =?us-ascii?Q?bKIlcVayTkH1ouyysqqvwBIUEDz6T3iTdmhb1mPef9YWj4DjCswKeeQPwNUZ?= =?us-ascii?Q?pbizOfn0lBSLLYdn+FZfzFOn/bkRE29Cre8Gb00NVnOYIjnaXsUXRETbFrEi?= =?us-ascii?Q?NzVWL5VuF5AThFMms+XkQwnAfcUdfXCLnH+JI52vfI48wnynrBEKnePcc4DA?= =?us-ascii?Q?bNaIkW+dYjCI/f6MGhj/rtEcK87dS/EYPHzSZG1U9AJ0vTUdhf9fdLjh2CwB?= =?us-ascii?Q?N68xza3dAbNmauwNpnomotPQ7y0ZwBKwh51UNm1+rWbzG6D5ItZtvPROpYcT?= =?us-ascii?Q?ttJoxWHDGrbUw7G3ikABFdfaOUvgJtq9ze+yFpmKuG1IuCrst7fll2qrIoyz?= =?us-ascii?Q?W2PiJ2V+Rmjax+BGuzz7F9ty1Lpbk0gCQF2FVi/HFSS24TpLtHPzf1ciZhhJ?= =?us-ascii?Q?v7IK07Oua52TFodnqW5bgUciwS2/kSiPQklGVB0stTvvlLdUGyUc/0GWPnpZ?= =?us-ascii?Q?F33cGJfVR51UrH1FscZrhn7u+fC4e8rxMSVLoIsacgmQSXJjxWQ6CJdm0neU?= =?us-ascii?Q?HF/I2vyA816T2YwjR3+SjIqGN/Mykl+NFRgefv5tqcjwMcqncHx+pfdU3nX9?= =?us-ascii?Q?Cep14wyBxxk4rRLfYrc3xhp+MESJmNRd8vU27SMCvlS0poZkkeqYlT5sbRXw?= =?us-ascii?Q?ZvH2rgX5kMkhbPH3raRz0M7qJv5jFv6gMqHuBc1C6x5CENfcT5G8Yb/d0kdn?= =?us-ascii?Q?4FAcXXnhU+06X0kq95VW7CIIcS1hmOFDSIKuIkaZwnOlEmC174qgj0Hh5NHz?= =?us-ascii?Q?9nRZEVcFkxPnulglz+qh4YSQVQ9jipY+zFJ5L5bgXOB2vFlmZNvR1BkrPl4C?= =?us-ascii?Q?TQrCGt+wqB3ZNQ4OSrcHDeyG1R+22yoUELtgd0jzUMeK+PslWHHCzEMKhXjH?= =?us-ascii?Q?7Dr1HYODS1spswR6wVq1cc2mPPcZTXHdQN3zt2WXIidT7iEFxvpEOAOjQFL3?= =?us-ascii?Q?/0Q=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 5:hO22rqnJpQW/HcjWYQslOGQyz7U9OVxA2hldzcjHRuJHyZcqBuctFiHKyxTfM/6RtgwB2ioBSS0NTTjYdbxG0ISaeIs3GGuNyeWH+7I4jfaENQYFSWawacAZkakgCoT1do+Bx2y3VMI6jC5HaPrPrjd8cyT6dY2Osmj/axy0eHJEr02ETo+vATz9oiZZXeysOc2eAPaxzTiXYMH4ZPfDTr3vLpnJwZXp/4BFkeYIXRta+VuucIjE2bUB+oxDN33YoTqRBEszBqkH7kHb5lABx3Sv++/jAVtlW00pgtv3Jyl2R4BciTCX9EpwlWX4AEJDOG8xGePQAI3I/IDC10UZfLNsM5Jfgw2V4BWImO9g2eUdxVpLDo5Ny1FbricKq7sLm4HF3ZAxYYW67/CKsP4AdEPahSYQZlYeRvggZmzKBL+pAMYWmRV1H0Z6UysnNX7ygiWZP/zglMFfz6mSn0+/A+HzMN++kSTdhYFZ1y2FGMejVjRn/yMBHfJBKPb/ZRMe; 24:NpvYsp6QU8uPjTTQHSf72ZxW6hMZYS3ai1CcotPeIVljCYsWuJfTh07C6O2Tfy31+WoAerQ5bC/3Ug7x7JQoS+p3j1w6OXPsA2/IF6p9xy0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 7:Qp3HpPICAIJTTMYHUBDxVJwUwJO/R5hlX3IGkcHrw2dcR2/dtsIsegfpI//Aw2TxXTj4eoiubZbEYwl3idopTJcLgrZcqrvlkw4fQxrt/Ksq+Qv6FVT/SL/KqGLa5ry1yI79eHkgdEzkLky5TKTfHTs+FTzxIUNcV0zof+KLUTjBaYTC7yL3LvyLCZxs9JDL313lQGtzLGlJa1c9olCMZO+fS6VPSZ86syeVHQBFakNlVM+LC0pO6P9zujFxgmnaWYR+0JL4owWE7ARpjxewIjMptls/Sg7ZDhu1ELrgH5CtYflzl7ZI3RDIX1Gz2waOPmP976D3arDBRn72dbvy+V8ME3bjeCtSuwy6WVCW/kp0MDDhqZaDKQH9Ur2Vry3jPvM/nEPtXfn8Cw4Rq/fBoIrI5Dml8SStS/ZsunGXWoJOCPtOuhpBBrAYjhyB0Fk+shOGvAthL9XDdn5bZfvuCXbbasacFqesXUY81/Dezp+SH3ojt384YXS8sjiKumClikODm3+IhACogIUvoH5326PEoAOyfE5ZIpHqpzV27MbxQumWyPf6CXCQ/WTXJ/nDdqb3VHiXM0v/CCe0yCdZC5gL2ktzQMvqq/n5crSYPsbB4vJqnmEsiRx9yRMBghqWaug0xCtrm/2BWXer4jcFiPDAGUkuNtJ41VmhBU7EarAfyIpP7p0a4PEWO2uNrEjvsFjD92KG+ovnujqTcFJ3xE3xcoGK1YMoQJaY1t1TCGT3G4+pueN4v9KCmWbrKxZORopKcBebwQpQJJ0EmHBNOBu6SbdNAhv5fBEVPOMOZT4= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 15:32:42.7437 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 15:32:48 -0000 On 17 Jul 2017, at 16:52, Carl Mehner wrote: > Do you have an example of where malware would be on your intranet > where using this > draft would help you? Sure - detecting attempted additional compromise and lateral movement utilizing exploits within TLS-encrypted traffic. Another is detecting (and subsequent blocking of) the download of malware by intranet users. Detecting data exfiltration is also a common use of this technique in intranet environments. > Thirdly, just because something is prevalent and important > and has been used for many years, doesn't mean that it should > continue. Sure - but it's also important to understand the mechanisms and techniques which are important to network operators, and to provide non-burdensome, non-iatrogenic ways for them to continue fulfilling critical functions within their own intranet environments. > > Non-FS was ok, because it's "intranet", now, it is not tools and > designs will have to > change. I understand what you're saying; but, conversely, isn't it in the interests of all of us working within this WG to help define practicable solutions that network operators can use on their own intranets to troubleshoot and ensure the security of those networks without requiring iatrogenic measures? > (And since we are throwing around PCI hypotheticals.. maybe > PCI will mandate forward secrecy without static keys because it's > more > secure.. we just don't know.) Agree with you 100%. That being said, the PCI/DSS board are quite well-versed in the monitoring techniques utilized by relevant organizations, so (hopefully!) they'll take this into account, when the time comes. But you're absolutely right - we just don't know. > The bar, as Steven pointed out earlier, is for you to prove. You > should be proving that it is necessary, not just that it is prevalent > or easier. The problem is that in many cases, the changes required to accommodate pervasive PFS within the intranet have the potential to be both impractical as well as iatrogenic in nature. I completely agree with you that PFS is very important whenever sending/receiving traffic across multiple spans of administrative control, like the public Internet. > I'm trying to get you to explain how this draft helps with that. It helps because if the intranet network operator has visibility within the TLS tunnel on his own intranet, he has the opportunity to infer the existence of unknown and unexpected traffic types, including possible superencryption. Just being able to something that looks out of place and warrants further investigation, without being able to instantly classify it, is very valuable, in a security context. Does that make more sense? > I recently analyzed some malware that was sending encrypted traffic > back and forth nested inside TLS. But we didn't need to open up the > TLS stream to know that it was malware. Understood - you were able to user some other mechanism, like traffic analysis or an endpoint mechanism, to determine the the presence of this particular malware, yes? Unfortunately, this isn't always going to be the case, in many circumstances and contexts. > it wouldn't have even helped determine that the crypto was doubled. Was the malware in question using countersurveillance/obfuscation techniques that made it more difficult to infer the presence of the additional layer of encryption? ----------------------------------- Roland Dobbins From nobody Mon Jul 17 08:35:20 2017 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 BD0BF131535 for ; Mon, 17 Jul 2017 08:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 5iVl1FW48BGc for ; Mon, 17 Jul 2017 08:35:16 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0129.outbound.protection.outlook.com [104.47.34.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA3F131C7D for ; Mon, 17 Jul 2017 08:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BgTYi27HMfD+CFvc2f3c+MP9uJKmJJjyYFEMiw5RXTs=; b=QwhjbGbwJvIcqOw+XcMk40QBZtfX57hpFyjiDUwzyEWdI7OHBVv2yG+9mWdGf5ObCesvlQ6wp+Utlki9OICIO8WvIq6gY+fqaQRk0wqUw8Y9mffZ9PlgjmA98m+fbT+9MM0dt7g50Hazf7l7ox2bU7P6fYvI4J5weElg5UYvy1M= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net; Received: from [172.16.1.3] (88.208.89.131) by BY1PR0101MB1032.prod.exchangelabs.com (10.160.199.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 15:35:13 +0000 From: "Roland Dobbins" To: "Yoav Nir" Cc: "Rich Salz" , "tls@ietf.org" Date: Mon, 17 Jul 2017 17:35:02 +0200 Message-ID: <1B8100FA-98E9-4776-A8F2-5C9F642A152E@arbor.net> In-Reply-To: <9D562446-7125-42EC-893F-CC6530818B9F@gmail.com> References: <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> <3847dfbfb9f5497a8aababb665e18ea8@usma1ex-dag1mb1.msg.corp.akamai.com> <79DD9197-1ACF-4133-86CF-C2E121F6B2C2@gmail.com> <9D562446-7125-42EC-893F-CC6530818B9F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [88.208.89.131] X-ClientProxiedBy: VI1P195CA0008.EURP195.PROD.OUTLOOK.COM (10.175.187.18) To BY1PR0101MB1032.prod.exchangelabs.com (10.160.199.16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c0943661-b3b9-4ac6-8926-08d4cd296b89 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY1PR0101MB1032; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 3:01cWYS1hxrwr0WuLpLOFvpLyqfVenbZaU573NRHX0OxDzTbxI4cV1hHMn5YKE/lJT3GDzlkxiNfQ2nFKPVx+qqcOTcAF6rO95jj3ELCEHbmfObm7z+afsLZFdjqC5PSVU2awKNDWt/qg73RSYsB6+Jd1i6t6RSJVvKs7IuoEWy/cLBCeAM0xn8zxB05k84+lOxvzZOJXDP0lAp9hy+JIerOWLtP9FuTFdpo0AiAqNvr3Y+diUdOq4VKMAnXvnECcp91op7OUGzTLJTSPHwMULy3uSPAgMB4k5Q48dz8/DR7Yug51T/0iSJWDbOf1XnJUd/im3Kvs7s8Ld3mzGo5Vl92+Q04Nh+OJ64HIUN5gAwKG7yZnH58bBxrFMOabfJZmm/ulKObLMGBT8KvuTUhPdOdEdKw2+qqMl0fpmG4OauAr1cxCU+MXu9zg8VtI2wv88uDw+x06LuBSbOmA66oPKqq+k4IE6sztozshM3NkPy08bXTV24rNtt67aZ6mmDlpvonIdoNslEvMQYsKe/hjERKqNooXp+LLThYeW5JQGd7vfllOPTbhmiHviQoCfuFfFYfX+uRs3TOmhPariQ7/i4RTwAx/SRRqUqFYNQGrElp0pJIHA2a9V+IqX8jXM6Mebo/wH/1T7y/ddGFuuEAAJJ7YE3jYc2HcOp4nFgUnK+Pf4P5/W+17YETH3KHu2M7ZpRtwjAlnUv+r3KQb+G6ey+es1NnGFosWUQfWKKHTVXk= X-MS-TrafficTypeDiagnostic: BY1PR0101MB1032: X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 25:7ujEmmrY6jwPJMtosv7KrrbohIhwYr2sklHTb1ooymYCZT+E5tQcbWVw8JK/CFnOe5esoyM38BUWQqTCyHyoNAZMgPqO7UNkLbHTouWfr1a5747zGt7+g4zGjdAwnaK/ndY59aUoIeGmAd33+UIbh1pt7n7fE2vEGqDRxSxj+I9RFiSn7OyYWJ+adxqnZeJbutwx5IU5JRc428ch/2dnMOorQ3zeWfHCsLiKuPeDUN0yd7/yTMu/FSQQPEv78TnFw23h4RN+TNlR5iC02bqqgo5l2Vc6lsvrg4UAcO6oGNzLap8b47LeJYiholSme6H9KAxCnADNMYlv7xXy8yivCfgxmhhAwmaJ16Tf509U0XKet8AxEErxmiT2JHkGBX4c7AQPUJHgJiRg3aekONdqN3ax3MT/xHcKOGwweIoVWHFoq+qrQ5h6/maNlBJZU0qf/V6aFMaB5rDlrqJKmgxJOud7toH4wixYLsV5IvFvYLj9KC6mPywCCGteS7LLUzrMrXy7c0M9hA0MXlVco9ynNkGa1mAeXWeVjvS36ojsv40YD3y6vgh5VJT8BOzW3HeIJT3JdjO9RuZjZei+gbTzflq++tZzaDp5ZsZr/Muj3sF4VAw8hX5OM4qn45uAXH8OJ2uVy2j3irGZhrDBAR5AzlSpRyFShSxXOEJa1S+q807kLcNV6H6eppcT0Ad7MHrtfTmk3hCGpiAlPg+jAs/aE5Mf/UYTWTnGtVAulZSTdtFApNo6s/vt6oBN+5kzcqlXFBJDjRIvr+0T6RI5P55T26+J9Du0UNlU5gv96+zExeyLsgY+tyxvoTG9F8vimF38pdD8Fz20ua1VaKGlZY30AS2g2QpzscNz8vzaWtfP5D2lu1QnT6bwRRNh/6WEyAz0S1wvTls+xX2dQPjF5MmbRH73qA5ciG6ntGmkc6SUmyA= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 31:Iy6zMxqLQr+QwVpBywEFEmuJNTWeFPR+98X0sDAeSgdUhTtCnwZ86L5CaLmZs+OFdHsq4yxoGWP2cfYy2+VXCzW6QTKwIUskFp1Ei1D1seFShTgriGYS5OUm5ZY8B6IaYoLTG7Ck0MCmqV+cb3cBTz3S+PxA3ATdsFN570JGIb3xlZB+34z9Obh+GE8C4RRJ+qw4dlr3uGIjKQfs/eILjork0hUGUOEm/EN0PDEFLxzX8SNALRQrg3UMofDthON9HPPw/mxGPYW5PGA0rxRoia3Tq+BfMlr3bsrmMuV4/4B/UqmXH+x0dW+yyaa5Gw8QOu6xou91wfPh4sDcRxZMNqJPqSipZO6Bf/BmA5qcp3Z1Ipk2TrdJB3Q6QbT5Ttaust7FEVSm7OMD6jh9MvjS7q2QExAoUnsJT6rWqxF68FNNvsL/hUfPnjjhT2NnkQuMYtG/a3xJ5ZIdoAsw4jD2UPS5pH8oeOWpvynaEwSZlWrK0nDt87a47HlTnzxgOxG3CJjPOnxqqNFwA/qDH12hHlqXyn58yxbCY/pTTMjzA+9MD4sI6rCkoX/DZOY1xCVef6+/TGgMNKCHoJ/Fr0na3+bbOyKIy+cKJnSg3gCocP0b/W8rvvc/jqhJBTN2R4frSShhc/04pk6jUMnTEQ7B4JZPkz3kgqhwJIRjX3Ew6EehGzPH5JXsanqv5aePNfRksg9gJ+eaB7kLk+ENNT+FuQ== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 20:LhH7+aHKyMFDhp+5ANLNOfyO9rQG8vqTNDSOwuPCSm0L4YDAXVYXN21Z2lLtpcBNrK1pzIKZOOLpLdnzYmSWYigGpfXaDSxOgz1/Vm4glr5IWTBmMa2QZx3nouckYIGH3LDgxERPDm43yYlpER5pB6E+LhGjBjYv3e3bQUlCQQusb9fw3JX2GMxbcGosvg09py4IlVUO97E9gsQxVLWLSZHvXUJ5ESNPb7qk/hbRN/pTwKY35e7HoM0ZXmzorYmnf+8VnxO2BNv3eg7KrJUfv136MT1DjLnR5on9sLph7eQd2RyPofiiTaCgDOnVl27LUiJawLfQrELWJ0y7D2H9aLRHcfl/qFtZCl3Yo8AAfpJAJfxNn1b5tSRnw7JEkobQbQ3d6K6B/Z/LT8LQXYAMEnBfOZ2oInWjhDHiAOXaizyoOBGIFMSlt7tikuRWtjT3RqdmI1mCN+gE7O3R5V1WFm32f4CdPVZn93Ht0rcnuqzwg5HHaOyHVN7vhBGZGnxy X-Exchange-Antispam-Report-Test: UriScan:(125551606395959)(246478575198768)(236129657087228); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0101MB1032; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0101MB1032; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1032; 4:4Vau5d8ztdUrnB7uznnP1WBakU7WYoNRLoI91i6I?= =?us-ascii?Q?K/N8xOYxNb7eB2Oqii4BcEKqGGiiqJ97Uu0xhnKre6kFKcCeFNUfTV9m7PiA?= =?us-ascii?Q?tuIM2rjL/zyqtvz2XW487loDT4O8DaA2PWTc2x3UUCGOixx0zJX5hZS6w0F9?= =?us-ascii?Q?KBwReUDIE40ANa8Y9VSFVcZXnFOxzisHPLbDdkgEkjXWzIU/alWYJuvT7g00?= =?us-ascii?Q?48IVUHBxw1fxtb8pCEsVxBm2chh3JqoEkbzIY6O6PJZarOyL57i8Jr/rbWrb?= =?us-ascii?Q?wDE8BabDjfkK8YckugSLctLc0VicFOaSTo8+iv/3fIjJxfSl2C7vcamKgngo?= =?us-ascii?Q?VWxS58dxbG5aoXZImG30o0Nhbw8KIw3SFjTZURpIR/u89tV6iWwEjPJBBxgw?= =?us-ascii?Q?oPHbWK8a7cEVV8/CcJuF96KMwyg6ubW/Q3Kr6ZRBMIPoGpdM23iykBWr+4xb?= =?us-ascii?Q?T9VDlRfokU9k3o0F9uCVM2THJUcR7DWhOp3CvDrHLZWw92/sxdif6wP9JkGj?= =?us-ascii?Q?FL5NNdHqS4A6JtL2IJu6dNPj7dekta2otwIMw83xlwxz0cHivCgnoQnLlmqR?= =?us-ascii?Q?p2Zkis15tZmL7vqSBj81GGCs+AzRAUswoYSTMFhUzbWigEX+k0fcodQohOkr?= =?us-ascii?Q?gckGgaYwSh8MrT0dzoSHxeUtQozMGvFHEKsBbO48wX4hUwl0xtEl4CZ+UcJj?= =?us-ascii?Q?PtdmxIXi/GzWg+jML2G0FEZb575nJknWFp9Hbi4SrWri2ZxK3nD3HyR2/Tvs?= =?us-ascii?Q?37T1Nmml757T2YrjTmvDpa8DrwO+wamhoOC9eiu8AvPENQ5FUn8OBkpGiDh2?= =?us-ascii?Q?TRWJ/d2PmJq0GYb7wwgAq51YjrxQt+I0nFqWd1qsqPD8thyLXExnb+hJUO3z?= =?us-ascii?Q?XajSV7F+yWkwRxk32oMydupeSKqAdU1CS6AydOfr9iXCP9+d+g2MMhfr9woR?= =?us-ascii?Q?zBl8Q4oVIYBtemg8mflLWT67cSur++4n49qEpYEQRjFguBdCTSXSyRszDEVv?= =?us-ascii?Q?YJRZBJ9gTdR2FSbsAJumm/tL9vg1rbzlbYbBaEAFzNmOknMs2X/Qo4cP6pfS?= =?us-ascii?Q?29ib2RB2ReezdIcmO9+BY74SDpDhGpk2w9xtVBueKoCad5DcLp7JXFtB5npA?= =?us-ascii?Q?L0KdIvyKkvGzCn/eyYt038S8cvj7jo+PWfWqfNWDiH0ktgAsyGmbaFFguJgS?= =?us-ascii?Q?xwqXRm7ppkmHN90hktJOS+4K8UkGPCTyKBAV6S2JZS3oeH0tYG30No1XDW9e?= =?us-ascii?Q?jiNZ5977et0dclTS9cOMx9sCON4a2bL0gcdDkQSC?= X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39400400002)(39850400002)(39410400002)(39840400002)(39450400003)(24454002)(6916009)(189998001)(50986999)(2950100002)(7350300001)(83716003)(93886004)(81166006)(33656002)(230783001)(50226002)(36756003)(229853002)(76176999)(4326008)(6666003)(50466002)(42186005)(6486002)(3846002)(53936002)(25786009)(305945005)(77096006)(90366009)(5660300001)(5003940100001)(7736002)(53546010)(47776003)(6246003)(66066001)(478600001)(2906002)(8676002)(86362001)(54906002)(6116002)(38730400002)(110136004)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0101MB1032; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1032; 23:syJO9HVM4AtkWse4I+Ybt93ydqrRgJo64RkdrBS?= =?us-ascii?Q?X/N6qcB505WV1LIDiJ9aejqKy6J1oTS8yb8rHZGkiQ7cZyLncSVe6LjrmVlx?= =?us-ascii?Q?TxBzUQFSAPrtytoAc2wXsJfUFWu4yBf3iB1jPZJiJjyouvpEgMQVGO/7hVYi?= =?us-ascii?Q?ftAXkoYtoHbflCjHaPWrVLX2qMW4h0zpvSlP74bmH/8lk6E9opVlE3tLkK1+?= =?us-ascii?Q?WtcFw487jjMNlGE52KmF4aRoESpYOazdBc6Me574SU7cx+SpXLTWO6Fds/Nd?= =?us-ascii?Q?Z2+7u8NU2DHcuGKh2rYLezT/ayFXtR6M0bnhEaRAL3vHMJOtnasBIAWYqWZg?= =?us-ascii?Q?PfILr6CFXiysVWxg60jZNapvWHUIkK1Zoj+Enn56iFJ9ylFFY2mYRvssCrvW?= =?us-ascii?Q?ozbRevUcYk5TBTt8cL/KG+oOdUkNBGE3v7fYjN4qZ4O0R0y4XjkX6bTKdqoC?= =?us-ascii?Q?Aqjk0hrBTJZIU0drcpY7khSNn8SXZ6havOByyoWOQ3FPnWL4j7gO+ZxOnKi4?= =?us-ascii?Q?X4r9Tj+0i0+Fi/0AI20aLeU2V0FhQxfdWgMeDk+F4oMEEiurMx7Zoa/pRVFZ?= =?us-ascii?Q?5EXO6VpQoalOaztDsdMPgbSjDxgX8reen1eQwIl2Q2DXoQiap1wf0ZFnlv8R?= =?us-ascii?Q?r8/k4d18Piev2TubEzZKwi6f2+8Nhe0Pma+EVlnzIPYxfNGfSFwByhDr/Z0r?= =?us-ascii?Q?OFxOwMUc2M+nZbNK+w25shNFAUbyHVTJ0NCPEj+whDPEIeCmHh4fHk3Y0CCC?= =?us-ascii?Q?Dd1jN5tDROIYTAh9fWv8fmWaIhRRqYTL2BWsd71N2s44+HfnYrQ+o1Dolquk?= =?us-ascii?Q?dM38WdrER6FNJTvdYxS88s1hXFZAA9B09AtzFMHEYyc3TwDky+EkiQ2S9edo?= =?us-ascii?Q?GhnBmXp8M9o7jUVNGJ8zPlJNZauj4kbmk6kqku6NKvW1f9x+SFTrCkwAQLUG?= =?us-ascii?Q?8gOSKiPyMnw11iHxi5YXLRnvwouz/pf/zHunv/PsWv6w2JSKezbpIW1ARcZO?= =?us-ascii?Q?gSwp4PLSvxu7H/uEisrVnsqL++NTJFxENRkRAkK98yot6c5SanOcvIpOB1Rk?= =?us-ascii?Q?MRcvEfvMDyhc+LgabKFX+Spz02/FJAD6/JQIl4qycq7EqFdDG/UqafdmI8Yb?= =?us-ascii?Q?8eMh7rpkoHrqdjetIpRGLLxLXMDSoi730K6Aa36fStvltMlVSNYiFpOuTpGt?= =?us-ascii?Q?twdgJeD0REwyEkxqb7YEWnfqxq4SSlkCzCsG6+JgkbuF/adIv8YNbRhQJSYB?= =?us-ascii?Q?kgbmzF/eDAn1wQb3KtDTOWHwgoIkbHHEEUn4FLnQ2?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1032; 6:KZ5Oufjn1/WLQ/OeD7z6xrFJyZIUXAWxTnWB1lG8?= =?us-ascii?Q?CXD0MlWIfGj5wjBhvg/m3iu0w1+CFqIaQXq5dxQko4Qu//GCzkjf+HztQGoZ?= =?us-ascii?Q?W4Qf2mB9pTwbJ4S7rnke0u/I5ssmg3j/mi5z6PsEIub6Pn1bHDSjQXcC50QQ?= =?us-ascii?Q?iv+Cnyc/Fqx7iblOEu3XIj98SCf662SzeTax94qx5q9WThyqK5levU7+Z4th?= =?us-ascii?Q?EaQDTzb/69OWc0ZyDiIDSEw2WSWiSyGuamPxVymYJiSONgMnNwL/wC9vGc1Z?= =?us-ascii?Q?BYoGg6So4pbvY2B2xgGlcjZZns3mGIhFriN9V18mgWhmhJSYJdg7YT4j2zKP?= =?us-ascii?Q?TGwB7/ZjJJFHvBKhnSLDkxq/6tXhj1JPCtNN7wRptUEGwzmIhNCLKm7L3CmU?= =?us-ascii?Q?6MXiPl32d2gWMyxemlZxhOgOkHLBqPo3OvQ5UvFk+ppylbsfMM5ZekFxLexq?= =?us-ascii?Q?mxiMpPJvMM5D05HqORjvJOQq1ofCq+ACKRwwNUOd5kj41qg32GJXxAR9JcTh?= =?us-ascii?Q?+tjSu6xXOBn+AYtrgbi5VA1EKNZ5Opmdpcj6KaIKKXu1RwZdDaRt2eUUUldY?= =?us-ascii?Q?0BVFWBjnmmfFn/zUvn+n0YIGIEk50tjbUrITJNPDe8YDrrqoafBB2ge2sWrL?= =?us-ascii?Q?2/NdGsmY3M1mdCII07SfOIBFwuERI6lBmzQNYb2ONjXQ5fXQQqme1gQaMCIr?= =?us-ascii?Q?tmrbFjYsoh1QOBDtZLYBPuSIwHADEcEJoOXSIM+smuuFZVozvkvXTS1NWvCY?= =?us-ascii?Q?cesuFrdQ33ljq2Nt1x8OFDR/dzsUt4ZA/mrEmVRNNVZ8Z466BOVwyUqpM910?= =?us-ascii?Q?ktxCaw7LPB4H9GHvvsHegFmomf0b3lJSIp1QDG+MlOk7ZP6CsbfXQd7sGmYb?= =?us-ascii?Q?HxD3eeZak20Dg8tcXbpN6WVZoEh6uhj4uMH82LbZlDQ1fblysQbQ4iiHKrdJ?= =?us-ascii?Q?UB0zURHaGExJyNsFKtizmv3MKzjf75UpAp2WxEXfQYyBuSN1OWC0OYBoIgWC?= =?us-ascii?Q?9AQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 5:MO0SOSO2Df8XYXoF4whmGpnq4CI2uNTVkRzy64LttSjgrEybmZC/pk7xZZ3U7Q0n17YHScfT/J5S04aIBn55pDlNC6XI1o2/pswzNdX8PRM9GW9Lil9xmq2ecP9d0kYiqowGbow0IlK2f9grie58PM4Zn9Fqbvkk+UfOUjwh/BQDASeajyNTZ0+5Jo5SLolid2iUsoENuztsfR+bTwygu0tZ4yIxOlYD7uhU8R2pg8FTWJgVU8f8LlY1vugEFf2Xb75iju+dXfXV20lyfPO+sw6nF7kOjz6jX26ExHdIY+K59a4l7wz9YE+CEr+schW8HJfYUg6yx6XSXCq0QhIraVbeu3lIykXpkxslMbVvnG4iQFRD5TWyCKKmaCNp+Mv+fRvuflAVtWINcfyV820y6uXpGrN1DfbW0GQ/gTHN5xUhmRFnfOuQDo7eUs+QqQ3epfINAiBxWinuZ9WPsZeSlnShntVzbWLvxY7/uUMS9H1jmcgQ0qnHXZVUprBBY1Z4; 24:WA8+g8JOmqBALYafq44ZIoi6rc45WacQocuOJ/atoaq/rYKhveuH7+MIKETkWgA0RCgKkVGnZtsciUGlBdcJ3+l4oMqDkpC6ubCyF83oPLs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 7:CMaBnXSlT0H+QGdC5pM4qTF2JBAVSnWwD0ue2Pkye4dELg4FlSyjQJfgESB4MG3XUOPqLyVWISHH7MAf5hWX/OoaX1FCyXK3i4jxz+7xZlFMisFy4owG+XqwsSo6wZP7dNNhAo841idD1dm9JTwwzwvVrzs4XfA+rLkBf2dIJ/C1BLAeha1ml8JwbIPe9wImGhZCMa2YJRWqj/dKnJpYxh+UmBfdka1REcDMdr9sKID/psgphG0+Ocd/vH67O/I66rVrbr7Wks4IEfItLREuwxXkl8gCFtiIe1NsWhh+xKGG3qte25UhlRNujkBue3hMsM6niV3P+0LXF6Cu9YjwgmTT01KXr2aNPDeFaFhD48k6191qRkAkYRKP9THZFLSntxj6FjinA7SpoL405mBvCNI1Ql0aDXPlGr6fGX3WYM+LEqz7MenUMvXZBYuHeUje0eTEROlsvsyCGCyZMOvJxBM7uSJTokpQAjwLf3B8cyrddZu1z4evIehET5uZ3IVfnxsT5GhPXqr8Ila4qMCIOU3ByqsUGekmrDcbsXdg1N748TrkaNj9jFMri2/Gr8yBQZQmhBK6Zu4DPLf917eXyPltxmKdbWxfrJcnuaQjeJJS6h9th089gXHjVAKfONmpBtmd1UUoqGV7CCYtekzg0wMrHLfCa2D8/Obs5qH3Nec3YnS2aPRvo00ZXEO6zvJNBiNQlBZbhoTCTk3OGeLX0SDQyIJTD6A3iKjZf17lkh26sbeLyn3DS/HbxGndDk6RaxjGf738rdzbi3318mJJMgCAfkogyxdmGAKu2NNZvwM= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 15:35:13.9017 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0101MB1032 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 15:35:18 -0000 On 17 Jul 2017, at 16:25, Yoav Nir wrote: > ISTM that this is a great argument *against* allowing the > administrators in the data center to be able to access the plaintext. The joke is that obviating crypto by going around is something bad guys can and will do, sorry for being unclear! Intranet administrators must have visibility into the traffic traversing their intranets in order to be able to maintain, troubleshoot, and secure those intranets. This often includes TLS-encrypted traffic, too. ----------------------------------- Roland Dobbins From nobody Mon Jul 17 09:32:52 2017 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 61E12131CB2 for ; Mon, 17 Jul 2017 09:32: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cem.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3Yl1aVOLQVf for ; Mon, 17 Jul 2017 09:32:43 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 373A0131CAA for ; Mon, 17 Jul 2017 09:32:43 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 35so54813588uax.3 for ; Mon, 17 Jul 2017 09:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t+v3QtdKv7OF+U8UEZVrqWEd0kFNQWsZDF7ov8sTuf0=; b=FrMamC1f/ZOcDwxuGCLEHECGJJnbzsoJxKfg/IhK+uv60LeOcbYi/3t38U2AOQ6Uwt wP4ushCleh6+xTyjptkHkUytZ9j5Dk+hLjIQGk7F0L+Kamd4rRuDp1aKTu4ayp0nnnNJ t5arYoAN8tzmLzezhlra9xycQWrEdTNLup2IU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t+v3QtdKv7OF+U8UEZVrqWEd0kFNQWsZDF7ov8sTuf0=; b=kRlwK4oiIxJ0+xoUotboomhoWZXKljFYHPZDNWydZSt6eLcVA0O0xKZRZLssshCeaA EvUVJYSGf3ALCLcelMKWX6C5W5xRaTAzAMtjUKyG6obtYajUxRAl2W+6By4dum2yh/qj 68AGg/+yXdodSwXSUwm6AUeyIbZ2AtInOheXo4vGUXkBKRKyeEaK1MByXmXRvmKE6yoH Qa9EkGNRJmC+B4qGQ81Ey1cNMlX2vWO+gJpuSxz1xzs1/M7bxv0DtQkcH1zBQaSOt9BQ /ou4fPOvLhg6o79zbu81AJqt5cSZUQOyWGplCDo/nTFLdC2H4u/s30kTYdNMQU3R5DMX v7ow== X-Gm-Message-State: AIVw111Q8QpI4dV7c6BULefhSYST476uSBvFr9RlY63dNzWCPD5vvvPq x89LutugjZWx1eon+Sy7xDIKIyLWsdi4zhYIxQ== X-Received: by 10.176.91.134 with SMTP id y6mr8784570uae.76.1500309162063; Mon, 17 Jul 2017 09:32:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.174 with HTTP; Mon, 17 Jul 2017 09:32:41 -0700 (PDT) X-Originating-IP: [172.8.175.41] In-Reply-To: <637C97B3-DA63-4F61-8EB5-D938136D520C@arbor.net> References: <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> <637C97B3-DA63-4F61-8EB5-D938136D520C@arbor.net> From: Carl Mehner Date: Mon, 17 Jul 2017 11:32:41 -0500 Message-ID: To: Roland Dobbins Cc: Russ Housley , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 16:32:45 -0000 On Mon, Jul 17, 2017 at 10:32 AM, Roland Dobbins wrote: > On 17 Jul 2017, at 16:52, Carl Mehner wrote: > >> Do you have an example of where malware would be on your intranet where >> using this >> draft would help you? > > > Sure - detecting attempted additional compromise and lateral movement > utilizing exploits within TLS-encrypted traffic. Why is the malware setting up servers that have been explicitly configured to use this draft and communicate with your enterprise static key server? An common used example is metasploit, this sets up its own keys and servers for communication and exploitation, another is powershell empire, which sets up its own listeners rather than using existing servers for intranet cross node communication. > Another is detecting (and subsequent blocking of) the download of malware by > intranet users. Why not just use an endpoint solution and delete the malware from your servers? Endpoint agents seem the best place architecturally for this issue. > Detecting data exfiltration is also a common use of this technique in > intranet environments. Exfiltration sounds like something done on the path towards the Internet, where a proxy would site terminating TLS. DLP solutions currently exist that take care of this requirement without needing this draft. > I understand what you're saying; but, conversely, isn't it in the interests > of all of us working within this WG to help define practicable solutions > that network operators can use on their own intranets to troubleshoot and > ensure the security of those networks without requiring iatrogenic measures? I don't think it's the WG's job to define network architecture. There are ways to change the network that allow the necessary troubleshooting. This goes back to Rich's question of is TLS 1.3 going to be mandated within 5 years. If not, then you have 5 years to pivot on architectural designs and deployed software to gain the same ends by different means. > Does that make more sense? I agree that seeing the presence of superencryption is valuable. >> I recently analyzed some malware that was sending encrypted traffic >> back and forth nested inside TLS. But we didn't need to open up the >> TLS stream to know that it was malware. > > > Understood - you were able to user some other mechanism, like traffic > analysis or an endpoint mechanism, to determine the the presence of this > particular malware, yes? yes > Unfortunately, this isn't always going to be the case, in many circumstances > and contexts. > >> it wouldn't have even helped determine that the crypto was doubled. > Was the malware in question using countersurveillance/obfuscation techniques > that made it more difficult to infer the presence of the additional layer of > encryption? nope, it was reaching out to a malicious site. That's why it's a bad example. From nobody Mon Jul 17 09:35:18 2017 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 7B127131CB9 for ; Mon, 17 Jul 2017 09:35:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 knOFe44UGKOp for ; Mon, 17 Jul 2017 09:35:15 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 9CC9C131CA3 for ; Mon, 17 Jul 2017 09:35:15 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HGW7I7005506; Mon, 17 Jul 2017 17:35:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=FsPH9arT9YgOimnixtpQASIE2hBzJWgDp1T9eQ32cnY=; b=nk8CTO/JM9pFAAb2fjAvPCSdav6SqLpPaV9WSMSNwSe9LpLQvbJwsv4ROSWbded6yeBy G3fqA4oyPghsfkjQ2JoYcMyBJCQwmQMwpEMN+hBE3BSFMGxJgrFeEdGc0NyynU7Z17c+ MLXx/rn+22FZHUtBtqs5BB/CCk/PVZT52/kp4IeDyMrwt2FR7qdBQEzNg0i8YCm3tVQb wkOd8m/5X7FX4Jea1f6nyn4uwViJjh4Ix+v1SAsjuGW5Is5U376YAOv2T9UrK5D5xwvS YgtPMzuyR3FsQSfI5yGPl6M4bxcOFDoM9MxinY29T8QvVibVsg8dLO+V4i/KYznBXh2W ZQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2bqaarrtev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 17:35:11 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HGUgx7012983; Mon, 17 Jul 2017 12:35:10 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bqecvef89-1; Mon, 17 Jul 2017 12:35:09 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 2937B20107; Mon, 17 Jul 2017 10:35:09 -0600 (MDT) To: Yoav Nir , Roland Dobbins Cc: "tls@ietf.org" , Matthew Green References: <87o9smrzxh.fsf@fifthhorseman.net> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> <52C47C57-DFCB-4378-8C7C-6D8A5AFF3075@arbor.net> <09C9DBF3-75F3-4B59-8522-7ED0D0BA3AD5@gmail.com> From: Benjamin Kaduk Message-ID: <8013b86e-fbaf-cbd2-8680-fae37b71ec39@akamai.com> Date: Mon, 17 Jul 2017 11:35:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <09C9DBF3-75F3-4B59-8522-7ED0D0BA3AD5@gmail.com> Content-Type: multipart/alternative; boundary="------------35BD30273F55EAF089D55F3D" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170265 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170265 Archived-At: Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2017 16:35:17 -0000 This is a multi-part message in MIME format. --------------35BD30273F55EAF089D55F3D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/17/2017 10:18 AM, Yoav Nir wrote: >> On 17 Jul 2017, at 17:06, Roland Dobbins wrote: >> >> On 16 Jul 2017, at 11:19, Salz, Rich wrote: >> >>> The key point here is Within the enterprise. >> +1 > It’s an illusion that inside the enterprise uses different technologies than outside the enterprise. IP was for outside, and yet it’s all over the inside. > > In the end, either this is in OpenSSL (perhaps plus a patch) or it’s not. Either it’s in SChannel or it’s not. Either F5 have it or they don’t. > > If it’s not, it will be impossible to deploy in the enterprise network. They’re not all going to implement it themselves. And if it is, then it’s on the open Internet, and then at least some people will have it turned on. The border between the enterprise and the non-enterprise is pretty blurry. > Right, and that's the core motivation for a lot of the fierce resistance this draft is experiencing. Fundamentally, we are here talking about things at the Internet Engineering Task Force. We have an Internet threat model, partially manifested in things like RFC 7624 but largely just latent institutional knowledge, that includes a hostile network. We know that Internet protocols get used in Intranets as well, but that is not the main use case for our work, and only a small portion of the scenarios that we must consider when designing Internet protocols. On at least many Enterprise Intranets, the threat model is different from the one we generally use for designing Internet protocols, so there is an impedance mismatch between what features are desired or seen as problematic on the Intranet and the Internet. Because the risks/disadvantages of the current proposal, when applied to the Internet as a whole, are so large, there is a lot of pushback, and a desire to provide strong assurances that any proposal in this space does not leak from the Intranet onto the Internet, both at a protocol level and a implementation level. If there was a scheme that cryptographically required input from both TLS client and server in order to enable the needed "key exfiltration" (or equivalent) for the Intranet use case, that seems like it would resolve most of the concerns being raised. Unfortunately, it seems really hard to come up with something like that, when there are so many options that are unilateral for the server. This is not just a question of "we promise we'll only use it on the Intranet" because of the reasons Yoav states above -- even though I assume that everyone participating in this thread is acting in good faith, once the capability is in popular software packages, it could easily be enabled accidentally on the Internet, or coercively required of certain entities, e.g., by national security letter, once enablement is just a configuration setting (as opposed to writing code). So, in order to have something that is verifiably opt-in by both parties, it seems like it would have to be a ClientHello/ServerHello extension (included in the transcript for the generated traffic keys) where both sides commit that they are willing to exfiltrate keys to a given named entity(ies) (whether that's by raw public key, certificate name, etc., is quite flexible). Because of the key schedule (the traffic keys are produced after that point in the handshake), it seems like such a scheme would require encrypting DH private values to the third party (and potentially a PSK as well). I'm curious whether a non-handwavy writeup of such a scheme would get a better reception than draft-green-tls-static-dh-in-tls13 is getting. It does lose forward secrecy for the traffic in question, but such traffic is clearly marked, and rotating the third-party key sufficiently often could regain some forward secrecy properties. (Of course I'm also interested in hearing if that is not feasible for the Enterprise case since I don't understand those requirements very well.) But it seems that we're not really getting anywhere just arguing about the current proposal (and repeating ourselves a lot), and proposing concrete alternatives (that do not require rearchitecting the enterprise networks) might be a way to make progress. (It's still unclear whether such a scheme would be acceptable as a WG item or Standards-Track, of course.) -Ben --------------35BD30273F55EAF089D55F3D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/17/2017 10:18 AM, Yoav Nir wrote:

      

        
On 17 Jul 2017, at 17:06, Roland Dobbins <rdobbins@arbor.net> wrote:

On 16 Jul 2017, at 11:19, Salz, Rich wrote:



        

          
The key point here is Within the enterprise.


        

        
+1


      

      
It’s an illusion that inside the enterprise uses different technologies than outside the enterprise. IP was for outside, and yet it’s all over the inside.

In the end, either this is in OpenSSL (perhaps plus a patch) or it’s not. Either it’s in SChannel or it’s not. Either F5 have it or they don’t.

If it’s not, it will be impossible to deploy in the enterprise network. They’re not all going to implement it themselves. And if it is, then it’s on the open Internet, and then at least some people will have it turned on. The border between the enterprise and the non-enterprise is pretty blurry.



    

    

    Right, and that's the core motivation for a lot of the fierce
    resistance this draft is experiencing.

    

    Fundamentally, we are here talking about things at the Internet
    Engineering Task Force.  We have an Internet threat model, partially
    manifested in things like RFC 7624 but largely just latent
    institutional knowledge, that includes a hostile network.  We know
    that Internet protocols get used in Intranets as well, but that is
    not the main use case for our work, and only a small portion of the
    scenarios that we must consider when designing Internet protocols. 
    On at least many Enterprise Intranets, the threat model is different
    from the one we generally use for designing Internet protocols, so
    there is an impedance mismatch between what features are desired or
    seen as problematic on the Intranet and the Internet.

    

    Because the risks/disadvantages of the current proposal, when
    applied to the Internet as a whole, are so large, there is a lot of
    pushback, and a desire to provide strong assurances that any
    proposal in this space does not leak from the Intranet onto the
    Internet, both at a protocol level and a implementation level.  If
    there was a scheme that cryptographically required input from both
    TLS client and server in order to enable the needed "key
    exfiltration" (or equivalent) for the Intranet use case, that seems
    like it would resolve most of the concerns being raised. 
    Unfortunately, it seems really hard to come up with something like
    that, when there are so many options that are unilateral for the
    server.

    

    This is not just a question of "we promise we'll only use it on the
    Intranet" because of the reasons Yoav states above -- even though I
    assume that everyone participating in this thread is acting in good
    faith, once the capability is in popular software packages, it could
    easily be enabled accidentally on the Internet, or coercively
    required of certain entities, e.g., by national security letter,
    once enablement is just a configuration setting (as opposed to
    writing code).

    

    So, in order to have something that is verifiably opt-in by both
    parties, it seems like it would have to be a ClientHello/ServerHello
    extension (included in the transcript for the generated traffic
    keys) where both sides commit that they are willing to exfiltrate
    keys to a given named entity(ies) (whether that's by raw public key,
    certificate name, etc., is quite flexible).  Because of the key
    schedule (the traffic keys are produced after that point in the
    handshake), it seems like such a scheme would require encrypting DH
    private values to the third party (and potentially a PSK as well).

    

    I'm curious whether a non-handwavy writeup of such a scheme would
    get a better reception than draft-green-tls-static-dh-in-tls13 is
    getting.  It does lose forward secrecy for the traffic in question,
    but such traffic is clearly marked, and rotating the third-party key
    sufficiently often could regain some forward secrecy properties. 
    (Of course I'm also interested in hearing if that is not feasible
    for the Enterprise case since I don't understand those requirements
    very well.)  But it seems that we're not really getting anywhere
    just arguing about the current proposal (and repeating ourselves a
    lot), and proposing concrete alternatives (that do not require
    rearchitecting the enterprise networks) might be a way to make
    progress.

    

    (It's still unclear whether such a scheme would be acceptable as a
    WG item or Standards-Track, of course.)

    

    -Ben

  


--------------35BD30273F55EAF089D55F3D--


From nobody Mon Jul 17 09:39:29 2017
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 C6FEA131B33 for ; Mon, 17 Jul 2017 09:39:27 -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, HTML_MESSAGE=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=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 EPLBY4nfR8qj for ; Mon, 17 Jul 2017 09:39:26 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 8EAB3131A88 for ; Mon, 17 Jul 2017 09:39:26 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HGb1rU016408; Mon, 17 Jul 2017 17:39:21 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : from : to : cc : references : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=8vyDAEqT++ADChJUvQB1o4kGhExNuQciHy+EIeDBCP4=; b=HhPiT4WeTWNItjra5aesvYtPfjO9KDrfuK1FCrYM2lF2t1tzq0M42XOV9+e5dO+zEK1e GXypBhBg+mkNGkeHDmmeYD9gyIJIG2gvHWEM1oOFviGDbdNlK6poFdyuyvZW5y0/i9M0 0CSaiqlwAH3f0XjsG6O4AZQkk/L/mXg+qheyf/3HhpOr7uO08WqnqERxwaAGZ5o3NzF5 /e1vZLP1fPgufa/eA7BiI7gF49af1c5uzeITxEDAHQ6Au2bDWd3WdcAFGYp1EHY5hfBP /Mknv0JLe5HAAPsEIDH+flkM1hqQhpFLeS4fUsYtUfR+w6KQt3zJRYIrLS1h7HYFWQ8M xw== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bq84d9000-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 17:39:20 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HGZnp2022497; Mon, 17 Jul 2017 12:39:19 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecun0am-1; Mon, 17 Jul 2017 12:39:19 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 8BFC11FC73; Mon, 17 Jul 2017 16:39:19 +0000 (GMT)
From: Benjamin Kaduk 
To: Yoav Nir , Roland Dobbins 
Cc: "tls@ietf.org" , Matthew Green 
References:  <87o9smrzxh.fsf@fifthhorseman.net>  <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>  <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie>  <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com>     <52C47C57-DFCB-4378-8C7C-6D8A5AFF3075@arbor.net> <09C9DBF3-75F3-4B59-8522-7ED0D0BA3AD5@gmail.com> <8013b86e-fbaf-cbd2-8680-fae37b71ec39@akamai.com>
Message-ID: <8123085b-897f-7455-ca4b-383087c73171@akamai.com>
Date: Mon, 17 Jul 2017 11:39:19 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <8013b86e-fbaf-cbd2-8680-fae37b71ec39@akamai.com>
Content-Type: multipart/alternative; boundary="------------FDE339784AA0ED9C8F0E0D42"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170266
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170266
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 16:39:28 -0000

This is a multi-part message in MIME format.
--------------FDE339784AA0ED9C8F0E0D42
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/17/2017 11:35 AM, Benjamin Kaduk wrote:
>
> So, in order to have something that is verifiably opt-in by both
> parties, it seems like it would have to be a ClientHello/ServerHello
> extension (included in the transcript for the generated traffic keys)
> where both sides commit that they are willing to exfiltrate keys to a
> given named entity(ies) (whether that's by raw public key, certificate
> name, etc., is quite flexible).  Because of the key schedule (the
> traffic keys are produced after that point in the handshake), it seems
> like such a scheme would require encrypting DH private values to the
> third party (and potentially a PSK as well).

Whoops, a little too hand-wavy, since only one DH private value is
needed to generate the shared secret.  But it's "easy" to have some
crypto that requires both contributions, especially if you are willing
to modify the key schedule for the traffic keys.

-Ben

--------------FDE339784AA0ED9C8F0E0D42
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 07/17/2017 11:35 AM, Benjamin Kaduk wrote:

    

      
      

      So, in order to have something that is verifiably opt-in by both
      parties, it seems like it would have to be a
      ClientHello/ServerHello extension (included in the transcript for
      the generated traffic keys) where both sides commit that they are
      willing to exfiltrate keys to a given named entity(ies) (whether
      that's by raw public key, certificate name, etc., is quite
      flexible).  Because of the key schedule (the traffic keys are
      produced after that point in the handshake), it seems like such a
      scheme would require encrypting DH private values to the third
      party (and potentially a PSK as well).

    

    

    Whoops, a little too hand-wavy, since only one DH private value is
    needed to generate the shared secret.  But it's "easy" to have some
    crypto that requires both contributions, especially if you are
    willing to modify the key schedule for the traffic keys.

    

    -Ben

  


--------------FDE339784AA0ED9C8F0E0D42--


From nobody Mon Jul 17 09:40:46 2017
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 3CDFA131CA3 for ; Mon, 17 Jul 2017 09:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 I8tD0ei3cuEF for ; Mon, 17 Jul 2017 09:40:43 -0700 (PDT)
Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (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 774C2131C70 for ; Mon, 17 Jul 2017 09:40:43 -0700 (PDT)
Received: from [91.183.52.43] (helo=[192.168.1.189]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1dX94b-0005cf-EK for tls@ietf.org; Mon, 17 Jul 2017 18:40:41 +0200
To: "tls@ietf.org" 
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>        <637C97B3-DA63-4F61-8EB5-D938136D520C@arbor.net>
From: Simon Friedberger 
Message-ID: 
Date: Mon, 17 Jul 2017 18:40:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <637C97B3-DA63-4F61-8EB5-D938136D520C@arbor.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 16:40:45 -0000

On 17/07/17 17:32, Roland Dobbins wrote:
> Sure - detecting attempted additional compromise and lateral movement
> utilizing exploits within TLS-encrypted traffic.
This is about decrypting traffic inside your network.


> Another is detecting (and subsequent blocking of) the download of
> malware by intranet users.
>
> Detecting data exfiltration is also a common use of this technique in
> intranet environments.
This is about decrypting traffic that goes outside of your network.


I'm not sure the same considerations should apply to both those situations.


From nobody Mon Jul 17 09:45:28 2017
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 21A1D131B4E for ; Mon, 17 Jul 2017 09:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 TsWqZNtLq5JW for ; Mon, 17 Jul 2017 09:45:25 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0127.outbound.protection.outlook.com [104.47.32.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6829B131B33 for ; Mon, 17 Jul 2017 09:45:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0QTvgAcprkmixI/sQiXQEqkfoh7Dp0aOSufQKIGmabc=; b=g0Gr/MIDbBMJVL99Kx9FH8C+q5wXxC9lDZqNA/vVfjomMh5DCD8npbnqtqVhcYynVuZZN4NznlqZwB4jQT0jjOYkBFnl9jTkUsBfFGfR2de4MLIi3Bks3mDRyjjUjcRzAxsE6op9YMSHk72ZSLsbFJ7ue2A4s2UJnReJeUIC88Q=
Authentication-Results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by DM2PR0101MB1038.prod.exchangelabs.com (2a01:111:e400:3c19::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 16:45:23 +0000
From: "Roland Dobbins" 
To: "Benjamin Kaduk" 
Cc: "Yoav Nir" , "tls@ietf.org" , "Matthew Green" 
Date: Mon, 17 Jul 2017 18:45:11 +0200
Message-ID: <92CF1858-7589-457B-BD1A-C9F22B7FDB0A@arbor.net>
In-Reply-To: <8013b86e-fbaf-cbd2-8680-fae37b71ec39@akamai.com>
References:  <87o9smrzxh.fsf@fifthhorseman.net>  <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>  <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie>  <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com>     <52C47C57-DFCB-4378-8C7C-6D8A5AFF3075@arbor.net> <09C9DBF3-75F3-4B59-8522-7ED0D0BA3AD5@gmail.com> <8013b86e-fbaf-cbd2-8680-fae37b71ec39@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: VI1PR0802CA0028.eurprd08.prod.outlook.com (2603:10a6:800:a9::14) To DM2PR0101MB1038.prod.exchangelabs.com (2a01:111:e400:3c19::27)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 83a52ae2-bc11-4a10-d4e4-08d4cd33387d
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1038; 
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 3:zEeE/TDZCX/EXgE6P62STjsGXWNr+OVPTecAH0iTmunJfFZMmf1q59Bs0o3Qb0WlEMvdvWFAyvaqp+cgeBhDj7BKKdK/+W6elUXzU/IWPwAyNbTmekYCsRbRjOvIFRBO90E91QnvHageGN40MWwsbXAVKF18Uk1KZ1q+O6DVcw30yv7dVTW7Fp3gdTUWQdDy1gxq1JsATNw7e7Q0OZHi7Lp85cfW4165uMabqjYal7pr5iACy6CE08PnWOOfZY64sKWTgXEFGodxiqsDgKC16Pfv5YVFxdEFsjm6GcxPBfQzk73hWbblEmDiZM+7dn1xcO5BAKkZcjLjYpBQ4Sjm7V5lT0CpNEPac1vTelsYbrv+SRi/jWqNtYmMB/y1fhLwX0pEKpr0VWYioPbYByJI7E4otz/x28ngKf0XDEHq2/TdyCQp1/9ZhCOx6fWVECjCJsvoqbx/CLTUIGLWzyz8Xc6QLA15Mqi9Ne9At/eAgjXHROcUjci3w2/h3cox6FY4gNcLXLTZ734ZpLROG7WwMZ2b6IFZyJiKg0oDYlSR4vHhoB1yXGlWVXEBsjQhy35KzNp69ckY2ebgmaLAAhgg57g9is2iKfbW1RzElu1vQEeQteaChzjJc52esSPmtJa6Znu2Nxe8LFx8czFRwywHfJfq41/yFh3DJic0xao6y4vZ6jPZlF1gunspdrbs2WXsCy0zEqZmDvonsqElSbwkL4OErLN7JIEPEmO6DzyyeNg=
X-MS-TrafficTypeDiagnostic: DM2PR0101MB1038:
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 25:/ZEV+wBsNV1hEotdB65IGcQT3HZCXgL9palSOL2IQMe6fgerI3bwlPShVxTeOHVm/hZmPqtaoSxPn5Hq/A59Q5af2pUkG/RX+7T/FT3f5qycrQHszl5DP2+DVsZAxb0pN7ov0BvpPYTSsXSM6/CioFt5wdEvK3sGhMe5wcekHXQr/6hShyy+if/ErRGV6sDkrSRs2d8rFxumzdW5/m8VIWVM+Em1DCOIYt2HOXXQJJELaRmEw67HBwWT9F6/SVwL586U5GtnvorHZGjFVFcGuw7rMkx8VcDQQo85ZUbwiBiLe8zSWb71RxDGGi4EJU80p7j4YkrsYIKVw5jfHfXxsIgb9qUymE0kt5nPEHoP68xLrCGZYnoK5igGCgSP9uy6usZZLy4vOa2y81jSmtqwSN8prFzzji7ii6hD4Ka+eQyiFO+FxojMeEkX1jH6yFN1PB1hONnlkTu3GQ/hweIiYyVGVmx67de6vqByG7EdC9ZM60lFvVXdB6dNs3WX4MgAeyRTw6otaWk8cDx445Yy7ra26m1MuEBpTg0bp39d6Sa6LcIy7yhZUcQ54DN82frwqouymrkGrQXVl41XgNV5ngT5IvvT8NzZczKFxalfqEAp+iXWheoQhAvP9U051gr9Na5FqpC8tBi0spLMysWDQ2cluz9hDKaTI9WFGJGUSgSLB94StX7c2+ZqDoDxGAU3fJ/nQhAwW6UUYTry2u1tozP/UzpTEjopY357zd64ZjrQG8EnFEfPZJg/7rSwUzsjtnhzeB1ZWe0ZlF9fvXjA4ru1qs80nTEc3k1O3PAuV8eANQuLCsXOFb8x92hLA2T2QTad2/q570rmFcqakOdbH6FkXWQ+rmZ1hBR8a5DH9FDUPMn+6FTUwAAkcGhzMBaEfFOmwnN34znr8TyQffM5KOfykRgIXvWnvQtVX2Lof+I=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 31:akpNGdmEiKzcSFk58PGsKozRdk3aYFQthvp1CmN42HYfLAA9jLpTGS3+qYX0iMyb/aeeRos3OSyr5vHm6wj7+vH8xcTF2ePfhmBHJFMkBrNeanILSkS4T5+KlE2lwk3td8IiW2khtsiid2oFBJ8fVhH84jCkqxW5fnAEO/Oo4P2RXHvCrqKzj7h4ayhxkUiSiLNK1dSHqibpQdZ1mRMiRm2Awdzgxfwe9j1/gL98opKlnp/GEHbZZDCZajeCWRcKY/WV8j0iLZlyDTVMQ7whdiIufo4XsVJSocEcwlkREbFf2k1hg+wloVrf0zsYDmmHVJhGLKvwJo5n+0+uX1DlydfZiE9Eknpck19vXCBBnB/nR6/7buwYC1/Zwx3R4tk1qOdMQNqvXIzBH7p6LAY/Wc0G2E8kK+0CN1TATzh83GP+4OfRgR+2LznwjIEnRojzo8hH+Noip/kMAaG+udYVBA0cuSk51xpy4/x7RAESxQnNyb0AvkxksOgrGAwxWsQ1GyNlGl41AXI7YT57H1t8+cKwnC6rRaPloG55CFwaijJhz6D/SIt9v2DNSbiuD/L1UwAiGkD8aV2Kb96K3CcdA5W/CaA+MBUVKnYIwp+98TXIgfHZaSvTlutU4zgeqd7mpho4w2ZsulzqG38FP2Vti3OtXM3uLuFYVw8j8NqapJFCDEJ/BDP0xCEfBortwgmPqhykPec+9S5P3tYpebKTbQ==
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 20:c7Q1qMtWYgdUaFKEH46ubZbjL4pE5Mte0Aigc1PAMCYLN/BquxTCSVyEN7as1d6u1Dl+dKJmo0/6x4amt1VmMWDeEIVQrIhmhnjEQ6cwQezmVImBmXTVpWqO7NPbR3AaweVYxlcCAxXP8izbWoKzFt9hNd7xcEs7kEi3jwQht4TAYNEeBkGwvEv9XaP8nlLpTNPtjx4Bchs0Uer4nDL+XWos93f24xGf5t8yMePn1rMmEfyVDXf7drNXPACseCvuIoGIbLE8DO5LFznPp1HCOakG9MUbP6NIbDbX+WwgdGLcydpzqkJCOoe0xUrvjnqPA9P0zWpK8V/CpZa7SkuzEwK3FRaHtZQEAKWwNcIs4jpdJ/24AoqvKrbBY0uF2n0AAjZ1Ty8svtQP26xjL+I3iYVZzu2WEfDm429yQxkvsLQCV2PNSzzScdgUODhPOCf21GPysnoQthlQjDGKnEC3n6iNafz9vYlF1jdvK0SXZ+KqUj6F7e9QSu75vE3zEvtr
X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(192374486261705);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1038; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1038; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1038; 4:DV30OZhqQIg0weVyShvkZJNT7E3DTifOQylRcveb?= =?us-ascii?Q?mwrKZVoYKIz3JqEo33vEifxXfsax8EeYcMrEc64TF2HT5znlrbIAwlHk52a+?= =?us-ascii?Q?QN+TBNpon/O+SnIL1BnlpE37M0vGwtf6WryBazkxdodQRG6G0AlsXN7ozlRA?= =?us-ascii?Q?Zm/MYZaiiIW7oDJiWRt5LwvzPo9MVb6MasQy4UVbC8RODhZASnZrUx4C3oqK?= =?us-ascii?Q?9ZzYvf3uLhxGhlAVot8Wvt6HSWXvAJ6I62NzSi638KvTM4KUowV6uYrmgnTs?= =?us-ascii?Q?eO2bs+ECQTXLqpo/H6TVIky1zr9zCv9J8KjSxW+GPEevX6rcrVlahUkmAlMG?= =?us-ascii?Q?9LcOQLy7TX3amCQ3xOUFB2Ev0X+7BQQiUy7o4fnkgI9Otsifdbe5iQEfexZd?= =?us-ascii?Q?NTlqS+f7cZCQ4C0tVzkHLdKeUEncpkKvOrbOfdwq2D4DCCo2xXU9LcKk35MS?= =?us-ascii?Q?9sriyHLNDXmUkHihG3glCm2eWMNVxnTtH5Lw+EdB8cEPW8Zd9KraVtglqhSm?= =?us-ascii?Q?8DZoVUklkXIiEFClDEzaY8R8jgkj48xQVcstUR/io/jV3PkT8wRSHCcIvWFn?= =?us-ascii?Q?Dj5zcSKw52oQx0mBwLWH8fcn8n9VF7YSlUt8ZP5/PfTELvUl2f8wmOLoOtaX?= =?us-ascii?Q?xEy1O17PTIaD84EH2ZXYbSb8CS6NuOou3I2BPspDQCm9vOZ52bciZyrN8Omt?= =?us-ascii?Q?KqPjd5gO/O8zdy6DpjtCQstKI8Ol0zL/RIQVKwDki5Jh2iMjLn7YU/z9zJjg?= =?us-ascii?Q?U+LSY/66fMHOSMYo5WynfmlUrYRxTFSzZHJqKInZahCuK+2Yj3ULvg/GLabE?= =?us-ascii?Q?xrqfQD3z0cil8fzZpYNKEWrxkRsgDYfhZOUanxQArjFVyx2k0kL/Cb1DxKun?= =?us-ascii?Q?nhLOpdt3JKMfiqv37Dpb/Jtt1WdhSAOmh/+RGWr+Ca+MQA9PCatUOyUxCfNV?= =?us-ascii?Q?N0aNsEGGScaUH2rrxBWrDK+KRFB7OXHJR5rCMome6jgoazq/G+5MZw8t6jFp?= =?us-ascii?Q?sGN6PZpJdc4ZjiPDYkAey2CBwKNseWyGCZir6e/nH8J04kKOIed0/zyHp2UU?= =?us-ascii?Q?MTFfWW3oZuePxavWuN1xxAb6cQ+7yA6TX0QEcTBy8JYjuPCmoLcUZsH8oo8O?= =?us-ascii?Q?z9lSaMrCgyQqOMXldnhx37leKQs3m/9ZGsyUuld0mE9U+wB6icbDaK4cOlgd?= =?us-ascii?Q?ybAUl5glGZ7KPyscJ1qeNsUblRAd1eXm8ymga1rJzfrMlP4WHRTMFOM0PNxJ?= =?us-ascii?Q?PKFR/WdpolnfgVEx2N8=3D?=
X-Forefront-PRVS: 0371762FE7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(24454002)(77096006)(6486002)(54906002)(8676002)(229853002)(478600001)(6116002)(50986999)(53546010)(76176999)(3846002)(81166006)(38730400002)(110136004)(6246003)(42186005)(36756003)(6916009)(2950100002)(6666003)(33656002)(5003940100001)(93886004)(50226002)(53936002)(5660300001)(66066001)(2906002)(83716003)(189998001)(4326008)(7350300001)(47776003)(230783001)(50466002)(82746002)(86362001)(7736002)(25786009)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1038; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1038; 23:J6jK6GPdYdNlpMSS46WIaSm+knjfl/7TGK/OhVe?= =?us-ascii?Q?f5wreaJhP+7nomshJbediRdBUyF5Zr+CkOVvaUbJXtg9/zJXjK/JHohtRA0D?= =?us-ascii?Q?kVvACEn6ugr8NWIFeOX61t9JemPJLlwn7Orlb9oRLheoMxK4YY+UTSWhVJFw?= =?us-ascii?Q?ZLxCGLQRUrhzhvCvX/2z8f998Ldlqe6Bj06q71TM8URc/mp7Kiz23+DzxhtA?= =?us-ascii?Q?vKRaq9JMcgoYMizRH46QW/DH5wlfHFj/gVYGCNvQ2qbEeL+dneGY8RTiJR9u?= =?us-ascii?Q?y1rIoUU+x4hOSYbJR+P8b8vSlFKU2BafnxJgfoTV75MRf1VklxQGcVhxhMpU?= =?us-ascii?Q?rpdfMBqimvfQY7aQKm5qjRpsk27iGq7pkHO6QexzF26W2lbq2vL37Qyq6IYq?= =?us-ascii?Q?U9pNDZE2V5vcrUbNLLnGjuHurh/8oToyXSiQO5x0jarnMzGbboM8YW+6vytq?= =?us-ascii?Q?aw4tCleOpj7ElS9TnOcQFn2qzhFYYFzPwnjUMkw3U/0fIxfr7YP3ypLs+FjX?= =?us-ascii?Q?hMuFRhdESL2C6tHmy+2vTUXtKkfdzef0eTllJc7gwV99CkqIrPIr/9WhX1Yw?= =?us-ascii?Q?Mp0b+FPGWMYdFyLhKZkF53HZtD+E3uoj7BKwFCjduOnr8Ptx+9SpQkq2NapH?= =?us-ascii?Q?YymzM8T9p/fAUDzLn1uNM7k/BN+8ptWL1Dsz6VH00kmfnKj262AXNU/DuHkG?= =?us-ascii?Q?lvl2M97szCGPPEnpjOWiij8gzK0oB/Y564WDxsTFU71f/tB2JWklupBVwbd2?= =?us-ascii?Q?5dZB/W1rOKelFltB/e2pQvcs0y4Y7vfhFQERo/ypAR1k69PfWHgVBKsZL1v/?= =?us-ascii?Q?4PQHpm6pB00orj/V6PcDdtV2iQT+8yjhkYOuT+rvoAaDT5XrBpulkmj3Cfv6?= =?us-ascii?Q?ZsEEvwWRpPpOniVfI15z7yy1W9lV8Q/QC4Vwrd2sG4KJJ1HMwJ631fXWeVi2?= =?us-ascii?Q?gLg5NcpNL8Y/Bq2v9o20t1jA3HPVnxuLrrUsFXrVyiLdPZ2Uh5rE8U4+4DaI?= =?us-ascii?Q?cTxlzbrUrVHw8Jyn33gZNMWNNga+5M2ztBpIAbalCpKlw/0TqOkRy1KV5/En?= =?us-ascii?Q?iRQKz4gOOCFAV9wDDm0Z4+WcydJIE3tZks6ThQZXAljoJG9eqVhXy7VnATmH?= =?us-ascii?Q?W3xAM0V6pfwYYlIJPBGh/9Pb4IELq9AOrAgjBTkrZBwauN6gnCu82vbOh/5c?= =?us-ascii?Q?IhC2eoddcm/bO+YDuOj6pHJHVAYIy/qqvJxLF0mPJ27EfnDRYTTesOkFLwWY?= =?us-ascii?Q?VLTuZ0WzAMvH58RzkfA4=3D?=
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1038; 6:NHwUXLAjdIxZIAoAN3C3pzotyHWiDUqHfbDTvtGu?= =?us-ascii?Q?SMGvKhFfqfE4f0wvDXiD2QhSYPHjPvESzI6RyzOinyPoDalbKEoG8hj+eg6f?= =?us-ascii?Q?A+nwPauXyJJprr2RpMld86Gon+jZFD2f1HHB8U8dHIVBIoYDHMAHwaYWo2kY?= =?us-ascii?Q?n/xZUeISpA8RivowYQ3NP9p2gfSOHfBMjLD0u/LZtWkP1xdWK11NsTMYomfz?= =?us-ascii?Q?8F/7aYgX2wMb+eRVLS0HuxT9YBAFBBOjYjDOX7XjWYH8qoiCr+xhdWgNxAE1?= =?us-ascii?Q?Y9BYQWabBvdVsCQ1XiXFlLnVarY4UcIN6nD3giJfsqrizwN+2r3YTYC/fpVj?= =?us-ascii?Q?HXMX0cIE4nM5g7rujVMFQt5XEdU4HVLjC631TPPaDVt6yYJqtPpPN9cTbLlh?= =?us-ascii?Q?rsxuz2X8CQnie9eHGdoreSjWNKjR0VP9+H/Vp938Zc5QsevtB2fAUJ+L1RCs?= =?us-ascii?Q?cD1+L9c9dF9lIQmtpSBmMu7gf/c/RLdaE8D83aFHlJKCNm+WUQ2gUJSjPtjq?= =?us-ascii?Q?97pMjXq/xmGw1fQhufVyU+vimA1yCMc2CbyG7/XX/DuLhbtaVLoxcNfNohvy?= =?us-ascii?Q?uvqIg6el9RRHNJfH0bwafYBAdRsgsvnkXrcWLyKmWqtVucULgtG90GcNdmr9?= =?us-ascii?Q?n5RlTPJohNrIAYM/Jf/9EixUpc9aDJJbxh/FjBxy0GRRC6pwPEEh491n4yQQ?= =?us-ascii?Q?aPICzdKn3aIoYnlG8DoVt+/vaq7O9e2MR6sKNvVvmrIYUK47HLmIC0wclANY?= =?us-ascii?Q?4ZNPCgozbTMLnS8ZZ+KkxIJ+y9J4bi/Y+GtL0HnvqqE0UOISWJV6aF7L2OYg?= =?us-ascii?Q?sMVlBIP0DhliZxB2B66dXdFpKelCx2b/NH6ANOL0YBYB54w0o/CUDqCCrd9l?= =?us-ascii?Q?qqR3EQsmQHzmfsvKaJzVBggo26d41xL3s4zUJDWCewN0uZfX6mPMrZt5K70c?= =?us-ascii?Q?CMt333IVsUlKwra8Cs08+9vfe6OQfzO355WzRfaB5IW/GiZPGwmlTNCfdYxp?= =?us-ascii?Q?jM4=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 5:LKFdLMAUcG3m/ygkyXgCeBOsaxVs/P2C4QI9T8aYIIV6rILugtMgnYati+esraB84jVgqqG0vws+r6/WAJltFgSGp/3xPuJcTmWJDVHzdITBXYNSa3dRDU4QhA3UmIXuzHntCTz5StmuV9xjgcEyTDT/CskVOj5j4VGYkbFJDfoM7mrxkIO8+yz0UgHBwpAX+9nTvJnRjHnCdxzZTyDzGs2cUEQLFQTeUdLRly9O/1lSRswC4G7E38WgLUQdoWf20X6lYbDtIPJun56cVuA9358XprIYhl1ZAK/woOesncqD/EHIHJqyZSfvMkwfXAHGNFExAkEO7J2g0CqPrpq3aku1use/Vt9RGnlUrYWmvYtRydjpRGXr5ElaFZKtC+8Q9Zfi1lymonhnTfIHXI5mZzxikVDC/DIgcI3nHMm4qQ75QMS4IEXopSZz6c4Y3M9FU4zwaOy6nAJ4wfFBipOKWQNwpW+EuDPXCHQ/zB1FhW2dgpuoMo9A7mphXKCMNaJ5; 24:j/VEKXgjjN4HlDfMl+66Mf/+wkYfLrHduNPlRd5Q0UUkO/wu6W8WuD4fbc/FTXZJ0xMrCxZ2orZChdDA4oezwyhijBFbA0r9QF19RpdAZtk=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 7:YD5bufZwAUCwYOEheDJIPIUnMPN7J6/PfhnvaUsB1jyM9ctRvg3ubzh6M2F56qrrra4vpq2bwphKQJ4t+/9MOk/AAreP4UU3oYyZI06FXJZIK8D71Iz35tvjW8LAsO9qqFzNsCZ3qrEgZXpnQAVBO7v4lWJknb++PyFCKGdvZLDSh0FIhif2F6d4DbstfPXYg9OSYYBlnZ5ddIuwTH7Wo93CeMMAnV5F/kfT0OCqhm6JxU7MQ9r+GqW2rStn++JhxnRUFKfnBBaWliZ7ftDbH8Ch2RQqfbZepm3O86dWrlIAGAoAd8h8wLF94xVDeUiuyPINugvy39HV+hoXja+OhsmfryB9JUlRES+YIFGG8zNkjCtSYvAzHTakDNCngHzx0dm5+PA1pR2Iuj28gPiGTIUCacp4gzBACQVFw3JQV/7LMooRxZsVX0YSjxV2mLQ1c+z+ottc0Yzs7b5IeCiq1PfXCCHSIvJIadkPhzmFG+2d3zx7Iz/SJd2ZDdo4FkxMktwQfvmP6jq+Ofz8Ielm72wJQOtFcHq3O0EUvitTvt/O/ur9/Ts66j6tkZtbtcfdYkgVrJofXM2j0HeHCB4UO4wKyecrZ5tlPfb8j2pklNvRmPAqKh8X8oDsx+fGhSZf6BdfOKWfKSClyzdkrLgzSr5e7qzlsu5/+rI9jutzS33YUAwf8QZVguhqLg3FXMTkPmR1TR0suqWYHnCQNw1X1ylZsf6bh4HOGBssp+L1D/m9zJ/0VouglbamTaNKdEdTzvb8lAVI7ViJ8mrdmGhJQuUIRNFUrQ3ia5nlkeas624=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 16:45:23.1491 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1038
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 16:45:27 -0000

On 17 Jul 2017, at 18:35, Benjamin Kaduk wrote:


> it could easily be enabled accidentally on the Internet, or coercively 
> required
> of certain entities, e.g., by national security letter, once 
> enablement
> is just a configuration setting (as opposed to writing code)

Yes, concur.

> So, in order to have something that is verifiably opt-in by both
> parties, it seems like it would have to be a ClientHello/ServerHello
> extension (included in the transcript for the generated traffic keys)
> where both sides commit that they are willing to exfiltrate keys to a
> given named entity(ies) (whether that's by raw public key, certificate
> name, etc., is quite flexible).

I agree that the extension approach is something which is worthy of 
exploration.

-----------------------------------
Roland Dobbins 


From nobody Mon Jul 17 09:48:44 2017
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 D2F2A131C57 for ; Mon, 17 Jul 2017 09:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 A_Ps_veUZgtH for ; Mon, 17 Jul 2017 09:48:41 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03CB131C1F for ; Mon, 17 Jul 2017 09:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UshRogoDwUIxGyjr5nhH8e6305KrpLFLSBWDe6gh/ow=; b=WLBvq5L+OBdTE4BPqsimgvLugQC1Pe8O8R02FgtOYbNJ1wkKX81edz6ONtBKq9iL21TuE+yXU+Ywgj2zIHp3hAlpSa1uLtyfeiB6YvLe/Dg4750ruUtqHhCmsXNmJJITZzaZu3Lkk58n8SKIDcZ6tjFOaXQ0h/ny/fXxHVK9x0w=
Authentication-Results: a-oben.org; dkim=none (message not signed) header.d=none;a-oben.org; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 16:48:39 +0000
From: "Roland Dobbins" 
To: "Simon Friedberger" 
Cc: "tls@ietf.org" 
Date: Mon, 17 Jul 2017 18:48:22 +0200
Message-ID: <64A2BAB5-5EAC-4608-9BF4-856CA0859042@arbor.net>
In-Reply-To: 
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>        <637C97B3-DA63-4F61-8EB5-D938136D520C@arbor.net> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: HE1P195CA0020.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::30) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 1e239e28-6e89-46af-cb5a-08d4cd33ad69
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; 
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:A5rkVjN57iblSpwaQ9olYnKsls3qQ0+3jNhIFJnq1uDI6Ai2LJEQGhxf8hPuu3p0RCq6sUpD8yNK4zmcUlt5QmbLZun3xWqB0AmkLQTWH6PXdRYtTlXF+oRoRm9lelopFrGF+Q73hZs6TqqlomBUdKnNOHcBnv9wfqJuReCN6qofHLwvoyqDF9Q5S39uyJyVmeL5p0RY+fyVb2nc36ixlDjBOjVsWwWl1kvPqmU/vTPJLLEu9d9chCZ6kf1jrEVdjy68z3l1A52U6qehFqdSS38KVWO0l2XQxuGNH5V7lvp8F3OSYs1HBqLsyPQyUmy3eyZcsND3aFYV7D7rs4zKcjgc0qsFhuQYAAwcUzQu5T3eXXsE7CLpi45i2SMnNzPFHJAIK2sUOZE8la27UImRJJZJnaZFx1+7NwI7OEGF3/VUeZNpFWdBaeS0gahs27mWDcnC5m46EocmfartOA9u3ztQW9FFz6gedayUOXIZntmD5mQgz3zII9LthEF3Bj8/TW6NNMz+OFMVdVV3JLRYHfx9zGPg/A6fFF1JEUPDhcpAP1vA2339+j+ynkkPamuQF12yA6UG/3x47ZhqJDqPHCNxyZFV2wJeFoCkE+yFII8WFDyHDECG+gve2npdsqYeEJIWkJkRnD8MOXDIH5s+8UA0a1mvCYHQ/x7HNxffLeMN2pVTtfSv7NM7uABTAo68fDCrlHUkEAdyYeJy2cbybSBxHL2/ayDVvXrLD4WQ610=
X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039:
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 25:iC37XT85hhTFhDDb9xrO84r7q2Ne/V9Xrhyh6WomSeYlu7mS1xdof4xkIAswJKjVQRpu7vthJggj/opOzQfrEr3j/MZhcKG0JvGxnH3qioBrY4UvVDsBRG0XqayIFkowUV2oIBtDJ48/41Ds6aXJI3I27k9sctqfbX7ed/GDkJ4W+/PBjqoUDJcvU0jgFSgRLs+p5jV9YQUmUOxwZHe1G9NUaOWDnaKCxspkDeaPC83zIYG4pyM1cpjrIRwEihBn0eEdTq4hHCewKJgs7oK/2HxkJ5CoadiNxwu8rRJ/p5ZUPyaZfZgscgU/Ck9wn3i8xb8sPqgPts0AZC4agurZJvy+wJgqEqdyQXNWd7abdoJQ1Iuka7nYlhpN1qUnxXqcS19GrGmoDF9d+QYXteSPuI4aLeAx+ui8ZdJ0Lk8lcHyFoYoOFHGCLrm6n5uAOGKGXGGK/E6uX6S2ezjeCZPb7QLl0db4J3dEC2JFGU0dStkE6oFGG33FPg1I7EgB11wiOLUyEVbI19YRhVfGIVknKjxWGbedmuVJBMi7gMiWi7za3xynvjSYE/tPX9gsp8NpKQsRrKcoR3J+BgnJjwCL0dMZRFh7pl8wfyyk5WBwXT29j5Klt0TbN6gf9VHpDQMUXXQQC7fk/I/yvm4XSaMMsRDZ4P/FCGLQhj96DomgsmfOl/6gpDpgBSEdLto5P8yCgoyt/Gh+3lB6kZ2wGtyhr6mTvSNjNqgzqgrhcZ9yOPC2Q/UFP3Czp5w2zMIeHqlg+GC1uYTFEBe7ah/jPzE5pS+5TB6seLrFO658k9vdUD8YRIqq/eeWTAic0iWrCfBmUApF/1A5YvrUWK/ijaYCgdk2kweNKHaVHNLxXt4ivPcelznQEaDcbWsMXbI0DAXKJBYztLZXRxotgWonoNPzTZupvNyr5Ps6tTvn4HM5ne8=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 31:+P17pEnjR8fpLM0zT4rloWJtigSmtW7CzhpXh1PvBSQeZUBycL8gtIzTQzTIElzLYtYEeFE3jdX8z/cIXiY6HhficTnLPDodZUvMvugyVi/L8vhA8eGlfHOyV7qE6qt64S6KO1mblQFji6Y6J603J9K7RQsUEtHO0V6/qWjeii9dVEsPKYwUYdgkWfTSuBa7IVaFxTeA6qvYNzfPkoJ5I4OFQ6UN5q//SAPFIlUX5SlSJj6jc57CenCYRWXI2r24ZvkwaMWXwAI/xatmK+cBTtH3JpNn0smN5P+XnANkuSzFJPoYYbvpsyFUk+DgUj63ChXsGRJnkG48AyXhecvMyU3lobyM3mAkWpRaS9/1y3e0iPuuYef4ImNSZLTAsRRr2Pl6/doCjZSgsAqdI/uU5zOARmL34B7VC/WXM39Wdz2BHXVBAZZzDcxJ1DDDM6fnHMok7QziYaGctndb9eRygQ+JwaO2xstGX8Pwd8ynjYvxlxAwUPBJ9nebpFTg55cIr40WePfHOk4g0Aw+shtvqh6zfjLdYwRakZHAySEpiyHg2+kyufVfkcFwO6APxYcU5J3UlAn5X2WgM/SZZyy7FxYtG0dlhg7pIQQXpyMjy6suvRR0gDcQnx8Dxb2aBwg1lfEJzHgfN8OQ0Ihsvw9kEc92qWc0rsYnvkAbpNu7VzE7CyiJJgzJp31AxJFOkoO8PQ2T/w5FxEyI+ckh9cuwzg==
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:s+ZogLerRyX9wnxpGIlPIqov406Lvds5SqpRJEQ0oKsdXonVC+moAqd08jmOWer1fwvO9hS7b8RF+roJbp62QyFwa6yFq4+IwwEr2w3iniM7aN7bgE7IsqLK0dK2ez4XUMbTdYbvDuQilOTQ4eyq4DFPsR7AAYMBzhi44lbPJHCNeVSVSI7HgUrn99QTIYK238ZzGRlUHXm4GnFKtAojwMjyJIDMWnIOYMElG4FIIOH5c96R4tI2jqnx55VJmN+BUHPrsxo3e/VT4RFVqM+sb8385Kz379UVwNm+NCR12pcfLLS7MBoWdE0SoD3FFqmb0Wy7JG2JSkMAq1JkBRN+eKMdhtXJYggDnnak23Z1u5XEUPl4uaw8rMNietK/wAt5684Lpdymr3fHNjTcOtAvAgVEBzFuF+Sk0lppN39zEXroXV00aty5MNTOXvxDaP2huztGIQaUAeGL9h2i9HqNY+s6RiqG4/m2H1M+SaRrkGYrcUE3Vv7kmdaaKh4gjPpU
X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(48057245064654);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 4:JI2x8Jhjkx4KJ/2WNaFrUrrG6/Fdn4F319R+JOwD?= =?us-ascii?Q?KkXil0F2sPMOmPwM19f98zvAhPpLekBb4/gqZrusLgGOvqC4m7yzd+YBB4r3?= =?us-ascii?Q?wb0dp94jJ1/+ogJTLNUuXayFB2t5Uk2ed0okWtoAiBSvJgTw0UNL0aRT8nxE?= =?us-ascii?Q?Z++aAQu0vHbKmwCCsk6FH3NPYfqXaVLfkYnP3e5PFbO3WFNyqMWb4wu02N60?= =?us-ascii?Q?GeBvPtjVIJ+jM1RO/0bN3PFVrefBDRr9/dKI7774shkkyGMcvltIZDnrJwPn?= =?us-ascii?Q?WbBgL3SuqdttjJSrGgy4DO1gLt5ccMuhr8oT9WZ7ko+F7HvOWgxWcq7iC3vY?= =?us-ascii?Q?sVR4zDjBDDSEYM+T0MBVedX4R/PXDMuc1eLf1FH06tgFA6ah5Wg0BU3kZB39?= =?us-ascii?Q?scKaHWHaRIxjEvLVLp8xUUKGSHskO7Dpxb56Rz1449t3/2mHMMYXslFB3CFI?= =?us-ascii?Q?KfukTxCvZ+dqTCrmSN41T08D5eAnpWLYNWBUgMsF9DZ0j0GxF9VlvrcPArEz?= =?us-ascii?Q?hxBuO18I1RO78ha82fx+PDt2keUA88LJWUoVtmws08nqjqPZjeVcg9kvJ/7u?= =?us-ascii?Q?N1Pbgnki3FVWYr0l+DhS+GElSxLvLd4Z8c0mXYa0Xc1DWTVcXi038Ocl8GIn?= =?us-ascii?Q?wZat0O0/DYpmHGeR6LJtMWzDF4Vwl4XTGgdA4QFAun4a1efEvIGT5eFq7lnh?= =?us-ascii?Q?VgWyoSCBrM4VEuY1CrNgddGclx9kVcNw3r3C/ybIIZFAxeEXFzSki6hZnjlJ?= =?us-ascii?Q?oU41Dw9hyIGR/QQhmheHSVRKV8rNrt0Yo/3L1FotrBkac47f5XbMBD1QbLwP?= =?us-ascii?Q?+o4fPj1WL03T9JLHIBdYhzEZ1HdxjV4KX+LoTvXLiZPvCrSTHk9ftkENHUFW?= =?us-ascii?Q?oKJAP9lktr/ZdGGvbfecCnD0C6c9Ts0x5DW1c4DqUEDHoyFqpSs4x2TyqCwW?= =?us-ascii?Q?nHfC1YH/gV1K9h7/jAAxOTfoxHczTC5GSCk5bbH9GKkSdIC5WdKo+9sywHr2?= =?us-ascii?Q?LUl6djDoCiLiBuEjIDgQ14vPlzA85LXQbuY6UuO9Xy+eafG00JwVH6Jsfu01?= =?us-ascii?Q?UiPut5isiJ4f7ujzaxEO0gMO1vFthrjIi/sfwGFK+IEsz00xJJ6JS2KccfdF?= =?us-ascii?Q?QdiBFzX/jE3njDCFf7PMkjf/KMAuZWRGjjpL7q+pncGGpjVnDTUjNOmRyj27?= =?us-ascii?Q?CEvQknakxiryV1mNrS0yRCI696Qo7GSZpNmoimMVfw4iUZTnlWTuG3it7IuF?= =?us-ascii?Q?gXLJg+ltjgZqn1c6Drk=3D?=
X-Forefront-PRVS: 0371762FE7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39840400002)(39450400003)(39400400002)(39410400002)(69234005)(24454002)(53546010)(478600001)(189998001)(7736002)(8676002)(33656002)(305945005)(50466002)(2906002)(229853002)(50986999)(76176999)(77096006)(47776003)(66066001)(4326008)(53936002)(50226002)(6666003)(6486002)(2950100002)(25786009)(81166006)(6916009)(36756003)(110136004)(38730400002)(7350300001)(6246003)(86362001)(83716003)(42186005)(5003940100001)(82746002)(3846002)(5660300001)(230783001)(93886004)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:KtKpvzbL0H3U0G8m7Mqc6o405WLcgqq4vhL+9bF?= =?us-ascii?Q?De5WOYEaLgWm6QzEq1A+ge953ImLkPLZaSYZQFLFuuBC3LJ+RnghORmnxHWA?= =?us-ascii?Q?GkMcPRW6naRy4FWq7/SyiVrVDSCZ/w3R4cdBXG9eln4vi8/P+hoNX45CvSBC?= =?us-ascii?Q?AUyFsd+JmKZ00jsKhD89RgX8dhz65Gox7mbMGmBvoCbIhzVDlAJJRaJW7+mv?= =?us-ascii?Q?N8pYXLy0WG3AwE2z2apwJNyMxz0ssL9s07hF5SDDvX8VsH5sFnGqZ9ZWJiP2?= =?us-ascii?Q?5Sb0IrG8GgWDzjtPVH5cskrGe+zJus5LsZXRVcL+lJswDIHQPE6dB0xNpVZm?= =?us-ascii?Q?IuVGNzIYOmflXZ6YxBF5iB2TBGlmRxkdSDU+jHOcu84W3/DPxhwGHNIOs7jW?= =?us-ascii?Q?zUtCv3U6ItRG0OTWgQ6Xalui22wN/Hmp0iNhGO3nVImieQIpWpJIMKGwul+L?= =?us-ascii?Q?q3OOCfQBeQWBj4+JjMBqtXcgw4ohUp8b8mHpqS1G2uG+XFTO4n2aZfpBswcO?= =?us-ascii?Q?+d1GISzRq54EaPm/Qvt2cjl3H1tsrgoovgOpM8JTtZV8fEzVDunOqn5FpxRF?= =?us-ascii?Q?pbSUs6R0zvMWGP3xGQQNX87StN4b8ByucQeGnM/KKB7l4oo2Xjoo463GTA/d?= =?us-ascii?Q?zJQKsmVZ0E9B5OU7i2LMe+5eJZP7xypB8W2FXN85KxZZqKdBXGrhQ9JyI2tS?= =?us-ascii?Q?pI6R0KZ1zNdgb5FKZlF3bCxHGx7YhL6NlAzsbitKXN4ITnJX63jXdYLYSx+c?= =?us-ascii?Q?A3TyzVn8njEh/oTEpC2/7XzIiW9pBB134dFAdq82ObTBmMlxzqQyN2j+x7pe?= =?us-ascii?Q?vGWNNIVRKZlxQERMOKLaj0ipPhOLA6+QB6m2MLBXSG7CjUzShZhS75DfHyQP?= =?us-ascii?Q?GvooSAc+7x0wiqJ23cznymiFxwIHDhtlx3j4zBWDqnw3/5sMlmryn/CyG0j6?= =?us-ascii?Q?AEB3NqKL4piHObG/9GpdOL9eO380mjuliMZQyUZlClJ2wR2zzMjUb1cpBQ/y?= =?us-ascii?Q?zka4Y+u3rR6QfxwX3rs02aIO7I5fRSKUnXyQ1MvcBErwHgAYfSO6gA/xq3Xh?= =?us-ascii?Q?3wnOOgw3M0jOY8Yh5x5RecKuRRqNOGXE4Wm9cMbE0gOVgOknOY+/ZBhu0myj?= =?us-ascii?Q?QGko836ItpidZ25OzbBSeNyL2TzlhjunM93han5Zopf7nUHVpYxdEUUUiazs?= =?us-ascii?Q?vbxJhVs8xc5Q6GAe2Tz+XeqV3IdR9amIkpBP+akXHL6UrKydRyaGiNJopIA?= =?us-ascii?Q?=3D=3D?=
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 6:zeDUPRUrSBEtPh6H497y5avw8OG6knMpDIHQGltD?= =?us-ascii?Q?5TryHbgh9YW/I84A0A/dM1bH2Mmdmuyu5+Tn8EgWQw3bMq4Bey1p47vTjcBZ?= =?us-ascii?Q?DJa9OwnS3o1Sf3PweKd4aDaKScobc7FmXPYhc4bdLlmsvXl0RNiu2YuK05QO?= =?us-ascii?Q?WYbnR8lM3vuWx+xXyNbrEDMSGeJAN7ujsGg57hFt1wK2Gtu7PZPJ0nNSSGOX?= =?us-ascii?Q?7Lcn0kUT3VakmImtJAaX39QCPJS0XR3xABSf5TobS1ZszJ+mgvHc3XRXMUxu?= =?us-ascii?Q?2hs2k9AYj10UcguOFao5U58inOoqh0PL55Cn5nA9bugQA/ZLUorFl2VZBWsp?= =?us-ascii?Q?/cMpnz9GhPP0crPhAGW3y5nY7eS0cgFSZNoBdJlPFrh3MhtICkS3nAoHCZs0?= =?us-ascii?Q?zUgxO9cZCYjA+sIsPEEYAbLizGlNyzL+rx/VRSB1qkr6nxd2hhB26axN6gG7?= =?us-ascii?Q?43mLDNwhtgInJtp1MyyynNuwph9eBC6DQIIgod4xTf20uShMM1BBcQ8Iye++?= =?us-ascii?Q?VcgP5BNXfcB0zNRbUWMCgZACr+uWv+2s7bAIGsTAgrel8+l+Gs1VvHnd7m2A?= =?us-ascii?Q?ZzOdjDgPgY0C3McLnG6FIOdrSXqAlDrsXUl+Lqz17ExskrW6hBSJF6yjGBuu?= =?us-ascii?Q?F0RmTWyPMRPA9RAipft3fsfJtC0zp2Cg5vtgey5iI3YyU+90RMdB6TfE9FVc?= =?us-ascii?Q?m7zPTu8z+5wSzdy1KurOoXxoStnBufAQtoBPEtKnueGtKUZec7TRAn+YVhBY?= =?us-ascii?Q?vM5ac29QjDZjZI7/CxEyRSQY7/R4zflFCuowihG4xu+cUIuYQSCV6ETQQ47h?= =?us-ascii?Q?aI5mPuVSvgu/qrbRhrYofNXtwHM9pCbMONL5oy4+5Qgga77QpWYhPG0AW/fz?= =?us-ascii?Q?sF7jFyq+syNCdJxSWplAKsrLudXboHMJeb01jBR5nqmiHV/95937ITpFXpbc?= =?us-ascii?Q?TKx7P7ChcD5eyVanjWcVE16S9lDkhaUd6Dj53U91KhwNNalXkg/iPW+rnHAi?= =?us-ascii?Q?Trc=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 5:UvmfDIgCSerVSJRAhEN1drU9/sENbKPFHQWniEOUsFEs0TvV4g5XRL0XgJg8wzVlLjX8nyA6igBdxWgweXxXqLY8omy8rzbImjoUzYpwKe75wxOyjNLItJTTBXE8u7uxMFa0G+Dy0xruUWSYaKyWsgow16dGcWr7t0IsR66yGwSpP/dI2zkBWcx0a4yiEBDxDD1dFgiHtYRskwOiJIJlL8xfAca/tBAmpEgoWhM80oDRO+S5W2gqkjVfz7r4G/ExVFwAyY8h8kGOg0QstepE6EqlSF2TyYeQl00VxhVTltOOMEtRvBvXuHQa7NZzPQ2nK78KkYojCN0yo5pWO+BZwPGgrxwf/STKOf3I2h94Nh8HJVK4RQk5bthRyl7dYk2WC7y2WM3naQ32aGCKAgJ7r6SuDjXW47P4G0yE0QOZv1kETN9yeyxLyoJHbme3bBjQDzXyEiRciDMo+l0S/PbP48BdZr1oaQL7uvnOteFThRrkYbc7X6ydxfhs8OYy3QFy; 24:fLWl6iegPWqD30xn7J+Voqr2QEX79PSsLgeGqaxe0eXaQ/Lk8datoeEtfeEalbZ522d/GUG4C/yq//kdiLXANOV26/7AKZK9xoWfexy86t0=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 7:X9Z+33rlXiWgNM+KtnNwBNEyp8vAAx/WbAnHCHf0OBcc0TuZMzJyotvg+zx0zOJDidL4yfBoURS5rf9KcXkfeeaFKKXb4gHevSzcKdmEVHljxGZhCxvQrsfOP9TBJ3NixLtp2zKVZ2zul55pR2YTjrWatA5DwSyzBKA6vAkR88bKlGEZNXX3il9ILPlaqdBD83jgudshP0cRvUAUARGOlRyxL9MCWwsjvAZUV2ebaIhMP4uWpY2e/0IwvO7R4HY1gNtH74o7484UT8aG4vB0VK2GmlLxFaa1Fh5MRyXiEjftu5JkN0ucc7rcEDUqGdettHkD23ipPIAPossB/9bhyJVReUCFUYkzGDm6H4u+si4lcbohWx7Ajf/9R3F341M3rW90gvd0b6uJLd814xDmzXQaS2myNtpOhsNgTqAWxH6lJCJPzIluse2QacFyU85T1HpxfVcebjbYXbmjDEsesTGNrgh8ANSASb4AHUQr8NSvyFpFX2pRkRCcCNF1PlQPVaI5pLfPez4kv3FPzBK8zcOK0oSvySHU+r9wI4IgMMuOXmjuXGiCnFWGtA7YDKUxeU3qP9iqb+xULnmAHs3hW98fsFynWbr+TOUtuiQ3e2F6Cl+MCVaZOD/ziteRJuUTtxCHhFm6WykZiZZP3vw2F6GsbQdi8t1iGxJ8AUcvW9xp6EAOv4oms4H4CNr3uVlsito5Oi9/TkhJNkoA577gKmtMf1C5xWn9HSh7Q18+G4yHHbkryJ6auA8Y7EPARVeBbYS/COCP8nJDLMFrB7jzq7ETjJr/+58mctYWRdnCHPQ=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 16:48:39.4062 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 16:48:43 -0000

On 17 Jul 2017, at 18:40, Simon Friedberger wrote:

> I'm not sure the same considerations should apply to both those 
> situations.

Actually, they do, when you're on your network prior to the egress point 
- apologies for being unclear about that.

Many enterprises force all outbound user-generated traffic through 
proxies, which then inspect TLS-wrapped traffic, blocking bad traffic 
(like data exfiltration) while then opening up proxy connections for 
legitimate traffic, FYI.

Conversely, they do the same with inbound traffic in response to said 
user-generated traffic, and block things like malware downloads.

-----------------------------------
Roland Dobbins 


From nobody Mon Jul 17 09:55:20 2017
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 16525131B4E for ; Mon, 17 Jul 2017 09:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6ykaSuGbLbA2 for ; Mon, 17 Jul 2017 09:55:17 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B81131B4A for ; Mon, 17 Jul 2017 09:55:17 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id u5so20289069pgq.3 for ; Mon, 17 Jul 2017 09:55:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7WYKJILxOjJKjwmxzInHJr481xJ+ON5EAz5mei0V/Rs=; b=i5QtJzUB9yvqjQ19ChXkpO7gl3vO+sVStGMURVw0PbcNWGP6UFoxpP+naN8qji8zoR lThl3SDdXCUoJIBbr5DT8k1vSV/TIi6LrEKcPfwZ5rhQjBz2Rm0W90lhjWtTwT9eWk0O rTbE7lMq8Kv5ef18eQlGk2tIlJ22L74pTpkve8psPfTCuymno8QvzwKWd094ynUgzVTw QiVzjSGIsNDn7XAmh6pNlMKgWXA6fyWMdJo52Nxt7ssWVyfvSCkDifoYPtZagBiLNhpM u9AB+qy6RdmdXT+mjHNVbMu5H4p+oV8BaZ/jqYo9DKyFWO9MSYQ/2A5oa/E8Ud7RtjIg q1zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7WYKJILxOjJKjwmxzInHJr481xJ+ON5EAz5mei0V/Rs=; b=tF9WzeechtuTg2ztBxOWlWszezld6qffSHD/0nnoK9sFy5+Nwv3Z7xm7PiYv6MhbzB HdtvcTTtMvBoDkn0GzUiwje1lbowpX/cD58OsotolWcUJLcacd2dAt6yyZegOaYCk/iC 5dCXWVdCKqzzZQtVLus0TMADvmr9fFnuAsq9ykVG61q5dZL4HAOP+2+0ifVmgQK0T+L6 olK+dn7BcMubUXCisS6YNfeCtMwj3OwrHC4viG1f2RQZruSpFVZeclatd2LlwI2WPVjY NSX06jP1jwnYaxGvl/+mgo4C2bq23n0hEsz7bDM+Q2r/shn/KSMaBWGIMTk9I+DXbFxt tRDQ==
X-Gm-Message-State: AIVw110/AzqOBOme5+ylzfh8kl81wG2d30dHQYxc3QfTRDh5hVpBRaVx Ybc0vWOgkIF0HIqn9ju3nskt1l0d5Q==
X-Received: by 10.84.229.79 with SMTP id d15mr31879589pln.4.1500310517114; Mon, 17 Jul 2017 09:55:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Mon, 17 Jul 2017 09:55:16 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Mon, 17 Jul 2017 09:55:16 -0700 (PDT)
In-Reply-To: 
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>        <637C97B3-DA63-4F61-8EB5-D938136D520C@arbor.net>  <64A2BAB5-5EAC-4608-9BF4-856CA0859042@arbor.net>  
From: Watson Ladd 
Date: Mon, 17 Jul 2017 09:55:16 -0700
Message-ID: 
To: Roland Dobbins 
Cc: Simon Friedberger , tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c19ecb46ceb71055486437e"
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 16:55:19 -0000

--94eb2c19ecb46ceb71055486437e
Content-Type: text/plain; charset="UTF-8"

On Jul 17, 2017 9:48 AM, "Roland Dobbins"  wrote:


On 17 Jul 2017, at 18:40, Simon Friedberger wrote:

I'm not sure the same considerations should apply to both those situations.
>

Actually, they do, when you're on your network prior to the egress point -
apologies for being unclear about that.

Many enterprises force all outbound user-generated traffic through proxies,
which then inspect TLS-wrapped traffic, blocking bad traffic (like data
exfiltration) while then opening up proxy connections for legitimate
traffic, FYI.

Conversely, they do the same with inbound traffic in response to said
user-generated traffic, and block things like malware downloads.


So FS has no impact on this, correct?


-----------------------------------
Roland Dobbins 


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

--94eb2c19ecb46ceb71055486437e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Jul 17, 2017 9:48 AM, "Roland Dobbins" <rdobbins@arbor.net> wrote:


On 17 Jul 2017, at 18:40, Simon Friedberger wrote:





I'm not sure the same considerations should apply to both those situati=
ons.





Actually, they do, when you're on your network prior to the egress poin=
t - apologies for being unclear about that.



Many enterprises force all outbound user-generated traffic through proxies,=
 which then inspect TLS-wrapped traffic, blocking bad traffic (like data ex=
filtration) while then opening up proxy connections for legitimate traffic,=
 FYI.



Conversely, they do the same with inbound traffic in response to said user-=
generated traffic, and block things like malware downloads.

So FS has =
no impact on this, correct?



-----------------------------------

Roland Dobbins <=
rdobbins@arbor.net>




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c19ecb46ceb71055486437e--


From nobody Mon Jul 17 10:01:48 2017
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 0F2D7129B5B for ; Mon, 17 Jul 2017 10:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 NaCAoHEA40V7 for ; Mon, 17 Jul 2017 10:01:44 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0117.outbound.protection.outlook.com [104.47.36.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BA7131668 for ; Mon, 17 Jul 2017 10:01:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t1DfJHcDQIj+thTCHqDI2xbsk5YdSawU1uMYdcqwBy8=; b=fGjV+2geEkZk/FDj494DET90mMTl6ZeBzTR0s3I0jUzo11ACYpFa9kvQsPb12hLSjE5z6Ez8vFuMRtdUoSmIxxrx7E+feuWfTK4U9Yi1beniDJ+Nbm4JHgLBMHtUJBngSE2zFftxTeTX48h7P+a3KtjuhM/tSD1pU/HMtGEhq1c=
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by CY1PR0101MB1036.prod.exchangelabs.com (10.160.225.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 17:01:29 +0000
From: "Roland Dobbins" 
To: "Watson Ladd" 
Cc: "Simon Friedberger" , tls@ietf.org
Date: Mon, 17 Jul 2017 19:01:18 +0200
Message-ID: <88AD564A-B299-44EB-A825-D20717119AC8@arbor.net>
In-Reply-To: 
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>        <637C97B3-DA63-4F61-8EB5-D938136D520C@arbor.net>  <64A2BAB5-5EAC-4608-9BF4-856CA0859042@arbor.net>   
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: DB6PR05CA0017.eurprd05.prod.outlook.com (10.170.218.30) To CY1PR0101MB1036.prod.exchangelabs.com (10.160.225.140)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e5ea2db7-f4d6-4da1-b665-08d4cd357857
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0101MB1036; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 3:7IQT8gYLXEt1XiSiKN8cH+AvDhGMn48Nb5hqqBkkLO8UwI2JwBPd9YP6xn5HSu7yJ+WQ1LwcpFWux/0FdO5qputLi7f6Ood2oB1IeSfyYMW++eOBdb+NMDr5J9/tCsWfwpVhb/tW5cacsB3GG+ZInJcqJbqIJpOxk1OzwMDF/O02Hizb5Qtl/0Ny5qKEE25DrZR8uJSKR9Px6BQkyu94zl1f5ywi0pOL52/3iyAnsQvUWKsDcqNDcxspfmLcU/DPTpwOqlHcG5p9PlDOvkCPy/OLBF3zbF7N+gfWzWGEaVvyOfDl+Xb3eUtOGuF7pqN+EiqFe/EBj/8KMYBtXkZ4vaTn/M/PhX00aO3SA9lY/kUNUbch7JUvyU3lCmaZqI423d4UDdJsQPBb/1CqBAgydCaWXzDJLhtMSBEBJwqNDbeWf/O0xLk9oSTr/6VHfoX3wnFUyJZuDpqUs0/ejy8PVPn5qvjRe63G7FkUUvOh+S3Cgg0eiw+F9sREbMK3IMIimKdOhjwFujCkjIGvrw/M0hgIZGd4ubicK89H7/nxQSq2hk7E5NSjESpRRCTxxiQ1y/6QWTLLMFrGiVfR/9eXygtW/1Q7boi1jSD67vvy8hW07Wb3eePIAUEqVQdnTyOFNaumkZ4QCiGqun1NSc3Dr9FMk8Ml70S5dE90tY3R+vjfyXBOmB7xtUqcd3gU5yZGbdoppGJJ+Gra1C9kjx++//XUMvLlDzDs4Q0JI9PnkmA=
X-MS-TrafficTypeDiagnostic: CY1PR0101MB1036:
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 25:0QpvNN+Mrwoizv26tcUBBM8szfvQ4nYfwv2hgmysSZVuJTqH0c1TfNPPtk46X5E8LU8ZjLjQlToxyyENHr+mfxJGI+a+7jDo4cJauX9F+a1lbmbl9JP5bMbZ5/KsgapvazS0j94l2FMAol51VpxLzd/NrOuNSB9sGwaiVQGWhU3AKRuuoQfo6fgFDU9PEyQHSsvEhzTPCWmRVJiR16hfTBpI7v2qlTaWDT4VJq9R36y3g4ZqKU0xRfLS8d7GAc7MnaUo5c/uo5NgtYbkcDo5VcTbKI/R5hHEPmWLIvFK7hJkcNXs0JWOtqvc9kLOO7sBPA13xgVQKQHK8DGAUeVSm6e11dUG6j4Tzv5CKSUDSJc7kyhd0Oje63ldRxeQCuFiineaSO2M4UEba8Egm6i1RwCVNo2FlMPpzRZi779jg1CMM82lJN9DuVEBhuFu5fdVXhZv689HF60B0Ctw3MgNrFaOxmboTuVGjOID4CCZu+g6VFYre4VGdcC4Sm0+IIOIPbcinZDXYJQ3bpXSoqXBwrsZWbH4JJUDVoEh+LeWaAZg65pG4rjy/GgHoh9LTwENrcXO+lQoApgXExB+Fxuq+DA5+xylQckPVlx88olxmCDb1GmUyA0706jmxIzlvdIbOvv5MnhxcIsPYLhpamVTHihzeSyucM17zQ7S648/M/a1+HHtq/5Uq/MdkcaC93wCX78gTx+Oz6xDF6XIVNgB3ZfCizfzv6Gws4OpOV6cfD+l7KmOYdPgR3UF5pmRl2rcMLvd97/ndf1jtvEtCcdhNY3gF8GWSWFooTUkMZjmIaqcBtNqH+YxDV8F7b0kXILhOzsThra1MtFnW1n/gk3/jzzo8901a/BQy+R32iKMGm0/4yA71C/eqoWOgVLpoLcQo2mm9p5ek9dhC6NHS+cIMRv7/9ZhUaBwvfMX+f9Wnr4=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 31:WZEQnoTWuhPhOePxSLGSW09nWTUOCOOUpoe+/8GpmFn/uEylP6EJJxkJD5jdcpXkaOzWks+rAWd/S13T3I6wPKNRVZyByF3GmhZHCv+yzg8T3uOSRlDShWL/ScRCvKdT6WzqqQVcUl7k+xjfhPDE5FcqH2leQzyOQYGGIVmTWbMAKq8GdG3xru5C/Ytiw+U929XA78Ov12gLX2JKWlWtQipJd+8awP6n4Hq+/vk+G8rP+nwDeDdxDx8Z/zapVwWuQphREpNISa/j9TrKO2bKpUi3Ku7yGxerVK/gznSuMK2fhkxJx8ckHRzcedtc6qC2Lg6D7nUmA2SRa+NrXSJzWn8TdVBvUvdQon9BdPL3YIsztE+g7yZKCveLvbo0/Ei7JZJhhLulkjQjbDkuc8AKVhXTWBaBHmJwH9ll3OGmqgX51344mvvsOVbuaDSMIWqkR1InD3IqgaK8Jb6GhDZRH9P5jbheX2BW2f5c3IMS+dgqKF+9voD2faMWN8Iuw3S5m+2XqbhQJTqYMjgQmekVYB4dWGFozcE2LuTfoRqB110MPZMIWEsvBt7ff+EdR2NgkaJ7Ae6BIioZA0dnrEO5g5zmbdds2OOkBXDmRsV84ARY9UAX0kiN9Ufjl01EmrhqKEX+W75003RbJsB+P9wI+wNTK8L6ZxY0EDcSL/X9+9eHiresKXZfXsuYHJXR+k4o0nkHr8k0tkCQMB6BCk+oqQ==
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 20:bM2zI93Yapmpy0JrGO8g7+vai/Ke//ycIm1twgUQNio/pQBCbvFZswCGtS/exuH1Pz1fo0N+9rwQABkP4MD0fgIvgbPs0uh/meTTgEcPWC0R2KcO81NegC2RwR6SKTNAeCQsF6QZJFhbMNDBcijYLz4oLDlZpB6MZkowyjfq9WhuScBwRvgxP+dE7fzv70dlrUrbFDQEmJD52ByuRQZDHNOqVAsWf91h+p4QREKk7Lhi1Pl9fxKyhsk/XhloR9Cr8/8ahpeRvI2QnFhY4tg+11oV3LdR6XGCz44V/h3SzN6KXM2Rq+khss6b3W94HsNfEAm9v8rx0kvYQY0LGIG7z936jmcX2INE3BnUQ0P8tEfbG3FBzkYfd0io0vaaXyyU60fGecm3lnMuNodwryFTySbQD+bEnlxIGU6xOJ6nJ/KgZ8hnYkBypoEkp5oxtBoWj9FZzm9kqGd/k2x6gIU/jtmucAejM716ycKfZ69xCWspNVKw1fgH3nOqY5zymrPY
X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(266576461109395);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0101MB1036; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0101MB1036; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1036; 4:8ZQFt5uetfqrvUmm2mRMqmsawiGFbxv00JQGRZHB?= =?us-ascii?Q?ycY7EBDvYHMzKpsxFsh87GIPHSn2Wh2IzN7DPNqLzf3GxxNF3shNxAybZXK+?= =?us-ascii?Q?v4Ox7GDuZapyP+73bR2fRiGiYMq9cg8es7w3fTY+O5Di0cH9S8lW2vSJ6nmt?= =?us-ascii?Q?PcfS/jy2bFxVL53NfcxLvwB8oKx0dYag0tHmwxSJ2QjEgJ+DUZPQ7mralSw+?= =?us-ascii?Q?l2nuuF74AqGBuiJ1EZhE9TtRhPYA1sKOyX2OpdcQc2hiJAq23e72gi/wUaXX?= =?us-ascii?Q?1aHQtF0f99GbHQ8Mat1QP9OocJZUy6yLye+GGOhjR2cDDXKwMhJ7G2jPjhD0?= =?us-ascii?Q?7KcOCnMfhfvRptzNwGkj5vzo+8PifjPF9lgS+amAC5BwNz7qqsoLIZyaRwxg?= =?us-ascii?Q?aU54NiBA+IF3deat1LvJXl1kdLTqp4xOU2pT/lHwv2XoxK4TG1DitxxsSBA8?= =?us-ascii?Q?se0oA7o1QhZgklxjBytrFNrA+VE6eKPuHGz8uQgMGXGAnOkNvdtTBkN4ZqAm?= =?us-ascii?Q?RTJMXY4srV3hvfCNctA662skdzzIYgp5ADKVrcr2YR8Z1aCqiUMQZevac5p5?= =?us-ascii?Q?CJ0D+TjEvmKptDuZFQf9P89uPrgFb2HK4thPK7QoOuzjxPlxAe7lVYMFnbu/?= =?us-ascii?Q?KOUHnMSJDWDCxPHvGzvdU9BoliOHwGkGs8NGHyRzlex8hdsPOdCr13VuP5L4?= =?us-ascii?Q?doQZTcJDtXHuxvbC7+pzRNGrwQkh8k5lyaBOKAKeH+LGTM4/EILli/HPpAet?= =?us-ascii?Q?NU4Oi/QFrRytOYNUeZtoC1U+6YMvdwCCOePggsZy0TKiS3bL/cVF7iqTXU7W?= =?us-ascii?Q?CWCXLH5G7wlggAqauDDF60Rj4jzr/mr6BZimku4BDVNje+Y61YyiAq7zQ0jn?= =?us-ascii?Q?yp2Kebqm9rzCbF0g42izdrWLbWZVAcupdDcI9WZhv6cWuMzBXQ9LxDafUbHG?= =?us-ascii?Q?n4B1Jveb46SBUAJxHDIcnmu1gmsNkir5rkobosVw8sXmxn3P+J6YtcpHpZMi?= =?us-ascii?Q?TJbjbeJErNkWr+xNvek5qwG6DkS70vYI1TY3YAzAY0sj7zneFP/EzwcEWzTz?= =?us-ascii?Q?3KuEkNubOxttJOVeNav+eYcqiQ3J74RnIMjLhSAAxVoyrWK5SXy7hkkYilSc?= =?us-ascii?Q?nHEHH91gYptPXo8PTD9SdSQQdNX96mdjroZ4UVGrIgNum8tKBWW9TwMu70ip?= =?us-ascii?Q?Hohr8zij8HR7QOLTmXD/fbB3LRcmuo4fQQkaxRvapMrisXFYt88Y2dQO1p+R?= =?us-ascii?Q?WlGRqJj/i1WgW7c0Os4=3D?=
X-Forefront-PRVS: 0371762FE7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39450400003)(39410400002)(39400400002)(39840400002)(39850400002)(24454002)(7350300001)(305945005)(6916009)(6116002)(5660300001)(3846002)(189998001)(6486002)(53936002)(77096006)(50466002)(50986999)(47776003)(76176999)(66066001)(6246003)(42186005)(478600001)(2950100002)(33656002)(86362001)(110136004)(6666003)(38730400002)(1411001)(7736002)(2906002)(93886004)(8676002)(90366009)(81166006)(50226002)(83716003)(25786009)(4326008)(230783001)(229853002)(53546010)(82746002)(36756003)(5003940100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB1036; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1036; 23:lkB54IbrBdLWmzgpLgXee3pclIGp0GWylM81PKv?= =?us-ascii?Q?MwlOUE3cw32s489vzE6hHdFQwVGZb8TZesa1WJPuRk7Z5U5AivhD6+uwO9sh?= =?us-ascii?Q?wjlAJDthyumzayjH/5mhVXRqHWnLcxNRrc+LehvrfTwZBSfjP7TuVruQZLrY?= =?us-ascii?Q?Q1rWekbI8FcHhN1Ydu0/p8rOb8qA61k9bTcXZRnJmxf8hDm2MBEhPCEhDlbJ?= =?us-ascii?Q?ef8jgr88wry8G3XUFvpEYYxoN3TmB/mSaDjI4/sDkmSfldNPEgOkPkmzjQpZ?= =?us-ascii?Q?cPfEjI+Ays7UvG732r6OCzJW3C6YzwlmKD0982/1BjJJ8QRdBLQj4Y9U/UFt?= =?us-ascii?Q?uO79+7vSIVajh/Egj/B5HBTAS6vJfsnZPAVlEbG0khpE5IaJ4w2nfsPIkaQU?= =?us-ascii?Q?6fDoDkFSruYKBmtpsIv5jzCRHJuTyznVM5esb3EgMf1DefMe+W3XhNTXnnLr?= =?us-ascii?Q?H8x6JdssysjoY1kYa04j0U8N28M5QkDomIaQLTiAzAPICOYIAKRDycoL8VkC?= =?us-ascii?Q?1GQFpjrZvBy7cPQqCo1tPydZbrtCsqU4JuxBvDjW+RUU/RMJD4PJmVn2NKEe?= =?us-ascii?Q?YtZZ86Bt09R7YJylkPkcs3cUtTg/E6Sm9rRXULylDvyn25VIwVnEfr6vq2Ye?= =?us-ascii?Q?NALWPlTtP8qKnyJGYqfDkCKv4KchBQTKHxYILPJrmpQxJ4yTzFabu027XOk2?= =?us-ascii?Q?zxbucpZrSmO1NPZji/9BwH+kqhRax2wHLcOROtWQviRWjwZ1FoaUlt4UKgih?= =?us-ascii?Q?OycUkzOmalGfjdHtgvVtvdk+FfrUTsheznRh6DR5WT0fu00UAly6mGlRc/Rk?= =?us-ascii?Q?Ngae/pP1CEU0P46jpdUJLj2T81XKnfHQ1iy2nlZx+C9vqv+m5BcXxEaLohTH?= =?us-ascii?Q?4NDMWV+AyEc92ddgyfhkAH7bDlKYXIkj5wi+75EwmQdk3cxHMpKFmgJ/2h2z?= =?us-ascii?Q?l5pfh8d5xClOMJunL73YRgQVAtQhIg2nZLAO6CbLlW2gvu150h7TzpbMejty?= =?us-ascii?Q?Y8zOCRqMfb1yiHllOS5mUQelq5J8IX9goAHPVSVQK4dgRdX7UaMO7AqvyDGN?= =?us-ascii?Q?08FJyD3RoWI9veNmzVy4FY81r7GTMMZGtGfSbNqb0We90RrQ/WF/sSM6xHFf?= =?us-ascii?Q?e71jEYwzfuh4j/7i1Ik8OeCjlX2ubwUKg/XV/JTfDBb1lBX2Bq6EE4R2lxwm?= =?us-ascii?Q?Yzo5DbOW0SNk6dYeXHzpHZTJftkGyzksRgtnSB3L5QGE7s6OXjC+C9SOlDG/?= =?us-ascii?Q?tZibuhTqZVm4/FsYdQMiQKy8yxPKun53pMSVX9+ll?=
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1036; 6:R1hgVtW9N42C+TqqR+9Q2NKUgmqgGfpuoPqCZLMs?= =?us-ascii?Q?w9v7B40m0Hx5Nj/5LYno0ZLG+fim6QHPP63ELPFKqFRLMNS61HTRFqWL3PiR?= =?us-ascii?Q?N5VQkT1AhotLkPW9vhSlWHo3IFxZ3fwKYPQZmAbMSRVafAakViEA5sCqaswD?= =?us-ascii?Q?GZ/uF3ch48A6T/NvMi2J9B2KXRijO3ylTE0ug1l/KnM5b5WUHqLDBFIIriBp?= =?us-ascii?Q?R3YGAYK24MEloX9QO1OMwDal9gLceEnGeHn1MDJRIcDo1RA5rHR53dttKWFz?= =?us-ascii?Q?LpNjjzKSbCwvEVhTgMlc7Pg4rRJmSIAvc8Fpta3w4oaEAYUlkvjwSGSJnu/L?= =?us-ascii?Q?miyIJ33CcAOonGY7xChwPJBXHAb5bDdXTSm22kKl8FlumMFH39XPYFI2NP5k?= =?us-ascii?Q?LyzaQONwabC0CmHcO2qYdO2nMsXqtpGq2T3m3Hz9WeLLVDNiBDgJzafp04vo?= =?us-ascii?Q?IfeikyJ4PjAc84NH55dKcMLVJTctJtUEh16Ak+LVd0+E9cYiRACiabCjz/TV?= =?us-ascii?Q?iboAVb1bk9ZOhmC49dsR60mcvztYKicYv19O7T9QjsjvWWACuOSx2eqZDmrA?= =?us-ascii?Q?qnyEXC/v27j7SSXQXNtRTPhCctMZxL2ecU5l5lHnIAZ3plSHXey72+3o+ko0?= =?us-ascii?Q?lew7Vy3kSQ3jfSGllbGyYhZPUJDHBfV5+I17wP3y0Zd20hipezvHlAhJZDpU?= =?us-ascii?Q?kSzVAt1fkkpMordByxBAup9YOSDWwXRP6KDXzBhLX5PmgCedAyO/m8mv1pCg?= =?us-ascii?Q?dnhznCE6z8c+miWeD0wzEid2lK4DcoOiMUN/AjWJ26oblMqwkSJM2Vo1WL5k?= =?us-ascii?Q?9Jl/a96keZ0qbvO7Svk3bernQ8/oLG53vghbqc5yJAcxMPG3bQgvvbBqNN3b?= =?us-ascii?Q?NvZiby7Oi6wHUoCin0CGZPOwuhFANM3VTxM6+wN09uXPwBMsDuZUHMCdoNfh?= =?us-ascii?Q?gA7kfgaAkLvmS04PTrynT/OeO7iWIR1HbkfsnCyfbMsT0Kxz/jXtk+Q/DDL1?= =?us-ascii?Q?nXY=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 5:KgQ/qGf5xPq0BCMm1KE3KFrHs6hQgFb28wgfzfFPsX3cE3/5YjDxN6MlholQF4QgpVT7rMgBdDX+1tcO8vLG35vHrPoqlIDLEsvS5wI74nb4SCKEjlkSjkNy5iYk1QFPbwL5F4y9LbZXomJculSPMk0eHN0SDSMSywFMTp9jMoEG+vJpbOGUKjR2SlWsgPQBBmu1f51vGNhgv6fNv1iK4P+IlA6zxduIz7/o18SrOuQWFA3wD1Num2jgMJ7Ir2ip8eVNRktHyKzmkVEGmFJqdlDYKFnQ4cdFdnCh/eiSuikGNR1bF9i1aTL+V5lTZNXsndMgYmuaJkKdL7n23mRVcHiHxCB4Hm/G0FW9vtPC/hqlnz62YZMYhc3CcPZ8L8QCKOWi8BHnXHMT+cf2FbQWO5pS/T+eQ9rvuN121Njwv6yQn+YJVkEerVWqbLYSh2ly7swNHHlcU9XF28LTTp1DBb1CeNRES9l40mVYmlbhs9O5+7bsjcTStyMMmqZIzOFQ; 24:b+i4sf9LWZldCwhg8rbrPFGF7JZFbNdDrKhIyVq0b9OJ077iP8y6bB00tyUofQZHaco6nez58LZIRX67rjx2U3KaUvjXziS3QrZps0gjjuo=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 7:alOumZIieS8wDt+T5Vd1zAUKmDh7AOuv+/Tbl+rOxTiCLrusxsDvvw5EEM+SGwJCAvHZL0lWKcQfv7Mdl2xdMwLCB1891rR6p+tINVej3BDSkHCBj4UibsVwRVlZrwSx5wgnfACWuBRO+8ILOZ5iALj/IMdxw8Y7LsMqPos9VMSLyu2BDTPUIuA/BGl/4CWKcEHAXO6io1D1ef8zAcdRcVyogHeKfZe/VW3n2im2zfirEtkID2rEK1A+SRuLjQDZ79hubDlWcTMtYCrAqcWrRMtf6R+hPci4gwYxrTHwZSbovww+jvyLeEmUxNiHlwgy6k5BVtVJfS1cIpkMAYXC9LVmabsjxuvr+ny0Ag5ERkXaPsJBxOY9aD+qxoRUbQHDzhPDAngsYnoVoofgbVtD40nO59geFUAzFdrJQMh7+XQe0df8mLcRGnTTNAZvhjI6cb9AcwGtHMEQHpmdbVqVSoRzZOe6b75Ly1D8wI27lOsNbSjSPQUsFZIpGKTxeQU74/YomDGFyEC80GOjJ8JcfSjVvInZszYJeSTWC4ktJVjAvspXOGtVbFmKJxC3hbbxB5hLUICvLyXNX4fG5VBx3pTniYn2+Uej3O1dVyauwKiQoPFqUe4BwyrwqonLADmWF0DDqtQjl4xY7GD70r4OyA/sLazglDWUib68I3b1dbuz6c+1t+wNaCF6pof4Pa4fe9ojM/SLbHMijZTvWiqO5iJOwXS1fxliC6KTJjyowTUwep10ZhEE3coie6gfSB8pJybx98ih3dgx0p3e/2pJja4jtGlE+Fr/K4zRtZcJST0=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 17:01:29.1509 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1036
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 17:01:46 -0000

On 17 Jul 2017, at 18:55, Watson Ladd wrote:

> So FS has no impact on this, correct?

It's often desirable to be able to inspect closer to the internal user 
traffic sources/destinations, as well as at the proxy.  It can greatly 
reduce the scope of traffic which is to be analyzed in any given 
investigative context (and possibly groveled through), which is a 
genuine operational concern.  So, having the ability to look at this 
traffic prior to it reaching the proxy can be valuable.

Many organizations do this, today.

-----------------------------------
Roland Dobbins 


From nobody Mon Jul 17 10:06:41 2017
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 72D6D1300CE for ; Mon, 17 Jul 2017 10:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 9E8OHAmIjET3 for ; Mon, 17 Jul 2017 10:06:39 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0123.outbound.protection.outlook.com [104.47.42.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDF7131B3E for ; Mon, 17 Jul 2017 10:06:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GRMflo5SzS0T7zrflt5iyvGwPcKdCMK/qJ4b3ar3AGo=; b=UTSDtVxwwFLK3H21/3rAkZwk+7pP8Z3dmR8CXORUiOa2ZPXo2GyxXoK8rj1xUQT8zaQZwqp+egim18DKfENrzCdStYPuq60XRvhJJ3my+8PRx8ai0S9z7I+1nkJDDbr+pdl1B6KmVP2yuf57ojWoR68jFcAcZjui3I0e8baH7cU=
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by BN3PR0101MB1026.prod.exchangelabs.com (10.160.182.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 17:06:32 +0000
From: "Roland Dobbins" 
To: "Watson Ladd" 
Cc: "Simon Friedberger" , tls@ietf.org
Date: Mon, 17 Jul 2017 19:06:21 +0200
Message-ID: <7B8FCD1C-D6F2-49E0-A88E-053CB8ABE279@arbor.net>
In-Reply-To: <88AD564A-B299-44EB-A825-D20717119AC8@arbor.net>
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>        <637C97B3-DA63-4F61-8EB5-D938136D520C@arbor.net>  <64A2BAB5-5EAC-4608-9BF4-856CA0859042@arbor.net>    <88AD564A-B299-44EB-A825-D20717119AC8@arbor.net>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: DB6PR05CA0008.eurprd05.prod.outlook.com (10.170.218.21) To BN3PR0101MB1026.prod.exchangelabs.com (10.160.182.155)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 26985b9e-d5a1-4b81-85c8-08d4cd362c9d
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0101MB1026; 
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 3:Ov5m1ExibzAS/UqpaVfgkGqBm/24tspvIYLlxojJzovVP3pSMbfK1IAiRPeDsCjX4ufY6AA15M8/SwXenxGYbzOzuqoTrq4/sJleVttUp1dXwHabCzpEt2Z93xAjkzfGOqDHeADp53OPD9WhnE6B7PfhkCY2Jwq70ffUZFZqyM7Mwj2OUdCLiYvxqLCXZ9r7sXaeMdwwV4ZDTSl96eu+MM2oiTYL2JWVbHrqywQRCJvCBRKS/K/xD0RRel92gLBwXlb0KBmIHZoWvXzj0HIEwFCsp30GKBRhCd72s3lSwymOftpAGfKHWJ3rMBbD1UREn9jProD8uRuRYQBXzVHqpPd9hQJM+Iqj57JvDKfA+P9bR35kbk88xTqlpL5sLjwb+8tmxQ8iCemUDMpcajnwdXfF/1B+B+T+kJxYBR9RMrbtQUoMwZBcw7iNUU7t9uWolDiQyINmQabRIt/Nj8Uxghith3r668W4oqeI7r/DmZawiw3zGK2HY/6Wab3S2TmpRwo7enyvn/sSoJQrLzqpFLpcBB0faDq7LstOrhX1mFJJfcBi6DMvxbqdkkhu11qCsWqxiyvfrlYoUO/6UuRpD+nc6WD3d0rRlVmnVM5xEMm+jAx8b9W3rc/5L4pzbq19mfqHw00n1Y/uwDqMUP34zBylrIkW7zkPmOoGkQO24w3fZWXU+P3Srw+nn+epEtOxPekLa98jZon8mJyLnXwWpCr8bR2t8Ng1QpvIhe9GQp4=
X-MS-TrafficTypeDiagnostic: BN3PR0101MB1026:
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 25:UHGQaeXG27Gs17xC1CYbA/a3HVxgx2xFhqQlpNXszvCJpqGrn/ANayZrS3qgAPkJix7I1TXjJymA6CfITOvWIINOg5UOADumTkwq8n2+Hg9NoeQ0dR4y967vxA+nhLx/My2G9k2HjLOjmDXSeYaI5KMTrXrcqvxDPwPwMW2CwRNMJ85IA/iqiq9duDkaGdS0VHoJZfJZ6ZKweRL9Rz0U5P/tQaTAYfW5M8XwzXZeSEhagD7fdUjAO6+emWitVfgHKzSTrQHfVqJeU2Ig3oDO+uMJw2EdRzafrfmSj5lkWcFsGSMz7HNySJk/IpqozkIQtlcpQvoFssFizUkivFIFLOqHWCQI4E0qV2+S5kqkXHtuhKSHdFlZxxGPEhyz7tZ//CSGrZLuOL/kkYpG0cMdrddzqJqAlL/GQi8AeFtvsGXg4NkejYWiLnektzatmMKkwzvcg15ikblXMoac5Gdq4BphH7HzoodzpifX4DRXwuUuAsIQ85V1FQdEDWWVn9tzz53dH1jrdAovqJMHZ0X3yGozUuEyl6ok5nQJdPzNH2gJf9kpgfD4ChrmzJgwT2pj9shNi3/c25DzHl8lSLnNTt0h1w7Ttwpv5JZPZkPIg4fi8O864tD2zc6YDnxFZTmonTAMgbMJgP3MZ1usKqEXSkZnQJVxzdXCPfBlQriNUTdXcH1Apg9ZiXrkrpcQxdCG+/lAM1CqnAx2gqGB62uzmFsecRpfbPebAIGM4kPulw5spsDwvLilGoNxuu0ckyg+mPZ5zStN0gASqbxfFST0Rysf7RlruItpoxGHyZgO/7LNqLeN7YcvG5N6cueAHGhyENXIOeC7Bznyb235zzkQcFLXNmmXy1QucsgmEz/nxTRb0RKiybtKL6AmUCB3ybK4bJutfN6E9M9Vz2sAgfcWt+NaRfiLo3nwHyHIHSuQgk0=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 31:FYN1to+1fKQ9vQoM1gdCR7bGEwAesH+EjgcRdz0zQiFaK/Gd/Xe5ej4yX9YfRTnwSm8AvzEopSI9EEexpsadz9+SJ47v90MTkrI8VTah2q0/lTvJmDv7ouC93UVn94+gnXM2yzy/fSJUmqeVSwaGnrdzafdOAeg3KsNgAYfKSwwJ/hHR8HmlzKLi5g1n5h9uyuLzCALosWYc5mYUVYaQ5D1q985OhRIvwrBS1eGqPfq+EL2OcaB7Ed6O7Aqacv3PyRkzWZUHQ3CHf0ONYmCbjAfVPUFjXjrJVfJt7XU5n6VQE0SO4eqKyWQSgcNGyJM+I2zJ2/zjzIcvy5Ecm4W4cKyfz9mxIDiJA92TvQozaE25rWICGFZQSbMUtW/rS8FAv43I819ckAOcm157IVgsI9S2aIPo/P98ZKwrOEZeWkVjY5rhl0I1i3cWoNaMu2AfBiqlhCigq3sZ9Yvjtguavng3m/JcxHxpYoj/b0K60zTipIXBi3sS/ng6OBGctZD2WD2NKw18Py2uqxfowWej/g/Xi8jCxr6gxvTSUUqEPJ9ozGL8AK3idFgBGTEJej87UdFUwEwzcupdNaKR3VJ6AWpr9DGroWQqftYsCZczW/NboAH2SHMIHYJNgpz96JsXVHVVDCoqNL1YaLVtEk6S7aLNj84XvHzoRCZfYgks3HeWnrNMc7iNdhBHVWUrKCL5
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 20:1U3+6A0hTM2z/DCXiQrXI5gkUsc9luaBCDj3BUayWXTVfdDoIsadGve4b2/Nud+tIbbyZqKqkVmfPlgYNull3RJxyxV7uOhoc6DMYNAdkS0y8VUEoNebY6e+iWOt7DpS6amTeieuGbOcEUV86IjxCxLnNFTLsa/i1dlS11veq0MsnFCFJRN455adVaHzmH6LKCwsEoA3P4a4OTnMgpOKf5yZdToI1NzZSXOo70I0M66eErpYR9yjh4AnT4E1mHBQZdF79taj6wsAvS3rRQTdiIEd6hcxnA2XCltaH8+gFqDT9NP9rjSjftVpH2E8obkod0W80kYHbS1DUA/qCBEuCN5XQCmlmuzNr1tFRkVPckCiOwKAQ7ZxC5xHpAWpJOXq+RxAoHZv4qIDYSf38zcP6+TMyOPJyxlrYzmkrQ0fxUQQKx2wQCo+qvAUMckANiQYV0Q92vGy8uv2I1cNKJtMh3DhmuFZeGn/JfdgSF+4Mp5cFzCyudd5WTkH5lA2NT4a
X-Exchange-Antispam-Report-Test: UriScan:(236129657087228);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0101MB1026; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0101MB1026; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1026; 4:1jBpMOy91lfVrIRswq2OlXHPlXmV11i8uv3DekQ7?= =?us-ascii?Q?Qg95GKqj8uApsGYETFQP4WAOEg+xhxigNQbWAVq97cyhlgZSCh8Djk9NS2mV?= =?us-ascii?Q?XwrnYDnsPbIjE73TEFWmbQlz7oXZ5Evlj311ckWsLzSKYSsAJ9B4hxnl9huc?= =?us-ascii?Q?cvE8lVHU4gOH5sKTxSyCuAgXcfVAiSXK+2beh20wJ/VYiZlFPzqRE+Au0Ti5?= =?us-ascii?Q?Qv7uTg/xR1Tw34zeK03wpEF6mVRvS+Xn5aD87UiCJRG1XauhWwfrXjygEFNq?= =?us-ascii?Q?n/jcouikAbj3HhGIB7YcYZtjix3w+/yHocR5M9YaOrMdeszYDXre4rN68JpX?= =?us-ascii?Q?SwmE3mIhGj3BDb9/OzkmCWBrrxieO8ZC6zUel7y5n+mWFProRSNL1tj5ZW2G?= =?us-ascii?Q?CkAEzhRDiTgYCdl5H7rGQVntrK4vl7WIfMlNnDoIzNc25yfKBoGkSg7Qvh6f?= =?us-ascii?Q?ZaxL+rd2+hlyM6a+GP4XP9OqoUtdrWDHcUH6/O1lE6ZiLw/mnzta8XmOfOc4?= =?us-ascii?Q?GrcfSXnjk79CEmUEUYJ+raMNZQ4Czz62ct5PlU/GiSU20/sQE19yzoz9uptq?= =?us-ascii?Q?C+vUu96JK3w/muwqQuujTef84AIepHAJ/fInsB99R08m9+cbQkWY2GeDvGPU?= =?us-ascii?Q?PezZC+WWG/oEgroxA71b5+DfhBJF0hPJ2oRll/ywQuBmfnLXX7f3A7r8jF7I?= =?us-ascii?Q?1OWOeCRblfMc8drsYz+pdXTPwjWYKLRx/CCqLWvGRo7+oX8PNFve08Xf0MD3?= =?us-ascii?Q?bRDVnbOlWHMeaCLuOd+NabFjDuiBpRZzx/EUa727aiWEfN/9esEBpwzUSSYG?= =?us-ascii?Q?UEwVNguSqjEzNFqaSWrsTUefgzJ1ZS+V9gLRXHAZi3F9KqECR0wq7rjA+IvM?= =?us-ascii?Q?BpgRIeU5K7qTo7aZUicMA6onizw4z/FIbIIEezJ+/XYYoYHbOtM+kRk9/Cdz?= =?us-ascii?Q?HxSiNkzGrjEWsV9OpQtkagc3XTYPz0DNf1dcuHm4WAOVOAebmqsBb75hh/aL?= =?us-ascii?Q?AsW862kT/9EwBG5jknVtEPSW53KE0Zu5JLiFh2aR4+WWqYSIgnZ8oFWGxLbF?= =?us-ascii?Q?bdvN8Tfo7k1KdOWF5+qTM6K8gjlcTfewKGHsJ7KmrhBmA7oc+8Dew/3ndvU8?= =?us-ascii?Q?o4LhOIHNG3euXoi8o2nlnSq/Xu9UzOnAyLlVzcQk8g6aXZPSiVDEFWwppYBz?= =?us-ascii?Q?XTV38SD3oGovii7+vAqNPh+A115oZlSdTs6o?=
X-Forefront-PRVS: 0371762FE7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39840400002)(39410400002)(39450400003)(39850400002)(39400400002)(24454002)(5660300001)(93886004)(229853002)(38730400002)(6246003)(50226002)(7736002)(478600001)(90366009)(6116002)(3846002)(2950100002)(6916009)(6666003)(53936002)(50986999)(189998001)(4326008)(25786009)(83716003)(76176999)(558084003)(53546010)(86362001)(110136004)(82746002)(77096006)(5003940100001)(66066001)(33656002)(305945005)(47776003)(50466002)(36756003)(6486002)(1411001)(2906002)(8676002)(230783001)(81166006)(42186005)(7350300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1026; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1026; 23:GMZFibmNWbQpZ/nuxABi7IFRGpeEA2hzCxLoQTi?= =?us-ascii?Q?gW0pDcfyaljaGHTNmVez50iZel1mS+BQicmQnwUmQ0F9wQ6Chw7MPT4wNwgG?= =?us-ascii?Q?UW+qvIw7gRYNzPPFNe4KegV4lfz0U+hUKe1EPNu0H6ppBALz65fqyemBZono?= =?us-ascii?Q?6R9omzZyyemTc4TDW1Mz7XL0016M15vQ1jG8jA8v9xOeI9wQ5zUpaq0j+Au9?= =?us-ascii?Q?jOC2NkDOC+6xpppIHDywjxAPJYaNs2c3mm16ozkpEbDOTsD42wDFZjCl23Rj?= =?us-ascii?Q?ZCTFoG6CfYBI4l+XNNoFTy/kQ3q56GmRrK02iEaWX3PrEBkypaKZjTlk2cnY?= =?us-ascii?Q?ecdHOcPUHR2krSjjfZMziARK1XPFy0LOH1HAPAm/7rrtZLjmTfZJWVvVotWP?= =?us-ascii?Q?GcpBXKNq75SknC/iLRFUSr1qTb2C4RQ94Ky2qGCBivf6QGB1tWv+N0a/lFR3?= =?us-ascii?Q?VdTG6fU9d2AYgukgYOBicvFl7Teod8dU0fq0PKLfoVwnI5jqZRmo5ssYGX2G?= =?us-ascii?Q?Llt4Jdb4Zccmai5tG9U9xV43agdeeHAlBWkaDY91YVo/arsl9TknZvqv7jch?= =?us-ascii?Q?Y6d5pHOyFCF8eGaJ1S6RhqfSs2W4GUr4EMfVzqY/UqqYX7JSnm1/c4wXtT81?= =?us-ascii?Q?EZGcR73F8sqb4VWRTvqB4h6R+Z5uQyy0xgznpNc3utRvZdls5Kkbf85zWQCT?= =?us-ascii?Q?oM5FIdsXoYVSnHrYb5MnnhdHcOoRQFX3V8RTdg1IPQWY3htotMTMlhKT9uA0?= =?us-ascii?Q?P1fmwQUdJAmvgyOb0Uapdu+Hd5eY5mGt9kXS9c+2QaFMhoUz2cFw5QwTGIG4?= =?us-ascii?Q?AgVvoug3jxIQt5fRiLeN//CWaEuXWE3/jD8ltFSkACAk+qcgRQHW/ZqFcPdW?= =?us-ascii?Q?ZQOpDtbGyOTIm1V1UdezTJeqOTVwc38ZnHIil/0nhgspHS8vKly6KJRIbgUJ?= =?us-ascii?Q?PmyFkeKSty44SkjLVDNeLKx2tLEntJUw8MY0fLzl0D+p3Uzi/KM382pJeBDv?= =?us-ascii?Q?gbtvt3hJOvbT0XPbAenCe8dh97Y0sQrTq24FDNJYOREV4nQqyB4MDO4KgKJG?= =?us-ascii?Q?N8DeXoXQ5IKIZD0AVO1v6ESCV12FiHqb0KgPxPOddk/tEvU4aVRH5yaz75vr?= =?us-ascii?Q?sBE8nlF3VmPwQmtu1RvGqjMUE3KvJi1XABWXTd6yhXKDAmeJB9KwABmcAgh7?= =?us-ascii?Q?UhrGsqsOXepqo0b1RDGJ5/4nKiiUFKosWeiRp5EaHurZr49HepQO1wNzLRxx?= =?us-ascii?Q?oYHs2YuZktj8/1FaWfz22M/qWq5FvlQwKZ+t4AfmGEFZTLmj4jBYnB7IniRo?= =?us-ascii?Q?HaA=3D=3D?=
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1026; 6:9SHceTGg81ZRoY/O7yz6CPbPnhq6REkYN4xDpciy?= =?us-ascii?Q?3O4dOrrFFZBz7XjT7X+UyRt1fpsgO5KtXBhp3Le8+27YHsJmetjYz9RoNexa?= =?us-ascii?Q?17k7XoSLEBANrlwIra0n0h7tufLj1K/xfUk0EWUb44FVG07NZJz2o/obf6Fn?= =?us-ascii?Q?B+tA0EqcmYf3Qr9zsRN7+7bSW3jIv6BxuYpXaEhy6U1zKUhhaJJ3uWU9q9kA?= =?us-ascii?Q?arYyf9R8pvJkTGHEiKlXlpZu62kJfGHESSUepA0edWbtsUPuU4nDa3R5ujs4?= =?us-ascii?Q?oHMydYlcV5P5mPaLHqLULhR3YQsOtDOlPK/eD2z57pxiWkowcqoziZHXvynj?= =?us-ascii?Q?5R1Nwm0YZ2HtYZgm29KPEiDMupP9/tqEJzmlB5soP9woUT8XG57d/DNP48UB?= =?us-ascii?Q?02t5zTyR2zjfwygBnmhmZgslAIJ8/pgEkxibfTmRcncIEY5SlY27EP6okOiX?= =?us-ascii?Q?n/yr5EV3dyt1HYXu/ZYkybncvBPjJVlgh7BdJd+fSoyz3OjTAFaHIwDRmOEp?= =?us-ascii?Q?s6L3v9WcBYTvJGU2JIPs++X4wOjUfqrWVwu6Cl77pwBsFshw0NeB24Zk2Y57?= =?us-ascii?Q?fZbivEt0AvxkqTeeo+J0dDSjj6SqAA6P93No5sAw8kN0n+dH2PIlmsZBt7V6?= =?us-ascii?Q?0xhr6wds8VGwkVLZYKZOkZcFUt4zjYhMaxLEtRzcyLd+SY4TSHrAf+pSDdWH?= =?us-ascii?Q?IJgfjWRjEpT79rM6aLmV89qApigTFidU84QyXiNOGIiPtPrEzHEWBs8ov6Hx?= =?us-ascii?Q?99BOpS9fR18rp5eUK+8G7ZvsmM5iOfyfL9kIcuqxAQtS5Gnl5EIvYr4Iegz+?= =?us-ascii?Q?sHqwaNJp2ciKiMngRj3Nuh0XiiYMxcw451DZqUEQjwgldVvUW9kOMOaITwZG?= =?us-ascii?Q?XruG8jf++TBjP2Bu44iDxpa4sDuRxas+eZXCH73YAJ6iF/hGNJonNb/9wx+x?= =?us-ascii?Q?M6buW2Fba0nJkHTzUTDLKW+cq1yd+al42/Zh0fz1Qp+EarPjxk75UC7CvFqc?= =?us-ascii?Q?JqE=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 5:p0C+7qLRvjcxxJlPB0tYkD8O8ZM/8AOVJE8LXu4JlUriEPgsCFbHZmQZSslkndfFM4Y4oQNIiycVRPx7OIKi7H4zFrKmRKSoZHI4uPuPkaL69plPhFZlbo77s3R6tf6hxrJzvUXES4Icue056Uq+Ajw4pe+B4qzAW7ESBznFjR3O0okN7ABvxoo0BAJT4WhxQ8oyP+HxH+AIeapBuihjhaJz9esyxqGw5R0md7Vy5wf3S6jytvJ7P9ga6dRb0uGbiyscEd5s4qqrVhFjE72UigY2xPEKhkvDft/1MBI0oMtjlFK7mZYxPn/2pAgPnBrfU7TKeRUfmot80f3Qrgsg9jNDJtpfPAPn/GCfZBCK0NyvsVWOfpOATCXVFnFTY1ANrmAUmCi0Ju1vjJ5SM76rNmvUiRmGeuJrWSL+ha2fpz9moH90ZV8FaPoB/jbIv2VM6C9ckVkHtnYtgxIe++LqnGId04VS5jbrMbKSAoSa56hHIkYIUQM6bUmBZDVhsVAW; 24:sB8gKRh+47AcmVL3k1mViTBhRalSwCe44Rnewxyl1wQ1Mal+Ed1YCiq8iLGRdJNV3DenL1pm4JoSVnj5m+0LZ4ha6spjdDI9n3xqjwbnW9w=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 7:cy1tiNUfed3rAOYsJjXLD7l1XsR8P7ZO+y14s/JUmfAI2lAIcgts2LWtMXYJ6Ttpk6c6/cmF2dTJN2z6hA8D1h0Tl9Q2YYY2DVCLr6CQ9/jMih9mf9ZQoni4vxnWatYBC9lAQhetzb59VgposGdpCcssUW6+QCL9ndUHZwbcvEF5h7uGpCJ592H91zA0jpHAaSBBFPGtajFZxAtMtsMerCKy+gidafeblv6Go1hutmFiHkmLCkUoH2456tTe/m9mYgSXp3YRQP4T+qGT/4hzx9fCnz2q7no8n691vXimucvMgoL+FhTW9kXjqv5kRtD/r3KU6TCDS7ULYRfs750tvbH4rePxrWR57v++iJyw90FlqAoNwIujcjzWuLYpNRc2rCIJdt8HPygwiXex556MYZhknZIaKHBnL6mq3m4s2C9DsgldOU/KEXmZMsUSZ3MVMS5cENiyPpBhMUQuMZpkGSlna2/v3J+Xe9svss/eqhoHjv1bHbYCJoIY7Usot0dgpsSVS3QK5PaXQCxE/yoHobnsGrbn8LbuZSSLUjoeAhOqRrvPjZpiW3Aa2GKus83zoS6G6ZG+yQLUO94TDTsOzdFSA75dwxadihXIlabGDUjoJozd49PYjD/gpUVTJ8KPxpwyo8tmTi1AsbHEsSejg8XD2n19evXLXHdm+WggDBtJya8jijnfe+xNaAjiq3dKv29jRpObaZ6gQ9fWxDN6eMSsR7wy2bzfEwMZx2Y5Kg0HJX2N1hygDfcq4Tt8Dt4K89eyoIyL3VIlH+wbGA2vpwKDPU4fERw1BNKBKQJfptw=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 17:06:32.0346 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1026
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 17:06:40 -0000

On 17 Jul 2017, at 19:01, Roland Dobbins wrote:

> Many organizations do this, today.

And some also go the passive-only route - I forgot to mention that.  
They'll use commercial IDS/IPS, or Snort with viewssld, et. al.

-----------------------------------
Roland Dobbins 


From nobody Mon Jul 17 10:28:13 2017
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 537501294A2 for ; Mon, 17 Jul 2017 10:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 QjXLdab4kwRq for ; Mon, 17 Jul 2017 10:28:08 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 64ECF131B1B for ; Mon, 17 Jul 2017 10:28:07 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6HHS31m039203; Mon, 17 Jul 2017 13:28:03 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Roland Dobbins 
CC: IETF TLS 
Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
Thread-Index: AQHS/vR5lF141oQzb0GeHnUlNx5L9aJYMXgAgAANgICAAAOcAIAABaaAgAABXQCAAAPqgIAAAY+AgAADO4D//8BIAIAAUI+A///jCgA=
Date: Mon, 17 Jul 2017 17:28:03 +0000
Message-ID: <31C01911-5E2B-4812-B4B5-334C7D212F22@ll.mit.edu>
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>       <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> <69018030-3157-42D4-A573-0E39E46EFAA9@arbor.net>
In-Reply-To: <69018030-3157-42D4-A573-0E39E46EFAA9@arbor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.24.0.170702
x-originating-ip: [172.26.150.37]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583142882_1919650293"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170278
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 17:28:11 -0000

--B_3583142882_1919650293
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

    > The standard definition of =E2=80=9Ctraffic analysis=E2=80=9D is deducing=20
    > information from the metadata and the patterns of communications. It=20
    > explicitly does NOT rely on knowing the content of the traffic (which=
=20
    > is assumed to be opaque).
   =20
    That's what I was trying to get across - that uncovering an unexpected=20
    layer of encryption, even without the ability to decrypt it, is very=20
    useful in a security context.    Sorry for being unclear!

You were perfectly clear. Apparently I was not clear enough explaining that=
 the likelihood of being able to determine the presence of an unexpected lay=
er of encryption is becoming increasingly slim, as all the bars (no pun inte=
nded :) keep rising.=20

Organized crime capabilities are reaching the level of nation states, ankle=
 biters reach up to where the organized crime was yesterday=E2=80=A6 Betting on ma=
lefactors to stay silly (send their traffic over TLS that complies with your=
 monitoring, doing the extra work to add super-encryption but forgetting to =
obfuscate it, etc.) is not a safe or reasonable bet. Certainly not worth it,=
 considering the risks that all the legitimate users will be subjected to by=
 this feature.

--B_3583142882_1919650293
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKSUBIdwAAAAC3lzANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE3MDQwNzE5MzYyNFoXDTIwMDQwNjE5MzYyNFow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8OK5RGbI6mDfMw/2HPG57y1TdKRaQwlj5iSXC4gDg
tv34L93tRDUTjA27kFG5HOrWar2c37RMkVX7nFR9TfGZh66CSe7Lj7ZMZ3wNyodJqptavXaV
DjSuqp6sPJGQFZNr/pIA2g/3uUOq/igeInptaYb3eDsTwt4fv4G3iLp5Z/4bd26LDJltFZnE
qOsLsQ3xfkAAaht55x+jl1QNm7+Vfe4RVeInASY7xZu9dQUJChc46p7sVcV9/exjYIkOeeG9
QB6i4CJK4vHbyF2qG+IqZfeYFjXWy3Eq7a7YrgqAl81Xs4Bpjsn9zPlFlwmHNVUBJTgShUql
kFvqKjcw0FDpAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUWa29JQeRiwuEcAGFzsv/xdyErcAw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBCDAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAIjee93wr/GEbKbqkXc5
krqRGzwcj6/NhW9rmX+MwXqm63OL+/H159UXdIQCqdd1uovIOcK8y/gXjlJOJ6ol54aixafq
sz3ozZ+eIUvphrxRVTxR8vVb17QnPxOQE0Mx9N1uRS+Hps7XgDS628KYfzxMb12+2WriuwyM
VAVl+lCBF1S4ZO/0NBx/wVyEu8Hi73kHC93/4HC1c4bwoExAAjY+twm7VBY8eTpvV/604iDf
1NdKtCb5l1fFZkyZnQ5ZDKONBehGsRGF0eWBUDCopoYTu8nbcRocvRGM+ZLFtPLh5xlpjrO2
E+CE6Bjx948aoJJCXqHf7BeKxlbazvl2RaIwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCklA
SHcAAAAAt5cwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgXN4ZwNX6uTenxe3c
jB+lQ1ORgmZsKSkl6Tg2U6jFZ8AwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE3MTcyODAyWjANBgkqhkiG9w0BAQEFAASCAQB2nWGoA+Tzfvvx5xqG
Iu1sbyDh5AplFrlqaPr/uIRNHyG0niFQxSkBzyfmev5PcBd4fuuwypExb7XCRfy7+qQqmRYq
Cu7SLIliwG1svEv1kkDVLKF0r3Q7buAEDYE1Wgp9aFxkt0UnmTfXCCWthHznGLeLSb3pMMjT
92hyAVtKbvAelAgOXbOI3GoKCDWSaZgPLWa3Scm4COBmiot2DRYZvDXSjfKTgjaKoyUpgBH6
1P7jbOtdgakMElL/pfSDYqkbcsj+KvJowtXp3JgvtS1xpdVieuiErJlHltPO5xGPnX+FluIV
n1dHCmb3/h5nSs04EnBtw1MYw9AYBXETVgW8

--B_3583142882_1919650293--


From nobody Mon Jul 17 10:37:32 2017
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 E49111289B0 for ; Mon, 17 Jul 2017 10:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 vp1xAzZISsZ2 for ; Mon, 17 Jul 2017 10:37:28 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id E3E1E131B1F for ; Mon, 17 Jul 2017 10:37:22 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6HHbLnr044341 for ; Mon, 17 Jul 2017 13:37:21 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS9u8cSScAhmTiiEWvrRLNt+JsyqJKs/sAgAkO1QCAAPElgIAAA/YAgAC+XICAABt7AIAAPk+AgAAdB4CAAEOLgIAAN5MAgAAOtwCAAANWAIAAAROAgAACPICAAADAAIAB83sAgAADN4CAABV5AIAAAs+A///Lg4A=
Date: Mon, 17 Jul 2017 17:37:20 +0000
Message-ID: <455F19E0-F002-4146-A51B-0556FD3545AA@ll.mit.edu>
References:  <87o9smrzxh.fsf@fifthhorseman.net>  <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>  <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie>  <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com>     <52C47C57-DFCB-4378-8C7C-6D8A5AFF3075@arbor.net> <09C9DBF3-75F3-4B59-8522-7ED0D0BA3AD5@gmail.com> <8013b86e-fbaf-cbd2-8680-fae37b71ec39@akamai.com> <92CF1858-7589-457B-BD1A-C9F22B7FDB0A@arbor.net>
In-Reply-To: <92CF1858-7589-457B-BD1A-C9F22B7FDB0A@arbor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.24.0.170702
x-originating-ip: [172.26.150.37]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583143440_102241079"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170281
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 17:37:31 -0000

--B_3583143440_102241079
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit

On 7/17/2017, 12:45, "TLS on behalf of Roland Dobbins"  wrote:

    On 17 Jul 2017, at 18:35, Benjamin Kaduk wrote:
    
    
    > it could easily be enabled accidentally on the Internet, or coercively 
    > required
    > of certain entities, e.g., by national security letter, once 
    > enablement
    > is just a configuration setting (as opposed to writing code)
    
    Yes, concur.
    
    > So, in order to have something that is verifiably opt-in by both
    > parties, it seems like it would have to be a ClientHello/ServerHello
    > extension (included in the transcript for the generated traffic keys)
    > where both sides commit that they are willing to exfiltrate keys to a
    > given named entity(ies) (whether that's by raw public key, certificate
    > name, etc., is quite flexible).
    
    I agree that the extension approach is something which is worthy of 
    exploration.

Great. Then we all are in agreement.
 

--B_3583143440_102241079
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKSUBIdwAAAAC3lzANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE3MDQwNzE5MzYyNFoXDTIwMDQwNjE5MzYyNFow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8OK5RGbI6mDfMw/2HPG57y1TdKRaQwlj5iSXC4gDg
tv34L93tRDUTjA27kFG5HOrWar2c37RMkVX7nFR9TfGZh66CSe7Lj7ZMZ3wNyodJqptavXaV
DjSuqp6sPJGQFZNr/pIA2g/3uUOq/igeInptaYb3eDsTwt4fv4G3iLp5Z/4bd26LDJltFZnE
qOsLsQ3xfkAAaht55x+jl1QNm7+Vfe4RVeInASY7xZu9dQUJChc46p7sVcV9/exjYIkOeeG9
QB6i4CJK4vHbyF2qG+IqZfeYFjXWy3Eq7a7YrgqAl81Xs4Bpjsn9zPlFlwmHNVUBJTgShUql
kFvqKjcw0FDpAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUWa29JQeRiwuEcAGFzsv/xdyErcAw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBCDAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAIjee93wr/GEbKbqkXc5
krqRGzwcj6/NhW9rmX+MwXqm63OL+/H159UXdIQCqdd1uovIOcK8y/gXjlJOJ6ol54aixafq
sz3ozZ+eIUvphrxRVTxR8vVb17QnPxOQE0Mx9N1uRS+Hps7XgDS628KYfzxMb12+2WriuwyM
VAVl+lCBF1S4ZO/0NBx/wVyEu8Hi73kHC93/4HC1c4bwoExAAjY+twm7VBY8eTpvV/604iDf
1NdKtCb5l1fFZkyZnQ5ZDKONBehGsRGF0eWBUDCopoYTu8nbcRocvRGM+ZLFtPLh5xlpjrO2
E+CE6Bjx948aoJJCXqHf7BeKxlbazvl2RaIwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCklA
SHcAAAAAt5cwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgUOBGr0wSS/3OqwTx
LABkw4xs4259fe3IfbUuHKGS52wwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE3MTczNzIwWjANBgkqhkiG9w0BAQEFAASCAQB/NdERilfng0Y06wnw
DdWLXLgHledhnrFn9Gs/c/sMIVAhgc1keF9G5ASZE3Pe7AT7JtaiQMfxUxwYf/1gcAb2s0fu
Yt6vGAYiryY2VV5xcgrxQBVbRoj10ijeEqbOvgDCRAUuDUDk0WIaJ9mEVVBWWz1kEXcGWU2p
A6CNyyoSJfpFIAtVDfsVRXfbWD5rjQEiKIEvHbexiOwBYFda63oEhSaDs3AhESXVYCS8cMwb
15Y5oSt4AGF86CaUePYx5hcNFCPc71m8HPEOU1WygcDyyKs/s7YPIMnIrFEkcuOx+hZWUEJj
I3oIeKiPojMwTOOANpLDPrQhSeJx85v1bwht

--B_3583143440_102241079--


From nobody Mon Jul 17 10:44:55 2017
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 DA56712F4B2 for ; Mon, 17 Jul 2017 10:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 AN_QFLS1xUxA for ; Mon, 17 Jul 2017 10:44:52 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0092.outbound.protection.outlook.com [104.47.32.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED85A131B23 for ; Mon, 17 Jul 2017 10:44:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h05dy1XWYwbtQ3Aq0wyvixNtf6tu/eV6o11c55rkkTY=; b=Jygs304O/jEIqprJLQdI52mLubxZi/Kro/ROHXsWiKsIpFYOMA3jAqkdyj0KSb5+5K/CSJAW73jL3GwOWSy3E5c8ggAOYLUNgPoLPzo8SGO3yPgGsWftshpNe0FRvrQvlIYQfC9GhhdUsAhVR7OSb1a81XrGz3IIOZyMs1tX21o=
Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 17:44:50 +0000
Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 17:44:50 +0000
From: "Dobbins, Roland" 
To: "Salz, Rich" 
CC: Kathleen Moriarty , "tls@ietf.org" , Matthew Green 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/LbQetAoAc0WMUGwvSG+0rIljKJUZVeAgAAD9wCAAL5cgIAAG3oAgAA+T4CAAB0IgIAAQ4qAgAA3lACAAA63AIAAA1UAgAAC5YCAAAgdAIACYVqA//+LpQCAACuzvA==
Date: Mon, 17 Jul 2017 17:44:50 +0000
Message-ID: <9B323105-F3A1-46B3-A581-EA26CE7F7B48@arbor.net>
References:    <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net>  <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>  <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie>  <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com>    <4F7D0238-D6AB-4A56-9036-3DB2C8576C6A@arbor.net>, <1b45a5082e71444a8042f97d7c980b69@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <1b45a5082e71444a8042f97d7c980b69@usma1ex-dag1mb1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=arbor.net;
x-originating-ip: [88.208.89.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 7:wD2fYzYjfrkvtO5QGuUDzMg/6JiCVXc3y9ynt7DkL/Sm0TQ/5GEy22QY063hcKvyLALR79qGw0NTSQbqhyOPd1/yApNamqqZmnYZTNrtTMo948BZH2i+5dWaXbzVNZepU9DEXVmt0NYmfPLXvWl28KA7HM00yUL82pOnVhgTVTWMaM2DS6zWNu/LKgiB0X/ihTnq9YwP3tSIl2w1HcJ3wkxvPtgJ3Sro/7A7RyLGP2CYQq5wDJdsCCWqVx1V1o+cCLkj226pUme8E5IWIJsqvsSjPGDLdjNQtePD7GoF6MALrPxWKC1tahT61R/NXTt23EARid2O2szhDj4clah9tFXJDLsuuuZKQz2C/zPhK9Xdwu9be+mPldwtgMh336bw5Rd1nhFassMXBWoL9xRBPF6CiZsVbG5IIOIZ6PFWPwzMkSGEnOZryHPWI6RkYfjMWDutYBngK1KcPNhiGFov8AYfmmQptMatDI/xv2OJ9iLbFIr8bqzkxTZUDFU0gkLHOFGFW9KB9ISgJU7Dqdy0zK3lgRYM0v8e90tm58KKDCF15d1G+BnH11h/149Rz72AvoYBr60lf2FQYuKq5RT/eRpT8Kez7ZcuC3qVNNG7DUHREePpO7lK43ltQSgkH0HtFs5LHb4Kt+AawXzX6Fl0IfVNseNoC/x61Bz4cO2NitRjnfYH7MZfHtZ5q8By6EVgryuzWhX85XF5Okbw8+B4OIv1oPppUFbtJju7ZUuh3cJQ/fCxrYw9mI0jIQ7oKMfLXcG0iTYmCFbkazfKuLwvc4Z08nOJdh+5UTVIPKD9Apk=
x-ms-office365-filtering-correlation-id: 7ddf103c-70ec-4cfe-2fee-08d4cd3b8643
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; 
x-ms-traffictypediagnostic: DM2PR0101MB1039:
x-exchange-antispam-report-test: UriScan:(50300203121483);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; 
x-forefront-prvs: 0371762FE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(24454002)(53546010)(558084003)(6436002)(6506006)(189998001)(7736002)(478600001)(8676002)(33656002)(2906002)(8936002)(229853002)(236005)(50986999)(76176999)(54356999)(6512007)(66066001)(99286003)(54906002)(54896002)(4326008)(53936002)(14454004)(6486002)(39060400002)(2950100002)(25786009)(81166006)(6916009)(36756003)(110136004)(38730400002)(2900100001)(6246003)(86362001)(83716003)(3280700002)(5250100002)(82746002)(5660300001)(3846002)(230783001)(3660700001)(93886004)(102836003)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_9B323105F3A146B3A581EA26CE7F7B48arbornet_"
MIME-Version: 1.0
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 17:44:50.3834 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 17:44:54 -0000

--_000_9B323105F3A146B3A581EA26CE7F7B48arbornet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTc6MDgsIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5j
b208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90ZToNCg0KTGV0J3Mgbm90IGd1ZXNzLg0K
DQpBZ3JlZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSb2xhbmQg
RG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0K

--_000_9B323105F3A146B3A581EA26CE7F7B48arbornet_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3
LCBhdCAxNzowOCwgU2FseiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1haS5j
b20iPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5MZXQncyBub3QgZ3Vlc3MuPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8YnI+DQo8ZGl2PkFncmVlZC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAy
NTUsIDApOyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9u
dC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3Jt
YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9u
dC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3Jt
YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGln
YXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFy
aWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+Um9sYW5kIERvYmJp
bnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiIHgtYXBwbGUtZGF0YS1k
ZXRlY3RvcnM9InRydWUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtdHlwZT0ibGluayIgeC1hcHBs
ZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9IjIiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PC9z
cGFuPjwvc3Bhbj48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_9B323105F3A146B3A581EA26CE7F7B48arbornet_--


From nobody Mon Jul 17 11:11:36 2017
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 A0A2A131CCD for ; Mon, 17 Jul 2017 11:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 RsXzrnYzS_ai for ; Mon, 17 Jul 2017 11:11:23 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0116.outbound.protection.outlook.com [104.47.34.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D86131CCA for ; Mon, 17 Jul 2017 11:11:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+9MvchGxV+xAW2x3lXu3PatZtHQ/v4/wyTmr7VL4BGs=; b=TzscFBprxxPu3qLZ73kyaBz8/MhidA/ETUECS+wCkrxf0/FtsfNymV8+24LsyFm15qUM5yv5NquGpoRGMqmUTG7k0frvxShzoc25pKeIh56V6rzchUBMxowtyycC1F61Hz4KGiLN53N5mQlZtIYHEYMHawbgkw4zcvD5x+l2FhU=
Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 18:11:22 +0000
Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 18:11:22 +0000
From: "Dobbins, Roland" 
To: "Blumenthal, Uri - 0553 - MITLL" 
CC: IETF TLS 
Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
Thread-Index: AQHS/vRnKFRxxE429kKncr36no97/qJX7moAgAANgG2AAAOcAIAABadKgAABXACAAAPrLoAAAY6AgAADO3aAAANXAIAAgtiA//+wwYCAAAwbxA==
Date: Mon, 17 Jul 2017 18:11:22 +0000
Message-ID: <7995AB85-5144-4ABE-993D-EB1415E7E2DD@arbor.net>
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>       <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> <69018030-3157-42D4-A573-0E39E46EFAA9@arbor.net>, <31C01911-5E2B-4812-B4B5-334C7D212F22@ll.mit.edu>
In-Reply-To: <31C01911-5E2B-4812-B4B5-334C7D212F22@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net;
x-originating-ip: [88.208.89.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 7:FYkqDWtSwfPVaPljIgE6jRLsBuaQvoCRF/L4X7k+/pcKHwIC+gjNIKphKAmWi+/MTVhEurDXXyiJSvh0SxYiR3fbWb/o8LgIPWkVAwZobEhy/ZLNTTJRKfJHA15ng7x2nFnvW35J02Xq0J3zqLtM7dGCDeg+Z3PGDllNNid+BvRZOYiZUufTfvn2mvpXFTd22we/lvnSlft0nBnyfrPouVXnrPLots+yr/BXUvi+/ncI06GYDeMPrv9uiNlubIcoEQSJ1ikqI+545VcNSXszDz9KmBGNN9fo/tQrqx70axp2EGcMtl5a/NfnxQXcZ+gmkHj47/skJnefZ8UUSfcH/ssRnyryZDEUMZyYRHWSWZHuIv1aHwzCkws6Ygu5l9hsEu2Z0RwI3oCcfbhx/PDQ5ZA54PELk01WU5CJcmocszHPNnh+kF0+8Eq5GO7ZR1bgRviNSOeiEDiMgRqFCEVPOVm/+WzA8qy5ZPtN03tPFoyCIpWCh4VbjkoH/Kw5gWeKeh80lOixojB5e1AjHS1dEmtkFKumcxddXF7hWr1DIT1xYydj6+Zlqz6lhsK3OYX0APYSy7prBx45AZ8BNyG9WFnPYUooY89oewMUyeUHD7QSaXH8sVnArbJM5FmuLQHyHyCAxLtk4GgjZHyZ+LBUR0V93n2Yyy+DLGesLXlhq7geHgq/NO0ZadHOq0KbYK1UKtlMOIEf4U98TgkjQ4wzhA6kgISEreCGYEv2dT6o+8oIrQsNhlBi7gef2ay8Lz+5OwJl85KA3hs7AFo42BPRwcwilnGI4+2Gb//aHlHvdY4=
x-ms-office365-filtering-correlation-id: c92958b2-695a-42ab-6fb7-08d4cd3f3b2b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; 
x-ms-traffictypediagnostic: DM2PR0101MB1037:
x-exchange-antispam-report-test: UriScan:(246478575198768)(236129657087228)(192374486261705)(50300203121483); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; 
x-forefront-prvs: 0371762FE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39450400003)(39400400002)(39840400002)(24454002)(2171002)(6246003)(230783001)(50986999)(5660300001)(53936002)(54356999)(76176999)(66066001)(3280700002)(99286003)(36756003)(3660700001)(93886004)(54896002)(6512007)(236005)(2950100002)(6916009)(83716003)(82746002)(14454004)(6506006)(33656002)(6486002)(4326008)(7736002)(81166006)(5250100002)(53546010)(8676002)(189998001)(102836003)(229853002)(25786009)(8936002)(86362001)(2906002)(6436002)(38730400002)(478600001)(6116002)(110136004)(3846002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_7995AB8551444ABE993DEB1415E7E2DDarbornet_"
MIME-Version: 1.0
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 18:11:22.3387 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 18:11:28 -0000

--_000_7995AB8551444ABE993DEB1415E7E2DDarbornet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTk6MjgsIEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBN
SVRMTCA8dXJpQGxsLm1pdC5lZHU8bWFpbHRvOnVyaUBsbC5taXQuZWR1Pj4gd3JvdGU6DQoNCk9y
Z2FuaXplZCBjcmltZSBjYXBhYmlsaXRpZXMgYXJlIHJlYWNoaW5nIHRoZSBsZXZlbCBvZiBuYXRp
b24gc3RhdGVzLCBhbmtsZSBiaXRlcnMgcmVhY2ggdXAgdG8gd2hlcmUgdGhlIG9yZ2FuaXplZCBj
cmltZSB3YXMgeWVzdGVyZGF54oCmDQoNCkkgdW5kZXJzdGFuZCBhbGwgdGhpcyAtIEkgaGF2ZSB0
byBkZWFsIHdpdGggaXQgZXZlcnkgZGF5LCBzbyBJIHVuZGVyc3RhbmQgd2hlcmUgeW91J3JlIGNv
bWluZyBmcm9tLg0KDQpCdXQgaXQncyBhbHNvIGltcG9ydGFudCBmb3IgdW5kZXJzdGFuZCB0aGF0
IHNlY3VyaXR5IGlzIGFkZGl0aXZlIGluIG5hdHVyZSwgbm90IGFsbCB0aGUgY3JpbWluYWxzIGFy
ZSBicmlnaHQgb3Igc29waGlzdGljYXRlZCwgJiBzbyB0aGUgZW1lcmdlbmNlIG9mIGEgZmV3IHNt
YXJ0ZXIgb25lcyBkb2Vzbid0IG1ha2UgdGhvc2UgbGVzcyBzbyBkaXNhcHBlYXIuDQoNCkluIHJl
YWxpdHksIG1vc3Qgb2YgdGhlbSBhcmUgYXdmdWwgYmx1bmRlcmVycyAtIHRoZXkgc3VjY2VlZCBi
ZWNhdXNlIHRoZSBkZWZlbmRlcnMgYXJlIHdvcnNlIGJsdW5kZXJlcnMuDQoNCkNvbnNlcXVlbnRs
eSwgdGhlcmUgaGFzbid0IGJlZW4gYW4gYWxhcm1pbmcgKGhlaCkgZHJvcG9mZiBpbiB0aGUgbmVl
ZCBmb3IgVExTIHZpc2liaWxpdHkgb24gdGhlIGludHJhbmV0IC0gcXVpdGUgdGhlIG9wcG9zaXRl
Lg0KDQpBbmQgdGhlIG5lZWQgZm9yIGl0IGlzbid0IGxpbWl0ZWQgdG8gdGhlIHNlY3VyaXR5IHNw
YWNlLiAgSXQnZCBleHRyZW1lbHkgaW1wb3J0YW50IGZvciB0cm91Ymxlc2hvb3RpbmcsIGFzIHdl
bGwuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSb2xhbmQgRG9iYmlu
cyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0K

--_000_7995AB8551444ABE993DEB1415E7E2DDarbornet_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3
LCBhdCAxOToyOCwgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMICZsdDs8YSBocmVmPSJt
YWlsdG86dXJpQGxsLm1pdC5lZHUiPnVyaUBsbC5taXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyPg0K
PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+T3JnYW5pemVkIGNy
aW1lIGNhcGFiaWxpdGllcyBhcmUgcmVhY2hpbmcgdGhlIGxldmVsIG9mIG5hdGlvbiBzdGF0ZXMs
IGFua2xlIGJpdGVycyByZWFjaCB1cCB0byB3aGVyZSB0aGUgb3JnYW5pemVkIGNyaW1lIHdhcyB5
ZXN0ZXJkYXnigKY8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjxkaXY+SSB1bmRlcnN0YW5k
IGFsbCB0aGlzIC0gSSBoYXZlIHRvIGRlYWwgd2l0aCBpdCBldmVyeSBkYXksIHNvIEkgdW5kZXJz
dGFuZCB3aGVyZSB5b3UncmUgY29taW5nIGZyb20uJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5CdXQgaXQncyBhbHNvIGltcG9ydGFudCBmb3IgdW5kZXJzdGFuZCB0aGF0IHNl
Y3VyaXR5IGlzIGFkZGl0aXZlIGluIG5hdHVyZSwgbm90IGFsbCB0aGUgY3JpbWluYWxzIGFyZSBi
cmlnaHQgb3Igc29waGlzdGljYXRlZCwgJmFtcDsgc28gdGhlIGVtZXJnZW5jZSBvZiBhIGZldyBz
bWFydGVyIG9uZXMgZG9lc24ndCBtYWtlIHRob3NlIGxlc3Mgc28gZGlzYXBwZWFyLiZuYnNwOzwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gcmVhbGl0eSwgbW9zdCBvZiB0aGVtIGFy
ZSBhd2Z1bCBibHVuZGVyZXJzIC0gdGhleSBzdWNjZWVkIGJlY2F1c2UgdGhlIGRlZmVuZGVycyBh
cmUgd29yc2UgYmx1bmRlcmVycy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
PkNvbnNlcXVlbnRseSwgdGhlcmUgaGFzbid0IGJlZW4gYW4gYWxhcm1pbmcgKGhlaCkgZHJvcG9m
ZiBpbiB0aGUgbmVlZCBmb3IgVExTIHZpc2liaWxpdHkgb24gdGhlIGludHJhbmV0IC0gcXVpdGUg
dGhlIG9wcG9zaXRlLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5kIHRo
ZSBuZWVkIGZvciBpdCBpc24ndCBsaW1pdGVkIHRvIHRoZSBzZWN1cml0eSBzcGFjZS4gJm5ic3A7
SXQnZCBleHRyZW1lbHkgaW1wb3J0YW50IGZvciB0cm91Ymxlc2hvb3RpbmcsIGFzIHdlbGwuJm5i
c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3Vu
ZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlh
bnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+LS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyIHN0eWxlPSJmb250LXZhcmlh
bnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+DQo8c3Bh
biBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFz
dC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWln
aHQ6IG5vcm1hbDsiPlJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNA
YXJib3IubmV0IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0
ZWN0b3JzLXR5cGU9ImxpbmsiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtcmVzdWx0PSIyIj5yZG9i
Ymluc0BhcmJvci5uZXQ8L2E+Jmd0Ozwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_7995AB8551444ABE993DEB1415E7E2DDarbornet_--


From nobody Mon Jul 17 11:30:16 2017
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 2688712ECB7 for ; Mon, 17 Jul 2017 11:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 BQsuRUgKpos2 for ; Mon, 17 Jul 2017 11:30:11 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id B317E12EC1D for ; Mon, 17 Jul 2017 11:30:11 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6HIUA2c028071 for ; Mon, 17 Jul 2017 14:30:10 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS9u8cSScAhmTiiEWvrRLNt+JsyqJKs/sAgAkO1QCAAPElgIAAA/YAgAC+XICAABt7AIAAPk+AgAAdB4CAAEOLgIAAN5MAgAAOtwCAAANWAIAAAuSAgAGxDQCAAAyrAIAACXyA///ZAwCAAFOrAP//9omA
Date: Mon, 17 Jul 2017 18:30:09 +0000
Message-ID: <609DCA58-706B-4AA1-AFF6-2DC1D6069BD8@ll.mit.edu>
References:    <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net>  <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>  <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie>  <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com>    <057af2f23acc450a9b896f9f0c81b06d@usma1ex-dag1mb1.msg.corp.akamai.com> <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.24.0.170702
x-originating-ip: [172.26.150.37]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583146609_428120313"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170293
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 18:30:15 -0000

--B_3583146609_428120313
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

On 7/17/2017, 11:04, "Roland Dobbins"  wrote:
    The actual concern of intranet operators is the inadvertent breakage of=
=20
    an important mechanism used for troubleshooting and security in the=20
    context of TLS-encrypted traffic on their own networks, within their ow=
n=20
    span of administrative control.

Something similar was brought up several decades ago, when some agencies ex=
pressed concerns that wide-spread availability of encryption would make nati=
onal security and law enforcement jobs impossible. Thankfully, those fears p=
roved unfounded then. They are likely to prove so now.

    > Considering that unless at least one of the end-points chooses to=20
    > comply with the =E2=80=9Crules=E2=80=9D it will not work =E2=80=93 the claim that this=20
    > measure is to help the good guys does not sound very candid.
   =20
    To clarify, this technique is for use on intranets, within a single spa=
n=20
    of administrative control.

=E2=80=9CIntranet=E2=80=9D is an administrative term, and has no technical meaning. As =
such, it has no bearing on the protocols.

Not to mention the obvious lack of enforcement mechanisms =E2=80=93 how are you g=
oing to enforce on the protocol level that =E2=80=9Cthis technique=E2=80=9D never crosse=
s the administrative domain?
   =20
    > Who is the intended target of this mechanism? What kind of criminals=20
    > is it supposed to catch/detect? Surely not the malware that penetrate=
d=20
    > your infrastructure and tries to =E2=80=9Ccall home=E2=80=9D?
   =20
    Actually, it's been used for this very purpose, quite successfully, for=
=20
    many years.  It's also used to detect and classify lateral movement and=
=20
    propagation of malware and attacks within an intranet.

You can=E2=80=99t seriously expect this method of surveillance to stay available =
forever, as the criminals get smarter and their tool chest gets enriched by =
exploits from higher-level organizations?=20

In any case, there are better mechanisms and tools to address this risk.   =
=20

    And it's used to detect and prevent malware downloads by intranet user=20
    populations.

There are better tools for that.
   =20
    > The proponents of the =E2=80=9Cbroken TLS=E2=80=9D somehow expect that  those=20
    > criminals would use weakened crypto for the convenience of the ntwork=
=20
    > police. How much sense does this make?
   =20
    In most cases, the attackers don't use any additional crypto at all. =20
    When they do, it's most often poor crypto.

You must be lucky then. Criminals that we=E2=80=99re concerned with, aren=E2=80=99t tha=
t dumb.
   =20
    > Experience shows that criminals use not just cutting edge =E2=80=93 bleedin=
g=20
    > edge crypto.
   =20
    You're absolutely correct that a few do - as you note, Conficker is a=20
    good example of that.

My point is that we should look at the trend =E2=80=93 not just the status quo. A=
nd the trend shows the attackers become smarter.
   =20
    > Plus, there are many ways to foil this proposed mechanism =E2=80=93 for=20
    > example, super-encrypting the data before transmission.
   =20
    Sure.  But the ability to infer the presence of superencryption is=20
    extremely valuable in and of itself.

If the adversary allows you to infer it. It=E2=80=99s next to impossible with the=
 large-scale traffic, when the adversary is crafty enough.
   =20
    > Then there=E2=80=99s an issue of the abuses. First, not all of the=20
    > =E2=80=9Clegitimate=E2=80=9D authorities are =E2=80=9Cgood guys=E2=80=9D (all the time :).=20
    > Second, I=E2=80=99m not aware of any =E2=80=9Cnetwork security=E2=80=9D tool that=20
    > hasn=E2=80=99t been subverted at some point in time.
   =20
    Again, to clarify, this mechanism for use on intranets within a single=20
    span of administrative control.  Like you, I would work to dissuade=20
    anyone from using it across the public Internet.

Again, technically there is no such thing as =E2=80=9Cintranet=E2=80=9D. It=E2=80=99s an *adm=
inistrative* domain, and there is no distinction protocol-wise.

The only =E2=80=9Cdissuade=E2=80=9D I=E2=80=99d consider is when it=E2=80=99s enforced on the proto=
col level (on the wire), and there are unambiguous ways to detect it (and ex=
plicitly opt in, or opt out).
   =20
    > The likely result of the =E2=80=9Cstatic-dh-=E2=80=A6=E2=80=9D proposal is improved mas=
s=20
    > surveillance by authorities, and exploits of this mechanism by the=20
    > organized crime.
   =20
    Let's remember that this technique is in use on intranets around the=20
    world, and that's the focus, here.

Let=E2=80=99s not forget that from the protocols point of view there is no =E2=80=9Cint=
ranet=E2=80=9D. There=E2=80=99s only =E2=80=9CInternet=E2=80=9D =E2=80=93 a network of interconnected netw=
orks. Administrators can draw boundaries around hosts and routers they think=
 they control =E2=80=93 but it has no impact on the protocols themselves.=20
   =20
    > Either you have PFS and the bad guys will benefit from it too (so you=
=20
    > need to detect and fight them using other methods), or only the bad=20
    > guys have PFS and you might [0] detect them because their=20
    > =E2=80=9Cprotection quality=E2=80=9D stands out amidst the ocean of the=20
    > automatically-inspected & censored traffic.
   =20
    The ability to infer superencryption is quite important, per the above.

First, this ability depends on your adversary letting you have it =E2=80=93 it is=
 not given. Second, I find it concerning that you seem to be OK with the sec=
ond option of the choice I outlined.
   =20
    > Because there are well-known ways of hiding the presence of=20
    > encryption, at the cost of increase of the ciphertext size.
   =20
    We should also keep in mind that are also ways to counter-detect these=20
    obfuscation techniques, too.
   =20
For an individual connection =E2=80=93 very likely so. For all the connections yo=
ur subjects have within the company, and/or with the outside world? Not hard=
ly.=20

    > The hope that the encrypted traffic would stand out is unfounded.
   =20
    Actually, it does stand out, in many cases.

In fewer and fewer cases. As adversaries learn, they encode that learning i=
nto the tools that then become available to the lower-skills-level attackers=
.=20
   =20
    > Considering how fast the attack sophistication is evolving, the=20
    > likelihood that =E2=80=9Cthey=E2=80=9D would employ other countermeasures, but=20
    > ignore this one is fairly low.
   =20
    This technique certainly isn't a universal panacea, as you rightly poin=
t=20
    out. =20

:-)

    But it's an extremely valuable and important technique that's been=20
    in broad use for quite some time, so maintaining a mechanism for=20
    intranet operators to analyze TLS-encrypted traffic within their own=20
    spans of administrative control is important and worthwhile, IMHO.

We disagree here.=20

Not to mention that a country might consider the entire traffic within its =
borders as =E2=80=9Cintranet=E2=80=9D. Some already do (and some don=E2=80=99t even stop there=
). I=E2=80=99d rather that these operators mature and realize that as the time goe=
s, some new capabilities arrive, and some old capabilities wither and die.=20
   =20
    We don't want to inadvertently drive them into using proprietary,=20
    non-auditable crypto.  That would be bad for everyone.

Publish that crypto, and it=E2=80=99s not proprietary any more. Subject it to an =
audit =E2=80=93 and it=E2=80=99s now audited/auditable.=20


--B_3583146609_428120313
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKSUBIdwAAAAC3lzANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE3MDQwNzE5MzYyNFoXDTIwMDQwNjE5MzYyNFow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8OK5RGbI6mDfMw/2HPG57y1TdKRaQwlj5iSXC4gDg
tv34L93tRDUTjA27kFG5HOrWar2c37RMkVX7nFR9TfGZh66CSe7Lj7ZMZ3wNyodJqptavXaV
DjSuqp6sPJGQFZNr/pIA2g/3uUOq/igeInptaYb3eDsTwt4fv4G3iLp5Z/4bd26LDJltFZnE
qOsLsQ3xfkAAaht55x+jl1QNm7+Vfe4RVeInASY7xZu9dQUJChc46p7sVcV9/exjYIkOeeG9
QB6i4CJK4vHbyF2qG+IqZfeYFjXWy3Eq7a7YrgqAl81Xs4Bpjsn9zPlFlwmHNVUBJTgShUql
kFvqKjcw0FDpAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUWa29JQeRiwuEcAGFzsv/xdyErcAw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBCDAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAIjee93wr/GEbKbqkXc5
krqRGzwcj6/NhW9rmX+MwXqm63OL+/H159UXdIQCqdd1uovIOcK8y/gXjlJOJ6ol54aixafq
sz3ozZ+eIUvphrxRVTxR8vVb17QnPxOQE0Mx9N1uRS+Hps7XgDS628KYfzxMb12+2WriuwyM
VAVl+lCBF1S4ZO/0NBx/wVyEu8Hi73kHC93/4HC1c4bwoExAAjY+twm7VBY8eTpvV/604iDf
1NdKtCb5l1fFZkyZnQ5ZDKONBehGsRGF0eWBUDCopoYTu8nbcRocvRGM+ZLFtPLh5xlpjrO2
E+CE6Bjx948aoJJCXqHf7BeKxlbazvl2RaIwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCklA
SHcAAAAAt5cwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgF3SYX1T6jFdR5WyY
7oydQYQtwBMxPKCTsfdBiS3K/2owGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE3MTgzMDA5WjANBgkqhkiG9w0BAQEFAASCAQBlQ3zuOgcWH6/ppJaK
+ikL1tfutGiRH0hWx13VnLB9Sc15fQAc/1/2TUAJz9da3PBWOiEgVpWCBIVhdyOnOaP/4oDY
3vyySZNEs5QWbqkneJX/V7RfrgCvS6MqHt3I4R6Axs66AWlFrDfnCNIgNIMcGbaWwfDuHiFM
qv3J+kJ83NriHxfZ6XnJ06hZS4Ub2Igf1y/xZB73QwapirqpII+Mlx/MPONOwsflEtBR6XB0
gVUoN28ds66F7wqs5B11EZ1nfkMZqVPKpIwLpVzckhP+/T9x3nXtmpxo1HY5lAuSSZiA2Lpg
GxjvZsYgMT+e0sxZNV12noP2VzAVhbjssRKi

--B_3583146609_428120313--


From nobody Mon Jul 17 11:35:26 2017
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 9B55F12ECB7 for ; Mon, 17 Jul 2017 11:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 wUv4xqRDhTAc for ; Mon, 17 Jul 2017 11:35:22 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 77B67131671 for ; Mon, 17 Jul 2017 11:35:22 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6HIZLIw031075 for ; Mon, 17 Jul 2017 14:35:21 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: IETF TLS 
Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
Thread-Index: AQHS/vR5lF141oQzb0GeHnUlNx5L9aJYMXgAgAANgICAAAOcAIAABaaAgAABXQCAAAPqgIAAAY+AgAADO4D//8BIAIAAUI+A///jCgCAAE8pAP//w6OA
Date: Mon, 17 Jul 2017 18:35:21 +0000
Message-ID: <0393B6D5-BE7F-41A2-BC8F-43D330BD499D@ll.mit.edu>
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>       <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> <69018030-3157-42D4-A573-0E39E46EFAA9@arbor.net> <31C01911-5E2B-4812-B4B5-334C7D212F22@ll.mit.edu> <7995AB85-5144-4ABE-993D-EB1415E7E2DD@arbor.net>
In-Reply-To: <7995AB85-5144-4ABE-993D-EB1415E7E2DD@arbor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.24.0.170702
x-originating-ip: [172.26.150.37]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583146919_391278835"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_15:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707170296
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 18:35:25 -0000

--B_3583146919_391278835
Content-type: multipart/alternative;
	boundary="B_3583146919_1813075890"


--B_3583146919_1813075890
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

But it's also important for understand that security is additive in nature,

not all the criminals are bright or sophisticated, & so the emergence of a

few smarter ones doesn't make those less so disappear.=20

=20

:-) It=E2=80=99s the Law Enforcement job to make the dumber ones disappear.=20

=20

The question is whether the risk all of the legit users would be subjected =
to is justified by the preserved ability to detect the dumber criminals usin=
g an outdated method, instead of evolving with times.

=20

In reality, most of them are awful blunderers - they succeed because the de=
fenders

are worse blunderers.  Consequently, there hasn't been an alarming (heh) dr=
opoff in

the need for TLS visibility on the intranet - quite the opposite.=20

=20

Let=E2=80=99s exchange our criminals =E2=80=93 I=E2=80=99d much rather deal with yours. ;-)

=20

My point though is =E2=80=93 this dropoff in visibility *will* come, like it or n=
ot.=20

=20

=20

And the need for it isn't limited to the security space.  It'd extremely im=
portant for troubleshooting, as well.=20

=20

Based on my experience troubleshooting =E2=80=93 I disagree. If I control at leas=
t one end of the communications =E2=80=93 I have all the visibility into the traff=
ic that I need.

=20


--B_3583146919_1813075890
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


But it's al=
so important for understand that security is additive in nature,<=
/p>
not all the criminals are bri=
ght or sophisticated, & so the emergence of a
few smarter ones doesn't make those less so =
disappear. 
 
=

:-) It=E2=80=99s the Law Enforcement job to make the dumber one=
s disappear. 
 
The question is whether the risk all of the legit users would be =
subjected to is justified by the preserved ability to detect the dumber crim=
inals using an outdated method, instead of evolving with times.
 
In reality, most of them are awful blunderers - they su=
cceed because the defenders
are worse blunderers.  Consequently, there hasn't been an ala=
rming (heh) dropoff in
the need for TLS visibility on the intranet - quite the opposite. =

 
Le=
t=E2=80=99s exchange our criminals =E2=80=93 I=E2=80=99d much rather deal with yours. ;-)=

 
My poin=
t though is =E2=80=93 this dropoff in visibility *will* come, like it or no=
t. 
 
 
And the need for it isn't limited to the security space.  I=
t'd extremely important for troubleshooting, as well. 
 
Based on my experience troubleshooting =E2=80=93 I disagree. If I control at le=
ast one end of the communications =E2=80=93 I have all the visibility into the tra=
ffic that I need.
 


--B_3583146919_1813075890--

--B_3583146919_391278835
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKSUBIdwAAAAC3lzANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE3MDQwNzE5MzYyNFoXDTIwMDQwNjE5MzYyNFow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8OK5RGbI6mDfMw/2HPG57y1TdKRaQwlj5iSXC4gDg
tv34L93tRDUTjA27kFG5HOrWar2c37RMkVX7nFR9TfGZh66CSe7Lj7ZMZ3wNyodJqptavXaV
DjSuqp6sPJGQFZNr/pIA2g/3uUOq/igeInptaYb3eDsTwt4fv4G3iLp5Z/4bd26LDJltFZnE
qOsLsQ3xfkAAaht55x+jl1QNm7+Vfe4RVeInASY7xZu9dQUJChc46p7sVcV9/exjYIkOeeG9
QB6i4CJK4vHbyF2qG+IqZfeYFjXWy3Eq7a7YrgqAl81Xs4Bpjsn9zPlFlwmHNVUBJTgShUql
kFvqKjcw0FDpAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUWa29JQeRiwuEcAGFzsv/xdyErcAw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBCDAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAIjee93wr/GEbKbqkXc5
krqRGzwcj6/NhW9rmX+MwXqm63OL+/H159UXdIQCqdd1uovIOcK8y/gXjlJOJ6ol54aixafq
sz3ozZ+eIUvphrxRVTxR8vVb17QnPxOQE0Mx9N1uRS+Hps7XgDS628KYfzxMb12+2WriuwyM
VAVl+lCBF1S4ZO/0NBx/wVyEu8Hi73kHC93/4HC1c4bwoExAAjY+twm7VBY8eTpvV/604iDf
1NdKtCb5l1fFZkyZnQ5ZDKONBehGsRGF0eWBUDCopoYTu8nbcRocvRGM+ZLFtPLh5xlpjrO2
E+CE6Bjx948aoJJCXqHf7BeKxlbazvl2RaIwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCklA
SHcAAAAAt5cwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgCzYyhZonI+NOaciQ
TcbDLDjxpVsVGvR1C6Ghs+NYmQcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE3MTgzNTE5WjANBgkqhkiG9w0BAQEFAASCAQCs1jdUPZiwFw4R6jLf
uyV1cUidGDBEQyecYTeF7WoLBknql0cVA//WJ9KZMnLTZN6qHfgPiBDh4u61JUn3xDudu2lx
MRtrw0vv9DKqwHBZAL2+H9fccvzgospt/u8N7Teb/kcdoGyQN/vSB+kXhoNPlIz0tBcckujv
BDbvghieZf8vNyEIyjEyBs2nk7LWzpVcVn0cKHx27u7c3ITUAOtKaSu7RsedS9bSD4AqE/+E
br2csi0XpZWXc/bZB+Ik/vJ/lEZUDdAbgLmv7/ZfuMqHE/no52IiyVPOrFel0CTkMMaZxWtR
9olmMyVDrFNOfQ7WzLU+vzQFTMdKRvlnEsDf

--B_3583146919_391278835--


From nobody Mon Jul 17 11:49:24 2017
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 60C0712F290 for ; Mon, 17 Jul 2017 11:49:23 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 RhNn9LUIrfox for ; Mon, 17 Jul 2017 11:49:21 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0116.outbound.protection.outlook.com [104.47.41.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AC412F258 for ; Mon, 17 Jul 2017 11:49:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=95y6pxrWBODI38YmLNMOeZx9pUwrs5+heE9Z2BHUiwg=; b=bdLRq6lTJ5SRFGqSxgYYbjhcwdIrKWw/nHFdGTRv7EXQwEKxKRPzxAloM6rZ7xzMh8hgajT8hmVKxUGUs+3GoBQ2YHbVrSno1XIS5I6steOffcV/LQ8mpHrnjLsfsbBBfzpWk4SrcIlVksZTquw2fS4OL9yCzH5EgDQN9Wg9r2Q=
Authentication-Results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by BN3PR0101MB1025.prod.exchangelabs.com (10.160.182.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 18:49:18 +0000
From: "Roland Dobbins" 
To: "Blumenthal, Uri - 0553 - MITLL" 
Cc: "IETF TLS" 
Date: Mon, 17 Jul 2017 20:49:08 +0200
Message-ID: 
In-Reply-To: <0393B6D5-BE7F-41A2-BC8F-43D330BD499D@ll.mit.edu>
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>       <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> <69018030-3157-42D4-A573-0E39E46EFAA9@arbor.net> <31C01911-5E2B-4812-B4B5-334C7D212F22@ll.mit.edu> <7995AB85-5144-4ABE-993D-EB1415E7E2DD@arbor.net> <0393B6D5-BE7F-41A2-BC8F-43D330BD499D@ll.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: DB6PR07CA0059.eurprd07.prod.outlook.com (10.175.237.149) To BN3PR0101MB1025.prod.exchangelabs.com (10.160.182.154)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 2890836b-d224-4e35-5ebc-08d4cd4487e9
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0101MB1025; 
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 3:JDvxSzZCHJbI3pFZJnsw/RrJ3uK0CXBzpKgmV+Ve6GYS7lzJAM6H1zkmVF8oNproRQajjXhmtTEu5Ir5l4hJHv3yLxjDq6jD6lwcx9YHLh+C/Sb3ZigloWm0yjhpkp1kH4m/HR6pYcQxWRA4A33YHGlWbJKFuyJoDtmPmlSOATUW6jitgyHVycMJKBiCjDYUbj2PIyJQ2cXSzrsQectMxr6qkcFJ563Jw5DtzOfNHM11I+aSkW3vlef0UIemn0x3JsG5iJfbof5bPszFevlOD+MH/C9GKWohzBbGAepACtRywL9qgkMi4R0aUW+Mbk6BpRG3G4EGj92kwtwadWP5ipBw/ZbIfRRPE9QRYmuNZnx9D6qqlQsGdSlx/92isSJaZodmsD/iHHM5Fw+1tgshbC7U+cbz8DlzKDvxxkJtOaV3gecPFy5xvQJmJ7Y1Dp/F4LT+U0ppChJMQ/0/gjGp8jeFA3dMIZ25tZmxruDAXKA1a5JTXsNZUQ+O0yHeeHw+Akpp5N3ideTUI95xLyaA8bgurIPd1oTdonX1d9srLXx8St74qQLAp/bbWu9wr5gorXYhXokBDsULAx+GFF8/wuIfXw9XsCcMnPI5nUjIs8fQoDKdNT4iUs/V2u7qztURLUnni/D7l3tJdZVziVs/ajk5Ejkwo/HhhOAj80Le4itspLC0Kl7apVFRDAR2KvR2CP3TxfDMMnlo9hzyP+OfOCLxPIBWxUxhvQr0z+O3qwI=
X-MS-TrafficTypeDiagnostic: BN3PR0101MB1025:
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 25:GhY1Hd4G5Yd78OY1wYlss5dAr1uxRRP2pZZOKgsyvc1OD9CGhYKMvy3snJtRbF1Ub7KC+3RPojkol2+VmDIloUf6oGmmQ+fGJUQJ2KT7uTd+NLLZEFiL54KQHyfy1iqss+z+FdlMndsWtnmgostJ+HGJSmIOhlZX5jcbjpE2aEDCy3S7Q0Nc/q3p4fAYGrqZHZDiV0vKUnTZny87DhPWqSEFGlPSzjRtICwFYUvVOSl6P7WH7ftMQhtAXqdmttMuv291P0NZrYboauon3M6hDzSbPTolVFpQBb0eneoYscagl/PvVf53CPfeSTZpxXgrIyfdd0WTjSZwJm6SJNfb7zREmgTGm3CYMkW76suJ6/Vncza3Jzr3Bhe9I/0G2upYUNitC0opydWA4QE39BBwOz7wVBK5KRzsBNc/1at9eFDt4L98btIQzlGnJFDVWOgv1oPnecelNn1hkhOLD4R8XlaJTp+xmmTejwR+ZXOhtrs5ZJDtvlAt81AuxVUNph3WSIsWA9qQErHcV9hGFf9A+4/9hoTXiF25y5h6XDenwB3+b04kanRNpSFfKsBbU4r3A+wjODOE2LkuxkBpAjUyADWZYycfo1ublP9O3h0EOMEChJ1cVY0l2PYdIm1h/zlHHHFh6DU7A5LhnYF6S713cp210EEtjIkF/fTszgvm3GlnzOG57+3U98ewiGozBwDY36aeBLg/Uuv744Y3eFREehtDSGRaf4/pItXqMqXW0TkaX9X8SwB6KOxPrDAIc9t+/bQAQBfkAe1IZ/ELi9E9vDREDx0mws/RA0hoO1gIk2GV/rTtEJenfjKXYOCoEO2xqWJKUs1Gr9avrsCO2PyQC03MkZboaL7c+gL+2c+NUz4T08wBXuWxodGaxk18WYpwiYDaQw2YcxBz5x6WfuvBrbzgBT5pK3pqPEGqfhVWpUw=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 31:rMtnk/yIxTNvBCCjbqz19Dfhmjca+zPBUZldcNjRG14FV0ijzKIpYSmuPCDoPUqtczfQsKMHbCUU+k9n5azbz+9AGxjJXE3JQH0c34rltim1bNzb5O6AgHfM4ktt/VBuQAOuulrSgt0bfy/oFb6bWyMJMvciQLLlzTIit2pIbR9CuMRGAUDkMKuLJB7sCzcsTSlyrkw9wlKt3xIc90hyl+p8zQfmgV6z7UkQcPiPSPvlu3mkpdx7guIDgGsjdB/02gV0Y4hckXNNw50W3jnSw/KaP2VMfNlXvRidGq4bzgI4IreuvHZZ47KOdvX56oYpsp7QTp8D9rBG0UE17tyZkCoBUCr8HPpT/w68YFciehRYxOHMwwOxLf6tE9Fy1h/UsVolX4nZ9DQKDW1ZHR8GQfSu9ohBU104d/zYeSFjV/gc7iewkAXwHoRzydq1totYHC3TVDBLdXURvQu1Akq4Qg3vOGvdi6OakVz+DdczM5cURxx6/yH781+C1FMZNRR9fUngGYErWx0O2j5zRWNIpSFTRPdM6JALBkjfC52GQJPTEqZ/woYFBujEjD7XemKZiBgHu9seyAjeauwXTTAbFEStHIqws0PkI/gSto7ig/EO7jT8K7QJYnK6k70cpy2TgeQnFs+t1QC+jWVvQzP4eGr5HU9SxYAnKurMx+MkD0tMRzIXQpWreCQlTBJh9WGgYcyA11ebq94aDNeY1hmfGg==
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 20:U5wWWuNGbia4Z3FJZJu+FeBdOE9Av2M/C8xKR2vnulefXDq5vQEFqXLwO5PSYMsc95+yLTl6esz5ordHyjLnxoS9WhKp/imkdFJh37OMN9ZvHwaB+gHqxD0iMv14WT53wGUOUSw1FXxDVqEqgWEPhTQrYS0wfnscj9l0/iSOpocPSJpLditQRbrDkrjk2z+ij+E94ccz459ODL6uS3vw8t4VsIdK/2k1RrLwW+HWNdIwmuehTT9BmuWQY92ZVeerycwrzYOP0eT+iOC0Rs+cM2wIWwt+RUmrQXxHWNKN3HaDxt6wnl2dYqz7Qs1G3zCgDI/hraTsVJifokNPbM8EJsu+WDhpzT/T5HsYeuQemvKBLnXI4TI1VzfhU4JF0UlscLbop9oRTQKAKKTj38hoQgKgvhJ50upIbygSUAauO5Q+ug6QDVlD2aJmtzKxp59TbqPrwltbjLjtCUwtfJJH6qC8h/F/o4C77bsjnDronvb0KDhi2Mt/a6PkWVZtzEhx
X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(48057245064654)(247924648384137); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0101MB1025; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0101MB1025; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAxMDFNQjEwMjU7NDp6aUxBczlqTkZtQzBLMU5Qd1QyeFBNalhB?= =?utf-8?B?YTZtSmpmRitYbEZPbVdDcG9RcklPUWNhak1PcTBYVkZyRTJmaDkxMEFUWVZJ?= =?utf-8?B?VnlFakxTZC9VaXlpZ2tiNGV1VDRyVktNNCttc2JlUUdnZ1VUQ0pPaFU0RUJT?= =?utf-8?B?dEFnVUZYY0VwdFVSamZHNUtjOFhxVkRZK0FqYWVjc016Q3l5REEyVDBham5l?= =?utf-8?B?dlZGUUtZVlJBZUV1NnJnL3dvUEc0KzBFQ2V1ZEJIdVVyRis2bWpFNjI4NUsx?= =?utf-8?B?R2phYTNSWFdRR1JYcTJLeS83a1h4UXdENlg5MG1IVWhoNVZaQVB5MHdZbnJw?= =?utf-8?B?NmNaZjFMKzRqN3VFZCtkR0lOd05CUWg1NzBreHk0ZGN1R1NpN3EwREJtKzho?= =?utf-8?B?RkxEU01iY1ZFckg4VFFVeUhxb1dYT0JQRlg1ejZmNWxUa3AzdWxKWXlBbWEx?= =?utf-8?B?VXhOQzNMa2xWSi85ZHJXZGovVWwxTlFuSVFXSGtXNjFVUHhhS1cxeUxLS1d6?= =?utf-8?B?cGRQU1JHcTJJcjhpblBiTjNmYjNsRVgxR0VQb3BLem1GYXBIMWI4WUNWd2Vv?= =?utf-8?B?MmZBeHlDMjk3OVhJQnRhWUNxZEVvU2YxSjFBV2lCUlNIWEloaTQxeUp5UVR0?= =?utf-8?B?TXhzZjdWS29IRHNHaCsvdXFJbmlRUWp3eFZFcithV2VkR1pnclpic1JTYUg5?= =?utf-8?B?M2Y1bEdQUVBJOVN5M0xxS3pEM3ZnNG80UnVCdjkrejVhL2N3bnNqTTl2ckRY?= =?utf-8?B?MERJZWMzVFphdUJ2VzhjRGQvUG1YOThmSTl3anR3SjBIczZYUWZOYlpDK3dP?= =?utf-8?B?eWhRWjFyNWpuOTJSdGRRdVNMaEpnNllMRGtVV1lXMk5NV1hxRUR4VzUzb3dH?= =?utf-8?B?SWZPZTNJWkpzKzJaazM0S3pqZDJuejNhanVRbzlaeVdHSDJmazJPOU5UdzF3?= =?utf-8?B?cFl4cTZqaUpOeXFNNHRaeGhiOFY3VXdIVDdYR00yZ1BwczRVMTJXdGVBVEZF?= =?utf-8?B?OCtpQW5FTkxQbjN1TXdEZVNTaHExOTZGVGFXZzdCM05scllFZnhnMjljTVZz?= =?utf-8?B?UHVhcE12eHBLUFBvdXNpREplOXdBNkpuTXJwWGhDVDZMcXk0eXU3TDlyQ3Rj?= =?utf-8?B?T2VKM2pMT2xyYVdMWW9SVFJkRkZINlFmK2N6Y09QYVJKTVJ1UFF4SEtlazdo?= =?utf-8?B?NTdHSU9XMjZka210NVAxejVMMWRvNzhraFg4NWVWMUo4eVIyWFlpZW9RaDNo?= =?utf-8?B?M0dIL3RvYXBGc1VFUzhUeXRDeExWOWExeitoeDE4OXBEeU0wL3EvclUyMVhh?= =?utf-8?B?NkJHTzF6ZCtkQ1hwR0J1bk5icGtkNnpvQ2ZqZWRLaWVQZ3R5RzR5ay9MZk4v?= =?utf-8?B?RnM5dGNySXhRdjlZNE9URFNXamhOaFRxVEpwYlU2MmFXNzRiTHdpYS9vM1pn?= =?utf-8?B?OTd1eGg3K01PTWNPUHdpdU1zVVFUM2RiZUpNUUd1Ukl1Q29iK2g3b3ljalZI?= =?utf-8?B?cUh4WlB6c3F1OXEvR0pIVXpMYXhQTDRFaCtzdWVuREplMVR2WWdWNVdITDR4?= =?utf-8?B?M045S2xJTzdLQ0ZBbFB6WHdwalZoL3RlUERMQ0NNc3hGMUFON2hJNmNoY3Jh?= =?utf-8?B?d1RERU93elhPWmVRUHkzVjJIM254QThPR3VpbmFEMUxWcW1EcmRHZlY4QjFQ?= =?utf-8?Q?MYbB8NlJKQsceZJm9w8AooULP2S3muuodDDLZcUh?=
X-Forefront-PRVS: 0371762FE7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39400400002)(39840400002)(39450400003)(39410400002)(39850400002)(24454002)(93886004)(2870700001)(36756003)(6666003)(53936002)(7350300001)(81166006)(83716003)(2950100002)(6916009)(3846002)(82746002)(230783001)(86362001)(50226002)(4326008)(2906002)(33656002)(7736002)(6116002)(76176999)(53546010)(6486002)(77096006)(50986999)(8676002)(478600001)(25786009)(23676002)(66066001)(6246003)(38730400002)(110136004)(305945005)(2171002)(189998001)(50466002)(90366009)(5660300001)(47776003)(42186005)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1025; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAxMDFNQjEwMjU7MjM6c3JXZHZaZzBqamRQd2l5MXpNMHpZZEFM?= =?utf-8?B?eVN5R05ndndCMHlhOG9aTGdXd29nZ1U4OWpxcnpYY2NLcC9TOW5SaFhOeGhi?= =?utf-8?B?WTdOKzg2d3BjR0pnL1hrU0VBMlM5L3N1S1pJYzJKamxNTVd3Q1o0WmVKaUVt?= =?utf-8?B?Qm9zVTVHd3BVQ0tsc0Z6bzY1b1FFNUhZT1MvNkh4Q2lvTmlHVTU3cXlhdElq?= =?utf-8?B?VHBDNktJQk8rRWtMODNaY3RKaW5yYkZNVThLNzh6VlMzWmlScDZKM0tDUThm?= =?utf-8?B?OEV3d0hiNEdKU2JXeFd2YTRQZkdLaHZqRjFodEVXSElTQXpPTUtTQmVvS0J2?= =?utf-8?B?c2VmbjZ0cFlpL1k5UjY2K0ExemVzdXo2a1E1b09sa01PaHZWaFJiYjg2bVNP?= =?utf-8?B?M2piUDhqUXIyWHI1eUVNSkU2K0I5SWFXYkxyK3U5YlBabHRvUFY5RHVlK0Fo?= =?utf-8?B?VHhsOHMrMlFjdHJyb3VNaUI5ZW9PRE0zRnpzSHBKYWFXZnUyNlU0YnFvVXdq?= =?utf-8?B?ZnlMeUN3OWozcXZETnlJRzcwMTU1N1ZJcDJ1QzllN2RrZUJudzlOQkFwbkpK?= =?utf-8?B?SXEyMnFOT3FyaG9vMFJhRWNrVGw4NkEvV3k4THg4dkZ0eTdWZE4xSzBFMFJy?= =?utf-8?B?aEpCdVlhblhHTVJrYU4vVlkxdkkwbnltUmFKc053L094MDMxdTVjaWk3MG5Y?= =?utf-8?B?Z2pkOTY3MXRCdnA5M05hczRJY2ZsR0xXbDY1Mk1sbzVWZWk4MzBXc2xzRGZi?= =?utf-8?B?U29Bc3FQSDRFblhneGUyVjBKYXhaM1JYQlRqd2hWQjd2dVFYeG5adlh2Sjd0?= =?utf-8?B?V3d0Sm50Q082Ri9WRHAzdjFSYnA3QzgvaFFNNUFkdmloMU9YSGYvallBUDFJ?= =?utf-8?B?UE5HUkx4cXlqM0YwbythbkIzU2hla3BvM1BLcVM4VlpKcnVnRFd0c3NCNVFp?= =?utf-8?B?aDdldEw0UVZQblgzQlBhcmNjM2hxOXZqZGdZdGViLzNSdEpTN1lqU3A0TzRP?= =?utf-8?B?dXFiMFFDVHdwb1NDUWV3OEk3SnAybS9xUG5SS3NuWTlMMHpMK0FPcmNxUndj?= =?utf-8?B?OGdNUmNyZ0VRcmcrSjFxYmJWK2dwcDE2UDMzbllOMGtDdHRONnpOZVlMNHA3?= =?utf-8?B?YU1RblJzOG83NWFUNHhIcXZySm96N2UxQkJDL01aRVplVFFyV0RXTkx6RHFn?= =?utf-8?B?djhDZlNkOXRjQlo4NEUvMVhPVjNwVzU2dG8veXhFSlg5NjZpMzBzSzZvbFBM?= =?utf-8?B?SlU0dTBmUjQrRnhnSThOVWYrdE4vSEJNSGZYWUF6Y3ZneWdZT0NoYXRTQXBG?= =?utf-8?B?ajgrNnlxSmk5QmlBSDJBdHVOTjNVdmxyWUcwNVpRMUQ0SjErM2h4cklrdG1w?= =?utf-8?B?ZTJUcVdQd0UyTll1cllFdXg2NVc5RC92dUxEK01tcklsYlFMVHNvN0VwZXJu?= =?utf-8?B?Zjd2LytqZm5ITVNUVm9peXVJeFZoQW1hSWg1VXBHbkQybnlTWk5OQXA5MGgx?= =?utf-8?B?ZTczaEJtOUZTblZoZXltb2FCc25uZmtoV1NIcUVMdlEveHpoWUJoZjc0VW5C?= =?utf-8?B?aWpDVS9RWFpSL2hZSTVVcEkzejFGdWlOY0xCbkVUNUNoS25JWVBIbFdFdzcy?= =?utf-8?B?ZTEzSFBuZXRLNEwwRnh6YnRBWmF4S1doREN6ekV0YW12R3pxeGMrMUlkSzBI?= =?utf-8?B?SFlCNUdqcHpjRVE3K1VITTN4Wmhzc1FLR2xxV3BRN1hVblVQSUtjbVBienRI?= =?utf-8?B?elpYdE1oYzFVeE5kMi93VjVRPT0=?=
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAxMDFNQjEwMjU7Njo3Ukluclpza1lmRENmOHpweTgrcENYYWY3?= =?utf-8?B?UjNCdTBUMkdSR2dFV2huT1l4bGl2a20xcldoRmxJVGNQbE1oN2RhZGZvbnIz?= =?utf-8?B?OHVpU3ZsdS9xUnBra0UvVzMrdzQ2cnJlUjRKQlh3a1BoVWJNVk0wT21YcGp3?= =?utf-8?B?eTlEbS9ZdG1oVkZFek1KMVI1YURPQTVlZCtzcnV0OHJtYnh5ZWZreVZTaEhk?= =?utf-8?B?aURNeUtaS2JVTHdYazY0OXpzbzFjb0ZMSFp4cFkraXdlZk1Jd0RXZ2tuWk0x?= =?utf-8?B?czdLYlBNN1AzRFFONVNIT1NKc251VTA2TXRvSmU1cll5UXZxRExHUXJCU1V5?= =?utf-8?B?Z1RqYUxJZzY1VmlMUTlrcjNyUlc2VTYvUkVhb3l2dWluN0Z4bVA2RFd3S0V3?= =?utf-8?B?SEllQWUrT0xQakVPUlZ5M0hEUzBOYUEwalVqb1FXMEJlTUN1OWV6RjN3TzJ3?= =?utf-8?B?TmpDMkNYT0NhTlJUV0pDS0dlTnV6dE9QclBSYTBYd0hvQVdxb2s2RnIwdkpl?= =?utf-8?B?M3hqb2lTMVE2dDhsNFh1UzNWbktIL2g4SlRSQzl1dTlWQnA1dWdIQWhCak16?= =?utf-8?B?WXZIcGJDdmh5NzUxUVd6T1k3bENwcG95MFBWMXpwZm9YZFhuSEYrSFE0QWNw?= =?utf-8?B?U1Mydm15VUY3M0ZtczRJRXB3d3N6UVRBdWt4LzlyWjk5VGtDbDc5VVRjaUl6?= =?utf-8?B?a0w4UWs1cXQzMG1Bb0NmN01STHdvQi90b0lTdW9ZdU9mTDljR0d3UDFvRG0x?= =?utf-8?B?cVpGTkJ4ZDQ2a3RXNml3Mk95WVZOQUFxemxtVldaVDNWalJPU2g1eW5hbVNI?= =?utf-8?B?MmJhYVJRSmVQenFHQUFhZ3ZyMUJBaVVCc1BMZXJlMU0zdkVHMUpmdzkrZGlD?= =?utf-8?B?MzVQLzdzRkpJWWhJRVNkRlNIN2xDRURjVjhNbUR6U3cwbWJwNjBmdXNjeDNM?= =?utf-8?B?Z2FMVjlMZlRYdlNhTnVqQjBiSzlYcjhrTVpyZnV4RlExTFBMdVVaTFFIYmZq?= =?utf-8?B?TUR1UUdvTzVXUjNmL3puaWZ5UXJFak5RMUllZVozUFgyVlNaWHNqVGp2MVp0?= =?utf-8?B?OFVSY21DdkgySGlwd3VOS0cwK2VacFJCMUEvTDhZOXJvbUdOdk9GMFFkL1d2?= =?utf-8?B?ZW8vTUlMa2FueFpNbVh1ckpNL0RVU1JhY1ZJcEdTVWpJZXZkV0lJeXhkN09z?= =?utf-8?B?Q25TY09aUThDbzBmemIxU1d6cTFHd0JsWjcrZXJOdXBTK04vVitreEVxT2g3?= =?utf-8?B?djRtb3RudXdFWjZaVzUxL3FiUkZydFdHam9TNnU3MHZCQk5tL2NUWDY3RUdW?= =?utf-8?Q?n2bu6WjHEBxMzp05cYfRX+o9Bbi3QO4sE=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 5:5bRAZum7A/jdgORzyYZYFLiyI+Rx81XR2Uxq2Ci1yng4j6ggh8hfn2fJcz9+M138EawK7mQxLS7TGjRFtE9BFtaJPDd2CBh2j9wnurnRtPOg2d8Bo2fVUay7beMaLdB1P7rP1/EMnbxcI0Eh5dotPzuVfftkd+B5/sAS0wDGH2GSj1m3W9swA37Gr36z/iSEnd4tG7YPTMqpjfG/BfCQPAoAgS7R30NGiuz10rHSlL8vtARCryHDuLJ/Z76WOLn7dgfLGcumFeTOIRITtwjJdA4dLxAl2VHCTpHZxLDCZyY8yjOHexlN6YwLB1P8YntWB/dlZe3BR2l3ycMxRqnvI2LH/0e13XwO2L7YKAN0WUAkJrNedtXkQ6sr36Vt4kxLqjDTCBUL8ihxLdHfkPPEOgu44B5VYhCkMKJBtr6O5X2WaQP4I12idnsGyvw0WzS+FOxbRfQ7rt1fiu5roL6BgcuA+viSJc32HWZXxK9ujAn84PXPoGBP+/Z+h/SBCXG/; 24:MCx4kRAUQYhsBZRZ+ZfO6X4FgSRBFaL0DUMlDDghE0tkgDoCpwHLaRTULxlvSYFKuUH88vtAZhzBiBAKJKCLzo2WBFlN1AQWVVy/GoVOV1A=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1025; 7:KMLTVazZRNQq+y9JlP/CIJGuf6i2vDWs10br8/glEV+2fmdYqhXgNDr3U/nWbVDszh8kXBhlFDQmiblSFfgkIor+cmUT2hJkv94BdVNbLh2vu0jFmDW3jHw5QF32lTA6lwYM1dOV3+3zTe9yDIQ0uOz+rudCp6vixBFbxmgANi5KLz0Uj7QCJw+o8y8TcVw+uGHUaQvXpVLvC3IgMGNkuJRt9rlKyF+TvnIITtXjMb0eYJP9N9Y//Uhk7zweD4ktdsvhiLLAslAdXJ1EbkictxWgmapfD69fEes+eMqvRXQu5SbAZT+ZMLE59MVEO8W0i8ZIhqhCWHoSsfI2b6Z0kJ03vdAm8/rYtZ22SpEucgNVzEY2bOOgcxlsVlPwbXaWIoBMLL3dKmqFhLQ8eJdy0aIp8OlF+itkrmMKNzLN0XNqIi5A05GHQOUhkss3dnuuaTSrAanQLO9AVXm3eY5bHmiKIuXrTEUyzRDNlAfz4S//uBC1Ka5Ttm6wAFA9MoE5yGUnyGPxC1nBuVNUV0S2DI/8XwZXVJ46vhVyTXTFdTtNX+R9rohVKchdgR6u811IWEx3fclErrUVumSUVBnUer2eBfh7EM+KYMlFU0uO6UXL/ForwXreO7PfkUOKeyzYO7fwJnRihpthcZLZg0g756PSNcaEUBJgCREuURDwe12W9XjqNkOJWUch5Qlq857ccCaAx1IhFybG/dhXUvohiZhX8MHA6SMsP1r67UZ8+IMRGwzVH53T4c9AXtKb6wLedXkukjDtcU/hYqRKq9thMjjTfkhsjS3wJOgjUJEfWe8=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 18:49:18.1833 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1025
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 18:49:23 -0000

On 17 Jul 2017, at 20:35, Blumenthal, Uri - 0553 - MITLL wrote:

> :-) It’s the Law Enforcement job to make the dumber ones disappear.

We aren't talking about law enforcement, per se - and it's law 
enforcement's job to make them *all* disappear.

> Let’s exchange our criminals – I’d much rather deal with yours. 
> ;-)

Sadly, I have to deal with all kinds.  I don't have the luxury of being 
selective, worse luck.

;>

> My point though is – this dropoff in visibility *will* come, like it 
> or not.

When that begins to occur in perceptible increments, then it's time to 
revisit.  But avoiding breaking existing, useful mechanisms is something 
we should strive for, IMHO.

> Based on my experience troubleshooting – I disagree. If I control at 
> least one end of the communications – I have all the visibility into 
> the traffic that I need.

Based on my experience troubleshooting, I disagree with your 
disagreement; while in many circumstances a great deal can be inferred 
from one end, it's sometimes vitally necessary to gain visibility from 
multiple points in the relevant topological scope.  Perhaps the scope 
and complexity of what we respectively troubleshoot differs 
considerably.

-----------------------------------
Roland Dobbins 


From nobody Mon Jul 17 11:53:53 2017
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 9B282131A61 for ; Mon, 17 Jul 2017 11:53:51 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 b-31H7REycdl for ; Mon, 17 Jul 2017 11:53:49 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0139.outbound.protection.outlook.com [104.47.33.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 600D3127B57 for ; Mon, 17 Jul 2017 11:53:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fvcjOBuO1lnHIo5yVhanQtrH+KDKtqjtv+5sVs7KvYM=; b=bYix57tx0kBcXrROSU2CrgObZ2/SlURds9wBvbaUx1NyTJUbn1gvEe8q5L70rC35j74QVEHoaNgopV5z+Y2AcZIsQJBEHBybfDkb98Aca5Ear5mKxQ7krXZzzn8S1sgdDw7fpfBDrhtOiP7x8z8li+RHIR/iDbgy2S2o+huEVXM=
Authentication-Results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by BY1PR0101MB1031.prod.exchangelabs.com (10.160.199.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 18:53:46 +0000
From: "Roland Dobbins" 
To: "Blumenthal, Uri - 0553 - MITLL" 
Cc: "IETF TLS" 
Date: Mon, 17 Jul 2017 20:53:35 +0200
Message-ID: 
In-Reply-To: 
References:  <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net>   <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net>       <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> <69018030-3157-42D4-A573-0E39E46EFAA9@arbor.net> <31C01911-5E2B-4812-B4B5-334C7D212F22@ll.mit.edu> <7995AB85-5144-4ABE-993D-EB1415E7E2DD@arbor.net> <0393B6D5-BE7F-41A2-BC8F-43D330BD499D@ll.mit.edu> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: VI1PR0601CA0034.eurprd06.prod.outlook.com (10.169.128.44) To BY1PR0101MB1031.prod.exchangelabs.com (10.160.199.156)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e98d3599-0c1c-4122-43b0-08d4cd452811
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY1PR0101MB1031; 
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1031; 3:3Az8VmWeJTif2KXAsGDeGvwod2AHMK/1aNi4AlwSq4wYqF15srkjTc+Lko5TMt9lo/1XVF6kQ5gHlrs5RzxfYJdA+BX7M9SxNzUrCjoaOcfBiQzJweSZ2u/OQElDGjKlnYokafjdTYWugoplLq3AINj4TQcJzlls8WStvFdNCygLvHa4Ubb2RsHy9cXcuNeMiLds2zLJ8iUrHisDEnSuyWW43hLbEN4uUGAahoI1TxJvXzLAVhm5f4TKWDOfc8qpOxVzLARHsQZ/qmubgd6cMYwfdA5xKawmX5oTnfZJZUAC3Uk8E5TPBAcOOL1BiyxcDUjAvsOQ5av0AdRIWwsJw0oSGeaPsasChIUiN7OiSjXmewQLRVrWFwT9nLbrnCqHzHJR9meJCpuWVJktsSW4JrZBlEa/nD2TqUkUJumkL7SjDZDcVFDpGPGaVxgqoGbVJBKzGZ9CVBh8f4+RqWYzdNAXeTijbs3DH9vtUEBnoeE7EK+70RpqQwrDzJs/A/FXI46YwLWMG6vnczPxJm4zVeUuWgxsVGcKaAuxH6lvxW0vtbBpqg/QwYGQ2HCIwx40tMw2q/XBE8Yi61JSx2E8/90UVkoJSK3n9ew9lgE55dZQkIAsa4CDYIETWmQZWrQXbope+RfZjubE2rUFu02xeGIcRf0Kru7YrcaQZs29awBkWjJY/32PcxW/edJrpOqrkCjShvegc16BNdcL8ErZQZRl82DJ6xTzAVxpPnhnYOk=
X-MS-TrafficTypeDiagnostic: BY1PR0101MB1031:
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1031; 25:GlUaqk3K+cDPyoDzoxra5+QvUh9jrvATEoua76PjTeXvJGxyOib4TFDeNGggV/88BxCDKdldiWZJpjleldCCw38wIBL7z3COxsvTebvXKqARe5ZFzNvOiF/Voi7eID0HFjBvsr8F+9GOJM02Bnv5YuswQ44PAWRs5eGBEUHUgyh1nbqy7AX1nUGUkQS/GlfMGp+/EyVgX5Tpy1vIQZZmy341R17SgJg93qD1ds1UmOfREsDeRuuii6o7n1fZcKbcOgqE+gYABwbnTnFZVwX1TjJHiDS3Aiw3MMhf14qR2JqQF4AWPw/wyrJ0CCS1Z666P4EcgBdDm9Frl6x6M20DdgUEOIvMaz7a7ni/zczSyPl+EoyqILOinEZEuWalCDshvqNyqmE2+k8mofV4vaxgNYzohMB9XhIbJ3E5O6qlKXWdSoF3RnbgfY1RV0JcZu35lUW8QH5hBSGXTXoLtwP/DV/gIzYyHC3AOtAKSd4tjExfB/wQe4S3Pf3Cu3pYukyX26M+VfKgIM92XXsxo3UnVBb5HRazhwZNGyXSREeLLPuk8+584CilI+l6wFQP+MWgnP6FqJ8TBQoJLiLGFopY8sh2sSAKscbHXnED2OS1f8h7V1iI3lk115zXtmPWwIzvW8H+mN0Zc9lhuMQEc9ri8prlcnMvnASs94okHfHOPENexwzGMODTpFYQSduws+uYdLwBMtqp+wDTnjhCVvQMiME/qSkqNkm79cRoyqh14qIt5JW0qt+Wy1ednxlmDNsrekTiSa96GLh9Xc6mPKLGOyLEERFUAY28Sd1Ot2ppuQYE4pJaNAP+GytfwtZrWcwPGlqEI1UXgyADfnyew5Ayuqmw+VpRL3Te7jyLvRrA8IpTvikv7S81E96ZpnUw14ZTN80Hhs8RO3dLuPoxX0s5oC/sKxYbU0mT0XJHiEXWAKs=
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1031; 31:VRhWmwQ5tV+J/P8LJRtPB+OWZkfLIFx0b2Dr4+rUmYhX9hKheAb32FX1m8Hn1SdPW9s5jPXsY9C3u5jjYPhPMGfx54e/g0gGW8+3oWjU99P4hLwu0+ZYs/4MWtDrvq6KxtFIO2JIPy/AwiufiMLuFO64gEzQ3mBLIoNJMfbuXwGW2FpZuXU6yby+NwF8+wyde/reiJR2lEm0O7mWef7kWV+DN95v9eEzIorWBOAeCEj+QjEpMinaRuD9MbolXPmJVrevRZD7lqQAzhw073dutX9eqgHlmW3YGqlud6N7IMSMs30DaeEA7Ug4m+uDYEtjzPaGp0C3VDap/EBjLQwpWr3c3N6dbIT5MXTlR7u8zRcSD060GDSzIGq08WoqGZz4ftHzuOMF9VonbwG97KMEHD9qE1Uo5axTlYvLKJVEL8Rq/YevQkcvMAx61ho85xb5NO0dLbwNIEXkG5TFsw5ylnIYdmC77i8VgPFmSMHrp6jGZ4MLaYzpioACUDfQBzWeIo2bIoGPtRsXmGQLVf2yBBLaNEfWRFBA7CFs+xA58Fb8S0AWbhsAODcfuhRyW2q1V3nHvD+MCFFDAJCJANXv11/udMe0FyJiKskwyMi+xauCQhk41zrLdsa/cwjVAl2EKt2htxm5M30lAU3SqAHbUU4G/ofOCSDnO8pTlkd5vWXacP5QNEwZnAdu54cXqESCZz8Yl3Mj9qNAxH9Tl/tsnw==
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1031; 20:XLj0t/jsyM9B3rZUoGm9bq+onLS3ioFezdsZoXk0euzIaXRhQeE1RObJoGPD7cZXnGQenzHe6xq/nso3aUPTXmgpxN1Q3TNh+SDBrhss36biaa5PWeWa6CW/CMlEoJ+enmbgOuaO/IgYa972CWNvgBYZfs1+M1JnKLMO8Oi34w/nSCQUhdPC99ynssWch39JGo1fwXJZOzo3xO5zhEtMD8D1PSIKvuB04lwH1Cd1v1IK8zeMlh+iJwhtdNfwdF8wS4sX69uDFRyyojUfge9pDvUBxsO7QK6Z9Axk7LBsYfLBVXsGWKiWxSmNblhRKFOk01jS/iMkLp8w+TTgz9557xWdLa7LLwcX0LQ2SsSALzw8BuuPS4XJirbUqz7vpuKDwKrVzKZqDTWVdZxh0iJT5y1uTliHBo7sns88WdYtv0jEy5rmeahydc/wpaDjlgXQE+MojsFjtRlTTqwlHlMyRbEbg1yMe1jeL5ml/ifHPbyF12T0WA9vQH2dqJsv67kh
X-Exchange-Antispam-Report-Test: UriScan:(60795455431006)(236129657087228)(48057245064654)(247924648384137); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0101MB1031; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0101MB1031; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1031; 4:Lzv2omMA693s/Vv1idsYwoGEd4pisyN2S3sXXdRW?= =?us-ascii?Q?vWnzNL/vKRcBKnZ9qJLi+EHtV0w+ChuBBKLJQFUzCjX0DnfazrxYm+cFYQwc?= =?us-ascii?Q?xvnQgs13ju3tYTTqTgP5T3Km69K89kgLUnUMZUgvTPc9CjgrXt8GyTZZmFVs?= =?us-ascii?Q?OA4S4/u+151agnjuSDFgt83LoY0CoZx+7LNTEOavALvq5z/g/I+K938ZyrDz?= =?us-ascii?Q?88OZ65a4mw7Qe5dLGcUBskLyZFQ18k1H1xipzjA4hHsDS2AfT6RfL/W4Cjg5?= =?us-ascii?Q?5/P/GUyDNkatC1ny7qaBogyQm8PdD5E13NmRI2DRmT8RwdhBqCttqgU2WYY3?= =?us-ascii?Q?AhmNuzRBxMy6dH2wIIFuTIX/A0Cs5ENyTNUvOl2/oQql/yge75dHL/QRN52O?= =?us-ascii?Q?uFnwAkH6yXBFwwjGtWIa9io2koAGq9FfZhX5CRlfACoR21muPYN26qtpOIiu?= =?us-ascii?Q?9uFwSfKOqmyZJrUuB+qyNB9YtNFc5ZVgndSfd8dy0wj7cCmTupUBHrgkj8Wt?= =?us-ascii?Q?16Fd2mXUqhmK6XswH0l4ArYkGlZRgHyuMJE/nzlowdzzl4JNe392zxOmTshW?= =?us-ascii?Q?dGoFHU5TDu1HqxuTmUPWan6magywkhQ9tB3092EJVTrPwPVah+dxXMUEd6Sk?= =?us-ascii?Q?exDApE2S3McfhscYGxPjcHE9JDIooZ5xulShHnlyQjy0wmfzIxibCoc16uPa?= =?us-ascii?Q?dfxGXf+gbhTMLJZojcKFaBV2mIl7AcnTRzM7JisRDb77e/K6f6xw0uG6xjsg?= =?us-ascii?Q?waiuj0zRHMeMVTE+wISl+2Qob6mnjM+6fRK9PmRY8PMi7lKoL3SZqwfa9C03?= =?us-ascii?Q?UaZp+qDgu0QPo6zUyRi8EBKL8/xODY8moBZDZPTKgRqEKuMvQwppnKV0zT4n?= =?us-ascii?Q?bMeNUZP2nWd2jutQKbQTEgmLihNSnCS3n3Ws1UcdB0JpLwrbEbgbCBWLFZZt?= =?us-ascii?Q?YsZh60uygF88arPSuBNQp7tUbAa981jv3HaMrhwkzewNp01WdjCjaOOqQmgz?= =?us-ascii?Q?yTWYwvBieYY8OktuwCGOQQoWuYWaiiPc7BFqDtqI3nh17hMl+GV/QRFHnh06?= =?us-ascii?Q?ICTVHsoN0I+8S5NVuGVupw0/DiGzqGYOa8OTCiilzO1qVKC5KMHg6nVAkGgr?= =?us-ascii?Q?PK9FSZw0eF64DfuWeQkGRS8Ian/TuWrJy7gwEonnRU0wroQlyjhwCacRP00L?= =?us-ascii?Q?4ayDkEkRi3sslDiFttevr3HPNw1dG6F9ZfxbSnhFH7uqj/54AAvNGMu8tS92?= =?us-ascii?Q?/XKr8Squ3+SBEEbMGBV/ZYMWsYKzKof8tXuhnDZKWhe+0/SGwkOI4hyOSdL0?= =?us-ascii?Q?NiUHQeLCb6Dz1LtgXM0gTrM=3D?=
X-Forefront-PRVS: 0371762FE7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(24454002)(76176999)(3846002)(7736002)(189998001)(90366009)(8676002)(50986999)(6916009)(6666003)(2950100002)(5660300001)(305945005)(229853002)(6116002)(7350300001)(5003940100001)(77096006)(6486002)(93886004)(50226002)(81166006)(42186005)(4326008)(38730400002)(53936002)(2906002)(66066001)(50466002)(82746002)(110136004)(230783001)(47776003)(53546010)(478600001)(83716003)(2171002)(36756003)(25786009)(6246003)(86362001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0101MB1031; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1031; 23:xo0SiMlMwWIGIegrat6ROzLvGXu9n05HA7Q7AMN?= =?us-ascii?Q?tYQ2Fk2HmYs4yj6AINoaJ/ZFy7b443EJ8KEOdDaQdOLQ7jv8NdJDBbwX4T1f?= =?us-ascii?Q?PCZxj1KAeteuJbRkws4IeXqf/GwNvVOMG8m8PeMk0q20psjc0pkkOQfjiOQg?= =?us-ascii?Q?4Sa8/7ygiHuSX/jVLSWBClvvTWPwvwabxdrpC279lw1uQ8cA7TOrIxvx0EH6?= =?us-ascii?Q?pAQnefEDt7HKKN9DbW/naCMbPUAFIS6HKvB3R44Nx3921hQqmki6Zlnp18cD?= =?us-ascii?Q?XV7JoKi1ZBNw13oMx2AX4nCt61Rz3AvU1fmj12wjOSee9X06geg+9XJ9iThF?= =?us-ascii?Q?gVOdLZ4X7/CTYlE32RbnaLUeSCiA6IJW/UEi3tnxVrbPdtNuZiL6zLjhS+P+?= =?us-ascii?Q?OI1UPhH/BCkuTjwQdCMk/uHYiyfLrgQf9OV88/y9Lp+bYDghsvNepfpzKBTh?= =?us-ascii?Q?keYVab/bC8JQ9rmQmf6kbTKOIjGOhXRDzOw8U+rqB2zbOHJFK8BN9IAcUm1L?= =?us-ascii?Q?9+HmOXbAMd94SxO5HneXROVZKc1q2oasIsOSCTyndJWsRwvq6q+OIzpjGJP/?= =?us-ascii?Q?U46R3p5A7bQp4JyhxrkU4ZVwO165aOrbSAiUSHeFvgHMY+VCYPJ8PekrGPHW?= =?us-ascii?Q?wMev6k6ItMUn1/AQHTz+vXdp+hevNumifmnCMgPXVexvv8GfyxjqByTewKdw?= =?us-ascii?Q?IURmY2SUbJ3N4SrFt6N8v0uXqiXEx1aJCPzvfuOIOE4p1sArKRIT1IR0wxFc?= =?us-ascii?Q?7//EIdxYEZG6jUjCKLnPoQGAtMKZnoOlUuCiLiOBGj24ygdDTNzUeill95qQ?= =?us-ascii?Q?ixbl3WQdAcXtnAB5EtuPCYu23t20rLHRMImdLRvpmHl7uukNe/SuPm2TMQmz?= =?us-ascii?Q?AEtvb446J5Gec5p6y81HKHYcm1dJbO0m9yrUxezyr0JhKMDhqJNPobrsMGja?= =?us-ascii?Q?+l9n+90ggbIzxHt76de/KZ07ZXhxxzt67rXRf5f1dLtV99A0CzDYk+O85RAP?= =?us-ascii?Q?NsHKyapk5GEHwHa+6LZ3C6ko8emZSFHaiYzDD1P9ljc+HQBx54hE+5BqmwUw?= =?us-ascii?Q?NSZ7IkTNG1NEzfXGVCWZcdNgjvgI/JKbjSeVd6WVjsq37tfhfvPdOg7VsQbt?= =?us-ascii?Q?p3EYzq+wjJqRPnza/vVBfWKQbHu+aD+8YfqiAMKvVJHZ25ZU3RQj7KF0TFoi?= =?us-ascii?Q?vu5jE2JZpMy8iOYqX6zkWs/mq9Qy56loWChziOXafyQblOSWBX+iGqUNzCUJ?= =?us-ascii?Q?RO3IL5ylBMmCSQvGZd/B56KpIr8UOhaqFGvQwf8WG?=
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1031; 6:gMwuxa7VmAUhrVpZVu101yrlYDxkHsVXGPRDkLG2?= =?us-ascii?Q?wNk1PjzcLHIugAYBNqkSEGrDV0Ky/KZf6nGIq18p93xjOJt+5bZVQ1VViCPq?= =?us-ascii?Q?cMIf/LUFh/si1D4/lHp/9js9ryhN6cbWVN9Clz2JlcDdZmYVFBJywGnKeTbI?= =?us-ascii?Q?STTc2y9M45U7smD+pCpSq8+kDY4SgzTxrZvdrAdCwhwouEqY6N4vJ++2LVJs?= =?us-ascii?Q?xwPwNBAe2ndyHaKx+NjldKEJFnIe7idF+n8fExj/V4pZ+st+oNCawoxD9uQN?= =?us-ascii?Q?dmRwMhZLUvNXxvT7mCv97rrYZEXhTgnAWx3NmcRUB7B91xB7gcQ0zhJcMbwE?= =?us-ascii?Q?BFuvHgex9c6z0N9SjPSAmORD/QlTcLwpfYaJtqYgDuRd21URjH3ABXrpIdUs?= =?us-ascii?Q?98OD+E6NMAztvCo+cv+TjuT0V7sJnGph7Jz/wuOF228ZuwU3rbtK7lZLBeE+?= =?us-ascii?Q?XN+3+37BBWsvute0DQcf4QsFMeKYGk0tl9/wU/k+E4rQaZq+OQ5CUlnsI/1e?= =?us-ascii?Q?clySNELcyBflLft/3qyzY2o0GZyU5chVHvWXlJer0pGihQMyYrZso1m4bp1c?= =?us-ascii?Q?BIqfFNQFdK2gIQKjQ1VKXGbBOBibrE+e1fOpaoy8xpRcyExeneZMc+nV/AUr?= =?us-ascii?Q?JuvkWglXpEDwnimUpNevsm5b+kuiuQyxB8JIPdsNlSSx7wqd1SxyYZtXauP9?= =?us-ascii?Q?P0H/ZpRz0PDG3GpJ0eJCgPT8ux0HoB+tLsRVrtX+VNMdR4ECMTq291iuOd4U?= =?us-ascii?Q?GOAZS+YiTlPZvIG1kn0K1zEn0aQoZehUMhhMA/33Erm9wpjvxWTgjLGt1ERi?= =?us-ascii?Q?h0w1HB0Th49Ky22E6GBaJLBzZzf2xfXuMEuKt4WbX5p/n9Kt3arnMO3DTd/0?= =?us-ascii?Q?9sB3wwXmuC7Qc6z5GWvGFGoG3eEG4IAQmOamb3E+SNQyPYIwlX8TTbr+tVet?= =?us-ascii?Q?kUFcW30FCbJ4t4U7PruIc+EQAMIpwBgIzt9X4vvWD2LjQQ40H9S9tPSbG0vK?= =?us-ascii?Q?yf8=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1031; 5:deQL5vBJUD8t/CaoVqvSCdpJA0gHNBOMiPEBzsccvOdSxIZKoj1Jbi06+3zhgzVqmCeoqPiSe5neni8tPKbDyqUJc5BTVS0eUvpt4aW65hAyddYhOXFAMY3adT9roWnXgt4owQtj2p0EaHdNn5VK25Ux5n3Q405myKRdFQCa5SXnzyPbWkHgHw9CazHcGWGn+RoJN6YAnslZdPMys3gleD2SwCgO83owJcF43xssnGzV9O+RQ+ppJ0g8wuSCsSnM/DfKFCysQmUNrE+xl2UNmMsLhHBdtmXjLIxTkn1JAD8uqOYd/+Ra6pr2pNz/6i2BKHYcAGOUV4uQXWNEH+jslfNY/x2JJF3ULR6eqTo8FNhJb6x7/UFNpp1RVzGZ9Xf+XZZK+XHREiId15H4GATrkvKeaI8sZwzqhXvku5VEcyo/hK/9kbzsYVfrKPyayWSyAkCbLJiAoBnyQm4ViD7nyw1HT4nxeaHlDXwibQhnlnaOq6qs+YSgeNpsKz5Okkwj; 24:X6dvlNizdTuM6h+uCq+I5h0thvO5BmcVq34zOO2GYPfAhI1AvYk+E+tbl9EeQqfAcf6sIoezyJ9b3fuUOPIPn3b4UczWqwI165CbzTm2+I0=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1031; 7:fIWvoYV9L72Ah7RaRTJH+5H5mxSiG9BvJJkochA6BNsTGlzWI3UeToaLwm+h8RJYqeWDgvnwBHbv5gyKRjqeWV7fF3V0iRh4Q80wGYe4p31e01AoMXmaEXBiu6DlIhDPEQGuiEw7T2VNQIpRdFPUp9tFU6pTvNCJEahs5gcNQHjmN8M3rO0j3QKM1Mt5jjkNwedCfW2UCd3sxUzREbFfcfXe6yjTVoTNfak5XVMbEfnep51l2b5RVOjrs83A5lxITSWTEhd8kGcXbnEM4hZ5j/r7o4zlAZVLZl0/UrCQ24TmE8y5Oc2LVoVmLouhtNcSMYf2pYLK78+oCJEVVh0/SMlnsvtv9aQ8YIZ+eHjYtNznLxwml743RNdUTPKQ8xvwnGQGjjVtKH8hUQfHmC6D4Ga7+gDeteUlCQPSlM1keOmfPlJvA3hrKkj/NfGMNsmYyeHj43/KV3aBz3U5QVN8n0W49kUcHWex8hq59JsM1wZhy1s/A7lQuwTQ4e7w7OzRAVq6OAgiMEgkTVLDKIEMjajEh9M1HAN22FK5PjgJ2opb9BlR1iRi8Qr1tnT4nmlEjCaHZe2XUY1eIUWiLyFCV3lpsm98zEchmGC6zhafN0iJas1dmy9hlprDIV1uDBivgVOALDZg+rZhFbl9xlt4nQTCsO777VoGcLEhjYximO8QA4ZapFJoYNyLqYuka+KpXqh2fZffoXjkRN0hArLCJqyV7EzDbQamQlrDWPRCGgAhgDQhcfTrlNAcmwL/jHBYj9TkUzd6n2gs++bgGGQgyrUtRCX+GdBNWOSGzolqqt4=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 18:53:46.6771 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0101MB1031
Archived-At: 
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 18:53:52 -0000

On 17 Jul 2017, at 20:49, Roland Dobbins wrote:

> Based on my experience troubleshooting, I disagree with your 
> disagreement; while in many circumstances a great deal can be inferred 
> from one end, it's sometimes vitally necessary to gain visibility from 
> multiple points in the relevant topological scope.

Also, it's quite common for the party responsible for the 
troubleshooting to *not* have ownership/admin privileges of/on either of 
the relevant endpoints.

-----------------------------------
Roland Dobbins 


From nobody Mon Jul 17 12:11:18 2017
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 97DC2129A92 for ; Mon, 17 Jul 2017 12:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QbBMecblecz1 for ; Mon, 17 Jul 2017 12:11:14 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 9EF5E127B57 for ; Mon, 17 Jul 2017 12:11:14 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id q86so80802259pfl.3 for ; Mon, 17 Jul 2017 12:11:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YQvPdPrn66mDXzqaR41Hw6m5IYmOegActqy95+FnayA=; b=n+EeXeE8GKu/lOmWszHFJEWbWKwnAJg6J4lfefHbQ0M6sEmG8VFaNApe38HlF1iTyP H8Qhh8L1NWOLOOh8XAIJ4H619CkfihkquQabDxDbnX8YHjK/OM54CQBJ1coai+5kXbT9 IIGsAIujku2CkaaziUdcyPVNkcpyJDS1G1H5jmrEdZBYkb7Thx9K0M+98EGe13jLO0dA IcJct2hGBBG1db9Tio7aLLqNvb/Y6oNg00tVblRF5kOmAv3iNWG2KZvBXbyolWtCeGGe 72Apa8fcGDD7Hfn7CVjrgD9wmYknyb043OQdcnkTBaQJdZbRuENygeCjwVArPYLz4Iq3 LIxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YQvPdPrn66mDXzqaR41Hw6m5IYmOegActqy95+FnayA=; b=uOVYAlcrPoblgQeNOxtpVbbiAA6FEgUTA9qSFYe8MdA1wSr+VhLukDMituvR37MDFq Bk8eSFa9gjqQhfRr9GjvBgBTwSkVGEtnKkDSadTLG+NHk9saYAhqIeBI1SSsuEuIAHHS nf6Cv6xQTFiehXGWpiIcsExUEkQ6pCMRcFt0xVZ8nNfe5UfMs3Uony02AXVS+L2IAKNY NPJwrzAU9c1++v/pUd/ZcQ/Ih/CYsaTtSbTbscusGKh8dCxGhR48wWbZylJLg7fvRdlc qmMpSX4/0rEO0k/vBZju2EO/qVNui5BwaWwSIyXCwDsCWIT9CFdxTANgHFC6aHFEdRj8 +kzQ==
X-Gm-Message-State: AIVw110WnlW5yo/bXgBKWv0bzCm4ehFuKoyNXUH0sA9MmEwueqaZAmhX 5yScmo/CJc0uW3nZ2RrW625fM2//FQ==
X-Received: by 10.84.217.144 with SMTP id p16mr403656pli.276.1500318674262; Mon, 17 Jul 2017 12:11:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Mon, 17 Jul 2017 12:11:13 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Mon, 17 Jul 2017 12:11:13 -0700 (PDT)
In-Reply-To: <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>
From: Watson Ladd 
Date: Mon, 17 Jul 2017 12:11:13 -0700
Message-ID: 
To: Roland Dobbins 
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0029c6a11f71055488291e"
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 19:11:17 -0000

--94eb2c0029c6a11f71055488291e
Content-Type: text/plain; charset="UTF-8"

On Jul 17, 2017 3:42 AM, "Roland Dobbins"  wrote:

On 15 Jul 2017, at 3:40, Watson Ladd wrote:

DDoS mitigation can be done at endpoints
>

Not at scale.  That's why it isn't done that way.


I'm all in favor of things like mod_security.  But they can't do the heavy
lifting on boxes which are already burdened by handling legitimate traffic.

If you want to detect unauthorized access to a resource, having the
> resource which
>
determines access anyway log that is enough.

This is incorrect.


How do you detect unauthorized access separate from knowing what
authorization is?


Exfiltration detection based on looking for sensitive identifiers doesn't
> work:
>

Yes, it does.  I know, because I've done it.


real attackers will encrypt the data and dribble it out slowly or pretend
> to be videoconferencing.
>

Believe me, real attackers do all kinds of things - and the most common
exfiltration mechanism is to try and get lost in the http/s crowd.


Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?


As for attack surface why is "Press here to get plaintex of everything" not
> a major, major increase in attackability?
>

Because these are intranet-only systems on isolated management networks
with strong access controls.


And the endpoints taking logs won't be?


Which DDoS attacks specifically?
>

Among others, application-layer DDoS attacks within the cryptostream.


Applications can rate-limited their own endpoints. You're telling me a
dedicated out of stream box can handle this but a beefy server cannot?



And if the traffic isn't hitting endpoints, does it matter?
>

Of course it matters.

I've not personally had the pleasure of doing this, but I
know it is possible because it is done every day.

Finally, most software can export the secrets from TLS connections to a
> file.
>

Logs are context-free and in no wise have the same value as being able to
see the interactive traffic on the network in real-time.

The capacity being asked for already exists.
>

Yes - and now folks are talking about arbitrarily taking this capability
away without understanding its criticality to network operations,
troubleshooting, and security.


No one is taking away the ability to log the PMS to a file. That's the
capacity which exists now.


The fact that we're even having this discussion at this point in time is
because of an astounding lack of due diligence on the part of those who are
pushing to remove the capability to monitor standards-based encrypted
traffic on intranets.


Alternatively it's because you've decided to run your networks in ways very
different from the public internet and used this as a way to avoid
organizational battles over giving operations the tools they need to work.


-----------------------------------
Roland Dobbins 

--94eb2c0029c6a11f71055488291e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Jul 17, 2017 3:42 AM, "Roland Dobbins" <rdobbins@arbor.net> wrote:
On 15 Jul=
 2017, at 3:40, Watson Ladd wrote:





DDoS mitigation can be done at endpoints





Not at scale.=C2=A0 That's why it isn't done that way.
=




I'm all in favor of things like mod_security.=C2=A0 But they can't =
do the heavy lifting on boxes which are already burdened by handling legiti=
mate traffic.





If you want to detect unauthorized access to a resource, having the resourc=
e which



determines access anyway log that is enough.



This is incorrect.

=

How do you detect unauthorized access separate from=
 knowing what authorization is?





Exfiltration detection based on looking for sensitive identifiers doesn'=
;t work:





Yes, it does.=C2=A0 I know, because I've done it.





real attackers will encrypt the data and dribble it out slowly or pretend t=
o be videoconferencing.





Believe me, real attackers do all kinds of things - and the most common exf=
iltration mechanism is to try and get lost in the http/s crowd.

Yes, b=
ut you'll rot13 or rot 128 the file first. Why wouldn't you?
<=
div dir=3D"auto">





As for attack surface why is "Press here to get plaintex of everything=
" not a major, major increase in attackability?





Because these are intranet-only systems on isolated management networks wit=
h strong access controls.

And the endpoints taking logs won't be?<=
/div>





Which DDoS attacks specifically?





Among others, application-layer DDoS attacks within the cryptostream.

Appl=
ications can rate-limited their own endpoints. You're telling me a dedi=
cated out of stream box can handle this but a beefy server cannot?

<=
br>




And if the traffic isn't hitting endpoints, does it matter?





Of course it matters.



I've not personally had the pleasure of doing this, but I

know it is possible because it is done every day.





Finally, most software can export the secrets from TLS connections to a fil=
e.





Logs are context-free and in no wise have the same value as being able to s=
ee the interactive traffic on the network in real-time.





The capacity being asked for already exists.





Yes - and now folks are talking about arbitrarily taking this capability aw=
ay without understanding its criticality to network operations, troubleshoo=
ting, and security.
No one is taking away the ability to log the PMS t=
o a file. That's the capacity which exists now.
=




The fact that we're even having this discussion at this point in time i=
s because of an astounding lack of due diligence on the part of those who a=
re pushing to remove the capability to monitor standards-based encrypted tr=
affic on intranets.

Alternatively it's because you've decided to r=
un your networks in ways very different from the public internet and used t=
his as a way to avoid organizational battles over giving operations the too=
ls they need to work.




-----------------------------------

Roland Dobbins <=
rdobbins@arbor.net>





--94eb2c0029c6a11f71055488291e--


From nobody Mon Jul 17 12:29:26 2017
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 25EA7127B57 for ; Mon, 17 Jul 2017 12:29:24 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 QJIMwswi0QfN for ; Mon, 17 Jul 2017 12:29:22 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0126.outbound.protection.outlook.com [104.47.41.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28463120721 for ; Mon, 17 Jul 2017 12:29:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Re4OsVuCmIc9qYkVxr/xXkQ1MPNNuCpSESu2roW9MOs=; b=PPSGVJ3yxiEjUEzYk0BWFFnNLlBGfksJoD0TNX8fZ5gMV6z7uCeX+bgwXHnwkL0VLfH1iSb3+jACsaOphC1bmDeZ0M8Wl+baG9kkzC5euqUowPAA1Aps+cF/EyvAt5AZCzHRPNufyQsJm4A2gxOsRKHN/l8hbb2GxcQapyMUV8k=
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 19:29:19 +0000
From: "Roland Dobbins" 
To: "Watson Ladd" 
Cc: tls@ietf.org
Date: Mon, 17 Jul 2017 21:29:03 +0200
Message-ID: 
In-Reply-To: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: AM3PR04CA0144.eurprd04.prod.outlook.com (2603:10a6:207::28) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 90f48101-6756-4048-a7e5-08d4cd4a1f68
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; 
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:a6wc/c4QhR4ooKdKkMNTKJKf4YaWcQf6fK8LzlrQNet4jYQ+WBs4sJEL3DvtGMBmJb9KmDtn73rpU8GvQqfR14m96wWy3NVqUn270DRWRPJUaWTb0pxs0VNS13kll4kXKsVCrv8gpglI9IuuqjQQY6yE05odV2a8/lGHKcKlGdlVfSoq/ICDSJd1ki7W9Gt6k4MkYROxX6maukKHK8EjLgZ2PI5AbK3oBZ3INwigT2ZbhTiqO3gygiV57mvFhC3Gplp/a0h7zjE/dNUsZaCWUocDhwGX2pQLmSCZGPZW8e95/jm/M8EQTaM5hXBFV5JABRzegcGp/3q5LPWSpteMKiC9IyTwfIHcfMko29mfDUiHHqFmSffxT1tPfYmMCh51SESiXuzjr1jWcFqFlDxr2c5qFvIk4QK/RiSLDhR/IVLDxJ9060FNjUxKFbM6WQR2C0Vi+NdrRe9QCy3ityIPXtnENx+OOvt5zmC6CD5q8JyCwB0VFF1YcnUUHHZFYojyLb4Jb8kRMKg8j/VFQLi3RIZPR43tMH3A1E8hlAB8hdyvkTR1PJWAuZ437MUIgstEUOfWOf5Sy3T7IgdkbcYw8hbgYuaTYWRYda034AGph3bCs3cMPDvkYcebGGtNX3sxTn8lAHjjt+NqH3FcBY0xuCHXmlDkbg10E4sMTiywV0ZOHHlKj/mRFafmOh13G1s2VRCs0HA+KdWndj2vnuIa70gXELYVIEMadNg3kDB4Q1Q=
X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039:
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 25:NeABrQZxMieuSEzmg9NOxauz8dAcsUFUnxbBsT+tEXOm2ZI+jyPCDYV5IZrMaH36stbf5RC+M9QnFsN6vleLjpnarTQov05VBuYBHVoPXwOTm8RPtXAAnb5GoYJJNdr7mzqoQOsjPkz5+Hv9sciviyEhccSPouhSy2Lz0XhRy0iM90a+RGLHJg1kvWYdUXgAl4jxQgX/dQTXaAb8loTsvx7MEzGJePv0UZhwEOzYjUnGr2s6mknSlpdDof0wg1yesSOzpABCGY0q8sIHOgUR/HDaq7rvBJ/kTJioReKXJo5k9dFcCEZgsCyHHvTCm36aoKLqEze4SiG6G+pjDXxXKRy92Y6nBxGxIZ2TI0tRlORAx6TKS3BG2LV2UXTzkDqKOIiWxps1S9n4EL2ECZ6C2tvSlLTzPpkdfxPgL64xQNEe8XAqWx86Qvn1uQTugnPI1BAhV0FwPty8+yW+ZXF5PnVFJe0COomS79T6vTxtGIqbd4YohlafAefdCTDeV7edjLCHNV+IasC2uMuNjNn/R57KVEWcJjEdIQFfYV1o+bNArVNf9G5NgUVHYqTLun35HEL0ANE9SDlzV74HFVb7JxDTzKRxZ63vZmSCLdqZPuiMYvsyy+KL2EOKm5adBcjo+KcDzNnPz0xWq8bYDWv5wSCIg+ZDO6zKPZeZQAxyuumQOObSRXeUQGsNPdU3OiHxUAB2MaoBqqxqBxuN36f7zptNz75Neiy5YfM6jnkDt7JvO4dj0wyyr9GXKq9cZkNttYhxE9wpCn/9H7sh6W3QZwUgsyRwuszClzW4GJiI8/5S4liRP4EUHQFaa090cTiyRZHzOnPCptKJsT7v6STwgLFyNMdmLkEvR3owPNFqzhWzFstvgXb0lEwY8M0Ex8bVsci5sC3aTKDS6zS3M0iERgJ5SnIe9TTCdaJO0Uw146Y=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 31:5cCI+6gkRaELp9Hi6GbqFgVI3R0iGtFjrTBV4Fjh/7DVHfEOEfNf4DUkEXqAvsW0O814gP8Dxf3bWT07eBY7cXLCTQw5SHYqAc+F6UAsdRJP2hgXGDaZiAqQEMJLRfCfndSEs6m8/XqkaasSU+3q4B8HMJHN1C8bmYQX8AxDkZ1seiHOENtevoqTejIHAcLiDdvjzVOTdPhdZ1zyqdA8eKlwdzcoVdcx6kctaNDMzJaxEnMoS1pq7qwhFOLJZs0rYHXL1EIf7WFjKxi0btcpVzQfzpS9LeoXWGbTyxsWaETlUfw9UEIfPUIWyqiWo05bnplN5YO38N4WFqvmRSeMZnfPhFQaJfCxVrVseZA6Tm7FKaoveIDAwzbKO7Zw2Pj8UDm2/EjaU5gyxB4bYWNlwC6BgXoTxmt8UGIoMlcOT+p6gePBvMQEOc9boF8dNlQnIWxkfuhUutyGGDK7cLqYc2F9ptyM7bksxQ/N8Lv/PZMGKaMaxpmru0GHcwogI4zBqb3RnO3pngsbG1UkQtyLWrH8BEmkHxe5yNz3bQMxWds/jfo/4h4O4ayaIQ5VABx+f7FalgmAiEmSowB4k06CE1E1aTvvEJX2/ghfVhI/FiOZonBE55yjd5C9ap6LZgrWJgb5IehuRvTXGCRg0L2v5vaexBICyv9+m52Nuj0mVvySqa18ROwsIM3mDtCD0XykgCLwLphLouMXyWjajv+8dA==
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:M42vhY6i/2cCUL2EjIbFXVpz4xiD05kZSwviDYxqWQE6csaWs+qIMfuUrjv0F7bIEKm9oSxdoez7xAvdcVCe/6a3WYSU6+W7H1qE0m4J8XRXb/QBYhrTF2/dEwfXZJgzdtO+xuMVrmK7AowYDCBFNRnSfeL9dD3jyBP1nav63CeirnCsPPHAEr6UFoMmiUFA9JFfuC92VTQxX5AXWeG9LK4J74XPQ7IoexFsnFPRjl/iMnShf4+mzLdm3GAEH3ZAr5SQE695IpW7AjC/6VZCJnClyp9AJtsWQdaorvUJ2/ESbkx/X53xwqO9E7u/WBqlWEZoAowgH1W6LCl9g2mdRMrFn1hfW6qKLNxUwIGGUsVp5KQ4Qub0edb076mjUmZNh2GHnHkJGa0ln7wX5++nA5vRfKnwYtMXW7s5TvbZFsGegfsOVaxsSgbSGWzoiLt3b6Gb1OAkhi9NQMY9jPdOiuLzEKfmB9RjepPKtjsVPBN2M35rOSUBFwH81YO9d1eN
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(278428928389397)(236129657087228)(192374486261705)(48057245064654)(266576461109395)(247924648384137);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 4:vk6fktM+SanirFe4TA5LVbTVEQ9eOsujoDa3Zo+p?= =?us-ascii?Q?EmoURYk7wLuVNEBnjcFo4yrnGI3ZIczI3F820cPzIPt+dn2PrwXsMLRaJ106?= =?us-ascii?Q?AsN6KB1TY7aWulO5hcxWddgQHtnw8N6wF1ap9uwVfSNy7WdyxlhPTGuiP59v?= =?us-ascii?Q?vRD/B1CLQ4boyC71LL9//J34tFanofbG3vAJ5NIErhiQ2Uw/myAWc8ZzdAJO?= =?us-ascii?Q?pWpwUvgNiiTEvk53r6YC03x8HIoEeFbpGL8MROK9rAob67REdlKIBJrX8Fdn?= =?us-ascii?Q?QyY6GBXIcjHTf9ZmOgFhQCmmpw4A0xyLJow2X49uX8f/axvsfz5wKMh+RNi6?= =?us-ascii?Q?+uF7sNwztM5O2BMI4ynnLXhHvhSN3AWsLxUj4jQlI6VOyXXnSX+2YzWXjDSw?= =?us-ascii?Q?2PlBIesX3j+g/Ld7DhkX4E7NTNB8uDG9Xi2i80Oe3dZ1pXq4l1/NU/m5xgM9?= =?us-ascii?Q?8YBjWmZkz6BT09k+KXEVEFuTrhTO51W7jsjKJ/bm+9tS4qx67iARa4bMdFt/?= =?us-ascii?Q?FWYutATOrLHaSyHK5eg/FfzhxbVEWZOxzezZXFIgqrGw8BY08+kCaVXJLkrT?= =?us-ascii?Q?Xiid6tqBXFL3mQFpuJKKjkcFxAvqhd/x26s1jrem889MFYf6NaK+eLaFSiEY?= =?us-ascii?Q?2NzZO6CbnI4gnv0QCgcMm0wgwBDy31oSe5vyBu86pww9uoA/LB8oDR6S09Kv?= =?us-ascii?Q?QpYFPUqyk//J3VMsQRLs/WKjP4aZkd6SppAoX/YfgzbH1EddX5QCJqDXDGGN?= =?us-ascii?Q?U83QBS4QHkH7ab4ldo9uq0ZHFEvN2XuBVEk//Kjui0EKeauTMUR6/Y9unzMb?= =?us-ascii?Q?vZLDjUM/UqePUQ5M719cLAXVRn1iIF13OGbx8hfANsC3CSFDhGuoOoNIVhti?= =?us-ascii?Q?h1KK2xF0agqvbUJ7WfNgCQ/NdMiMF/itwi1kqQ2k/5Jd1K7XS2gvzBigJJ4W?= =?us-ascii?Q?/HJZbxOhGhBsZW2DPaVcSycUyyiyPVQ+ppUDpSEAlamdsPYSLibMh/DuEZfY?= =?us-ascii?Q?WGZ78vi0qMeF0LzNKNBdlXa7pSwAVRnMm301W6hELl5JQWKpbBm306BGYGuj?= =?us-ascii?Q?0lmwAs8FeVgtyLnKDQI+oZrPsh7C7m/dM4sISe6RRElxekt1TiyyHpDtoUYv?= =?us-ascii?Q?OKccZuoxF6v7HL7KIu1s61iqKG2QMsrYvE49BR5cKfmg/IImaGp++Yq1eGfQ?= =?us-ascii?Q?hJr7qbX17kzeNuh7u45y7d/k0SxnlnLMmxl/+mCiMDWINzMulKRK+hsbCSHL?= =?us-ascii?Q?VTvq5tXcPWGzvFNMxe5es6Y0eS5Dg9pw6L5fHFCkQ1fz0zWUskv5ykn4phHL?= =?us-ascii?Q?H8XYlZ8FhozApGLXzENMPjUUXPHpG9/OCB6OdDddvJHNJ4JngrfsTH3+/K2I?= =?us-ascii?Q?D/OVqhAED/UeO3gUVsIo2idltkHWIiCYKwRy/M+094RhSLge7Mf4LcSK/+hl?= =?us-ascii?Q?PlZ7wGBneA=3D=3D?=
X-Forefront-PRVS: 0371762FE7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6049001)(6009001)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(24454002)(51444003)(7350300001)(86362001)(6246003)(25786009)(6916009)(81166006)(2950100002)(110136004)(38730400002)(36756003)(1411001)(3846002)(230783001)(93886004)(5660300001)(6116002)(83716003)(42186005)(5003940100001)(82746002)(50466002)(305945005)(53546010)(189998001)(478600001)(8676002)(7736002)(33656002)(4326008)(50226002)(53936002)(66066001)(6486002)(6666003)(229853002)(2906002)(77096006)(47776003)(50986999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:zyeWOiB3a5BsfjYlDoM4xA70Vjh6wfch8Vweifm?= =?us-ascii?Q?YOu2yVhLeZw1NEibnDwOYVs7QoqVU4aXgXz2rOvXvYEUZV8Qb+CQBkDRH6xK?= =?us-ascii?Q?NP9G+EwNymQguthBqVuIMGwGkquXXyRB7MlMCBG4w2nDfS7V/Onho1eGFprj?= =?us-ascii?Q?7HIUhxS/m3feWP/VeJ//Z5UrV6JWJ8GZozYW/NUOrX1ow4Ffdk5MR4gMTKIT?= =?us-ascii?Q?3IvWIkKpgAutHCtweQXh6zF26CG8vkPWwkZnWyMC3wshT1XvWByKdoAFCBUF?= =?us-ascii?Q?GSmJogu1EAOLz9VEVuyl1NLntct1dxf7ISU2uSVRSrN1TuPIwLLBcQ/3AGCW?= =?us-ascii?Q?imNFLvQCpZpTr8gKKhERTN5Fq8YfHf82njVDoYOACKUv/3JNj5gBLw+dBprS?= =?us-ascii?Q?yGGuJHLPMMLUMyy08Som/aJfi+mmDYXFBT0g/aTGm2k55ioZYbyx0FYo1Anh?= =?us-ascii?Q?FcVu6Mycmz9bKIdiDSCcyX0M+wrYAeDZLs3G8cbpxRMvq8IromEMoP4L2b26?= =?us-ascii?Q?5I6ScPAVRAm4Fzx3IHXFeMT/Fc0oLA4N3mb7JPaymHeBILgUWkZQylhtZ6nV?= =?us-ascii?Q?JZ9jPzWnB945gC+RGhP8+k0+U2VXC8hjSu8Ra3hlC6iepyY8EjLOaJN5TfAi?= =?us-ascii?Q?+xriOKBHmWVEZKSdfyqixCeAdpV+zWKujv1GNuTWXfQzi0ZlW04NdHIRfGRf?= =?us-ascii?Q?U1gMZ6o359reuE5Ba8yNOENY6A1EFEcTVie/n+Mqe2bDjKmRZ/tkvCcRfCbn?= =?us-ascii?Q?WYS+NyICX5jXAWUbh3ZDXMWQTAlu5e6ASrTQ32UwM+EHm2YlfLUh2cwFe9Ju?= =?us-ascii?Q?H3jcuziFDRj7gNxJ8Ch70FrYz10UQTaDtOqDC5tj2QM+s6AwdpVHlhWogiEo?= =?us-ascii?Q?+P5uS9iWZ+TFgDn3SpMYW13xUmpornaghYTDmWZSnVQ6hrlGambE3UtzQOSR?= =?us-ascii?Q?sb5mETO/9WEDOGipjx0dG0Qqde3gQ+PzKgkH//G7W5X+pO6I7QKkVHPfgY6X?= =?us-ascii?Q?GMF2iRqfD+H5D6P3HwDO9Xg3JR14tZTQ5ngy3W4VgYvnndNL6pNHmagz6L79?= =?us-ascii?Q?5twXl4+Bgi3kwjYZWhJz7t9BpI91com4Tf+stK1IkPQju/G/54ZslZ2miDSU?= =?us-ascii?Q?ZIlYEb2UjQ8efIouhMIGDZLkU8n01O9enAypFFZJ510cByS3GzVwjZJjjY3+?= =?us-ascii?Q?oxXXQrRoFIfoCeVzF75tUpdz6SK2fMgHJTcvzaO3S2aM71EpTQmzdfoHhsFA?= =?us-ascii?Q?cUcyEuL1wnB2dR0R2hfS6njrAlGSWcJ6YCcH7jvAn?=
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 6:NOWjtEit/PaqIfT7S01ipcRy5/VHY2wv+ZDZI7D/?= =?us-ascii?Q?H18gGFFOnbn4W1MOBEcvkrCU0pfm0psSE7JywZjevcUc3+q9QMeyTvVIscmo?= =?us-ascii?Q?N9vIAEMlOQRuJ3k17nsRGmTFomQLSppKPtcT/yDEM2+gLn+JJGVuIPJkIljO?= =?us-ascii?Q?oAkTWoky9o1gC4qHmnXBkQKlFZYYT5kvAXBBrSqQ+WUuXx8k4yWxOsskF1BN?= =?us-ascii?Q?DaW1qkcotFLcmLyuHnR5gkCsmucWq9qwpsVfNyXfKUsim8VH4I9cun1u5GLr?= =?us-ascii?Q?ODVKNkZJ9wEdmlmG4u9iJDwTV5wCH/LAmi4EJ/RGLeZ8U8G/pD0s4tP/k73G?= =?us-ascii?Q?/aQ14tqZ4ZNU5IoQ1Ec2kCHYdklYtZXhRAUDqqdJtdEVt52qsp0yFir4QTOn?= =?us-ascii?Q?UMLec+1iIhEfsmZOmAkc/9KdAcMPd1mmQr+u5albwc4gee+TjS6MbYJrjP9z?= =?us-ascii?Q?VwghXEiYIYYxsQ/Eag0mSLOxM4GM4UWQVEFlxyvNmgZ+ff8OPc/Aa4AuDtgH?= =?us-ascii?Q?YgCqoajuQvmh/f2Mx118aMXqT+RkMigFtkvgcvptEy5BcrnS40/BFWDS3t3W?= =?us-ascii?Q?+u+tr+m/gN+UQKCEDtTjG68XSA74qR+pzxr9uGsrUAIF+rKYTRqRREsTkq24?= =?us-ascii?Q?r/lrlRup2SGHDuu9R0lHomuA+GnjsIEBKOdZ3boS+agyRkryuI+SQkPEtnFD?= =?us-ascii?Q?tYLWVMXu5IdpZ/DoZd7/8c4lpwpfQyM6Zj/S28Ur2pA+n0qgDp+oui6AraBc?= =?us-ascii?Q?WmM214g1n3h1xQ/KS19JrFd4juy5/6mcGkM1qCd6yMyL5DsJ3SnMgsnYtjch?= =?us-ascii?Q?l+P2+dNbTQzhZ1U8TXFEOXjKN06NcY5KRJinU8eoWRCDF7iC1LWZB4gBFnpy?= =?us-ascii?Q?d5C5GXWrLVReNHrZQ+t4ZKie5i66sMedyEMGgso2ZMSSkPa3NTWUC6nf180Q?= =?us-ascii?Q?tUNNd7+2w6LPsf1uyfyvzWhXv42VZE+auvWQFP1Fdkro3w4L3uE4J/famWom?= =?us-ascii?Q?IGo=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 5:snHJYxvPW2j8ZY0ujfEE/oBVcGvF0Hfbxp7KKGHFOEB/VdMWFtFi3J3UyqIb5NnU/F9I4ekvdnph3EyhSPtbWcC+XpFDKRdUv0/tM/4Y3+pbNrjqUmmMCkrr6SlB5BBWtyhLhU0g+2etLp7JzwX6pHiGhxw/zf0zLMk2J1MNV2Y+LGtxitN4UHkmgHDursCUTkpLX+Y2Nk4h7NhCtqBVbQLfGaSee1CnWcjz4p3c9+IZ+6LwIkkezTbB+B+ma1zUvvlHNe8FOu+UUmrJjmqKmovTmuJB8lYwQmvAom3ZJcGeaf9nTIIWqYo6Ttc/vAxGyzuk6JEjEzLvqpLeFD5AOhXulofqbDYqV20/vXmISiJm8rJTtPXRTe9IpabBTi2K8P6dD8YWD6ZmmLGEhnnd6SNlO6ecH12tNKAd5SwgcF1NSbLmO6PuMKTiiEkyy+CzlNLsbGYbsTej9lFtv8XjXq6uTr9WMzBwIor1atqUtUwrXs8+H86pzVlTSOjUNoo0; 24:59qgwjrgEBwnpHFOFtwc5WoAy6rsODRnBM8GTckA4PM3XmZQiwA5SPrzvI9Mu1b71r33miFaYCJn/bbxqsNDH5oQQ+7v6xi29mHBQN3Qca4=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 7:kMfA7PLbVer9qNfcC8gxuv1YTkiHRYsJcXE59bvVlmbr8Swd58cVNE3RykeOiznP6QmlFDiQSFiamYymCR3zj3y4lk+GyiJO9vLjLb1lwtS1IRmGqDURCD4Av/bMbF3SWbp5oSC4RwoXmpr/zF9e/F126FfYILBR9v2/iaGyAK5XgTCu7XM6Fm7tee5hDKviCf50o5a6u/A4ttXw2AyLS9VGCZN1rZTZYrV2mhK1IhERBb5CId8T1Z6V3V1r22R8GgV6UpJ3f5jRgP4SzDvj0DLd9PXGHFLMhk/mVlJFdwIk16XmHFVNf0O4SF+A05/UJluFGjWfJcUAACoEnPS7so/ogV3h3piq2iK8QmpnslEUB/kcEtV2KH7zasmmUfE0AVwI1lVRFzKQZ2ormguZ69LR5ZVlnfyIsCSJ8snahe4oS3xMA4mLcMG4kAdsY8TTwbt3H2AI/FG392dVgocXEhrO1CPF3izlXmZwni9hj08RzRMWzCH6VD2M9odQZbAmQzaPekjJjW86JAQJb1hpA1RaEK+pmCXC7gqibQUfncL2vOshhEkBZVG0jVwoH2JwpBE4UzbTPjN5dFWaqX4pp5w96d91S6CsdnOflpyzM3JC6AhoqaVh8ofaVxecmPJN7ghrCCLqh6zpSRrGAgtVD5HkC3HX15oj8X6Zsk59v4Dv1Ng37/5BU+jydNTvq9B2NAuq4grRkmQ8FOjy+AWFkl6jC9IwPkclKGjdPUggypCBniRx0FTkRjRnVIZi6xI9Sri59UBl3y6NzXS8m9GxOpOUbOHTdty7v+dEtsYNemw=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 19:29:19.7746 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 17 Jul 2017 19:29:24 -0000

On 17 Jul 2017, at 21:11, Watson Ladd wrote:

> How do you detect unauthorized access separate from knowing what
> authorization is?

I think we're talking at cross purposes, here.  Can you clarify?

> Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?

Many don't.  And being able to see rot(x) in the cryptostream has value.


> And the endpoints taking logs won't be?

Logs are no substitute for seeing the packets on the wire.


> Applications can rate-limited their own endpoints.

There's a lot more to DDoS defense than rate-limiting.  Rate-limiting 
often leads to gross overblocking.

> You're telling me a dedicated out of stream box can handle this but a 
> beefy server cannot?

Sadly, in all too many cases, yes.


> No one is taking away the ability to log the PMS to a file. That's the
> capacity which exists now.

But the capacity in question here is to see the packets on the wire.

> Alternatively it's because you've decided to run your networks in ways 
> very
> different from the public internet and used this as a way to avoid
> organizational battles over giving operations the tools they need to 
> work.

I think that some perceptions of how these things are done even on the 
public Internet may be a bit circumscribed.

The tools that network engineers and security personnel need analyze 
network traffic.  Logs are insufficient.

-----------------------------------
Roland Dobbins 


From nobody Tue Jul 18 04:07:10 2017
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 AA6AD12F280; Tue, 18 Jul 2017 04:07:08 -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 bQNBsz3wPdzG; Tue, 18 Jul 2017 04:07:07 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2681252BA; Tue, 18 Jul 2017 04:07:06 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id x187so13774766oig.3; Tue, 18 Jul 2017 04:07:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tq3jYZt/QV3exHH7BUYohwXf2B/h176cb1o6DmdlVFI=; b=ZCpqwuuZLcRD8vVOmYQAUH2MbXpPzndPHQAV7JygvySZzfoxUzNFZ7iypRKqZU7aCZ eT0y+o10/SDelvaIbrrnz3zgx0I304JlizLD74IEU/ClnWcEQ2k6eGqn5cgEM8rHbQKd fEEEKz/XekdCIRi5+IJ7pzICR+hovrejWpmJhQ7PsJGqBtzoh2r7ZB65zQ/dMyU69Hm2 GE8u1IIkb9xHDVXEgThzpeh2R26rLIaMlaZZlvVJfdwWqtHBqqEiUKC1rZE2ezleXcd3 Su7UpDMrNsybHg87pfG8qFRTvfM1gZP+SNxGzsL2mJFS0/CaAq9lxlaUWEgdA/om/IRQ qmSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tq3jYZt/QV3exHH7BUYohwXf2B/h176cb1o6DmdlVFI=; b=SFhjt9ZvSebztD+twW4FvQmkwkyPEwpXp4+ra4bfK2bK/wXykddVbC4ha3iEGS2Ycf Q6SbKnVBOjL6tj+5zLu7CRBtCb4BCM9Z45cOweGp1QauTUMCaUc6R88BGcC7jA5RMeQS TEpnJmMa6VaA+ncPQO5sdYO8rCf0xPCCJOwXJdELzQP7HsDeH7UCgqzR+CkROOcuxB0a GJ6dCtdOR5k151EMscRUaJl32pEKBqqduZXxTjC5JEheR4Cz06SDPsml9Z15sU+Ywi4n rfz+9592jLhgRjlU+PjBQcLDxap7j+oneexcMbgLvBvA/tgHfwwtxt8eet/Dkwyn73xD JE0Q==
X-Gm-Message-State: AIVw111mr6mHVYgqwKWAgwGazAMFVQkHJBtqE1Zb9t+1N9AHxjVxdvz6 EBDjmja+cdzR/75tlGqhvKXMbPgVzg==
X-Received: by 10.202.213.216 with SMTP id m207mr639550oig.17.1500376026067; Tue, 18 Jul 2017 04:07:06 -0700 (PDT)
MIME-Version: 1.0
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>
In-Reply-To: <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>
From: Nick Sullivan 
Date: Tue, 18 Jul 2017 11:06:55 +0000
Message-ID: 
To: Sean Turner , "" 
Cc: lurk@ietf.org
Content-Type: multipart/alternative; boundary="001a113d34ca103c6205549584ee"
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 11:07:09 -0000

--001a113d34ca103c6205549584ee
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sean,

We've had some additional discussions in person here at IETF 99 with folks
who were in the proxy certificates and short-lived certs camp, and we think
there is now more agreement that the mechanism described in this draft is
superior to the alternatives. I've included a summary of some of the pros
and cons of the approaches:


*Proxy certificates vs. Delegated Credentials*
*Pro proxy certificates*:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key =3D=3D certificate.
*Con proxy certificates*:
- Proxy certificates adds additional complexity to the delegation other
than limiting the time period (full X.509, additional constraints  such as
hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as
part of TLS:
-- There have been problems and inconsistencies around pathlen and
constraints enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated
creds (which can easily be implemented in TLS as demonstrated by the 3
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE
cert. This is a binding weaker than delegated credentials which includes a
signature over the EE certificate.

*Short-lived certs vs. Delegated Credentials*
*Pro short-lived certs*:
- Short lived certs work with existing libraries, no new code changes.
*Con short-lived certs*:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be
logged in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must
provide proof of domain possession to CA vs. internally managed credential
minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials
you can fall back to a LURK-style protocol with the long-lived certificate
key.

Given these comparisons, we think the proposed draft is the superior option
and would like to continue the discussion about adopting it.

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner  wrote:

> All,
>
> During the WG call for adoption, a couple of questions were raised about
> comparison/analysis of sub-certs versus proxy and/or short-lived
> certificates.  There is some discussion currently in the draft, but the
> chairs feel that these issues need further discussion (and elaboration in
> the draft) prior to WG adoption.  So let=E2=80=99s keep the conversation =
going.
>
> J&S
>
> > On Apr 12, 2017, at 15:31, Sean Turner  wrote:
> >
> > All,
> >
> > At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the
> list so please let the list know whether you support adoption of the draf=
t
> and are willing to review/comment on the draft before 20170429.  If you
> object to its adoption, please let us know why.
> >
> > Clearly, the WG is going to need to work through the trade-offs between
> short-lived certificates and sub-certs because both seem, to some, to be
> addressing the same problem.
> >
> > Cheers,
> >
> > J&S
> >
> > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113d34ca103c6205549584ee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sean,

We've had some additional=
 discussions in person here at IETF 99 with folks who were in the proxy cer=
tificates and short-lived certs camp, and we think there is now more agreem=
ent that the mechanism described in this draft is superior to the alternati=
ves. I've included a summary of some of the pros and cons of the approa=
ches:

Proxy ce=
rtificates vs. Delegated Credentials
Pro proxy certificates:
- Already deployed in some industries, though not on the Web.
-=
 Fits the conceptual model that public key =3D=3D certificate.
Co=
n proxy certificates:
- Proxy certificates adds additional complexi=
ty to the delegation other than limiting the time period (full X.509, addit=
ional constraints=C2=A0 such as hostname).
- Encourages implementers to reu=
se PKIX libraries rather than build code as part of TLS:
-- There have b=
een problems and inconsistencies around pathlen and constraints enforcement=
 in existing PKIX libraries.
-- Modifying these libraries is more comple=
x and risk prone than delegated creds (which can easily be implemented in T=
LS as demonstrated by the 3 interoperable implementations at the IETF 98 ha=
ckathon).
- In proxy certificates, pathing is SKI dependent, not directly t=
ied to=20
EE cert. This is a binding weaker than delegated credentials which includes=
 a=20
signature over the EE certificate.

Short-lived certs vs. Delegated Credentials
=
Pro short-lived certs:
- Short lived certs work with existing li=
braries, no new code changes.
Con short-lived certs:
- No=
t widely available from CAs, especially for EV.
- Potentially problemat=
ic to the CT ecosystem (all certificates must be logged in CT, which may bl=
oat them).
- Introduces a high-risk operational dependency on external =
party:
-- Requires frequent exchanges with an external Certificate Autho=
rity (must provide proof of domain possession to CA vs. internally managed =
credential minter for delegated credentials).
-- There is no fallback i=
f the CA has outage. With delegated credentials you can fall back to a LURK=
-style protocol with the long-lived certificate key.
Given these comparisons, we think the proposed draft is the su=
perior option and would like to continue the discussion about adopting it.<=
br>

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner <sean@sn3rd.com> wrote:
All,



During the WG call for adoption, a couple of questions were raised about co=
mparison/analysis of sub-certs versus proxy and/or short-lived certificates=
.=C2=A0 There is some discussion currently in the draft, but the chairs fee=
l that these issues need further discussion (and elaboration in the draft) =
prior to WG adoption.=C2=A0 So let=E2=80=99s keep the conversation going.


J&S



> On Apr 12, 2017, at 15:31, Sean Turner <sean@sn3rd.com> wrote:

>

> All,

>

> At our IETF 98 session, there was support in the room to adopt draft-r=
escorla-tls-subcerts [0].=C2=A0 We need to confirm this support on the list=
 so please let the list know whether you support adoption of the draft and =
are willing to review/comment on the draft before 20170429.=C2=A0 If you ob=
ject to its adoption, please let us know why.

>

> Clearly, the WG is going to need to work through the trade-offs betwee=
n short-lived certificates and sub-certs because both seem, to some, to be =
addressing the same problem.

>

> Cheers,

>

> J&S

>

> [0] https://datatracker.ietf.o=
rg/doc/html/draft-rescorla-tls-subcerts



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--001a113d34ca103c6205549584ee--


From nobody Tue Jul 18 04:40:50 2017
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 B61C3131897; Tue, 18 Jul 2017 04:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=nokia.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 st73GRmZsS9s; Tue, 18 Jul 2017 04:40:44 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0124.outbound.protection.outlook.com [104.47.0.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F501317BE; Tue, 18 Jul 2017 04:40:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qHvBAJ3korO/NIuGyHqWvAmuBmxN4k3CG5JBcalNEhY=; b=MUHd/y8SHG9L9lEpc4tMhSQorS888mbsXg9GkHe2wLSPYBnJBmzI/gEFld3EPornzRCM/d4UmlFyzPIImIGVH3JVVpH+8l+Mq2SqnaYY0TcNjmuTVgEGDOpB4R2ijVcWNQ8ExYbIDHXtpOeXAp4HxcLeJwnJN3MV0N4LvMMSfQI=
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1215.eurprd07.prod.outlook.com (10.163.169.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Tue, 18 Jul 2017 11:40:40 +0000
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::d0a5:5d5d:c414:4b10]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::d0a5:5d5d:c414:4b10%14]) with mapi id 15.01.1282.008; Tue, 18 Jul 2017 11:40:40 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" 
To: Nick Sullivan , Sean Turner ,  "" 
CC: "lurk@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" 
Thread-Topic: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
Thread-Index: AQHS0CpTH+tPQf6rjUes9Cw+A0SKZqJZy5mAgAAaMYA=
Date: Tue, 18 Jul 2017 11:40:40 +0000
Message-ID: <61435CE8-3A17-4773-8329-54908985FB80@nokia.com>
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [81.134.152.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB1215; 7:NLWmWGuiC1CXxDn678PD6o1suwea3ShILEJXbBlMgEL28pwVPO3dZDVEySi6nRoRoW9E1WOniPdfIPOgJwBUL81Jw+OoS2zGtMlcBVrK2zt6aAlqZGBpgLgmC+PQqblIQDUbSbDVmPp21/vKGVLOamYBPvi3fd4mOnaI0SHjcTvdHFkGf911sVpC8QjiP+a9tvv9XJ5pTNXiObNkLYT245zwLP0A5iMrNS3tHkmLey07WH8sG4TEB8fPkDR0wBR1/wNzcUiv25k5GBpRfMquDGBH0zUogaDNwV8aQdGU+JIhWu/Rwbz6E+AGJDr2dmBCpGQa+jxXM/41qUqutP5chWHPd4ZU6Iwmt1Vdm00n69vyrtKEUQ6bzONYbsBQgavJkKbw24eqXrQO8u+zMR2iH6sWTrr8ZJ+r9Wnz8AhjXQtZiG6y020IADwDio19vOPlZabV+LSinIK5DcSDzDZ3JP9pOsEAJEU3PSaxjJTka16pobIJtDMbz94czoGS2WGDn8w6P8k95zJ7fL30gTBA26kyeTyVC7T9jyYgqJjFZP1UMGRMT2NZd6uXb1N+CLcXTDRQ8fGbZDBOqgvUcinuC15rc6K3i9JRKJl6oeI3IDxW9wRMJFdYgfeC976kW84UMcyIIg+XG/BaTcSGB6o77TuuhDHe2imYALtPa8EdFPofzyNa0gXtMceTk3z4m//7THP5TidFy8JV63L5qavJx6qoWJfvET9wVZq4NIU7oIrgkG27YMabeLlCvz9aPwMJfHWRQO442mh2Wf6ya3yvkh4gh1WkipgYtAg58i59Hn0=
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(24454002)(377454003)(39060400002)(5660300001)(6486002)(3846002)(6506006)(53936002)(6246003)(38730400002)(236005)(107886003)(6436002)(4001350100001)(53546010)(229853002)(83506001)(83716003)(54896002)(66066001)(6306002)(99286003)(54906002)(7736002)(6512007)(14454004)(33656002)(5250100002)(3280700002)(54356999)(36756003)(3660700001)(25786009)(606006)(2906002)(478600001)(8936002)(2950100002)(189998001)(6116002)(102836003)(86362001)(81166006)(230783001)(50986999)(76176999)(2900100001)(82746002)(966005)(9326002)(4326008)(8676002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1215; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
x-ms-office365-filtering-correlation-id: 37a92acb-1af3-4ceb-a048-08d4cdd1d0e0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR07MB1215; 
x-ms-traffictypediagnostic: VI1PR07MB1215:
x-exchange-antispam-report-test: UriScan:(151999592597050)(133145235818549)(120809045254105)(26388249023172)(236129657087228)(150554046322364)(48057245064654)(148574349560750)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1215; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1215; 
x-forefront-prvs: 037291602B
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_61435CE83A174773832954908985FB80nokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2017 11:40:40.0604 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1215
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 11:40:47 -0000

--_000_61435CE83A174773832954908985FB80nokiacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTmljaywNCg0KSSBhbSBub3QgYWdhaW5zdCBkZWxlZ2F0ZWQgY3JlZGVudGlhbHMsIGluIGZh
Y3QgSSB0aGluayBpdOKAmXMgYSBnb29kIHRoaW5nIHBlciBzZS4NCg0KSSBoYWQgZXhwcmVzc2Vk
IGEgY291cGxlIG9mIGNvbmNlcm5zIGF0IHRoZSB0aW1lIHRoZSBjYWxsIGZvciBhZG9wdGlvbiB3
YXMgZmlyc3QgaXNzdWVkIFsxXSwgd2hpY2ggSSB0aGluayBhcmUgc3RpbGwgdmFsaWQuDQoNCkNv
dWxkIHlvdSBwbGVhc2UgY29tbWVudCBvbiAvIGFkZCB0aGVtIHRvIHlvdXIgcHJvLWNvbnMgYW5h
bHlzaXM/DQoNCkNoZWVycywgdGhhbmtzLA0KdA0KDQpbMV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyMjk2Ni5odG1sDQoNCk9uIDE4LzA3LzIw
MTcsIDEyOjA2LCAiVExTIG9uIGJlaGFsZiBvZiBOaWNrIFN1bGxpdmFuIiA8dGxzLWJvdW5jZXNA
aWV0Zi5vcmc8bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgbmljaG9s
YXMuc3VsbGl2YW5AZ21haWwuY29tPG1haWx0bzpuaWNob2xhcy5zdWxsaXZhbkBnbWFpbC5jb20+
PiB3cm90ZToNCg0KU2VhbiwNCldlJ3ZlIGhhZCBzb21lIGFkZGl0aW9uYWwgZGlzY3Vzc2lvbnMg
aW4gcGVyc29uIGhlcmUgYXQgSUVURiA5OSB3aXRoIGZvbGtzIHdobyB3ZXJlIGluIHRoZSBwcm94
eSBjZXJ0aWZpY2F0ZXMgYW5kIHNob3J0LWxpdmVkIGNlcnRzIGNhbXAsIGFuZCB3ZSB0aGluayB0
aGVyZSBpcyBub3cgbW9yZSBhZ3JlZW1lbnQgdGhhdCB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBp
biB0aGlzIGRyYWZ0IGlzIHN1cGVyaW9yIHRvIHRoZSBhbHRlcm5hdGl2ZXMuIEkndmUgaW5jbHVk
ZWQgYSBzdW1tYXJ5IG9mIHNvbWUgb2YgdGhlIHByb3MgYW5kIGNvbnMgb2YgdGhlIGFwcHJvYWNo
ZXM6DQpQcm94eSBjZXJ0aWZpY2F0ZXMgdnMuIERlbGVnYXRlZCBDcmVkZW50aWFscw0KUHJvIHBy
b3h5IGNlcnRpZmljYXRlczoNCi0gQWxyZWFkeSBkZXBsb3llZCBpbiBzb21lIGluZHVzdHJpZXMs
IHRob3VnaCBub3Qgb24gdGhlIFdlYi4NCi0gRml0cyB0aGUgY29uY2VwdHVhbCBtb2RlbCB0aGF0
IHB1YmxpYyBrZXkgPT0gY2VydGlmaWNhdGUuDQpDb24gcHJveHkgY2VydGlmaWNhdGVzOg0KLSBQ
cm94eSBjZXJ0aWZpY2F0ZXMgYWRkcyBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgdG8gdGhlIGRlbGVn
YXRpb24gb3RoZXIgdGhhbiBsaW1pdGluZyB0aGUgdGltZSBwZXJpb2QgKGZ1bGwgWC41MDksIGFk
ZGl0aW9uYWwgY29uc3RyYWludHMgIHN1Y2ggYXMgaG9zdG5hbWUpLg0KLSBFbmNvdXJhZ2VzIGlt
cGxlbWVudGVycyB0byByZXVzZSBQS0lYIGxpYnJhcmllcyByYXRoZXIgdGhhbiBidWlsZCBjb2Rl
IGFzIHBhcnQgb2YgVExTOg0KLS0gVGhlcmUgaGF2ZSBiZWVuIHByb2JsZW1zIGFuZCBpbmNvbnNp
c3RlbmNpZXMgYXJvdW5kIHBhdGhsZW4gYW5kIGNvbnN0cmFpbnRzIGVuZm9yY2VtZW50IGluIGV4
aXN0aW5nIFBLSVggbGlicmFyaWVzLg0KLS0gTW9kaWZ5aW5nIHRoZXNlIGxpYnJhcmllcyBpcyBt
b3JlIGNvbXBsZXggYW5kIHJpc2sgcHJvbmUgdGhhbiBkZWxlZ2F0ZWQgY3JlZHMgKHdoaWNoIGNh
biBlYXNpbHkgYmUgaW1wbGVtZW50ZWQgaW4gVExTIGFzIGRlbW9uc3RyYXRlZCBieSB0aGUgMyBp
bnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBhdCB0aGUgSUVURiA5OCBoYWNrYXRob24pLg0K
LSBJbiBwcm94eSBjZXJ0aWZpY2F0ZXMsIHBhdGhpbmcgaXMgU0tJIGRlcGVuZGVudCwgbm90IGRp
cmVjdGx5IHRpZWQgdG8gRUUgY2VydC4gVGhpcyBpcyBhIGJpbmRpbmcgd2Vha2VyIHRoYW4gZGVs
ZWdhdGVkIGNyZWRlbnRpYWxzIHdoaWNoIGluY2x1ZGVzIGEgc2lnbmF0dXJlIG92ZXIgdGhlIEVF
IGNlcnRpZmljYXRlLg0KDQpTaG9ydC1saXZlZCBjZXJ0cyB2cy4gRGVsZWdhdGVkIENyZWRlbnRp
YWxzDQpQcm8gc2hvcnQtbGl2ZWQgY2VydHM6DQotIFNob3J0IGxpdmVkIGNlcnRzIHdvcmsgd2l0
aCBleGlzdGluZyBsaWJyYXJpZXMsIG5vIG5ldyBjb2RlIGNoYW5nZXMuDQpDb24gc2hvcnQtbGl2
ZWQgY2VydHM6DQotIE5vdCB3aWRlbHkgYXZhaWxhYmxlIGZyb20gQ0FzLCBlc3BlY2lhbGx5IGZv
ciBFVi4NCi0gUG90ZW50aWFsbHkgcHJvYmxlbWF0aWMgdG8gdGhlIENUIGVjb3N5c3RlbSAoYWxs
IGNlcnRpZmljYXRlcyBtdXN0IGJlIGxvZ2dlZCBpbiBDVCwgd2hpY2ggbWF5IGJsb2F0IHRoZW0p
Lg0KLSBJbnRyb2R1Y2VzIGEgaGlnaC1yaXNrIG9wZXJhdGlvbmFsIGRlcGVuZGVuY3kgb24gZXh0
ZXJuYWwgcGFydHk6DQotLSBSZXF1aXJlcyBmcmVxdWVudCBleGNoYW5nZXMgd2l0aCBhbiBleHRl
cm5hbCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgKG11c3QgcHJvdmlkZSBwcm9vZiBvZiBkb21haW4g
cG9zc2Vzc2lvbiB0byBDQSB2cy4gaW50ZXJuYWxseSBtYW5hZ2VkIGNyZWRlbnRpYWwgbWludGVy
IGZvciBkZWxlZ2F0ZWQgY3JlZGVudGlhbHMpLg0KLS0gVGhlcmUgaXMgbm8gZmFsbGJhY2sgaWYg
dGhlIENBIGhhcyBvdXRhZ2UuIFdpdGggZGVsZWdhdGVkIGNyZWRlbnRpYWxzIHlvdSBjYW4gZmFs
bCBiYWNrIHRvIGEgTFVSSy1zdHlsZSBwcm90b2NvbCB3aXRoIHRoZSBsb25nLWxpdmVkIGNlcnRp
ZmljYXRlIGtleS4NCg0KR2l2ZW4gdGhlc2UgY29tcGFyaXNvbnMsIHdlIHRoaW5rIHRoZSBwcm9w
b3NlZCBkcmFmdCBpcyB0aGUgc3VwZXJpb3Igb3B0aW9uIGFuZCB3b3VsZCBsaWtlIHRvIGNvbnRp
bnVlIHRoZSBkaXNjdXNzaW9uIGFib3V0IGFkb3B0aW5nIGl0Lg0KDQpOaWNrDQoNCk9uIEZyaSwg
TWF5IDE5LCAyMDE3IGF0IDEyOjU4IEFNIFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbTxtYWls
dG86c2VhbkBzbjNyZC5jb20+PiB3cm90ZToNCkFsbCwNCg0KRHVyaW5nIHRoZSBXRyBjYWxsIGZv
ciBhZG9wdGlvbiwgYSBjb3VwbGUgb2YgcXVlc3Rpb25zIHdlcmUgcmFpc2VkIGFib3V0IGNvbXBh
cmlzb24vYW5hbHlzaXMgb2Ygc3ViLWNlcnRzIHZlcnN1cyBwcm94eSBhbmQvb3Igc2hvcnQtbGl2
ZWQgY2VydGlmaWNhdGVzLiAgVGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGN1cnJlbnRseSBpbiB0
aGUgZHJhZnQsIGJ1dCB0aGUgY2hhaXJzIGZlZWwgdGhhdCB0aGVzZSBpc3N1ZXMgbmVlZCBmdXJ0
aGVyIGRpc2N1c3Npb24gKGFuZCBlbGFib3JhdGlvbiBpbiB0aGUgZHJhZnQpIHByaW9yIHRvIFdH
IGFkb3B0aW9uLiAgU28gbGV04oCZcyBrZWVwIHRoZSBjb252ZXJzYXRpb24gZ29pbmcuDQoNCkom
Uw0KDQo+IE9uIEFwciAxMiwgMjAxNywgYXQgMTU6MzEsIFNlYW4gVHVybmVyIDxzZWFuQHNuM3Jk
LmNvbTxtYWlsdG86c2VhbkBzbjNyZC5jb20+PiB3cm90ZToNCj4NCj4gQWxsLA0KPg0KPiBBdCBv
dXIgSUVURiA5OCBzZXNzaW9uLCB0aGVyZSB3YXMgc3VwcG9ydCBpbiB0aGUgcm9vbSB0byBhZG9w
dCBkcmFmdC1yZXNjb3JsYS10bHMtc3ViY2VydHMgWzBdLiAgV2UgbmVlZCB0byBjb25maXJtIHRo
aXMgc3VwcG9ydCBvbiB0aGUgbGlzdCBzbyBwbGVhc2UgbGV0IHRoZSBsaXN0IGtub3cgd2hldGhl
ciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGUgZHJhZnQgYW5kIGFyZSB3aWxsaW5nIHRvIHJl
dmlldy9jb21tZW50IG9uIHRoZSBkcmFmdCBiZWZvcmUgMjAxNzA0MjkuICBJZiB5b3Ugb2JqZWN0
IHRvIGl0cyBhZG9wdGlvbiwgcGxlYXNlIGxldCB1cyBrbm93IHdoeS4NCj4NCj4gQ2xlYXJseSwg
dGhlIFdHIGlzIGdvaW5nIHRvIG5lZWQgdG8gd29yayB0aHJvdWdoIHRoZSB0cmFkZS1vZmZzIGJl
dHdlZW4gc2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVzIGFuZCBzdWItY2VydHMgYmVjYXVzZSBib3Ro
IHNlZW0sIHRvIHNvbWUsIHRvIGJlIGFkZHJlc3NpbmcgdGhlIHNhbWUgcHJvYmxlbS4NCj4NCj4g
Q2hlZXJzLA0KPg0KPiBKJlMNCj4NCj4gWzBdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLXN1YmNlcnRzDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0
Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vdGxzDQo=

--_000_61435CE83A174773832954908985FB80nokiacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <64C334CB49B9C44B9A733F65C14998C3@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0
IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdC
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBOaWNrLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMiPkkgYW0gbm90IGFnYWluc3QgZGVsZWdhdGVkIGNyZWRlbnRpYWxz
LCBpbiBmYWN0IEkgdGhpbmsgaXTigJlzIGEgZ29vZCB0aGluZyBwZXIgc2UuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUyI+SSBoYWQgZXhwcmVzc2VkIGEgY291cGxlIG9mIGNvbmNlcm5zIGF0IHRoZSB0
aW1lIHRoZSBjYWxsIGZvciBhZG9wdGlvbiB3YXMgZmlyc3QgaXNzdWVkIFsxXSwgd2hpY2ggSSB0
aGluayBhcmUgc3RpbGwgdmFsaWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy
aTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q291bGQgeW91IHBs
ZWFzZSBjb21tZW50IG9uIC8gYWRkIHRoZW0gdG8geW91ciBwcm8tY29ucyBhbmFseXNpcz88bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVlcnMsIHRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj50PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUyI+WzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdGxz
L2N1cnJlbnQvbXNnMjI5NjYuaHRtbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli
cmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
OjM2LjBwdCI+T24gMTgvMDcvMjAxNywgMTI6MDYsICZxdW90O1RMUyBvbiBiZWhhbGYgb2YgTmlj
ayBTdWxsaXZhbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3Jn
Ij50bHMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86
bmljaG9sYXMuc3VsbGl2YW5AZ21haWwuY29tIj5uaWNob2xhcy5zdWxsaXZhbkBnbWFpbC5jb208
L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t
OjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KU2Vhbiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYu
MHB0Ij4NCldlJ3ZlIGhhZCBzb21lIGFkZGl0aW9uYWwgZGlzY3Vzc2lvbnMgaW4gcGVyc29uIGhl
cmUgYXQgSUVURiA5OSB3aXRoIGZvbGtzIHdobyB3ZXJlIGluIHRoZSBwcm94eSBjZXJ0aWZpY2F0
ZXMgYW5kIHNob3J0LWxpdmVkIGNlcnRzIGNhbXAsIGFuZCB3ZSB0aGluayB0aGVyZSBpcyBub3cg
bW9yZSBhZ3JlZW1lbnQgdGhhdCB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0
IGlzIHN1cGVyaW9yIHRvIHRoZSBhbHRlcm5hdGl2ZXMuIEkndmUNCiBpbmNsdWRlZCBhIHN1bW1h
cnkgb2Ygc29tZSBvZiB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUgYXBwcm9hY2hlczo8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6
MzYuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojMjEyMTIxIj5Qcm94eSBjZXJ0aWZpY2F0ZXMg
dnMuIERlbGVnYXRlZCBDcmVkZW50aWFsczwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PGk+PHU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPlBybyBw
cm94eSBjZXJ0aWZpY2F0ZXM8L3NwYW4+PC91PjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+OjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPi0gQWxyZWFkeSBkZXBs
b3llZCBpbiBzb21lIGluZHVzdHJpZXMsIHRob3VnaCBub3Qgb24gdGhlIFdlYi48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojMjEyMTIxIj4tIEZpdHMgdGhl
IGNvbmNlcHR1YWwgbW9kZWwgdGhhdCBwdWJsaWMga2V5ID09IGNlcnRpZmljYXRlLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PGk+PHU+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPkNv
biBwcm94eSBjZXJ0aWZpY2F0ZXM8L3NwYW4+PC91PjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+OjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPi0gUHJveHkgY2Vy
dGlmaWNhdGVzIGFkZHMgYWRkaXRpb25hbCBjb21wbGV4aXR5IHRvIHRoZSBkZWxlZ2F0aW9uIG90
aGVyIHRoYW4gbGltaXRpbmcgdGhlIHRpbWUgcGVyaW9kIChmdWxsIFguNTA5LCBhZGRpdGlvbmFs
DQogY29uc3RyYWludHMmbmJzcDsgc3VjaCBhcyBob3N0bmFtZSkuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0OjM2LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBFbmNvdXJhZ2VzIGltcGxl
bWVudGVycyB0byByZXVzZSBQS0lYIGxpYnJhcmllcyByYXRoZXIgdGhhbiBidWlsZCBjb2RlIGFz
IHBhcnQgb2YgVExTOjxicj4NCi0tIFRoZXJlIGhhdmUgYmVlbiBwcm9ibGVtcyBhbmQgaW5jb25z
aXN0ZW5jaWVzIGFyb3VuZCBwYXRobGVuIGFuZCBjb25zdHJhaW50cyBlbmZvcmNlbWVudCBpbiBl
eGlzdGluZyBQS0lYIGxpYnJhcmllcy48YnI+DQotLSBNb2RpZnlpbmcgdGhlc2UgbGlicmFyaWVz
IGlzIG1vcmUgY29tcGxleCBhbmQgcmlzayBwcm9uZSB0aGFuIGRlbGVnYXRlZCBjcmVkcyAod2hp
Y2ggY2FuIGVhc2lseSBiZSBpbXBsZW1lbnRlZCBpbiBUTFMgYXMgZGVtb25zdHJhdGVkIGJ5IHRo
ZSAzIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zIGF0IHRoZSBJRVRGIDk4IGhhY2thdGhv
bikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEy
MSI+LSBJbiBwcm94eSBjZXJ0aWZpY2F0ZXMsIHBhdGhpbmcgaXMgU0tJIGRlcGVuZGVudCwgbm90
IGRpcmVjdGx5IHRpZWQgdG8gRUUgY2VydC4gVGhpcyBpcyBhIGJpbmRpbmcgd2Vha2VyIHRoYW4g
ZGVsZWdhdGVkIGNyZWRlbnRpYWxzDQogd2hpY2ggaW5jbHVkZXMgYSBzaWduYXR1cmUgb3ZlciB0
aGUgRUUgY2VydGlmaWNhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5k
OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRp
Y2E7Y29sb3I6IzIxMjEyMSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtiYWNr
Z3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+U2hvcnQtbGl2ZWQgY2VydHMgdnMuIERlbGVnYXRl
ZCBDcmVkZW50aWFsczwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz
Ni4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PGk+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPlBybyBzaG9ydC1saXZlZCBj
ZXJ0czwvc3Bhbj48L3U+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OkhlbHZldGljYTtjb2xvcjojMjEyMTIxIj46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw
dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBTaG9ydCBsaXZlZCBjZXJ0cyB3b3JrIHdp
dGggZXhpc3RpbmcgbGlicmFyaWVzLCBubyBuZXcgY29kZSBjaGFuZ2VzLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PGk+PHU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPkNvbiBzaG9y
dC1saXZlZCBjZXJ0czwvc3Bhbj48L3U+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojMjEyMTIxIj46PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0OjM2LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBOb3Qgd2lkZWx5IGF2YWls
YWJsZSBmcm9tIENBcywgZXNwZWNpYWxseSBmb3IgRVYuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2
LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBQb3RlbnRpYWxseSBwcm9ibGVtYXRp
YyB0byB0aGUgQ1QgZWNvc3lzdGVtIChhbGwgY2VydGlmaWNhdGVzIG11c3QgYmUgbG9nZ2VkIGlu
IENULCB3aGljaCBtYXkgYmxvYXQgdGhlbSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDti
YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBJbnRyb2R1Y2VzIGEgaGlnaC1yaXNrIG9wZXJh
dGlvbmFsIGRlcGVuZGVuY3kgb24gZXh0ZXJuYWwgcGFydHk6PGJyPg0KLS0gUmVxdWlyZXMgZnJl
cXVlbnQgZXhjaGFuZ2VzIHdpdGggYW4gZXh0ZXJuYWwgQ2VydGlmaWNhdGUgQXV0aG9yaXR5ICht
dXN0IHByb3ZpZGUgcHJvb2Ygb2YgZG9tYWluIHBvc3Nlc3Npb24gdG8gQ0EgdnMuIGludGVybmFs
bHkgbWFuYWdlZCBjcmVkZW50aWFsIG1pbnRlciBmb3IgZGVsZWdhdGVkIGNyZWRlbnRpYWxzKS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojMjEyMTIxIj4t
LSBUaGVyZSBpcyBubyBmYWxsYmFjayBpZiB0aGUgQ0EgaGFzIG91dGFnZS4gV2l0aCBkZWxlZ2F0
ZWQgY3JlZGVudGlhbHMgeW91IGNhbiBmYWxsIGJhY2sgdG8gYSBMVVJLLXN0eWxlIHByb3RvY29s
IHdpdGggdGhlDQogbG9uZy1saXZlZCBjZXJ0aWZpY2F0ZSBrZXkuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkdpdmVuIHRo
ZXNlIGNvbXBhcmlzb25zLCB3ZSB0aGluayB0aGUgcHJvcG9zZWQgZHJhZnQgaXMgdGhlIHN1cGVy
aW9yIG9wdGlvbiBhbmQgd291bGQgbGlrZSB0byBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBhYm91
dCBhZG9wdGluZyBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0
Ij5OaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBGcmks
IE1heSAxOSwgMjAxNyBhdCAxMjo1OCBBTSBTZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRv
OnNlYW5Ac24zcmQuY29tIj5zZWFuQHNuM3JkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjM2LjBwdCI+QWxsLDxicj4NCjxicj4NCkR1cmluZyB0aGUgV0cgY2FsbCBmb3Ig
YWRvcHRpb24sIGEgY291cGxlIG9mIHF1ZXN0aW9ucyB3ZXJlIHJhaXNlZCBhYm91dCBjb21wYXJp
c29uL2FuYWx5c2lzIG9mIHN1Yi1jZXJ0cyB2ZXJzdXMgcHJveHkgYW5kL29yIHNob3J0LWxpdmVk
IGNlcnRpZmljYXRlcy4mbmJzcDsgVGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGN1cnJlbnRseSBp
biB0aGUgZHJhZnQsIGJ1dCB0aGUgY2hhaXJzIGZlZWwgdGhhdCB0aGVzZSBpc3N1ZXMgbmVlZCBm
dXJ0aGVyIGRpc2N1c3Npb24NCiAoYW5kIGVsYWJvcmF0aW9uIGluIHRoZSBkcmFmdCkgcHJpb3Ig
dG8gV0cgYWRvcHRpb24uJm5ic3A7IFNvIGxldOKAmXMga2VlcCB0aGUgY29udmVyc2F0aW9uIGdv
aW5nLjxicj4NCjxicj4NCkomYW1wO1M8YnI+DQo8YnI+DQomZ3Q7IE9uIEFwciAxMiwgMjAxNywg
YXQgMTU6MzEsIFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJtYWlsdG86c2VhbkBzbjNyZC5jb20i
IHRhcmdldD0iX2JsYW5rIj5zZWFuQHNuM3JkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8
YnI+DQomZ3Q7IEFsbCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBdCBvdXIgSUVURiA5OCBzZXNzaW9u
LCB0aGVyZSB3YXMgc3VwcG9ydCBpbiB0aGUgcm9vbSB0byBhZG9wdCBkcmFmdC1yZXNjb3JsYS10
bHMtc3ViY2VydHMgWzBdLiZuYnNwOyBXZSBuZWVkIHRvIGNvbmZpcm0gdGhpcyBzdXBwb3J0IG9u
IHRoZSBsaXN0IHNvIHBsZWFzZSBsZXQgdGhlIGxpc3Qga25vdyB3aGV0aGVyIHlvdSBzdXBwb3J0
IGFkb3B0aW9uIG9mIHRoZSBkcmFmdCBhbmQgYXJlIHdpbGxpbmcgdG8gcmV2aWV3L2NvbW1lbnQg
b24gdGhlIGRyYWZ0DQogYmVmb3JlIDIwMTcwNDI5LiZuYnNwOyBJZiB5b3Ugb2JqZWN0IHRvIGl0
cyBhZG9wdGlvbiwgcGxlYXNlIGxldCB1cyBrbm93IHdoeS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBD
bGVhcmx5LCB0aGUgV0cgaXMgZ29pbmcgdG8gbmVlZCB0byB3b3JrIHRocm91Z2ggdGhlIHRyYWRl
LW9mZnMgYmV0d2VlbiBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgYW5kIHN1Yi1jZXJ0cyBiZWNh
dXNlIGJvdGggc2VlbSwgdG8gc29tZSwgdG8gYmUgYWRkcmVzc2luZyB0aGUgc2FtZSBwcm9ibGVt
Ljxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBKJmFtcDtT
PGJyPg0KJmd0Ozxicj4NCiZndDsgWzBdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLXN1YmNlcnRzIiB0YXJnZXQ9Il9ibGFu
ayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXJlc2Nvcmxh
LXRscy1zdWJjZXJ0czwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt
YWlsdG86VExTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VExTQGlldGYub3JnPC9hPjxicj4N
CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_61435CE83A174773832954908985FB80nokiacom_--


From nobody Tue Jul 18 05:45:55 2017
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 33F29131E09; Tue, 18 Jul 2017 05:45:48 -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 (2048-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 KRRktsrVlgjG; Tue, 18 Jul 2017 05:45:47 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 124CA129B10; Tue, 18 Jul 2017 05:45:47 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6ICg5DZ032318; Tue, 18 Jul 2017 13:45:44 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=gLxYEupd7k8x4RE+2BESVDHbfiNpiQ0We/52/MswElQ=; b=j8wgKcyRExg+vKGgZqFeBU9WIouFTtepgZvp1qC831vIZ1wFGqaG9XxKXVNu6wbIdZtl rt36EVBAuT3ntbPDcDqBBu0MJXWvLaqUiy6IUiB797DgbL/YG4NXfTHDZohXSGoBUqZJ m4V3x/QHwFYLJux79bZ++AzlUx0IVf/5qoMnV33o92Oha0a8nbf87ZS/pLeKsxIoBjex u6ZI9y6IUzwntPhDJcGi2uNfO6NwsCXRFLjIkilu01xnLnnCk2I+nyR532trSrXMurE3 aj4KOQ+aNWj8DaMoqduU91o3HGIfmPs5jToD5DjOdijW44GbD7VyPSPmv+W6VeuEwUc1 iw== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bs7vsa5kh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 13:45:44 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6ICfhAT017338; Tue, 18 Jul 2017 08:45:43 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecu83md-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 08:45:43 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 18 Jul 2017 05:45:42 -0700
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.1263.000; Tue, 18 Jul 2017 08:45:42 -0400
From: "Salz, Rich" 
To: Nick Sullivan , Sean Turner ,  "" 
CC: "lurk@ietf.org" 
Thread-Topic: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
Thread-Index: AQHS/7YFJL/ZiBkmWkmJeFDwmY5i2qJZh80g
Date: Tue, 18 Jul 2017 12:45:41 +0000
Message-ID: <74e61e9189db490abff8708d2bf3932f@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.153.157]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707180198
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707180198
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 12:45:48 -0000

PiBDb24gc2hvcnQtbGl2ZWQgY2VydHM6DQo+IC0gUG90ZW50aWFsbHkgcHJvYmxlbWF0aWMgdG8g
dGhlIENUIGVjb3N5c3RlbSAoYWxsIGNlcnRpZmljYXRlcyBtdXN0IGJlIGxvZ2dlZCBpbiBDVCwg
d2hpY2ggbWF5IGJsb2F0IHRoZW0pLg0KDQpUaGF0J3MgYSBicm93c2VyIHBvbGljeSwgbm90IGFu
IElFVEYgcmVxdWlyZW1lbnQsIHJpZ2h0Pw0KDQo=


From nobody Tue Jul 18 05:47:28 2017
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 7E56212EC46; Tue, 18 Jul 2017 05:47:26 -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 (2048-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 MF5NgG017ocL; Tue, 18 Jul 2017 05:47:25 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 63415129B10; Tue, 18 Jul 2017 05:47:25 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6ICkcYe003272; Tue, 18 Jul 2017 13:47:24 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=V4R0xW1roHJiWkYCuOT82VUZgOVcH5GtMYhpfTGextE=; b=dLzh/RXlwsP5PXhjsRJDWi+Me8DesDxHj5guc4E8+LScw379fEmL5wY4wgz/P4fpf+xQ 5GsWiGLG046V9X6KK6cEk7gGQmE2UmUssXfgnjNlSjwW8bbWwCgJtRqFo1dM8K3UI3VU G83/N8w2Vn6hCygmBPi9fEfdorCCkW0ft8AOfMdzJ4isaunESpAq8Lh16/4QenDM3kbu X1JB/CZ7miVlK/274wGaRKOeJP/Xcq5oqMANCh2YOYfeFYG5EIns9PoNPEg+FLRrbIiG 6+4u3OqaxSJUiiijbhp7vte8vZ/KnaD+MDz4jEvF2qCuJfamLlzULYJ5+NQMndcuf+y4 7A== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bs7vsa5v7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 13:47:24 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6ICk9dX020473; Tue, 18 Jul 2017 08:47:23 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecu83s0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 08:47:22 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 18 Jul 2017 08:47:21 -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.1263.000; Tue, 18 Jul 2017 08:47:22 -0400
From: "Salz, Rich" 
To: "Salz, Rich" , Nick Sullivan , Sean Turner , "" 
CC: "lurk@ietf.org" 
Thread-Topic: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
Thread-Index: AQHS/7YFJL/ZiBkmWkmJeFDwmY5i2qJZh80ggAAAmTA=
Date: Tue, 18 Jul 2017 12:47:21 +0000
Message-ID: 
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>  <74e61e9189db490abff8708d2bf3932f@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <74e61e9189db490abff8708d2bf3932f@usma1ex-dag1mb1.msg.corp.akamai.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.153.157]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707180199
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707180199
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 12:47:26 -0000

> > Con short-lived certs:
> > - Potentially problematic to the CT ecosystem (all certificates must be
> logged in CT, which may bloat them).
>=20
> That's a browser policy, not an IETF requirement, right?

And to be even more pedantic, it's the possible-future policy of Chrome, bu=
t not yet required nor implemented


From nobody Tue Jul 18 06:08:36 2017
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 A207313188D for ; Tue, 18 Jul 2017 06:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] 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 b88ivGasv4LI for ; Tue, 18 Jul 2017 06:08:33 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002: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 58D2E12EC3F for ; Tue, 18 Jul 2017 06:08:33 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id 70so6128817ybn.2 for ; Tue, 18 Jul 2017 06:08:33 -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=VRo6GRljCO9Xo5Wu3Ssc/K5b7zAOoZRwYbRQrUJDr/M=; b=rN/y/a9CBqnSbyFQLu52o1d6t6Uh9NeHHtpVLDKt7m5WlulBGcYpMmeA8IFwVfytl8 MsekRfrQp2Fvt7Efyq30ThB8TJLL/s6QYbafnVNuOff1DfZY9/PK4KQxJ7ii9FKeZGs3 Llb24aO+4r0X5Aygj/FjZPFFJyv+bfUZURreSb5Zdl2V26FzUUyPtV1ElCasEsHgsZbQ 10uVmuAsjaXN1QH8JbSSYdB3pPhl6UKLS48RQMQfgKNpvjWD+GCKOqVoj8b8PuYla7c+ 4P+6bwDAfCCrFwu3J+Nd9i646sSZ2PZIfYXTU5QcCeXQTXuNWBFPLtfbFgGG8cYqrARP SE1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VRo6GRljCO9Xo5Wu3Ssc/K5b7zAOoZRwYbRQrUJDr/M=; b=ZQPfN3A0MR4pHdi9iqdT2kxqMUu/5GQZEdQTvlDIHQg6J3XOQCLP7bBSxzufXyH4sG bMB4/P2OUBSn5Df68BaPFms4edz8OLSRoWezQyfFbUPWkba1EU2UCufPGV1vfvhYjuJO 089F1b3e45vS45XLrcg0ICpKu3EWjZPVcULVypaZnWOlftezjXK0xA8neRWCA+sLA/rG atMojdWVhbFFO+cDjxH82/M748MQqBN39EnZGZmpATLVXD0q9F5dtGs+gEUGvo4Uu6JI 6aJhWjJ2CQtzhkg/vM/N1VLty7OfBZvOGozP/CU3tdvwxKoFtdFskst3J3oN0vw+aphX KSlA==
X-Gm-Message-State: AIVw113uJWCxoCd7aWXFvQRpsJ6GorvOT97+vWRkXPy3UQa2dIkvINhP DL6ntuEA8dEEIr/vDBGkb09AzUhKTjMg
X-Received: by 10.37.212.150 with SMTP id m144mr1251080ybf.256.1500383312533;  Tue, 18 Jul 2017 06:08:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.215.9 with HTTP; Tue, 18 Jul 2017 06:07:52 -0700 (PDT)
In-Reply-To: <752c2b4e-fb24-6857-ac88-e42504029dd6@akamai.com>
References: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com>   <752c2b4e-fb24-6857-ac88-e42504029dd6@akamai.com>
From: Eric Rescorla 
Date: Tue, 18 Jul 2017 06:07:52 -0700
Message-ID: 
To: Benjamin Kaduk 
Cc: Sean Turner , "" 
Content-Type: multipart/alternative; boundary="94eb2c07cd065ef41f05549736a8"
Archived-At: 
Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 13:08:36 -0000

--94eb2c07cd065ef41f05549736a8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk  wrote:

> On 07/11/2017 03:50 PM, Eric Rescorla wrote:
>
>
>
> On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk 
> wrote:
>>
>>
>> Another question I also relates to 0-RTT, specifically with the freshnes=
s
>> checks and the case where the computed expected_arrival_time is in outsi=
de
>> "the window" by virtue of being in the future. (See the Note: at the end=
 of
>> section 8.2.) (The case where the expected_arrival_time is in the past c=
an
>> clearly be treated as "this is a stale request" and the current text abo=
ut
>> aborting with "illegal_parameter" or rejecting 0-RTT but accepting the P=
SK
>> is acceptable, even if it doesn't give guidance as to what might cause
>> someone to pick one behavior or the other.)  I am wondering whether we
>> should consider this to be a potential attack and abort the connection. =
 I
>> concede that there are likely to be cases where this
>> situation occurs incidentally, for clients with extremely fast-running
>> clocks, and potential timezone/suspend-resume weirdness.  But there is a=
lso
>> the potential for a client that deliberately lies about its ticket age a=
nd
>> intends to replay the wire messages when the age becomes in window, or a=
n
>> attacker that records the messages and knows that the client's clock is =
too
>> fast, or other cases.  (A client that deliberately does this could of
>> course just send the same application data later as well.)  If the time =
is
>> only a few seconds out of the window, then delaying a response until it =
is
>> in the window and only then entering it into the single-use cache might =
be
>> reasonable, but if the time is very far in the future, do we really want=
 to
>> try to succeed in that case?
>>
>
> If the time is very far in the future, the text is supposed to tell you t=
o
> fall back
> to 1-RTT...
>
>
> I agree that that is what the text currently says.  I'm questioning
> whether that's actually the behavior we want.
>
> That is, in this case, the CH+0RTT data can be replayed by an observer
> once enough time has elapsed that the expected_arrival_time is within the
> window, similar to one of the reordering attacks mentioned elsewhere.  We
> could add the CH to the strike register in this case, which would bloat i=
ts
> storage somewhat and have entries that take longer than the window to
> expire out.
>
> I don't have a good sense for how often we expect postdated CHs to occur
> and whether the ensuing breakage would be manageable, but I'm not sure th=
at
> we've thought very hard as a group about this question.
>

I think post-dated are going to happen pretty often based on what I
understand from
Kyle and others. I wouldn't be comfortable with hard fail, especially given
that this
just seems like the dual of the other case. Adding the CH to the list seems
like
a problem because it might stay forever.

-Ekr


>
>
>
>
>
> It looks like we no longer do anything to obsolete/reserve/similar the
>> HashAlgorithm and SignatureAlgorithm registries; was that just an editor=
ial
>> mixup or an intended change?
>>
>
> https://tlswg.github.io/draft-ietf-tls-iana-registry-
> updates/#orphaned-registries
> 
>
>
> Oh right, I forgot about that -- thanks.
>
>
> We removed the API guidance for separate APIs for read/writing early data
>> versus regular data, which I believe had consensus.  But I thought we we=
re
>> going to say something carefully worded about having an API to determine
>> whether the handshake has completed (or client Finished has been validat=
ed,
>> or ...), and it looks like this is buried at the end of E.5(.0), with th=
e
>> string "API" not appearing.  It might be useful to make this a little mo=
re
>> prominent/discoverable, whether by subsection heading or otherwise.
>>
>
> Suggestions welcome for where this would be better....
>
>
> I'll see if I have time to think about it some more.
>
> -Ben
>

--94eb2c07cd065ef41f05549736a8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk <<=
a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com=
> wrote:

 =20
   =20
 =20
  

    On 07/11/2017 03:50 PM, Eric Rescorla wrote:

    

     =20
      


        


          
On Tue, Jul 11, 2017 at 1:39 PM,
            Benjamin Kaduk <bkaduk@akamai.com>
            wrote:
            

              
 

                Another question I also relates to 0-RTT, specifically
                with the freshness checks and the case where the
                computed expected_arrival_time is in outside "the
                window" by virtue of being in the future. (See the Not=
e:
                at the end of section 8.2.) (The case where the
                expected_arrival_time is in the past can clearly be
                treated as "this is a stale request" and the curr=
ent
                text about aborting with "illegal_parameter" or
                rejecting 0-RTT but accepting the PSK is acceptable,
                even if it doesn't give guidance as to what might cause
                someone to pick one behavior or the other.)=C2=A0 I am
                wondering whether we should consider this to be a
                potential attack and abort the connection.=C2=A0 I concede
                that there are likely to be cases where this

                situation occurs incidentally, for clients with
                extremely fast-running clocks, and potential
                timezone/suspend-resume weirdness.=C2=A0 But there is also
                the potential for a client that deliberately lies about
                its ticket age and intends to replay the wire messages
                when the age becomes in window, or an attacker that
                records the messages and knows that the client's clock
                is too fast, or other cases.=C2=A0 (A client that
                deliberately does this could of course just send the
                same application data later as well.)=C2=A0 If the time is
                only a few seconds out of the window, then delaying a
                response until it is in the window and only then
                entering it into the single-use cache might be
                reasonable, but if the time is very far in the future,
                do we really want to try to succeed in that case?

            

            


            

            
If the time is very far in the future, the text is
              supposed to tell you to fall back

            
to 1-RTT...

            


            

          

        

      

    

    

    I agree that that is what the text currently says.=C2=A0 I'm questi=
oning
    whether that's actually the behavior we want.

    

    That is, in this case, the CH+0RTT data can be replayed by an
    observer once enough time has elapsed that the expected_arrival_time
    is within the window, similar to one of the reordering attacks
    mentioned elsewhere.=C2=A0 We could add the CH to the strike register i=
n
    this case, which would bloat its storage somewhat and have entries
    that take longer than the window to expire out.

    

    I don't have a good sense for how often we expect postdated CHs to
    occur and whether the ensuing breakage would be manageable, but I'm
    not sure that we've thought very hard as a group about this
    question.

I think post-dated are =
going to happen pretty often based on what I understand from
Kyle=
 and others. I wouldn't be comfortable with hard fail, especially given=
 that this
just seems like the dual of the other case. Adding the=
 CH to the list seems like
a problem because it might stay foreve=
r.

-Ekr
=C2=A0


    

    

    

      

        

          

            


            

            


            

            

              
 It looks like we no longer do
                anything to obsolete/reserve/similar the HashAlgorithm
                and SignatureAlgorithm registries; was that just an
                editorial mixup or an intended change?

              

            

            


            

            
            


            

          

        

      

    

    

    Oh right, I forgot about that -- thanks.

    

    

      

        

          

            


            

            

              
 We removed the API guidance for
                separate APIs for read/writing early data versus regular
                data, which I believe had consensus.=C2=A0 But I thought we
                were going to say something carefully worded about
                having an API to determine whether the handshake has
                completed (or client Finished has been validated, or
                ...), and it looks like this is buried at the end of
                E.5(.0), with the string "API" not appearing.=C2=
=A0 It might
                be useful to make this a little more
                prominent/discoverable, whether by subsection heading or
                otherwise.

              

            

            


            

            
Suggestions welcome for where this would be better....
            

          

        

      

    

    

    I'll see if I have time to think about it some more.

    

    -Ben

  






--94eb2c07cd065ef41f05549736a8--


From nobody Tue Jul 18 06:20:18 2017
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 89230131B41; Tue, 18 Jul 2017 06:20:10 -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 G9fiDHbrQCDz; Tue, 18 Jul 2017 06:20:09 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1538513181F; Tue, 18 Jul 2017 06:20:09 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id p188so16808195oia.0; Tue, 18 Jul 2017 06:20:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r9TQwruK4xi43Ht3P7F+XNuOKrsZXqy3857WfRO8xlU=; b=JYxKxihQwf/oQcnx+van5XQKq4sFVzNRItj/Z+K3Orn9HEmFnWamt0Qk2HFyrgQBb5 n9rYioVjGH7t7f2lUlN4XpFeDHHsH6X3TfqrKgWyOKoxAU9nU1fmmhDllDW7876cWfjq mrQJeV6Kl9txnQZoieZCFKN7pxUzsNn9ORbeCpt5uKtqLvMSNnR5TtXy1r0y1GEbtQTz UmaK0wosQk4WJ3oBsHMPs9whvE1cszlnsllydExVvtnCazUPVV9LQejV8dCOO0/OeM3X MQDylIHvV/KaTPt3AlE4jXnKYO/3XYHASffwOhvlwCPxIBxTAxXiIzs0ryKPfarlQQv6 ptEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r9TQwruK4xi43Ht3P7F+XNuOKrsZXqy3857WfRO8xlU=; b=fdpQMnx8jZR6YqrPEsQeMune++kgTF48CJOvyks08Lc/CVOGH8PQSZuKfcAJEK0JCf NtJ49JziD0XPTkiZfI/QcCn6N6924/tV2GZ3zaHAEwYfn6BzcObfSiwmoySQCQgKYrH4 Oll8gP3pRWXTxQ1ipdpG9Bq3PM+bKgHKJ2hZ8cKsxLItrXcdbFbHbJwzUObuL/jSCG6p 6FAH0WWMeyWF4FyNiwLmeuCVY+C5/C4CDcSfslD4FCP2lHguo+J3SrH1T6GDHgqC3RVa JEpkXjL+FJDDSkY65ODuSCbq0UQ0x7C138PbBJfYoJQOF880ne1eP6vZLwAXRRc68Z4/ Vd/A==
X-Gm-Message-State: AIVw110ATP4hzf1ngKNamX9+KqtT+UhuAgvpTAK6ZBybL95XG+3bYMFZ WYSv59S2kSlrbw2IwEOf4HSK6mksSw==
X-Received: by 10.202.213.216 with SMTP id m207mr1049674oig.17.1500384008336;  Tue, 18 Jul 2017 06:20:08 -0700 (PDT)
MIME-Version: 1.0
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>  <74e61e9189db490abff8708d2bf3932f@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <74e61e9189db490abff8708d2bf3932f@usma1ex-dag1mb1.msg.corp.akamai.com>
From: Nick Sullivan 
Date: Tue, 18 Jul 2017 13:19:57 +0000
Message-ID: 
To: "Salz, Rich" , Sean Turner , "" 
Cc: "lurk@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113d34cad7fb590554975ff2"
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 13:20:10 -0000

--001a113d34cad7fb590554975ff2
Content-Type: text/plain; charset="UTF-8"

It's a reality of the current CT system. If a crawler sees a short-lived
certificate, it will submit it to a CT log and it will be accepted.

On Tue, Jul 18, 2017 at 2:45 PM Salz, Rich  wrote:

> > Con short-lived certs:
> > - Potentially problematic to the CT ecosystem (all certificates must be
> logged in CT, which may bloat them).
>
> That's a browser policy, not an IETF requirement, right?
>
>

--001a113d34cad7fb590554975ff2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It's a reality of the current CT system. If a crawler =
sees a short-lived certificate, it will submit it to a CT log and it will b=
e accepted.

On Tue,=
 Jul 18, 2017 at 2:45 PM Salz, Rich <rsalz@akamai.com> wrote:
&g=
t; Con short-lived certs:

> - Potentially problematic to the CT ecosystem (all certificates must b=
e logged in CT, which may bloat them).



That's a browser policy, not an IETF requirement, right?






--001a113d34cad7fb590554975ff2--


From nobody Tue Jul 18 06:35:16 2017
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 3B452131905; Tue, 18 Jul 2017 06:35: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 Yqr4OWkbhH-M; Tue, 18 Jul 2017 06:35:12 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1899A12EC3F; Tue, 18 Jul 2017 06:35:11 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id x187so16850800oig.3; Tue, 18 Jul 2017 06:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vv4pxVue6e3GhKqHZFLM31rjlJuwbxKw1xQWc+ukrjM=; b=i0pwJwwg2QfWNvh9o0vnEjaJ8xxu6wKPOlPUYY7ovbIR+itwF0WeS4iApi3JKIK6hi RlgRgNBd+xu0ED9sCk5ydnA9+Pv4flgB2bs4NK2yYsUmllsN4CBNZnuYyqByRO7WVmHy kLbzDGGNyFQcrnYXVf3dAlY1iH3chl+LnuvKTMcJH1K+XaVHtzs81NYmDGuuENVKNaj6 E4hThNG8qqdP46d3BmUjlmooFCvKGmnfoDzFY5t4sPbK3jN99okwvj+f1iTpeGHsjASg 8DXNFE6p3KLBixoJdr14yzgyKibbsK1cSfbcal88wOeNy+51W2W9yr55KADzKZyKwDsh c+Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vv4pxVue6e3GhKqHZFLM31rjlJuwbxKw1xQWc+ukrjM=; b=lxLOLlpRGT62QnE5sby5ihfVpplhnLcNzRjSQoPBRO3V0xTtiTfuStjwfhBrssUPmp 721GwppDlWvEYx514moJwq6gcm9lSH65Bkbv5KF87TzT786S9WcUQzUk1PsAT7hJ4g7A 0LtrajuY8peXQNk2CWurpKiJOffiW6Guy9fSB7te6PYRvaWdm7JAnCnBwYXmUde3nkwl r7qmoXXfMj204l71HuRa9pMaBRI+h/8+Fz7luF+6puHx4Q55ahFskJlsNE+ZEu/ifsP2 x39nUaGSSdJuPhgWsI1PR96c1+MPZGKMQlB66IBo8MY33arIgidLhXZLZ2g8Zt2Xogkg NBgw==
X-Gm-Message-State: AIVw110e91nITFiM3Gy0mt67XvbHLzwiGAAnxC0wydZRhwZMl/AXocuH YyJ+1di5BkyToJPmQHuNS8NOXfHyqw==
X-Received: by 10.202.87.130 with SMTP id l124mr1106887oib.209.1500384911149;  Tue, 18 Jul 2017 06:35:11 -0700 (PDT)
MIME-Version: 1.0
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>  <61435CE8-3A17-4773-8329-54908985FB80@nokia.com>
In-Reply-To: <61435CE8-3A17-4773-8329-54908985FB80@nokia.com>
From: Nick Sullivan 
Date: Tue, 18 Jul 2017 13:35:00 +0000
Message-ID: 
To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Sean Turner , "" 
Cc: "lurk@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113d360ea7d32705549795d5"
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 13:35:15 -0000

--001a113d360ea7d32705549795d5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thomas,

Thanks for your comments. Let me see if I can summarize them:

- A disadvantage of delegated credentials vs short-lived certs is that it
requires client opt-in. This is also a disadvantage of proxy certificates.
If client support is below 100%, a LURK-type system may be required to keep
long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software
updates on both client and server. This is also a disadvantage of proxy
certificates. I think this is covered by my point below: "Short lived certs
work with existing libraries, no new code changes."
- An advantage of short-lived certificates is that there is an audit log by
a third party (either the CA's internal logs and optionally Certificate
Transparency logs).

I should state that short-lived certificates are possible right now and
it's supported by some CAs, though not necessarily at the scale needed to
provide, say, a unique 7-day certificate for each server of a large
Internet company. This draft's advantages apply most strongly to
organizations who don't want to tie their ability to have functional TLS on
the ability for CAs to maintain high-availability issuance services.  How
much Delegated Credentials can be rotated and diversified inside an
organization is only limited by the operational ability of the organization
that has control of the EE private key.

Nick

On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) =
<
thomas.fossati@nokia.com> wrote:

> Hi Nick,
>
>
>
> I am not against delegated credentials, in fact I think it=E2=80=99s a go=
od thing
> per se.
>
>
>
> I had expressed a couple of concerns at the time the call for adoption wa=
s
> first issued [1], which I think are still valid.
>
>
>
> Could you please comment on / add them to your pro-cons analysis?
>
>
>
> Cheers, thanks,
>
> t
>
>
>
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html
>
>
>
> On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" <
> tls-bounces@ietf.org on behalf of nicholas.sullivan@gmail.com> wrote:
>
>
>
> Sean,
>
> We've had some additional discussions in person here at IETF 99 with folk=
s
> who were in the proxy certificates and short-lived certs camp, and we thi=
nk
> there is now more agreement that the mechanism described in this draft is
> superior to the alternatives. I've included a summary of some of the pros
> and cons of the approaches:
>
> *Proxy certificates vs. Delegated Credentials*
>
> *Pro proxy certificates*:
>
> - Already deployed in some industries, though not on the Web.
>
> - Fits the conceptual model that public key =3D=3D certificate.
>
> *Con proxy certificates*:
>
> - Proxy certificates adds additional complexity to the delegation other
> than limiting the time period (full X.509, additional constraints  such a=
s
> hostname).
>
> - Encourages implementers to reuse PKIX libraries rather than build code
> as part of TLS:
> -- There have been problems and inconsistencies around pathlen and
> constraints enforcement in existing PKIX libraries.
> -- Modifying these libraries is more complex and risk prone than delegate=
d
> creds (which can easily be implemented in TLS as demonstrated by the 3
> interoperable implementations at the IETF 98 hackathon).
>
> - In proxy certificates, pathing is SKI dependent, not directly tied to E=
E
> cert. This is a binding weaker than delegated credentials which includes =
a
> signature over the EE certificate.
>
>
>
> *Short-lived certs vs. Delegated Credentials*
>
> *Pro short-lived certs*:
>
> - Short lived certs work with existing libraries, no new code changes.
>
> *Con short-lived certs*:
>
> - Not widely available from CAs, especially for EV.
>
> - Potentially problematic to the CT ecosystem (all certificates must be
> logged in CT, which may bloat them).
>
> - Introduces a high-risk operational dependency on external party:
> -- Requires frequent exchanges with an external Certificate Authority
> (must provide proof of domain possession to CA vs. internally managed
> credential minter for delegated credentials).
>
> -- There is no fallback if the CA has outage. With delegated credentials
> you can fall back to a LURK-style protocol with the long-lived certificat=
e
> key.
>
>
>
> Given these comparisons, we think the proposed draft is the superior
> option and would like to continue the discussion about adopting it.
>
>
>
> Nick
>
>
>
> On Fri, May 19, 2017 at 12:58 AM Sean Turner  wrote:
>
> All,
>
> During the WG call for adoption, a couple of questions were raised about
> comparison/analysis of sub-certs versus proxy and/or short-lived
> certificates.  There is some discussion currently in the draft, but the
> chairs feel that these issues need further discussion (and elaboration in
> the draft) prior to WG adoption.  So let=E2=80=99s keep the conversation =
going.
>
> J&S
>
> > On Apr 12, 2017, at 15:31, Sean Turner  wrote:
> >
> > All,
> >
> > At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the
> list so please let the list know whether you support adoption of the draf=
t
> and are willing to review/comment on the draft before 20170429.  If you
> object to its adoption, please let us know why.
> >
> > Clearly, the WG is going to need to work through the trade-offs between
> short-lived certificates and sub-certs because both seem, to some, to be
> addressing the same problem.
> >
> > Cheers,
> >
> > J&S
> >
> > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a113d360ea7d32705549795d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



--001a113d360ea7d32705549795d5--


From nobody Tue Jul 18 06:57:00 2017
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 2C85613167D; Tue, 18 Jul 2017 06:56:58 -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, HTML_MESSAGE=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=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 OLz68cY_TyZ9; Tue, 18 Jul 2017 06:56:56 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9C125129B15; Tue, 18 Jul 2017 06:56:56 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6IDpxYL001092; Tue, 18 Jul 2017 14:56:52 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=mDeKH+9GSw3DMYfzgXP6ghxWvc6P4ZX/NN30b0tp0+Q=; b=jDuAhewaCZKreovIixz4YVLfH31hCsRgmKUcr3yVE4tf5IzODtO/DP5U6mgUENm9rBei LW+FTkXIPBR0U/gS1cv0WUflMy+Hx4OTdI4H4tWFWD9L0xLiqAW4AFoGaJpLDLC1pRYY o/gHBHSFvoPWi67KtYw4R2qV7Phlw7HVdf32CL9IM5hdLd5WC1NuvfnzYKDxhB6vO3lN ofOxDjEHn09MHjSKl93ASv0CnbVP8TH1Eb1VANYKKrjF+Ay/ClbV+YTHyGTErMA7ecJ4 9Fk4Ftk10e2PjNVzCetyeqJl2dWzEEQYLWjB5fThtwZGwJarnQ2PJh2bZheSnH6x6Duj BQ== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2bqbf9ccgr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 14:56:52 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6IDu4hI005838; Tue, 18 Jul 2017 09:56:51 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecu8bbq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 09:56:51 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 18 Jul 2017 06:56:50 -0700
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.1263.000; Tue, 18 Jul 2017 09:56:50 -0400
From: "Salz, Rich" 
To: Nick Sullivan , Sean Turner ,  "" 
CC: "lurk@ietf.org" 
Thread-Topic: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
Thread-Index: AQHS/7YFJL/ZiBkmWkmJeFDwmY5i2qJZh80ggABM7oD//8cocA==
Date: Tue, 18 Jul 2017 13:56:50 +0000
Message-ID: 
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>  <74e61e9189db490abff8708d2bf3932f@usma1ex-dag1mb1.msg.corp.akamai.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.153.157]
Content-Type: multipart/alternative; boundary="_000_fa802ecb3e714820946c553fcca5d5e5usma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707180221
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707180219
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 13:56:58 -0000

--_000_fa802ecb3e714820946c553fcca5d5e5usma1exdag1mb1msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T2theSwgeW91IHNhaWQg4oCccG90ZW50aWFsbHnigJ0gYSBwcm9ibGVtLiAgSSBndWVzcyBzby4N
Cg==

--_000_fa802ecb3e714820946c553fcca5d5e5usma1exdag1mb1msgcorpak_
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
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu
az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9rYXksIHlvdSBzYWlkIOKAnHBvdGVudGlhbGx54oCdIGEg
cHJvYmxlbS4mbmJzcDsgSSBndWVzcyBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_fa802ecb3e714820946c553fcca5d5e5usma1exdag1mb1msgcorpak_--


From nobody Tue Jul 18 08:23:41 2017
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 0E62D131B26 for ; Tue, 18 Jul 2017 08:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8sdRptFIure for ; Tue, 18 Jul 2017 08:23:34 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBD612EC19 for ; Tue, 18 Jul 2017 08:23:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 75020BE38 for ; Tue, 18 Jul 2017 16:23:31 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rar8MgkLpY64 for ; Tue, 18 Jul 2017 16:23:29 +0100 (IST)
Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9A49DBE2C for ; Tue, 18 Jul 2017 16:23:29 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500391409; bh=Mod8/72jnI/pxZN/U3o4Xt+BXzLbe7h1ZTfw1DBt3AI=; h=Subject:References:To:From:Date:In-Reply-To:From; b=ye5zQubBGhxi1/RlVKUCauVCcY6Zi0m4zmGTbeMknPdEG5q/KJFQKOf4HdlbO43Tu nMpe6+Dlr/r67g8LNB6Uy9U8/Khs7WGuFwikW1CdzQIu+ht7hfEmfRBzgFSXSYlWT7 Xvu+NcG1hBgmJdxzmNsLDLrzkLm6sf0Z0ntzfIt8=
References: 
To: "tls@ietf.org" 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5537764a-b7b8-038b-783e-28000bb9b7e6@cs.tcd.ie>
Date: Tue, 18 Jul 2017 16:23:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OMJ10eRgwmFHdBF5rHoThLGDMLhIF7GiQ"
Archived-At: 
Subject: Re: [TLS] possible new work item: not breaking TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 15:23:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--OMJ10eRgwmFHdBF5rHoThLGDMLhIF7GiQ
Content-Type: multipart/mixed; boundary="wi4PwCEUPTpGdg4ocpCWkQscnGMmnqpNP";
 protected-headers="v1"
From: Stephen Farrell 
To: "tls@ietf.org" 
Message-ID: <5537764a-b7b8-038b-783e-28000bb9b7e6@cs.tcd.ie>
Subject: Re: [TLS] possible new work item: not breaking TLS
References: 
In-Reply-To: 

--wi4PwCEUPTpGdg4ocpCWkQscnGMmnqpNP
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Hiya,

Thanks to the chairs for allocating some agenda time for
discussion of this topic at tomorrow's session. I plan to
more or less present [1] instead of using slides, so if
folks have a chance to read it over before we get to that
agenda item tomorrow that should help speed things up a
bit.

I'm still happy to take corrections, comments and suggestions
however folks would like to provide those but plan to be at
the social event tonight so likely won't do more updates to
the text before tomorrow morning (semi-inebriated additions
being a bad plan, even if nowhere near as bad a plan as
draft-green:-)

Cheers,
S.

[1] https://github.com/sftcd/tinfoil

On 13/07/17 13:00, Stephen Farrell wrote:
>=20
> Hi again TLS WG chairs,
>=20
> I've done a bit more work on the collection of arguments
> against the latest break-TLS proposal. [1] I plan to keep
> working on that so more input is welcome. (Corrections
> where I've gotten stuff wrong are even more welcome.)
>=20
> I'd like to again request some time on the agenda to
> allow discussion of those points in a more structured
> manner than will be possible during the mic-line scrum
> that'll likely follow a sales-pitch for draft-green.
>=20
> I'd also like to ask the WG if we think it'd be useful
> to document the arguments against that and other "let's
> break-tls" proposals we've seen in the past in an RFC.
> If people think it would be useful, I'd be willing to
> do work to edit such a draft, or help edit that.
>=20
> Thanks,
> S.
>=20
> [1] https://github.com/sftcd/tinfoil
>=20
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>=20


--wi4PwCEUPTpGdg4ocpCWkQscnGMmnqpNP--

--OMJ10eRgwmFHdBF5rHoThLGDMLhIF7GiQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZbifuAAoJEC88hzaAX42i4ZAH/20iqRkPXCCyECywWnKPutTA
gEcTCqLX+jH+odGvi9KNeIQbE3iqh7f98KcKPDAfDHQh8y3hPwYnCz1CqHGiXI0y
aD7feA5unt2Q/jblaQSRAEdrLiHlTgq/WsuEhLt54mvch+LzKhcNEJQUzULbioks
BK9NcbCW9HckTMc4jMvsYjGFoYAfyBU9rKKAOz1X7G9UYZsEPDVejkP2ZLVwzAXC
KF5FefDKgNu/6pUpuIwR0LGFy2eR2GcOYWsBLZPtBEnWbb3SkcV6rwv0HKlM5Ffl
ra02Wu1JiWnbpveUEwDcRnd2BpSzfAf6aaQclhnivD8h+0eVhrG1G2aZCU3IOvI=
=Np3n
-----END PGP SIGNATURE-----

--OMJ10eRgwmFHdBF5rHoThLGDMLhIF7GiQ--


From nobody Tue Jul 18 09:26:15 2017
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 96383129B5E; Tue, 18 Jul 2017 09:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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, RCVD_IN_MSPIKE_H2=-2.8, 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=nokia.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 Zi9u_zgNa3CU; Tue, 18 Jul 2017 09:26:11 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40101.outbound.protection.outlook.com [40.107.4.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 BB070131B88; Tue, 18 Jul 2017 09:26:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rSOs8v1IM93Jj6SG4xnH6cFRfbmaRpCDVFIFu7HosiE=; b=RJ/OL6xy+HNkQHXTgl14YWBs3dnIsBvLdu3HWhsF9LRqEMhdSqwRhrBaaChpgsRCqhabMeMOzQx6YjHejyHovzyTfpNlS9BNn0PN0mNg+KH2i1beHrLLc43s7xl4RhSL0qv2xkNe5rurxanJloxiBZw3hwL9Fs+hXyN1pwdElVs=
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB0895.eurprd07.prod.outlook.com (10.161.108.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Tue, 18 Jul 2017 16:26:07 +0000
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::d0a5:5d5d:c414:4b10]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::d0a5:5d5d:c414:4b10%14]) with mapi id 15.01.1282.008; Tue, 18 Jul 2017 16:26:06 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" 
To: Nick Sullivan , Sean Turner ,  "" 
CC: "lurk@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" 
Thread-Topic: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
Thread-Index: AQHS0CpTH+tPQf6rjUes9Cw+A0SKZqJZy5mAgAAaMYCAAA8vAIAAQJGA
Date: Tue, 18 Jul 2017 16:26:06 +0000
Message-ID: 
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>  <61435CE8-3A17-4773-8329-54908985FB80@nokia.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [81.134.152.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB0895; 7:wdkl+1j+vKJ/7a9XZLtl1wc6VY25OT2f41VRwfPPR0cIv2yKcYNH9+nCFSaN/SFEGvU0sW4wYl+7DOL8QF47WS8xgLrCXnp/QSerUdTj8oficqDjTf8GCvkR/5kVr/QMgWezQDBJVUizAVTuUbcqXtKByRB5dt9OxkRP2Gdayw860vCuXLha3AolcDeUOTy9NmX04xomTTy82tJpRo5WoRM2yJSSEcX6tMZr2k2jBAQcOSrkXCfUjagfXzyKvTIQgy/uSjX6eIo+wPmSHEI2hQg4x1ddopPXdzMeS0qM4L9OjrySQN7e7X4TtKJ2E2PlqSmVGO6oAYByjd0RF2BzUo1c5mBUCoE8oXjY4FvkoUZLBsQSZvqdAcMROq1OxZQkFeSYvIXdFdWdFAt0dxTXduWkFowhbCFlzEEu594cZoPR0n8pt/XMVZq96B6cTRqd0KGaY0SYaSRP7saZVoLJwuFoUYkdz3DoRtBwC5eAz2lZxE52aqE3UiZIs9eAcjQTiNIK9/MkF4k3S0nauTvrddwqqcR6V6C0556c826qv6uspmwsLEMkt+jq+IMBzEdvNnhdvbBJn5CC4JBNhzMPyJleEoqNCiaBnRazmxv81JZC0MiBgzt+cC1GLTyaswCOtrBUIu83S7ZnTuJ7dQGGVoZXEbR4dZrWuPJSQ1meAcEw5xmEohJc6CTboed/uHpEaPd4rMEIAKPhdUxDRKObSXGQNGUhiwAgmW4b+ZVfgIMqIGkwkxB746b9GPFkRhjOPEHDDOc9ca0xDQXB70Bta5hdTty6Upv0tAiegOvrx8c=
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(39410400002)(39850400002)(39840400002)(39450400003)(39400400002)(24454002)(377454003)(189998001)(38730400002)(229853002)(8676002)(2900100001)(2906002)(6486002)(25786009)(6436002)(54356999)(236005)(76176999)(7736002)(478600001)(5660300001)(81166006)(50986999)(54906002)(9326002)(3280700002)(230783001)(6246003)(606006)(107886003)(53546010)(14454004)(4001350100001)(3660700001)(83716003)(6506006)(93886004)(36756003)(33656002)(4326008)(83506001)(39060400002)(82746002)(86362001)(8936002)(2950100002)(5250100002)(966005)(3846002)(6116002)(102836003)(54896002)(6306002)(99286003)(6512007)(66066001)(53936002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB0895; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
x-ms-office365-filtering-correlation-id: bdd1791e-f4dc-4a1c-a781-08d4cdf9b0f9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR07MB0895; 
x-ms-traffictypediagnostic: VI1PR07MB0895:
x-exchange-antispam-report-test: UriScan:(151999592597050)(60795455431006)(158342451672863)(133145235818549)(120809045254105)(26388249023172)(236129657087228)(150554046322364)(82608151540597)(48057245064654);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB0895; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB0895; 
x-forefront-prvs: 037291602B
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BB0F27F7F5CF4512A5D117E557D5D295nokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2017 16:26:06.4534 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0895
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 16:26:14 -0000

--_000_BB0F27F7F5CF4512A5D117E557D5D295nokiacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTmljaywNCg0KWW91ciB3cml0ZS11cCBpcyBzcG90IG9uLCB0aGFua3MuDQoNCkxldCBtZSBj
b21tZW50IG9uIGEgZmV3IHBvaW50czoNCg0K4oCcSG93IG11Y2ggRGVsZWdhdGVkIENyZWRlbnRp
YWxzIGNhbiBiZSByb3RhdGVkIGFuZCBkaXZlcnNpZmllZCBpbnNpZGUgYW4gb3JnYW5pemF0aW9u
IGlzIG9ubHkgbGltaXRlZCBieSB0aGUgb3BlcmF0aW9uYWwgYWJpbGl0eSBvZiB0aGUgb3JnYW5p
emF0aW9uIHRoYXQgaGFzIGNvbnRyb2wgb2YgdGhlIEVFIHByaXZhdGUga2V5LuKAnQ0KDQpUaGUg
c2VsZi1zZXJ2aWNlL2FnaWxlIG5hdHVyZSBvZiBELUMgaXMgZ3JlYXQuIFdpdGggdGhhdCwgdGhv
dWdoLCBjb21lcyBhIGNvc3Qgb2Ygb3duZXJzaGlwIHRoYXQgbWF5YmUgbm90IGFsbCBwbGF5ZXJz
IGNhbiBhZmZvcmQuDQoNCi0gSW50cm9kdWNlcyBhIGhpZ2gtcmlzayBvcGVyYXRpb25hbCBkZXBl
bmRlbmN5IG9uIGV4dGVybmFsIHBhcnR5Og0KLS0gUmVxdWlyZXMgZnJlcXVlbnQgZXhjaGFuZ2Vz
IHdpdGggYW4gZXh0ZXJuYWwgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IChtdXN0IHByb3ZpZGUgcHJv
b2Ygb2YgZG9tYWluIHBvc3Nlc3Npb24gdG8gQ0EgdnMuIGludGVybmFsbHkgbWFuYWdlZCBjcmVk
ZW50aWFsIG1pbnRlciBmb3IgZGVsZWdhdGVkIGNyZWRlbnRpYWxzKS4NCg0KVGhlcmUgc2hvdWxk
IGJlIHdheXMgdG8gbWl0aWdhdGUgdGhpcywgc2F5IGFsbG93aW5nIHRoZSBuZXh0IFMtVCBpbiBs
aW5lIHRvIGJlIGF2YWlsYWJsZSDigJxsb25nIGVub3VnaOKAnSBiZWZvcmUgaXQgYmVjb21lcyBh
Y3RpdmUuDQoNCi0tIFRoZXJlIGlzIG5vIGZhbGxiYWNrIGlmIHRoZSBDQSBoYXMgb3V0YWdlLiBX
aXRoIGRlbGVnYXRlZCBjcmVkZW50aWFscyB5b3UgY2FuIGZhbGwgYmFjayB0byBhIExVUkstc3R5
bGUgcHJvdG9jb2wgd2l0aCB0aGUgbG9uZy1saXZlZCBjZXJ0aWZpY2F0ZSBrZXkuDQoNCkkgdW5k
ZXJzdGFuZCB0aGUgbG9naWNzIGJ1dCwgc2luY2UgTFVSSyBib3hlcyBkb27igJl0IHNjYWxlLCB0
aGUgY29zdCB0byBjb3ZlciB5b3VyIGVudGlyZSBmb290cHJpbnQgZm9yIHRoZSBzcG9yYWRpYyBj
YXNlcyB3aGVuIHRoZSBDQSBpcyBkb3duIG1pZ2h0IGJlIGEgYml0IHByb2hpYml0aXZlLg0KDQpD
aGVlcnMsIHQNCg0KDQpPbiAxOC8wNy8yMDE3LCAxNDozNSwgIk5pY2sgU3VsbGl2YW4iIDxuaWNo
b2xhcy5zdWxsaXZhbkBnbWFpbC5jb208bWFpbHRvOm5pY2hvbGFzLnN1bGxpdmFuQGdtYWlsLmNv
bT4+IHdyb3RlOg0KDQpUaG9tYXMsDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIExldCBtZSBz
ZWUgaWYgSSBjYW4gc3VtbWFyaXplIHRoZW06DQotIEEgZGlzYWR2YW50YWdlIG9mIGRlbGVnYXRl
ZCBjcmVkZW50aWFscyB2cyBzaG9ydC1saXZlZCBjZXJ0cyBpcyB0aGF0IGl0IHJlcXVpcmVzIGNs
aWVudCBvcHQtaW4uIFRoaXMgaXMgYWxzbyBhIGRpc2FkdmFudGFnZSBvZiBwcm94eSBjZXJ0aWZp
Y2F0ZXMuIElmIGNsaWVudCBzdXBwb3J0IGlzIGJlbG93IDEwMCUsIGEgTFVSSy10eXBlIHN5c3Rl
bSBtYXkgYmUgcmVxdWlyZWQgdG8ga2VlcCBsb25nLXRlcm0gcHJpdmF0ZSBrZXlzIG9mZiBUTFMg
dGVybWluYXRpb24gZW5kcG9pbnRzLg0KLSBBIGRpc2FkdmFudGFnZSBvZiBkZWxlZ2F0ZWQgY3Jl
ZGVudGlhbHMgaXMgdGhhdCBpdCByZXF1aXJlcyBzb2Z0d2FyZSB1cGRhdGVzIG9uIGJvdGggY2xp
ZW50IGFuZCBzZXJ2ZXIuIFRoaXMgaXMgYWxzbyBhIGRpc2FkdmFudGFnZSBvZiBwcm94eSBjZXJ0
aWZpY2F0ZXMuIEkgdGhpbmsgdGhpcyBpcyBjb3ZlcmVkIGJ5IG15IHBvaW50IGJlbG93OiAiU2hv
cnQgbGl2ZWQgY2VydHMgd29yayB3aXRoIGV4aXN0aW5nIGxpYnJhcmllcywgbm8gbmV3IGNvZGUg
Y2hhbmdlcy4iDQotIEFuIGFkdmFudGFnZSBvZiBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgaXMg
dGhhdCB0aGVyZSBpcyBhbiBhdWRpdCBsb2cgYnkgYSB0aGlyZCBwYXJ0eSAoZWl0aGVyIHRoZSBD
QSdzIGludGVybmFsIGxvZ3MgYW5kIG9wdGlvbmFsbHkgQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5
IGxvZ3MpLg0KSSBzaG91bGQgc3RhdGUgdGhhdCBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgYXJl
IHBvc3NpYmxlIHJpZ2h0IG5vdyBhbmQgaXQncyBzdXBwb3J0ZWQgYnkgc29tZSBDQXMsIHRob3Vn
aCBub3QgbmVjZXNzYXJpbHkgYXQgdGhlIHNjYWxlIG5lZWRlZCB0byBwcm92aWRlLCBzYXksIGEg
dW5pcXVlIDctZGF5IGNlcnRpZmljYXRlIGZvciBlYWNoIHNlcnZlciBvZiBhIGxhcmdlIEludGVy
bmV0IGNvbXBhbnkuIFRoaXMgZHJhZnQncyBhZHZhbnRhZ2VzIGFwcGx5IG1vc3Qgc3Ryb25nbHkg
dG8gb3JnYW5pemF0aW9ucyB3aG8gZG9uJ3Qgd2FudCB0byB0aWUgdGhlaXIgYWJpbGl0eSB0byBo
YXZlIGZ1bmN0aW9uYWwgVExTIG9uIHRoZSBhYmlsaXR5IGZvciBDQXMgdG8gbWFpbnRhaW4gaGln
aC1hdmFpbGFiaWxpdHkgaXNzdWFuY2Ugc2VydmljZXMuICBIb3cgbXVjaCBEZWxlZ2F0ZWQgQ3Jl
ZGVudGlhbHMgY2FuIGJlIHJvdGF0ZWQgYW5kIGRpdmVyc2lmaWVkIGluc2lkZSBhbiBvcmdhbml6
YXRpb24gaXMgb25seSBsaW1pdGVkIGJ5IHRoZSBvcGVyYXRpb25hbCBhYmlsaXR5IG9mIHRoZSBv
cmdhbml6YXRpb24gdGhhdCBoYXMgY29udHJvbCBvZiB0aGUgRUUgcHJpdmF0ZSBrZXkuDQoNCk5p
Y2sNCg0KT24gVHVlLCBKdWwgMTgsIDIwMTcgYXQgMTo0MCBQTSBGb3NzYXRpLCBUaG9tYXMgKE5v
a2lhIC0gR0IvQ2FtYnJpZGdlLCBVSykgPHRob21hcy5mb3NzYXRpQG5va2lhLmNvbTxtYWlsdG86
dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPj4gd3JvdGU6DQpIaSBOaWNrLA0KDQpJIGFtIG5vdCBh
Z2FpbnN0IGRlbGVnYXRlZCBjcmVkZW50aWFscywgaW4gZmFjdCBJIHRoaW5rIGl04oCZcyBhIGdv
b2QgdGhpbmcgcGVyIHNlLg0KDQpJIGhhZCBleHByZXNzZWQgYSBjb3VwbGUgb2YgY29uY2VybnMg
YXQgdGhlIHRpbWUgdGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdhcyBmaXJzdCBpc3N1ZWQgWzFdLCB3
aGljaCBJIHRoaW5rIGFyZSBzdGlsbCB2YWxpZC4NCg0KQ291bGQgeW91IHBsZWFzZSBjb21tZW50
IG9uIC8gYWRkIHRoZW0gdG8geW91ciBwcm8tY29ucyBhbmFseXNpcz8NCg0KQ2hlZXJzLCB0aGFu
a3MsDQp0DQoNClsxXSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9j
dXJyZW50L21zZzIyOTY2Lmh0bWwNCg0KT24gMTgvMDcvMjAxNywgMTI6MDYsICJUTFMgb24gYmVo
YWxmIG9mIE5pY2sgU3VsbGl2YW4iIDx0bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxzLWJv
dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBuaWNob2xhcy5zdWxsaXZhbkBnbWFpbC5jb208
bWFpbHRvOm5pY2hvbGFzLnN1bGxpdmFuQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpTZWFuLA0KV2Un
dmUgaGFkIHNvbWUgYWRkaXRpb25hbCBkaXNjdXNzaW9ucyBpbiBwZXJzb24gaGVyZSBhdCBJRVRG
IDk5IHdpdGggZm9sa3Mgd2hvIHdlcmUgaW4gdGhlIHByb3h5IGNlcnRpZmljYXRlcyBhbmQgc2hv
cnQtbGl2ZWQgY2VydHMgY2FtcCwgYW5kIHdlIHRoaW5rIHRoZXJlIGlzIG5vdyBtb3JlIGFncmVl
bWVudCB0aGF0IHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQgaXMgc3VwZXJp
b3IgdG8gdGhlIGFsdGVybmF0aXZlcy4gSSd2ZSBpbmNsdWRlZCBhIHN1bW1hcnkgb2Ygc29tZSBv
ZiB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUgYXBwcm9hY2hlczoNClByb3h5IGNlcnRpZmljYXRl
cyB2cy4gRGVsZWdhdGVkIENyZWRlbnRpYWxzDQpQcm8gcHJveHkgY2VydGlmaWNhdGVzOg0KLSBB
bHJlYWR5IGRlcGxveWVkIGluIHNvbWUgaW5kdXN0cmllcywgdGhvdWdoIG5vdCBvbiB0aGUgV2Vi
Lg0KLSBGaXRzIHRoZSBjb25jZXB0dWFsIG1vZGVsIHRoYXQgcHVibGljIGtleSA9PSBjZXJ0aWZp
Y2F0ZS4NCkNvbiBwcm94eSBjZXJ0aWZpY2F0ZXM6DQotIFByb3h5IGNlcnRpZmljYXRlcyBhZGRz
IGFkZGl0aW9uYWwgY29tcGxleGl0eSB0byB0aGUgZGVsZWdhdGlvbiBvdGhlciB0aGFuIGxpbWl0
aW5nIHRoZSB0aW1lIHBlcmlvZCAoZnVsbCBYLjUwOSwgYWRkaXRpb25hbCBjb25zdHJhaW50cyAg
c3VjaCBhcyBob3N0bmFtZSkuDQotIEVuY291cmFnZXMgaW1wbGVtZW50ZXJzIHRvIHJldXNlIFBL
SVggbGlicmFyaWVzIHJhdGhlciB0aGFuIGJ1aWxkIGNvZGUgYXMgcGFydCBvZiBUTFM6DQotLSBU
aGVyZSBoYXZlIGJlZW4gcHJvYmxlbXMgYW5kIGluY29uc2lzdGVuY2llcyBhcm91bmQgcGF0aGxl
biBhbmQgY29uc3RyYWludHMgZW5mb3JjZW1lbnQgaW4gZXhpc3RpbmcgUEtJWCBsaWJyYXJpZXMu
DQotLSBNb2RpZnlpbmcgdGhlc2UgbGlicmFyaWVzIGlzIG1vcmUgY29tcGxleCBhbmQgcmlzayBw
cm9uZSB0aGFuIGRlbGVnYXRlZCBjcmVkcyAod2hpY2ggY2FuIGVhc2lseSBiZSBpbXBsZW1lbnRl
ZCBpbiBUTFMgYXMgZGVtb25zdHJhdGVkIGJ5IHRoZSAzIGludGVyb3BlcmFibGUgaW1wbGVtZW50
YXRpb25zIGF0IHRoZSBJRVRGIDk4IGhhY2thdGhvbikuDQotIEluIHByb3h5IGNlcnRpZmljYXRl
cywgcGF0aGluZyBpcyBTS0kgZGVwZW5kZW50LCBub3QgZGlyZWN0bHkgdGllZCB0byBFRSBjZXJ0
LiBUaGlzIGlzIGEgYmluZGluZyB3ZWFrZXIgdGhhbiBkZWxlZ2F0ZWQgY3JlZGVudGlhbHMgd2hp
Y2ggaW5jbHVkZXMgYSBzaWduYXR1cmUgb3ZlciB0aGUgRUUgY2VydGlmaWNhdGUuDQoNClNob3J0
LWxpdmVkIGNlcnRzIHZzLiBEZWxlZ2F0ZWQgQ3JlZGVudGlhbHMNClBybyBzaG9ydC1saXZlZCBj
ZXJ0czoNCi0gU2hvcnQgbGl2ZWQgY2VydHMgd29yayB3aXRoIGV4aXN0aW5nIGxpYnJhcmllcywg
bm8gbmV3IGNvZGUgY2hhbmdlcy4NCkNvbiBzaG9ydC1saXZlZCBjZXJ0czoNCi0gTm90IHdpZGVs
eSBhdmFpbGFibGUgZnJvbSBDQXMsIGVzcGVjaWFsbHkgZm9yIEVWLg0KLSBQb3RlbnRpYWxseSBw
cm9ibGVtYXRpYyB0byB0aGUgQ1QgZWNvc3lzdGVtIChhbGwgY2VydGlmaWNhdGVzIG11c3QgYmUg
bG9nZ2VkIGluIENULCB3aGljaCBtYXkgYmxvYXQgdGhlbSkuDQotIEludHJvZHVjZXMgYSBoaWdo
LXJpc2sgb3BlcmF0aW9uYWwgZGVwZW5kZW5jeSBvbiBleHRlcm5hbCBwYXJ0eToNCi0tIFJlcXVp
cmVzIGZyZXF1ZW50IGV4Y2hhbmdlcyB3aXRoIGFuIGV4dGVybmFsIENlcnRpZmljYXRlIEF1dGhv
cml0eSAobXVzdCBwcm92aWRlIHByb29mIG9mIGRvbWFpbiBwb3NzZXNzaW9uIHRvIENBIHZzLiBp
bnRlcm5hbGx5IG1hbmFnZWQgY3JlZGVudGlhbCBtaW50ZXIgZm9yIGRlbGVnYXRlZCBjcmVkZW50
aWFscykuDQotLSBUaGVyZSBpcyBubyBmYWxsYmFjayBpZiB0aGUgQ0EgaGFzIG91dGFnZS4gV2l0
aCBkZWxlZ2F0ZWQgY3JlZGVudGlhbHMgeW91IGNhbiBmYWxsIGJhY2sgdG8gYSBMVVJLLXN0eWxl
IHByb3RvY29sIHdpdGggdGhlIGxvbmctbGl2ZWQgY2VydGlmaWNhdGUga2V5Lg0KDQpHaXZlbiB0
aGVzZSBjb21wYXJpc29ucywgd2UgdGhpbmsgdGhlIHByb3Bvc2VkIGRyYWZ0IGlzIHRoZSBzdXBl
cmlvciBvcHRpb24gYW5kIHdvdWxkIGxpa2UgdG8gY29udGludWUgdGhlIGRpc2N1c3Npb24gYWJv
dXQgYWRvcHRpbmcgaXQuDQoNCk5pY2sNCg0KT24gRnJpLCBNYXkgMTksIDIwMTcgYXQgMTI6NTgg
QU0gU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+IHdy
b3RlOg0KQWxsLA0KDQpEdXJpbmcgdGhlIFdHIGNhbGwgZm9yIGFkb3B0aW9uLCBhIGNvdXBsZSBv
ZiBxdWVzdGlvbnMgd2VyZSByYWlzZWQgYWJvdXQgY29tcGFyaXNvbi9hbmFseXNpcyBvZiBzdWIt
Y2VydHMgdmVyc3VzIHByb3h5IGFuZC9vciBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMuICBUaGVy
ZSBpcyBzb21lIGRpc2N1c3Npb24gY3VycmVudGx5IGluIHRoZSBkcmFmdCwgYnV0IHRoZSBjaGFp
cnMgZmVlbCB0aGF0IHRoZXNlIGlzc3VlcyBuZWVkIGZ1cnRoZXIgZGlzY3Vzc2lvbiAoYW5kIGVs
YWJvcmF0aW9uIGluIHRoZSBkcmFmdCkgcHJpb3IgdG8gV0cgYWRvcHRpb24uICBTbyBsZXTigJlz
IGtlZXAgdGhlIGNvbnZlcnNhdGlvbiBnb2luZy4NCg0KSiZTDQoNCj4gT24gQXByIDEyLCAyMDE3
LCBhdCAxNTozMSwgU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPG1haWx0bzpzZWFuQHNuM3Jk
LmNvbT4+IHdyb3RlOg0KPg0KPiBBbGwsDQo+DQo+IEF0IG91ciBJRVRGIDk4IHNlc3Npb24sIHRo
ZXJlIHdhcyBzdXBwb3J0IGluIHRoZSByb29tIHRvIGFkb3B0IGRyYWZ0LXJlc2NvcmxhLXRscy1z
dWJjZXJ0cyBbMF0uICBXZSBuZWVkIHRvIGNvbmZpcm0gdGhpcyBzdXBwb3J0IG9uIHRoZSBsaXN0
IHNvIHBsZWFzZSBsZXQgdGhlIGxpc3Qga25vdyB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9u
IG9mIHRoZSBkcmFmdCBhbmQgYXJlIHdpbGxpbmcgdG8gcmV2aWV3L2NvbW1lbnQgb24gdGhlIGRy
YWZ0IGJlZm9yZSAyMDE3MDQyOS4gIElmIHlvdSBvYmplY3QgdG8gaXRzIGFkb3B0aW9uLCBwbGVh
c2UgbGV0IHVzIGtub3cgd2h5Lg0KPg0KPiBDbGVhcmx5LCB0aGUgV0cgaXMgZ29pbmcgdG8gbmVl
ZCB0byB3b3JrIHRocm91Z2ggdGhlIHRyYWRlLW9mZnMgYmV0d2VlbiBzaG9ydC1saXZlZCBjZXJ0
aWZpY2F0ZXMgYW5kIHN1Yi1jZXJ0cyBiZWNhdXNlIGJvdGggc2VlbSwgdG8gc29tZSwgdG8gYmUg
YWRkcmVzc2luZyB0aGUgc2FtZSBwcm9ibGVtLg0KPg0KPiBDaGVlcnMsDQo+DQo+IEomUw0KPg0K
PiBbMF0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1yZXNjb3Js
YS10bHMtc3ViY2VydHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg==

--_000_BB0F27F7F5CF4512A5D117E557D5D295nokiacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <385B581D075AB44AA47F9EEA4E54680D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0
IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdC
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBOaWNrLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMiPllvdXIgd3JpdGUtdXAgaXMgc3BvdCBvbiwgdGhhbmtzLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMiPkxldCBtZSBjb21tZW50IG9uIGEgZmV3IHBvaW50czo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igJxIb3cgbXVjaCBE
ZWxlZ2F0ZWQgQ3JlZGVudGlhbHMgY2FuIGJlIHJvdGF0ZWQgYW5kIGRpdmVyc2lmaWVkIGluc2lk
ZSBhbiBvcmdhbml6YXRpb24gaXMgb25seSBsaW1pdGVkIGJ5IHRoZSBvcGVyYXRpb25hbCBhYmls
aXR5IG9mDQogdGhlIG9yZ2FuaXphdGlvbiB0aGF0IGhhcyBjb250cm9sIG9mIHRoZSBFRSBwcml2
YXRlIGtleS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgc2VsZi1zZXJ2aWNlL2FnaWxl
IG5hdHVyZSBvZiBELUMgaXMgZ3JlYXQuIFdpdGggdGhhdCwgdGhvdWdoLCBjb21lcyBhIGNvc3Qg
b2Ygb3duZXJzaGlwIHRoYXQgbWF5YmUgbm90IGFsbCBwbGF5ZXJzIGNhbiBhZmZvcmQuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LSBJbnRyb2R1Y2Vz
IGEgaGlnaC1yaXNrIG9wZXJhdGlvbmFsIGRlcGVuZGVuY3kgb24gZXh0ZXJuYWwgcGFydHk6PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs
aWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LS0gUmVxdWlyZXMgZnJlcXVlbnQgZXhj
aGFuZ2VzIHdpdGggYW4gZXh0ZXJuYWwgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IChtdXN0IHByb3Zp
ZGUgcHJvb2Ygb2YgZG9tYWluIHBvc3Nlc3Npb24gdG8gQ0EgdnMuIGludGVybmFsbHkNCiBtYW5h
Z2VkIGNyZWRlbnRpYWwgbWludGVyIGZvciBkZWxlZ2F0ZWQgY3JlZGVudGlhbHMpLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz
Ni4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZXJlIHNob3VsZCBi
ZSB3YXlzIHRvIG1pdGlnYXRlIHRoaXMsIHNheSBhbGxvd2luZyB0aGUgbmV4dCBTLVQgaW4gbGlu
ZSB0byBiZSBhdmFpbGFibGUg4oCcbG9uZyBlbm91Z2jigJ0gYmVmb3JlIGl0IGJlY29tZXMgYWN0
aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0t
IFRoZXJlIGlzIG5vIGZhbGxiYWNrIGlmIHRoZSBDQSBoYXMgb3V0YWdlLiBXaXRoIGRlbGVnYXRl
ZCBjcmVkZW50aWFscyB5b3UgY2FuIGZhbGwgYmFjayB0byBhIExVUkstc3R5bGUgcHJvdG9jb2wg
d2l0aCB0aGUgbG9uZy1saXZlZA0KIGNlcnRpZmljYXRlIGtleS48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHVuZGVyc3RhbmQgdGhlIGxvZ2ljcyBi
dXQsIHNpbmNlIExVUksgYm94ZXMgZG9u4oCZdCBzY2FsZSwgdGhlIGNvc3QgdG8gY292ZXIgeW91
ciBlbnRpcmUgZm9vdHByaW50IGZvciB0aGUgc3BvcmFkaWMgY2FzZXMgd2hlbiB0aGUgQ0EgaXMg
ZG93biBtaWdodCBiZSBhIGJpdCBwcm9oaWJpdGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5D
aGVlcnMsIHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm
dDozNi4wcHQiPk9uIDE4LzA3LzIwMTcsIDE0OjM1LCAmcXVvdDtOaWNrIFN1bGxpdmFuJnF1b3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86bmljaG9sYXMuc3VsbGl2YW5AZ21haWwuY29tIj5uaWNob2xh
cy5zdWxsaXZhbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21h
cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N
ClRob21hcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t
OjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBM
ZXQgbWUgc2VlIGlmIEkgY2FuIHN1bW1hcml6ZSB0aGVtOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+
LSBBIGRpc2FkdmFudGFnZSBvZiBkZWxlZ2F0ZWQgY3JlZGVudGlhbHMgdnMgc2hvcnQtbGl2ZWQg
Y2VydHMgaXMgdGhhdCBpdCByZXF1aXJlcyBjbGllbnQgb3B0LWluLiBUaGlzIGlzIGFsc28gYSBk
aXNhZHZhbnRhZ2Ugb2YgcHJveHkgY2VydGlmaWNhdGVzLiBJZiBjbGllbnQgc3VwcG9ydCBpcyBi
ZWxvdyAxMDAlLCBhIExVUkstdHlwZSBzeXN0ZW0gbWF5IGJlIHJlcXVpcmVkDQogdG8ga2VlcCBs
b25nLXRlcm0gcHJpdmF0ZSBrZXlzIG9mZiBUTFMgdGVybWluYXRpb24gZW5kcG9pbnRzLjxicj4N
Ci0gQSBkaXNhZHZhbnRhZ2Ugb2YgZGVsZWdhdGVkIGNyZWRlbnRpYWxzIGlzIHRoYXQgaXQgcmVx
dWlyZXMgc29mdHdhcmUgdXBkYXRlcyBvbiBib3RoIGNsaWVudCBhbmQgc2VydmVyLiBUaGlzIGlz
IGFsc28gYSBkaXNhZHZhbnRhZ2Ugb2YgcHJveHkgY2VydGlmaWNhdGVzLiBJIHRoaW5rIHRoaXMg
aXMgY292ZXJlZCBieSBteSBwb2ludCBiZWxvdzogJnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPlNob3J0DQogbGl2
ZWQgY2VydHMgd29yayB3aXRoIGV4aXN0aW5nIGxpYnJhcmllcywgbm8gbmV3IGNvZGUgY2hhbmdl
cy4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNt
O21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBB
biBhZHZhbnRhZ2Ugb2Ygc2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVzIGlzIHRoYXQgdGhlcmUgaXMg
YW4gYXVkaXQgbG9nIGJ5IGEgdGhpcmQgcGFydHkgKGVpdGhlciB0aGUgQ0EncyBpbnRlcm5hbCBs
b2dzIGFuZCBvcHRpb25hbGx5IENlcnRpZmljYXRlIFRyYW5zcGFyZW5jeSBsb2dzKS48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+SSBzaG91bGQgc3RhdGUgdGhhdCBzaG9y
dC1saXZlZCBjZXJ0aWZpY2F0ZXMgYXJlIHBvc3NpYmxlIHJpZ2h0IG5vdyBhbmQgaXQncyBzdXBw
b3J0ZWQgYnkgc29tZSBDQXMsIHRob3VnaCBub3QgbmVjZXNzYXJpbHkgYXQgdGhlIHNjYWxlIG5l
ZWRlZA0KIHRvIHByb3ZpZGUsIHNheSwgYSB1bmlxdWUgNy1kYXkgY2VydGlmaWNhdGUgZm9yIGVh
Y2ggc2VydmVyIG9mIGEgbGFyZ2UgSW50ZXJuZXQgY29tcGFueS4gVGhpcyBkcmFmdCdzIGFkdmFu
dGFnZXMgYXBwbHkgbW9zdCBzdHJvbmdseSB0byBvcmdhbml6YXRpb25zIHdobyBkb24ndCB3YW50
IHRvIHRpZSB0aGVpciBhYmlsaXR5IHRvIGhhdmUgZnVuY3Rpb25hbCBUTFMgb24gdGhlIGFiaWxp
dHkgZm9yIENBcyB0byBtYWludGFpbiBoaWdoLWF2YWlsYWJpbGl0eQ0KIGlzc3VhbmNlIHNlcnZp
Y2VzLiZuYnNwOyBIb3cgbXVjaCBEZWxlZ2F0ZWQgQ3JlZGVudGlhbHMgY2FuIGJlIHJvdGF0ZWQg
YW5kIGRpdmVyc2lmaWVkIGluc2lkZSBhbiBvcmdhbml6YXRpb24gaXMgb25seSBsaW1pdGVkIGJ5
IHRoZSBvcGVyYXRpb25hbCBhYmlsaXR5IG9mIHRoZSBvcmdhbml6YXRpb24gdGhhdCBoYXMgY29u
dHJvbCBvZiB0aGUgRUUgcHJpdmF0ZSBrZXkuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TmljazxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFR1ZSwgSnVsIDE4LCAyMDE3IGF0IDE6NDAg
UE0gRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSwgVUspICZsdDs8YSBocmVm
PSJtYWlsdG86dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tIj50aG9tYXMuZm9zc2F0aUBub2tpYS5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSBOaWNr
LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm
dDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs
aWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpIj5JIGFtIG5vdCBhZ2FpbnN0IGRlbGVnYXRlZCBjcmVkZW50aWFscywg
aW4gZmFjdCBJIHRoaW5rIGl04oCZcyBhIGdvb2QgdGhpbmcgcGVyIHNlLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2
LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp
Ij5JIGhhZCBleHByZXNzZWQgYSBjb3VwbGUgb2YgY29uY2VybnMgYXQgdGhlIHRpbWUgdGhlIGNh
bGwgZm9yIGFkb3B0aW9uIHdhcyBmaXJzdCBpc3N1ZWQgWzFdLCB3aGljaCBJIHRoaW5rIGFyZSBz
dGlsbCB2YWxpZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Q291bGQgeW91IHBsZWFzZSBjb21tZW50IG9uIC8g
YWRkIHRoZW0gdG8geW91ciBwcm8tY29ucyBhbmFseXNpcz88L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Q2hlZXJz
LCB0aGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h
cmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTpDYWxpYnJpIj50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlsxXSA8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzIyOTY2Lmh0bWwiIHRhcmdl
dD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdGxzL2N1
cnJlbnQvbXNnMjI5NjYuaHRtbDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu
MHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpPbiAxOC8wNy8yMDE3LCAxMjowNiwgJnF1
b3Q7VExTIG9uIGJlaGFsZiBvZiBOaWNrIFN1bGxpdmFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls
dG86dGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHMtYm91bmNlc0BpZXRm
Lm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86bmljaG9sYXMuc3VsbGl2YW5A
Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bmljaG9sYXMuc3VsbGl2YW5AZ21haWwuY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Ojcy
LjBwdCI+DQpTZWFuLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu
MHB0O21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpXZSd2ZSBoYWQgc29tZSBhZGRpdGlvbmFsIGRpc2N1
c3Npb25zIGluIHBlcnNvbiBoZXJlIGF0IElFVEYgOTkgd2l0aCBmb2xrcyB3aG8gd2VyZSBpbiB0
aGUgcHJveHkgY2VydGlmaWNhdGVzIGFuZCBzaG9ydC1saXZlZCBjZXJ0cyBjYW1wLCBhbmQgd2Ug
dGhpbmsgdGhlcmUgaXMgbm93IG1vcmUgYWdyZWVtZW50IHRoYXQgdGhlIG1lY2hhbmlzbSBkZXNj
cmliZWQgaW4gdGhpcyBkcmFmdCBpcyBzdXBlcmlvciB0byB0aGUgYWx0ZXJuYXRpdmVzLiBJJ3Zl
DQogaW5jbHVkZWQgYSBzdW1tYXJ5IG9mIHNvbWUgb2YgdGhlIHByb3MgYW5kIGNvbnMgb2YgdGhl
IGFwcHJvYWNoZXM6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
O21hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojMjEyMTIxIj5Qcm94
eSBjZXJ0aWZpY2F0ZXMgdnMuIERlbGVnYXRlZCBDcmVkZW50aWFsczwvc3Bhbj48L2I+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl
ZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPGk+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPlBybyBwcm94eSBj
ZXJ0aWZpY2F0ZXM8L3NwYW4+PC91PjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+Ojwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4w
cHQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBBbHJlYWR5IGRlcGxveWVkIGluIHNv
bWUgaW5kdXN0cmllcywgdGhvdWdoIG5vdCBvbiB0aGUgV2ViLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4w
cHQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBGaXRzIHRoZSBjb25jZXB0dWFsIG1v
ZGVsIHRoYXQgcHVibGljIGtleSA9PSBjZXJ0aWZpY2F0ZS48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0
O2JhY2tncm91bmQ6d2hpdGUiPg0KPGk+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPkNvbiBwcm94eSBjZXJ0aWZpY2F0
ZXM8L3NwYW4+PC91PjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dy
b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBQcm94eSBjZXJ0aWZpY2F0ZXMgYWRkcyBhZGRpdGlv
bmFsIGNvbXBsZXhpdHkgdG8gdGhlIGRlbGVnYXRpb24gb3RoZXIgdGhhbiBsaW1pdGluZyB0aGUg
dGltZSBwZXJpb2QgKGZ1bGwgWC41MDksIGFkZGl0aW9uYWwgY29uc3RyYWludHMmbmJzcDsgc3Vj
aCBhcyBob3N0bmFtZSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xv
cjojMjEyMTIxIj4tIEVuY291cmFnZXMgaW1wbGVtZW50ZXJzIHRvIHJldXNlIFBLSVggbGlicmFy
aWVzIHJhdGhlciB0aGFuIGJ1aWxkIGNvZGUgYXMgcGFydCBvZiBUTFM6PGJyPg0KLS0gVGhlcmUg
aGF2ZSBiZWVuIHByb2JsZW1zIGFuZCBpbmNvbnNpc3RlbmNpZXMgYXJvdW5kIHBhdGhsZW4gYW5k
IGNvbnN0cmFpbnRzIGVuZm9yY2VtZW50IGluIGV4aXN0aW5nIFBLSVggbGlicmFyaWVzLjxicj4N
Ci0tIE1vZGlmeWluZyB0aGVzZSBsaWJyYXJpZXMgaXMgbW9yZSBjb21wbGV4IGFuZCByaXNrIHBy
b25lIHRoYW4gZGVsZWdhdGVkIGNyZWRzICh3aGljaCBjYW4gZWFzaWx5IGJlIGltcGxlbWVudGVk
IGluIFRMUyBhcyBkZW1vbnN0cmF0ZWQgYnkgdGhlIDMgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRh
dGlvbnMgYXQgdGhlIElFVEYgOTggaGFja2F0aG9uKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0O2Jh
Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPi0gSW4gcHJveHkgY2VydGlmaWNhdGVzLCBwYXRo
aW5nIGlzIFNLSSBkZXBlbmRlbnQsIG5vdCBkaXJlY3RseSB0aWVkIHRvIEVFIGNlcnQuIFRoaXMg
aXMgYSBiaW5kaW5nIHdlYWtlciB0aGFuIGRlbGVnYXRlZCBjcmVkZW50aWFscyB3aGljaCBpbmNs
dWRlcyBhIHNpZ25hdHVyZSBvdmVyIHRoZSBFRSBjZXJ0aWZpY2F0ZS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6
NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm
dDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+U2hvcnQtbGl2ZWQgY2Vy
dHMgdnMuIERlbGVnYXRlZCBDcmVkZW50aWFsczwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0O2Jh
Y2tncm91bmQ6d2hpdGUiPg0KPGk+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEiPlBybyBzaG9ydC1saXZlZCBjZXJ0czwv
c3Bhbj48L3U+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okhl
bHZldGljYTtjb2xvcjojMjEyMTIxIj46PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5k
OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl
dGljYTtjb2xvcjojMjEyMTIxIj4tIFNob3J0IGxpdmVkIGNlcnRzIHdvcmsgd2l0aCBleGlzdGlu
ZyBsaWJyYXJpZXMsIG5vIG5ldyBjb2RlIGNoYW5nZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdDti
YWNrZ3JvdW5kOndoaXRlIj4NCjxpPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojMjEyMTIxIj5Db24gc2hvcnQtbGl2ZWQgY2VydHM8
L3NwYW4+PC91PjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2E7Y29sb3I6IzIxMjEyMSI+Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3Vu
ZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2
ZXRpY2E7Y29sb3I6IzIxMjEyMSI+LSBOb3Qgd2lkZWx5IGF2YWlsYWJsZSBmcm9tIENBcywgZXNw
ZWNpYWxseSBmb3IgRVYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xv
cjojMjEyMTIxIj4tIFBvdGVudGlhbGx5IHByb2JsZW1hdGljIHRvIHRoZSBDVCBlY29zeXN0ZW0g
KGFsbCBjZXJ0aWZpY2F0ZXMgbXVzdCBiZSBsb2dnZWQgaW4gQ1QsIHdoaWNoIG1heSBibG9hdCB0
aGVtKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiMyMTIxMjEi
Pi0gSW50cm9kdWNlcyBhIGhpZ2gtcmlzayBvcGVyYXRpb25hbCBkZXBlbmRlbmN5IG9uIGV4dGVy
bmFsIHBhcnR5Ojxicj4NCi0tIFJlcXVpcmVzIGZyZXF1ZW50IGV4Y2hhbmdlcyB3aXRoIGFuIGV4
dGVybmFsIENlcnRpZmljYXRlIEF1dGhvcml0eSAobXVzdCBwcm92aWRlIHByb29mIG9mIGRvbWFp
biBwb3NzZXNzaW9uIHRvIENBIHZzLiBpbnRlcm5hbGx5IG1hbmFnZWQgY3JlZGVudGlhbCBtaW50
ZXIgZm9yIGRlbGVnYXRlZCBjcmVkZW50aWFscykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdDtiYWNr
Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYTtjb2xvcjojMjEyMTIxIj4tLSBUaGVyZSBpcyBubyBmYWxsYmFjayBpZiB0aGUg
Q0EgaGFzIG91dGFnZS4gV2l0aCBkZWxlZ2F0ZWQgY3JlZGVudGlhbHMgeW91IGNhbiBmYWxsIGJh
Y2sgdG8gYSBMVVJLLXN0eWxlIHByb3RvY29sIHdpdGggdGhlIGxvbmctbGl2ZWQgY2VydGlmaWNh
dGUga2V5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3
Mi4wcHQiPg0KR2l2ZW4gdGhlc2UgY29tcGFyaXNvbnMsIHdlIHRoaW5rIHRoZSBwcm9wb3NlZCBk
cmFmdCBpcyB0aGUgc3VwZXJpb3Igb3B0aW9uIGFuZCB3b3VsZCBsaWtlIHRvIGNvbnRpbnVlIHRo
ZSBkaXNjdXNzaW9uIGFib3V0IGFkb3B0aW5nIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0
OjcyLjBwdCI+DQpOaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KT24gRnJp
LCBNYXkgMTksIDIwMTcgYXQgMTI6NTggQU0gU2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0
bzpzZWFuQHNuM3JkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNlYW5Ac24zcmQuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g
Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0
OjcyLjBwdCI+DQpBbGwsPGJyPg0KPGJyPg0KRHVyaW5nIHRoZSBXRyBjYWxsIGZvciBhZG9wdGlv
biwgYSBjb3VwbGUgb2YgcXVlc3Rpb25zIHdlcmUgcmFpc2VkIGFib3V0IGNvbXBhcmlzb24vYW5h
bHlzaXMgb2Ygc3ViLWNlcnRzIHZlcnN1cyBwcm94eSBhbmQvb3Igc2hvcnQtbGl2ZWQgY2VydGlm
aWNhdGVzLiZuYnNwOyBUaGVyZSBpcyBzb21lIGRpc2N1c3Npb24gY3VycmVudGx5IGluIHRoZSBk
cmFmdCwgYnV0IHRoZSBjaGFpcnMgZmVlbCB0aGF0IHRoZXNlIGlzc3VlcyBuZWVkIGZ1cnRoZXIg
ZGlzY3Vzc2lvbg0KIChhbmQgZWxhYm9yYXRpb24gaW4gdGhlIGRyYWZ0KSBwcmlvciB0byBXRyBh
ZG9wdGlvbi4mbmJzcDsgU28gbGV04oCZcyBrZWVwIHRoZSBjb252ZXJzYXRpb24gZ29pbmcuPGJy
Pg0KPGJyPg0KSiZhbXA7Uzxicj4NCjxicj4NCiZndDsgT24gQXByIDEyLCAyMDE3LCBhdCAxNToz
MSwgU2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzZWFuQHNuM3JkLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPnNlYW5Ac24zcmQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZn
dDsgQWxsLDxicj4NCiZndDs8YnI+DQomZ3Q7IEF0IG91ciBJRVRGIDk4IHNlc3Npb24sIHRoZXJl
IHdhcyBzdXBwb3J0IGluIHRoZSByb29tIHRvIGFkb3B0IGRyYWZ0LXJlc2NvcmxhLXRscy1zdWJj
ZXJ0cyBbMF0uJm5ic3A7IFdlIG5lZWQgdG8gY29uZmlybSB0aGlzIHN1cHBvcnQgb24gdGhlIGxp
c3Qgc28gcGxlYXNlIGxldCB0aGUgbGlzdCBrbm93IHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRp
b24gb2YgdGhlIGRyYWZ0IGFuZCBhcmUgd2lsbGluZyB0byByZXZpZXcvY29tbWVudCBvbiB0aGUg
ZHJhZnQNCiBiZWZvcmUgMjAxNzA0MjkuJm5ic3A7IElmIHlvdSBvYmplY3QgdG8gaXRzIGFkb3B0
aW9uLCBwbGVhc2UgbGV0IHVzIGtub3cgd2h5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IENsZWFybHks
IHRoZSBXRyBpcyBnb2luZyB0byBuZWVkIHRvIHdvcmsgdGhyb3VnaCB0aGUgdHJhZGUtb2ZmcyBi
ZXR3ZWVuIHNob3J0LWxpdmVkIGNlcnRpZmljYXRlcyBhbmQgc3ViLWNlcnRzIGJlY2F1c2UgYm90
aCBzZWVtLCB0byBzb21lLCB0byBiZSBhZGRyZXNzaW5nIHRoZSBzYW1lIHByb2JsZW0uPGJyPg0K
Jmd0Ozxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZndDs8YnI+DQomZ3Q7IEomYW1wO1M8YnI+DQom
Z3Q7PGJyPg0KJmd0OyBbMF0gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvaHRtbC9kcmFmdC1yZXNjb3JsYS10bHMtc3ViY2VydHMiIHRhcmdldD0iX2JsYW5rIj4NCmh0
dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLXN1
YmNlcnRzPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpU
TFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2Js
YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
Ym9keT4NCjwvaHRtbD4NCg==

--_000_BB0F27F7F5CF4512A5D117E557D5D295nokiacom_--


From nobody Tue Jul 18 09:34:27 2017
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 8560912EC12 for ; Tue, 18 Jul 2017 09:34:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 th-uApPYIWmE for ; Tue, 18 Jul 2017 09:34:19 -0700 (PDT)
Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F4C131474 for ; Tue, 18 Jul 2017 09:34:19 -0700 (PDT)
Received: by mail-pf0-x243.google.com with SMTP id q85so3285395pfq.2 for ; Tue, 18 Jul 2017 09:34:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C4I82VrXHvvYr9GHs0mOO5ycOymBcD90K/Fy04S6+Qg=; b=VdwHnfNxJl4dkE9UjGClE91aSNLEwWgtVA7GO9XDDmAV02nhE4WkjhGxZBgLPyC8Ii KBZPgBG/hK0UNXYC6frFXY6C6MVP3fZlTItGlL3mCbNnNSJ1R3awh5wHCm91oAA9fwM+ bdID8paxhVcJYTFvcmMbEcffsZplvgo2Qi9PdSzjkpvD+PDyVFiE/zM5u12D4stCPuU9 CxCUDg+NTF4o0ghU+MVn6VXkSuRTm7fr9N4nEqxhp3YFQzPodDjcf/MqHtci/k17JnSD WizsLvHVfzHLfvtq365q6909qYTBB9hcZiGGsoaQlU8OyVYWI7bKGltySHNKkcwQCygh TO5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C4I82VrXHvvYr9GHs0mOO5ycOymBcD90K/Fy04S6+Qg=; b=LH9VNAVYNDWLgCdNke0O7oLc0BlyeCgL4BFEug1p2DjAUr+ZXy6iO2IK6o1EMf8f8D 5wIipCxwv+924vKV1DagBOXv1hnO8SuOspCRx24ErTHrxGRSSRlFboBzojjLySUMTO1A RM9E+QGigRKJjnUZoia1qNhA22F7JDHgUIOL6GF7Rz3ItgqWcVnMfRqqFkxDLULdb/Sc bZG1ONsUiv6QHmiov8AxtufQ2Ozjfb3IUb61g+Fmdht2h5uQnTUuEiinYjhD1Ov4G3Jb vdK1ebepvCz3xgyGCki3kqAIx86nh9ulGk5YrQq5d8Tk+KcEgWOQ+iK1aKLwnZkXpEp5 9vUw==
X-Gm-Message-State: AIVw111qbznX/4mg/fIRlpjbYFRmIEnUFo4p+fA+pg14hf0qHIrxWlD6 DcGHmcXm6pJ/4Q==
X-Received: by 10.99.153.26 with SMTP id d26mr2471384pge.241.1500395658521; Tue, 18 Jul 2017 09:34:18 -0700 (PDT)
Received: from [192.168.1.3] (c-76-103-103-185.hsd1.ca.comcast.net. [76.103.103.185]) by smtp.gmail.com with ESMTPSA id v17sm8409203pgn.4.2017.07.18.09.34.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 09:34:18 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dan Wing 
In-Reply-To: 
Date: Tue, 18 Jul 2017 09:34:16 -0700
Cc: "tls@ietf.org" , Sean Turner 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AF62E7E-84AA-4011-8895-3274559DA4E8@gmail.com>
References:   <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com>    <609E20D4-2430-4DE0-BF10-C3F44AA4A350@gmail.com> 
To: yinxinxing 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 16:34:25 -0000

> On Jul 16, 2017, at 8:39 PM, yinxinxing  wrote:
>=20
> Hi Wing,
>=20
> I noticed that Helloverifyrequest is optional by the server and used =
when DOS is to be mitigated.=20
>=20
> But from practical use cases, the IOT server may not have dedicated =
anti-DOS mechanism.=20
>=20
> If there is a more power-saving solution with the function of DOS =
mitigation retained, and don't need to bother the server(customer) to =
deploy anti-DOS devices, why not have a try? =20

Sure.  You might work with the authors of =
draft-mavrogiannopoulos-tls-cid to add more considerations around denial =
of service, perhaps also a longer cid as you suggested earlier.

-d


> Regards,
> Yin Xinxing
>=20
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: yinxinxing=20
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8813=E6=97=A5=
 16:56
> =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Dan Wing'
> =E6=8A=84=E9=80=81: tls@ietf.org; Sean Turner
> =E4=B8=BB=E9=A2=98: =E7=AD=94=E5=A4=8D: [TLS] Solving the NAT expiring =
problem causing DTLS renegotiation with high power consumption in =
DTLS1.2
>=20
> Hi Wing,
>=20
> Please see the comments inline
>=20
> Regards,
> Yin Xinxing
>=20
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dan Wing [mailto:danwing@gmail.com]=20
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8813=E6=97=A5=
 12:35
> =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing
> =E6=8A=84=E9=80=81: tls@ietf.org; Sean Turner
> =E4=B8=BB=E9=A2=98: Re: [TLS] Solving the NAT expiring problem causing =
DTLS renegotiation with high power consumption in DTLS1.2
>=20
>=20
>> On Jul 12, 2017, at 7:11 PM, yinxinxing  =
wrote:
>>=20
>> Thanks Wing,
>>=20
>> Please see my comments inline.
>>=20
>> Regards,
>> Yin Xinxing
>>=20
>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dan Wing [mailto:danwing@gmail.com]=20
>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8813=E6=97=A5=
 8:52
>> =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing
>> =E6=8A=84=E9=80=81: tls@ietf.org; Sean Turner
>> =E4=B8=BB=E9=A2=98: Re: [TLS] Solving the NAT expiring problem =
causing DTLS renegotiation with high power consumption in DTLS1.2
>>=20
>>=20
>>> On Jul 12, 2017, at 5:21 PM, yinxinxing  =
wrote:
>>>=20
>>> Hi Dan Wing,
>>>=20
>>> Thanks for your comments.
>>>=20
>>> Please see my comments inline.
>>>=20
>>> Regards,
>>> Yin Xinxing
>>>=20
>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dan Wing [mailto:danwing@gmail.com]=20
>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8813=E6=97=A5=
 1:09
>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing
>>> =E6=8A=84=E9=80=81: tls@ietf.org; Sean Turner
>>> =E4=B8=BB=E9=A2=98: Re: [TLS] Solving the NAT expiring problem =
causing DTLS renegotiation with high power consumption in DTLS1.2
>>>=20
>>>=20
>>>> On Jul 12, 2017, at 7:56 AM, Sean Turner  wrote:
>>>>=20
>>>>=20
>>>>> On Jul 6, 2017, at 23:04, yinxinxing  =
wrote:
>>>>>=20
>>>>> Hi all,
>>>>>=20
>>>>> The NAT table expiring problem mentioned in the  following email =
should also be considered in DTLS1.2 as an extension.
>>>>>=20
>>>>> The value and necessity are as follows.
>>>>>=20
>>>>> 1. Essentially, NAT expiring problem causing DTLS renegotiation =
with high power consumption is existing in DTLS 1.2. Even if we solve =
this in DTLS1.3, this problem still exist for products using DTLS1.2.
>>>>> Currently, many IOT products using DTLS 1.2 are going to be =
deployed commercially, such as intelligent water/gas meter. These meters =
usually have limited battery and low cost. To be more accurate, the =
battery of the chip module of the intelligent water/gas meter are =
required to last for 10 years. These lead to an exercise strict control =
over the power consumption of the chip module. NAT expiring problem =
causing DTLS renegotiation with high power consumption is a bottleneck =
of these IOT devices. According to our experimental data, under the =
worst coverage level (ECL2), power consumption of the chip module when =
DTLS is embedded increases by nearly 60%. Therefore, there should be a =
solution to solve the urgent problem to match the low-cost and =
low-battery feature of the IOT devices in DTLS 1.2.
>>>>=20
>>>> I have to ask whether these IoT devices are updatable?
>>>>=20
>>>>> 2. DTLS 1.3 will be standardized in 2018, but the corresponding =
open source code will be available about one year later after the =
standardization. At present, large-scale commercial IOT industry =
deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope =
that the above problem could be solved in DTLS 1.2 as soon as possible.
>>>>=20
>>>> On this point, I=E2=80=99m hoping that you=E2=80=99ll be wrong ;). =
=46rom the list of TLS implementations found here:
>>>> https://github.com/tlswg/tls13-spec/wiki/Implementations
>>>> and assuming there is as much enthusiasm to implement DTLS1.3 as =
there was for TLS1.3 then I=E2=80=99m hoping that the DTLS =
implementations will be ready much sooner than a year after publication =
(they might be ready before the RFC is published).
>>>=20
>>>=20
>>>> Yin Xinxing,
>>>=20
>>>> While waiting for cid, perhaps today do session resumption =
(RFC5077), anytime the client has reason to suspect their UDP port or IP =
address might have changed -- such as it's been longer than, say, 30 =
seconds since last UDP transmission.  (The problem isn't solely NAT; =
there are several ISPs that change subscriber's IP address, >also =
forcing re-negotiation of DTLS security association.  Less frequent than =
NATs timing out UDP, of course.)
>>>=20
>>>> -d
>>> [Yin] Yes, you are right. The problem isn't solely NAT expiring, but =
changing from WLAN to 3GPP, or IOT devices waking up from sleep mode. =
All of these could lead to IP change.
>>> Session resumption is a good way to re-negotiate the DTLS session. =
However, according to our IOT products, e.g., intelligent water/gas =
meter, session resumption mechanism still needs to communicate 6 or 5 =
messages(based on the cipher suite TLS_PSK_WITH_AES_128_CBC_SHA256) and =
this re-negotiation mechanism still costs too much battery and can not =
ensure 10-year lifetime of the IOT products' battery.=20
>>=20
>>> I see 3 messages and no cryptographic operations for the client in =
Figure 2 of https://tools.ietf.org/html/rfc5077#page-5.  So I guess =
you're saying the IoT device can't send two packets and receive one =
packet without impacting its battery.  I agree 'cid' is more efficient, =
but it isn't yet standardized.  I would consider doing >RFC5077 and =
then, when 'cid' or DTLS 1.3 is available, update the devices to support =
'cid' or DTLS 1.3, as Sean implied when he asked if the devices could be =
updated.
>>=20
>>> (I hope the devices aren't using the same pre-shared key!  That =
would be bad.)
>>=20
>>> -d
>> [Yin] Figure 2 is TLS resumption. For DTLS, there are "clienthello" =
and "helloverifyrequest"
>=20
>> HelloVerifyRequest is only sent if the DTLS server is defending =
itself from attack.  I would imagine DDoS mitigation companies will, or =
have already, built DTLS defenses that can avoid sending that message in =
many cases, or such logic could be included as part of a quality DTLS =
server implementation? =20
>> If the client devices are so sensitive to sending/receiving packets, =
I wouldn't want the server to challenge them with HelloVerifyRequest, =
but instead be sure there is DoS and DDoS mitigation on the server that =
doesn't push effort back to the clients.  Afterall, the client sent a =
packet that the server could have validated,=20
>> at cryptographic cost to the server.  Creative encoding of that nonce =
could allow the server to reduce its validation effort and reduce its =
likelyhood of challenging with a HelloVerifyRequest.
>=20
>> before the resumption procedure in Figure2. Anyway, the resumption =
mechanism is not efficient for battery-constrained IOT devices.
>> For upgrading problem you and Sean mentioned, please see my reply for =
Sean.=20
>=20
>> Thanks, I did read that reply.  The devices can't be upgraded.
>=20
>> -d
>=20
> [Yin] I don't think so. =46rom the perspective of security, these =
messages are needed. Even the client devices are battery-constrained, =
security is needed in DTLS as required by our customers.=20
>=20
>>=20
>>=20
>>=20
>>>=20
>>>> spt
>>>>=20
>>>>> Any comment is appreciated.
>>>>>=20
>>>>> Regards,
>>>>> Yin Xinxing
>>>>>=20
>>>>>=20
>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: yinxinxing=20
>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8827=E6=97=
=A5 16:28
>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric Rescorla'
>>>>> =E6=8A=84=E9=80=81: tls@ietf.org; Tobias Gondrom
>>>>> =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG
>>>>>=20
>>>>> Thanks Eric,
>>>>>=20
>>>>> I have seen the CID scheme, and talked with Hannes(the author of =
the scheme).
>>>>>=20
>>>>> CID scheme is a good idea to solve the problem I mentioned.
>>>>>=20
>>>>> I think the length of CID (currently, it is 32 bits) can be longer =
so that it can support more DTLS sessions. It is known that for IOT =
scenario, 1 million connection is nothing.
>>>>>=20
>>>>> Regards,
>>>>> Yin Xinxing
>>>>>=20
>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]=20=

>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B46=E6=9C=8825=E6=97=
=A5 21:33
>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: yinxinxing
>>>>> =E6=8A=84=E9=80=81: tls@ietf.org; Xiongxiaochun
>>>>> =E4=B8=BB=E9=A2=98: Re: [TLS] Yin Xinxing joins the TLS WG
>>>>>=20
>>>>> Hi Yin,
>>>>>=20
>>>>> The usual solution to this is to add a connection id. Please see:
>>>>> https://github.com/tlswg/dtls13-spec/issues/6
>>>>>=20
>>>>> -Ekr
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing =
 wrote:
>>>>> Hello everyone,
>>>>>=20
>>>>> I am Yin Xinxing from Huawei company. I am glad to join the TLS =
WG.
>>>>>=20
>>>>> For the DLTS 1.3 draft, I am interested and have some ideas to =
talk with you.
>>>>>=20
>>>>> DTLS has a lot of application scenarios in IOT fields, but =
currently, there is some difficulty when DTLS 1.2 is applied to IOT =
devices, especially the battery-constrained IOT devices.
>>>>>=20
>>>>> For example, when the IOT device wakes up from sleep mode, the NAT =
table may have expired.
>>>>> Then the IOT device has to establish a new DTLS session or at =
least launches a resume process with the server, the corresponding power =
consumption is too high for some power-constrained devices.=20
>>>>> How can DTLS renegotiation be avoided in order to save battery?
>>>>>=20
>>>>> I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider =
this problem and give a proper solution. =20
>>>>>=20
>>>>> Any comment or idea about this problem is welcome.
>>>>>=20
>>>>> Regards,
>>>>> Yin Xinxing
>>>>>=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
>>>>=20
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>=20
>>=20
>=20


From nobody Tue Jul 18 09:34:34 2017
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 C024C131B93; Tue, 18 Jul 2017 09:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 dtj6RNr5RjCv; Tue, 18 Jul 2017 09:34:29 -0700 (PDT)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 B57F9131B92; Tue, 18 Jul 2017 09:34:28 -0700 (PDT)
Received: by mail-pg0-x234.google.com with SMTP id v190so15592522pgv.2; Tue, 18 Jul 2017 09:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YN2Z3p9qjLMabBSt4bR8H5wgmrLDp9dSKm1sgx4z8JQ=; b=ZahaPho2oQELeV46Egwm1zw4mjREsiYyB5EGBWyGJtlVSNC0yVQF99cqkOX+8VZDaE 9jG7cyklN3BJIu/4cEVh8kA4vZ1w5zjBe7l2wA5dSBz6xQAZekmv4sD+Ztb3xqnbzCXj z6j3Gi0oyIzWDC7XYrha+pGkH75whg1zaEk+W6xIiA4ZM7atYSWBm7Kvw3mTDUs0Upyz uYFnuRm9K3ybZNa8FrP2GiqLcUiMppQOX6jkp+PKQKGMdBvejtiHs82NoYAXKk4lQ1xA dllnzOICr48lM9ev3AZXsK2sPA/MGYahgVlFbPTXQFQySnk9duMVhWwMtjsSb69iN1aJ 6kiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YN2Z3p9qjLMabBSt4bR8H5wgmrLDp9dSKm1sgx4z8JQ=; b=CR86bV5BaPdp1nipb886wSItrf4RA8pGvRuL2j1tJl9Ksuvm25M3tdqrwNGoVoj6AN P/bL8ZVeN9DZNhvPNpMYk5LJrplOiXemM4jpZlZc4NmpUCnOs9iky3CSo3EFpgpLCt+a UET6ES3+DA3mhZD1SkYYoooAHy1gIEmfyv8EQPHcftbjIwio6sKhlDsBRLYdyUE1SRYO CDVLmW3f+goHh1d4Jm4efvTmKwxZCJrXGPo00cQQWQ8GK3p8MRTnBpTMs6zGgAFVbeLG 6cKeSJS78S31VzFQqZIVEiO37giZLcqZoi6GihPHaNWzyoFUouS2ebd7VbGInFEoORo9 VUAw==
X-Gm-Message-State: AIVw111D1YnmlQwTozeC3RVEy6q7xa/Jb5oo+bGqcOYLigUBT3ZSp9N2 p6iEFSaUtdLXjOnn4UI7SoBTVl1fpYsS
X-Received: by 10.98.7.87 with SMTP id b84mr2564504pfd.216.1500395668310; Tue, 18 Jul 2017 09:34:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Tue, 18 Jul 2017 09:34:27 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Tue, 18 Jul 2017 09:34:27 -0700 (PDT)
In-Reply-To: 
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>  <61435CE8-3A17-4773-8329-54908985FB80@nokia.com>  
From: Watson Ladd 
Date: Tue, 18 Jul 2017 09:34:27 -0700
Message-ID: 
To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" 
Cc: LURK BoF , tls@ietf.org, Sean Turner ,  Nick Sullivan 
Content-Type: multipart/alternative; boundary="001a1143ccc4d5107c05549a1653"
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 16:34:32 -0000

--001a1143ccc4d5107c05549a1653
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Jul 18, 2017 9:26 AM, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <
thomas.fossati@nokia.com> wrote:

Hi Nick,



Your write-up is spot on, thanks.



Let me comment on a few points:



=E2=80=9CHow much Delegated Credentials can be rotated and diversified insi=
de an
organization is only limited by the operational ability of the organization
that has control of the EE private key.=E2=80=9D



The self-service/agile nature of D-C is great. With that, though, comes a
cost of ownership that maybe not all players can afford.


Outsourcing to get to something like short lived certs is possible here. If
you can put a cert on a webserver I'm sure you can put it on a delegated
credential creator and point your server at it.



- Introduces a high-risk operational dependency on external party:

-- Requires frequent exchanges with an external Certificate Authority (must
provide proof of domain possession to CA vs. internally managed credential
minter for delegated credentials).



There should be ways to mitigate this, say allowing the next S-T in line to
be available =E2=80=9Clong enough=E2=80=9D before it becomes active.



-- There is no fallback if the CA has outage. With delegated credentials
you can fall back to a LURK-style protocol with the long-lived certificate
key.



I understand the logics but, since LURK boxes don=E2=80=99t scale, the cost=
 to
cover your entire footprint for the sporadic cases when the CA is down
might be a bit prohibitive.


CA reliability is not good.



Cheers, t





On 18/07/2017, 14:35, "Nick Sullivan"  wrote:



Thomas,

Thanks for your comments. Let me see if I can summarize them:

- A disadvantage of delegated credentials vs short-lived certs is that it
requires client opt-in. This is also a disadvantage of proxy certificates.
If client support is below 100%, a LURK-type system may be required to keep
long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software
updates on both client and server. This is also a disadvantage of proxy
certificates. I think this is covered by my point below: "Short lived certs
work with existing libraries, no new code changes."

- An advantage of short-lived certificates is that there is an audit log by
a third party (either the CA's internal logs and optionally Certificate
Transparency logs).

I should state that short-lived certificates are possible right now and
it's supported by some CAs, though not necessarily at the scale needed to
provide, say, a unique 7-day certificate for each server of a large
Internet company. This draft's advantages apply most strongly to
organizations who don't want to tie their ability to have functional TLS on
the ability for CAs to maintain high-availability issuance services.  How
much Delegated Credentials can be rotated and diversified inside an
organization is only limited by the operational ability of the organization
that has control of the EE private key.



Nick



On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) =
<
thomas.fossati@nokia.com> wrote:

Hi Nick,



I am not against delegated credentials, in fact I think it=E2=80=99s a good=
 thing
per se.



I had expressed a couple of concerns at the time the call for adoption was
first issued [1], which I think are still valid.



Could you please comment on / add them to your pro-cons analysis?



Cheers, thanks,

t



[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html



On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan"  wrote:



Sean,

We've had some additional discussions in person here at IETF 99 with folks
who were in the proxy certificates and short-lived certs camp, and we think
there is now more agreement that the mechanism described in this draft is
superior to the alternatives. I've included a summary of some of the pros
and cons of the approaches:

*Proxy certificates vs. Delegated Credentials*

*Pro proxy certificates*:

- Already deployed in some industries, though not on the Web.

- Fits the conceptual model that public key =3D=3D certificate.

*Con proxy certificates*:

- Proxy certificates adds additional complexity to the delegation other
than limiting the time period (full X.509, additional constraints  such as
hostname).

- Encourages implementers to reuse PKIX libraries rather than build code as
part of TLS:
-- There have been problems and inconsistencies around pathlen and
constraints enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated
creds (which can easily be implemented in TLS as demonstrated by the 3
interoperable implementations at the IETF 98 hackathon).

- In proxy certificates, pathing is SKI dependent, not directly tied to EE
cert. This is a binding weaker than delegated credentials which includes a
signature over the EE certificate.



*Short-lived certs vs. Delegated Credentials*

*Pro short-lived certs*:

- Short lived certs work with existing libraries, no new code changes.

*Con short-lived certs*:

- Not widely available from CAs, especially for EV.

- Potentially problematic to the CT ecosystem (all certificates must be
logged in CT, which may bloat them).

- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must
provide proof of domain possession to CA vs. internally managed credential
minter for delegated credentials).

-- There is no fallback if the CA has outage. With delegated credentials
you can fall back to a LURK-style protocol with the long-lived certificate
key.



Given these comparisons, we think the proposed draft is the superior option
and would like to continue the discussion about adopting it.



Nick



On Fri, May 19, 2017 at 12:58 AM Sean Turner  wrote:

All,

During the WG call for adoption, a couple of questions were raised about
comparison/analysis of sub-certs versus proxy and/or short-lived
certificates.  There is some discussion currently in the draft, but the
chairs feel that these issues need further discussion (and elaboration in
the draft) prior to WG adoption.  So let=E2=80=99s keep the conversation go=
ing.

J&S

> On Apr 12, 2017, at 15:31, Sean Turner  wrote:
>
> All,
>
> At our IETF 98 session, there was support in the room to adopt
draft-rescorla-tls-subcerts [0].  We need to confirm this support on the
list so please let the list know whether you support adoption of the draft
and are willing to review/comment on the draft before 20170429.  If you
object to its adoption, please let us know why.
>
> Clearly, the WG is going to need to work through the trade-offs between
short-lived certificates and sub-certs because both seem, to some, to be
addressing the same problem.
>
> Cheers,
>
> J&S
>
> [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts

_______________________________________________
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

--001a1143ccc4d5107c05549a1653
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thomas,

Thanks for your comments. L=
et me see if I can summarize them:

- A disadvantage of de=
legated credentials vs short-lived certs is that it requires client opt-in.=
 This is also a disadvantage of proxy certificates. If client support is be=
low 100%, a LURK-type system may be required to keep long-term private keys=
 off TLS termination endpoints.
- A disadvantage of delegated credential=
s is that it requires software updates on both client and server. This is a=
lso a disadvantage of proxy certificates. I think this is covered by my poi=
nt below: "Short lived certs work with existing libraries, no new code c=
hanges."
- An advantage of short-lived certificates=
 is that there is an audit log by a third party (either the CA's intern=
al logs and optionally Certificate Transparency logs).

=

I should state that short-lived certificates are possible right now and =
it's supported by some CAs, though not necessarily at the scale needed =
to provide, say, a unique 7-day certificate for each server of a large Inte=
rnet company. This
 draft's advantages apply most strongly to organizations who don't =
want=20
to tie their ability to have functional TLS on the ability for CAs to=20
maintain high-availability issuance services.=C2=A0 How much =
Delegated Credentials can be rotated and diversified inside an organ=
ization is only limited by the operational ability of the organization that=
 has control of the EE private key. 

Nick

On Tue, Jul=
 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote=
:













Hi Nick,


=C2=A0


I am not against delegated credentials, in fact I think it=E2=80=99s a goo=
d thing per se.


=C2=A0


I had expressed a couple of concerns at the time the call for adoption was=
 first issued [1], which I think are still valid.


=C2=A0


Could you please comment on / add them to your pro-cons analysis?


=C2=A0


Cheers, thanks,


t


=C2=A0


[1] https://www.ietf.org/mail-archive/web/tls/current/m=
sg22966.html


=C2=A0






On 18/07/2017, 12:06, &=
quot;TLS on behalf of Nick Sullivan" <tls-bounces@ietf.org on behalf of
nicholas.s=
ullivan@gmail.com> wrote:








=C2=A0








Sean,







We've had some additional discussions in person here at IETF 99 with fo=
lks who were in the proxy certificates and short-lived certs camp, and we t=
hink there is now more agreement that the mechanism described in this draft=
 is superior to the alternatives. I've
 included a summary of some of the pros and cons of the approaches:<=
u>




Proxy cer=
tificates vs. Delegated Credentials






=
Pro pr=
oxy certificates:






- Already de=
ployed in some industries, though not on the Web.






- Fits the c=
onceptual model that public key =3D=3D certificate.





=
Con pr=
oxy certificates:






- Proxy cert=
ificates adds additional complexity to the delegation other than limiting t=
he time period (full X.509, additional
 constraints=C2=A0 such as hostname).






- Encourages=
 implementers to reuse PKIX libraries rather than build code as part of TLS=
:

-- There have been problems and inconsistencies around pathlen and constrai=
nts enforcement in existing PKIX libraries.

-- Modifying these libraries is more complex and risk prone than delegated =
creds (which can easily be implemented in TLS as demonstrated by the 3 inte=
roperable implementations at the IETF 98 hackathon).





- In proxy c=
ertificates, pathing is SKI dependent, not directly tied to EE cert. This i=
s a binding weaker than delegated credentials
 which includes a signature over the EE certificate.





=C2=
=A0






Short-liv=
ed certs vs. Delegated Credentials






=
Pro sh=
ort-lived certs:






- Short live=
d certs work with existing libraries, no new code changes.






=
Con sh=
ort-lived certs:






- Not widely=
 available from CAs, especially for EV.






- Potentiall=
y problematic to the CT ecosystem (all certificates must be logged in CT, w=
hich may bloat them).






- Introduces=
 a high-risk operational dependency on external party:

-- Requires frequent exchanges with an external Certificate Authority (must=
 provide proof of domain possession to CA vs. internally managed credential=
 minter for delegated credentials).






-- There is =
no fallback if the CA has outage. With delegated credentials you can fall b=
ack to a LURK-style protocol with the
 long-lived certificate key.








=C2=A0





Given these comparisons=
, we think the proposed draft is the superior option and would like to cont=
inue the discussion about adopting it.






=C2=A0



Nick




=C2=A0





On Fri, May 19, 2017 at=
 12:58 AM Sean Turner <sean@sn3rd.com> wrote:






All,



During the WG call for adoption, a couple of questions were raised about co=
mparison/analysis of sub-certs versus proxy and/or short-lived certificates=
.=C2=A0 There is some discussion currently in the draft, but the chairs fee=
l that these issues need further discussion
 (and elaboration in the draft) prior to WG adoption.=C2=A0 So let=E2=80=99=
s keep the conversation going.



J&S



> On Apr 12, 2017, at 15:31, Sean Turner <sean@sn3rd.com> wrote:

>

> All,

>

> At our IETF 98 session, there was support in the room to adopt draft-r=
escorla-tls-subcerts [0].=C2=A0 We need to confirm this support on the list=
 so please let the list know whether you support adoption of the draft and =
are willing to review/comment on the draft
 before 20170429.=C2=A0 If you object to its adoption, please let us know w=
hy.

>

> Clearly, the WG is going to need to work through the trade-offs betwee=
n short-lived certificates and sub-certs because both seem, to some, to be =
addressing the same problem.

>

> Cheers,

>

> J&S

>

> [0] 
https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts



_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls








On Jul 18, 2017 9:26 AM, "Fossati, Thomas (Nokia - GB/Cambri=
dge, UK)" <thomas.fossa=
ti@nokia.com> wrote:




Hi Nick,


=C2=A0


Your write-up is spot on, thanks.


=C2=A0


Let me comment on a few points:


=C2=A0


=E2=80=9CHow much Delegated Credentials can b=
e rotated and diversified inside an organization is only limited by the ope=
rational ability of
 the organization that has control of the EE private key.=E2=80=9D


=C2=A0


The self-service/agile nature of D-C is great. With that, though, comes a =
cost of ownership that maybe not all players can afford.

Outsourcing to get to something like short lived certs is possible he=
re. If you can put a cert on a webserver I'm sure you can put it on a d=
elegated credential creator and point your server at it.
=



=C2=A0


- Introduces a high-risk operational dependen=
cy on external party:


-- Requires frequent exchanges with an extern=
al Certificate Authority (must provide proof of domain possession to CA vs.=
 internally
 managed credential minter for delegated credentials).=



=C2=A0


There should be ways to mitigate this, say allowing the next S-T in =
line to be available =E2=80=9Clong enough=E2=80=9D before it becomes active=
.


=C2=A0


-- There is no fallback if the CA has outage.=
 With delegated credentials you can fall back to a LURK-style protocol with=
 the long-lived
 certificate key.


=C2=A0


I understand the logics but, since LURK boxes don=E2=80=99t scale, t=
he cost to cover your entire footprint for the sporadic cases when the CA i=
s down might be a bit prohibitive.

CA reliability i=
s not good.


=C2=A0


Cheers, t


=C2=A0


=C2=A0






On 18/07/2017, 14:35, &=
quot;Nick Sullivan" <nicholas.sullivan@gmail.com> wrote:=









=C2=A0










Thomas,





Thanks for your comments. Let me see if I can summarize them:=







- A disadvantage of del=
egated credentials vs short-lived certs is that it requires client opt-in. =
This is also a disadvantage of proxy certificates. If client support is bel=
ow 100%, a LURK-type system may be required
 to keep long-term private keys off TLS termination endpoints.

- A disadvantage of delegated credentials is that it requires software upda=
tes on both client and server. This is also a disadvantage of proxy certifi=
cates. I think this is covered by my point below: "Short
 lived certs work with existing libraries, no new code changes."







- An a=
dvantage of short-lived certificates is that there is an audit log by a thi=
rd party (either the CA's internal logs and optionally Certificate Tran=
sparency logs).






I should state that short-liv=
ed certificates are possible right now and it's supported by some CAs, =
though not necessarily at the scale needed
 to provide, say, a unique 7-day certificate for each server of a large Int=
ernet company. This draft's advantages apply most strongly to organizat=
ions who don't want to tie their ability to have functional TLS on the =
ability for CAs to maintain high-availability
 issuance services.=C2=A0 How much Delegated Credentials can be rotated and=
 diversified inside an organization is only limited by the operational abil=
ity of the organization that has control of the EE private key.







=C2=A0



Nick








=C2=A0





On Tue, Jul 18, 2017 at=
 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>=
 wrote:











Hi Nick,=




=C2=A0



I am not against deleg=
ated credentials, in fact I think it=E2=80=99s a good thing per se.<=
u>



=C2=A0



I had expressed a coup=
le of concerns at the time the call for adoption was first issued [1], whic=
h I think are still valid.



=C2=A0



Could you please comme=
nt on / add them to your pro-cons analysis?



=C2=A0



Cheers, thanks,=




t=




=C2=A0



[1] 
https://www.ietf.org/mail-archive/web/tls/current/msg22966.html











=C2=A0






=C2=A0









Sean,







We've had some additional discussions in person here at IETF 99 with fo=
lks who were in the proxy certificates and short-lived certs camp, and we t=
hink there is now more agreement that the mechanism described in this draft=
 is superior to the alternatives. I've
 included a summary of some of the pros and cons of the approaches:<=
u>





Pro=
xy certificates vs. Delegated Credentials







=
Pro proxy certificates:







- Alre=
ady deployed in some industries, though not on the Web.







- Fits=
 the conceptual model that public key =3D=3D certificate.<=
/u>







=
Con proxy certificates:







- Prox=
y certificates adds additional complexity to the delegation other than limi=
ting the time period (full X.509, additional constraints=C2=A0 such as host=
name).







- Enco=
urages implementers to reuse PKIX libraries rather than build code as part =
of TLS:

-- There have been problems and inconsistencies around pathlen and constrai=
nts enforcement in existing PKIX libraries.

-- Modifying these libraries is more complex and risk prone than delegated =
creds (which can easily be implemented in TLS as demonstrated by the 3 inte=
roperable implementations at the IETF 98 hackathon).






- In p=
roxy certificates, pathing is SKI dependent, not directly tied to EE cert. =
This is a binding weaker than delegated credentials which includes a signat=
ure over the EE certificate.







=C2=A0=








Sho=
rt-lived certs vs. Delegated Credentials







=
Pro short-lived certs:







- Shor=
t lived certs work with existing libraries, no new code changes.<=
/u>







=
Con short-lived certs:







- Not =
widely available from CAs, especially for EV.







- Pote=
ntially problematic to the CT ecosystem (all certificates must be logged in=
 CT, which may bloat them).







- Intr=
oduces a high-risk operational dependency on external party:

-- Requires frequent exchanges with an external Certificate Authority (must=
 provide proof of domain possession to CA vs. internally managed credential=
 minter for delegated credentials).







-- The=
re is no fallback if the CA has outage. With delegated credentials you can =
fall back to a LURK-style protocol with the long-lived certificate key.









=C2=A0







Given these comparisons, we think the proposed draft is the superior option=
 and would like to continue the discussion about adopting it.=








=C2=A0





Nick





=C2=A0







On Fri, May 19, 2017 at 12:58 AM Sean Turner <sean@sn3rd.com> wrote:







All,



During the WG call for adoption, a couple of questions were raised about co=
mparison/analysis of sub-certs versus proxy and/or short-lived certificates=
.=C2=A0 There is some discussion currently in the draft, but the chairs fee=
l that these issues need further discussion
 (and elaboration in the draft) prior to WG adoption.=C2=A0 So let=E2=80=99=
s keep the conversation going.



J&S



> On Apr 12, 2017, at 15:31, Sean Turner <sean@sn3rd.com> wrote:

>

> All,

>

> At our IETF 98 session, there was support in the room to adopt draft-r=
escorla-tls-subcerts [0].=C2=A0 We need to confirm this support on the list=
 so please let the list know whether you support adoption of the draft and =
are willing to review/comment on the draft
 before 20170429.=C2=A0 If you object to its adoption, please let us know w=
hy.

>

> Clearly, the WG is going to need to work through the trade-offs betwee=
n short-lived certificates and sub-certs because both seem, to some, to be =
addressing the same problem.

>

> Cheers,

>

> J&S

>

> [0] 
https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts=




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls



























_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a1143ccc4d5107c05549a1653--


From nobody Tue Jul 18 11:11:01 2017
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 E8799131B3B for ; Tue, 18 Jul 2017 11:10:59 -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=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 VRiPoDzz0JEr for ; Tue, 18 Jul 2017 11:10:58 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 3323A129AD3 for ; Tue, 18 Jul 2017 11:10:58 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6II7LT9005068; Tue, 18 Jul 2017 19:10:56 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=6Xx626qt7Q37dKfgZpBw/vLbEZsppoUnefm5ukgUHtE=; b=iUCWIi38Nnea7VPEZbi9wI5QVQVNKP2VE3VlJooMAafglxMI8/JXfW+Mkadakkejoh6r W35ERuKTMp9s9hHigj4i5dYo4J0aN+FKEAij/EsPyaQ8tnhAuU7OyusjomSgVymrrtDa Xu1BKXQ1cqjnDV6GkqfEGrsvML4hVSAwTdzGl+h1r5uM0TVI68QKxQ0/gQ9JUX0KYphE 5ktlLn7XGMc149tBrnMelrXXuWYsWwKhTE5EAg8R2/aL+LLbsBxJJmq8pJsxKWunT0Xi MR6WOjUOzQ01H+zPdrF6mq9A8gafGiQiug+bHG2EiYs3pupFVIXPA9vvmFizJY/3TZlv tg== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2bqak4x1pd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 19:10:56 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6IIATwu008401; Tue, 18 Jul 2017 14:10:55 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2bqecv1mb0-1; Tue, 18 Jul 2017 14:10:55 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 0188B20064; Tue, 18 Jul 2017 12:10:54 -0600 (MDT)
To: Eric Rescorla 
Cc: Sean Turner , "" 
References: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com>   <752c2b4e-fb24-6857-ac88-e42504029dd6@akamai.com> 
From: Benjamin Kaduk 
Message-ID: <261d0fe6-764f-81d8-2701-f4031de8eb36@akamai.com>
Date: Tue, 18 Jul 2017 13:10:54 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E79E8759F352DBE6B4E653AC"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707180283
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707180283
Archived-At: 
Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 18:11:00 -0000

This is a multi-part message in MIME format.
--------------E79E8759F352DBE6B4E653AC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/18/2017 08:07 AM, Eric Rescorla wrote:
>
>
> On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk  > wrote:
>
>
>     That is, in this case, the CH+0RTT data can be replayed by an
>     observer once enough time has elapsed that the
>     expected_arrival_time is within the window, similar to one of the
>     reordering attacks mentioned elsewhere.  We could add the CH to
>     the strike register in this case, which would bloat its storage
>     somewhat and have entries that take longer than the window to
>     expire out.
>
>     I don't have a good sense for how often we expect postdated CHs to
>     occur and whether the ensuing breakage would be manageable, but
>     I'm not sure that we've thought very hard as a group about this
>     question.
>
>
> I think post-dated are going to happen pretty often based on what I
> understand from
> Kyle and others. I wouldn't be comfortable with hard fail, especially
> given that this
> just seems like the dual of the other case. Adding the CH to the list
> seems like
> a problem because it might stay forever.
>

The "stay forever" part is awkward, yes.  It would be great if Kyle/etc.
could say a bit about why post-dated seems likely on the list, but I
guess for the purposes of WGLC we can consider this comment resolved.

-Ben

--------------E79E8759F352DBE6B4E653AC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 07/18/2017 08:07 AM, Eric Rescorla wrote:

    

      
      


        


          
On Wed, Jul 12, 2017 at 3:39 PM,
            Benjamin Kaduk <bkaduk@akamai.com>
            wrote:

            
 

              
That
                is, in this case, the CH+0RTT data can be replayed by an
                observer once enough time has elapsed that the
                expected_arrival_time is within the window, similar to
                one of the reordering attacks mentioned elsewhere.  We
                could add the CH to the strike register in this case,
                which would bloat its storage somewhat and have entries
                that take longer than the window to expire out.

                

                I don't have a good sense for how often we expect
                postdated CHs to occur and whether the ensuing breakage
                would be manageable, but I'm not sure that we've thought
                very hard as a group about this question.

            

            


            

            
I think post-dated are going to happen pretty often
              based on what I understand from

            
Kyle and others. I wouldn't be comfortable with hard
              fail, especially given that this

            
just seems like the dual of the other case. Adding the
              CH to the list seems like

            
a problem because it might stay forever.

            


            

          

        

      

    

    

    The "stay forever" part is awkward, yes.  It would be great if
    Kyle/etc. could say a bit about why post-dated seems likely on the
    list, but I guess for the purposes of WGLC we can consider this
    comment resolved.

    

    -Ben

  


--------------E79E8759F352DBE6B4E653AC--


From nobody Tue Jul 18 12:05:38 2017
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 1872613179D for ; Tue, 18 Jul 2017 12:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (1024-bit key) header.d=fb.com header.b=W+CouqAW; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=jnAimVpl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6vURTnrjpC7 for ; Tue, 18 Jul 2017 12:05:33 -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 4D441131BCD for ; Tue, 18 Jul 2017 12:05:33 -0700 (PDT)
Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6IJ2Vm7006140; Tue, 18 Jul 2017 12:05:29 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=gV9pHQLneho99fLg5bvr1OIRUhct9qnvsO9D+PIi8uE=; b=W+CouqAWMACI0QwCm51JJg1oLQxHVmc7jgfIN8RAALdYg2+I0DSGvc+tFY2YsTICGp3w qgMeKlyzCDKHRKVNGrqHHtAJCMCKHp13/Nhpl1VxVYXdyI6uJj1WV658wt+I0pzDAqzy ChYgnrbxPqJH7wpZTfERshvaer9//F5dR44= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2bspew0h90-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jul 2017 12:05:29 -0700
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 18 Jul 2017 15:05:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=gV9pHQLneho99fLg5bvr1OIRUhct9qnvsO9D+PIi8uE=; b=jnAimVplgYkRoBLLiH8XcWDwC4QhUl6XpJlD3zdL93FD7m6xwisUV1VeWazQG24u8Uzx14Wb0YdRXOwTz3voxGLCVBhzvJOqrboy9b8IPIQ6Iu4dvecaBCMrsmiiasau2bMM++X1W7ojYNyMG4AtIr+HyNltCgTcODEXbKN+gOE=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1184.namprd15.prod.outlook.com (10.175.2.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Tue, 18 Jul 2017 19:05:25 +0000
Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.1261.024; Tue, 18 Jul 2017 19:05:25 +0000
From: Kyle Nekritz 
To: Benjamin Kaduk , Eric Rescorla 
CC: "" 
Thread-Topic: [TLS] 2nd WGLC: draft-ietf-tls-tls13
Thread-Index: AQHS9HlDCDJRMW0JlkuTgjl20q17Z6JPIpyAgAADMACAAbCdgIAIzl4AgABUqgCAAAmIQA==
Date: Tue, 18 Jul 2017 19:05:25 +0000
Message-ID: 
References: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com>   <752c2b4e-fb24-6857-ac88-e42504029dd6@akamai.com>  <261d0fe6-764f-81d8-2701-f4031de8eb36@akamai.com>
In-Reply-To: <261d0fe6-764f-81d8-2701-f4031de8eb36@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=fb.com;
x-originating-ip: [2620:10d:c091:200::2:d50c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1184; 20:JCLo2SGdo8UaDqZT1OTcNXZZjr/2djLSQnYcPUCzDBL6BZcOv2QFKpONN8j2cSSalQvYRpPwOv2qMlgLQg1NWJFVwuzrJlEjGTYS4mZYXxic644mNgVK6x9Kj+7e+Bzhwq7YGxItHsE3PJLi1m5UA2wosw5rERgNlylwTKHE9l8=
x-ms-office365-filtering-correlation-id: d5c6f6cc-0a90-4e66-9863-08d4ce0ff295
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1184; 
x-ms-traffictypediagnostic: MWHPR15MB1184:
x-exchange-antispam-report-test: UriScan:(151999592597050)(158342451672863)(26388249023172)(236129657087228)(148574349560750)(21748063052155)(247924648384137);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1184; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1184; 
x-forefront-prvs: 037291602B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39840400002)(39450400003)(39400400002)(377454003)(24454002)(81166006)(5660300001)(3660700001)(2906002)(8676002)(4326008)(2950100002)(74316002)(7696004)(53546010)(38730400002)(50986999)(76176999)(3280700002)(54356999)(25786009)(7736002)(14454004)(8936002)(53936002)(9686003)(86362001)(54896002)(6306002)(99286003)(189998001)(236005)(2900100001)(6246003)(6436002)(55016002)(229853002)(230783001)(93886004)(6116002)(478600001)(33656002)(790700001)(102836003)(6506006)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1184; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1182EA51FA0477398ED90977AFA10MWHPR15MB1182namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2017 19:05:25.3772 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1184
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_10:, , signatures=0
Archived-At: 
Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 19:05:37 -0000

--_000_MWHPR15MB1182EA51FA0477398ED90977AFA10MWHPR15MB1182namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGltZXN0YW1wcyBvdXRzaWRlIHRoZSBleHBlY3RlZCB3aW5kb3cgY2FuIGhhcHBlbiBkdWUgdG8g
dmFyaWFuY2VzIGluIFJUVCwgY2xpZW50IGNsb2NrIHNrZXcsIGV0Yy4gKHdlIHNlZSBhcm91bmQg
LjElIG9mIGNsaWVudHMgb3V0c2lkZSBvZiBhIDMwcyB3aW5kb3cgZm9yIGV4YW1wbGUpLiBOb3Qg
bGlrZWx5IHRvIGhhcHBlbiBvbiBhIGdpdmVuIGNvbm5lY3Rpb24sIGJ1dCBpdCBjZXJ0YWlubHkg
aGFwcGVucyBlbm91Z2ggdGhhdCB5b3UgZG9u4oCZdCB3YW50IHRvIGFib3J0IHRoZSBjb25uZWN0
aW9uIChyYXRoZXIgdGhhbiBhbGxvd2luZyAxLVJUVCkgd2l0aG91dCByZWFzb24uIEnigJltIG5v
dCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgZGVzaXJlIHRvIGFib3J0IHRoZXNlIGNvbm5lY3Rpb25z
LiBXaGF0IHZhbHVlIGRvZXMgaXQgcHJvdmlkZT8gVGhlIHRpbWVzdGFtcCBtZWNoYW5pc20gZG9l
cyBub3QgcHJvdmlkZSBwcm90ZWN0aW9uIGFnYWluc3QgYSBtYWxpY2lvdXMgY2xpZW50IHRoYXQg
aGFzIHBvc3Nlc3Npb24gb2YgdGhlIFBTSyBrZXkuDQoNCklmIHRoZSBzZXJ2ZXIgaXMgMTAwJSBz
dXJlIHRoYXQgYSBDSCBpcyByZXBsYXllZCBpdCBpcyBtb3JlIHJlYXNvbmFibGUgdG8gYWJvcnQg
dGhlIGNvbm5lY3Rpb24sIGJ1dCBJIHRoaW5rIGl0IHNob3VsZCBiZSBleHBsaWNpdCB0byB0aGUg
Y2xpZW50IHRoYXQgdGhhdCBpcyB0aGUgcmVhc29uIGZvciB0aGUgZXJyb3IgKGllIHVzaW5nIGEg
bmV3IGFsZXJ0IHR5cGUgcmF0aGVyIHRoYW4gaWxsZWdhbF9wYXJhbWV0ZXIpIHNvIHRoZSBjbGll
bnQgY2FuIGtub3cgdG8gcmV0cnkgd2l0aG91dCAwLVJUVC4gSeKAmW0gYWxzbyBzbGlnaHRseSBj
b25jZXJuZWQgdGhhdCBpdCBhbGxvd3MgYSBwYXNzaXZlIGF0dGFja2VyIHRvIGNhdXNlIGNvbm5l
Y3Rpb24gZmFpbHVyZXMgaWYgaXQgY2FuIGZyb250LXJ1biBhIGNvcHkgb2YgdGhlIENIIHRvIHRo
ZSBzZXJ2ZXIsIGFuZCBJIHN0aWxsIGRvbuKAmXQgdGhpbmsgaXQgaXMgcHJvdmlkaW5nIG11Y2gg
dmFsdWUuDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgQmVuamFtaW4gS2FkdWsNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTgsIDIwMTcgMjoxMSBQ
TQ0KVG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCkNjOiA8dGxzQGlldGYub3JnPiA8
dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIDJuZCBXR0xDOiBkcmFmdC1pZXRmLXRs
cy10bHMxMw0KDQpPbiAwNy8xOC8yMDE3IDA4OjA3IEFNLCBFcmljIFJlc2NvcmxhIHdyb3RlOg0K
DQoNCg0KT24gV2VkLCBKdWwgMTIsIDIwMTcgYXQgMzozOSBQTSwgQmVuamFtaW4gS2FkdWsgPGJr
YWR1a0Bha2FtYWkuY29tPG1haWx0bzpia2FkdWtAYWthbWFpLmNvbT4+IHdyb3RlOg0KDQpUaGF0
IGlzLCBpbiB0aGlzIGNhc2UsIHRoZSBDSCswUlRUIGRhdGEgY2FuIGJlIHJlcGxheWVkIGJ5IGFu
IG9ic2VydmVyIG9uY2UgZW5vdWdoIHRpbWUgaGFzIGVsYXBzZWQgdGhhdCB0aGUgZXhwZWN0ZWRf
YXJyaXZhbF90aW1lIGlzIHdpdGhpbiB0aGUgd2luZG93LCBzaW1pbGFyIHRvIG9uZSBvZiB0aGUg
cmVvcmRlcmluZyBhdHRhY2tzIG1lbnRpb25lZCBlbHNld2hlcmUuICBXZSBjb3VsZCBhZGQgdGhl
IENIIHRvIHRoZSBzdHJpa2UgcmVnaXN0ZXIgaW4gdGhpcyBjYXNlLCB3aGljaCB3b3VsZCBibG9h
dCBpdHMgc3RvcmFnZSBzb21ld2hhdCBhbmQgaGF2ZSBlbnRyaWVzIHRoYXQgdGFrZSBsb25nZXIg
dGhhbiB0aGUgd2luZG93IHRvIGV4cGlyZSBvdXQuDQoNCkkgZG9uJ3QgaGF2ZSBhIGdvb2Qgc2Vu
c2UgZm9yIGhvdyBvZnRlbiB3ZSBleHBlY3QgcG9zdGRhdGVkIENIcyB0byBvY2N1ciBhbmQgd2hl
dGhlciB0aGUgZW5zdWluZyBicmVha2FnZSB3b3VsZCBiZSBtYW5hZ2VhYmxlLCBidXQgSSdtIG5v
dCBzdXJlIHRoYXQgd2UndmUgdGhvdWdodCB2ZXJ5IGhhcmQgYXMgYSBncm91cCBhYm91dCB0aGlz
IHF1ZXN0aW9uLg0KDQpJIHRoaW5rIHBvc3QtZGF0ZWQgYXJlIGdvaW5nIHRvIGhhcHBlbiBwcmV0
dHkgb2Z0ZW4gYmFzZWQgb24gd2hhdCBJIHVuZGVyc3RhbmQgZnJvbQ0KS3lsZSBhbmQgb3RoZXJz
LiBJIHdvdWxkbid0IGJlIGNvbWZvcnRhYmxlIHdpdGggaGFyZCBmYWlsLCBlc3BlY2lhbGx5IGdp
dmVuIHRoYXQgdGhpcw0KanVzdCBzZWVtcyBsaWtlIHRoZSBkdWFsIG9mIHRoZSBvdGhlciBjYXNl
LiBBZGRpbmcgdGhlIENIIHRvIHRoZSBsaXN0IHNlZW1zIGxpa2UNCmEgcHJvYmxlbSBiZWNhdXNl
IGl0IG1pZ2h0IHN0YXkgZm9yZXZlci4NCg0KDQpUaGUgInN0YXkgZm9yZXZlciIgcGFydCBpcyBh
d2t3YXJkLCB5ZXMuICBJdCB3b3VsZCBiZSBncmVhdCBpZiBLeWxlL2V0Yy4gY291bGQgc2F5IGEg
Yml0IGFib3V0IHdoeSBwb3N0LWRhdGVkIHNlZW1zIGxpa2VseSBvbiB0aGUgbGlzdCwgYnV0IEkg
Z3Vlc3MgZm9yIHRoZSBwdXJwb3NlcyBvZiBXR0xDIHdlIGNhbiBjb25zaWRlciB0aGlzIGNvbW1l
bnQgcmVzb2x2ZWQuDQoNCi1CZW4NCg==

--_000_MWHPR15MB1182EA51FA0477398ED90977AFA10MWHPR15MB1182namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN
Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z
b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l
Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu
Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNv
bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5
N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u
dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47
DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7
cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48
IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0
PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5
b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh
bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu
ZG93dGV4dCI+VGltZXN0YW1wcyBvdXRzaWRlIHRoZSBleHBlY3RlZCB3aW5kb3cgY2FuIGhhcHBl
biBkdWUgdG8gdmFyaWFuY2VzIGluIFJUVCwgY2xpZW50IGNsb2NrIHNrZXcsIGV0Yy4gKHdlIHNl
ZSBhcm91bmQgLjElIG9mIGNsaWVudHMgb3V0c2lkZSBvZiBhIDMwcyB3aW5kb3cgZm9yDQogZXhh
bXBsZSkuIE5vdCBsaWtlbHkgdG8gaGFwcGVuIG9uIGEgZ2l2ZW4gY29ubmVjdGlvbiwgYnV0IGl0
IGNlcnRhaW5seSBoYXBwZW5zIGVub3VnaCB0aGF0IHlvdSBkb27igJl0IHdhbnQgdG8gYWJvcnQg
dGhlIGNvbm5lY3Rpb24gKHJhdGhlciB0aGFuIGFsbG93aW5nIDEtUlRUKSB3aXRob3V0IHJlYXNv
bi4gSeKAmW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8gYWJvcnQgdGhlc2Ug
Y29ubmVjdGlvbnMuIFdoYXQgdmFsdWUgZG9lcw0KIGl0IHByb3ZpZGU/IFRoZSB0aW1lc3RhbXAg
bWVjaGFuaXNtIGRvZXMgbm90IHByb3ZpZGUgcHJvdGVjdGlvbiBhZ2FpbnN0IGEgbWFsaWNpb3Vz
IGNsaWVudCB0aGF0IGhhcyBwb3NzZXNzaW9uIG9mIHRoZSBQU0sga2V5LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k
b3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+SWYgdGhlIHNlcnZlciBpcyAxMDAl
IHN1cmUgdGhhdCBhIENIIGlzIHJlcGxheWVkIGl0IGlzIG1vcmUgcmVhc29uYWJsZSB0byBhYm9y
dCB0aGUgY29ubmVjdGlvbiwgYnV0IEkgdGhpbmsgaXQgc2hvdWxkIGJlIGV4cGxpY2l0IHRvIHRo
ZSBjbGllbnQgdGhhdCB0aGF0IGlzDQogdGhlIHJlYXNvbiBmb3IgdGhlIGVycm9yIChpZSB1c2lu
ZyBhIG5ldyBhbGVydCB0eXBlIHJhdGhlciB0aGFuIGlsbGVnYWxfcGFyYW1ldGVyKSBzbyB0aGUg
Y2xpZW50IGNhbiBrbm93IHRvIHJldHJ5IHdpdGhvdXQgMC1SVFQuIEnigJltIGFsc28gc2xpZ2h0
bHkgY29uY2VybmVkIHRoYXQgaXQgYWxsb3dzIGEgcGFzc2l2ZSBhdHRhY2tlciB0byBjYXVzZSBj
b25uZWN0aW9uIGZhaWx1cmVzIGlmIGl0IGNhbiBmcm9udC1ydW4gYSBjb3B5IG9mIHRoZSBDSA0K
IHRvIHRoZSBzZXJ2ZXIsIGFuZCBJIHN0aWxsIGRvbuKAmXQgdGhpbmsgaXQgaXMgcHJvdmlkaW5n
IG11Y2ggdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv
d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+
IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5C
ZW5qYW1pbiBLYWR1azxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDE4LCAyMDE3IDI6
MTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs8
YnI+DQo8Yj5DYzo8L2I+ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7
PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSAybmQgV0dMQzogZHJhZnQtaWV0Zi10bHMt
dGxzMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAw
Ny8xOC8yMDE3IDA4OjA3IEFNLCBFcmljIFJlc2NvcmxhIHdyb3RlOjxicj4NCjxicj4NCjxvOnA+
PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdWwgMTIsIDIwMTcgYXQgMzoz
OSBQTSwgQmVuamFtaW4gS2FkdWsgJmx0OzxhIGhyZWY9Im1haWx0bzpia2FkdWtAYWthbWFpLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPmJrYWR1a0Bha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMsIGluIHRoaXMgY2FzZSwgdGhlIENIJiM0MzswUlRU
IGRhdGEgY2FuIGJlIHJlcGxheWVkIGJ5IGFuIG9ic2VydmVyIG9uY2UgZW5vdWdoIHRpbWUgaGFz
IGVsYXBzZWQgdGhhdCB0aGUgZXhwZWN0ZWRfYXJyaXZhbF90aW1lIGlzIHdpdGhpbiB0aGUgd2lu
ZG93LCBzaW1pbGFyIHRvIG9uZSBvZiB0aGUgcmVvcmRlcmluZyBhdHRhY2tzIG1lbnRpb25lZCBl
bHNld2hlcmUuJm5ic3A7IFdlIGNvdWxkIGFkZCB0aGUgQ0gNCiB0byB0aGUgc3RyaWtlIHJlZ2lz
dGVyIGluIHRoaXMgY2FzZSwgd2hpY2ggd291bGQgYmxvYXQgaXRzIHN0b3JhZ2Ugc29tZXdoYXQg
YW5kIGhhdmUgZW50cmllcyB0aGF0IHRha2UgbG9uZ2VyIHRoYW4gdGhlIHdpbmRvdyB0byBleHBp
cmUgb3V0Ljxicj4NCjxicj4NCkkgZG9uJ3QgaGF2ZSBhIGdvb2Qgc2Vuc2UgZm9yIGhvdyBvZnRl
biB3ZSBleHBlY3QgcG9zdGRhdGVkIENIcyB0byBvY2N1ciBhbmQgd2hldGhlciB0aGUgZW5zdWlu
ZyBicmVha2FnZSB3b3VsZCBiZSBtYW5hZ2VhYmxlLCBidXQgSSdtIG5vdCBzdXJlIHRoYXQgd2Un
dmUgdGhvdWdodCB2ZXJ5IGhhcmQgYXMgYSBncm91cCBhYm91dCB0aGlzIHF1ZXN0aW9uLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JIHRoaW5rIHBvc3QtZGF0ZWQgYXJlIGdvaW5nIHRvIGhhcHBlbiBwcmV0dHkgb2Z0
ZW4gYmFzZWQgb24gd2hhdCBJIHVuZGVyc3RhbmQgZnJvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S3lsZSBhbmQgb3RoZXJzLiBJIHdvdWxkbid0
IGJlIGNvbWZvcnRhYmxlIHdpdGggaGFyZCBmYWlsLCBlc3BlY2lhbGx5IGdpdmVuIHRoYXQgdGhp
czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+anVz
dCBzZWVtcyBsaWtlIHRoZSBkdWFsIG9mIHRoZSBvdGhlciBjYXNlLiBBZGRpbmcgdGhlIENIIHRv
IHRoZSBsaXN0IHNlZW1zIGxpa2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPmEgcHJvYmxlbSBiZWNhdXNlIGl0IG1pZ2h0IHN0YXkgZm9yZXZlci48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGUgJnF1b3Q7c3RheSBmb3JldmVy
JnF1b3Q7IHBhcnQgaXMgYXdrd2FyZCwgeWVzLiZuYnNwOyBJdCB3b3VsZCBiZSBncmVhdCBpZiBL
eWxlL2V0Yy4gY291bGQgc2F5IGEgYml0IGFib3V0IHdoeSBwb3N0LWRhdGVkIHNlZW1zIGxpa2Vs
eSBvbiB0aGUgbGlzdCwgYnV0IEkgZ3Vlc3MgZm9yIHRoZSBwdXJwb3NlcyBvZiBXR0xDIHdlIGNh
biBjb25zaWRlciB0aGlzIGNvbW1lbnQgcmVzb2x2ZWQuPGJyPg0KPGJyPg0KLUJlbjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_MWHPR15MB1182EA51FA0477398ED90977AFA10MWHPR15MB1182namp_--


From nobody Tue Jul 18 14:06:54 2017
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 7FF53131803; Tue, 18 Jul 2017 14:06:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 88G8vUS7muUh; Tue, 18 Jul 2017 14:06:38 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 5A99712EC23; Tue, 18 Jul 2017 14:06:38 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id 12so46664547wrb.1; Tue, 18 Jul 2017 14:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=SEfm4AnFh5uvikYToVE7bCgWp4QpwSujpNXn8tDVavU=; b=c+0W5RUy/V7SOwv5nZ7wdiSeviDo74WuTrzPp28Pvv2sX6XIMjnxvXTDwlnyUy+TL3 KDiT+bXmYDBK6YpB3ZSD3u9mjmGqP0pE2ESzGYe/8BJNBseR/jnI6HtwrggUb8CNMlje 1oIwmzVj4hh9gcB67rKDcjSzX+NMryJ7Nik1BqHVDHMOLZRhLRL64ntXmjLAeosJO50t vDnkas+2ZxPlwd1d5AvphjPnbVmkHFpYvhce8cBPZceLdYLBkb9IjkbSpz5m2XI1LPi8 PIZDdqCstVY9XpOqDtyNgXbd9BYcM690g5zzwJX7m/XfbEgJBi1Cvl8LbMR8jiYwv22r RTjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=SEfm4AnFh5uvikYToVE7bCgWp4QpwSujpNXn8tDVavU=; b=hVxAB52NN26IFrFPwugowem9iOJEzck0OFRtrJMkNuauDQ3xRQYda6BbAK4eqw0t3k SW+9uqV3CPr2+Csy1chjBSjy1S4BuqUlAuXmJeYFt7tCSGrOPbHVNWH68JiwiIuaeI+q 6iGuPyM0nZCaI8CrO8VEoksbY6WrM1b1ofUy3v1C6p3OrMWY0B43zLvLHHAOHGH/Xgiw +rMDkRXEIjjEtT9lmw5QCWd+4MFREnWQ1GEN1JCIlDwz9ux2t5Xt5SpFGe5iM+UpWcoQ tt+RMKof7LIG3F+Nqd9sSUW1M8zoF3HcssB2M/mZYSuQl2xqW2Sa/E9s+OEdOs+B1ZMW qsdA==
X-Gm-Message-State: AIVw113YG2b99dWr4j0InC2q+5Ocn6pD3giL+E7I05wN+SyS4MLtTs7D kPdm1gWTPUsNp7qkxBo=
X-Received: by 10.223.163.10 with SMTP id c10mr670697wrb.164.1500411996487; Tue, 18 Jul 2017 14:06:36 -0700 (PDT)
Received: from [172.20.0.78] ([88.208.89.131]) by smtp.gmail.com with ESMTPSA id q2sm19585275wmg.3.2017.07.18.14.06.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 14:06:36 -0700 (PDT)
To: Watson Ladd , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" 
Cc: LURK BoF , tls@ietf.org
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>  <61435CE8-3A17-4773-8329-54908985FB80@nokia.com>   
From: Yaron Sheffer 
Message-ID: <551adafa-db63-4884-216e-bf5cfecf0c2d@gmail.com>
Date: Tue, 18 Jul 2017 23:06:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 18 Jul 2017 21:06:46 -0000

On 18/07/17 18:34, Watson Ladd wrote:
>
>     I understand the logics but, since LURK boxes don’t scale, the
>     cost to cover your entire footprint for the sporadic cases when
>     the CA is down might be a bit prohibitive.
>
>
> CA reliability is not good.
>
>
 From my own experience, I agree that CA reliability is "not good". 
However if I'm using short-term certs with say, a 7 day validity, and 
(per draft-ietf-acme-star) the next certificate is issued halfway 
through this period, it means that the CA has to to be unavailable for 
all of 3.5 days for the failure to affect the delegated site. That's a 
lot, even for a CA.

On the other hand the LURK signing box (though managed by the same 
organization, which is a clear benefit) needs to be available at the 
same level of the delegated site - 99.99% of the time or whatever your 
standard is.

Thanks,
     Yaron


From nobody Tue Jul 18 17:52:33 2017
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 BBBEA131691 for ; Tue, 18 Jul 2017 17:52:32 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ywrvW5xomE7f for ; Tue, 18 Jul 2017 17:52:30 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC0C12441E for ; Tue, 18 Jul 2017 17:52:28 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRM79754; Wed, 19 Jul 2017 00:52:26 +0000 (GMT)
Received: from DGGEMI401-HUB.china.huawei.com (10.3.17.134) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 19 Jul 2017 01:52:25 +0100
Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.151]) by dggemi401-hub.china.huawei.com ([10.3.17.134]) with mapi id 14.03.0301.000; Wed, 19 Jul 2017 08:52:20 +0800
From: yinxinxing 
To: Dan Wing 
CC: "tls@ietf.org" , Sean Turner 
Thread-Topic: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2
Thread-Index: AdL2zV5W/HDgxBACQSqQFOyDPszOzQEDqAMAAASeQgAAH2kMQP//hj2A//9mI6CAANgkgP//MwQA//h4IcACHyz/AP/+79iQ
Date: Wed, 19 Jul 2017 00:52:20 +0000
Message-ID: 
References:   <8B21E199-A56B-41DE-A50B-C689C0DA7BA0@gmail.com>    <609E20D4-2430-4DE0-BF10-C3F44AA4A350@gmail.com>  <8AF62E7E-84AA-4011-8895-3274559DA4E8@gmail.com>
In-Reply-To: <8AF62E7E-84AA-4011-8895-3274559DA4E8@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.184.225.248]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.596EAD4B.0032, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7c9b4d1e7dd2418be352d6763ee8b7a5
Archived-At: 
Subject: [TLS] =?utf-8?b?562U5aSNOiAgU29sdmluZyB0aGUgTkFUIGV4cGlyaW5nIHBy?= =?utf-8?q?oblem_causing_DTLS_renegotiation_with_high_power_consumption_in?= =?utf-8?q?_DTLS1=2E2?=
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 00:52:33 -0000

VGhhbmtzIFdpbmcuDQoNCkkgYW0gZ2xhZCB0byBkaXNjdXNzIHRoZSB0ZWNobmljYWwgZGV0YWls
cyBvZiBDSUQgZHJhZnQgd2l0aCBIYW5uZXMsIFRob21hcyBhbmQgTmlrb3MuIA0KDQpSZWdhcmRz
LA0KWWluIFhpbnhpbmcNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBEYW4g
V2luZyBbbWFpbHRvOmRhbndpbmdAZ21haWwuY29tXSANCuWPkemAgeaXtumXtDogMjAxN+W5tDfm
nIgxOeaXpSAwOjM0DQrmlLbku7bkuro6IHlpbnhpbnhpbmcNCuaKhOmAgTogdGxzQGlldGYub3Jn
OyBTZWFuIFR1cm5lcg0K5Li76aKYOiBSZTogW1RMU10gU29sdmluZyB0aGUgTkFUIGV4cGlyaW5n
IHByb2JsZW0gY2F1c2luZyBEVExTIHJlbmVnb3RpYXRpb24gd2l0aCBoaWdoIHBvd2VyIGNvbnN1
bXB0aW9uIGluIERUTFMxLjINCg0KDQo+IE9uIEp1bCAxNiwgMjAxNywgYXQgODozOSBQTSwgeWlu
eGlueGluZyA8eWlueGlueGluZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIFdpbmcsDQo+
IA0KPiBJIG5vdGljZWQgdGhhdCBIZWxsb3ZlcmlmeXJlcXVlc3QgaXMgb3B0aW9uYWwgYnkgdGhl
IHNlcnZlciBhbmQgdXNlZCB3aGVuIERPUyBpcyB0byBiZSBtaXRpZ2F0ZWQuIA0KPiANCj4gQnV0
IGZyb20gcHJhY3RpY2FsIHVzZSBjYXNlcywgdGhlIElPVCBzZXJ2ZXIgbWF5IG5vdCBoYXZlIGRl
ZGljYXRlZCBhbnRpLURPUyBtZWNoYW5pc20uIA0KPiANCj4gSWYgdGhlcmUgaXMgYSBtb3JlIHBv
d2VyLXNhdmluZyBzb2x1dGlvbiB3aXRoIHRoZSBmdW5jdGlvbiBvZiBET1MgbWl0aWdhdGlvbiBy
ZXRhaW5lZCwgYW5kIGRvbid0IG5lZWQgdG8gYm90aGVyIHRoZSBzZXJ2ZXIoY3VzdG9tZXIpIHRv
IGRlcGxveSBhbnRpLURPUyBkZXZpY2VzLCB3aHkgbm90IGhhdmUgYSB0cnk/ICANCg0KU3VyZS4g
IFlvdSBtaWdodCB3b3JrIHdpdGggdGhlIGF1dGhvcnMgb2YgZHJhZnQtbWF2cm9naWFubm9wb3Vs
b3MtdGxzLWNpZCB0byBhZGQgbW9yZSBjb25zaWRlcmF0aW9ucyBhcm91bmQgZGVuaWFsIG9mIHNl
cnZpY2UsIHBlcmhhcHMgYWxzbyBhIGxvbmdlciBjaWQgYXMgeW91IHN1Z2dlc3RlZCBlYXJsaWVy
Lg0KDQotZA0KDQoNCj4gUmVnYXJkcywNCj4gWWluIFhpbnhpbmcNCj4gDQo+IC0tLS0t6YKu5Lu2
5Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiB5aW54aW54aW5nDQo+IOWPkemAgeaXtumXtDogMjAx
N+W5tDfmnIgxM+aXpSAxNjo1Ng0KPiDmlLbku7bkuro6ICdEYW4gV2luZycNCj4g5oqE6YCBOiB0
bHNAaWV0Zi5vcmc7IFNlYW4gVHVybmVyDQo+IOS4u+mimDog562U5aSNOiBbVExTXSBTb2x2aW5n
IHRoZSBOQVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVzaW5nIERUTFMgDQo+IHJlbmVnb3RpYXRpb24g
d2l0aCBoaWdoIHBvd2VyIGNvbnN1bXB0aW9uIGluIERUTFMxLjINCj4gDQo+IEhpIFdpbmcsDQo+
IA0KPiBQbGVhc2Ugc2VlIHRoZSBjb21tZW50cyBpbmxpbmUNCj4gDQo+IFJlZ2FyZHMsDQo+IFlp
biBYaW54aW5nDQo+IA0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogRGFu
IFdpbmcgW21haWx0bzpkYW53aW5nQGdtYWlsLmNvbV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0
N+aciDEz5pelIDEyOjM1DQo+IOaUtuS7tuS6ujogeWlueGlueGluZw0KPiDmioTpgIE6IHRsc0Bp
ZXRmLm9yZzsgU2VhbiBUdXJuZXINCj4g5Li76aKYOiBSZTogW1RMU10gU29sdmluZyB0aGUgTkFU
IGV4cGlyaW5nIHByb2JsZW0gY2F1c2luZyBEVExTIA0KPiByZW5lZ290aWF0aW9uIHdpdGggaGln
aCBwb3dlciBjb25zdW1wdGlvbiBpbiBEVExTMS4yDQo+IA0KPiANCj4+IE9uIEp1bCAxMiwgMjAx
NywgYXQgNzoxMSBQTSwgeWlueGlueGluZyA8eWlueGlueGluZ0BodWF3ZWkuY29tPiB3cm90ZToN
Cj4+IA0KPj4gVGhhbmtzIFdpbmcsDQo+PiANCj4+IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5s
aW5lLg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gWWluIFhpbnhpbmcNCj4+IA0KPj4gLS0tLS3pgq7k
u7bljp/ku7YtLS0tLQ0KPj4g5Y+R5Lu25Lq6OiBEYW4gV2luZyBbbWFpbHRvOmRhbndpbmdAZ21h
aWwuY29tXQ0KPj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0N+aciDEz5pelIDg6NTINCj4+IOaUtuS7
tuS6ujogeWlueGlueGluZw0KPj4g5oqE6YCBOiB0bHNAaWV0Zi5vcmc7IFNlYW4gVHVybmVyDQo+
PiDkuLvpopg6IFJlOiBbVExTXSBTb2x2aW5nIHRoZSBOQVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVz
aW5nIERUTFMgDQo+PiByZW5lZ290aWF0aW9uIHdpdGggaGlnaCBwb3dlciBjb25zdW1wdGlvbiBp
biBEVExTMS4yDQo+PiANCj4+IA0KPj4+IE9uIEp1bCAxMiwgMjAxNywgYXQgNToyMSBQTSwgeWlu
eGlueGluZyA8eWlueGlueGluZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4+PiANCj4+PiBIaSBEYW4g
V2luZywNCj4+PiANCj4+PiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQo+Pj4gDQo+Pj4gUGxl
YXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiBZaW4g
WGlueGluZw0KPj4+IA0KPj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4+PiDlj5Hku7bkuro6
IERhbiBXaW5nIFttYWlsdG86ZGFud2luZ0BnbWFpbC5jb21dDQo+Pj4g5Y+R6YCB5pe26Ze0OiAy
MDE35bm0N+aciDEz5pelIDE6MDkNCj4+PiDmlLbku7bkuro6IHlpbnhpbnhpbmcNCj4+PiDmioTp
gIE6IHRsc0BpZXRmLm9yZzsgU2VhbiBUdXJuZXINCj4+PiDkuLvpopg6IFJlOiBbVExTXSBTb2x2
aW5nIHRoZSBOQVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVzaW5nIERUTFMgDQo+Pj4gcmVuZWdvdGlh
dGlvbiB3aXRoIGhpZ2ggcG93ZXIgY29uc3VtcHRpb24gaW4gRFRMUzEuMg0KPj4+IA0KPj4+IA0K
Pj4+PiBPbiBKdWwgMTIsIDIwMTcsIGF0IDc6NTYgQU0sIFNlYW4gVHVybmVyIDxzZWFuQHNuM3Jk
LmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiANCj4+Pj4+IE9uIEp1bCA2LCAyMDE3LCBhdCAyMzow
NCwgeWlueGlueGluZyA8eWlueGlueGluZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+
Pj4gSGkgYWxsLA0KPj4+Pj4gDQo+Pj4+PiBUaGUgTkFUIHRhYmxlIGV4cGlyaW5nIHByb2JsZW0g
bWVudGlvbmVkIGluIHRoZSAgZm9sbG93aW5nIGVtYWlsIHNob3VsZCBhbHNvIGJlIGNvbnNpZGVy
ZWQgaW4gRFRMUzEuMiBhcyBhbiBleHRlbnNpb24uDQo+Pj4+PiANCj4+Pj4+IFRoZSB2YWx1ZSBh
bmQgbmVjZXNzaXR5IGFyZSBhcyBmb2xsb3dzLg0KPj4+Pj4gDQo+Pj4+PiAxLiBFc3NlbnRpYWxs
eSwgTkFUIGV4cGlyaW5nIHByb2JsZW0gY2F1c2luZyBEVExTIHJlbmVnb3RpYXRpb24gd2l0aCBo
aWdoIHBvd2VyIGNvbnN1bXB0aW9uIGlzIGV4aXN0aW5nIGluIERUTFMgMS4yLiBFdmVuIGlmIHdl
IHNvbHZlIHRoaXMgaW4gRFRMUzEuMywgdGhpcyBwcm9ibGVtIHN0aWxsIGV4aXN0IGZvciBwcm9k
dWN0cyB1c2luZyBEVExTMS4yLg0KPj4+Pj4gQ3VycmVudGx5LCBtYW55IElPVCBwcm9kdWN0cyB1
c2luZyBEVExTIDEuMiBhcmUgZ29pbmcgdG8gYmUgZGVwbG95ZWQgY29tbWVyY2lhbGx5LCBzdWNo
IGFzIGludGVsbGlnZW50IHdhdGVyL2dhcyBtZXRlci4gVGhlc2UgbWV0ZXJzIHVzdWFsbHkgaGF2
ZSBsaW1pdGVkIGJhdHRlcnkgYW5kIGxvdyBjb3N0LiBUbyBiZSBtb3JlIGFjY3VyYXRlLCB0aGUg
YmF0dGVyeSBvZiB0aGUgY2hpcCBtb2R1bGUgb2YgdGhlIGludGVsbGlnZW50IHdhdGVyL2dhcyBt
ZXRlciBhcmUgcmVxdWlyZWQgdG8gbGFzdCBmb3IgMTAgeWVhcnMuIFRoZXNlIGxlYWQgdG8gYW4g
ZXhlcmNpc2Ugc3RyaWN0IGNvbnRyb2wgb3ZlciB0aGUgcG93ZXIgY29uc3VtcHRpb24gb2YgdGhl
IGNoaXAgbW9kdWxlLiBOQVQgZXhwaXJpbmcgcHJvYmxlbSBjYXVzaW5nIERUTFMgcmVuZWdvdGlh
dGlvbiB3aXRoIGhpZ2ggcG93ZXIgY29uc3VtcHRpb24gaXMgYSBib3R0bGVuZWNrIG9mIHRoZXNl
IElPVCBkZXZpY2VzLiBBY2NvcmRpbmcgdG8gb3VyIGV4cGVyaW1lbnRhbCBkYXRhLCB1bmRlciB0
aGUgd29yc3QgY292ZXJhZ2UgbGV2ZWwgKEVDTDIpLCBwb3dlciBjb25zdW1wdGlvbiBvZiB0aGUg
Y2hpcCBtb2R1bGUgd2hlbiBEVExTIGlzIGVtYmVkZGVkIGluY3JlYXNlcyBieSBuZWFybHkgNjAl
LiBUaGVyZWZvcmUsIHRoZXJlIHNob3VsZCBiZSBhIHNvbHV0aW9uIHRvIHNvbHZlIHRoZSB1cmdl
bnQgcHJvYmxlbSB0byBtYXRjaCB0aGUgbG93LWNvc3QgYW5kIGxvdy1iYXR0ZXJ5IGZlYXR1cmUg
b2YgdGhlIElPVCBkZXZpY2VzIGluIERUTFMgMS4yLg0KPj4+PiANCj4+Pj4gSSBoYXZlIHRvIGFz
ayB3aGV0aGVyIHRoZXNlIElvVCBkZXZpY2VzIGFyZSB1cGRhdGFibGU/DQo+Pj4+IA0KPj4+Pj4g
Mi4gRFRMUyAxLjMgd2lsbCBiZSBzdGFuZGFyZGl6ZWQgaW4gMjAxOCwgYnV0IHRoZSBjb3JyZXNw
b25kaW5nIG9wZW4gc291cmNlIGNvZGUgd2lsbCBiZSBhdmFpbGFibGUgYWJvdXQgb25lIHllYXIg
bGF0ZXIgYWZ0ZXIgdGhlIHN0YW5kYXJkaXphdGlvbi4gQXQgcHJlc2VudCwgbGFyZ2Utc2NhbGUg
Y29tbWVyY2lhbCBJT1QgaW5kdXN0cnkgZGVwbG95bWVudCBpcyB1cmdlbnQsIGl0IGlzIHRvbyBs
YXRlIHRvIHdhaXQgZm9yIERUTFMgMS4zLiBUaHVzLCB3ZSBob3BlIHRoYXQgdGhlIGFib3ZlIHBy
b2JsZW0gY291bGQgYmUgc29sdmVkIGluIERUTFMgMS4yIGFzIHNvb24gYXMgcG9zc2libGUuDQo+
Pj4+IA0KPj4+PiBPbiB0aGlzIHBvaW50LCBJ4oCZbSBob3BpbmcgdGhhdCB5b3XigJlsbCBiZSB3
cm9uZyA7KS4gRnJvbSB0aGUgbGlzdCBvZiBUTFMgaW1wbGVtZW50YXRpb25zIGZvdW5kIGhlcmU6
DQo+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL3dpa2kvSW1wbGVtZW50
YXRpb25zDQo+Pj4+IGFuZCBhc3N1bWluZyB0aGVyZSBpcyBhcyBtdWNoIGVudGh1c2lhc20gdG8g
aW1wbGVtZW50IERUTFMxLjMgYXMgdGhlcmUgd2FzIGZvciBUTFMxLjMgdGhlbiBJ4oCZbSBob3Bp
bmcgdGhhdCB0aGUgRFRMUyBpbXBsZW1lbnRhdGlvbnMgd2lsbCBiZSByZWFkeSBtdWNoIHNvb25l
ciB0aGFuIGEgeWVhciBhZnRlciBwdWJsaWNhdGlvbiAodGhleSBtaWdodCBiZSByZWFkeSBiZWZv
cmUgdGhlIFJGQyBpcyBwdWJsaXNoZWQpLg0KPj4+IA0KPj4+IA0KPj4+PiBZaW4gWGlueGluZywN
Cj4+PiANCj4+Pj4gV2hpbGUgd2FpdGluZyBmb3IgY2lkLCBwZXJoYXBzIHRvZGF5IGRvIHNlc3Np
b24gcmVzdW1wdGlvbiANCj4+Pj4gKFJGQzUwNzcpLCBhbnl0aW1lIHRoZSBjbGllbnQgaGFzIHJl
YXNvbiB0byBzdXNwZWN0IHRoZWlyIFVEUCBwb3J0IA0KPj4+PiBvciBJUCBhZGRyZXNzIG1pZ2h0
IGhhdmUgY2hhbmdlZCAtLSBzdWNoIGFzIGl0J3MgYmVlbiBsb25nZXIgdGhhbiwgDQo+Pj4+IHNh
eSwgMzAgc2Vjb25kcyBzaW5jZSBsYXN0IFVEUCB0cmFuc21pc3Npb24uICAoVGhlIHByb2JsZW0g
aXNuJ3QgDQo+Pj4+IHNvbGVseSBOQVQ7IHRoZXJlIGFyZSBzZXZlcmFsIElTUHMgdGhhdCBjaGFu
Z2Ugc3Vic2NyaWJlcidzIElQIA0KPj4+PiBhZGRyZXNzLCA+YWxzbyBmb3JjaW5nIHJlLW5lZ290
aWF0aW9uIG9mIERUTFMgc2VjdXJpdHkgYXNzb2NpYXRpb24uICANCj4+Pj4gTGVzcyBmcmVxdWVu
dCB0aGFuIE5BVHMgdGltaW5nIG91dCBVRFAsIG9mIGNvdXJzZS4pDQo+Pj4gDQo+Pj4+IC1kDQo+
Pj4gW1lpbl0gWWVzLCB5b3UgYXJlIHJpZ2h0LiBUaGUgcHJvYmxlbSBpc24ndCBzb2xlbHkgTkFU
IGV4cGlyaW5nLCBidXQgY2hhbmdpbmcgZnJvbSBXTEFOIHRvIDNHUFAsIG9yIElPVCBkZXZpY2Vz
IHdha2luZyB1cCBmcm9tIHNsZWVwIG1vZGUuIEFsbCBvZiB0aGVzZSBjb3VsZCBsZWFkIHRvIElQ
IGNoYW5nZS4NCj4+PiBTZXNzaW9uIHJlc3VtcHRpb24gaXMgYSBnb29kIHdheSB0byByZS1uZWdv
dGlhdGUgdGhlIERUTFMgc2Vzc2lvbi4gSG93ZXZlciwgYWNjb3JkaW5nIHRvIG91ciBJT1QgcHJv
ZHVjdHMsIGUuZy4sIGludGVsbGlnZW50IHdhdGVyL2dhcyBtZXRlciwgc2Vzc2lvbiByZXN1bXB0
aW9uIG1lY2hhbmlzbSBzdGlsbCBuZWVkcyB0byBjb21tdW5pY2F0ZSA2IG9yIDUgbWVzc2FnZXMo
YmFzZWQgb24gdGhlIGNpcGhlciBzdWl0ZSBUTFNfUFNLX1dJVEhfQUVTXzEyOF9DQkNfU0hBMjU2
KSBhbmQgdGhpcyByZS1uZWdvdGlhdGlvbiBtZWNoYW5pc20gc3RpbGwgY29zdHMgdG9vIG11Y2gg
YmF0dGVyeSBhbmQgY2FuIG5vdCBlbnN1cmUgMTAteWVhciBsaWZldGltZSBvZiB0aGUgSU9UIHBy
b2R1Y3RzJyBiYXR0ZXJ5LiANCj4+IA0KPj4+IEkgc2VlIDMgbWVzc2FnZXMgYW5kIG5vIGNyeXB0
b2dyYXBoaWMgb3BlcmF0aW9ucyBmb3IgdGhlIGNsaWVudCBpbiBGaWd1cmUgMiBvZiBodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTA3NyNwYWdlLTUuICBTbyBJIGd1ZXNzIHlvdSdyZSBz
YXlpbmcgdGhlIElvVCBkZXZpY2UgY2FuJ3Qgc2VuZCB0d28gcGFja2V0cyBhbmQgcmVjZWl2ZSBv
bmUgcGFja2V0IHdpdGhvdXQgaW1wYWN0aW5nIGl0cyBiYXR0ZXJ5LiAgSSBhZ3JlZSAnY2lkJyBp
cyBtb3JlIGVmZmljaWVudCwgYnV0IGl0IGlzbid0IHlldCBzdGFuZGFyZGl6ZWQuICBJIHdvdWxk
IGNvbnNpZGVyIGRvaW5nID5SRkM1MDc3IGFuZCB0aGVuLCB3aGVuICdjaWQnIG9yIERUTFMgMS4z
IGlzIGF2YWlsYWJsZSwgdXBkYXRlIHRoZSBkZXZpY2VzIHRvIHN1cHBvcnQgJ2NpZCcgb3IgRFRM
UyAxLjMsIGFzIFNlYW4gaW1wbGllZCB3aGVuIGhlIGFza2VkIGlmIHRoZSBkZXZpY2VzIGNvdWxk
IGJlIHVwZGF0ZWQuDQo+PiANCj4+PiAoSSBob3BlIHRoZSBkZXZpY2VzIGFyZW4ndCB1c2luZyB0
aGUgc2FtZSBwcmUtc2hhcmVkIGtleSEgIFRoYXQgDQo+Pj4gd291bGQgYmUgYmFkLikNCj4+IA0K
Pj4+IC1kDQo+PiBbWWluXSBGaWd1cmUgMiBpcyBUTFMgcmVzdW1wdGlvbi4gRm9yIERUTFMsIHRo
ZXJlIGFyZSAiY2xpZW50aGVsbG8iIGFuZCAiaGVsbG92ZXJpZnlyZXF1ZXN0Ig0KPiANCj4+IEhl
bGxvVmVyaWZ5UmVxdWVzdCBpcyBvbmx5IHNlbnQgaWYgdGhlIERUTFMgc2VydmVyIGlzIGRlZmVu
ZGluZyBpdHNlbGYgZnJvbSBhdHRhY2suICBJIHdvdWxkIGltYWdpbmUgRERvUyBtaXRpZ2F0aW9u
IGNvbXBhbmllcyB3aWxsLCBvciBoYXZlIGFscmVhZHksIGJ1aWx0IERUTFMgZGVmZW5zZXMgdGhh
dCBjYW4gYXZvaWQgc2VuZGluZyB0aGF0IG1lc3NhZ2UgaW4gbWFueSBjYXNlcywgb3Igc3VjaCBs
b2dpYyBjb3VsZCBiZSBpbmNsdWRlZCBhcyBwYXJ0IG9mIGEgcXVhbGl0eSBEVExTIHNlcnZlciBp
bXBsZW1lbnRhdGlvbj8gIA0KPj4gSWYgdGhlIGNsaWVudCBkZXZpY2VzIGFyZSBzbyBzZW5zaXRp
dmUgdG8gc2VuZGluZy9yZWNlaXZpbmcgcGFja2V0cywgDQo+PiBJIHdvdWxkbid0IHdhbnQgdGhl
IHNlcnZlciB0byBjaGFsbGVuZ2UgdGhlbSB3aXRoIEhlbGxvVmVyaWZ5UmVxdWVzdCwgYnV0IGlu
c3RlYWQgYmUgc3VyZSB0aGVyZSBpcyBEb1MgYW5kIEREb1MgbWl0aWdhdGlvbiBvbiB0aGUgc2Vy
dmVyIHRoYXQgZG9lc24ndCBwdXNoIGVmZm9ydCBiYWNrIHRvIHRoZSBjbGllbnRzLiAgQWZ0ZXJh
bGwsIHRoZSBjbGllbnQgc2VudCBhIHBhY2tldCB0aGF0IHRoZSBzZXJ2ZXIgY291bGQgaGF2ZSB2
YWxpZGF0ZWQsIGF0IGNyeXB0b2dyYXBoaWMgY29zdCB0byB0aGUgc2VydmVyLiAgQ3JlYXRpdmUg
ZW5jb2Rpbmcgb2YgdGhhdCBub25jZSBjb3VsZCBhbGxvdyB0aGUgc2VydmVyIHRvIHJlZHVjZSBp
dHMgdmFsaWRhdGlvbiBlZmZvcnQgYW5kIHJlZHVjZSBpdHMgbGlrZWx5aG9vZCBvZiBjaGFsbGVu
Z2luZyB3aXRoIGEgSGVsbG9WZXJpZnlSZXF1ZXN0Lg0KPiANCj4+IGJlZm9yZSB0aGUgcmVzdW1w
dGlvbiBwcm9jZWR1cmUgaW4gRmlndXJlMi4gQW55d2F5LCB0aGUgcmVzdW1wdGlvbiBtZWNoYW5p
c20gaXMgbm90IGVmZmljaWVudCBmb3IgYmF0dGVyeS1jb25zdHJhaW5lZCBJT1QgZGV2aWNlcy4N
Cj4+IEZvciB1cGdyYWRpbmcgcHJvYmxlbSB5b3UgYW5kIFNlYW4gbWVudGlvbmVkLCBwbGVhc2Ug
c2VlIG15IHJlcGx5IGZvciBTZWFuLiANCj4gDQo+PiBUaGFua3MsIEkgZGlkIHJlYWQgdGhhdCBy
ZXBseS4gIFRoZSBkZXZpY2VzIGNhbid0IGJlIHVwZ3JhZGVkLg0KPiANCj4+IC1kDQo+IA0KPiBb
WWluXSBJIGRvbid0IHRoaW5rIHNvLiBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBzZWN1cml0eSwg
dGhlc2UgbWVzc2FnZXMgYXJlIG5lZWRlZC4gRXZlbiB0aGUgY2xpZW50IGRldmljZXMgYXJlIGJh
dHRlcnktY29uc3RyYWluZWQsIHNlY3VyaXR5IGlzIG5lZWRlZCBpbiBEVExTIGFzIHJlcXVpcmVk
IGJ5IG91ciBjdXN0b21lcnMuIA0KPiANCj4+IA0KPj4gDQo+PiANCj4+PiANCj4+Pj4gc3B0DQo+
Pj4+IA0KPj4+Pj4gQW55IGNvbW1lbnQgaXMgYXBwcmVjaWF0ZWQuDQo+Pj4+PiANCj4+Pj4+IFJl
Z2FyZHMsDQo+Pj4+PiBZaW4gWGlueGluZw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IOWPkeS7tuS6
ujogeWlueGlueGluZw0KPj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0NuaciDI35pelIDE2OjI4
DQo+Pj4+PiDmlLbku7bkuro6ICdFcmljIFJlc2NvcmxhJw0KPj4+Pj4g5oqE6YCBOiB0bHNAaWV0
Zi5vcmc7IFRvYmlhcyBHb25kcm9tDQo+Pj4+PiDkuLvpopg6IFJlOiBbVExTXSBZaW4gWGlueGlu
ZyBqb2lucyB0aGUgVExTIFdHDQo+Pj4+PiANCj4+Pj4+IFRoYW5rcyBFcmljLA0KPj4+Pj4gDQo+
Pj4+PiBJIGhhdmUgc2VlbiB0aGUgQ0lEIHNjaGVtZSwgYW5kIHRhbGtlZCB3aXRoIEhhbm5lcyh0
aGUgYXV0aG9yIG9mIHRoZSBzY2hlbWUpLg0KPj4+Pj4gDQo+Pj4+PiBDSUQgc2NoZW1lIGlzIGEg
Z29vZCBpZGVhIHRvIHNvbHZlIHRoZSBwcm9ibGVtIEkgbWVudGlvbmVkLg0KPj4+Pj4gDQo+Pj4+
PiBJIHRoaW5rIHRoZSBsZW5ndGggb2YgQ0lEIChjdXJyZW50bHksIGl0IGlzIDMyIGJpdHMpIGNh
biBiZSBsb25nZXIgc28gdGhhdCBpdCBjYW4gc3VwcG9ydCBtb3JlIERUTFMgc2Vzc2lvbnMuIEl0
IGlzIGtub3duIHRoYXQgZm9yIElPVCBzY2VuYXJpbywgMSBtaWxsaW9uIGNvbm5lY3Rpb24gaXMg
bm90aGluZy4NCj4+Pj4+IA0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+IFlpbiBYaW54aW5nDQo+Pj4+
PiANCj4+Pj4+IOWPkeS7tuS6ujogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0N
Cj4+Pj4+IOWPkemAgeaXtumXtDogMjAxN+W5tDbmnIgyNeaXpSAyMTozMw0KPj4+Pj4g5pS25Lu2
5Lq6OiB5aW54aW54aW5nDQo+Pj4+PiDmioTpgIE6IHRsc0BpZXRmLm9yZzsgWGlvbmd4aWFvY2h1
bg0KPj4+Pj4g5Li76aKYOiBSZTogW1RMU10gWWluIFhpbnhpbmcgam9pbnMgdGhlIFRMUyBXRw0K
Pj4+Pj4gDQo+Pj4+PiBIaSBZaW4sDQo+Pj4+PiANCj4+Pj4+IFRoZSB1c3VhbCBzb2x1dGlvbiB0
byB0aGlzIGlzIHRvIGFkZCBhIGNvbm5lY3Rpb24gaWQuIFBsZWFzZSBzZWU6DQo+Pj4+PiBodHRw
czovL2dpdGh1Yi5jb20vdGxzd2cvZHRsczEzLXNwZWMvaXNzdWVzLzYNCj4+Pj4+IA0KPj4+Pj4g
LUVrcg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBPbiBTdW4sIEp1biAy
NSwgMjAxNyBhdCAyOjMzIEFNLCB5aW54aW54aW5nIDx5aW54aW54aW5nQGh1YXdlaS5jb20+IHdy
b3RlOg0KPj4+Pj4gSGVsbG8gZXZlcnlvbmUsDQo+Pj4+PiANCj4+Pj4+IEkgYW0gWWluIFhpbnhp
bmcgZnJvbSBIdWF3ZWkgY29tcGFueS4gSSBhbSBnbGFkIHRvIGpvaW4gdGhlIFRMUyBXRy4NCj4+
Pj4+IA0KPj4+Pj4gRm9yIHRoZSBETFRTIDEuMyBkcmFmdCwgSSBhbSBpbnRlcmVzdGVkIGFuZCBo
YXZlIHNvbWUgaWRlYXMgdG8gdGFsayB3aXRoIHlvdS4NCj4+Pj4+IA0KPj4+Pj4gRFRMUyBoYXMg
YSBsb3Qgb2YgYXBwbGljYXRpb24gc2NlbmFyaW9zIGluIElPVCBmaWVsZHMsIGJ1dCBjdXJyZW50
bHksIHRoZXJlIGlzIHNvbWUgZGlmZmljdWx0eSB3aGVuIERUTFMgMS4yIGlzIGFwcGxpZWQgdG8g
SU9UIGRldmljZXMsIGVzcGVjaWFsbHkgdGhlIGJhdHRlcnktY29uc3RyYWluZWQgSU9UIGRldmlj
ZXMuDQo+Pj4+PiANCj4+Pj4+IEZvciBleGFtcGxlLCB3aGVuIHRoZSBJT1QgZGV2aWNlIHdha2Vz
IHVwIGZyb20gc2xlZXAgbW9kZSwgdGhlIE5BVCB0YWJsZSBtYXkgaGF2ZSBleHBpcmVkLg0KPj4+
Pj4gVGhlbiB0aGUgSU9UIGRldmljZSBoYXMgdG8gZXN0YWJsaXNoIGEgbmV3IERUTFMgc2Vzc2lv
biBvciBhdCBsZWFzdCBsYXVuY2hlcyBhIHJlc3VtZSBwcm9jZXNzIHdpdGggdGhlIHNlcnZlciwg
dGhlIGNvcnJlc3BvbmRpbmcgcG93ZXIgY29uc3VtcHRpb24gaXMgdG9vIGhpZ2ggZm9yIHNvbWUg
cG93ZXItY29uc3RyYWluZWQgZGV2aWNlcy4gDQo+Pj4+PiBIb3cgY2FuIERUTFMgcmVuZWdvdGlh
dGlvbiBiZSBhdm9pZGVkIGluIG9yZGVyIHRvIHNhdmUgYmF0dGVyeT8NCj4+Pj4+IA0KPj4+Pj4g
SSBob3BlIHRoZSBjb250cmlidXRvcnMgb2YgRFRMUyAxLjMgKG9yIERUTFMgMS4yKSBjYW4gY29u
c2lkZXIgdGhpcyBwcm9ibGVtIGFuZCBnaXZlIGEgcHJvcGVyIHNvbHV0aW9uLiAgDQo+Pj4+PiAN
Cj4+Pj4+IEFueSBjb21tZW50IG9yIGlkZWEgYWJvdXQgdGhpcyBwcm9ibGVtIGlzIHdlbGNvbWUu
DQo+Pj4+PiANCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiBZaW4gWGlueGluZw0KPj4+Pj4gDQo+Pj4+
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4g
VExTIG1haWxpbmcgbGlzdA0KPj4+Pj4gVExTQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBUTFMgbWFp
bGluZyBsaXN0DQo+Pj4+PiBUTFNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdGxzDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBUTFMgbWFpbGluZyBsaXN0DQo+Pj4+IFRM
U0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs
cw0KPj4+IA0KPj4gDQo+IA0KDQo=


From nobody Tue Jul 18 20:42:30 2017
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 A38D012EAA5 for ; Tue, 18 Jul 2017 20:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 JnsA6vR4Lftb for ; Tue, 18 Jul 2017 20:42:26 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 3A9C412783A for ; Tue, 18 Jul 2017 20:42:26 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id o88so14383809pfk.3 for ; Tue, 18 Jul 2017 20:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=z20/5ftQrcISiWQ7TB3T2Sdgc/Rfm0ouHMZGqmUJMJ0=; b=NM1/tKUD3MLL5YXA+r1c1y0+SjBShhobE4jvbZodIa2ywsTZ1Qb+xcaswXOFOHxElU Qafw03gxMbF7q+wNaRUmf42cdSEBXOrJUFyzjDqXhGbAH/55nvBJL8WGChax1SoKAY+n IeLZ8cittfCIk+WQn/yM4LrJIjdI3Cw6GvVkz93TQ3ClXfJk2eSPgfXrsnf2qUQ7iPPq laGG7ghlPNV97DRcOSDXHtY/ptwkI6yZsOHxJ/c2Zpd9zObbDq0ZI6aNLewMQKThmlLo 6J9roLawsUxl4Xus2DGTBn4hrrwpJqPOVNxNv/tv3yguKeG5UFxbolkY83q1HcQtO3RO 7lWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=z20/5ftQrcISiWQ7TB3T2Sdgc/Rfm0ouHMZGqmUJMJ0=; b=iaSIoKeOSDcNS+Lt+p2Ido17paZxkDkprEAO6kKeXrKXBbL82LOpAGeiDMklIpATYG N55FNCKhX4sBg+U95hm+DBYV6yveE3y3mHBlWEzKYavJn+gQfjkUGjWM6nL275Y7FCFZ Rjea05myVad4CQAKAxKO/W6x92bGs0b9C8nmz1LLeSkSmZPgXceSxgCoUINGJ7xgGIqn 41sOpz81ndI1gn8PFzMC+pNw6J0BrFL5SyfApSBL3mt5fA+KNJOadmJW1Zqdv6q3RwtC 0DoC4hNbK0SqK0OOG/LDGFuORnpauZHS8vBstr6O3fQU8/IF2s+qMlior4AfxKc6S2Yq n7AQ==
X-Gm-Message-State: AIVw1131ji52gTY4yfpfsXokyg6k9q57GXa3ElWyb4U62vY6rpHUWuF6 a/PgoINTdnhLg74CfCN4Yz/+WlyAoA==
X-Received: by 10.99.184.2 with SMTP id p2mr938708pge.194.1500435745609; Tue, 18 Jul 2017 20:42:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.3 with HTTP; Tue, 18 Jul 2017 20:42:24 -0700 (PDT)
In-Reply-To: <150043553129.25392.13213180786681889232.idtracker@ietfa.amsl.com>
References: <150043553129.25392.13213180786681889232.idtracker@ietfa.amsl.com>
From: Kazuho Oku 
Date: Wed, 19 Jul 2017 05:42:24 +0200
Message-ID: 
To: "" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 03:42:29 -0000

Hi,

I am happy to see us having discussions on how to protected SNI. I am
also happy to see that draft-huitema-tls-sni-encryption [1] proposes
actual methods that we might want to use, and that the I-D discusses
about various attack vectors that we need to be aware of.

On the other hand, as stated on the mailing list an on the mic, I am
not super happy with the fact that the proposed methods have a
negative impact on connection establishment time.

So here goes my straw-man proposal, as an Internet Draft:
https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.

In essence, the draft proposes of sending information (e.g.,
semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.

Since DNS queries can run in parallel, there would be no negative
performance impact, as long as DNS responses can be obtained in a
single RTT.

The draft mainly discusses about sending a signed bootstrap
information together with the certificate chain, since doing so is not
only more secure but opens up other possibilities in the future (such
as 0-RTT full handshake). However, since transmitting a bootstrap
record with digital signature and identity is unlikely to fit in a
single packet (and therefore will have negative performance impact
until DNS over TLS or QUIC becomes popular), the draft also discusses
the possibility of sending the EC(DH) key unsigned in the "Things to
Consider" section.

I would appreciate it if you could give me comments / suggestions on
the proposed approach. Thank you in advance.

[1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/


---------- Forwarded message ----------
From:  
Date: 2017-07-19 5:38 GMT+02:00
Subject: New Version Notification for draft-kazuho-protected-sni-00.txt
To: Kazuho Oku 



A new version of I-D, draft-kazuho-protected-sni-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name:           draft-kazuho-protected-sni
Revision:       00
Title:          TLS Extensions for Protecting SNI
Document date:  2017-07-19
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/
Htmlized:       https://tools.ietf.org/html/draft-kazuho-protected-sni-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00


Abstract:
   This memo introduces TLS extensions and a DNS Resource Record Type
   that can be used to protect attackers from obtaining the value of the
   Server Name Indication extension being transmitted over a Transport
   Layer Security (TLS) version 1.3 handshake.




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.

The IETF Secretariat



-- 
Kazuho Oku


From nobody Tue Jul 18 21:03:34 2017
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 20EC0127076 for ; Tue, 18 Jul 2017 21:03: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GMV4z6iPUhk for ; Tue, 18 Jul 2017 21:03:31 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 4857D126D85 for ; Tue, 18 Jul 2017 21:03:31 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id y70so4061732vky.3 for ; Tue, 18 Jul 2017 21:03:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EVpOgr+W7ZJyK7EmBBOWRYakeQupul4/Qlp0JAbLtP0=; b=h4nUJciGhEqlAyhzJhyYwlN55HAglvFooAlAh5s4omyxIOkF4wm1KfG+sKTqzsBFaW YtebpAYAszomV2V5b8/NA1lGARCEAgaoLDexsWmOrdu/7VxHsERlorp/2f0bvNqEIO1U B0oSCNweyGY2bZCQuvnrhNi8/Mbqb1fS/FX1E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EVpOgr+W7ZJyK7EmBBOWRYakeQupul4/Qlp0JAbLtP0=; b=PbveClZBMnF6MQ2rdJZTol8gfHddI+TQLF6HhMImmKyoFZGcgWxhqGg0w4GP4dNegg 9TqmrUJTEzhVZXBM6/lt3qHhTpc8qPAH/TMoII7ChjenwezumDEamHgTJeSMlb6Mk2W5 +8jfOMblBvNdnF6h4xz6Lt/ypqkHHk3S7nSHoT/TlCcFNbZGOdwLFNRIcFU5czO0ekXG yFvHPa5CM9BzrfucUXaCj1NULlp4/+CuEJvkHMn9fQpzGyZrC4aamOkjCr/Ghc9vCcih zWcSXVin3sKYKMvXUx8z6etbVTnacgUeN5Ft5f74E8hAzUC9JBO5+eO+V87xOKqQinWs jdkg==
X-Gm-Message-State: AIVw112/2Lg5g8vnlBRkTb2ZJypBFEcthH9lbB+Z8JWJ4spsbs5w7ZHH N8Eaky1xBuAGqgQ7gbxhjH4A5iTlOoWB
X-Received: by 10.31.107.136 with SMTP id k8mr411392vki.82.1500437010010; Tue, 18 Jul 2017 21:03:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.195 with HTTP; Tue, 18 Jul 2017 21:03:09 -0700 (PDT)
In-Reply-To: 
References: <150043553129.25392.13213180786681889232.idtracker@ietfa.amsl.com> 
From: Tom Ritter 
Date: Tue, 18 Jul 2017 23:03:09 -0500
Message-ID: 
To: Kazuho Oku 
Cc: "" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 04:03:33 -0000

If I remember correctly, the idea of enabling SNI encryption (and
0RTT) via DNS had been brought up very early on in the discussion.
draft-nygren-service-bindings was the first (only? major?) concrete
proposal.

In general, I think the feedback was "DNS gets filtered to only
A/CNAME records so frequently that anything that relies on other DNS
records isn't going to work an appreciable portion of the time".

I'm disappointed by this also; but as we are also trying to deploy DNS
privacy - mechanisms that rely on an easily surveilled, censored, or
blocked mechanism to enable other sorts of privacy are concerning.

-tom


On 18 July 2017 at 22:42, Kazuho Oku  wrote:
> Hi,
>
> I am happy to see us having discussions on how to protected SNI. I am
> also happy to see that draft-huitema-tls-sni-encryption [1] proposes
> actual methods that we might want to use, and that the I-D discusses
> about various attack vectors that we need to be aware of.
>
> On the other hand, as stated on the mailing list an on the mic, I am
> not super happy with the fact that the proposed methods have a
> negative impact on connection establishment time.
>
> So here goes my straw-man proposal, as an Internet Draft:
> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.
>
> In essence, the draft proposes of sending information (e.g.,
> semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.
>
> Since DNS queries can run in parallel, there would be no negative
> performance impact, as long as DNS responses can be obtained in a
> single RTT.
>
> The draft mainly discusses about sending a signed bootstrap
> information together with the certificate chain, since doing so is not
> only more secure but opens up other possibilities in the future (such
> as 0-RTT full handshake). However, since transmitting a bootstrap
> record with digital signature and identity is unlikely to fit in a
> single packet (and therefore will have negative performance impact
> until DNS over TLS or QUIC becomes popular), the draft also discusses
> the possibility of sending the EC(DH) key unsigned in the "Things to
> Consider" section.
>
> I would appreciate it if you could give me comments / suggestions on
> the proposed approach. Thank you in advance.
>
> [1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/
>
>
> ---------- Forwarded message ----------
> From:  
> Date: 2017-07-19 5:38 GMT+02:00
> Subject: New Version Notification for draft-kazuho-protected-sni-00.txt
> To: Kazuho Oku 
>
>
>
> A new version of I-D, draft-kazuho-protected-sni-00.txt
> has been successfully submitted by Kazuho Oku and posted to the
> IETF repository.
>
> Name:           draft-kazuho-protected-sni
> Revision:       00
> Title:          TLS Extensions for Protecting SNI
> Document date:  2017-07-19
> Group:          Individual Submission
> Pages:          9
> URL:
> https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/
> Htmlized:       https://tools.ietf.org/html/draft-kazuho-protected-sni-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00
>
>
> Abstract:
>    This memo introduces TLS extensions and a DNS Resource Record Type
>    that can be used to protect attackers from obtaining the value of the
>    Server Name Indication extension being transmitted over a Transport
>    Layer Security (TLS) version 1.3 handshake.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
> --
> Kazuho Oku
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Jul 18 21:50:03 2017
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 0E11F12EA74 for ; Tue, 18 Jul 2017 21:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KcROW-faYjkV for ; Tue, 18 Jul 2017 21:50:00 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AE812EB5F for ; Tue, 18 Jul 2017 21:49:59 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id 125so930087pgi.3 for ; Tue, 18 Jul 2017 21:49:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jQh4pcl0Capv4KvrRZgrwyrQ3fPmRg8WH6CvRAxuBmk=; b=kU6XnBTk2+SmNKGbm0SW/3YEZ3y/MLhdXq79mYa/1067QJEqGA1ARKCYLf2rXmCTAu hda6OVG5GyIgdsQitseHqWjpTn821lGzbXz4sa5VvwjhcKYQdMAJGUJL4K6X6ol2Akbz mdHSxXhrvmpYkrgowJVRt0vZUINYW5JSBJqKgKnuYugYxJVSBXVBF+Ht2/pjBoyHfBon aBXbxABnnWY6vHABFdP/jz7c91ncfMDbwNbNUTYgrhyS/V6G2dibNnZ7kRPEYDZc0a2z dMz7WZvMXT4vBqM30xyx782Edu9yq8z81Als5MZMI0LWlvZWIrFrp9rCEvgHMkgR0OUh arMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jQh4pcl0Capv4KvrRZgrwyrQ3fPmRg8WH6CvRAxuBmk=; b=k3DAgPZqQlZ3/0f+9ZS2eEAiDSZXeVTEpJtSIvc/dFIkGBOaswI8tJKG5Iiqcge/Fg 680PxcJ8d5llliyhz1uI1I3gEhRWs7ILDLfBA+808or0dZJXQqjH1eh9/xKoX/Nm0x40 KDwEHrQ7r9tIVsba3M0g8kR1HnbN5Smttbgc12rGDHP/YkqdsfONHvuoRyxxudp7OP+9 lplKX08g9U3dhAriMfkiQ/FRVVVVJb4wJ45VxoM5+5C+CXnXrbFYW3KtA4SMflxaR2Lr j5sftgo/wNFhAtdXPLbE7xDGKnUMn3L+ZMugYf0eGdLwIuz2PmFjHW1qGNW0bsZjGPZK 4pHg==
X-Gm-Message-State: AIVw111hU14SdgZ68qnkyHIsRtDf4SKt+WuRbby9DdctFUQ+gmYmwfdM xZc7anjJg4mYEKD/qykC42+kjW5ZaA7T
X-Received: by 10.99.98.71 with SMTP id w68mr1179372pgb.100.1500439799353; Tue, 18 Jul 2017 21:49:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.3 with HTTP; Tue, 18 Jul 2017 21:49:58 -0700 (PDT)
In-Reply-To: 
References: <150043553129.25392.13213180786681889232.idtracker@ietfa.amsl.com>  
From: Kazuho Oku 
Date: Wed, 19 Jul 2017 06:49:58 +0200
Message-ID: 
To: Tom Ritter 
Cc: "" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 04:50:02 -0000

Hi,

Thank you for the response.

I was not aware that the penetration rates of minor DNS records were
low. I will read the I-D and the mailing list archive.

OTOH, I think that the penetration rate being low might not be a
killer for the proposal, since in the short term, SNI encryption can
be an opportunistic feature, considering the fact that DNS packets
will be sent in cleartext anyways.

It might be possible to query for the A record and the bootstrap
record simultaneously and activate SNI protection only if responses to
both queries are obtained.

2017-07-19 6:03 GMT+02:00 Tom Ritter :
> If I remember correctly, the idea of enabling SNI encryption (and
> 0RTT) via DNS had been brought up very early on in the discussion.
> draft-nygren-service-bindings was the first (only? major?) concrete
> proposal.
>
> In general, I think the feedback was "DNS gets filtered to only
> A/CNAME records so frequently that anything that relies on other DNS
> records isn't going to work an appreciable portion of the time".
>
> I'm disappointed by this also; but as we are also trying to deploy DNS
> privacy - mechanisms that rely on an easily surveilled, censored, or
> blocked mechanism to enable other sorts of privacy are concerning.
>
> -tom
>
>
> On 18 July 2017 at 22:42, Kazuho Oku  wrote:
>> Hi,
>>
>> I am happy to see us having discussions on how to protected SNI. I am
>> also happy to see that draft-huitema-tls-sni-encryption [1] proposes
>> actual methods that we might want to use, and that the I-D discusses
>> about various attack vectors that we need to be aware of.
>>
>> On the other hand, as stated on the mailing list an on the mic, I am
>> not super happy with the fact that the proposed methods have a
>> negative impact on connection establishment time.
>>
>> So here goes my straw-man proposal, as an Internet Draft:
>> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.
>>
>> In essence, the draft proposes of sending information (e.g.,
>> semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
>> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.
>>
>> Since DNS queries can run in parallel, there would be no negative
>> performance impact, as long as DNS responses can be obtained in a
>> single RTT.
>>
>> The draft mainly discusses about sending a signed bootstrap
>> information together with the certificate chain, since doing so is not
>> only more secure but opens up other possibilities in the future (such
>> as 0-RTT full handshake). However, since transmitting a bootstrap
>> record with digital signature and identity is unlikely to fit in a
>> single packet (and therefore will have negative performance impact
>> until DNS over TLS or QUIC becomes popular), the draft also discusses
>> the possibility of sending the EC(DH) key unsigned in the "Things to
>> Consider" section.
>>
>> I would appreciate it if you could give me comments / suggestions on
>> the proposed approach. Thank you in advance.
>>
>> [1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/
>>
>>
>> ---------- Forwarded message ----------
>> From:  
>> Date: 2017-07-19 5:38 GMT+02:00
>> Subject: New Version Notification for draft-kazuho-protected-sni-00.txt
>> To: Kazuho Oku 
>>
>>
>>
>> A new version of I-D, draft-kazuho-protected-sni-00.txt
>> has been successfully submitted by Kazuho Oku and posted to the
>> IETF repository.
>>
>> Name:           draft-kazuho-protected-sni
>> Revision:       00
>> Title:          TLS Extensions for Protecting SNI
>> Document date:  2017-07-19
>> Group:          Individual Submission
>> Pages:          9
>> URL:
>> https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/
>> Htmlized:       https://tools.ietf.org/html/draft-kazuho-protected-sni-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00
>>
>>
>> Abstract:
>>    This memo introduces TLS extensions and a DNS Resource Record Type
>>    that can be used to protect attackers from obtaining the value of the
>>    Server Name Indication extension being transmitted over a Transport
>>    Layer Security (TLS) version 1.3 handshake.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
>>
>>
>> --
>> Kazuho Oku
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls



-- 
Kazuho Oku


From nobody Tue Jul 18 22:05:22 2017
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 BA14C126CC4 for ; Tue, 18 Jul 2017 22:05:20 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 SNdCnfzGhd-b for ; Tue, 18 Jul 2017 22:05:18 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5AF124217 for ; Tue, 18 Jul 2017 22:05:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 35CDA391DE; Wed, 19 Jul 2017 08:05:16 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 0mIDtUfCwMjb; Wed, 19 Jul 2017 08:05:15 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id A17E921C; Wed, 19 Jul 2017 08:05:13 +0300 (EEST)
Date: Wed, 19 Jul 2017 08:05:13 +0300
From: Ilari Liusvaara 
To: Kazuho Oku 
Cc: "" 
Message-ID: <20170719050513.2e6v4w3fkdg2q26y@LK-Perkele-VII>
References: <150043553129.25392.13213180786681889232.idtracker@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 05:05:21 -0000

On Wed, Jul 19, 2017 at 05:42:24AM +0200, Kazuho Oku wrote:
> Hi,
> 
> I am happy to see us having discussions on how to protected SNI. I am
> also happy to see that draft-huitema-tls-sni-encryption [1] proposes
> actual methods that we might want to use, and that the I-D discusses
> about various attack vectors that we need to be aware of.
> 
> On the other hand, as stated on the mailing list an on the mic, I am
> not super happy with the fact that the proposed methods have a
> negative impact on connection establishment time.
> 
> So here goes my straw-man proposal, as an Internet Draft:
> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.

At least that method does not obviously vulernable to replay. However,
it has multitude of other problems:

> In essence, the draft proposes of sending information (e.g.,
> semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.

There are multiple problems with use of DNS:

- Individual DNS records can be at most 64kB.
- The whole DNS reply can be at most 64kB.
- In practice, exceeding about 1200 bytes for response starts
  causing problems with DNSoDTLS (there is a fallback to DNSoTLS,
  but it is not very pleasant).
- The textual representation starts getting unpleasant way before
  that.
- DNS records are defined to have textual and wire formats. Using TLS
  notation would be pretty great for latter, but not good for the
  former.

> Since DNS queries can run in parallel, there would be no negative
> performance impact, as long as DNS responses can be obtained in a
> single RTT.

Unfortunately, this is not quite true:

- Packets can get lost, and DNS retransmissions are fairly slow.
- There are lots of horked DNS servers that respond in all sorts of
  bad ways (including timing out, or sending utterly bogus error
  codes) to unknown RRTypes, especially if the RRType number is
  above 255 (but bad servers that do that to any RRType they do
  not know about still exist).

(And let's also ignore difficulties in adding new RRTypes, despite
RFC3597 being almost 14 years old, and covering almost everything that
has been added (one needs extra justfication for breaking RFC3597-
complatiblity[1]).)


[1] In practicular, following kinds of things break RFC3597:

- Compressing RRDATA with reference to rest of the DNS message (e.g.,
  DNS name compression).
- Requiring any kinds of transofrmations on the data in path between
  the master file and the end application.

> The draft mainly discusses about sending a signed bootstrap
> information together with the certificate chain, since doing so is not
> only more secure but opens up other possibilities in the future (such
> as 0-RTT full handshake). However, since transmitting a bootstrap
> record with digital signature and identity is unlikely to fit in a
> single packet (and therefore will have negative performance impact
> until DNS over TLS or QUIC becomes popular), the draft also discusses
> the possibility of sending the EC(DH) key unsigned in the "Things to
> Consider" section.

There is not much space in DNS records for anything bigger than one
ECDH key per record (but there is space for a few records of that
kind).


-Ilari


From nobody Wed Jul 19 01:37:26 2017
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 5BCDE131C37 for ; Wed, 19 Jul 2017 01:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7X4lEBgl-ywm for ; Wed, 19 Jul 2017 01:37:22 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 1642B131C2F for ; Wed, 19 Jul 2017 01:37:22 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id s70so15038490pfs.0 for ; Wed, 19 Jul 2017 01:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gYTPtIHL9i0G1/lweZgMR82ut1Rb18oARn9z6vMjG8Y=; b=M8GAda27ZeKmL3D2PIzTBOZqfRR4N7Bd+fZGa5jPmpPmWO1ViAKELIoKdKJ4wRn2R5 h6pgvOl/zx/159jVGYAMT3jbpw4zOyND9bvAUYtNNAnZRa7Lq66TuFbkWsDaKVxweAId ZNhPzlyYadInvZVlpZLgRy/VfApuZSenMrOj7C7meqfXj4/sUTf4G7Ini8DpQ9S2M+jx YBpNVNo/6KfOOvOFLEv5n95xysCmFHTXvZZ2ZzW8JXcSIpz91UsgJ86ccd+dTy1cfn7/ sQBZkW0UbOs8vlw/w4p8Zx2DCHHJ0r2n6zc+wuqYZDiiJHM28WWf17TwLZK0PbSwGAC1 DlZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gYTPtIHL9i0G1/lweZgMR82ut1Rb18oARn9z6vMjG8Y=; b=qhNngE1FvmlSqAQsUBNzdm6uFxqV2bnZTRW8JCpWLlhGgLZHuunZbUoglQOA5cBP4g +tG+pWV6gdKfO9nLfsWECBKgiISt/0yqg7gzICQftBDHPBLp8P+e0cjRBb3e1ishR278 EQHWnq8O1BdMTVDV+fOapU+V6wYawGDuP/MXVTSxwR0CF/yExYshXre1SLiRer/GwYms rDH0GcisjGf5Pz7H1h/TgbJOcKXqWHbNkHp/5GyKeUZu6qhn8CouQbbbqHFVrmyECCLd D1Gt4HtNV+CgFQznH732xdb/U+K0GLZvHQuH5/88XAPG+ytIMmxnblegIuKI2oa0cv/e EPvQ==
X-Gm-Message-State: AIVw113nNC52ECziHL2M7Q3p7sYWEyEdweRFADn1kRXxjTzZih7pDCiy UL4wt3uQ+zCC5vebIdmWMiOfgByWsQ==
X-Received: by 10.98.42.4 with SMTP id q4mr1865109pfq.143.1500453441516; Wed, 19 Jul 2017 01:37:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.3 with HTTP; Wed, 19 Jul 2017 01:37:20 -0700 (PDT)
In-Reply-To: <20170719050513.2e6v4w3fkdg2q26y@LK-Perkele-VII>
References: <150043553129.25392.13213180786681889232.idtracker@ietfa.amsl.com>  <20170719050513.2e6v4w3fkdg2q26y@LK-Perkele-VII>
From: Kazuho Oku 
Date: Wed, 19 Jul 2017 10:37:20 +0200
Message-ID: 
To: Ilari Liusvaara 
Cc: "" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 08:37:24 -0000

Hi,

Thank you for your comments.

2017-07-19 7:05 GMT+02:00 Ilari Liusvaara :
> On Wed, Jul 19, 2017 at 05:42:24AM +0200, Kazuho Oku wrote:
>> Hi,
>>
>> I am happy to see us having discussions on how to protected SNI. I am
>> also happy to see that draft-huitema-tls-sni-encryption [1] proposes
>> actual methods that we might want to use, and that the I-D discusses
>> about various attack vectors that we need to be aware of.
>>
>> On the other hand, as stated on the mailing list an on the mic, I am
>> not super happy with the fact that the proposed methods have a
>> negative impact on connection establishment time.
>>
>> So here goes my straw-man proposal, as an Internet Draft:
>> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.
>
> At least that method does not obviously vulernable to replay. However,
> it has multitude of other problems:
>
>> In essence, the draft proposes of sending information (e.g.,
>> semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
>> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.
>
> There are multiple problems with use of DNS:
>
> - Individual DNS records can be at most 64kB.
> - The whole DNS reply can be at most 64kB.
> - In practice, exceeding about 1200 bytes for response starts
>   causing problems with DNSoDTLS (there is a fallback to DNSoTLS,
>   but it is not very pleasant).

Yes. It is very unlikely that a TLS bootstrap record that contains a
signature and a certificate chain will fit into a single packet, hence
there would be a performance penalty if DNS over DTLS that fallback to
TLS is used.

I have had DNS over QUIC in mind when writing the draft, and I might
say that the draft (especially the mode that bootstraps the _signed_
signature) is written under the premise that DNS over QUIC will become
popular in the future.

> - The textual representation starts getting unpleasant way before
>   that.
> - DNS records are defined to have textual and wire formats. Using TLS
>   notation would be pretty great for latter, but not good for the
>   former.

Generally speaking, for the following two reasons, I prefer having a
TLS structure that defines how a bootstrap information should be
encoded, and then have a DNS record type that conveys the information.

First reason is because the certificate chain and the signature that
signs the EC(DH) keys ideally should be validated the same way as we
do with the server certificates transmitted within a TLS handshake. It
would make sense to just convey certain extensions that affect the
behavior of validation (e.g., OCSP stapling extension) as-is, rather
than trying to come with corresponding textual representations.

Second reason is that we might want to transmit the bootstrap record
using something other than DNS.

>> Since DNS queries can run in parallel, there would be no negative
>> performance impact, as long as DNS responses can be obtained in a
>> single RTT.
>
> Unfortunately, this is not quite true:
>
> - Packets can get lost, and DNS retransmissions are fairly slow.
> - There are lots of horked DNS servers that respond in all sorts of
>   bad ways (including timing out, or sending utterly bogus error
>   codes) to unknown RRTypes, especially if the RRType number is
>   above 255 (but bad servers that do that to any RRType they do
>   not know about still exist).

If DNS over QUIC (or TLS) is used to transfer a signed bootstrap
record with a certificate chain, the amount of data that is sent (in
sum of DNS query and TLS handshake) will be roughly the same, assuming
that Cached Information Extension (RFC7924) is used. Therefore, I
believe that the performance will be roughly the same even when taking
packet loss into consideration.

If UDP-based DNS protocol is used to transfer a signed bootstrap
record with a certificate chain, the DNS query needs to fallback to
TCP, since the record does not fit into a single packet. That means
that it would never be possible to obtain the DNS response in 1 RTT in
such case.

If UDP-based DNS protocol is used to transfer a bootstrap record
without a sign or a certificate chain, then the question will be how
high the probability will be in the following two cases: lose more
than 1 packet within 2 packets vs. lose more than 1 packet within 4
packets. I agree that amortized performance will be worse for the
latter.

> (And let's also ignore difficulties in adding new RRTypes, despite
> RFC3597 being almost 14 years old, and covering almost everything that
> has been added (one needs extra justfication for breaking RFC3597-
> complatiblity[1]).)
>
>
> [1] In practicular, following kinds of things break RFC3597:
>
> - Compressing RRDATA with reference to rest of the DNS message (e.g.,
>   DNS name compression).
> - Requiring any kinds of transofrmations on the data in path between
>   the master file and the end application.
>
>> The draft mainly discusses about sending a signed bootstrap
>> information together with the certificate chain, since doing so is not
>> only more secure but opens up other possibilities in the future (such
>> as 0-RTT full handshake). However, since transmitting a bootstrap
>> record with digital signature and identity is unlikely to fit in a
>> single packet (and therefore will have negative performance impact
>> until DNS over TLS or QUIC becomes popular), the draft also discusses
>> the possibility of sending the EC(DH) key unsigned in the "Things to
>> Consider" section.
>
> There is not much space in DNS records for anything bigger than one
> ECDH key per record (but there is space for a few records of that
> kind).

Agreed.

>
> -Ilari



-- 
Kazuho Oku


From nobody Wed Jul 19 06:10:02 2017
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 572A7131C71 for ; Wed, 19 Jul 2017 06:10:00 -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=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 sBY-ymDpuZuK for ; Wed, 19 Jul 2017 06:09:59 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 1E6BD131B42 for ; Wed, 19 Jul 2017 06:09:59 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6JD0SoH007785 for ; Wed, 19 Jul 2017 14:09:57 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=to : from : subject : message-id : date : mime-version : content-type; s=jan2016.eng; bh=JV/2tZ3fxM8xN0rLY1PKoqmOOZap1ZbAje93LSsdJjI=; b=M5/BsfdinuPuW0XoIZxZqltH8ENnzsZEE5BFXbHNfoEZMMlLrq+3aVHstP49gLvCXSg6 AmqeoCF/g0rJNhXI16F+D7tqbcFGFdVGJ5Qi4gC9LWr3AwVcNbpMNTKiKpeHEsN2OeZh CM60/lunwJNjCRZWG0KlEyUkNX2RWPb3PED3RI9BLj/szUq9dJMkK6004GoC7gh1lEO3 ITUv/cT7L3swvaAmqk31I/vJP3hdnGhqcD4/4rcU4qO1kdjzitDt1NodbqVP1hC9wCF7 YGZVtitG975B0O1mIg/LRzHfW52iraNzY9Vd75FKDMClWfBzp//RQRUKzBRUMaamPtv1 DQ== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2bs7vsf2df-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 19 Jul 2017 14:09:57 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6JD6IqJ025467 for ; Wed, 19 Jul 2017 09:09:55 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecuv698-1 for ; Wed, 19 Jul 2017 09:09:55 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 741131FCAD for ; Wed, 19 Jul 2017 13:09:55 +0000 (GMT)
To: "" 
From: Benjamin Kaduk 
Message-ID: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
Date: Wed, 19 Jul 2017 08:09:55 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------1667CDA4696770A730CCDF37"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707190213
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707190211
Archived-At: 
Subject: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 13:10:00 -0000

This is a multi-part message in MIME format.
--------------1667CDA4696770A730CCDF37
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

As Stephen noted in his presentation, a lot of the proposals for passive
decryption can be seen as trying to turn TLS from a two-party protocol
into a three-party protocol.  Which is probably the right way to think
about it, even when all (three) parties are within the same
administrative domain.

Stephen also said something about it being hard to shoehorn a
three-party protocol into the API for a two party protocol.  But
depending on the specifics, maybe it's not so bad.  For example, if the
only semantics you need are a new API for "this is the list of third
parties I authorize to wiretap this connection", the scope seems fairly
limited.

Another thought spawned from today's session is that, given concerns
about preventing/noticing if schemes intended for the datacenter leak
out onto the internet, it's not really clear that "minimizes changes to
the wire protocol" should be considered a benefit of proposals in this
space.  If there are clear changes to the wire protocol, that makes it
easy to detect when the scheme is in use.

-Ben

--------------1667CDA4696770A730CCDF37
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    As Stephen noted in his presentation, a lot of the proposals for
      passive decryption can be seen as trying to turn TLS from a
      two-party protocol into a three-party protocol.  Which is probably
      the right way to think about it, even when all (three) parties are
      within the same administrative domain.

      

      Stephen also said something about it being hard to shoehorn a
      three-party protocol into the API for a two party protocol.  But
      depending on the specifics, maybe it's not so bad.  For example,
      if the only semantics you need are a new API for "this is the list
      of third parties I authorize to wiretap this connection", the
      scope seems fairly limited.

      

      Another thought spawned from today's session is that, given
      concerns about preventing/noticing if schemes intended for the
      datacenter leak out onto the internet, it's not really clear that
      "minimizes changes to the wire protocol" should be considered a benefit
      of proposals in this space.  If there are clear changes to the
      wire protocol, that makes it easy to detect when the scheme is in
      use.

      

      -Ben

    
  


--------------1667CDA4696770A730CCDF37--


From nobody Wed Jul 19 06:44:21 2017
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 C6327131CA7 for ; Wed, 19 Jul 2017 06:44:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 opadMY1w7NeR for ; Wed, 19 Jul 2017 06:44:17 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 EA4D0131C7E for ; Wed, 19 Jul 2017 06:44:16 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id 123so524590pgj.1 for ; Wed, 19 Jul 2017 06:44:16 -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=yOp+2obZrPTFOW/SckPkeiYzlupsVohaoElKL9S9Nfg=; b=UlQZFcynhX/+8E8gNZLhYWtN8pDmTGJfw6c+bETfqavHG8cn0NaXlaLhND0FHxyWma LHZxHe7ZTm+2OjnSMSq64T1jpejU8ARLKfS1emZceZhA3JGsH1F8kdpWY2Gw10p4gXjp Q1BT2s2+KvZs6cq+ftFvL3CCjkd10LUJNTdx0sCdRZaRCx93ximXSMkHL6ia2YA6KNON aeWBJEkYMmfQ1ItRGqOwDhX9z5DvLlJHeAxURyarE8P4bZ1QyY47p/gtbTjjsQhhpYxw v3ZhbbAJszrM9puKnR8bN7bRowqyM4JxxwDMAkP/aKsLWggfM0GC2ObMynQhM4a5HTg+ Ay4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yOp+2obZrPTFOW/SckPkeiYzlupsVohaoElKL9S9Nfg=; b=gjyiMXYdqWcaqlLSqRxocFQzVajlOzaEd5lkyvx6NKdF9MBrmvXWeXMId4VsOM//xW US5AWUVlpmKCC0Iq8CZjzBh+q5VPdM/WzEyGHtpGjIU/dxVQLP8Ey8L1Vabd4adm3aFk B9yowfGnTs5v0Qc8CDa44Xd8QsWdIsHkFdx7IN1uwNy4QLvW1p1ApehEeyFE/e7ydCvv 3WPm+uRJ48gYN+kgiTttel2BBLEfBIm3aLgsmgWtwK4xTIgr5RRUWH5r42c0lbd0mYzA QMUwWIKB5qtvp1oEhz4eEUUYk69W/nxWy5FxsQK/2m5jqHihjJc8Epjnp2Sty/eiTXkC aYlw==
X-Gm-Message-State: AIVw112SVv/aS51dguHy+u6T/U5Wc1mNtnfNKgrX6vJC2nxLg8CoRyo8 QdF6FwGrTfXlyPIlTQTSlpnt8oa9Ry9R
X-Received: by 10.101.91.203 with SMTP id o11mr162684pgr.206.1500471856561; Wed, 19 Jul 2017 06:44:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 06:43:36 -0700 (PDT)
In-Reply-To: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
From: Ted Lemon 
Date: Wed, 19 Jul 2017 15:43:36 +0200
Message-ID: 
To: Benjamin Kaduk 
Cc: "" 
Content-Type: multipart/alternative; boundary="089e082342e4018aee0554abd4d4"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 13:44:20 -0000

--089e082342e4018aee0554abd4d4
Content-Type: text/plain; charset="UTF-8"

This is exactly right.   We have a *real* problem here.   We should *really*
solve it.   We should do the math.   :)

On Wed, Jul 19, 2017 at 3:09 PM, Benjamin Kaduk  wrote:

> As Stephen noted in his presentation, a lot of the proposals for passive
> decryption can be seen as trying to turn TLS from a two-party protocol into
> a three-party protocol.  Which is probably the right way to think about it,
> even when all (three) parties are within the same administrative domain.
>
> Stephen also said something about it being hard to shoehorn a three-party
> protocol into the API for a two party protocol.  But depending on the
> specifics, maybe it's not so bad.  For example, if the only semantics you
> need are a new API for "this is the list of third parties I authorize to
> wiretap this connection", the scope seems fairly limited.
>
> Another thought spawned from today's session is that, given concerns about
> preventing/noticing if schemes intended for the datacenter leak out onto
> the internet, it's not really clear that "minimizes changes to the wire
> protocol" should be considered a benefit of proposals in this space.  If
> there are clear changes to the wire protocol, that makes it easy to detect
> when the scheme is in use.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--089e082342e4018aee0554abd4d4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This is exactly right. =C2=A0 We have a real proble=
m here. =C2=A0 We should really solve it. =C2=A0 We should do the ma=
th. =C2=A0 :)

On Wed, Jul 19, 2017 at 3:09 PM, Benjamin Kaduk <bkaduk@akamai.com&g=
t; wrote:

 =20

   =20
 =20
  

    As Stephen noted in his presentation, a lot of the proposals for
      passive decryption can be seen as trying to turn TLS from a
      two-party protocol into a three-party protocol.=C2=A0 Which is probab=
ly
      the right way to think about it, even when all (three) parties are
      within the same administrative domain.

      

      Stephen also said something about it being hard to shoehorn a
      three-party protocol into the API for a two party protocol.=C2=A0 But
      depending on the specifics, maybe it's not so bad.=C2=A0 For exam=
ple,
      if the only semantics you need are a new API for "this is the li=
st
      of third parties I authorize to wiretap this connection", the
      scope seems fairly limited.

      

      Another thought spawned from today's session is that, given
      concerns about preventing/noticing if schemes intended for the
      datacenter leak out onto the internet, it's not really clear that
      "minimizes changes to the wire protocol" should be consider=
ed a benefit
      of proposals in this space.=C2=A0 If there are clear changes to the
      wire protocol, that makes it easy to detect when the scheme is in
      use.

      

      -Ben

    
  



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--089e082342e4018aee0554abd4d4--


From nobody Wed Jul 19 06:51:14 2017
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 70159131B44 for ; Wed, 19 Jul 2017 06:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EM9kKqhuskwX for ; Wed, 19 Jul 2017 06:51:10 -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 C96D512F268 for ; Wed, 19 Jul 2017 06:51:09 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id 32so1781293qtv.1 for ; Wed, 19 Jul 2017 06:51:09 -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=M1Ca05ga+3cWJYU00mE2ZiF8n7Dfv+Z1Auj4Zr88Pxk=; b=nhRcxSRJwdvyQc+hPc5UnULNIPsaVRgQcVe9VVnKwTdLPN79Kmz+h355FcrthdYSRi 0/Bc1Qks7Oy+/GxK0Jp++Q1l3Y6BG+luSN+gPtRiqG//bALGwxh5N04DQFYlGYEGtvBI kXN734/Fo4Fy6c7aik2XEjUgotvYErEfQtJjo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M1Ca05ga+3cWJYU00mE2ZiF8n7Dfv+Z1Auj4Zr88Pxk=; b=TuIfdhAN2w9cL/pSqQLWpV00Q9m02kr9avyGSigndz7gxTwQWmL/LwYrJt7BhBRiqi HndEEB//bo0zrfpTBtX7xivsJDubjbZl/+KHzBdYp0LwwbeVSLVKMqm2HuGuxEmGhlpT HXOLXibDnoOYGZ2/3BEr7G8pM9LB5IG9PsX184A0GHCNz9ODG0ICUU1RXe87q9MFW/NI BGsuCgw7rswx4aS0t4ghQ3QVE3mc+R6Nb5chaoPJqy5WeYlY3oLBVEyXdmOkA2vsXVom AIYYt7RJZm6akskiAeVRsvysIQVApEbOeVOa3qS5W2AVt/tU3vDDEoF+rNPca+fdb4DS 6Iuw==
X-Gm-Message-State: AIVw113cogrMKQqtG3Z1rdrwpdw8CCeAzLjO4EeItLcdCuIM8gg0Nm/E r15wa+pvPe8LNw0AEjLr45D5y8k0kU6z
X-Received: by 10.233.216.1 with SMTP id u1mr239186qkf.10.1500472268738; Wed, 19 Jul 2017 06:51:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.128.194 with HTTP; Wed, 19 Jul 2017 06:51:08 -0700 (PDT)
X-Originating-IP: [2001:67c:1232:144:dcb8:7855:d332:9475]
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> 
From: Kyle Rose 
Date: Wed, 19 Jul 2017 15:51:08 +0200
Message-ID: 
To: Ted Lemon 
Cc: Benjamin Kaduk , "" 
Content-Type: multipart/alternative; boundary="94eb2c043d4e9304160554abeca4"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 13:51:12 -0000

--94eb2c043d4e9304160554abeca4
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon  wrote:

> This is exactly right.   We have a *real* problem here.   We should
> *really* solve it.   We should do the math.   :)
>

Is there appetite to do this work? If we restrict this to two paths, one of
which is spending years designing and implementing a new multi-party
security protocol, the other of which is silently and undetectably (at
least on private networks) modifying the standardized protocol for which
lots of well-tested code already exists... my money is on the latter
happening.

In every decision we make with respect to the static DH approach, we have
to keep in mind that this change can be implemented unilaterally, i.e.,
without any modifications for interop. Consequently, I think the work we
really need to do is to design and implement a FS-breakage detector so we
can at least tell when this is happening on the public internet. Beyond
that, the best we can really do is ask implementors to be polite and
intentionally make their implementations not interoperate silently with TLS
1.3.

Kyle

--94eb2c043d4e9304160554abeca4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon <mellon@fugue.c=
om> wrote:
This is exactly=
 right. =C2=A0 We have a real problem here. =C2=A0 We should real=
ly solve it. =C2=A0 We should do the math. =C2=A0 :)
=


Is there appetite to do this work? If we restrict this =
to two paths, one of which is spending years designing and implementing a n=
ew multi-party security protocol, the other of which is silently and undete=
ctably (at least on private networks) modifying the standardized protocol f=
or which lots of well-tested code already exists... my money is on the latt=
er happening.

In every decision we make with respect to the static D=
H approach, we have to keep in mind that this change can be implemented uni=
laterally, i.e., without any modifications for interop. Consequently, I thi=
nk the work we really need to do is to design and implement a FS-breakage d=
etector so we can at least tell when this is happening on the public intern=
et. Beyond that, the best we can really do is ask implementors to be polite=
 and intentionally make their implementations not interoperate silently wit=
h TLS 1.3.

Kyle



--94eb2c043d4e9304160554abeca4--


From nobody Wed Jul 19 07:03:15 2017
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 EB011131B18 for ; Wed, 19 Jul 2017 07:03:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iv4djA7Qq7oy for ; Wed, 19 Jul 2017 07:03:12 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 2EFA2126CD8 for ; Wed, 19 Jul 2017 07:03:12 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id e199so613754pfh.2 for ; Wed, 19 Jul 2017 07:03:12 -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=Oyb68uIxxguWvaEOzlL5ORXMIvk4qn3rlTQBhwV4zR4=; b=VOnR07RkPq+yBQAVTIIAARtm5yAd7CHtjRfOcNx4fTCOye2P35Q+8CByRLuHgoMfcv 5CaN2wjzjA5jiAJ5r0N/KKYiBVQ1pNwYxV7f7kk4VYlkx2EBWhkHEdqzsivRCaW4NhZN emQNNibH0tevSygyzqdi8RQst4ucGBPepYtXCNiHfqb6g/fCD4cPkSRRzCds65SFHdh/ RpiPa8uttJf4sofqFJwuMiVL7m4+QHJGPj0O3qvQmWx3oFxYiBXUqubgoszQYWo5xSzl M78XXX4y3eJTYQ981Gans6HL1tSgr7GOJHWgMot+3lKKMyQW/9tVdRFRTQal9XeE4nKx SEQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Oyb68uIxxguWvaEOzlL5ORXMIvk4qn3rlTQBhwV4zR4=; b=Bap/v8/kRSEPsayR0vjEuyLNo1HSsO6o/T2HK+bxUGxMJSd8ErLMEFajvwxoh3Rpee XTcKeD2uECsjl8XITvLbfU7BTToJBYav0JmWmSFkElevY2IT6pEVkCoavN9hZl8rIZrx iMTZjbljnpOumMw4WEOAy31oLH6ad6w/Y4ZyqVQ3+fbmoUM8KXGNxgqB/++KQK00iaeo viBVxefYobn2lfqaYRH8IBcBh8uN+hcJgox36TsmwPSHSwsXDdaSo2bkQTdLPh8bvTCU T7hlEcqyKwK+8VeKf5XuD2XcU9XBFysQGiHMEGEo6D4W+H20z3nL28dh/9jAEjRxBuoT n1ZQ==
X-Gm-Message-State: AIVw1128IjKy5KENZUmwmDS200TUmOGpuIhle5yC6TrcS8Ypbyks1GNn 1xKHrd4vRLNc04rgQvUIrkunajhfasyv
X-Received: by 10.101.91.203 with SMTP id o11mr224684pgr.206.1500472991731; Wed, 19 Jul 2017 07:03:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 07:02:31 -0700 (PDT)
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>  
From: Ted Lemon 
Date: Wed, 19 Jul 2017 16:02:31 +0200
Message-ID: 
To: Kyle Rose 
Cc: Benjamin Kaduk , "" 
Content-Type: multipart/alternative; boundary="089e082342e4aae5130554ac17f5"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 14:03:14 -0000

--089e082342e4aae5130554ac17f5
Content-Type: text/plain; charset="UTF-8"

Bear in mind that what we (or at least I) want out of not publishing a spec
is that this technology not be present by default in TLS implementations.
If someone wants to maintain a set of patches, there's not much we can do
about it, and I don't honestly care *because* there isn't much that we can
do about it.   What I do not want to see is *the IETF* recommending this
solution.

It would be very nice if the people who are hot on a solution to this
problem were willing to do the work to do the three-way protocol.   But the
purpose of pointing out that that is the right solution is to say "if you
want to solve this problem in the IETF, here is what we could do that might
get IETF consensus."

On Wed, Jul 19, 2017 at 3:51 PM, Kyle Rose  wrote:

> On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon  wrote:
>
>> This is exactly right.   We have a *real* problem here.   We should
>> *really* solve it.   We should do the math.   :)
>>
>
> Is there appetite to do this work? If we restrict this to two paths, one
> of which is spending years designing and implementing a new multi-party
> security protocol, the other of which is silently and undetectably (at
> least on private networks) modifying the standardized protocol for which
> lots of well-tested code already exists... my money is on the latter
> happening.
>
> In every decision we make with respect to the static DH approach, we have
> to keep in mind that this change can be implemented unilaterally, i.e.,
> without any modifications for interop. Consequently, I think the work we
> really need to do is to design and implement a FS-breakage detector so we
> can at least tell when this is happening on the public internet. Beyond
> that, the best we can really do is ask implementors to be polite and
> intentionally make their implementations not interoperate silently with TLS
> 1.3.
>
> Kyle
>
>

--089e082342e4aae5130554ac17f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Bear in mind that what we (or at least I) want out of not =
publishing a spec is that this technology not be present by default in TLS =
implementations. =C2=A0 If someone wants to maintain a set of patches, ther=
e's not much we can do about it, and I don't honestly care becau=
se=C2=A0there isn't much that we can do about it. =C2=A0 What I do =
not want to see is the IETF=C2=A0recommending this solution.
It would be very nice if the people who are hot on a solution t=
o this problem were willing to do the work to do the three-way protocol. =
=C2=A0 But the purpose of pointing out that that is the right solution is t=
o say "if you want to solve this problem in the IETF, here is what we =
could do that might get IETF consensus."

On Wed, Jul 19, 2017 at 3:51 PM, Ky=
le Rose <krose@krose.org> wrote:
On Wed, Jul 19, 2017 at 3:43 PM, Ted=
 Lemon <mellon@fugue.com> wrote:
This is exactly right. =C2=A0 We have a r=
eal problem here. =C2=A0 We should really solve it. =C2=A0 We sh=
ould do the math. =C2=A0 :)

Is=
 there appetite to do this work? If we restrict this to two paths, one of w=
hich is spending years designing and implementing a new multi-party securit=
y protocol, the other of which is silently and undetectably (at least on pr=
ivate networks) modifying the standardized protocol for which lots of well-=
tested code already exists... my money is on the latter happening.

I=
n every decision we make with respect to the static DH approach, we have to=
 keep in mind that this change can be implemented unilaterally, i.e., witho=
ut any modifications for interop. Consequently, I think the work we really =
need to do is to design and implement a FS-breakage detector so we can at l=
east tell when this is happening on the public internet. Beyond that, the b=
est we can really do is ask implementors to be polite and intentionally mak=
e their implementations not interoperate silently with TLS 1.3.

Kyle






--089e082342e4aae5130554ac17f5--


From nobody Wed Jul 19 07:12:23 2017
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 245A7131CFA for ; Wed, 19 Jul 2017 07:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level: 
X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zfj7MIuqf3b7 for ; Wed, 19 Jul 2017 07:12:20 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 697EB131C93 for ; Wed, 19 Jul 2017 07:12:20 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id m7so2393018qtm.4 for ; Wed, 19 Jul 2017 07:12:20 -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=eD+HU8pAlm7uKzo2QLirD6nQURvGPXE5xIz47nb9xi8=; b=MwA8e6Qt1T3MOlwD2jwYz6qvLDJk/LMdLywWgQShsgz6lFnOZx/xVscDzKwfpq/CZu wLZldm8n9Y8G3X3IiogA2GgXnbGSXV7Y05TsUaCqfeyT/tPhJhRRoPy93OVXcvY0kpyT 81myX4SjSuff8tixT+e66dauj2XfG7TEkPmKc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eD+HU8pAlm7uKzo2QLirD6nQURvGPXE5xIz47nb9xi8=; b=e8/kCOvVu0kguk44Ccsut8TM0r6gFJxW4mDMpJA+gNqgbh+Bz9s00xjjK8YtcPSZiq eevDvdMT3IrUnW6EKPD5FXS3RMaH4ockn0KR3Rly3HkPm0oHJATLzduOadxvPlwAkWHc SzepBA4+irQO/TFgHaNPwjrt8tqBbKXsqcC/v8yK8+RIaR8y6LuD3YhbgJcNYxGLt8mA ffb3e+DERgHJAxRweCHTChxJaE74kUI7CsaLzsxquGFsCbRFLt4wKVhd9d/XeoSPlbsL zm+Ki5jv+oMe9kuQCls3nq+zow0xGK5ktUa9ER7veZao95m+u5zcPyaFFOE0DaYKSW4j 2X2A==
X-Gm-Message-State: AIVw113JEyM3FaD+1GFKq+MQ4zkXHYD+r+ersEIxXUmgAoNIkvaBS9M3 0Wp1b85OfjFqgaGiQv1zj2/Vp+IimvNa
X-Received: by 10.233.216.1 with SMTP id u1mr333561qkf.10.1500473539302; Wed, 19 Jul 2017 07:12:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.128.194 with HTTP; Wed, 19 Jul 2017 07:12:18 -0700 (PDT)
X-Originating-IP: [2001:67c:1232:144:dcb8:7855:d332:9475]
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>   
From: Kyle Rose 
Date: Wed, 19 Jul 2017 16:12:18 +0200
Message-ID: 
To: Ted Lemon 
Cc: Benjamin Kaduk , "" 
Content-Type: multipart/alternative; boundary="94eb2c043d4e4e240d0554ac38f4"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 14:12:22 -0000

--94eb2c043d4e4e240d0554ac38f4
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 19, 2017 at 4:02 PM, Ted Lemon  wrote:

> Bear in mind that what we (or at least I) want out of not publishing a
> spec is that this technology not be present by default in TLS
> implementations.   If someone wants to maintain a set of patches, there's
> not much we can do about it, and I don't honestly care *because* there
> isn't much that we can do about it.   What I do not want to see is *the
> IETF* recommending this solution.
>
> It would be very nice if the people who are hot on a solution to this
> problem were willing to do the work to do the three-way protocol.   But the
> purpose of pointing out that that is the right solution is to say "if you
> want to solve this problem in the IETF, here is what we could do that might
> get IETF consensus."
>

Agreed. 

--94eb2c043d4e4e240d0554ac38f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Wed, Jul 19, 2017 at 4:02 PM, Ted Lemon <mellon@fugue.c=
om> wrote:
Bear in mind that wh=
at we (or at least I) want out of not publishing a spec is that this techno=
logy not be present by default in TLS implementations. =C2=A0 If someone wa=
nts to maintain a set of patches, there's not much we can do about it, =
and I don't honestly care because=C2=A0there isn't much that=
 we can do about it. =C2=A0 What I do not want to see is the IETF=C2=
=A0recommending this solution.

It would be very nice if =
the people who are hot on a solution to this problem were willing to do the=
 work to do the three-way protocol. =C2=A0 But the purpose of pointing out =
that that is the right solution is to say "if you want to solve this p=
roblem in the IETF, here is what we could do that might get IETF consensus.=
"

Agreed. <req:newslett=
er-subscribe /> 


--94eb2c043d4e4e240d0554ac38f4--


From nobody Wed Jul 19 07:22:29 2017
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 79DDA1252BA for ; Wed, 19 Jul 2017 07:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3hZxGc0-Pu1 for ; Wed, 19 Jul 2017 07:22:24 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (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 3F3C8131D29 for ; Wed, 19 Jul 2017 07:22:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500474141; l=4803; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=oINQj9EhPt9MhTKjwf30Md4Wone8lyQ0x6LdH2aMA6Q=; b=tX3i/PycT25fg/fn4jVgJ/gWzKf4932YogQjN92ZzXTfOxMdyyxjenv6qFMLEelBzH W/QimFGrDfawjDxRT6Kyi6mOZreP/GMH/NahSCLGA0RaDT5VABLFwwFovCYnjJIZtPVH a0/kAbeU68OBgcml1//AreBLfBUo7FSf8gzdk=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWWlmkPDB+7nwYIvSX1sH
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.91] (p508A6EE0.dip0.t-ipconnect.de [80.138.110.224]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id Z09c35t6JEML2vS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Wed, 19 Jul 2017 16:22:21 +0200 (CEST)
To: tls@ietf.org
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>  
From: Roland Zink 
Message-ID: <76bb50c5-a699-4c91-7993-618acb365baf@zinks.de>
Date: Wed, 19 Jul 2017 16:22:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F5F27BBFF07A1EB2EC9D8C61"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 14:22:27 -0000

This is a multi-part message in MIME format.
--------------F5F27BBFF07A1EB2EC9D8C61
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



Am 19.07.2017 um 15:51 schrieb Kyle Rose:
> On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon  > wrote:
>
>     This is exactly right.   We have a /real/ problem here.   We
>     should /really/ solve it. We should do the math.   :)
>
>
> Is there appetite to do this work? If we restrict this to two paths, 
> one of which is spending years designing and implementing a new 
> multi-party security protocol, the other of which is silently and 
> undetectably (at least on private networks) modifying the standardized 
> protocol for which lots of well-tested code already exists... my money 
> is on the latter happening.
>
There is a good chance that this "cheaper" solution is what will happen. 
However the multi-party protocol may be a safer and better approach and 
may even forced in by some regulators when it exists as an implemented 
alternative.

> In every decision we make with respect to the static DH approach, we 
> have to keep in mind that this change can be implemented unilaterally, 
> i.e., without any modifications for interop. Consequently, I think the 
> work we really need to do is to design and implement a FS-breakage 
> detector so we can at least tell when this is happening on the public 
> internet. Beyond that, the best we can really do is ask implementors 
> to be polite and intentionally make their implementations not 
> interoperate silently with TLS 1.3.
>
> Kyle
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------F5F27BBFF07A1EB2EC9D8C61
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
Am 19.07.2017 um 15:51 schrieb Kyle
      Rose:

    

    

      
On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon <mellon@fugue.com>
        wrote:

        

          

            

              

                
This is exactly right.   We have a real
                  problem here.   We should really solve it.  
                  We should do the math.   :)

              

              


              

              
Is there appetite to do this work? If we restrict
                this to two paths, one of which is spending years
                designing and implementing a new multi-party security
                protocol, the other of which is silently and
                undetectably (at least on private networks) modifying
                the standardized protocol for which lots of well-tested
                code already exists... my money is on the latter
                happening.

                

              

            

          

        

      

    

    There is a good chance that this "cheaper" solution is what will
    happen. However the multi-party protocol may be a safer and better
    approach and may even forced in by some regulators when it exists as
    an implemented alternative.

     

    

      

        

          

            

              
In every decision we make with respect to the static
                DH approach, we have to keep in mind that this change
                can be implemented unilaterally, i.e., without any
                modifications for interop. Consequently, I think the
                work we really need to do is to design and implement a
                FS-breakage detector so we can at least tell when this
                is happening on the public internet. Beyond that, the
                best we can really do is ask implementors to be polite
                and intentionally make their implementations not
                interoperate silently with TLS 1.3.

                

              

              
Kyle

              

              


              

            

          

        

      

      

      

      

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


    

    

  


--------------F5F27BBFF07A1EB2EC9D8C61--


From nobody Wed Jul 19 07:48:49 2017
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 3108F126C0F for ; Wed, 19 Jul 2017 07:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EK3p1WTVv-ng for ; Wed, 19 Jul 2017 07:48:44 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631B2131B11 for ; Wed, 19 Jul 2017 07:48:44 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id 125so1232023pgi.3 for ; Wed, 19 Jul 2017 07:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aSha9v+4/2VA6s3gqh6zx2VePy24oAnbAlkK5wch22g=; b=UNS32tcTc9mbkFp3+HIbNqdlBOsdvQe5fQUF44qSULJktWoY/WoABTZuFMPBXtHSvr QiaBdfQGE0CrK7C5fc0KOQl/S7LCJhm8HaHTNYE8jafLukDUN6+tSv1Z3SYPbYx0wyGF Gkyzz2kzNosF8gxZPAfOJAQlwxMeAzXAmscOXQ4Tat+4bN/VvcDBV6A8GRvFG5g820rP rigu2Z4Tw30vT+T1UVPXcXBzjt347DOF2l2Lg3u9rlS0o2lLW8R3HFTPAJoeuKIiZHVU Sykng9Ys2YGVzz1hImfb6rPN+0KXeuuVGcOsPWAFezFFN0oecEyhCd2n+ObC8QUkwaqs v3Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aSha9v+4/2VA6s3gqh6zx2VePy24oAnbAlkK5wch22g=; b=NZA7WUpJJ/bmiJ24UIYaaA4zWmC/rHOQpp9UCS6k+TaLfjtSXPM3zJtXa2Tmcyd4U/ 9P3iYCpoxSCyo+EmC9pBdDxhpSNlEOLLowgiIvJYLWOQVUSY+P47Bq1iuuyTzwvyWPtB TknnjM7G4L1HKNO1p5/luXsxHHqvotW+3xi2jn68GvQIwLznKD2QmvwRT5ibfl7YDoXS IkWyJau5tpcy7aklnbItFH1BoH23B4rVU1dASVWdrZD4TNLnPIZ7zk/UuQ/ADyp6Azur 91jjGSbeSPpMu1JpT3O3qgcoqzf/7G9E2FMD+ChZmIrVuOT91XvorcIqwgzdNOYOlB+L RO+Q==
X-Gm-Message-State: AIVw112UV8xa5Z5at1iNIoYSlAtLTOmWgNbAWXaRp2dlA7Yr1HQwR8al K9Am5dbllFGurIiVGcXTHbvlwOPmVw==
X-Received: by 10.98.16.203 with SMTP id 72mr357646pfq.290.1500475723941; Wed, 19 Jul 2017 07:48:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Wed, 19 Jul 2017 07:48:43 -0700 (PDT)
In-Reply-To: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>  
From: Watson Ladd 
Date: Wed, 19 Jul 2017 07:48:43 -0700
Message-ID: 
To: Roland Dobbins 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11448bbe850e910554acba40"
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 14:48:47 -0000

--001a11448bbe850e910554acba40
Content-Type: text/plain; charset="UTF-8"

On Jul 17, 2017 12:29 PM, "Roland Dobbins"  wrote:

On 17 Jul 2017, at 21:11, Watson Ladd wrote:

How do you detect unauthorized access separate from knowing what
> authorization is?
>

I think we're talking at cross purposes, here.  Can you clarify?


You said you need to look at packets to see unauthorized access. How do you
that access is unauthorized unless the authorization system is doing the
monitoring?



Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?
>

Many don't.  And being able to see rot(x) in the cryptostream has value.


As the IRA pointed out to the Prime Minister, she needed to get lucky every
time.




And the endpoints taking logs won't be?
>

Logs are no substitute for seeing the packets on the wire.


Then log the raw plaintext stream.




Applications can rate-limited their own endpoints.
>

There's a lot more to DDoS defense than rate-limiting.  Rate-limiting often
leads to gross overblocking.


You're telling me a dedicated out of stream box can handle this but a beefy
> server cannot?
>

Sadly, in all too many cases, yes.


... something is wrong here.




No one is taking away the ability to log the PMS to a file. That's the
> capacity which exists now.
>

But the capacity in question here is to see the packets on the wire.


Wireshark can use that file to decrypt packets on the wire. Today. What is
the problem with that?



Alternatively it's because you've decided to run your networks in ways very
> different from the public internet and used this as a way to avoid
> organizational battles over giving operations the tools they need to work.
>

I think that some perceptions of how these things are done even on the
public Internet may be a bit circumscribed.

The tools that network engineers and security personnel need analyze
network traffic.  Logs are insufficient.

-----------------------------------
Roland Dobbins 

--001a11448bbe850e910554acba40
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Jul 17, 2017 12:29 PM, "Roland Dobbins&q=
uot; <rdobbins@a=
rbor.net> wrote:
On 17 =
Jul 2017, at 21:11, Watson Ladd wrote:





How do you detect unauthorized access separate from knowing what

authorization is?





I think we're talking at cross purposes, here.=C2=A0 Can you clarify?

=
You said you need to look at packets to see unauthorized access. How do you=
 that access is unauthorized unless the authorization system is doing the m=
onitoring?







Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?<=
br>




Many don't.=C2=A0 And being able to see rot(x) in the cryptostream has =
value.

As the IRA pointed out to the Prime Minister, she needed to get l=
ucky every time.=C2=A0








And the endpoints taking logs won't be?





Logs are no substitute for seeing the packets on the wire.

Then log the ra=
w plaintext stream.








Applications can rate-limited their own endpoints.





There's a lot more to DDoS defense than rate-limiting.=C2=A0 Rate-limit=
ing often leads to gross overblocking.






You're telling me a dedicated out of stream box can handle this but a b=
eefy server cannot?





Sadly, in all too many cases, yes.

... something is wrong here.









No one is taking away the ability to log the PMS to a file. That's the<=
br>
capacity which exists now.





But the capacity in question here is to see the packets on the wire.

Wires=
hark can use that file to decrypt packets on the wire. Today. What is the p=
roblem with that?






Alternatively it's because you've decided to run your networks in w=
ays very

different from the public internet and used this as a way to avoid

organizational battles over giving operations the tools they need to work.<=
br>




I think that some perceptions of how these things are done even on the publ=
ic Internet may be a bit circumscribed.



The tools that network engineers and security personnel need analyze networ=
k traffic.=C2=A0 Logs are insufficient.



-----------------------------------

Roland Dobbins <=
rdobbins@arbor.net>







--001a11448bbe850e910554acba40--


From nobody Wed Jul 19 08:07:10 2017
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 A1633131CE6 for ; Wed, 19 Jul 2017 08:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 kgJJkx19TQPf for ; Wed, 19 Jul 2017 08:07:05 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8C50712F280 for ; Wed, 19 Jul 2017 08:07:05 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6JF746P005135 for ; Wed, 19 Jul 2017 11:07:04 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB0GJJTXEJ9Nke26Xc5y2RlZKJba/cAgAACGwCAAAi6AP//yW6A
Date: Wed, 19 Jul 2017 15:07:03 +0000
Message-ID: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>   <76bb50c5-a699-4c91-7993-618acb365baf@zinks.de>
In-Reply-To: <76bb50c5-a699-4c91-7993-618acb365baf@zinks.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583307223_1931397775"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707190248
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 15:07:09 -0000

--B_3583307223_1931397775
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

>>> This is exactly right. =C2=A0 We have a real problem here. =C2=A0 We should rea=
lly solve it. =C2=A0
>>> We should do the math. =C2=A0 :)
>>
>>  Is there appetite to do this work? If we restrict this to two paths, on=
e of which is
>> spending years designing and implementing a new multi-party security pro=
tocol,=20
>> the other of which is silently and undetectably (at least on private net=
works) modifying
>> the standardized protocol for which lots of well-tested code already exi=
sts...
>> my money is on the latter happening.
>
> There is a good chance that this "cheaper" solution is what will happen.=20

Sure. The point is that IETF *must not* support such =E2=80=9Cundetectable modifi=
cations of a standard protocol=E2=80=9D.
The fact that crime invariably happens does not imply that we should become=
 criminals. ;-)

> However the multi-party protocol may be a safer and better approach and m=
ay even
> forced in by some regulators when it exists as an implemented alternative=
.

IETF is supposed to be about designing and (until a decade or so ago) imple=
menting the *right* solutions. In this case multi-party protocol =C2=A0appears t=
o be =E2=80=9Cit=E2=80=9D.=20

So let those who need this capability spearhead the design, with cryptograp=
hers and academia helping that work or at least auditing the results.

>> In every decision we make with respect to the static DH approach, we hav=
e to keep
>> in mind that this change can be implemented unilaterally, i.e., without =
any modifications
>> for interop. Consequently, I think the work we really need to do is to d=
esign and implement
>> a FS-breakage detector so we can at least tell when this is happening on=
 the public internet.

I agree. Though I don=E2=80=99t know off-hand if this is technically possible. Be=
cause as you pointed out, an end-point can always choose to leak its part ou=
t-of-band, and there=E2=80=99s nothing his communicating peer can do about it (AFA=
IK). (We can at least make sure that the official implementations such as Op=
enSSL and GnuTLS do not include such =E2=80=9Cextensions=E2=80=9D.)

Still, a multi-party protocol that makes the presence or absence of such mo=
nitoring explicit, would be the best option, IMHO.

>> Beyond that, the best we can really do is ask implementors to be polite =
and intentionally
>> make their implementations not interoperate silently with TLS 1.3.

I agree.


--B_3583307223_1931397775
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU
WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO
DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A
97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN
YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR
COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x
dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01
c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ
KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G
/F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL
e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c
A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgtNKvyBo8WAV4hIE2
/su+zgOpEbVSJqwcz+XMXOQ/UO8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE5MTUwNzAzWjANBgkqhkiG9w0BAQEFAASCAQB4JO0Pm+XlZhfyAlpN
CRYpvLbbaiMp6F9NgjZnqkI7Ukv9i06lesorOwdQjNdB3L4DVGmjnKt3iaus4iddFTrxblLA
vvpJIyzsnoh8x+lpRItWbcKUjgzocW28mJVVLlJ15AXwNunyzImkuTz45sOJ/yQwqDiczSeE
l7LrA/jbIhjGoYYWMoBYJ6YOPw9+PDSgWSoOxK6iRvGJk8D9ZYndOzT8ZBVoW2GCt3T6hmd1
BevlexBtUAo+ZF3cuLJLkH86ZtEKouI9irw5r3VCAfPhmgEOIhPZ5miXxXzVYf+bFK7jAQ3J
CQDw5CAnvU58IpXV/dI+hjuZqZ8aj9c4S19W

--B_3583307223_1931397775--


From nobody Wed Jul 19 09:02:27 2017
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 76781131686 for ; Wed, 19 Jul 2017 09:02:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 zq6uPyeCWUAg for ; Wed, 19 Jul 2017 09:02:23 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 81A11127B60 for ; Wed, 19 Jul 2017 09:02:23 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id k71so7013986wrc.2 for ; Wed, 19 Jul 2017 09:02:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=f9FbvBDtTfyXjQPBQ6l6SF39FeK50sLS6mdtB8akN4I=; b=cJgD1iUD6GQ0OY0RV43WYz/e8kOrW5hf97dOhiYVLtQSHsnhZ5yXaes6GCnro57yKT CPv46LubsE5kmbGVbOFa+cvGyjKKrtqMLfOMzmAcAjoQ5RM+uY3BR5MHcOs9g1J0uy+y 6mpi51emhreFsHrFtdB4GVLGs8pKPuP0ZoRSLV2SZ58IwgxB4YwuhSmbNTkkshTbbCjJ K8DYvI5INisX3JD2ca7w3biFpNua0YD1qhYZ9LKdViu3cszyeumI8r6SBnlIYSs3q+Po rQpwU20+4CCDY9E92gb4RglLMDmNpactsseGP5Yr4m8/o+s/43YQqHsq/zEHgit7XWKf xW5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=f9FbvBDtTfyXjQPBQ6l6SF39FeK50sLS6mdtB8akN4I=; b=tGMu90g+53xL4Xuen2Gzw/Q2qQETyT05rGB0/jq/pz3/d8Xtaoy7cAlr/iEfW79yIA yAVilhAD3uWAvWOaeU4K8z24r0xfYuDkAZwshJFmeNUEckRjwmeg4a1CIyMrxkWfHrps y7SgROgqb1rifdygHVeS3v22ylKbOznm4lIJ5X2GoMssmnDRrj94FNf+22zZN+9xxqX1 SvRHpihG/YFBDY0L4nNmH6XR386De/+Js8KT/4UGkIAEmSCV2qrEYBJ4TC0aobmtnNPx 13exLZ3WpGM7mNk6Jt4mL23/KgyjF/GAnvO9AaqRan2Uh3OzUZg0xLqW38vx2xB+7zj/ elUw==
X-Gm-Message-State: AIVw112+WHVRGNBU5J8lxzYNBg2vQ7qx8derCPGRMphZA/EU8lJcT+cn hxcxFiERGoinMA==
X-Received: by 10.223.131.99 with SMTP id 90mr4358259wrd.155.1500480142032; Wed, 19 Jul 2017 09:02:22 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:71ba:2eb3:367b:d792? ([2001:67c:370:128:71ba:2eb3:367b:d792]) by smtp.gmail.com with ESMTPSA id u66sm908923wrb.77.2017.07.19.09.02.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 09:02:21 -0700 (PDT)
From: Yoav Nir 
Message-Id: <09CF3C56-E9C7-4F02-8D1F-B5766CC9430C@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_7CB3732B-149C-40D5-8827-44CDA12A1349"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 19 Jul 2017 18:02:19 +0200
In-Reply-To: 
Cc: "tls@ietf.org" 
To: "Blumenthal, Uri - 0553 - MITLL" 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>   <76bb50c5-a699-4c91-7993-618acb365baf@zinks.de> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 16:02:25 -0000

--Apple-Mail=_7CB3732B-149C-40D5-8827-44CDA12A1349
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 19 Jul 2017, at 17:07, Blumenthal, Uri - 0553 - MITLL =
 wrote:
>=20
>>>> This is exactly right.   We have a real problem here.   We should =
really solve it.
>>>> We should do the math.   :)
>>>=20
>>> Is there appetite to do this work? If we restrict this to two paths, =
one of which is
>>> spending years designing and implementing a new multi-party security =
protocol,
>>> the other of which is silently and undetectably (at least on private =
networks) modifying
>>> the standardized protocol for which lots of well-tested code already =
exists...
>>> my money is on the latter happening.
>>=20
>> There is a good chance that this "cheaper" solution is what will =
happen.
>=20
> Sure. The point is that IETF *must not* support such =E2=80=9Cundetectab=
le modifications of a standard protocol=E2=80=9D.
> The fact that crime invariably happens does not imply that we should =
become criminals. ;-)
>=20
>> However the multi-party protocol may be a safer and better approach =
and may even
>> forced in by some regulators when it exists as an implemented =
alternative.
>=20
> IETF is supposed to be about designing and (until a decade or so ago) =
implementing the *right* solutions. In this case multi-party protocol  =
appears to be =E2=80=9Cit=E2=80=9D.
>=20
> So let those who need this capability spearhead the design, with =
cryptographers and academia helping that work or at least auditing the =
results.
>=20
>>> In every decision we make with respect to the static DH approach, we =
have to keep
>>> in mind that this change can be implemented unilaterally, i.e., =
without any modifications
>>> for interop. Consequently, I think the work we really need to do is =
to design and implement
>>> a FS-breakage detector so we can at least tell when this is =
happening on the public internet.
>=20
> I agree. Though I don=E2=80=99t know off-hand if this is technically =
possible. Because as you pointed out, an end-point can always choose to =
leak its part out-of-band, and there=E2=80=99s nothing his communicating =
peer can do about it (AFAIK). (We can at least make sure that the =
official implementations such as OpenSSL and GnuTLS do not include such =
=E2=80=9Cextensions=E2=80=9D.)
>=20
> Still, a multi-party protocol that makes the presence or absence of =
such monitoring explicit, would be the best option, IMHO.

At the very least, a standards-track multi-party protocol like that can =
be something that standards like PCI, HIPAA and others can latch on to =
and say =E2=80=9CDo TLS 1.3 without backdoors unless you really need to =
and in that case use *this*=E2=80=9D.

That is better guidance than =E2=80=9CDo TLS 1.3 without backdoors, =
unless you really need to and in that case do whatever works for you"

--Apple-Mail=_7CB3732B-149C-40D5-8827-44CDA12A1349
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJZb4KMAAoJELhJCxUKWMyZJjAIAJBx3/c2ISECtpJwMr8iFrHY
G/0hpz4++NZD48ZM+FnI56K+CqwGHEyVeEwqAbt8iBckrwjhfdW/HQFKl5+PfT3K
DrjEuus30F2AHS3yJgtqAsivn0atQ8tNTXD6ROC29Bpz8l/o2ExgMDEZAGGxg3Hl
JSD99ypSXeqZiCUyxaQdD5/fyfMp/EZFGrhGcDV4c8qDcSXmzLUy/6wctoOVQGI+
aY22p3EV7sG/1/munDRd/GPgiR8qQo/Sky2oJQxRZ9Wne/zLMI7NRUT9PWpgTWgq
1erlZ4ot/hHgU4NRhFsn3tHqEwcVRcqK3m2xSAicSloq+RIb45MnKEVACH6z2jM=
=dLut
-----END PGP SIGNATURE-----

--Apple-Mail=_7CB3732B-149C-40D5-8827-44CDA12A1349--


From nobody Wed Jul 19 09:20:13 2017
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 2E9C8124234 for ; Wed, 19 Jul 2017 09:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 tVXVrZPIzTSZ for ; Wed, 19 Jul 2017 09:20:10 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002: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 98A601287A5 for ; Wed, 19 Jul 2017 09:20:10 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id w187so1363438ybc.0 for ; Wed, 19 Jul 2017 09:20:10 -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=J5z+qfHt8u7hvuCOCZ5JcPjF1/j4BE+ISWH/tW0DsVE=; b=DE8pIoaz7+EA0e7nTw/zSnvnd4WR/MR7SeDrnI+ivKaF9g86LeAGskG/5tg6AT9/Ci HqbrSJumAxa4SwAMlrfJSQkGHkdarQ1VvBI+Q30Td4D34ZFjdkHrPZNrCNyTN+pCITfC bnnKsyR9vHYChHjd5mw4HIIx/NpvgBb7YbmiMtAljf3DSctQQ/vCRDwJN804ED9oo5Qa HAYUS8r9K8C7KKfc2Gah0PVKDKaHnvJjcTagFJEPxbT8NYyXDFUV55R6Ac3Br8JfWsql SFJK4mGP572R5/WuuNAV+F0XdX142uBw3/VOKAnyD6wAdpZIyQJIlZy4Dn3/z0p3LgB/ YbrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J5z+qfHt8u7hvuCOCZ5JcPjF1/j4BE+ISWH/tW0DsVE=; b=nxjgtEw0AKdcyBG6z1Iasee+Rxwj/Evt7zde4glvrtvGFOHql1oIJgTu71IvHoF7nu RyAWvQ5p2X+oIwY4XwUqmQ0Shwab7Ewtioi7/eoKP+isX6VyTQXG2YvYBbGL4JwxT34j TxmsAf8n+Rj/9JnpFhtW9r1i5+/43B1bWO0ntbzrsy7lAHtcueVQQrVXV/leFJvHzBbq 7O3+rH6OLIESDqlHHKvQdetLhwAQloLuYunQYD19PSoyHgizCdnJ7v4rmVf4d0xUgJk1 ky1a277GuVSBppeVIkDtkI3mpwew3N6aDvoz3inoQTlTSR6SQt8xT22UwV3ZCoesqYXd /L8Q==
X-Gm-Message-State: AIVw1133daFzYCfzrsygm7r2fygrjMVSXG+NZ1WhCY1odnP2628lUXB6 ZjMd0cYhFi5wIcf00ZKH8OD4KPXtjGgB
X-Received: by 10.37.84.8 with SMTP id i8mr607487ybb.12.1500481209723; Wed, 19 Jul 2017 09:20:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Wed, 19 Jul 2017 09:20:08 -0700 (PDT)
In-Reply-To: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>   
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 19 Jul 2017 09:20:08 -0700
Message-ID: 
To: Watson Ladd 
Cc: Roland Dobbins , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1135162c7fa0970554ae0136"
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 16:20:12 -0000

--001a1135162c7fa0970554ae0136
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 19, 2017 at 7:48 AM, Watson Ladd  wrote:
>
> On Jul 17, 2017 12:29 PM, "Roland Dobbins"  wrote:
>
> On 17 Jul 2017, at 21:11, Watson Ladd wrote:
>
> How do you detect unauthorized access separate from knowing what
>> authorization is?
>>
>
> I think we're talking at cross purposes, here.  Can you clarify?
>
>
> You said you need to look at packets to see unauthorized access. How do
> you that access is unauthorized unless the authorization system is doing
> the monitoring?
>

Over the years I've met with businesses who have these kinds of set ups.
The way it usually works is that the analysis is secondary and based on a
suspicion of some kind. For example: if an employee is suspected of insider
trading, or stealing proprietary data, then the administrators may take the
extreme measure of inspecting all of their traffic. This is why many
corporate environments have those "No expectation of privacy" disclaimers.

Another example is where traffic to a set of suspicious destinations is
subject to a higher level of scrutiny. For example, maybe traffic bound for
well known file sharing services.

I've never seen an environment with pervasive always-on monitoring;
creating a trove of plaintext would be a net security negative, and
organizations rarely have the resources it would take to keep or analyze
all of it anyway.

Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?
>>
>
> Many don't.  And being able to see rot(x) in the cryptostream has value.
>
>
> As the IRA pointed out to the Prime Minister, she needed to get lucky
> every time.
>

Where I come from, if you're quoting the IRA to support an argument, nobody
takes you seriously.


> The tools that network engineers and security personnel need analyze
> network traffic.  Logs are insufficient.
>
>

They are, though it's a big change. I think we can do better than logs; a
mechanism that's in TLS itself could be opt-in and user-aware, and so less
likely to be abused in other situations. There's also some basic security
model advantages to encrypting the PMS under a public-private key pair, and
one that isn't using the private key that the servers themselves hold.

-- 
Colm

--001a1135162c7fa0970554ae0136
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Jul 19, 2017 at 7:48 AM, Watson Ladd <watsonbladd@gmail.co=
m> wrote:
On Jul 17, 2017 12:29 PM, "Roland Dobbins" <<=
a href=3D"mailto:rdobbins@arbor.net" target=3D"_blank">rdobbins@arbor.net> wrote:
On 17 Jul 2017, at 21:11, Watson Ladd wrote:





How do you detect unauthorized access separate from knowing what

authorization is?





I think we're talking at cross purposes, here.=C2=A0 Can you clarify?

You said you need to look at packets to see unauthorized access. How=
 do you that access is unauthorized unless the authorization system is doin=
g the monitoring?

Over th=
e years I've met with businesses who have these kinds of set ups. The w=
ay it usually works is that the analysis is secondary and based on a suspic=
ion of some kind. For example: if an employee is suspected of insider tradi=
ng, or stealing proprietary data, then the administrators may take the extr=
eme measure of inspecting all of their traffic. This is why many corporate =
environments have those "No expectation of privacy" disclaimers.<=
/div>

Another example is where traffic to a set of suspi=
cious destinations is subject to a higher level of scrutiny. For example, m=
aybe traffic bound for well known file sharing services.=C2=A0
I've never seen an environment with pervasive always-on mo=
nitoring; creating a trove of plaintext would be a net security negative, a=
nd organizations rarely have the resources it would take to keep or analyze=
 all of it anyway. =C2=A0




Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?<=
br>




Many don't.=C2=A0 And being able to see rot(x) in the cryptostream has =
value.

As the IRA pointed out to the Prime Minister, she needed to =
get lucky every time.

Whe=
re I come from, if you're quoting the IRA to support an argument, nobod=
y takes you seriously.=C2=A0
=C2=A0
The tools that network e=
ngineers and security personnel need analyze network traffic.=C2=A0 Logs ar=
e insufficient.


They are, though it's a big c=
hange. I think we can do better than logs; a mechanism that's in TLS it=
self could be opt-in and user-aware, and so less likely to be abused in oth=
er situations. There's also some basic security model advantages to enc=
rypting the PMS under a public-private key pair, and one that isn't usi=
ng the private key that the servers themselves hold.=C2=A0
=

-- 
Colm




--001a1135162c7fa0970554ae0136--


From nobody Wed Jul 19 09:26:54 2017
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 7423F13167D for ; Wed, 19 Jul 2017 09:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 3Q7fd8Xn0QL1 for ; Wed, 19 Jul 2017 09:26:51 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id C14A1131472 for ; Wed, 19 Jul 2017 09:26:50 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6JGQmBM006779; Wed, 19 Jul 2017 12:26:48 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: "tls@ietf.org" , Watson Ladd 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulwkltwWiCLAkez9/LKtukmkaJYpiSAgAAE/ICAAtZXgIAAGYoA//++zoA=
Date: Wed, 19 Jul 2017 16:26:47 +0000
Message-ID: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583312007_1490358185"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707190270
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 16:26:53 -0000

--B_3583312007_1490358185
Content-type: multipart/alternative;
	boundary="B_3583312007_645825106"


--B_3583312007_645825106
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

You said you need to look at packets to see unauthorized access. How do you=
 that access is unauthorized unless the authorization system is doing the mo=
nitoring?

=20

Over the years I've met with businesses who have these kinds of set ups. Th=
e way it usually works is that the analysis is secondary and based on a susp=
icion of some kind. For example: if an employee is suspected of insider trad=
ing, or stealing proprietary data, then the administrators may take the extr=
eme measure of inspecting all of their traffic. This is why many corporate e=
nvironments have those "No expectation of privacy" disclaimers.

=20

Another example is where traffic to a set of suspicious destinations is sub=
ject to a higher level of scrutiny. For example, maybe traffic bound for wel=
l known file sharing services.=20

=20

This all is fairly obvious. The question is when do you start recording (an=
d therefore examining) the traffic.

=20

I've never seen an environment with pervasive always-on monitoring; creatin=
g a trove of plaintext would be a net security negative, and organizations r=
arely have the resources it would take to keep or analyze all of it anyway. =
=20

=20

Same question. At some point in time you need to decide to start examining =
all the traffic. At that point you can start capturing its plaintext. The pr=
oposed alternative seems to be capturing the ciphertext and the key so the c=
iphertext can be decrypted later =E2=80=93 which makes no sense to me.

=20

=20

They are, though it's a big change. I think we can do better than logs; a m=
echanism that's in TLS itself could be opt-in and user-aware, and so less li=
kely to be abused in other situations. There's also some basic security mode=
l advantages to encrypting the PMS under a public-private key pair, and one =
that isn't using the private key that the servers themselves hold.=20

=20

To use the key you need to have the corresponding ciphertext stored. It is =
worse time- and space-wise than storing the plaintext (encrypted under the a=
uthorities=E2=80=99 key). You seem to have proved that capturing the plaintext fro=
m the originating (or receiving =E2=80=93 whatever end you own) end-point and encr=
ypting/storing it is much better option than sending ciphertext and leaking =
its keys (or reusing static keys for the same purpose).

=20


--B_3583312007_645825106
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


You said yo=
u need to look at packets to see unauthorized access. How do you that access=
 is unauthorized unless the authorization system is doing the monitoring?
 
Over the years =
I've met with businesses who have these kinds of set ups. The way it usually=
 works is that the analysis is secondary and based on a suspicion of some ki=
nd. For example: if an employee is suspected of insider trading, or stealing=
 proprietary data, then the administrators may take the extreme measure of i=
nspecting all of their traffic. This is why many corporate environments have=
 those "No expectation of privacy" disclaimers.
 
Another example is where =
traffic to a set of suspicious destinations is subject to a higher level of =
scrutiny. For example, maybe traffic bound for well known file sharing servi=
ces. 
&n=
bsp;
This all is fai=
rly obvious. The question is when do you start recording (and therefore exam=
ining) the traffic.
 
I've never seen an environment with pervasive always-on =
monitoring; creating a trove of plaintext would be a net security negative, =
and organizations rarely have the resources it would take to keep or analyze=
 all of it anyway.  
 
=
Same question. At some point in time you need to decide to start examining a=
ll the traffic. At that point you can start capturing its plaintext. The pro=
posed alternative seems to be capturing the ciphertext and the key so the ci=
phertext can be decrypted later =E2=80=93 which makes no sense to me.
 
 
They are, though it's a big change. I think we c=
an do better than logs; a mechanism that's in TLS itself could be opt-in and=
 user-aware, and so less likely to be abused in other situations. There's al=
so some basic security model advantages to encrypting the PMS under a public=
-private key pair, and one that isn't using the private key that the servers=
 themselves hold. 
 
To use the key you need to have the corresponding cipher=
text stored. It is worse time- and space-wise than storing the plaintext (en=
crypted under the authorities=E2=80=99 key). You seem to have proved that capturin=
g the plaintext from the originating (or receiving =E2=80=93 whatever end you own)=
 end-point and encrypting/storing it is much better option than sending ciph=
ertext and leaking its keys (or reusing static keys for the same purpose).
&nbs=
p;


--B_3583312007_645825106--

--B_3583312007_1490358185
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU
WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO
DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A
97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN
YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR
COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x
dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01
c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ
KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G
/F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL
e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c
A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgyHoAlV2Pug/7styL
J8ydrRv4hHMZKtosgDQUll58PSswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE5MTYyNjQ3WjANBgkqhkiG9w0BAQEFAASCAQAFTFcZH5Gm4414Wi84
mLeb1jLjPSs9HG9wCIucvzDxOuFcL+YxTHQz1Fb1J9OB9bx9tqHNtYnRbkz2MawNyTY2WchC
fcWYhossVBVKwD+FdiZDpcpVrE2Dn6U2sic9/xHi3qAvFQvYH/K/LQ3Po63hNFG6OnACSxRW
W2ScZL+uLacc16UYxvBINmQ4N8eMG3ASLV0yBEihsRIZt0STYWySu+4F19Vwpu88rueqRVBL
JxzVAAo05M6uqSEwfZP6NGyiHgr2S9jzVD4M3JL1E8QXcXgddWOJMFRp57kTZZde9KFYAJ4j
S09LGuoipMbf3Oiw6kq3j2zYK3RV/4rcKvY0

--B_3583312007_1490358185--


From nobody Wed Jul 19 09:28:37 2017
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 957DD12EA95 for ; Wed, 19 Jul 2017 09:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 ZD6hQ0139LeH for ; Wed, 19 Jul 2017 09:28:34 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 53D43127077 for ; Wed, 19 Jul 2017 09:28:34 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6JGSWXF007726; Wed, 19 Jul 2017 12:28:32 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Yoav Nir 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB0GJJTXEJ9Nke26Xc5y2RlZKJba/cAgAACGwCAAAi6AP//yW6AgABSf4D//8RFAA==
Date: Wed, 19 Jul 2017 16:28:32 +0000
Message-ID: <2A557041-43FD-4912-BC07-46B7B9BE699F@ll.mit.edu>
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>   <76bb50c5-a699-4c91-7993-618acb365baf@zinks.de>  <09CF3C56-E9C7-4F02-8D1F-B5766CC9430C@gmail.com>
In-Reply-To: <09CF3C56-E9C7-4F02-8D1F-B5766CC9430C@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583312112_1313426452"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707190270
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 16:28:36 -0000

--B_3583312112_1313426452
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

> At the very least, a standards-track multi-party protocol like that can b=
e something that standards
> like PCI, HIPAA and others can latch on to and say =E2=80=9CDo TLS 1.3 without =
backdoors unless you really
> need to and in that case use *this*=E2=80=9D.
> That is better guidance than =E2=80=9CDo TLS 1.3 without backdoors, unless you =
really need to and in that
> case do whatever works for you"
 =20
One emphatic YES. =20

--B_3583312112_1313426452
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU
WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO
DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A
97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN
YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR
COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x
dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01
c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ
KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G
/F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL
e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c
A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgWKINSgig9Cm8bNzu
zaE8LrSlBY8LiTnzTgUPq0fxkokwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE5MTYyODMyWjANBgkqhkiG9w0BAQEFAASCAQBty4ExWCQ8OXlHdnsk
zrv3TiAktrh7h2+e7nscx/az+GZaz38Ww2Jsq/5M99kE44u1g+SYNEknJn+i2CsLSUetoyLr
7XgbHtcPOFD3OYi9TtLm41SQL1eNU0R+4goT+5vnINWrIO1yX1XnLJg604d/KIfbLvkINKna
I7kwVXba6+cb1B6i+byZD6eijUcaTqZNg+UBE9sNzvAV/FnLNT9zzrDoy+0QcENZEK9bB/2I
o38vdv5AL7iT8MVfNiEmzqUzmg9iXnw//WC9uTudoKmvXtcK1BprQNCEPDNcUlSw6yQCFAHw
rKfsBqH+X32xstxUPy8MmGicnI0StY06nFCn

--B_3583312112_1313426452--


From nobody Wed Jul 19 09:35:39 2017
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 E6569131472 for ; Wed, 19 Jul 2017 09:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 ahBvLao-tYuE for ; Wed, 19 Jul 2017 09:35:36 -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 6DCF912F3CB for ; Wed, 19 Jul 2017 09:35:36 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id v193so2733453ywg.2 for ; Wed, 19 Jul 2017 09:35:36 -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=Qa89sV6rKVUO2NXoAWnS60CHcJcI9iLQ8nb1fSkpzgM=; b=r7hMRYlXmNwo1WfM9hfekTW5ju4sqD04B4UG8d2s38zOgmeyQBmYKRaRwxIq/U6pZY hbuyW8LEt5y5/o07/Tpe6pb6pCc2ts1c0cQMcelRzlHzb8Dva/5vGupZXeUw7GQajSVS EddFltyQGPbHWXrVpcVB7rgnya/tXEGVGlxuRU7+tXki8CUn3cE8vijdOuf97Fye4rGP /ntDR0nYat2gYteBukUP1zGrAp/tWKPnbvG92UzcQVr4QkQ5FfvrndNkTLZgGy3VsL9c 8U0+Rgx6bLMhoG9RnEXI9De++edvNiQJ9QKVpOA51b2A0ZNEKUojes5qmBUkC88PsBEP ffNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qa89sV6rKVUO2NXoAWnS60CHcJcI9iLQ8nb1fSkpzgM=; b=DRaeMx+n8ppkvf3z5p+xxTIKbAQud1e5y1LBQ1kcaCUTt3PO5OJS/68u2MFZ9AIe65 gbQ1D9YUos1+fJG3AeMrIn+5YePrU7Ooq+RCF1VymhLeoYu8jkIor9hZWOMMJxaP+FQ4 FrDGr3Xh6iE8oQ4jqg6ybrlCOEtfrAKxmxAR7ASbFoI66HFQmpcjPR9SHiiPivgS1fcM AEvFMEl4Y8Ph7atQDHoBrs98Q/Bn6mIAjxgGsuheWqNqu3kh5AAmGmsWPHSAyQ6UFlMB vARidyfN5l5ZlzNOa3qAc1jPQyi/RNEdb1wBGjFToeZu7vr9brLwp5Hai/pxqPFuQ5OB jJIQ==
X-Gm-Message-State: AIVw113Ck6+qvBw/7g/KjWIRE4qL2n52hAF7VqaNv1xfxwCN4eiOPm6P p+lpUDwFHL7DVzKH47/qLrLblLH24Qya
X-Received: by 10.129.182.77 with SMTP id h13mr756185ywk.90.1500482135563; Wed, 19 Jul 2017 09:35:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Wed, 19 Jul 2017 09:35:34 -0700 (PDT)
In-Reply-To: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>     
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 19 Jul 2017 09:35:34 -0700
Message-ID: 
To: "Blumenthal, Uri - 0553 - MITLL" 
Cc: "tls@ietf.org" , Watson Ladd 
Content-Type: multipart/alternative; boundary="94eb2c1cbeb0aecac10554ae38fc"
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 16:35:38 -0000

--94eb2c1cbeb0aecac10554ae38fc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 19, 2017 at 9:26 AM, Blumenthal, Uri - 0553 - MITLL <
uri@ll.mit.edu> wrote:
>
> Same question. At some point in time you need to decide to start examinin=
g
> all the traffic. At that point you can start capturing its plaintext. The
> proposed alternative seems to be capturing the ciphertext and the key so
> the ciphertext can be decrypted later =E2=80=93 which makes no sense to m=
e.
>

That's not what I've seen. Instead, I see administrators creating port
mirrors on demand and then filtering the traffic they are interested in
using standard tcpdump rules, and I see MITM boxes that selectively decrypt
some traffic to look inside it and apply some kind of security filtering.
In the former case, DNS lookups and IP/port destinations are commonly used
to trigger some suspicions too.


> They are, though it's a big change. I think we can do better than logs; a
> mechanism that's in TLS itself could be opt-in and user-aware, and so les=
s
> likely to be abused in other situations. There's also some basic security
> model advantages to encrypting the PMS under a public-private key pair, a=
nd
> one that isn't using the private key that the servers themselves hold.
>
>
>
> To use the key you need to have the corresponding ciphertext stored.
>

That's not how the tcpdump/wireshark approach usually works. You give it
the private key and decrypts the TLS connection as it's happening.

--=20
Colm

--94eb2c1cbeb0aecac10554ae38fc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Jul 19, 2017 at 9:26 AM, Blumenthal, Uri - 0553 - MITLL <uri@ll.m=
it.edu> wrote:
Same question. At some point in time you need to decide to start =
examining all the traffic. At that point you can start capturing its plaint=
ext. The proposed alternative seems to be capturing the ciphertext and the =
key so the ciphertext can be decrypted later =E2=80=93 which makes no sense=
 to me.

That&#=
39;s not what I've seen. Instead, I see administrators creating port mi=
rrors on demand and then filtering the traffic they are interested in using=
 standard tcpdump rules, and I see MITM boxes that selectively decrypt some=
 traffic to look inside it and apply some kind of security filtering. In th=
e former case, DNS lookups and IP/port destinations are commonly used to tr=
igger some suspicions too.=C2=A0
=C2=A0=C2=A0
=

They are, though it&=
#39;s a big change. I think we can do better than logs; a mechanism that=
9;s in TLS itself could be opt-in and user-aware, and so less likely to be =
abused in other situations. There's also some basic security model adva=
ntages to encrypting the PMS under a public-private key pair, and one that =
isn't using the private key that the servers themselves hold.=C2=A0<=
/u>
=
=C2=A0
To use the key you need to have the corresponding ciphe=
rtext stored. 

That's not how the tcpdump/wireshark approach usually works. You give =
it the private key and decrypts the TLS connection as it's happening.=
=C2=A0

-- 
Colm




--94eb2c1cbeb0aecac10554ae38fc--


From nobody Wed Jul 19 09:36:53 2017
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 82AE012F3CB for ; Wed, 19 Jul 2017 09:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 2PRjmL5u0Oby for ; Wed, 19 Jul 2017 09:36:45 -0700 (PDT)
Received: from Mail.Yoyodyne.COM (mail.yoyodyne.com [209.118.176.138]) by ietfa.amsl.com (Postfix) with SMTP id BBB28127077 for ; Wed, 19 Jul 2017 09:36:45 -0700 (PDT)
Received: from [IPv6:2001:67c:370:128:bc7d:c18e:bcce:7d9f] ([2001:67c:370:128:bc7d:c18e:bcce:7d9f]) by Mail.Yoyodyne.COM via Internet for ; Wed, 19 Jul 2017 09:36:45 PDT
From: Derrell Piper 
Content-Type: multipart/alternative; boundary="Apple-Mail=_51B0CCF4-5AAA-4D51-8465-A985DFC73DEB"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 19 Jul 2017 18:36:40 +0200
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>   <76bb50c5-a699-4c91-7993-618acb365baf@zinks.de>  <09CF3C56-E9C7-4F02-8D1F-B5766CC9430C@gmail.com>
To: "tls@ietf.org" 
In-Reply-To: <09CF3C56-E9C7-4F02-8D1F-B5766CC9430C@gmail.com>
Message-Id: <0479B834-8E93-4590-B091-AD45CDDC812C@electric-loft.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 16:36:51 -0000

--Apple-Mail=_51B0CCF4-5AAA-4D51-8465-A985DFC73DEB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 19, 2017, at 6:02 PM, Yoav Nir  wrote:
>=20
> At the very least, a standards-track multi-party protocol like that =
can be something that standards like PCI, HIPAA and others can latch on =
to and say =E2=80=9CDo TLS 1.3 without backdoors unless you really need =
to and in that case use *this*=E2=80=9D.
>=20
> That is better guidance than =E2=80=9CDo TLS 1.3 without backdoors, =
unless you really need to and in that case do whatever works for you=E2=80=
=9D

Yes, that=E2=80=99s what I would like to see after today=E2=80=99s =
meeting too.=

--Apple-Mail=_51B0CCF4-5AAA-4D51-8465-A985DFC73DEB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Jul 19, 2017, at 6:02 PM, Yoav Nir <ynir.ietf@gmail.com>=
 wrote:

At the very least, a =
standards-track multi-party protocol like that can be something that =
standards like PCI, HIPAA and others can latch on to and say =E2=80=9CDo =
TLS 1.3 without backdoors unless you really need to and in that case use =
*this*=E2=80=9D.

That is better guidance than =
=E2=80=9CDo TLS 1.3 without backdoors, unless you really need to and in =
that case do whatever works for you=E2=80=9D

Yes, that=E2=80=99s what I would like to see after =
today=E2=80=99s meeting too.
=

--Apple-Mail=_51B0CCF4-5AAA-4D51-8465-A985DFC73DEB--


From nobody Wed Jul 19 09:50:14 2017
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 7E83412EBF4 for ; Wed, 19 Jul 2017 09:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk4veqLfuN_J for ; Wed, 19 Jul 2017 09:50:10 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA09129482 for ; Wed, 19 Jul 2017 09:50:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28470BE4D; Wed, 19 Jul 2017 17:50:07 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJuLLq3KLIlJ; Wed, 19 Jul 2017 17:50:05 +0100 (IST)
Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A484BE2D; Wed, 19 Jul 2017 17:50:05 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500483005; bh=51G7VZYJNTM8n0vGD8kCIhmcyqJjVshJmk+ckqXv5rI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=0UtiNR7R5UWfbsYVFW7PbXBakkIGg+aKZcLG+ns6t2J+rBXdITHYIX914zxCOaCoC 1EGub0ByZxhY1FZ5U3oFAn4NI5qjcartRWN5+KXYmoaJhBriRDRL3M+i33Aluz5RHX 9FDQ/wkOU/Urb8cF5q1RzfOTGakaBcQ68rLrW8Lo=
To: Benjamin Kaduk , "" 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie>
Date: Wed, 19 Jul 2017 17:49:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3pvikXueKLfNmLM8pJGHbxRgBPmHHmoWA"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 16:50:12 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--3pvikXueKLfNmLM8pJGHbxRgBPmHHmoWA
Content-Type: multipart/mixed; boundary="70hAFUeuVUuqqfW7U9W1BBh4tdgmokXXJ";
 protected-headers="v1"
From: Stephen Farrell 
To: Benjamin Kaduk , "" 
Message-ID: <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
In-Reply-To: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>

--70hAFUeuVUuqqfW7U9W1BBh4tdgmokXXJ
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 19/07/17 14:09, Benjamin Kaduk wrote:
> As Stephen noted in his presentation, a lot of the proposals for passiv=
e
> decryption can be seen as trying to turn TLS from a two-party protocol
> into a three-party protocol.  Which is probably the right way to think
> about it, even when all (three) parties are within the same
> administrative domain.
>=20
> Stephen also said something about it being hard to shoehorn a
> three-party protocol into the API for a two party protocol.  But
> depending on the specifics, maybe it's not so bad.  For example, if the=

> only semantics you need are a new API for "this is the list of third
> parties I authorize to wiretap this connection", the scope seems fairly=

> limited.

I would question the size of the set of applications for which the
semantics of such a list/interface could make sense. For example,
asking a person if they're ok with some random IPv6 address spying
on a TLS session makes zero sense for example.

Cheers,
S.

>=20
> Another thought spawned from today's session is that, given concerns
> about preventing/noticing if schemes intended for the datacenter leak
> out onto the internet, it's not really clear that "minimizes changes to=

> the wire protocol" should be considered a benefit of proposals in this
> space.  If there are clear changes to the wire protocol, that makes it
> easy to detect when the scheme is in use.
>=20
> -Ben
>=20
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>=20


--70hAFUeuVUuqqfW7U9W1BBh4tdgmokXXJ--

--3pvikXueKLfNmLM8pJGHbxRgBPmHHmoWA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZb42kAAoJEC88hzaAX42inKQH/1+ynQP99V0botonYz1l1QfR
yfjbBlohRG0ykObAlOZa2uSDO5a4Fpjdib0BEX6n3F+s0o2rR4XR81Rz1wGDhtvh
or6UbTOoybH+9trL/uXreh+YhmJ9S6jG5blloKxmsJjkvigI7k6SUXxqj112wLVQ
+Z3kluCRHL7Qp3nVGvfo5IikKQuO/3PkrK84iGFnUk/8xTjc/T2OcW1cvwZnbzh2
GorxDTb3zyj/tcT1MpMx2hVK69nek6TvelY1iTFwZCof/gcfDULlG37GCBV6Ckik
LDHktR7g64hUHuuOPd3w2sYAnrc7y14vsiUsQj5oKyxnHH1ykdDsT/4D+AWzk78=
=gDSQ
-----END PGP SIGNATURE-----

--3pvikXueKLfNmLM8pJGHbxRgBPmHHmoWA--


From nobody Wed Jul 19 09:52:41 2017
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 A2D92131A7D for ; Wed, 19 Jul 2017 09:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 6GQcL9WWi41G for ; Wed, 19 Jul 2017 09:52:37 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0135.outbound.protection.outlook.com [104.47.38.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED859129482 for ; Wed, 19 Jul 2017 09:52:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GbjyLrlMGhupM+hlMYsms4XQigQEKU93AdzHVZwYFa4=; b=XVk+zf7anl84DABWnnwqHClb2be0BxEzOWw+vOXsmt7l15nEX07pW+s1W0bPGhvR9Rgb+qy2s+Y/iUyZVSE3iXWDPLQIE+hSjZohtT2zqjjQ1dhTEar9S3k954F1gjShhI9QBADjzKwc17+0ruzMJ8eg3WY495QkV3nu2m3V/+E=
Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1038.prod.exchangelabs.com (10.160.129.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 16:52:35 +0000
Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 16:52:34 +0000
From: "Dobbins, Roland" 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulnreU48MdBA0WwDcIvwebnRKJYYxaAgAB6VYCAAmD9gIAAGYsAgAAB3ICAAAJ0AIAABMBa
Date: Wed, 19 Jul 2017 16:52:34 +0000
Message-ID: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>     , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none;allcosts.net; dmarc=none action=none header.from=arbor.net;
x-originating-ip: [88.208.89.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1038; 7:QJAUNeAxXmBqu9Ng0RfR13V6zNXSYhj3FgOyC4t1e5y1BkB71jjsEtcG+lXZMg+v9QYkKDO23BTLFCcUMfB2+jj9aMCBb0B28N7/Tg+lglPN8eoliEM2WD/pmZG1ZPBuwc5MkCYKwO0DsZW5c1VZkC6/hojKehqdQfONQ63TaB+UrSgkpGmNcKBsXtmtsRBMv6hKdcM0VfTqj5XXBNw+jr8varIGSzK4YAme0VNKOVgmPJe5rq5DF53cfN3C6CURs2JABS0D4Zqkdm1H8osaROJnzqOboarZYX/5XZJ4zIzUZX+/bG21Dpol/so56RjoWV4Rr3db75zOi23BowElyzxsj9OfJZiU8YgLMkO/99XP4B3ezUxtgrWn4KBbg1+ZX6FfhsB2k3eJM9TtBYVeS4Rs3n+vY2hTAlbSR+B6mMe1CTbfYsRguZKiDTPY6NMLIQAiKCunWCjyNBNwRInA5BFURKCuxaVc7za57MYdhLbcp/zeJMsv11BTci3ET6qfQDNFGEEmNw3ee76i6ME+Rw3FQ3gVAXunIrUh/zgDqfPc5j5/nfEe6O15M46gtWcA3GTqQAreHfQq41AoR61QA+Q0p4SYfgOyhSbxQIPs/8kO7vP0dYKyh1sFsmRRgZ7OQiX9a0YDokSRDR7tyVgNJ51KAHZ5GOygvYT+hR9zA8pSJCNJ8ijvSe4nJpYN+LZhp+07uWh1RHj0GCyymnCe3yUVc90k3ewRIqKKzsDzg9gmigN3kRV0AYgJRSGUu02+Zyef2N/M3YepZyjor7ET5oMw/e50JLbT70oRYUYdjG8=
x-ms-office365-filtering-correlation-id: 2138e280-47a6-4357-5243-08d4cec68dfe
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1038; 
x-ms-traffictypediagnostic: DM2PR0101MB1038:
x-exchange-antispam-report-test: UriScan:(236129657087228)(192374486261705)(17755550239193); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1038; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1038; 
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39400400002)(39840400002)(24454002)(66066001)(99286003)(54906002)(6436002)(2950100002)(189998001)(82746002)(2906002)(6512007)(83716003)(6916009)(86362001)(3846002)(6116002)(102836003)(6486002)(33656002)(478600001)(2900100001)(14454004)(6506006)(305945005)(7736002)(3660700001)(230783001)(93886004)(38730400002)(6246003)(110136004)(4326008)(5660300001)(8676002)(53936002)(53546010)(5250100002)(81166006)(25786009)(36756003)(50986999)(76176999)(3280700002)(54356999)(229853002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1038; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 16:52:34.5621 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1038
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 16:52:40 -0000

DQoNCj4gT24gSnVsIDE5LCAyMDE3LCBhdCAxODozNSwgQ29sbSBNYWNDw6FydGhhaWdoIDxjb2xt
QGFsbGNvc3RzLm5ldD4gd3JvdGU6DQo+IA0KPiBUaGF0J3Mgbm90IHdoYXQgSSd2ZSBzZWVuLiBJ
bnN0ZWFkLCBJIHNlZSBhZG1pbmlzdHJhdG9ycyBjcmVhdGluZyBwb3J0IG1pcnJvcnMgb24gZGVt
YW5kIGFuZCB0aGVuIGZpbHRlcmluZyB0aGUgdHJhZmZpYyB0aGV5IGFyZSBpbnRlcmVzdGVkIGlu
IHVzaW5nIHN0YW5kYXJkIHRjcGR1bXAgcnVsZXMsIGFuZCBJIHNlZSBNSVRNIGJveGVzIHRoYXQg
c2VsZWN0aXZlbHkgZGVjcnlwdCBzb21lIHRyYWZmaWMgdG8gbG9vayBpbnNpZGUgaXQgYW5kIGFw
cGx5IHNvbWUga2luZCBvZiBzZWN1cml0eSBmaWx0ZXJpbmcuIEluIHRoZSBmb3JtZXIgY2FzZSwg
RE5TIGxvb2t1cHMgYW5kIElQL3BvcnQgZGVzdGluYXRpb25zIGFyZSBjb21tb25seSB1c2VkIHRv
IHRyaWdnZXIgc29tZSBzdXNwaWNpb25zIHRvby4gDQoNCkNvcnJlY3QuDQoNCj4gVGhhdCdzIG5v
dCBob3cgdGhlIHRjcGR1bXAvd2lyZXNoYXJrIGFwcHJvYWNoIHVzdWFsbHkgd29ya3MuIFlvdSBn
aXZlIGl0IHRoZSBwcml2YXRlIGtleSBhbmQgZGVjcnlwdHMgdGhlIFRMUyBjb25uZWN0aW9uIGFz
IGl0J3MgaGFwcGVuaW5nLg0KDQpDb3JyZWN0LiANCg0KRXgtcG9zdC1mYWN0byBpcyBpbnN1ZmZp
Y2llbnQgdG8gcHVycG9zZS4gIFJlYWwtdGltZSBpcyB0aGUgZm9jdXMuICBBcmNoaXZpbmcgaXMg
cmFyZWx5IGRvbmUsIGFuZCBpcyB0eXBpY2FsbHkganVzdCBzbmlwcGV0cyByZXByZXNlbnRhdGl2
ZSBvZiB0aGUgaW5jaWRlbnQgaW4gcXVlc3Rpb24uIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD4NCg0K


From nobody Wed Jul 19 09:59:04 2017
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 25EDB129482 for ; Wed, 19 Jul 2017 09:59: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, 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=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 dHNB4dHsVAxy for ; Wed, 19 Jul 2017 09:59:01 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 AC8CA128C81 for ; Wed, 19 Jul 2017 09:59:01 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6JGVvLC017154; Wed, 19 Jul 2017 17:58:55 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=j1P9XJIuqY/Ha7ikn31SIc68dg3yrfiD2/reZHUVB+U=; b=i6ROmzBDTo8Z8g1CArAofcM7qXdrGdDoaolP09cZsOMMTFc4y5HYtbf2W9L0ANaXf0vo lwVLFdUiepVfOqzgNtHQVkUNoOXCV/c3R4B5r/KSi5tq7RP/n2w0LlmxBdnw9fUCSueK v7egaksNuWX+bZ9Dl9MW4zqb6bhZXCakjc+Jl+Qs0bCM6wK5jV8QZDIBEyvjzl48vcgp AmdrHQVTkrvD/OLdiRb97nbwWwfhcL/dtpYkcbsoO8v/A3nkFYG+TjrYDXcKO4QKlUmJ xHxbzMIfov00uGLMJ27vJevi2VkEYaDIV6g2tpeopKDNYFrXpeHchF6RFNEQCdmfLDzi sg== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bt1abt9q4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 17:58:54 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6JGaVUF031919; Wed, 19 Jul 2017 12:58:53 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecud0ys-1; Wed, 19 Jul 2017 12:58:53 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 523FA1FC71; Wed, 19 Jul 2017 16:58:53 +0000 (GMT)
To: Stephen Farrell , "" 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie>
From: Benjamin Kaduk 
Message-ID: <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com>
Date: Wed, 19 Jul 2017 11:58:52 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="------------78A896BA47A28AB8E9FC40C6"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707190274
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707190273
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 16:59:03 -0000

This is a multi-part message in MIME format.
--------------78A896BA47A28AB8E9FC40C6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/19/2017 11:49 AM, Stephen Farrell wrote:
>
> On 19/07/17 14:09, Benjamin Kaduk wrote:
>> As Stephen noted in his presentation, a lot of the proposals for passive
>> decryption can be seen as trying to turn TLS from a two-party protocol
>> into a three-party protocol.  Which is probably the right way to think
>> about it, even when all (three) parties are within the same
>> administrative domain.
>>
>> Stephen also said something about it being hard to shoehorn a
>> three-party protocol into the API for a two party protocol.  But
>> depending on the specifics, maybe it's not so bad.  For example, if the
>> only semantics you need are a new API for "this is the list of third
>> parties I authorize to wiretap this connection", the scope seems fairly
>> limited.
> I would question the size of the set of applications for which the
> semantics of such a list/interface could make sense. For example,
> asking a person if they're ok with some random IPv6 address spying
> on a TLS session makes zero sense for example.
>

Sure, some random IPv6 address makes no sense, and is not
cryptographically bound to anything.
On the other hand, "this (semi-)static DH key is one currently used by
my enterprise's network monitoring system, and is allowed to read my
traffic" seems closer to what is being asked for.

As has been said downthread, the recommendation is not "you should
always use this thing", it's "you should do TLS 1.3 without backdoors,
but if you really need to, this is a way to do so with known and limited
properties".

-Ben

-Ben

--------------78A896BA47A28AB8E9FC40C6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 07/19/2017 11:49 AM, Stephen Farrell wrote:

    

      

On 19/07/17 14:09, Benjamin Kaduk wrote:


      

        
As Stephen noted in his presentation, a lot of the proposals for passive
decryption can be seen as trying to turn TLS from a two-party protocol
into a three-party protocol.  Which is probably the right way to think
about it, even when all (three) parties are within the same
administrative domain.

Stephen also said something about it being hard to shoehorn a
three-party protocol into the API for a two party protocol.  But
depending on the specifics, maybe it's not so bad.  For example, if the
only semantics you need are a new API for "this is the list of third
parties I authorize to wiretap this connection", the scope seems fairly
limited.


      

      
I would question the size of the set of applications for which the
semantics of such a list/interface could make sense. For example,
asking a person if they're ok with some random IPv6 address spying
on a TLS session makes zero sense for example.



    

    

    Sure, some random IPv6 address makes no sense, and is not
    cryptographically bound to anything.

    On the other hand, "this (semi-)static DH key is one currently used
    by my enterprise's network monitoring system, and is allowed to read
    my traffic" seems closer to what is being asked for.

    

    As has been said downthread, the recommendation is not "you should
    always use this thing", it's "you should do TLS 1.3 without
    backdoors, but if you really need to, this is a way to do so with
    known and limited properties".

    

    -Ben

    

    -Ben

  


--------------78A896BA47A28AB8E9FC40C6--


From nobody Wed Jul 19 10:11:02 2017
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 E7CAE131472 for ; Wed, 19 Jul 2017 10:11:01 -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 s67waaKnvtZs for ; Wed, 19 Jul 2017 10:11:00 -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 8B47512EC3F for ; Wed, 19 Jul 2017 10:11:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B7BAE3004CB for ; Wed, 19 Jul 2017 13:10:59 -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 CBecaePugCAI for ; Wed, 19 Jul 2017 13:10:59 -0400 (EDT)
Received: from [5.5.33.118] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 99843300285 for ; Wed, 19 Jul 2017 13:10:58 -0400 (EDT)
From: Russ Housley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: 
Date: Wed, 19 Jul 2017 13:10:56 -0400
To: IETF TLS 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:11:02 -0000

The hum told us that the room was roughly evenly split.  In hind sight, =
I wish the chairs had asked a second question.  If the split in the room =
was different for the second question, then I think we might have =
learned a bit more about what people are thinking.

If a specification were available that used an extension that involved =
both the client and the server, would the working group adopt it, work =
on it, and publish it as an RFC?

I was listening very carefully to the comments made by people in line.  =
Clearly some people would hum for "no" to the above question, but it =
sounded like many felt that this would be a significant difference.  It =
would ensure that both server and client explicitly opt-in, and any =
party observing the handshake could see the extension was included or =
not.

Russ=


From nobody Wed Jul 19 10:15:19 2017
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 1B7CA131B54 for ; Wed, 19 Jul 2017 10:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 yLYCqWKArRrP for ; Wed, 19 Jul 2017 10:15:06 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4013A131474 for ; Wed, 19 Jul 2017 10:15:05 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6JHF49m035904 for ; Wed, 19 Jul 2017 13:15:04 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulwkltwWiCLAkez9/LKtukmkaJYpiSAgAAE/ICAAtZXgIAAGYoA//++zoCAAEWCAIAABMAA///DOoA=
Date: Wed, 19 Jul 2017 17:15:03 +0000
Message-ID: <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583314903_2066918823"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707190274
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:15:12 -0000

--B_3583314903_2066918823
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

>> That's not what I've seen. Instead, I see administrators creating port m=
irrors on demand and then
>> filtering the traffic they are interested in using standard tcpdump rule=
s, and I see MITM boxes
>> that selectively decrypt some traffic to look inside it and apply some k=
ind of security filtering.
>> In the former case, DNS lookups and IP/port destinations are commonly us=
ed to trigger some suspicions too.=20
>  Correct.

Yes I realize all that. That is the =E2=80=9Ctraditional=E2=80=9D way.

My point is that if you own/control the endpoint, then it doesn=E2=80=99t matter =
from the architecture point of view where you tap =E2=80=93 and if TLS is not brok=
en (i.e., does not allow you to =E2=80=9Cselectively decrypt=E2=80=9D) you can tap the p=
laintext at the endpoint. You just need a different set of tools. But consid=
ering how today=E2=80=99s endpoints are loaded with tons and tons of =E2=80=9Csecurity s=
oftware=E2=80=9D, it seems rather straightforward.=20

It=E2=80=99s not like you have an opaque endpoint, and the switch is the only pla=
ce your visibility starts.
   =20
>> That's not how the tcpdump/wireshark approach usually works. You give it=
 the private key and
>> decrypts the TLS connection as it's happening.
>
>  Correct.=20
> Ex-post-facto is insufficient to purpose.  Real-time is the focus.  Archi=
ving is rarely done,
> and is typically just snippets representative of the incident in question=
.=20

Yes. The contention is between being able to decrypt already-encrypted traf=
fic on-demand, and being able to tap the traffic before the encryption (or a=
fter the decryption) on-demand.

Your current tools to the first. Evolvement of the technology is pushing yo=
u towards the second. Arguing against it IMHO would have as much effect as a=
rguing against exporting strong crypto had decades ago. Or are you simply tr=
ying to delay the inevitable?
=20

--B_3583314903_2066918823
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU
WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO
DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A
97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN
YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR
COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x
dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01
c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ
KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G
/F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL
e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c
A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgvr5RvGjDlVxa51Pn
VLCoPYpZC+rb7wLJQsJXLSDZ2k0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE5MTcxNTAzWjANBgkqhkiG9w0BAQEFAASCAQBySGNhphO/oqcZ3ejV
E9NY0rlMysgXXNk0BIWqDpIz1atPY1HOlOyLVUeL55DdGFMtaT0QysGcLJ3I3IoQ9w3E9YTi
z+7P8EL4vRXX/Vgrv826pwh/beggba7BtWTYcA5BUDVinIoelZhKi76FAiTGRGq1yGN8co2Z
uN+739o3JJdAcChrqvsKgj3ab9/qUHH3yU4vriarbGhvR2rWcjIBWNBkLilFx94YafT2YKtH
96xXyv+B4zJGapI1O7BDslFTISfyHTt3Np8WP6W5mmqvklyJN96KbwfhOnUg8Qy5QlJWWbjp
NtlCsIyXzWa9DhNJVoPogAXhQnZ0NhX9nblU

--B_3583314903_2066918823--


From nobody Wed Jul 19 10:15:34 2017
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 1E5EA131474 for ; Wed, 19 Jul 2017 10:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6RpUksLIFYqO for ; Wed, 19 Jul 2017 10:15:28 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF24D131B84 for ; Wed, 19 Jul 2017 10:15:27 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id y129so2878433pgy.4 for ; Wed, 19 Jul 2017 10:15:27 -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=j0sQRgOLncm54rDtzl28UOOSg4rYkVvW5rvrdrhIGwE=; b=jFKKkLus9y9tZu/f3uXgpUP+6GNfVuXK8bqo821EGkSIaNc0LPeDxEYjOF4HvYud8H YISPwROkehz1oxJQZGSlyTul2TKBO2wR/JKCfq4wIL1KflngVlRaVIwfCyiFuVwSwlPk 2bDSBjxapIElaSQDGOc5MwOS7mgIxU+CFh3jx4kz9tB/6Ow2YtWVULc4+OsZ06kKxJ9o hUgzt9XpoWnhTmtng85pNgh11jxnkS3AUz6PnxoJALJd6QhA+KfEKkVgaHTdkLL3KRI7 HxCoNh556xnJHnFTn61iPa8yNyCyYhELZqlXJ4GjHpmrKOJMFIRfpHvQcjykkhDHIY2j BLHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j0sQRgOLncm54rDtzl28UOOSg4rYkVvW5rvrdrhIGwE=; b=s4m0G9zJSXojQEkdFAZEjUZYkE0kh1A0hM4gz302hsdk6XeSlFQKgpM80ESZiID5fP RhMGO7Z3+d0jygRVEWNZkOhXLVp0f5INiZe1rPmX6Hnda9Sw/G/vppBYbv+YyAfda7FV DTIsLL6y/h/t/vOSscJAht8mZ1Xu7kz031IADljRcHf73Qymi75WL59lIKgU+nHeyfs4 nk4oFmwQxKJA9N3BcPFSJCorG4jaE3RXb0MoSd2tHKYrybmeb3fgBqnPIvuXKeS/52+d DzoHBf/ZY+UwnZQwGvzKtNAVJHSg8Fax45UcnG7iLWlZqcMDGTxd+DPWMN94kEIW5Pu0 xUgQ==
X-Gm-Message-State: AIVw113w6cOSc+mKt1BWa9VB0DzRTHiLjIYgCQy2GMd27GtRhHkcJxH0 e0pq8i+zUiEGZISrGcUnNf17WEtJiPzb
X-Received: by 10.99.43.5 with SMTP id r5mr784508pgr.135.1500484527439; Wed, 19 Jul 2017 10:15:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 10:14:46 -0700 (PDT)
In-Reply-To: 
References: 
From: Ted Lemon 
Date: Wed, 19 Jul 2017 19:14:46 +0200
Message-ID: 
To: Russ Housley 
Cc: IETF TLS 
Content-Type: multipart/alternative; boundary="001a1146e2e03fd7870554aec715"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:15:33 -0000

--001a1146e2e03fd7870554aec715
Content-Type: text/plain; charset="UTF-8"

Provably involved, or involved setting an evil bit?

On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley  wrote:

> The hum told us that the room was roughly evenly split.  In hind sight, I
> wish the chairs had asked a second question.  If the split in the room was
> different for the second question, then I think we might have learned a bit
> more about what people are thinking.
>
> If a specification were available that used an extension that involved
> both the client and the server, would the working group adopt it, work on
> it, and publish it as an RFC?
>
> I was listening very carefully to the comments made by people in line.
> Clearly some people would hum for "no" to the above question, but it
> sounded like many felt that this would be a significant difference.  It
> would ensure that both server and client explicitly opt-in, and any party
> observing the handshake could see the extension was included or not.
>
> Russ
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a1146e2e03fd7870554aec715
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Provably involved, or involved setting an evil bit?
<=
div class=3D"gmail_extra">
On Wed, Jul 19, 20=
17 at 7:10 PM, Russ Housley <housley@vigilsec.com> wrote:=

The hum told us that the room was roughl=
y evenly split.=C2=A0 In hind sight, I wish the chairs had asked a second q=
uestion.=C2=A0 If the split in the room was different for the second questi=
on, then I think we might have learned a bit more about what people are thi=
nking.



If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?



I was listening very carefully to the comments made by people in line.=C2=
=A0 Clearly some people would hum for "no" to the above question,=
 but it sounded like many felt that this would be a significant difference.=
=C2=A0 It would ensure that both server and client explicitly opt-in, and a=
ny party observing the handshake could see the extension was included or no=
t.



Russ

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a1146e2e03fd7870554aec715--


From nobody Wed Jul 19 10:27:25 2017
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 4E9B3131B39 for ; Wed, 19 Jul 2017 10:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chxvC3paOFcN for ; Wed, 19 Jul 2017 10:27:22 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B25131A4F for ; Wed, 19 Jul 2017 10:27:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3CAE8BE50; Wed, 19 Jul 2017 18:27:20 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZrkHvJMh9Pc; Wed, 19 Jul 2017 18:27:17 +0100 (IST)
Received: from [31.133.148.54] (dhcp-9436.meeting.ietf.org [31.133.148.54]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 135E3BE55; Wed, 19 Jul 2017 18:27:17 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500485237; bh=cedYfUZT18/D1YOT8uf1cVTyNZ82RHeKhL49i66k3x4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QHbF+VQuQbuk+PA72Z/Qf0nKqSrcymOeeJaPs+c574vRryYH1ABPXmubiRv/SMGEy rrCRgd3+VMZgyHOpzwzrHFMbNp3aJ10nq/OOo/x2jfe5wfGJRLB/oQ5Ww/R9JSH0ze dl5VB0iQTtYkvsfO8DBl12wkqw79BerAuCbZ/GAY=
To: Russ Housley , IETF TLS 
References: 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <1677ecdf-411d-30ac-089f-5e00e9370552@cs.tcd.ie>
Date: Wed, 19 Jul 2017 18:27:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AHK21spORvSnKwJp0JAjeLCjKDKAgD5xh"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:27:24 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--AHK21spORvSnKwJp0JAjeLCjKDKAgD5xh
Content-Type: multipart/mixed; boundary="7bh2KtKOVMoQW2R110nespQcvW9JWgnT2";
 protected-headers="v1"
From: Stephen Farrell 
To: Russ Housley , IETF TLS 
Message-ID: <1677ecdf-411d-30ac-089f-5e00e9370552@cs.tcd.ie>
Subject: Re: [TLS] Is there a way forward after today's hum?
References: 
In-Reply-To: 

--7bh2KtKOVMoQW2R110nespQcvW9JWgnT2
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 19/07/17 18:10, Russ Housley wrote:
> The hum told us that the room was roughly evenly split.  In hind
> sight, I wish the chairs had asked a second question.  If the split
> in the room was different for the second question, then I think we
> might have learned a bit more about what people are thinking.
>=20
> If a specification were available that used an extension that
> involved both the client and the server, would the working group
> adopt it, work on it, and publish it as an RFC?

I would almost certainly be opposed. There are enough generic
reasons to not break tls to go around for us all.

S.

>=20
> I was listening very carefully to the comments made by people in
> line.  Clearly some people would hum for "no" to the above question,
> but it sounded like many felt that this would be a significant
> difference.  It would ensure that both server and client explicitly
> opt-in, and any party observing the handshake could see the extension
> was included or not.
>=20
> Russ _______________________________________________ TLS mailing
> list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>=20


--7bh2KtKOVMoQW2R110nespQcvW9JWgnT2--

--AHK21spORvSnKwJp0JAjeLCjKDKAgD5xh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZb5ZzAAoJEC88hzaAX42i5mUH/jwfrc08FW2PbfGpTqJo4oJZ
8zYl/KRrTFbcU6QjE1ROQbIEK5vqag40raUyojOMcWWF+NiYeTRc9GhAUTH3fuTN
yIV+nDg6/l8/Nnf46Y99eFgIZt3UydrzE3YChUAAKZKyeORcQOy3E86hmP/KWy+o
415NrqN4agFLPReEa7Zi8C9ieqgqdpiIssZ5OfKvGYRPDc84sHMAi9KM6j+L9b+3
gNSKC11ByphillufpgF5ZBo351mkdMUkiQW9M89hJ1zyDVSr+iW8pp1DZ0XEGBda
/mil5rAMvl/+ztbbvjpILHccrUSN6J3kY5qAMh8J0i0ATw72DXv6I8EQavMpyhU=
=6t0x
-----END PGP SIGNATURE-----

--AHK21spORvSnKwJp0JAjeLCjKDKAgD5xh--


From nobody Wed Jul 19 10:33:52 2017
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 0A67B131A63 for ; Wed, 19 Jul 2017 10:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8zMZboP5LZ8 for ; Wed, 19 Jul 2017 10:33:46 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD143131488 for ; Wed, 19 Jul 2017 10:33:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3E590BE53; Wed, 19 Jul 2017 18:33:44 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjKTZBJY5xAh; Wed, 19 Jul 2017 18:33:43 +0100 (IST)
Received: from [31.133.148.54] (dhcp-9436.meeting.ietf.org [31.133.148.54]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 91E13BE4D; Wed, 19 Jul 2017 18:33:42 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500485622; bh=uLOnWNG6NZysJKLg3Jo3KA/ftTADNfTP/ZU6NeKz7Lw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=TEtITiFWK7ULoywNtftakMbdreu/lLwFSCxzLOZXDWGQsemUHNQdIYAxA3X7hSu2i 24ScYnWa09cPMm3IYZiwF4eGoPJSjXHIwtIU0jogYDTEGFNFZmhNLeSnj7JcM3ldFh N+OmctXRGRh2kAt9zbzlbZ7hZ5yhxdMlEpWP9280=
To: Benjamin Kaduk , "" 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>
Date: Wed, 19 Jul 2017 18:33:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9BXlxb9IKrwc3HnXor7FlFNaL49NVA55F"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:33:49 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9BXlxb9IKrwc3HnXor7FlFNaL49NVA55F
Content-Type: multipart/mixed; boundary="BuSbKMRpSiTO5PvrsHnWDOkvF5Ap2EsTC";
 protected-headers="v1"
From: Stephen Farrell 
To: Benjamin Kaduk , "" 
Message-ID: <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
 <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie>
 <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com>
In-Reply-To: <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com>

--BuSbKMRpSiTO5PvrsHnWDOkvF5Ap2EsTC
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 19/07/17 17:58, Benjamin Kaduk wrote:
> On 07/19/2017 11:49 AM, Stephen Farrell wrote:
>>
>> On 19/07/17 14:09, Benjamin Kaduk wrote:
>>> As Stephen noted in his presentation, a lot of the proposals for pass=
ive
>>> decryption can be seen as trying to turn TLS from a two-party protoco=
l
>>> into a three-party protocol.  Which is probably the right way to thin=
k
>>> about it, even when all (three) parties are within the same
>>> administrative domain.
>>>
>>> Stephen also said something about it being hard to shoehorn a
>>> three-party protocol into the API for a two party protocol.  But
>>> depending on the specifics, maybe it's not so bad.  For example, if t=
he
>>> only semantics you need are a new API for "this is the list of third
>>> parties I authorize to wiretap this connection", the scope seems fair=
ly
>>> limited.
>> I would question the size of the set of applications for which the
>> semantics of such a list/interface could make sense. For example,
>> asking a person if they're ok with some random IPv6 address spying
>> on a TLS session makes zero sense for example.
>>
>=20
> Sure, some random IPv6 address makes no sense, and is not
> cryptographically bound to anything.
> On the other hand, "this (semi-)static DH key is one currently used by
> my enterprise's network monitoring system, and is allowed to read my
> traffic" seems closer to what is being asked for.

I don't know how that kind of identifier can be made meaningful
for almost any application where the identifier is not already
meaningful, and in many such cases I would guess there are
already hop-by-hop behaviours where TLS is not e2e for the
application layer (MTAs etc.) But sure, someone could do the
work to describe some applications that might have a need for
a multiparty security protocol like that I guess. As I said,
my guess is that the size of that set of applications is small.

>=20
> As has been said downthread, the recommendation is not "you should
> always use this thing", it's "you should do TLS 1.3 without backdoors,
> but if you really need to, this is a way to do so with known and limite=
d
> properties".

I can see why people might consider that some kind of compromise
that's less bad, but I think searching for "less bad" is not at all
the right approach. I don't mean that we oughtn't investigate
possible scenarios, but searching for a compromise is not in itself
a good goal here.

Cheers,
S.

>=20
> -Ben
>=20
> -Ben
>=20


--BuSbKMRpSiTO5PvrsHnWDOkvF5Ap2EsTC--

--9BXlxb9IKrwc3HnXor7FlFNaL49NVA55F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZb5f0AAoJEC88hzaAX42iEokH/itHIIsTJ6CS8w/fHq659mki
xyR49vi8gWfN4hl0sQMRr33xNZHxu95i6iuMsAXIoiKFt0rM+8CE6QQPlq4T6pBR
5LitmNICxIaao3veD9lxMjApjG+zTXlNnPKHYYoFEsjCtTeLyjGsNiqTnof8B3mp
6z3/8k+52l2jtbWFUPJqPZWpiYSw9wDB9hlTxmF7EB5mzXL7byPUiIZXbDGosewQ
++uBeJtQACx5A9ok/Ig2j+gZaDm5vvKeSsbp+y8zKfgjLW+4mJ2LDdlfpc//H8rP
gcEeLPrGd9VBto2Yq0haR16zRH4XSQ6zHPuYNp6p9q11E0m5XMs446L4AWA0R/Y=
=Idc+
-----END PGP SIGNATURE-----

--9BXlxb9IKrwc3HnXor7FlFNaL49NVA55F--


From nobody Wed Jul 19 10:39:33 2017
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 DE335131A50 for ; Wed, 19 Jul 2017 10:39:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TBynnbtaDV6p for ; Wed, 19 Jul 2017 10:39:25 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 497FF12EBF4 for ; Wed, 19 Jul 2017 10:39:25 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id e199so2640082pfh.2 for ; Wed, 19 Jul 2017 10:39:25 -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=VzG3RB8OCMxbBEoQt/nhmHCepe+Svaw2kWIJmsqHduA=; b=VYJtbPO2XH36vvwKEQIP/9F1z3xaoYgc+yDSf/oTqD+z04FYVxrhJpR5HL47gJA2ZC htuI7w4Mgfp3MlRH6h4xLtsEVQCgT61badrWAaAEHDxEZoCwFrLJv2ZTFv/qW59bfRsG hX7GORVhcP02jtkofhYGARzCaFJa/psZ4+Cop0Tn+pLjxzYI9pBqEE0fFzBlu0PQd7fD 0ygm74yPK5Cl7Kttl70BOmF6vBLUCx2RRYfw2Vr8mBTwir30XOrO+SZLDaPGRXysmzl7 HixovIvOsbgRF6d2JBYPygzTI/QuDS7k9uKsKRLvBJU4+7L5qofPKelaefNSEpa54fzh inhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VzG3RB8OCMxbBEoQt/nhmHCepe+Svaw2kWIJmsqHduA=; b=RAs53r/J/uPbpjPMIcl8/+ECk1o39zlTG1deZKejuH1LrLIHs3KuvaxESdkiTjzOjk h6hiuhj/0VMCpKEECYkiEqViqZS01afk/5PD8lDnHGwOQJfnttkE7EoIRLS2YzK1xvTl 9iJHyxScboaO9AzV2nh9NBwTqUPYpB6hFIAk29E2eWLtJcMuGEor2Ei+MOG2YtLixo/T HiXJ40Siyt/9p5xbGhrBt+tIux5w3Vflf9hWycCAzduA1kuMB1RKsxhQD0QqTsZsb04v D+t1cANR9SQvxVFqbEi+Ao5xLZNznN29oHoZPfcyWEYcjAcP1E1Ry8hA60aCtcYu//O1 033w==
X-Gm-Message-State: AIVw112/LScqvpmBCS948houHNp1OXHcvB0toE+YwacimY52oqCDRDs1 D2mDFf1gq8qforMph2txWFWOvFJdkbf/
X-Received: by 10.99.44.66 with SMTP id s63mr890907pgs.302.1500485964894; Wed, 19 Jul 2017 10:39:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 10:38:44 -0700 (PDT)
In-Reply-To: <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>
From: Ted Lemon 
Date: Wed, 19 Jul 2017 19:38:44 +0200
Message-ID: 
To: Stephen Farrell 
Cc: Benjamin Kaduk , "" 
Content-Type: multipart/alternative; boundary="001a113e48bcedabce0554af1c76"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:39:28 -0000

--001a113e48bcedabce0554af1c76
Content-Type: text/plain; charset="UTF-8"

The problem is that the actual solution to this problem is to accept that
you aren't going to be able to decrypt the streams, and then figure out
what to do instead.   Which is work the proponents of not doing that are
not interested in doing, understandably, and which is also not the work of
this working group.

I'm skeptical that there is a way for this working group to solve the
proposed problem, but if there is, it involves figuring out a way to do
this that doesn't make it easy to MiTM *my* connections, or, say, those of
activists in dangerous places.

On Wed, Jul 19, 2017 at 7:33 PM, Stephen Farrell 
wrote:

>
>
> On 19/07/17 17:58, Benjamin Kaduk wrote:
> > On 07/19/2017 11:49 AM, Stephen Farrell wrote:
> >>
> >> On 19/07/17 14:09, Benjamin Kaduk wrote:
> >>> As Stephen noted in his presentation, a lot of the proposals for
> passive
> >>> decryption can be seen as trying to turn TLS from a two-party protocol
> >>> into a three-party protocol.  Which is probably the right way to think
> >>> about it, even when all (three) parties are within the same
> >>> administrative domain.
> >>>
> >>> Stephen also said something about it being hard to shoehorn a
> >>> three-party protocol into the API for a two party protocol.  But
> >>> depending on the specifics, maybe it's not so bad.  For example, if the
> >>> only semantics you need are a new API for "this is the list of third
> >>> parties I authorize to wiretap this connection", the scope seems fairly
> >>> limited.
> >> I would question the size of the set of applications for which the
> >> semantics of such a list/interface could make sense. For example,
> >> asking a person if they're ok with some random IPv6 address spying
> >> on a TLS session makes zero sense for example.
> >>
> >
> > Sure, some random IPv6 address makes no sense, and is not
> > cryptographically bound to anything.
> > On the other hand, "this (semi-)static DH key is one currently used by
> > my enterprise's network monitoring system, and is allowed to read my
> > traffic" seems closer to what is being asked for.
>
> I don't know how that kind of identifier can be made meaningful
> for almost any application where the identifier is not already
> meaningful, and in many such cases I would guess there are
> already hop-by-hop behaviours where TLS is not e2e for the
> application layer (MTAs etc.) But sure, someone could do the
> work to describe some applications that might have a need for
> a multiparty security protocol like that I guess. As I said,
> my guess is that the size of that set of applications is small.
>
> >
> > As has been said downthread, the recommendation is not "you should
> > always use this thing", it's "you should do TLS 1.3 without backdoors,
> > but if you really need to, this is a way to do so with known and limited
> > properties".
>
> I can see why people might consider that some kind of compromise
> that's less bad, but I think searching for "less bad" is not at all
> the right approach. I don't mean that we oughtn't investigate
> possible scenarios, but searching for a compromise is not in itself
> a good goal here.
>
> Cheers,
> S.
>
> >
> > -Ben
> >
> > -Ben
> >
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a113e48bcedabce0554af1c76
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The problem is that the actual solution to this problem is=
 to accept that you aren't going to be able to decrypt the streams, and=
 then figure out what to do instead. =C2=A0 Which is work the proponents of=
 not doing that are not interested in doing, understandably, and which is a=
lso not the work of this working group.

I'm skeptica=
l that there is a way for this working group to solve the proposed problem,=
 but if there is, it involves figuring out a way to do this that doesn'=
t make it easy to MiTM my=C2=A0connections, or, say, those of activi=
sts in dangerous places.

On Wed, Jul 19, 2017 at 7:33 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:




On 19/07/17 17:58, Benjamin Kaduk wrote:

> On 07/19/2017 11:49 AM, Stephen Farrell wrote:

>>

>> On 19/07/17 14:09, Benjamin Kaduk wrote:

>>> As Stephen noted in his presentation, a lot of the proposals f=
or passive

>>> decryption can be seen as trying to turn TLS from a two-party =
protocol

>>> into a three-party protocol.=C2=A0 Which is probably the right=
 way to think

>>> about it, even when all (three) parties are within the same
>>> administrative domain.

>>>

>>> Stephen also said something about it being hard to shoehorn a<=
br>
>>> three-party protocol into the API for a two party protocol.=C2=
=A0 But

>>> depending on the specifics, maybe it's not so bad.=C2=A0 F=
or example, if the

>>> only semantics you need are a new API for "this is the li=
st of third

>>> parties I authorize to wiretap this connection", the scop=
e seems fairly

>>> limited.

>> I would question the size of the set of applications for which the=


>> semantics of such a list/interface could make sense. For example,<=
br>
>> asking a person if they're ok with some random IPv6 address sp=
ying

>> on a TLS session makes zero sense for example.

>>

>

> Sure, some random IPv6 address makes no sense, and is not

> cryptographically bound to anything.

> On the other hand, "this (semi-)static DH key is one currently us=
ed by

> my enterprise's network monitoring system, and is allowed to read =
my

> traffic" seems closer to what is being asked for.



I don't know how that kind of identifier can be made meaningful<=
br>
for almost any application where the identifier is not already

meaningful, and in many such cases I would guess there are

already hop-by-hop behaviours where TLS is not e2e for the

application layer (MTAs etc.) But sure, someone could do the

work to describe some applications that might have a need for

a multiparty security protocol like that I guess. As I said,

my guess is that the size of that set of applications is small.



>

> As has been said downthread, the recommendation is not "you shoul=
d

> always use this thing", it's "you should do TLS 1.3 with=
out backdoors,

> but if you really need to, this is a way to do so with known and limit=
ed

> properties".



I can see why people might consider that some kind of compromise

that's less bad, but I think searching for "less bad" is not =
at all

the right approach. I don't mean that we oughtn't investigate

possible scenarios, but searching for a compromise is not in itself

a good goal here.



Cheers,

S.



>

> -Ben

>

> -Ben

>




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a113e48bcedabce0554af1c76--


From nobody Wed Jul 19 10:43:47 2017
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 CC62012EBF4 for ; Wed, 19 Jul 2017 10:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 JArM9tyAOVMe for ; Wed, 19 Jul 2017 10:43:43 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0096.outbound.protection.outlook.com [104.47.34.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036B0129461 for ; Wed, 19 Jul 2017 10:43:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HG25VYj0J/CknLgr+aLzDTnMVJu7W7fUy3im/xrKguM=; b=dw+0AWAYO1JUbUEoY7IIJjctDQYBBXpyqyOqmx3de8gXWACY9kEQESFTXfSP8XKqcA1Rcf5dBlQxOEYnRunoLP1/+C1wnUmU/X+I87c2L+fYXJuCi+f4qF77p2BM9gJ0xncebsly+M3lDYslUbumdRhGXKyv1i46Mfnaoat2sLc=
Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1038.prod.exchangelabs.com (10.160.129.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 17:43:42 +0000
Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 17:43:41 +0000
From: "Dobbins, Roland" 
To: "Blumenthal, Uri - 0553 - MITLL" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulnreU48MdBA0WwDcIvwebnRKJYYxaAgAB6VYCAAmD9gIAAGYsAgAAB3ICAAAJ0AIAABMBagAAGSICAAAgAnw==
Date: Wed, 19 Jul 2017 17:43:41 +0000
Message-ID: <5E90933D-3D9F-4166-808D-7ECE53D264F4@arbor.net>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>       , <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu>
In-Reply-To: <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net;
x-originating-ip: [88.208.89.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1038; 7:iRXgpz7ZvoLdYfxwgU1v3f+4HQRSLt+M0zrlZMfsOhzFr7TMaND1JPSj4QOVjxxCQWU5BFTidBZB3Pr8LePs6pwaHKnvIr+/DTBgL854aYEEBu+f0JrL/TFuOOMu5BF1k7BlPH8x+l0KLjcA7JVzIBGU6zpRPzZBnIfUy89vgS/gk924/mRX8zZ078+RMwHvaAQa8FcRIf/WB0sLii6ReLvZxqUZjbWXADZCSgOopBTP8rAzGb8B92FtJRRl5m4xu1m7/4dnQETgww3o5NnWRp1mfFhVUjGkmBSOpAPfOgz2SwNaYpixAuuxp7fvu4c7mXBBfumEo9NceDiZwe/4sdUzuyfiuMupQWryTV4C05hQlEAAhy6cVi/zltsxEIaMuu9CrNqjhsInFhxskfVn+EP9Vh6Z9cS1gBZCSQz/gzBvxIIx92gY1/m51zfMtF6K7bcWb2BoKVo3Hotkqn5PxPmIVf2I/e3CxI1Bo+4t/6JV/ahkWdvmkd6ax/uAdFqWJZVflUadtZdt+eMluJCDGROdbJV5ymP9gRpdFSQAI4+6T5DV5ivG3nX3TsTiW5C2Q0ZwhNUS/YKmpuwl3Mr1NEb9GTpEmKwF01iCo5XRewe0pC+brVr+Vu5GMvWgiW0wIbTL6pp68h2XbDQT7dF7LmolZFgzCAqYns9nu+9EIxz3ZUAUwn1L+pHfPD0jOvy0FyaY4KWUpMEum2zR8LLrvsAiprcDfE2ZiSDacxRrP4S2r8JzgUXONtBPLFx7h6GioG5u7oMYXko6avce/ErtpMVM14OvcWveXhSKJoq89XE=
x-ms-office365-filtering-correlation-id: de10aaf9-9efc-4653-6213-08d4cecdb22c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1038; 
x-ms-traffictypediagnostic: DM2PR0101MB1038:
x-exchange-antispam-report-test: UriScan:(236129657087228)(192374486261705)(48057245064654); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1038; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1038; 
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39450400003)(39400400002)(39850400002)(24454002)(66066001)(99286003)(6436002)(2950100002)(189998001)(82746002)(2906002)(6512007)(83716003)(6916009)(6116002)(3846002)(86362001)(102836003)(6486002)(478600001)(33656002)(2900100001)(14454004)(305945005)(7736002)(6506006)(3660700001)(230783001)(93886004)(6246003)(2171002)(38730400002)(110136004)(4326008)(5660300001)(53936002)(8676002)(53546010)(5250100002)(81166006)(25786009)(54356999)(36756003)(76176999)(50986999)(3280700002)(229853002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1038; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 17:43:41.6296 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1038
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:43:45 -0000

DQoNCj4gT24gSnVsIDE5LCAyMDE3LCBhdCAxOToxNSwgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAt
IE1JVExMIDx1cmlAbGwubWl0LmVkdT4gd3JvdGU6DQo+IA0KPiBNeSBwb2ludCBpcyB0aGF0IGlm
IHlvdSBvd24vY29udHJvbCB0aGUgZW5kcG9pbnQsIHRoZW4gaXQgZG9lc27igJl0IG1hdHRlciBm
cm9tIHRoZSBhcmNoaXRlY3R1cmUgcG9pbnQgb2Ygdmlldw0KDQpJdCBhYnNvbHV0ZWx5IG1hdHRl
cnMgZnJvbSBhbiBvcGVyYXRpb25hbCBwZXJzcGVjdGl2ZSwgd2hpY2ggYm90aCBpbmZvcm1zIGFu
ZCBpcyBpbmZvcm1lZCBieSB0aGUgYXJjaGl0ZWN0dXJlLiANCg0KQW5kIGV2ZW4gdGhvdWdoIHlv
dXIgb3ZlcmFyY2hpbmcgb3JnYW5pemF0aW9uIG93bnMgdGhlIGVuZHBvaW50LCB0aGUgJ3lvdScg
d2hvIGlzIHJlc3BvbnNpYmxlIGZvciB0cm91Ymxlc2hvb3RpbmcgYW5kL29yIHNlY3VyaXR5IGFu
YWx5c2lzIG9mdGVuIGRvZXMgbm90LiAgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0Pg==


From nobody Wed Jul 19 10:45:17 2017
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 DB86F13167D for ; Wed, 19 Jul 2017 10:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 c_C0qk_lgyN8 for ; Wed, 19 Jul 2017 10:45:14 -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 91D64129461 for ; Wed, 19 Jul 2017 10:45:14 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id v193so3513839ywg.2 for ; Wed, 19 Jul 2017 10:45:14 -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=nqhRfmZWMd3HdyTI3Z5GMGeQg0RtadqyRw24qf6K3/Y=; b=TUI9Po+5u0uYtXZhcFcysE+gRZtJhmCUkqDoInYrpwb3rvy4//KCwSyEeGttARGApM JuWRrrZs83UuexEji0T3pr+VFkcYRzcGfdNNkvHXTkpkC+I3ia6dNHjmJS5TuhxF5Pbz d4HGpDAzMjwMwt3BLPPc9enUFoWw1ctYjymnFchjq/Ws4fIpHcpJHs3aAuDakDpKpqOT 0bgSwvBDooTCRb76gjqxZdFYAnruipKY1M96orvzNTOhMEhH5XG7xFV7ZtgLlbyhGfS2 yffbWDkZdQajHFCBIwCPxP7lxymGHeiCbKPnmLbh/Iq9I0OcU8qeQk0Twtd5utj48Bqc WPlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nqhRfmZWMd3HdyTI3Z5GMGeQg0RtadqyRw24qf6K3/Y=; b=rsIRaMImmo8zCJ+frkNjh3okP0mCXEayeo4ibzvm2zkBPpVdx6xa0RzGPHU+unOKmG eUQ8XJkTFEH8aKmw7TPxzEnP6yERyXxpO9naTApRNN1vjf9vL96IUHSNsfkvDFHXcn/M f4g8tdqexCAm9KYJI84o5tmHGoJS+1AUHRoX11gU8MlLyRhz8UmxDzTJk7of9nKPDoek kNTcoxFEGKKi7Y3V8KCnZSfaeM/MsaHfcwBs8sXSQ6NqNGBAvct0NoT6B5Aj2ndDQdoN ts4dVOACrYtujw7HXYadJ6KHM/EZTMmBXvDblmMQ+JLmFei5e3o9kithBp2fseNZzlSA jIfw==
X-Gm-Message-State: AIVw111sMiVJICchGLinKqAYNXYGPuwsqEvGLhTRz1u/gdRrsNdCGVs0 hS5nitBGHY9tpUTm0sTWv9VXDqDHkvpu
X-Received: by 10.129.121.135 with SMTP id u129mr809425ywc.171.1500486313610;  Wed, 19 Jul 2017 10:45:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Wed, 19 Jul 2017 10:45:13 -0700 (PDT)
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie> 
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 19 Jul 2017 10:45:13 -0700
Message-ID: 
To: Ted Lemon 
Cc: Stephen Farrell , "" 
Content-Type: multipart/alternative; boundary="94eb2c0a93c0b6e0410554af310c"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:45:16 -0000

--94eb2c0a93c0b6e0410554af310c
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon  wrote:

> The problem is that the actual solution to this problem is to accept that
> you aren't going to be able to decrypt the streams, and then figure out
> what to do instead.   Which is work the proponents of not doing that are
> not interested in doing, understandably, and which is also not the work of
> this working group.
>
> I'm skeptical that there is a way for this working group to solve the
> proposed problem, but if there is, it involves figuring out a way to do
> this that doesn't make it easy to MiTM *my* connections, or, say, those
> of activists in dangerous places.
>

I find this a very bizarre outcome that works against our collective goals.
If there is no mechanism at all, then it is quite likely that organizations
will use static-DH or stay on TLS1.2. Those are bad options, in my opinion,
because there's no signaling or opt-in to the client. We can do much better
than that.  Client opt-ins are far from academic. For example, browser's
incognito modes may refuse to support such sessions, if they knew what was
going on.

It's also bad if organizations end up deploying static-DH and that means we
can't do things like checking for changing DH parameters.

It seems like we would be rejecting a good opportunity to make what the
network operators want work in a better and more secure way, while making
it harder for passive observers and coercive authorities, to use the same
mechanism for other purposes. What do we gain? beyond a hollow moral
victory.

-- 
Colm

--94eb2c0a93c0b6e0410554af310c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <mellon@fugue.com> wrote:
The problem=
 is that the actual solution to this problem is to accept that you aren'=
;t going to be able to decrypt the streams, and then figure out what to do =
instead. =C2=A0 Which is work the proponents of not doing that are not inte=
rested in doing, understandably, and which is also not the work of this wor=
king group.

I'm skeptical that there is a way for th=
is working group to solve the proposed problem, but if there is, it involve=
s figuring out a way to do this that doesn't make it easy to MiTM my=
=C2=A0connections, or, say, those of activists in dangerous places.

I find this a very bizarre outcome=
 that works against our collective goals. If there is no mechanism at all, =
then it is quite likely that organizations will use static-DH or stay on TL=
S1.2. Those are bad options, in my opinion, because there's no signalin=
g or opt-in to the client. We can do much better than that.=C2=A0 Client op=
t-ins are far from academic. For example, browser's incognito modes may=
 refuse to support such sessions, if they knew what was going on.

It's also bad if organizations end up deploying static-=
DH and that means we can't do things like checking for changing DH para=
meters.=C2=A0

It seems like we would be rejecting =
a good opportunity to make what the network operators want work in a better=
 and more secure way, while making it harder for passive observers and coer=
cive authorities, to use the same mechanism for other purposes. What do we =
gain? beyond a hollow moral victory.=C2=A0

-- 
Colm



--94eb2c0a93c0b6e0410554af310c--


From nobody Wed Jul 19 10:48:07 2017
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 C386F129461 for ; Wed, 19 Jul 2017 10:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7AAi4a0iEBUc for ; Wed, 19 Jul 2017 10:48:04 -0700 (PDT)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 0248A131AAF for ; Wed, 19 Jul 2017 10:48:02 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id s4so3205863pgr.5 for ; Wed, 19 Jul 2017 10:48:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=62dwV8M5ZXX6nAEz2ShjSi3rVpfa7QeqmhzMGYDuWBo=; b=cYSH4NZTnkwxSP3ed+wB30d6+a3cMN5QsKwBVlk4EPEqD2tUvPjs9hB7ysakK2A0Jv KGl19mG7cdVWTPkUxMfE1JO6Dhidf/P4cpAJd9zihkRzxRkpLq5mwEB5hy5jaUKiHSOG VgXO/mJEUnvxSU2P8LXftjyAw5LepTs675by9mmFehkA4/dBZhFEZ+n6MiL+tWXjqd6p 9pfZSDr0kRL3tNxjKTqw8hSYKJ9QFUyfadqa4M0QHY+ccU4pPwgt6CpFtyCJEQ51k0Dz eAs9haaYlvZQuovV7doyB9paVEvZa4hFgRMTDHt38IcR3Smut7dKJyI/qbeEAYqVVQmD zXGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=62dwV8M5ZXX6nAEz2ShjSi3rVpfa7QeqmhzMGYDuWBo=; b=AXBjbVp7AYFfInfZOLsP8grDvE9WaoF18MgbeMDpTfvKA+mk/9RydvHoHj8FFfaZeC jKD5G8PlLlzk/cojxxG8u8pur4yg+oXn2RJObBuQ8UtvzwYqWYu7Zq5QSSWzmYJfKHPQ 6JT6vThJ9ZLHk1dNWgopJfJq+vfWlA/rmFjMIrrhPqcrbRIqNZs8WUg2sDiqlGDRNr5F iNwmoQYaYacJRElxO4OfCJq6+xUqIYWkS30jbLIvvizMZxNlkolquIv6+PRKWhF9yuyr aFqx4GO9ORaP+F5ZnQsGsidzzCxGAg5uw0Q86YtIQzagRyiRHkzperFMnlhNeIv+qIaJ VfgQ==
X-Gm-Message-State: AIVw113ONe2KtwHcUG2WlgjKlIfrHOrW7EYOXGal0EujA2KwWPB+CTK4 bbuJODn8w8Hhb8ocu1XlWNWc47j0Yb/J
X-Received: by 10.84.210.141 with SMTP id a13mr970865pli.199.1500486481545; Wed, 19 Jul 2017 10:48:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Wed, 19 Jul 2017 10:47:59 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Wed, 19 Jul 2017 10:47:59 -0700 (PDT)
In-Reply-To: <5E90933D-3D9F-4166-808D-7ECE53D264F4@arbor.net>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <5E90933D-3D9F-4166-808D-7ECE53D264F4@arbor.net>
From: Watson Ladd 
Date: Wed, 19 Jul 2017 10:47:59 -0700
Message-ID: 
To: "Dobbins, Roland" 
Cc: tls@ietf.org, "Blumenthal, Uri - 0558 - MITLL" 
Content-Type: multipart/alternative; boundary="94eb2c18828ab90e5b0554af3b1c"
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:48:06 -0000

--94eb2c18828ab90e5b0554af3b1c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Jul 19, 2017 10:43 AM, "Dobbins, Roland"  wrote:



> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL 
wrote:
>
> My point is that if you own/control the endpoint, then it doesn=E2=80=99t=
 matter
from the architecture point of view

It absolutely matters from an operational perspective, which both informs
and is informed by the architecture.

And even though your overarching organization owns the endpoint, the 'you'
who is responsible for troubleshooting and/or security analysis often does
not.


Technical solutions to political problems are not the right approach.


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

--94eb2c18828ab90e5b0554af3b1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Jul 19, 2017 10:43 AM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:




> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:

>

> My point is that if you own/control the endpoint, then it doesn=E2=80=
=99t matter from the architecture point of view




It absolutely matters from an operational perspective, which both inf=
orms and is informed by the architecture.



And even though your overarching organization owns the endpoint, the 'y=
ou' who is responsible for troubleshooting and/or security analysis oft=
en does not.

=

Technical solutions to political problems are not the rig=
ht approach.




-----------------------------------

Roland Dobbins <rdobbins@arbor.net=
>

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c18828ab90e5b0554af3b1c--


From nobody Wed Jul 19 10:54:41 2017
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 45A36127342 for ; Wed, 19 Jul 2017 10:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 LfmJZbEGVJI8 for ; Wed, 19 Jul 2017 10:54:36 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0118.outbound.protection.outlook.com [104.47.32.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48648131B9A for ; Wed, 19 Jul 2017 10:54:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Mo4fw9uTOkrp05YhFR2C52zHz7kjugMw240zPLG94IM=; b=Pj/IBlOJ70lxCq7UKWyOn6AsqtYf4TTOX5qrftxTGqRP30YbY8clGsDJKt5qaVjq6HKVjLqwUaYrS7ZulKJTu43xlOIg+EzYWwfcDXdh/t1XeXx0+77qvn6U1XL2zP13eIH0OSDn9iW9uGb3UTpoKp+j2O6khO1ZxFKJpxgpiOU=
Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 17:54:34 +0000
Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 17:54:34 +0000
From: "Dobbins, Roland" 
To: Watson Ladd 
CC: "tls@ietf.org" , "Blumenthal, Uri - 0558 - MITLL" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulnreU48MdBA0WwDcIvwebnRKJYYxaAgAB6VYCAAmD9gIAAGYsAgAAB3ICAAAJ0AIAABMBagAAGSICAAAgAn4AAATSAgAAB138=
Date: Wed, 19 Jul 2017 17:54:34 +0000
Message-ID: <0739E598-8CE6-4B41-BFC2-4085218A06A6@arbor.net>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <5E90933D-3D9F-4166-808D-7ECE53D264F4@arbor.net>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net;
x-originating-ip: [88.208.89.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 7:J/oeSwzdQ3y21zmtdHiXlLO36jVklxh3r4Gjf1f+F0fTVI4KKr9wNSH0niIQ8JkLspc1wgpQidjNy7Z2cRWum8uMfJNOsb/+S+8eUBmNlCPsZA/PXGlhn7fwKsKYbcxS/2otyMcaE+hvlhS4xiGGr1hRoB5S1XDjNRmlY8M1I7zLtwO7vM6dSCw5kzOwpzALDAtUau2ugholvuXIuE8ym6sXiLr4zAJIqL++9aBit/iz53T0n7LIN9TQ3aae5b3nkzeacT9USNLp9nKH3ofn5PlrP1247RSunPecMNTgvdA6vYmpLl4GB52gYYKrIdMnMiOss00AJeox1T1auGxEa0vvg3FhERlc6pQFO78gliGwlS8z27Q4YkAkTF+UZ32tCEMg19nbSWfoIO3UU6FGE4pHkN3BvicBu2nsdsNHTeym1Na/oWll1qm5ueesS4WKuRXj8YDaNXlPcKaNNqG+h+Js9LWXAzJtxrIwzPszj/Ys3yGM92GVGBD/YA1ljoY14FjAORBh/znUOj51Li33eUqbYB2+wI1+D4h811quN/v7+Oq9ABbda7jpZZ65zMDASn8lqTCVQfDlCUIesK4eCcVxfhpchfo1Fw0T2HmU6rpZHbkC3uABcbO+ecd4vTasn8uXPoWdT1ohAmI16RqTyXWyyEZfGa3UPkmtbHU5KdKvAcL8ZeP+gClEweojLk54OgiZiyDtUch8W5WhHdBovrGZynqBkrK/ZCWKI9XIY3L2+1EwMxjrNm1pwC1HIXPrLPswZpIMPZw7g1U8vESt6VbEsyhHRDkoR64qa13yRH4=
x-ms-office365-filtering-correlation-id: 58abf3be-87b1-4007-e65b-08d4cecf3726
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; 
x-ms-traffictypediagnostic: DM2PR0101MB1039:
x-exchange-antispam-report-test: UriScan:(236129657087228)(266576461109395)(50300203121483); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; 
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39400400002)(39840400002)(24454002)(189998001)(76176999)(966005)(54356999)(53546010)(14454004)(50986999)(36756003)(66066001)(1411001)(8676002)(81166006)(8936002)(606006)(25786009)(33656002)(7736002)(4326008)(6246003)(39060400002)(38730400002)(478600001)(6436002)(2906002)(236005)(54906002)(99286003)(110136004)(53936002)(6512007)(6306002)(54896002)(19627405001)(2900100001)(102836003)(6116002)(3846002)(6916009)(2950100002)(5660300001)(82746002)(6506006)(229853002)(6486002)(5250100002)(86362001)(83716003)(3280700002)(3660700001)(93886004)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_0739E5988CE64B41BFC24085218A06A6arbornet_"
MIME-Version: 1.0
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 17:54:34.3219 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:54:38 -0000

--_000_0739E5988CE64B41BFC24085218A06A6arbornet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCk9uIEp1bCAxOSwgMjAxNywgYXQgMTk6NDgsIFdhdHNvbiBMYWRkIDx3YXRzb25ibGFkZEBn
bWFpbC5jb208bWFpbHRvOndhdHNvbmJsYWRkQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpUZWNobmlj
YWwgc29sdXRpb25zIHRvIHBvbGl0aWNhbCBwcm9ibGVtcyBhcmUgbm90IHRoZSByaWdodCBhcHBy
b2FjaC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJvbGFuZCBEb2Ji
aW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcg
bGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQpDb252ZXJzZWx5LCB0ZWNobmljYWwgc29sdXRp
b25zIHdoaWNoIGRvIG5vdCB0YWtlIGludG8gYWNjb3VudCBvcGVyYXRpb25hbCByZWFsaXR5IGRv
bid0IGJlbmVmaXQgdGhvc2Ugd2hvIG5lZWQgdGhlbSB0aGUgbW9zdC4NCg0KU2FkbHksIHdlIGRv
bid0IGhhdmUgdGhlIGx1eHVyeSBvZiBzdGFydGluZyBmcm9tIGEgY2xlYW4gc2xhdGUuDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJp
bnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0K

--_000_0739E5988CE64B41BFC24085218A06A6arbornet_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gSnVsIDE5LCAyMDE3
LCBhdCAxOTo0OCwgV2F0c29uIExhZGQgJmx0OzxhIGhyZWY9Im1haWx0bzp3YXRzb25ibGFkZEBn
bWFpbC5jb20iPndhdHNvbmJsYWRkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9ImF1dG8i
PlRlY2huaWNhbCBzb2x1dGlvbnMgdG8gcG9saXRpY2FsIHByb2JsZW1zIGFyZSBub3QgdGhlIHJp
Z2h0IGFwcHJvYWNoLjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdiBjbGFzcz0iZ21haWxf
ZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9InF1
b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6
IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIw
NCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsgZGlzcGxheTogbm9uZTsiIHByZW9mZnNl
dHRvcD0iNDU1IiBwcmVvZmZzZXRoZWlnaHQ9IjE4MiI+DQo8ZGl2IGNsYXNzPSJlbGlkZWQtdGV4
dCI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLTxicj4NClJv
bGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9i
Ymluc0BhcmJvci5uZXQ8L2E+Jmd0Ozxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzx3YnI+X19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl
Zj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiByZWw9Im5vcmVmZXJyZXIi
IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGlu
Zm8vdGxzPC9hPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZGl2PkNvbnZlcnNlbHksIHRlY2hu
aWNhbCBzb2x1dGlvbnMgd2hpY2ggZG8gbm90IHRha2UgaW50byBhY2NvdW50IG9wZXJhdGlvbmFs
IHJlYWxpdHkgZG9uJ3QgYmVuZWZpdCB0aG9zZSB3aG8gbmVlZCB0aGVtIHRoZSBtb3N0LiZuYnNw
OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2FkbHksIHdlIGRvbid0IGhhdmUgdGhl
IGx1eHVyeSBvZiBzdGFydGluZyBmcm9tIGEgY2xlYW4gc2xhdGUuICZuYnNwOzwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEo
MjU1LCAyNTUsIDI1NSwgMCk7Ij48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczog
bm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9z
aXRpb246IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczog
bm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9z
aXRpb246IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPg0KPC9zcGFuPg0KPGRpdiBzdHls
ZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lh
bjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v
cm1hbDsiPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1
NSwgMCk7Ij5Sb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9y
Lm5ldCI+cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwv
Ym9keT4NCjwvaHRtbD4NCg==

--_000_0739E5988CE64B41BFC24085218A06A6arbornet_--


From nobody Wed Jul 19 10:55:59 2017
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 522E0131B87 for ; Wed, 19 Jul 2017 10:55:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8Ulk6zb35a41 for ; Wed, 19 Jul 2017 10:55:56 -0700 (PDT)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 E90D8131B76 for ; Wed, 19 Jul 2017 10:55:55 -0700 (PDT)
Received: by mail-pg0-x234.google.com with SMTP id 125so3320775pgi.3 for ; Wed, 19 Jul 2017 10:55:55 -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=BKitumoi0t6e2VR6RCnmMfSYvYiSx78OxEdsHPwFTws=; b=yX6XHCFBzmT7gCCAdQfQ8J2R+WGEs9nlz0ncF7GZBvFG9KYamYN7A1WROAP5ZlQlgs xtc1ByicqZrB3z/ApPYz1HKriP8nfCkz815Cz43Pn/olxUOUhhk+WdmCkv3MYufRp/Qe I364cCKaFQuBCPL0SzVN33PDQHPHYYlK6o34hGqwMRENKh0lxfbjE978v3Udfwy5guCp NoC34Xvlq3s1wWcfVpsmF7y0a/zgRi2dFYx53Pbyl1KpG10vAyL1Vd1Yv7X5+WFV5w3I JQlrwHTpEr39y+LFZAuZIVml8VHO+4W8/AERu0Q4UYTwqRNrwhio9KITIKSHa+aY41kh AIZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BKitumoi0t6e2VR6RCnmMfSYvYiSx78OxEdsHPwFTws=; b=MjWZfOgJsvots4kyRrhu/eqTUFmpVMMzGe6jJ2hjvnOfRf1zeAIMZT3YOg6DPRPnfy p1XuMaZZESuTNjSd9rMUz/h0WedFumSDyIXkGRPJOs9imIbJMftWN5s8Ujy/fKujFOOI Yvu/mQB1DYuhmyuFM9PidDJ7T9lnBKrovZOsDkxSspjYSIU4BMfQJmFAeGACH1eJZB2w OFg5YNt6CH8f9gkLjHDXEWHcmh8qj4YEyvaLS/orMujS4LhTRrXCKRvCT4wAgKbYJTkF V/VUG+4G3PW6dJS1n4UcSOJ/OVnpkWGjxdjoza4UKXuBciCutf2xjZ4TY7lTNgVep1gf tZIg==
X-Gm-Message-State: AIVw110C3cS98cT1Wj4KZHe7UBd8SYYZgRxKPj0z8ADspsqkZa1pzE8d mHQLWQEoQWpSBkzP1opUmy+8lLWZssPw
X-Received: by 10.98.18.69 with SMTP id a66mr925163pfj.33.1500486955540; Wed, 19 Jul 2017 10:55:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 10:55:15 -0700 (PDT)
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>  
From: Ted Lemon 
Date: Wed, 19 Jul 2017 19:55:15 +0200
Message-ID: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Cc: Stephen Farrell , "" 
Content-Type: multipart/alternative; boundary="001a1145b83af9b7080554af5770"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 17:55:57 -0000

--001a1145b83af9b7080554af5770
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry, the more I think about how to do this in a way that doesn't make
things worse, the less faith I have that it is possible.   But if you know
of a way to do it, I certainly don't oppose you doing it.   I'm not an
expert: the fact that I don't see how to do it doesn't mean it can't be
done.

On Wed, Jul 19, 2017 at 7:45 PM, Colm MacC=C3=A1rthaigh 
wrote:

>
>
> On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon  wrote:
>
>> The problem is that the actual solution to this problem is to accept tha=
t
>> you aren't going to be able to decrypt the streams, and then figure out
>> what to do instead.   Which is work the proponents of not doing that are
>> not interested in doing, understandably, and which is also not the work =
of
>> this working group.
>>
>> I'm skeptical that there is a way for this working group to solve the
>> proposed problem, but if there is, it involves figuring out a way to do
>> this that doesn't make it easy to MiTM *my* connections, or, say, those
>> of activists in dangerous places.
>>
>
> I find this a very bizarre outcome that works against our collective
> goals. If there is no mechanism at all, then it is quite likely that
> organizations will use static-DH or stay on TLS1.2. Those are bad options=
,
> in my opinion, because there's no signaling or opt-in to the client. We c=
an
> do much better than that.  Client opt-ins are far from academic. For
> example, browser's incognito modes may refuse to support such sessions, i=
f
> they knew what was going on.
>
> It's also bad if organizations end up deploying static-DH and that means
> we can't do things like checking for changing DH parameters.
>
> It seems like we would be rejecting a good opportunity to make what the
> network operators want work in a better and more secure way, while making
> it harder for passive observers and coercive authorities, to use the same
> mechanism for other purposes. What do we gain? beyond a hollow moral
> victory.
>
> --
> Colm
>

--001a1145b83af9b7080554af5770
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sorry, the more I think about how to do this in a way that=
 doesn't make things worse, the less faith I have that it is possible. =
=C2=A0 But if you know of a way to do it, I certainly don't oppose you =
doing it. =C2=A0 I'm not an expert: the fact that I don't see how t=
o do it doesn't mean it can't be done.

On Wed, Jul 19, 2017 at 7:45 PM, Colm Ma=
cC=C3=A1rthaigh <colm@allcosts.net> wrote:


On Wed, Jul 19, 2017 at 10:38 AM, Ted=
 Lemon <mellon@fugue.com> wrote:
The problem is that the actual solution to this prob=
lem is to accept that you aren't going to be able to decrypt the stream=
s, and then figure out what to do instead. =C2=A0 Which is work the propone=
nts of not doing that are not interested in doing, understandably, and whic=
h is also not the work of this working group.

I'm sk=
eptical that there is a way for this working group to solve the proposed pr=
oblem, but if there is, it involves figuring out a way to do this that does=
n't make it easy to MiTM my=C2=A0connections, or, say, those of =
activists in dangerous places.

I find this a very bizarre outcome that works against our collective=
 goals. If there is no mechanism at all, then it is quite likely that organ=
izations will use static-DH or stay on TLS1.2. Those are bad options, in my=
 opinion, because there's no signaling or opt-in to the client. We can =
do much better than that.=C2=A0 Client opt-ins are far from academic. For e=
xample, browser's incognito modes may refuse to support such sessions, =
if they knew what was going on.

It's also bad =
if organizations end up deploying static-DH and that means we can't do =
things like checking for changing DH parameters.=C2=A0

=

It seems like we would be rejecting a good opportunity to make what th=
e network operators want work in a better and more secure way, while making=
 it harder for passive observers and coercive authorities, to use the same =
mechanism for other purposes. What do we gain? beyond a hollow moral victor=
y.=C2=A0
-- 
Colm







--001a1145b83af9b7080554af5770--


From nobody Wed Jul 19 11:01:08 2017
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 4A528131AAF for ; Wed, 19 Jul 2017 11:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 K6wr9k4eNmuI for ; Wed, 19 Jul 2017 11:01:05 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB02131B76 for ; Wed, 19 Jul 2017 11:01:05 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id a12so3641650ywh.3 for ; Wed, 19 Jul 2017 11:01:05 -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=8Q/Q0k44w4nu8iCxPg9IrhTnydqYaBT59xvlulgUq4M=; b=Kl3+JRBlpkno6HAPDof/7xla8qh2omNaZl/cLqvPFKIHQIZWcpIiN65bhPhrK+6NJl lYXHC/Hvd5w5eJ7wY6B9S635ZsS6QRmTMFys+vMiD3NGyr7pqpOv2lNn07fPWRV4Wqdp T7jQC2QJzvmbfzkHhlQXw1u/pCHOUV/h+gU6ZRkgAzP+C1UtIlSpqtV8fKKMn0XZY6yM J2Mw15Puwty6Hou48YLoZpQJVyHhNuRk3SR0iO0utNJ94fA9RheDKlSjLPj2UpSqBXAR gy6savHQinT5N161N6STuVzWthLjoRxuRfzew8aGuIDiPI4+MZPuAcx4RFQKzARSpM65 C1ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8Q/Q0k44w4nu8iCxPg9IrhTnydqYaBT59xvlulgUq4M=; b=MprQAswXPMbn7JPKeB4VW3UyjYncFky7j4FMgbrh1bm/P1FR4yRx3qK3k3k2MHOtys evIlkXb6+CW4dM1Y4nAbMmTxVFgIGXOfrUiVj1cB6jDQVAji0Leo+As+iJmXuwnepdEP vIQx9yKY4vkg4tZ+NXpKXSfw04efHetIiwZTG5pGI0ikYnJr71sgxGwB+JynhhD3rpLM s9/Tu9ILE28qIJj0b+T3JbmhWQuQ6Hefmq+JsPtR4LvU6SFxPCrhIdo/8+/4ie9KvTCI tv/e/dz8hQac6UQdJbvLH7to3iC7P6K+TAcEsOOCdxOVqL95eZ7wk4R0HK4fS13hgISA mZug==
X-Gm-Message-State: AIVw110LcHd4mCg/6xE56/zVjcVkhr+kmsVKPvMb9iZNte/RhrbCaoew Cs6juMa2lOFHrLoUTPbNF5kfoe0AQCAf
X-Received: by 10.129.178.133 with SMTP id q127mr817722ywh.49.1500487264437; Wed, 19 Jul 2017 11:01:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Wed, 19 Jul 2017 11:01:03 -0700 (PDT)
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>   
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 19 Jul 2017 11:01:03 -0700
Message-ID: 
To: Ted Lemon 
Cc: Stephen Farrell , "" 
Content-Type: multipart/alternative; boundary="94eb2c146c3c63812e0554af6a24"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:01:07 -0000

--94eb2c146c3c63812e0554af6a24
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 19, 2017 at 10:55 AM, Ted Lemon  wrote:

> Sorry, the more I think about how to do this in a way that doesn't make
> things worse, the less faith I have that it is possible.   But if you kno=
w
> of a way to do it, I certainly don't oppose you doing it.   I'm not an
> expert: the fact that I don't see how to do it doesn't mean it can't be
> done.
>

I think it was Nick who had the idea of adding a message to the TLS
transcript that encrypts the PMS or session key under a public key. This
had some advantages:

* Static-DH can be banned and clients can check for changing DH parameters.
* The technique would be signaled and opt-in to clients; they can terminate
the connection if they don't want it. Clients could insist on being
configured to support it, not support it in incognito mode, etc.
* The PMS/key could be encrypted under a different key than the key pair
used to authenticate the server; this means that the servers needn't have a
key that can decrypt these transcripts. It can be kept offline. It also
means that the investigation team needn't have access to the servers
certificate private key. Much better all-round.
* Still can work with tcpdump/wireshark etc, but not very useful to three
letter agencies, etc.


>
> On Wed, Jul 19, 2017 at 7:45 PM, Colm MacC=C3=A1rthaigh 
> wrote:
>
>>
>>
>> On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon  wrote:
>>
>>> The problem is that the actual solution to this problem is to accept
>>> that you aren't going to be able to decrypt the streams, and then figur=
e
>>> out what to do instead.   Which is work the proponents of not doing tha=
t
>>> are not interested in doing, understandably, and which is also not the =
work
>>> of this working group.
>>>
>>> I'm skeptical that there is a way for this working group to solve the
>>> proposed problem, but if there is, it involves figuring out a way to do
>>> this that doesn't make it easy to MiTM *my* connections, or, say, those
>>> of activists in dangerous places.
>>>
>>
>> I find this a very bizarre outcome that works against our collective
>> goals. If there is no mechanism at all, then it is quite likely that
>> organizations will use static-DH or stay on TLS1.2. Those are bad option=
s,
>> in my opinion, because there's no signaling or opt-in to the client. We =
can
>> do much better than that.  Client opt-ins are far from academic. For
>> example, browser's incognito modes may refuse to support such sessions, =
if
>> they knew what was going on.
>>
>> It's also bad if organizations end up deploying static-DH and that means
>> we can't do things like checking for changing DH parameters.
>>
>> It seems like we would be rejecting a good opportunity to make what the
>> network operators want work in a better and more secure way, while makin=
g
>> it harder for passive observers and coercive authorities, to use the sam=
e
>> mechanism for other purposes. What do we gain? beyond a hollow moral
>> victory.
>>
>> --
>> Colm
>>
>
>


--=20
Colm

--94eb2c146c3c63812e0554af6a24
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Jul 19, 2017 at 10:55 AM, Ted Lemon <mellon@fugue.com> wrote:
Sorry, the =
more I think about how to do this in a way that doesn't make things wor=
se, the less faith I have that it is possible. =C2=A0 But if you know of a =
way to do it, I certainly don't oppose you doing it. =C2=A0 I'm not=
 an expert: the fact that I don't see how to do it doesn't mean it =
can't be done.

I think it was Nic=
k who had the idea of adding a message to the TLS transcript that encrypts =
the PMS or session key under a public key. This had some advantages:
<=
div>
* Static-DH can be banned and clients can check for chan=
ging DH parameters.=C2=A0
* The technique would be signaled and o=
pt-in to clients; they can terminate the connection if they don't want =
it. Clients could insist on being configured to support it, not support it =
in incognito mode, etc.=C2=A0
* The PMS/key could be encrypted un=
der a different key than the key pair used to authenticate the server; this=
 means that the servers needn't have a key that can decrypt these trans=
cripts. It can be kept offline. It also means that the investigation team n=
eedn't have access to the servers certificate private key. Much better =
all-round.
* Still can work with tcpdump/wireshark etc, but not v=
ery useful to three letter agencies, etc.=C2=A0
=C2=A0

On Wed, Jul 19, 2017 at 7:=
45 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
=



On Wed, Jul 19, 2017 at 10:38 AM, =
Ted Lemon <mellon@fugue.com> wrote:
The problem is that the actual solution to this =
problem is to accept that you aren't going to be able to decrypt the st=
reams, and then figure out what to do instead. =C2=A0 Which is work the pro=
ponents of not doing that are not interested in doing, understandably, and =
which is also not the work of this working group.

I'=
m skeptical that there is a way for this working group to solve the propose=
d problem, but if there is, it involves figuring out a way to do this that =
doesn't make it easy to MiTM my=C2=A0connections, or, say, those=
 of activists in dangerous places.

<=
/span>
I find this a very bizarre outcome that works against our collec=
tive goals. If there is no mechanism at all, then it is quite likely that o=
rganizations will use static-DH or stay on TLS1.2. Those are bad options, i=
n my opinion, because there's no signaling or opt-in to the client. We =
can do much better than that.=C2=A0 Client opt-ins are far from academic. F=
or example, browser's incognito modes may refuse to support such sessio=
ns, if they knew what was going on.

It's also =
bad if organizations end up deploying static-DH and that means we can't=
 do things like checking for changing DH parameters.=C2=A0

It seems like we would be rejecting a good opportunity to make wha=
t the network operators want work in a better and more secure way, while ma=
king it harder for passive observers and coercive authorities, to use the s=
ame mechanism for other purposes. What do we gain? beyond a hollow moral vi=
ctory.=C2=A0

-- 
C=
olm










-- 
=

Colm



--94eb2c146c3c63812e0554af6a24--


From nobody Wed Jul 19 11:01:44 2017
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 E6BD2131D39 for ; Wed, 19 Jul 2017 11:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 lFsQtpVfkDwe for ; Wed, 19 Jul 2017 11:01:38 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0114.outbound.protection.outlook.com [104.47.33.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451B5131D34 for ; Wed, 19 Jul 2017 11:01:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cVF5gQh80K7CnRhrXeNlCcFH+A3/9LOUUldI7D+rnVg=; b=KGJG3ARetExTxmxRy9XJbA/7Qp5DiKUOf0hJNOhUXnxVH0l/5/abzsQyNc90nMgXTg0p6HpyWDriWvM53G5aVb148FuRw+CPDr5SsCtuwVX5mfLjeeyUZ1U19KJgwoB9OslEMsFzVC9gAfiaU8BeHLRhIsLJcgbvcNcbOXRcK1I=
Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1038.prod.exchangelabs.com (10.160.129.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:01:36 +0000
Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 18:01:36 +0000
From: "Dobbins, Roland" 
To: "Blumenthal, Uri - 0553 - MITLL" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulnreU48MdBA0WwDcIvwebnRKJYYxaAgAB6VYCAAmD9gIAAGYsAgAAB3ICAAAJ0AIAABMBagAAGSICAAA0Cfg==
Date: Wed, 19 Jul 2017 18:01:36 +0000
Message-ID: <2FAFADF2-F791-406B-9519-EAB266AC2FCD@arbor.net>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>       , <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu>
In-Reply-To: <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net;
x-originating-ip: [88.208.89.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1038; 7:D0wpEto3XzTFzqrpNg2hWNU2PtkQx57yMNLBCeXlD/Yuxw1fvUCf8ITU2YfDy6ZT1SjhO/s39TpMMYB9fN4QYVIcJEAj0/t57hcJ5NqvZMLUDNV4c/qLg/wAqjQ3Gq7zGR3xM8hR8rEwbvx7wm/JDGTJiLr6S0yE1H6+5BrwJHWTgJiYL6ypJWXQue15/8qNZ7yeM+lU8Ve5agGwY1VHd0PXoH3dmpB6oh4xYZBhYF1mwSy0f9zMMrhNLWA4oU1D4rUMJARtKyg6QxVJYrA8QIl264gzKSeblkiWS+4SnV0CSVLdqMD2X4rQnET92CgjqEmGoAUWAV3DWam2/iebc/X5dDZlfvtoo7BWWV44YDFNVWt58xsjxE4B0kcm8XH+vf3tRIqcGSayf4LtKO0UtC3HfenNLPB2FgwMspPjh6Heu2pfQV6Im/Dda586q0Mk+DfY98ehw7tb5PUrqkCeoc69g7pb3kimzVMI7wI6uINIxuVbixP45yQVjxOY6O7Y5wh1zxDWiV5PoOE/DRBOeeiVDosmFASwnzQwLguMZRMs5eN9cFWZugdeAhh+cty13h6zcfZKWy5QQovKStiBiVlm3E8S0UjuOETGR8naw4S07eQ2WBW0zp9hNDZJqwbx+V1mvH25Q9rOxMyxr5UKbLZxMzi2DizEBN1Jt5xgTfxhSr270FdstFK6BfHjlJSTPN/+NmZNq9xWZREq1ObQ4A/8fwE3i1hVwEoznSqsuGq0DIcPvudxZwEDIwEvkhTZQ5hwPL4g3SUrHcAA9BJ0GsTOuLL1gb3kwcVnIzQ+oMw=
x-ms-office365-filtering-correlation-id: 0a8cab1c-3285-4a1e-29d5-08d4ced032c5
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1038; 
x-ms-traffictypediagnostic: DM2PR0101MB1038:
x-exchange-antispam-report-test: UriScan:(236129657087228);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1038; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1038; 
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39450400003)(39840400002)(39410400002)(24454002)(93886004)(230783001)(3660700001)(2900100001)(14454004)(6486002)(478600001)(33656002)(6506006)(305945005)(7736002)(25786009)(5250100002)(81166006)(229853002)(8936002)(76176999)(50986999)(54356999)(36756003)(3280700002)(110136004)(2171002)(38730400002)(6246003)(53546010)(53936002)(8676002)(4326008)(5660300001)(99286003)(66066001)(6436002)(189998001)(2950100002)(6116002)(3846002)(86362001)(102836003)(82746002)(2906002)(6916009)(83716003)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1038; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 18:01:36.4040 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1038
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:01:42 -0000

> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL  wrote:
>=20
> Or are you simply trying to delay the inevitable?

I'm open to any solution which meets the stated requirements & is deployabl=
e & usable on real-world production networks, without necessitating a total=
 redesign of said networks & the complete social reorganization of the enti=
ties in question.=20

;>

There's some very constructive discussion taking place now about the relati=
ve merits of various approaches, & I'm following it quite keenly.=20

-----------------------------------
Roland Dobbins =


From nobody Wed Jul 19 11:06:00 2017
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 DB1C2131AAF for ; Wed, 19 Jul 2017 11:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fsroundtable.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 b3VkB_al--Ko for ; Wed, 19 Jul 2017 11:05:55 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0057.outbound.protection.outlook.com [104.47.33.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3225D12785F for ; Wed, 19 Jul 2017 11:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsroundtable.onmicrosoft.com; s=selector1-fsroundtable-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sNgarBIts13ZMeFKEqwy+opFbGBePdD0ztpLivCS9gQ=; b=AtyCh161pN+/NqC9zbjNb0LGxyJHKNVxvmxTXdRjtnxF0Quqklb2sPEXpRYpPY4/MlDUn7YadkJxyapbteYjOqv3C7VuHV9d4ZDaqC0U4NggvluOChBXS0zTWkszzjvjOXlMh/UPuv3cCpBT5g7U3Jsidgjzntr5N0SW6vDiWoY=
Received: from BN6PR11MB1922.namprd11.prod.outlook.com (10.175.100.135) by BN6PR11MB1921.namprd11.prod.outlook.com (10.175.100.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:05:53 +0000
Received: from BN6PR11MB1922.namprd11.prod.outlook.com ([10.175.100.135]) by BN6PR11MB1922.namprd11.prod.outlook.com ([10.175.100.135]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 18:05:53 +0000
From: BITS Security 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Ted Lemon 
CC: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJBar1BHW2E/7UWFUn2swYAliaJbXOSAgAAClACAAAm5AIAAAWoAgAAB0ICAAADYAA==
Date: Wed, 19 Jul 2017 18:05:53 +0000
Message-ID: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none;allcosts.net; dmarc=none action=none header.from=fsroundtable.org;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [165.117.248.226]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR11MB1921; 7:wzsLQZz9ss1lA2LQm7UFyGTEb+ikbGR0v2IQZdiQ/XCs/hk7tcUd5BlLdypnVqAo7LGIIdT1exgiqDA28J9irWcAzOn+iP8hEv6N6eKrjAG7XuAaJvT3xTRvDD2+aTPchNYpA5HCGfRbaZFjheWiQHAqEMdbI/eD4ABlye4a3XI+RUPR+e1uaDT+qRKDHt3yEIfEYuvtTdbGrvHP44dyseqoP5RLKMIhLQekjT+x3iBEDucRFMIRYkDWFuXsc3X4asK95ssFJxYeoqA2+vv4qKRQInOqVRADSf3bsIgwVXQqxCSdFeYgwrdDO1e3dN0v68bW7QWJU0R8B8ndnH8buHsER7UFmY+ewSqwUfqmEC1iNc9Bkfy/Y7wicXjPzLE1cbh041KaF4gF/57iCRb2SNXZDiIMXR4Gx9KSdNtKgWc2CGarMpvCye+ImX/lv509n+P0653YyAA0CwI7KsArc0rRLgSk16VJB+/oYbjCQIotEIYJmNL2EVdhQOHY+Puogs/7wZU+JDQEm0Rrel7WF+yt595WkOU6sGHxYvDbmHnwRX35TYLjg/B9aajB3GCoOM/d80ULHnxn9ly7algaoZJr2wjUTLwvpPzXELBnyEU2Kz3wSSthG+nCREkOpn/v4dRMKq1A3ZGLMJoRRCVRhXHFVTCdfLZ1fUqQeu4/+K8Ech/PPuS5io0CPI0RoFp3z0VaWb73q9NqO5zJxBrXhJQ3+F+8lMoZA8pAc3KvWK4wUxLMqrlXw6x5bl4JnHvqrPskyuIR6AciWL/mpfMbict9y6aiAlS8GCdY1Q6DUOU=
x-ms-office365-filtering-correlation-id: da41f077-d3c6-46bb-5d25-08d4ced0cbf4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR11MB1921; 
x-ms-traffictypediagnostic: BN6PR11MB1921:
x-exchange-antispam-report-test: UriScan:(151999592597050)(125551606395959)(133145235818549)(26388249023172)(236129657087228)(100405760836317)(148574349560750)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR11MB1921; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR11MB1921; 
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39400400002)(39410400002)(39450400003)(24454002)(377454003)(19609705001)(53936002)(478600001)(6116002)(3846002)(102836003)(790700001)(6306002)(54896002)(55016002)(53546010)(6246003)(236005)(9686003)(93886004)(99286003)(229853002)(6506006)(189998001)(38730400002)(6436002)(74316002)(77096006)(86362001)(25786009)(7696004)(5660300001)(8936002)(2950100002)(8676002)(80792005)(50986999)(4326008)(2906002)(81166006)(2900100001)(3280700002)(3660700001)(66066001)(7736002)(33656002)(14454004)(54356999)(76176999)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1921; H:BN6PR11MB1922.namprd11.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR11MB1922516F23D3307DC915906EF4A60BN6PR11MB1922namp_"
MIME-Version: 1.0
X-OriginatorOrg: fsroundtable.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 18:05:53.4672 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 841de5a0-73e8-4cbc-8142-f80b225ef22d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1921
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:05:58 -0000

--_000_BN6PR11MB1922516F23D3307DC915906EF4A60BN6PR11MB1922namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBJdCBzZWVtcyBsaWtlIHdlIHdvdWxkIGJlIHJlamVjdGluZyBhIGdvb2Qgb3Bwb3J0dW5pdHkg
dG8gbWFrZSB3aGF0IHRoZSBuZXR3b3JrIG9wZXJhdG9ycyB3YW50IHdvcmsgaW4gYSBiZXR0ZXIg
YW5kIG1vcmUgc2VjdXJlIHdheSwgd2hpbGUgbWFraW5nIGl0IGhhcmRlciBmb3IgcGFzc2l2ZSBv
YnNlcnZlcnMgYW5kIGNvZXJjaXZlIGF1dGhvcml0aWVzLCB0byB1c2UgdGhlIHNhbWUgbWVjaGFu
aXNtIGZvciBvdGhlciBwdXJwb3Nlcy4gV2hhdCBkbyB3ZSBnYWluPyBiZXlvbmQgYSBob2xsb3cg
bW9yYWwgdmljdG9yeS4NCg0KKzEgYW5kIHRoaXMgaXMgZnVuZGFtZW50YWxseSB3aHkgd2XigJl2
ZSBtYWRlIHNpZ25pZmljYW50IGVmZm9ydCB0byB3b3JrIHdpdGhpbiB0aGUgSUVURiBwcm9jZXNz
LiAgV2Ugc3Ryb25nbHkgYmVsaWV2ZSBhIGNvbnNlbnN1cyBvdXRjb21lIHdpbGwgYmUgYmV0dGVy
IGZvciBhbGwsIGluY2x1ZGluZyB0aG9zZSB3aG8gYXJlIGN1cnJlbnRseSBpbiBkaXNhZ3JlZW1l
bnQuICBXaGF0IHdl4oCZZCBsaWtlIHRvIGF2b2lkIGlzIGJlaW5nIHRvbGQgdGhlIHNvbHV0aW9u
IGlzIHRvIGlnbm9yZSAob3IgYWRtaXJlKSB0aGUgcHJvYmxlbS4gIEZpbmRpbmcgYSB3b3JrYWJs
ZSBzb2x1dGlvbiB3aWxsIHJlZHVjZSB0aGUgcmlzayBvZiBmb3JraW5nIFRMUyBhbmQgd2lsbCBp
bmNyZWFzZSB0aGUgYnJvYWQgYWRvcHRpb24gb2YgMS4zLg0KDQotQW5kcmV3DQoNCg0KDQpGcm9t
OiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENvbG0gTWFj
Q8OhcnRoYWlnaA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE5LCAyMDE3IDE6NDUgUE0NClRvOiBU
ZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpDYzogPHRsc0BpZXRmLm9yZz4gPHRsc0BpZXRm
Lm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBkYXRhY2VudGVyIFRMUyBkZWNyeXB0aW9uIGFzIGEg
dGhyZWUtcGFydHkgcHJvdG9jb2wNCg0KDQoNCk9uIFdlZCwgSnVsIDE5LCAyMDE3IGF0IDEwOjM4
IEFNLCBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb208bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20+
PiB3cm90ZToNClRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGFjdHVhbCBzb2x1dGlvbiB0byB0aGlz
IHByb2JsZW0gaXMgdG8gYWNjZXB0IHRoYXQgeW91IGFyZW4ndCBnb2luZyB0byBiZSBhYmxlIHRv
IGRlY3J5cHQgdGhlIHN0cmVhbXMsIGFuZCB0aGVuIGZpZ3VyZSBvdXQgd2hhdCB0byBkbyBpbnN0
ZWFkLiAgIFdoaWNoIGlzIHdvcmsgdGhlIHByb3BvbmVudHMgb2Ygbm90IGRvaW5nIHRoYXQgYXJl
IG5vdCBpbnRlcmVzdGVkIGluIGRvaW5nLCB1bmRlcnN0YW5kYWJseSwgYW5kIHdoaWNoIGlzIGFs
c28gbm90IHRoZSB3b3JrIG9mIHRoaXMgd29ya2luZyBncm91cC4NCg0KSSdtIHNrZXB0aWNhbCB0
aGF0IHRoZXJlIGlzIGEgd2F5IGZvciB0aGlzIHdvcmtpbmcgZ3JvdXAgdG8gc29sdmUgdGhlIHBy
b3Bvc2VkIHByb2JsZW0sIGJ1dCBpZiB0aGVyZSBpcywgaXQgaW52b2x2ZXMgZmlndXJpbmcgb3V0
IGEgd2F5IHRvIGRvIHRoaXMgdGhhdCBkb2Vzbid0IG1ha2UgaXQgZWFzeSB0byBNaVRNIG15IGNv
bm5lY3Rpb25zLCBvciwgc2F5LCB0aG9zZSBvZiBhY3RpdmlzdHMgaW4gZGFuZ2Vyb3VzIHBsYWNl
cy4NCg0KSSBmaW5kIHRoaXMgYSB2ZXJ5IGJpemFycmUgb3V0Y29tZSB0aGF0IHdvcmtzIGFnYWlu
c3Qgb3VyIGNvbGxlY3RpdmUgZ29hbHMuIElmIHRoZXJlIGlzIG5vIG1lY2hhbmlzbSBhdCBhbGws
IHRoZW4gaXQgaXMgcXVpdGUgbGlrZWx5IHRoYXQgb3JnYW5pemF0aW9ucyB3aWxsIHVzZSBzdGF0
aWMtREggb3Igc3RheSBvbiBUTFMxLjIuIFRob3NlIGFyZSBiYWQgb3B0aW9ucywgaW4gbXkgb3Bp
bmlvbiwgYmVjYXVzZSB0aGVyZSdzIG5vIHNpZ25hbGluZyBvciBvcHQtaW4gdG8gdGhlIGNsaWVu
dC4gV2UgY2FuIGRvIG11Y2ggYmV0dGVyIHRoYW4gdGhhdC4gIENsaWVudCBvcHQtaW5zIGFyZSBm
YXIgZnJvbSBhY2FkZW1pYy4gRm9yIGV4YW1wbGUsIGJyb3dzZXIncyBpbmNvZ25pdG8gbW9kZXMg
bWF5IHJlZnVzZSB0byBzdXBwb3J0IHN1Y2ggc2Vzc2lvbnMsIGlmIHRoZXkga25ldyB3aGF0IHdh
cyBnb2luZyBvbi4NCg0KSXQncyBhbHNvIGJhZCBpZiBvcmdhbml6YXRpb25zIGVuZCB1cCBkZXBs
b3lpbmcgc3RhdGljLURIIGFuZCB0aGF0IG1lYW5zIHdlIGNhbid0IGRvIHRoaW5ncyBsaWtlIGNo
ZWNraW5nIGZvciBjaGFuZ2luZyBESCBwYXJhbWV0ZXJzLg0KDQpJdCBzZWVtcyBsaWtlIHdlIHdv
dWxkIGJlIHJlamVjdGluZyBhIGdvb2Qgb3Bwb3J0dW5pdHkgdG8gbWFrZSB3aGF0IHRoZSBuZXR3
b3JrIG9wZXJhdG9ycyB3YW50IHdvcmsgaW4gYSBiZXR0ZXIgYW5kIG1vcmUgc2VjdXJlIHdheSwg
d2hpbGUgbWFraW5nIGl0IGhhcmRlciBmb3IgcGFzc2l2ZSBvYnNlcnZlcnMgYW5kIGNvZXJjaXZl
IGF1dGhvcml0aWVzLCB0byB1c2UgdGhlIHNhbWUgbWVjaGFuaXNtIGZvciBvdGhlciBwdXJwb3Nl
cy4gV2hhdCBkbyB3ZSBnYWluPyBiZXlvbmQgYSBob2xsb3cgbW9yYWwgdmljdG9yeS4NCg0KLS0N
CkNvbG0NCg==

--_000_BN6PR11MB1922516F23D3307DC915906EF4A60BN6PR11MB1922namp_
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
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
Jmd0Ozwvc3Bhbj4gSXQgc2VlbXMgbGlrZSB3ZSB3b3VsZCBiZSByZWplY3RpbmcgYSBnb29kIG9w
cG9ydHVuaXR5IHRvIG1ha2Ugd2hhdCB0aGUgbmV0d29yayBvcGVyYXRvcnMgd2FudCB3b3JrIGlu
IGEgYmV0dGVyIGFuZCBtb3JlIHNlY3VyZQ0KIHdheSwgd2hpbGUgbWFraW5nIGl0IGhhcmRlciBm
b3IgcGFzc2l2ZSBvYnNlcnZlcnMgYW5kIGNvZXJjaXZlIGF1dGhvcml0aWVzLCB0byB1c2UgdGhl
IHNhbWUgbWVjaGFuaXNtIGZvciBvdGhlciBwdXJwb3Nlcy4gV2hhdCBkbyB3ZSBnYWluPyBiZXlv
bmQgYSBob2xsb3cgbW9yYWwgdmljdG9yeS4mbmJzcDs8bzpwPjwvbzpwPjwvYT48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPiYjNDM7MSBhbmQgdGhpcyBpcyBmdW5kYW1lbnRhbGx5IHdoeSB3ZeKA
mXZlIG1hZGUgc2lnbmlmaWNhbnQgZWZmb3J0IHRvIHdvcmsgd2l0aGluIHRoZSBJRVRGIHByb2Nl
c3MuJm5ic3A7IFdlIHN0cm9uZ2x5IGJlbGlldmUgYSBjb25zZW5zdXMgb3V0Y29tZSB3aWxsIGJl
IGJldHRlciBmb3IgYWxsLA0KIGluY2x1ZGluZyB0aG9zZSB3aG8gYXJlIGN1cnJlbnRseSBpbiBk
aXNhZ3JlZW1lbnQuJm5ic3A7IFdoYXQgd2XigJlkIGxpa2UgdG8gYXZvaWQgaXMgYmVpbmcgdG9s
ZCB0aGUgc29sdXRpb24gaXMgdG8gaWdub3JlIChvciBhZG1pcmUpIHRoZSBwcm9ibGVtLiZuYnNw
OyBGaW5kaW5nIGEgd29ya2FibGUgc29sdXRpb24gd2lsbCByZWR1Y2UgdGhlIHJpc2sgb2YgZm9y
a2luZyBUTFMgYW5kIHdpbGwgaW5jcmVhc2UgdGhlIGJyb2FkIGFkb3B0aW9uIG9mIDEuMy4mbmJz
cDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LUFuZHJldzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5D
b2xtIE1hY0PDoXJ0aGFpZ2g8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDE5LCAy
MDE3IDE6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlZCBMZW1vbiAmbHQ7bWVsbG9uQGZ1Z3VlLmNv
bSZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0Zi5v
cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBkYXRhY2VudGVyIFRMUyBkZWNy
eXB0aW9uIGFzIGEgdGhyZWUtcGFydHkgcHJvdG9jb2w8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBXZWQsIEp1bCAxOSwgMjAxNyBhdCAxMDozOCBBTSwgVGVkIExlbW9uICZsdDs8YSBocmVm
PSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1lbGxvbkBmdWd1ZS5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgYWN0dWFsIHNvbHV0aW9u
IHRvIHRoaXMgcHJvYmxlbSBpcyB0byBhY2NlcHQgdGhhdCB5b3UgYXJlbid0IGdvaW5nIHRvIGJl
IGFibGUgdG8gZGVjcnlwdCB0aGUgc3RyZWFtcywgYW5kIHRoZW4gZmlndXJlIG91dCB3aGF0IHRv
IGRvIGluc3RlYWQuICZuYnNwOyBXaGljaCBpcyB3b3JrIHRoZSBwcm9wb25lbnRzIG9mIG5vdCBk
b2luZyB0aGF0IGFyZSBub3QgaW50ZXJlc3RlZCBpbg0KIGRvaW5nLCB1bmRlcnN0YW5kYWJseSwg
YW5kIHdoaWNoIGlzIGFsc28gbm90IHRoZSB3b3JrIG9mIHRoaXMgd29ya2luZyBncm91cC48bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBza2VwdGljYWwg
dGhhdCB0aGVyZSBpcyBhIHdheSBmb3IgdGhpcyB3b3JraW5nIGdyb3VwIHRvIHNvbHZlIHRoZSBw
cm9wb3NlZCBwcm9ibGVtLCBidXQgaWYgdGhlcmUgaXMsIGl0IGludm9sdmVzIGZpZ3VyaW5nIG91
dCBhIHdheSB0byBkbyB0aGlzIHRoYXQgZG9lc24ndCBtYWtlIGl0IGVhc3kgdG8gTWlUTQ0KPGk+
bXk8L2k+Jm5ic3A7Y29ubmVjdGlvbnMsIG9yLCBzYXksIHRob3NlIG9mIGFjdGl2aXN0cyBpbiBk
YW5nZXJvdXMgcGxhY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZmluZCB0aGlzIGEgdmVyeSBi
aXphcnJlIG91dGNvbWUgdGhhdCB3b3JrcyBhZ2FpbnN0IG91ciBjb2xsZWN0aXZlIGdvYWxzLiBJ
ZiB0aGVyZSBpcyBubyBtZWNoYW5pc20gYXQgYWxsLCB0aGVuIGl0IGlzIHF1aXRlIGxpa2VseSB0
aGF0IG9yZ2FuaXphdGlvbnMgd2lsbCB1c2Ugc3RhdGljLURIIG9yIHN0YXkgb24gVExTMS4yLiBU
aG9zZSBhcmUgYmFkIG9wdGlvbnMsIGluIG15IG9waW5pb24sIGJlY2F1c2UNCiB0aGVyZSdzIG5v
IHNpZ25hbGluZyBvciBvcHQtaW4gdG8gdGhlIGNsaWVudC4gV2UgY2FuIGRvIG11Y2ggYmV0dGVy
IHRoYW4gdGhhdC4mbmJzcDsgQ2xpZW50IG9wdC1pbnMgYXJlIGZhciBmcm9tIGFjYWRlbWljLiBG
b3IgZXhhbXBsZSwgYnJvd3NlcidzIGluY29nbml0byBtb2RlcyBtYXkgcmVmdXNlIHRvIHN1cHBv
cnQgc3VjaCBzZXNzaW9ucywgaWYgdGhleSBrbmV3IHdoYXQgd2FzIGdvaW5nIG9uLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCdzIGFsc28g
YmFkIGlmIG9yZ2FuaXphdGlvbnMgZW5kIHVwIGRlcGxveWluZyBzdGF0aWMtREggYW5kIHRoYXQg
bWVhbnMgd2UgY2FuJ3QgZG8gdGhpbmdzIGxpa2UgY2hlY2tpbmcgZm9yIGNoYW5naW5nIERIIHBh
cmFtZXRlcnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkl0IHNlZW1zIGxpa2Ugd2Ugd291bGQgYmUgcmVqZWN0aW5nIGEgZ29vZCBv
cHBvcnR1bml0eSB0byBtYWtlIHdoYXQgdGhlIG5ldHdvcmsgb3BlcmF0b3JzIHdhbnQgd29yayBp
biBhIGJldHRlciBhbmQgbW9yZSBzZWN1cmUgd2F5LCB3aGlsZSBtYWtpbmcgaXQgaGFyZGVyIGZv
ciBwYXNzaXZlIG9ic2VydmVycyBhbmQgY29lcmNpdmUgYXV0aG9yaXRpZXMsIHRvIHVzZSB0aGUg
c2FtZSBtZWNoYW5pc20gZm9yIG90aGVyDQogcHVycG9zZXMuIFdoYXQgZG8gd2UgZ2Fpbj8gYmV5
b25kIGEgaG9sbG93IG1vcmFsIHZpY3RvcnkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db2xtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BN6PR11MB1922516F23D3307DC915906EF4A60BN6PR11MB1922namp_--


From nobody Wed Jul 19 11:06:18 2017
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 46AF4131B9B for ; Wed, 19 Jul 2017 11:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 WSHF1Cddcrai for ; Wed, 19 Jul 2017 11:06:14 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6821B12785F for ; Wed, 19 Jul 2017 11:06:12 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6JI6A1n018619; Wed, 19 Jul 2017 14:06:10 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: "Dobbins, Roland" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulwkltwWiCLAkez9/LKtukmkaJYpiSAgAAE/ICAAtZXgIAAGYoA//++zoCAAEWCAIAABMAA///DOoCAAFAQAP//vjeA
Date: Wed, 19 Jul 2017 18:06:09 +0000
Message-ID: <1CA52ED8-3119-41CD-AD51-EA5DC7B77ADD@ll.mit.edu>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <2FAFADF2-F791-406B-9519-EAB266AC2FCD@arbor.net>
In-Reply-To: <2FAFADF2-F791-406B-9519-EAB266AC2FCD@arbor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583317969_1020197046"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707190284
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:06:16 -0000

--B_3583317969_1020197046
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

    > Or are you simply trying to delay the inevitable?
   =20
    I'm open to any solution which meets the stated requirements & is deplo=
yable & usable on real-world
    production networks, without necessitating a total redesign of said net=
works & the complete social
    reorganization of the entities in question.=20
   =20
    ;>

It=E2=80=99s not the networks that need to be =E2=80=9Ctotally redesigned=E2=80=9D, but the m=
echanism to do surveillance. And only for some kinds of traffic (that uses T=
LS 1.3).
And we are not talking about =E2=80=9Ccomplete=E2=80=9D =E2=80=9Csocial reorganization=E2=80=9D of =
the entities (if you mean endpoints) =E2=80=93 most of them already carry all that=
=E2=80=99s necessary (and more) to perform surveillance from inside the endpoint.
   =20
    There's some very constructive discussion taking place now about the re=
lative merits of various approaches, & I'm following it quite keenly.=20

So am I. ;>
   =20
    -----------------------------------
    Roland Dobbins 
   =20

--B_3583317969_1020197046
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU
WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO
DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A
97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN
YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR
COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x
dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01
c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ
KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G
/F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL
e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c
A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgkwy3dY/+/ylHD4CT
NES5Zd23/VFyrvSxBPXG++1w5WwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE5MTgwNjA5WjANBgkqhkiG9w0BAQEFAASCAQBZatoI1hZ3JIKT2Gd+
kIaGw+LpTGuHZ4Y1UnPe36ltTxvNXW7+YOSWUYMzLP36jaWIEhNANqSnTbBkEBUDVOc8NF0Z
Ac8dhEOJLZVh6qvJRVEVe/B/cOY55usd5HJLzEcaCz5OurZMcV4DQBU7sM3LPTLtodIp6dn5
zGlTe8L3AhgzuaDdu8pM2gl/UNyKf33zclWcyT0cpr/D9y4KJTyIjEQt1y45i6XbYAZOG4+X
aN0nKHL3AUjNA0rAYnhzxSQOqxbHbTIVmBAQVorcfOQOcaWxDPhwgXtpY6dmwaS1GIDK5l+v
BgfFoSHchgA25AqwJsyw9r9DxqHz/prGhFy6

--B_3583317969_1020197046--


From nobody Wed Jul 19 11:14:52 2017
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 31471131AAF for ; Wed, 19 Jul 2017 11:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 otGQuu8SiMFl for ; Wed, 19 Jul 2017 11:14:49 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0110.outbound.protection.outlook.com [104.47.38.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCF712EC18 for ; Wed, 19 Jul 2017 11:14:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sDUZB53YF/6DOovSjdwdmZwDSfI4la3IcDh5+tdkRYY=; b=BDJoi+rI/yaCuTZspDWmG0YYlnoG8JoK48VtJ+jOzGZBnU0fPMmWJ924885q9I/MR0f3N31Pr1WsWIELITB0K2+v8up/CSNPFMRj4k14cC4rR8jeVH7UyAIu/qRhHTY9wp9deVoIjIq0RKi9ovIU5ELyZhZ2HGTH249ZgYldr0w=
Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1040.prod.exchangelabs.com (10.160.129.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:14:48 +0000
Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 18:14:47 +0000
From: "Dobbins, Roland" 
To: "Blumenthal, Uri - 0553 - MITLL" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulnreU48MdBA0WwDcIvwebnRKJYYxaAgAB6VYCAAmD9gIAAGYsAgAAB3ICAAAJ0AIAABMBagAAGSICAAA0CfoAAAUWAgAACapc=
Date: Wed, 19 Jul 2017 18:14:47 +0000
Message-ID: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <2FAFADF2-F791-406B-9519-EAB266AC2FCD@arbor.net>, <1CA52ED8-3119-41CD-AD51-EA5DC7B77ADD@ll.mit.edu>
In-Reply-To: <1CA52ED8-3119-41CD-AD51-EA5DC7B77ADD@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net;
x-originating-ip: [88.208.89.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1040; 7:N2FUjZcZLicUtvsi+Oe1RBE/nc6OJiwsxwxMmrvhdhIlG+20PG0gBgiEfI7kqlwGq0GvjTvhC4xSEqWCpwyQayAgTZ0IAGHHe+TKeqskPkFE8Vbpj3IwYgjoMe6ueYSdLbPECysHwAftb2aIlGMKsSxA755jwbCHj6r6lDeWBBt7aT21ZIBtAoKFVg/fReqLD02Qt7rMRhGkn9JXScIHe1IPobkyeXuEH/sK++wfkBIdFBT2NYRU32FISpcRbskftJT6zIRzgm+Ivw90oU89SPq6JhbbOdAKm7kCiAsqdH+Rpxgb8fCMQ818vjgd0XQ5ya2NXk1RmIuxcUvE+6DnvA4S5JeYlZXxrMAjNmPb/ylarTmJ56baaxHc9b9AuDgHHGuSMJwsfThucKAWZioNl95wLYqGQbGtzD71CBoaoF8j/B7pmWRERas+8emGZJZvvBYx0ia4ws9Z4ami5DkGNhp6URwcfHfSsuS9sBMAWl7PiMAN2OlRMdyTvo85pWAE4NVgyXKL/2Dr+GjW9v4Pq5w/pnj/iMfoAP5gceG44mLEeRwKu9jyap9GQ7AJzTurqdLKtC6c0wB14w3g+BnKuzxSRLEWmVPg2sWBUn761fZE1UW1MheIdMKwrC214u9tl86jWbvE60F48W7KRAkLhZWWbiigcAOaoKVV/4pH9ZVvGMNCODyKyqo4AD94Xe41Oy7oDwJICBeFcOBd0GNXHyxkG8YttWfaO16aAP9gOjwqhsY0vysG0FUehq0xJW+4XxLA73dLfml6dPYu5I7zsfKF9uhAD7ZKDuxyYU1jPDk=
x-ms-office365-filtering-correlation-id: 9b316852-86a9-4e56-2d8c-08d4ced20a46
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1040; 
x-ms-traffictypediagnostic: DM2PR0101MB1040:
x-exchange-antispam-report-test: UriScan:(236129657087228)(17755550239193);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1040; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1040; 
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(39850400002)(24454002)(6486002)(82746002)(8676002)(8936002)(5250100002)(2900100001)(6506006)(93886004)(81166006)(14454004)(53546010)(38730400002)(6916009)(189998001)(2950100002)(2171002)(110136004)(83716003)(478600001)(6246003)(230783001)(5660300001)(2906002)(33656002)(53936002)(6512007)(3660700001)(3280700002)(4326008)(229853002)(25786009)(76176999)(50986999)(102836003)(54356999)(6436002)(99286003)(66066001)(305945005)(7736002)(3846002)(86362001)(6116002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1040; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 18:14:47.5345 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1040
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:14:51 -0000

DQoNCj4gT24gSnVsIDE5LCAyMDE3LCBhdCAyMDowNiwgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAt
IE1JVExMIDx1cmlAbGwubWl0LmVkdT4gd3JvdGU6DQo+IA0KPiBtb3N0IG9mIHRoZW0gYWxyZWFk
eSBjYXJyeSBhbGwgdGhhdOKAmXMgbmVjZXNzYXJ5IChhbmQgbW9yZSkgdG8gcGVyZm9ybSBzdXJ2
ZWlsbGFuY2UgZnJvbSBpbnNpZGUgdGhlIGVuZHBvaW50Lg0KDQpVbmZvcnR1bmF0ZWx5LCB0aGlz
IGlzIG5vdCB0aGUgY2FzZS4gIFF1aXRlIHRoZSBvcHBvc2l0ZSwgYWN0dWFsbHkuIA0KDQpJdCdz
IGFscmVhZHkgYmVlbiBleHBsYWluZWQgd2h5IGVuZHBvaW50LWJhc2VkIG1lYXN1cmVzIGFyZSBp
bXByYWN0aWNhbC4gIElmIHRoZXkgd2VyZSBwcmFjdGljYWwsIHRoZXknZCBhbHJlYWR5IGJlIGlu
IHdpZGVzcHJlYWQgdXNlLCBhbmQgdGhpcyB3b3VsZG4ndCBiZSBhbiBpc3N1ZSBpbiB0aGUgZmly
c3QgcGxhY2UuIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUm9sYW5k
IERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD4=


From nobody Wed Jul 19 11:18:29 2017
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 5F1AF12EC18 for ; Wed, 19 Jul 2017 11:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 fMvnEXTuCFz7 for ; Wed, 19 Jul 2017 11:18:25 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0138.outbound.protection.outlook.com [104.47.38.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9012F131822 for ; Wed, 19 Jul 2017 11:18:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8qUHAmKBbGxFzU1ZyQ2R2/hNhHTePD0Fc+ldGItBo0I=; b=Sc1yC4jATOrD4Oq9ZPdCI8oazjCDM8otbFHBb+YL38Ud/gqeSQ61rpLjxwa+Fh93wfIWiUmTXqXNLlTLdkJRPFTrfQCgSKs/BoHPG1sSYoRHjW9ShgwzCa7fywU9MgVC4BOAAIeIQq3Ba8MOGlw6Q5NKt4IdvAFLLvzhZrENYd0=
Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1038.prod.exchangelabs.com (10.160.129.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:18:23 +0000
Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::810f:2255:5d85:2fc7%17]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 18:18:23 +0000
From: "Dobbins, Roland" 
To: "Blumenthal, Uri - 0553 - MITLL" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulnreU48MdBA0WwDcIvwebnRKJYYxaAgAB6VYCAAmD9gIAAGYsAgAAB3ICAAAJ0AIAABMBagAAGSICAAA0CfoAAAUWAgAADa8Q=
Date: Wed, 19 Jul 2017 18:18:23 +0000
Message-ID: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <2FAFADF2-F791-406B-9519-EAB266AC2FCD@arbor.net>, <1CA52ED8-3119-41CD-AD51-EA5DC7B77ADD@ll.mit.edu>
In-Reply-To: <1CA52ED8-3119-41CD-AD51-EA5DC7B77ADD@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net;
x-originating-ip: [88.208.89.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1038; 7:v9cwW2Z72LPDwKDxlhPN1+yfMBnB2A+vF+nf5m9ElmRqGHhklyJv6Np6002bdeo/t/Xd8CcD9iH8Ko0qvBz3a/kh2i8HGIuXxY0xwHhqi/ucErbmhlm0fT9gByLpiuGG39s7PBEruZOuheL0y9cFMTr6q+guPikkC0Xx3wouJyksGBdIsjkI1+ZOjxqrCJ9HsXNRu52rdJfKLZ7mJV+Ccb/hNYJKNdsJ8GaSQ/HKOpnNjzFhGta3TUTiRYEHLZs4B7TiYh90/Qx6VI7jw17T1lQOw2/eef+4ipcWScLvRdZRLz+mXMYUF5uf5Kled9SWVEub6TeZfGOR0Yx+n5OTDcpSAEu8J4dz5aw1lHjHTPnfCHqDLOsaiNONwn0FgQnmmvhsJCeLc5pmDFJDcrP3LE13ahnVab39qk0TUVBwPH6nfMViJjsD8Mp0BcgNuiLrP9O+4bn3WIoENYjzZUYngGvvK7IGr4VZjtW4XZ9nUQuGTqOA9qa73sVenW0NPo383HZpwRFh14GufhhZHfWCQ2cUZN6L+O+IjK6aXl9M0p4/COpHGQQcUJgKDKy9pg2lX+CzgXKCNRvd6HUtUJKwfI9JIZY+BH5TpmWPLbHjVy3IPBcVBjV5R7b9CBroEZiylZa+BIacvBU5ramYcP7WVPCWL2ZeSWsJIpjJ2gKiBWfFr+/FOIVT/rsvTYps9QRRT8w429DOWULGhTpe66FAQIvkwd6Kyy2rPZE/gGHB8elUYOjd66QmmA0p3grZ5s/QjSEYlijcvN1tbW1u9KLPNiUbub6WJob8lE41l1E/2RI=
x-ms-office365-filtering-correlation-id: 38d3b560-dce3-42e0-0867-08d4ced28ac5
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1038; 
x-ms-traffictypediagnostic: DM2PR0101MB1038:
x-exchange-antispam-report-test: UriScan:(236129657087228);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1038; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1038; 
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39400400002)(39450400003)(39840400002)(24454002)(6436002)(66066001)(99286003)(2950100002)(189998001)(82746002)(2906002)(6512007)(6916009)(83716003)(6116002)(3846002)(86362001)(102836003)(6486002)(478600001)(33656002)(2900100001)(14454004)(305945005)(7736002)(6506006)(3660700001)(230783001)(93886004)(2171002)(6246003)(38730400002)(110136004)(4326008)(5660300001)(8676002)(53936002)(53546010)(5250100002)(81166006)(25786009)(54356999)(36756003)(50986999)(3280700002)(229853002)(8936002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1038; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 18:18:23.0830 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1038
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:18:27 -0000

DQoNCj4gT24gSnVsIDE5LCAyMDE3LCBhdCAyMDowNiwgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAt
IE1JVExMIDx1cmlAbGwubWl0LmVkdT4gd3JvdGU6DQo+IA0KPiBJdOKAmXMgbm90IHRoZSBuZXR3
b3JrcyB0aGF0IG5lZWQgdG8gYmUg4oCcdG90YWxseSByZWRlc2lnbmVk4oCdLCBidXQgdGhlIG1l
Y2hhbmlzbSB0byBkbyBzdXJ2ZWlsbGFuY2UuDQoNCllvdSB1bmRlcmVzdGltYXRlIHRoZSBjYXNj
YWRlIGVmZmVjdCBvZiBzdWNoIG1lYXN1cmVzLiAgSXQncyBuZWl0aGVyIG9wZXJhdGlvbmFsbHkg
bm9yIGVjb25vbWljYWxseSB2aWFibGUuIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD4=


From nobody Wed Jul 19 11:29:40 2017
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 BE50A12EAB0 for ; Wed, 19 Jul 2017 11:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DKKC_dCa2BBS for ; Wed, 19 Jul 2017 11:29:37 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 069911300CE for ; Wed, 19 Jul 2017 11:29:37 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id q85so3133862pfq.1 for ; Wed, 19 Jul 2017 11:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8nz0l/CcIqjqnicGTrzNDF6DR4wViV2e1YS5GzP5EA=; b=CHuTDfYjgEgB4HPrW2Em2ek74WayZ2K6vRvpkPPVIzdKalz5L5MATrsrZpefSvwVKR 69onseTQdZnwEQlAIWBIK6Ou3ePM5kRzYoF9Y+vhwkl8o5az4l+i7OcUa5zD8VURoOmq s+bXVgzpHV4JzzCz7mzssvXGgdnejoLM+kWIiv4L6Tce2jnpqgZcSvo4LfBOPno+3K3t wSzm+Q0WAvwQ2GDRitfi0ULj/lYs5SXrseuxrsK0sG9M8dRbABf8iZlo3DAnERMnIREk zYLN2ZqwplIHamXRmTmu0CjtuqiqyG7wwb7VcQHViNv93Q0MKoEfhD8AsvFIF9XWweo8 Owdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8nz0l/CcIqjqnicGTrzNDF6DR4wViV2e1YS5GzP5EA=; b=ScJp4WK8GPuSR9GPXRhiICYnFsPkQxG+CHiskCegJ/bEbQmq3SZM4ifDOiEyHnXsdM gtUKazVTP7PKBMIaYeV62E7WpTYYgsjCdLHnurVrhyuJbjFdyEYgfuzO6ucT4LdmBFFK EWc1ELkLkAfWp4Be9M/fSyIkYyyHDbX/GES6GDO1G567G2VtfIzlv1xihCJtGLOGHbSJ 1TUAnAxkNrpbIjdbPL6zCp5KtNsoYhUgz/Q8eHfCUK9juhrQTfhU/xd4CH5HozIDZk8H Zm/zrLV7wDMIn3wpN7TZPd0q69ZZ01/HzEJzH8F9YIq3mDnzWw9yQtQ/Squbw9M5912m BjaA==
X-Gm-Message-State: AIVw110W6jzW1IEnsXJzz5cklHuE/B3S24INRYGmcAuNC3prYBE+AXmk jjw2o+YRaysl4qLDwGjHdANI86YHOw==
X-Received: by 10.84.167.2 with SMTP id c2mr1054544plb.366.1500488976596; Wed, 19 Jul 2017 11:29:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Wed, 19 Jul 2017 11:29:35 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Wed, 19 Jul 2017 11:29:35 -0700 (PDT)
In-Reply-To: <0739E598-8CE6-4B41-BFC2-4085218A06A6@arbor.net>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <5E90933D-3D9F-4166-808D-7ECE53D264F4@arbor.net>  <0739E598-8CE6-4B41-BFC2-4085218A06A6@arbor.net>
From: Watson Ladd 
Date: Wed, 19 Jul 2017 11:29:35 -0700
Message-ID: 
To: "Dobbins, Roland" 
Cc: "Blumenthal, Uri - 0558 - MITLL" , tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c145bae70834a0554afd0bc"
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:29:39 -0000

--94eb2c145bae70834a0554afd0bc
Content-Type: text/plain; charset="UTF-8"

On Jul 19, 2017 10:54 AM, "Dobbins, Roland"  wrote:



On Jul 19, 2017, at 19:48, Watson Ladd  wrote:

Technical solutions to political problems are not the right approach.


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


Conversely, technical solutions which do not take into account operational
reality don't benefit those who need them the most.

Sadly, we don't have the luxury of starting from a clean slate.


You started with a long list of requirements which had to be met by
interception. Now it turns out that the requirements on solutions came from
organizational issues you never told us about.

I still don't see a response to how you determine unauthorized access
happened without being the authority on what access is authorized.
Apparently exporting the PMS from clients and servers  isn't possible: I
find that hard to believe.

Let's standardize an extension that exports an encrypted EMS and be done
with this debate.


-----------------------------------
Roland Dobbins 

--94eb2c145bae70834a0554afd0bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Jul 19, 2017 10:54 AM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:
















On Jul 19, 2017, at 19:48, Watson Ladd <watsonbladd@gmail.com> wrote:










Technical solutions to political problems are not the rig=
ht approach.












-----------------------------------

Roland Dobbins <=
rdobbins@arbor.net>

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls


















Conversely, technical solutions which do not take into account o=
perational reality don't benefit those who need them the most.=C2=A0






Sadly, we don't have the luxury of starting from a clean slate. =
=C2=A0

You started with a long list of requirements which had =
to be met by interception. Now it turns out that the requirements on soluti=
ons came from organizational issues you never told us about.

I still don't see a response to h=
ow you determine unauthorized access happened without being the authority o=
n what access is authorized. Apparently exporting the PMS from clients and =
servers =C2=A0isn't possible: I find that hard to believe.

Let's standardize an extension t=
hat exports an encrypted EMS and be done with this debate.







-----------------------------------




Roland Dobbins <rdobbins@arbor.net=
>










--94eb2c145bae70834a0554afd0bc--


From nobody Wed Jul 19 11:37:48 2017
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 E5F1312EAB0 for ; Wed, 19 Jul 2017 11:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 mMLHVZRgVWP8 for ; Wed, 19 Jul 2017 11:37:44 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80E12711E for ; Wed, 19 Jul 2017 11:37:44 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6JIbc2s037608; Wed, 19 Jul 2017 14:37:38 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: "Dobbins, Roland" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulwkltwWiCLAkez9/LKtukmkaJYpiSAgAAE/ICAAtZXgIAAGYoA//++zoCAAEWCAIAABMAA///DOoCAAFAQAP//vjeAAAivAYD//8NRAA==
Date: Wed, 19 Jul 2017 18:37:37 +0000
Message-ID: <03E785A6-5C65-4DB0-AFD7-65DD7B4C94B1@ll.mit.edu>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <2FAFADF2-F791-406B-9519-EAB266AC2FCD@arbor.net> <1CA52ED8-3119-41CD-AD51-EA5DC7B77ADD@ll.mit.edu> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583319857_1453733097"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707190290
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:37:47 -0000

--B_3583319857_1453733097
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

    > most of them already carry all that=E2=80=99s necessary (and more) to perfo=
rm surveillance from inside the endpoint.
   =20
    Unfortunately, this is not the case.  Quite the opposite, actually.=20
   =20
    It's already been explained why endpoint-based measures are impractical=
.=20
    If they were practical, they'd already be in widespread use, and this w=
ouldn't be an issue in the first place.=20

When there is a pool of data waiting for the operator to (figuratively spea=
king) push a button on a switch and start intercepting the traffic in plaint=
ext =E2=80=93 there=E2=80=99s no need to go through the extra inconvenience of using end=
points for that. No surprise.

I keep telling that this pool is drying up. It=E2=80=99s =E2=80=9Cgo to endpoint for th=
e plaintext=E2=80=9D or =E2=80=9Csorry, no plaintext at all=E2=80=9D (or =E2=80=9Cstay with the old =
stuff =E2=80=93 using old-rotten methods goes hand-in-hand with the bit-rot of the=
 older protocols=E2=80=9D).

--B_3583319857_1453733097
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU
WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO
DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A
97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN
YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR
COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x
dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01
c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ
KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G
/F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL
e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c
A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgP/RZWZXXBmzo8Ye2
ZRSkk6htGdyU0UdqtEM0qMk1hMwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzE5MTgzNzM2WjANBgkqhkiG9w0BAQEFAASCAQB2ZRKNaSn8igzqTE9r
dY3gWXSkRBO+YUap2gTpoZId7WQzV0WDenwPMX7+QOhKBn2/ZQSxiSWq9EbI1IxReEibcC7W
7c01vowoQJz8HSvNqCF9HZadig3G8s3xKJCE8C5qO/dpZ1ombcB/Cwr1Gq3lDkz85e2CHxjc
buCLh/JwMUPQPIlX+UMuFBHvwYIMePnMMTJrZf9D30DqFp75ddUrfiqhxH9sRiOAPFos6DXP
zws6xPQ7Lv7XNTbGvtFUtOneow8EYzcQ1Ryle8ZqmXi3pwEi8elQu8IevQbGvulwjW1Mxx2S
m5WbUGgTKHkcgotEXvdq2VF/t7QpckCfPqzQ

--B_3583319857_1453733097--


From nobody Wed Jul 19 11:38:34 2017
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 F1C45131B3E for ; Wed, 19 Jul 2017 11:38:32 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 opNMp-ij42xb for ; Wed, 19 Jul 2017 11:38:31 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0096.outbound.protection.outlook.com [104.47.40.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D305B12711E for ; Wed, 19 Jul 2017 11:38:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BlyRg1PqM8aN5jMSK5uhM5ij5g1fdcVV4OU99f7Y+tE=; b=nhGpHMIBNr5r3nknVZfIjFQSGvIcyaUz9QsXpqjCSnOActnXSzXYPz0U7b11RUApEabAnKGjSdYk5pDDqnXKuq8VjDqLSjIIe0tun73Qpr0WwPHi0XnMaHSUfnWJv/LsucsOh2DX6jVUbXYVs3NwyQlp7K5q+mZzxAoEg/HydX4=
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:38:27 +0000
From: "Roland Dobbins" 
To: "Watson Ladd" 
Cc: "Blumenthal, Uri - 0558 - MITLL" , tls@ietf.org
Date: Wed, 19 Jul 2017 20:38:14 +0200
Message-ID: <2D273F40-2DF4-431D-9392-5B492409363C@arbor.net>
In-Reply-To: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <5E90933D-3D9F-4166-808D-7ECE53D264F4@arbor.net>  <0739E598-8CE6-4B41-BFC2-4085218A06A6@arbor.net> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: VI1P195CA0005.EURP195.PROD.OUTLOOK.COM (2603:10a6:800:d0::15) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 844a6e89-f57c-493d-643c-08d4ced558d0
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; 
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:XGyTC8nGBNpC5YZQZo1uP9MYEZplupYEQP0o/jrR8u8ZPBan8J1Dz21Qc5RULKjVUttXl5vpoBt6RZymXyNhrQVb/XzyjImPv87H2NkzhmkRDcRnwQ3g46Y5ZSDYKk5/GKxZgzx8b0x6pvjolm+csxY/Fq1lGArKRnzbojBjhnQGPbGuXK6Q6A6enJa5RIS6y9l0dEJUL2ICmZXqIZAlimqqWO2znYm/tx2fziJjn/JkBWISEzyCzn0KOevviSo5BHaj6hhOvF7s++UiUivMpw9rYWEiJwdrfTF92dCsZNk9bSXwOOEA1AoyjdxFvQwzQM2Nes1fqeiujhIOz2Ot9AmgiZg02foW4l3x0VaZyytgzALB6bkR4MHHgpRJDoBtXbCmB5ab/BRzt0EjtjS2yuapzjEn4IP3WNbXzeCkFVx0LKOoR+l1MR3sacmiDfDht6P5AApYa7BnUVDhN08DlQH0mQvmgNq5auYy8auWrFjPwsDcQr1cK83ak4mzP2n8DauDfQp/A8tUJAQ2xigHK6T/dS6xUIAz6QJ5/3hbu1dpYUGCt6rlZDXU/DfmLJ1xw+jIQMMddXeTneiF5UBExmbqnjJXxqrd8mJq3f54u8N3YGXm/t65Ab3SU0Wf7lIvobl7OewTzyOMXt9OXjU3kt4sPOmm2WgwKhV37xTG9/8FS1zYp58uWhTyOOwVmik7/UGTKab+eH2s5W8VikLzNLXu/nEckGEm+maEttz05mM=
X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039:
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 25:lTJGo1Ozm9QpCzOBnYgvkuw6kMgOazK7dOlroOISWUsr+F53GmAI23Gimb30+x/zf8+rLzIChg8GlTBzMLTXX+j/fJ6AEkMd4R7+JhKDHUilaPBn5ZgMfXdmxGDmgelmiOzXWCKnnNk26zfQT1I+5i8aK4ior+figQjXjxZDmRrTqVK0TvjjlKwU4eaKiPBLuFO9ql4mRPupnjYPEGel+/VIiByWjEtL4RlV9OYZBpmf2HckUF9cDHD7kpOfeDyN3fWfeQvGjlcsJy+LM7QHCp4jUeCDILR/yyWfkm30Usz/D5RMeTskCdu2EoMONNctoNSsuo3QVOz/SXs7kLAT/boCgHuk2pbtxb9+8Fidyh0E6CiTXlJTI7mfc9MBfxpnSUupxsuLYF8FwJMe9p6EAE+nBWureNPunFOknCq95TIyNRRC6+UDcnKpzDjbjy+zBTDkJohX2nqdWCgUWXsllIFk/dbeSgCNndWy+ZWAtm4RgOTJlD4XitwwWI8vBAhu0ZPQndW94H20TNHEAjEt06R9goC3rvjLYDTrxgeVp/EoaC1dDSmcxsAeGvlsMxsJIovSIababGD514Zd2FS0LfD783SuoVC8Y2oxc8efzEMkexZKKIgmsNz9vh4Jt3lz3/o5ljPpI2KoFWsYXTvnxdv517qhGfSZGl0VJlNMS4uDtZSyMNGSMnn+V3UEd2jbB1hiVKQDejwScvDZeAID/StuVdtyq2gc2hvk6GVCL4u9lXYujhPVWsJ0y9+eHcLv6r3+XeSQocy4wseAeem6fFjOCs9JOT2LKs5hsYeWPTVTM5Qwxt0rU6Den6AsKtBIA9eX26fbRddU4bH0/JnNlE1iq7TnF9nxoATc9fFC6xRxvSMdiRnyjBpNKiDetdT5HYkg9IU0Lc4SVIe0fVhnwvEQIP/y1Lqkzo/vE0Mz0JQ=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 31:3Qbks2003rYA23Wj78ADHsuuDeenSmM0/s/pnHuYXFdottikXC5WqSgVwWC1DPz5IlBLt77spCJ0KGBc28Rrf/gqRPkDttCMoZEgpTtyboHqrgLiUMEKP1ZBOSeXmHFeC+gLLn7ztmkPXIdwnj2Fzzov+ev3m5Rd05yRR2LAAF9Uu4rmTdGMgs2z1Qe/GNRdZ6modACm6oGBoOjQ9TUPdrdrEaG6tDN7OYepK6rlSuCnFatxuubiQPzBj98C9K+0ITUPOXFhwu3UA5RiT9k7nTzfDnrVrsGbBOhdUOf+4xkLYWjx5fX4aLLR9fXSH7orCLffLj71Fb7qbd2opLyCGSh4zlSQmmoe7DrrE47S4Vgy43CtTpWBsrk0nplNsW2g9sdci47yPrN1a3B3Vknq6kp6hCb7CnUiRI4jlVnGkMPj/HO1dh7W3pEkpwYYJgIq2UxUPzLk8Csy6BrABTnN0P2fTNnmMZqyIh0YKLerwnk+/KomUiqpYUIG8Vg2s8JSJsHZ8wQMFCLsLeWj45LfIKbCWEWIdumvs1DXRiNNGoY9jsiuxeEEJu3X4CEqhLG2w1mK9t62bI3l+6/3DAPZ31ROFTOpIFEQvcip9SLixd9jhoLjWrTquC8wV8BmZv4xbcpCPzU5g/q1T8THog5fgftzJ4+PUMVcFtHWDs6VQq1JHVTAYC1UrIvRjL8BHI/B
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:1tAnsZJrwUBwTRjclsiMjNEUoq3bTM0bJhieyEEe3pDM3d6M/mIYLEnoK49Q8juBrEmzDIGfReuh734RqoHZzcBwB9+P5XiQZxbjpEkDK/OjW0EB6gfUa10OW3vI1eCSeop9bDUH05QDeBFo5R9U51+KV5I7nwISfVjDBacNpnaR//Mp+37IidYNl3y4CnIXrTlTU7iO0ZD99AWczzBDJcF03vfEJU355HR3nP5oGDWe5RzyLF5tS/uxe9JN37Z6Kma6xJ4C8sEUTxW1QaT2nnwVS8dB7KFHDmWfSe9/DN4bJDqCYA1Jum62SSG6lF1HV/H22Uwhr5a3YKkkRgnx03CW7GsnKM175H6aukvqIYmEyWd973Ixi2nP1ArC53PjXm/d8U9mw7x7m0wE18gVy+1WgO12YPSOaXfxDNU/B7P437oWja1qX+MOm6kW3AxpnqYQRjsJtrzpBP6GCdCqsFjhkBsOgH3X4rsmgD3QAeQ1Z/l1/i7oYHFDCM5ByvU0
X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(266576461109395)(247924648384137); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 4:hzwS8H+k2+sq3vC4i+CnsH3FBn0o6LiAIp4VK9ZA?= =?us-ascii?Q?DIozvYp1eOcnncevECRk+zPYatk7jXLM7XMoQiTFuvIrjyo5NM1hWTORwtoW?= =?us-ascii?Q?1IakxYhqNEPJkdeJzbJXzTj6oe0CRvmMt3hqEe5rpsCBZw10wd6UrjnFL1B4?= =?us-ascii?Q?+QYdAh0OHCfYR/UNjQoHW+ubynaYw4l5g9UcfARJdM+ECHloJzxgLLsTgsPU?= =?us-ascii?Q?BHY0FHC8F0Xs1Co/Bt7IARWBei+NQ4SWY0MtXPQ19u4A9CI6y9vTRDqKS22i?= =?us-ascii?Q?WzLv+yWI168t/ro2nC3Sij0ExKAK1703lnUpCIiYWncVUgSKr6Ml5ifY+zRD?= =?us-ascii?Q?nZbbIhxraJrqvxvKW03ssa1mp1TYbggczpiOySsFAfq6+iUeVKEMP0HYL6VY?= =?us-ascii?Q?ySMAFny1Hp/tw0FXHiUBk5BCxCHXzfKZLjglluScQV24dCFL6+LGz3iUvdDn?= =?us-ascii?Q?7PplSyqPaPguR/kjXovWICbB+yQkLrALUpv9JLPkz9R0HDp96oBRVbJiPdyP?= =?us-ascii?Q?herq8C/UjsrvEMRaYdA9UlzAJ9axNJxWWWDRTkCeyufE7IJuyFL8CCkekjjr?= =?us-ascii?Q?e3coguLQTQ8Pfj2V3ofOBOZNBo+OoeuX0Ba78Vhoh3l5woOUkSAQHnQY2QnC?= =?us-ascii?Q?/rWdgPNuzaI/76sB2nvBY4KoB/D+xmnzdvM9GYTuNPFlT4v1cRhI02LOuv/M?= =?us-ascii?Q?IUyblEfKPd9IZSLz/jpK9KXwy+xx3bOIPJfCJd1zSPH84NICW6sxGR0V6SHe?= =?us-ascii?Q?zHp9oA0+gu7+GSvW4lHPYvhCAulo9J9RL8FE4bk+LGnBPcg9FE2f8ZJVyyBE?= =?us-ascii?Q?dAyiw6aise54FuZiho8/Rqyu945P88jaOdh/9kPsJXetB2vR+M3jOcHkR3HU?= =?us-ascii?Q?c0npiBedDg2nG2MgTSsQAGn3vBwi2ZWmt6lu0u3jy07WeFk3p+iaHthFxbWG?= =?us-ascii?Q?Wj/uLQtFH82a5jukdYiCIwBqPw8HKPcEY6YsOr+Xj0mNM7FGmUKhZwZAde91?= =?us-ascii?Q?v2JqnFYEuWg2hjZm1WQAjUn/cSolwAH6wOwW/HL4GrMvpVOb97tW+abloDtA?= =?us-ascii?Q?dzKxitbaDUGZ4krlaxbwbz19SJ08TxSnay24BlzQbhy/NnqeEQS39r0dJM0r?= =?us-ascii?Q?u16u04ogAnNgtKj8JzoaS6HQ6zQaMRu+uMrl70Zqa5KMGbpXAnrEKaqjcIEr?= =?us-ascii?Q?lFEBpBgVdMRKqIZB0I9b03LTmGoWvzWjyeEv756SFKrzysXMMJO2FFigHL6w?= =?us-ascii?Q?fit3YdWP4BCWnLDoNOs7DJpCjU4sTESjf3+JIQsn?=
X-Forefront-PRVS: 0373D94D15
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(6049001)(39840400002)(39850400002)(39400400002)(39410400002)(39450400003)(24454002)(82746002)(6916009)(2950100002)(6666003)(5660300001)(229853002)(77096006)(6486002)(3846002)(6116002)(93886004)(42186005)(230783001)(83716003)(50466002)(5003940100001)(86362001)(1411001)(50226002)(36756003)(66066001)(81166006)(8676002)(53546010)(76176999)(189998001)(50986999)(110136004)(478600001)(6246003)(4326008)(2906002)(38730400002)(53936002)(47776003)(25786009)(7350300001)(7736002)(305945005)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:MJEFOQg9zLS0s//hPTc+J6hMneCsrfXF2WaG++d?= =?us-ascii?Q?q4kyKcPHm9I8UfUnQ46V4PAeHVvQ/55gB5frvv2HoIQHEU4QROxe7Ek8ai4D?= =?us-ascii?Q?VcrjZd2eJR9FLJyFE2taozc+u1WqY6UTwk2hOntiyFoXBVKGz62X/y4vOGqf?= =?us-ascii?Q?iwLFT6DYXg1KSUkned0YIgVRG/bwF5gt7iRrMIXEXHS0Gn1m5vkZxMbrohRf?= =?us-ascii?Q?ZTKfJHrvEeJj+ClQlcaK/wPt7WYbCNvqVQVceSEqqUMk8v7t2KvrMfj+uLRm?= =?us-ascii?Q?S9Ayffh9zYrLpfbdu1CI1XmJnzlDHMDHRF/ReAGcFWH1W1bR4GZhst6qTuRQ?= =?us-ascii?Q?1371BTerW7bpIfIeIiZ3LLhtpT5rOBfxNxldTPpPnbg0GcAvz1KQEG3k9J6L?= =?us-ascii?Q?YC/aKHYHQ5iEZJ3m/jmCFXOJHwYoDyWKduHbkuJ1BRjEtCQkdiOzBwzExKyZ?= =?us-ascii?Q?LfX5vIjnIm41hRYMl9NOf2Ee109AiWsNP0+jX305vtdIlhL76ESAr0EQrbbW?= =?us-ascii?Q?Qwa2oIVAZvood3jkDXf+g9J3VXw2RB0GKHIg2rMlD7ytbwTMqhdlAr0nyqP1?= =?us-ascii?Q?r63Z1v0TppiSAuySbAwhQCjKZZZg+eO3VFFYQ0Q5DjGtO2gcEnVB6GLVFei2?= =?us-ascii?Q?D4es2TSgPECNEJpqugkWo2T8S/Wi4Mb4L27MJGAIVRoiS04W3YMOwgFMTZ/p?= =?us-ascii?Q?FgWf5XRFOKQs63G+GL0Plm1zMRtFTfAwKOcVPE1chvbpX/OZf+jRwXfAZ+nT?= =?us-ascii?Q?4CQUHKI24O44afxVOcqPGgsXl4e5BHWJV8sNWlvw13WRKvojItXeL1XdFflg?= =?us-ascii?Q?LGau0QBgGfM1fIrlo3vSEpSh4Ywf3Yil+aFUip7qcr4O68QROC2oLoFuohLC?= =?us-ascii?Q?Z/cjEk2TaRs9kHFJHn+EpE8LWt/QM88uvQAx6w5wOQfOhAgc1BjG40L2Ha1Z?= =?us-ascii?Q?J+OAAQfe2AU1I4LSmoXjW24QSqwqCN/kPU2+3g/fzf+pgVtcnDQ4fxdWGiv5?= =?us-ascii?Q?d64yGMLNjJkRNagQ0FkyLvj8juRKMMbH3gRYkn+V7xWwEFDJe7z3hANl4sNG?= =?us-ascii?Q?GSguUVJHhEFaIQrccR0K4c9h1U0VyEl/kK1TTd9UeR1DqlyJhnH26gdoqyfR?= =?us-ascii?Q?b5Now6SN9J7eV4AHyESSocXOOToLpytrZ8F9UjKTnCZ4ZIJMkrRAYN2SDVUP?= =?us-ascii?Q?gmjfwhaW+afHeAW4t4fnQVedFSqLl9xUXVZBOahjFriFEbRJo11+racVZEtX?= =?us-ascii?Q?9pyneCJJpvphUVqZ/LsI=3D?=
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 6:Dx+fpDtTyde0+CudGiu+5BDnY/dJIQhuoCNVqsDt?= =?us-ascii?Q?q6C/nOPo+aQlrc8CZwu2uWV27xYHs6I3N5gIfa8KHa9RwxJm7SYDfBn8Z82H?= =?us-ascii?Q?g6jfFfyTznXIwBPnHyQu6iKPeVFZkZ+0nx6P+nckmXSOxGRqqH1IreOLlsFC?= =?us-ascii?Q?Et46La60meuwnlav+56/0qfH3OI+esjvly1ICNhT/07/d94oud6hsvKUuD4w?= =?us-ascii?Q?etzIUtD+XPWbmG2AHKNI0SZcq+BDZvp2v6VpFwgrSlhyuV8mIsKbuIWgmmKj?= =?us-ascii?Q?uQ1JP0l8iFYN3uCc6gNoEXsaV/PNumWzYbmGRhDdICMVZuS6M2WT/ypwsWHp?= =?us-ascii?Q?62DowLd69PDHGqfkhECjxf+hdvvY4i3R31z5w0br5SUqI+19uUFPGLw4e7Cm?= =?us-ascii?Q?alHXkslsYU1O/+qmPqw01eYrti/NckwVYAwGmykifOmUwZ4iMUNxsYRdQuzn?= =?us-ascii?Q?ZXM/AeQJjZhQ0E5h/Qxm16HQkavMwYybriOxq6rhUZpJdaGApU/NSYbtauvU?= =?us-ascii?Q?ydZi3mQKDNeTV4sPx9QmDl3VLGhbdc92RbnwKoHxbWyPVsZTa05AceDIEO+F?= =?us-ascii?Q?mV2MOVHJTetUyH5J9vH/8tDpUGAVhw2CWLoZs7C5fNkAQgnEHU1dtj5LygPp?= =?us-ascii?Q?qTyM0W1bgbXlFAw01J6CL3TuoJzoO1Vll+CygnaJL6ejM8RROnutPza+z8Nx?= =?us-ascii?Q?jeyHC/JV6dqIFOAg6I96B8UcQWIO0RB+b2sOrivr7CI0Quey/QJlN02Gg5pA?= =?us-ascii?Q?DVZ3Ac7LU6lc76oZgytHvbEPDQAM58vuq4nznsY+4JgUag/y1e/YJW6IG9Bp?= =?us-ascii?Q?gb+fKMM1S4OCTj2WJcq7ZtKerT9jf/Q/7HhkwE69Ud7Db3LC0hvvrYCMUReS?= =?us-ascii?Q?GU4SvbwjMd2XTALBbuHhW+p359CwmzUyf4098QROXcuf/chokFPNQZeIpT7i?= =?us-ascii?Q?Q7fowey+/coiMLOL81nmifIFwwTE0onqQTQ1EAIEUUpTlLmAhHvbMY+3Fl7S?= =?us-ascii?Q?f4k=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 5:daI4ABLKU0QmIbaCvQ9ezE0VsFooX3BxElRMeV3UwmAw0kyazZ4EpEBNpFlkXU4MhYjBxSeiBa1KHAe20QPLlK05yNXDW4zGj748pURYlywVfxID1IbSK8eruqjyQNOLoPw9oAp+tCmtL+vuLGKy1TukUPJFnZHrwGcyNKBpIEvZspf4XNlb6Oh8RcvPwZyazMfqyV8hcvXTBBoBaYy3CT4tjhV3g0C33HPBC+wi566SbHBqXgX9R3YO8m82MdJisn5dL94p9tU5o43wFcnsUHsf2k2J+cdwNIrNlGBmSj1H3tjcQif/es71jieCLmskzEHbev060Z+TzgVBAEejjOvoU7GTIZsdVE2/nja6DSrUFOg6Kub+6euzctCmAUuWe02cLlSANB7/Ub6o7AXybraJVjYbnNHoGo0Wp3oMpOeshCLDMyCr2o2KORbWOpoRyB1kcydZRDOTFy+EmdrHr8l7f8gTCUcZPl7zQoWbT4Yor52UI3OlbTCeLOi23pzo; 24:M/jwnGdNOyg832T7mcvDPTR9dNmSMqZO4n1oaCXnVW/X8c7n88RiaVHryGWeTWAH+NSaMlG44fs/LhnHhvjbMu9ypG/gBB+7rRMc47EOUPM=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 7:a6+di+x9VIcAXxcdPD+rjUinyoG8IFEOSE/olrdQMmNU3qFuYZapUEBLA80e5Ay1xqJk0CURcPsFEuCylnb2TOtFm66Uu/WiGAtkSeDegRFnvWcbnjvwhlHvKYTonxAz2gTUz4sKpvGN3Ww9lK6LJcoIvGeTcAaw38kv4jM8SDqdfHHWi9+pNzAWe9ZV1QyZnJa44hm9m5HDY8SogzybVC4IYjySWyP8dS7/FkL2saLjm+NQOJa7WX0L487I9PS/0L+OCyfm2AbwIfnDigsaF3NAZZI8Y3HfATksq+8DVLaj8gYyJiYhihzU7jRiD8IdWnqYQCrg23vAemDD7M75CqBVmW1mazdq9hzusYupkaKUaeUZN78xlmilnOQJlAqs54Q/BHMAI+3DbdPIk53eG9Wk1xZ479O9jbi6hVglNQib8UWbfg8xWQLiqfkmDFlyiweCYf5F1iNmPqunt8krTcd+5SOL9sy0j7XqIioZqYXaHnh7p4zl++XSX9TYGxDHYQBTXXT9E/D5pe11hiWSOMfIDR7gNUX3c52jicBFjNDBotORgWP7lCemFPUmR0uiYSTRJmtK8urVbxyr4Yqt2Wl+vpD8b9reGKHpO7fnHDMOmzTlAYamWWtHwiUot5rGXWSqcRlYnVpkd8AvFARLm4GoX/VE51gCzOEmQdOnJ5nOr6S4+fQpW+96qPbRtOFd3QuSRrbWrPpO8nilwmIilA9whQqLNYyG052xtmiZBqaPqGvN35Qr7wOhZHP4gPEFO88DGTddNP5j4SMPmUdW2Jj7So6ocKAUOv/x9cmltP8=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2017 18:38:27.1834 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:38:33 -0000

On 19 Jul 2017, at 20:29, Watson Ladd wrote:

> Now it turns out that the requirements on solutions came from
> organizational issues you never told us about.

The organizational issues have been described previously, both on the 
list and in the meetings; and the technical issues are quite separate 
from the organizational ones.  The one isn't the cause of the other.

In many cases, the organizational issues do not exist, yet the technical 
ones remain.

There is a serious technical issue here; the only reason the 
organizational issues were even mentioned was to provide context.

> I still don't see a response to how you determine unauthorized access 
> happened without being the authority on what access is authorized.

It's possible to have the relevant access policy information to hand 
without being the authority oneself.

> Apparently exporting the PMS from clients and servers  isn't possible: 
> I find that hard to believe.

It isn't practical from a performance nor a network architecture 
perspective.

> Let's standardize an extension that exports an encrypted EMS and be 
> done with this debate.

That does not meet the technical requirements.

There's some quite useful and constructive discussion of possible 
approaches taking place - I'm observing it with interest.

-----------------------------------
Roland Dobbins 


From nobody Wed Jul 19 11:41:09 2017
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 1FDDB13166B for ; Wed, 19 Jul 2017 11:41:08 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 q3JgSGKPOor4 for ; Wed, 19 Jul 2017 11:41:06 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0095.outbound.protection.outlook.com [104.47.40.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464731300CE for ; Wed, 19 Jul 2017 11:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iWaVEaSZ2yW9bawDT2d1vqa/GitdCG1anIPh18ePO1c=; b=XMakg60KU00rHslzDBxgw6JJBpDU6/yCBiZ04RRSLUtxYX7g0qF1TIzWQW0YnRuBhAMr/u+rO+1Wa1f9fRAnE47FjaP1s+VbeKS5Q0GzFMq2PwtBzrseiiSPHi+CZTjoVSRRKBy7fYFf9dnr3jmO1Ig+AnMPXRdfl8esjtAyqgQ=
Authentication-Results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by BY1PR0101MB1032.prod.exchangelabs.com (10.160.199.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:41:04 +0000
From: "Roland Dobbins" 
To: "Blumenthal, Uri - 0553 - MITLL" 
Cc: "tls@ietf.org" 
Date: Wed, 19 Jul 2017 20:40:51 +0200
Message-ID: <0D618507-AE9F-4758-B3A4-646297D4DB96@arbor.net>
In-Reply-To: <03E785A6-5C65-4DB0-AFD7-65DD7B4C94B1@ll.mit.edu>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <2FAFADF2-F791-406B-9519-EAB266AC2FCD@arbor.net> <1CA52ED8-3119-41CD-AD51-EA5DC7B77ADD@ll.mit.edu>  <03E785A6-5C65-4DB0-AFD7-65DD7B4C94B1@ll.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: VI1PR0701CA0057.eurprd07.prod.outlook.com (10.168.131.147) To BY1PR0101MB1032.prod.exchangelabs.com (10.160.199.16)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: cd61c7b7-26c5-491a-da8c-08d4ced5b67d
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY1PR0101MB1032; 
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 3:dWzstTdaLktFryrwANZSJUHpMdn6WzWib7mgozAz+zurWnrA1ZU3j451CHs4TQKjjzSpANSuPtc4TUigN891xyxHwF5vsVI3qf+ji9/ZmPvk3EV/14mk853nY5x8u1e8Qnuvg6/zWG/luoaDEuxoAJeLNCTsknEJCZG65tV7hjrYvlo1fNGEAsl9oaRWHh7yHbhmKV9dlepKS2Mkty5+s/T/MfvoxupzyLbzxXrvqQ7z21akpDlU+b4M1KmShc0xqOgFkzWFjJt+ci45AHNhAW2H2FsewLt0hfWzwOe3XXJDqlHAEv2WOzw3GbrcsflP0WqvHmY/7nwstfN1qhsP3LQi9kWFtEwUmNXS847byQGLmD2g+QXAAGZADlX55qUkDx7zj9Mwz0U3gUm7loYa7/Y44BGegZu6f8dzoKQ5UgTQzeYzuU+X/tA2GcZfO5jF8tqQx5Ndq7+62TUDdxFlFeb3370eZJswjsO6UlBs33JvbbNotzaAAwl9/YFJkLMFH/ZzrWJfzUeD2k94Y5iD2/8jIBXP0FM5TShlANO7dbAUCxpe2irJDf1BGoKI/h2Z/yhv6Ts0O13cDWlRyLgoGeHHQ8vj/+HGKLrJj1PeVOqG1foYgZyzEOScbffjUmXQHjlVryI21fqDKchrujm5PX3JHSztufDg0Zv8azFDhq+MqGA+DnPesYc6ZiHz2U6dGwyHz4IGBnX45DI5ffLq5paiR+OYn5O0ernfuU7IPWI=
X-MS-TrafficTypeDiagnostic: BY1PR0101MB1032:
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 25:zpzdC37txnJkUCIPMczedkdR5dko+ANX0JO4g46GNhyyQthCLg0hP72crkEnkEYEo8guS43P9qm8Ho1/nmg9cDUxtKlb3PxksgqCMvAmHyzsiRg60A28yCfun+RSMZqygbdCrkhCrz0DpiwP19b6c2OMraaMDCm4T/CB/D649HRT4q5m5F0Vc5T7Gb2UKcmc03UD3F6E1HtEK2iLRbr+ai3+wv3a2/p+j1laacsiwwTod49KM/rnbdc+0o41qxbBYQiTiQSx4tLeNC+6zAN/Sh9xfjzzbjGSNZ4UOZWlORZzIXQNOoP8IJ93S5tIhd20NO2JcUV5cGhR5ns1uZMpzo1n6WKgvF1EnyKdnMIv4BfmV8sw8NXmism4W6aipwXI4u0qxvUVFSO/DFvKVuZo6fZ5mns4xgbpaXVambiILAkvjzCbth4/oUEXRe/szC92ezKNqwqCffrtsLBBLhgcMy9jyrEtbiapbjFbYFFYNGob+4cAl5R1nDNf9v/PlmYSHo72Hru3IcaIZXJBQyxnWUMioK7koR8C5a1jpwtJFiAhxrdNDQdmIfi+ZlX99JDXooXi9vY2nJOaoS4exhHf5hXmkBXnDAotIsv5Eotr5nkYqUFigqAkK77ly8Qufz8UcQ4KW5dXGlbTQRqhyyh561KjQ2PqR65jnXeCLh95LE4TwGQcRnMnk7cB402YCD00P+OiORUN+EvBMyZhCpgE07I1BAfQ260ZIFiVVTIvcqzU6Np+l1xG7iwpoN71I1Z1U0GXrDluCv0nfytugWVBZ1RB88DN9FaVpJRvZZugADN3cg6/l64E7cAdCmS27XqNLG0ORt8MdmGuLUYYNPx/MP2y4xJxWqsHJP8w8+dF/JgIXvwtZ1/ZCmVv50c63GWcD28sXRtWEddQnIqn5DDlh93nYG/9opGaTCe0phdZxng=
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 31:Yg8vAEc2Og/kAk+P/aZ4ZPnkQelc70kNgWjB5zlI9cqsLmaUDIRcsqzo0c1sXCs0vBh28LlChxeQ4qIj/SPacTFLGEtWq9WrwBiSw3E9xIxYYplCI7/5z0iyO8oy3IHbETXw/S7isbCm2HvyLp1+IKyHt2rRaYA9tWaPMpMwXWJdawcLmD8iRnyvdClqg6PUPtgHSV7oFKpvKQ3nrvwYJ0F60divXzjBs1BEvVYqSDTnOuWYwrIgXqUyDP1PHr5O+t3z5FVdjNTxXZAbrqyceEPybVaL//6MTPsz7vrd19JCZ9U4XOkU/+6OZXo49jBKIpT4zrIJC3Z5p4PVOPROlDO+qnaWGeyIFuaRU09H3XwzmRrcbMc3Fq8ucSiy+835+i9DV/Me4tgBZ7vvAe1czMx1ipBvawDbaNnR7D46VeOYKwW7AGTZyWUWHC8fRmjX7q0n0P4GiZw5mucb2Ne9+uq8RWAsnq5B2zj3auQoAwCjGld3hQhVzpEJ/0LnxdsY7W+lpXrmmHJdDjm37PsMcy4cgwFigJlfyJNzqf8mzVutQwp9FHy8rf2g/1xTEfNVIj9HdJCKoI2CAsgYM/bIytJSNLHq7C323OXYOAyD4Mlv+8/cFyKy/wRxAVH7RqEmLSPlbjCfeblkjs4tItxeRaW7j75jkbQ3ZY3dag8h2CQhyQ0JrK5q5gwfwwjkJ5CWU9+HqngwjJ9doiQjv+r7Rg==
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 20:3rMm6q0d1wmQ+Z5KCej+aJg4EKoJvmPg0/HK8PpugSoQ+VZ5gX+apFCks8I8dQOVCeNIwaLjl/iqVuM8r6ghyYCiQxam/bTApegksv+Z2/Wm72sIFpWarqU7nPyd+yAvZBWOLYa5I534XjuaRWtYcTA8MmlB4m/bWL08BfeK0eHoAZ0qh9EHpc5DhKX78YJYvhWowYy1iQrLVdKBDwgTY8Nas1hHB3j4CRDwuGQJKdNlkkh1MfFDo04m1fJYJm3qS5j4w8Qk6P3LE8PD80dWpF7DNLOeFad3sueBXnhbQc/QbUaOWWZ1j9QadovFgI+DDhVJxYFIj86QZmT6a2qhHK1QgguJLPJZm05eca9++q7dkFyUwwmo1ydSyki1TQxQ9oqc8EFWF4lZuZZ0nPOGNziYK9MdTuZe6by3Q4MvX9URZp78KlnEthXoDxID1N7oERHPimW2GAzYIfe85uHHWlb9A2QiIRf3a0Be+C0yJZG4dd3tvaWeVmmyGbX3n7Zw
X-Exchange-Antispam-Report-Test: UriScan:(236129657087228);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(2017060910075)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0101MB1032; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0101MB1032; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1032; 4:Y0irO1hB1Ulrc2L5UMgf1eqxWFYKmY00p73jDNjQ?= =?us-ascii?Q?aqHlv8kMViPa1lm9qMs8ZOC6ynFqV6wjYEDkmHZK2Bs791D/Y8ecwAFxNAU4?= =?us-ascii?Q?Q4GxpMADjTr2WfX3lP0S5twG09FkaC8lelxSVqIvZnAC/ydDtgbTgpIzav9C?= =?us-ascii?Q?/zDYdK0wFr1myViZvWTZECOd6WcM3NcvYf0BPoRm47M6Gdl8nrSibbIyfwVW?= =?us-ascii?Q?dquryWoIbzhszVoOHjZyOcWf4bK85OXv7B6TbFYuopkYTlscEFX0DoNkTt4V?= =?us-ascii?Q?ziQRErelpyB2r1ip51lVKvaXEiwPGepxg1KKErGOzECoH06Lxf4s6wEEl63z?= =?us-ascii?Q?AZ0blvwe3Z/AUBMnro2M643icmJ3fgjNaFQinEnE8YD5Ly+UkXVZNLx/UiCF?= =?us-ascii?Q?mFtYYhH8TqjDlJccE8zTcICWJwXR3D6Mk9SXShWBpr7utXcSQos9+q5EZad0?= =?us-ascii?Q?hP7NGJJWoGkW+AiUikLO4chES9Yo34TVOTbb7sb1J/UrAaIU9+Bn6TPEAqDE?= =?us-ascii?Q?xz7uurZI3eCsES07QN3lVkdIiKfrx0JSIVYu2TrQx/TdjsM6zSZb9oxjKjEf?= =?us-ascii?Q?vaxdimSkFc8tMKhG6BJ6ygQp1CC5rG7nHR6odpZeXmIkDudPR2R0ovN1lSSI?= =?us-ascii?Q?akJ9YInkMeZm1o+jyd0TcmNbr8UBX49KtLWTDxwMyIgdjVwjzK+mhgh3X0GU?= =?us-ascii?Q?zdlaAz5h3hsWAhxtcLjV+mDvZRs48G7hyHISKmJvwwgMMGLtFjpvg61xBpO6?= =?us-ascii?Q?6WjzOiwSBqbaN6UOKoduE0XBVjQm95K+1gSO/RFGG6kGXqXQwDGRM8p6SVtR?= =?us-ascii?Q?BerFWRIzrHk3ZRpPBt6NvDyXnHOcZvdOk/4DwnoKyQTcwAiCCEXo5Gca75FQ?= =?us-ascii?Q?zXLCF1Q3B7QsE3sS1sSs5l14zvU5NnKGbKoi6PegrUMb00j7Moj+duUfgnqn?= =?us-ascii?Q?uwhDcnqTIdFjCIaQha+XL+S2GbcHQikQyT8CHO2CMpMfrSlWup73vwO8ABsM?= =?us-ascii?Q?WRO4v/UshF0PPB/cvgu8oy3pj0AelxwPgDlty+Jfl9FoMXjr+FpM+i2nZMHj?= =?us-ascii?Q?iuf+QyiE/aT+n6M+UGkmPDNDYkrXr3L4IrhfRfqOo8j/tPQ0hCCE2feWGAhh?= =?us-ascii?Q?n6HioIizwJODOZchrD2ZOcDBEVm66EyVCFk2rK3gAXG1l7ICMphQDlkuMBsk?= =?us-ascii?Q?sflUPr/x6ouHnwrS/h8tPsQROODPJCRl+JLD?=
X-Forefront-PRVS: 0373D94D15
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39400400002)(39450400003)(39410400002)(39850400002)(39840400002)(24454002)(83716003)(4326008)(82746002)(189998001)(42186005)(478600001)(90366009)(53936002)(77096006)(6486002)(2171002)(6246003)(110136004)(7350300001)(38730400002)(229853002)(25786009)(5003940100001)(50226002)(33656002)(76176999)(50986999)(6666003)(6916009)(230783001)(50466002)(305945005)(66066001)(2950100002)(36756003)(7736002)(81166006)(93886004)(86362001)(53546010)(6116002)(47776003)(2906002)(5660300001)(8676002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0101MB1032; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1032; 23:Aqbhy+dSCSNuFtJc2k6r9n8y9A+XFG4gQ/xJx1f?= =?us-ascii?Q?evsaVOY2dvEJTOxXpVnq/JVrEb7X+qeLPrCqcqGers4C+j7tvmtcY/4m3CJF?= =?us-ascii?Q?4jOcLxzmTxyE3NM8VNVzslwMrBRAStwHAd5t+SnfGwXhhBQlqdfPWptlx4zq?= =?us-ascii?Q?gB22QA/kCSSr5Wp95lhdmGfdjEhCdDiWKnW4990qicOX+xPYSGagm8vDrlof?= =?us-ascii?Q?b+e+cPoitx/0+Ll7+SO3t0Yzb7qhKkJYLetwk2yEyoy/VCpr11YdgYEEYl3q?= =?us-ascii?Q?RZOqnXtChOV4CxEwIRen4r5d7sQsERWtCXQ+9zq3o2DLuDMc5rys1TjeOyVt?= =?us-ascii?Q?YFdaxCpFH+rC/8XXKdPHfPbtgrK9R8Ti2fJvEt0YMJ1AR9zID8hbJxAUP/6p?= =?us-ascii?Q?aGrI3FLhZp7tLS160HtTHBxOYa4kTmBe7cE84m/4eZOSrX7nBc+o+3lVfhK4?= =?us-ascii?Q?4JiEASo9iPtNEAKSp4sdmWeLiDMcPFk3x+LAxxe9FGRXUWrwoO7PL3/vMFkY?= =?us-ascii?Q?g84IjmTwumBZ74Q/bWDHV3P9m/+chbO1t4YYDEDpURIyYHpzYkj8JtVEx+Yd?= =?us-ascii?Q?3PaJ0QggP+9QTRGZdCJCH28QZhB9Jx1VsHouSStXSsXKtlgaHaJDO1AJEXf8?= =?us-ascii?Q?LVV+g1qIvZ2ukZpBRLBjJxO0bbBOf/ozYRWpbjx9RKvQuuyue4ZwzcBfUkFo?= =?us-ascii?Q?hWIilVdltVEh9QFFSjA3zJOeZRtAYsydS/Ybhbl8SeaFfZto7xdZT0kX9o49?= =?us-ascii?Q?u4YZhvpBjJ5jz2Mns+JKNyxPfK0Fb5vJvBrM2jqL3r7vhmHobQx67MCz8tOu?= =?us-ascii?Q?u0boAZdgX/i4/JHbd9wWw5XqElSlVLiD9JFlSaH28TJeIkiYbxblgTXMtl5B?= =?us-ascii?Q?OS3Dy07fUioziacriwOKYsqCgJhGNOXTTxRnkF04FgPeTQHyjCog3cOsEA8L?= =?us-ascii?Q?VvZxJyAD6Uf/JEyXUUNcWhiUpqm9St64j8JRC6K0aqBXwrenEl6/BJzZgnSm?= =?us-ascii?Q?ZVLvR0QVOe19Z2rFc/G3Bn6/60cH4Os23erjC9yQpJ3YUvF2e52rM+MLxY3Q?= =?us-ascii?Q?a7xl3lAwVLwQC/IE2DjI/S9dJLcGsRieWbk+tbRdreliem8JAC0EAWTK5pq0?= =?us-ascii?Q?5NvRT+q6arvXJYLMshCEdWXcmwmYNHFtiAy4oREEi1VqiwUoR2tDYIpu5CYd?= =?us-ascii?Q?L6qFj1M9sVQ6gYchJvuSuDPEqGry9FAbNb1DIWwT2MjyP4oVDhsRUBHix+SN?= =?us-ascii?Q?hdlBLWdVxKJZ+93iypxW/0mS3K3iccbTH/we0hP4a?=
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1032; 6:12PJHwFSHQr40/9RWRYNjox4kK9HLaDkGUZOMZD/?= =?us-ascii?Q?YOX+9HcTCb8S7bPRUyJXkAWv6kJ8oT6t3Ci9BC6boQsC04G8o7W+wrqGxnb8?= =?us-ascii?Q?3tZ68rKJKcFd1awZiTLOFcMhsiP3v6cgwQFfGUTq5eLXB/2no5+8xgZCFRlZ?= =?us-ascii?Q?+Y6U0yDvINCOCNSmCOz6d4LrNMgHRSUWMPfVOzIXNqWASjGUlvwPo3+PkwGn?= =?us-ascii?Q?bnxown1Bt7zW3unIt3T9TSK0NF8l6uJ7BnHITFcudL5TtTfSZfYC0clOfjh5?= =?us-ascii?Q?H6KhafrRhNPRZ18R10wDHpnjdL9EvXLYh57z9wNKHMClMCS8jNuHl+9qroMZ?= =?us-ascii?Q?8Ub1h8vmAOHokROL28ChKSsTGjV0WN/7reTvguIezfRrMQqh0GLNFJ4JzsRz?= =?us-ascii?Q?UvTCDy+HWw8yzpI2R8CX6RCfbSPyH26Dd0wOW552mmOZ9l++P0vWMbeOZ7mm?= =?us-ascii?Q?8480j/jPOWixdVxHBjFw2qFXvknOb54HMiOK70wlZclj2U1HEAyWVFV/TIxJ?= =?us-ascii?Q?gyPYi9DNzwxn1aaGD8jR5DAJh8hVcqTl7Upc1BT0SIrZDplDcZx6OOyc7qLS?= =?us-ascii?Q?pTaSAvBcSKZgIAGRdlI1yJ4K7THFcj0COUXXuYTijMyPoxEV68eJY1Bi5vSf?= =?us-ascii?Q?7/Ne7JiHOO8ZXxxvM2+XRszkr072rm2jEaA1F31ZkUtr/OEJTWkxpgopb2mC?= =?us-ascii?Q?Du7JkxEnHyUTQO9NyNwxIYihUOCK+sxR13Bjx1tnhnZsSRfrakYw76mBjcvA?= =?us-ascii?Q?Sb4yfOWCr1mJpr9j2E+pnJcVvMJB0w/ZrgWtriccWb3L+UEtgONhdVAU2uSy?= =?us-ascii?Q?MgU1VyvUxmFLHvDcM65yEJhKPVDym4foxnCEO39c9hePsNzrIYs1YaUiJtdl?= =?us-ascii?Q?J3/Td87n+UvwdhOZNCFZj/IiIMo5rg57vU06B1KE2NpjV4cD8khj1Ap3DUCW?= =?us-ascii?Q?eKv9hj+GN1gAkjE4zTO+Z9x2aUaYdzLPu3XuCQFJlStd6m98EE1kJLlTe01z?= =?us-ascii?Q?nBw=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 5:Kn0WOhF2DGTuF7TAXRJxwfKnYMfClqvX030pzUYkcapDelQrNbYlLwejZfUcLBhwoO9qLKXnQ7eqlWtoQxp74LopmYSoMqllYFkhux+OCfJJd/zKQ1+bHI+nNxVDFC/nFYsia0P1JFolP80VSsQQEOC5RFc2y9lCt4HdmAO22awETLHcbX6PhYPuLPys7tnWKxoSahMcr1XqwbZC7Roqd++LXedspda/n0hWpuf5M5vP8C6XXA6umdN8E82qJh3cAHx9CHm9+KS6tmo155nL8EWGExk0bXNRIe0fPELMMg+ULl3zmxVpFvdxmD5BvrYHSyzqRxeR07DRpjvtb+lQpzQEezjnRGjPvR+yEn4bvpOkjqnDMNlfzlQlwYhxpznlpxOYFMHiA7Pd2OQ2+hO7xV5CxMOLXuad33dkeBM5hGSsmxxAlI0t6N6cVs8Ie24w0Unz0Ekprpeqh5IkyEAOjBfawRk7mZF8VMFl83BsXtLS3MXAHWyeGOrEQfgzXkwK; 24:jFiE4WqX37YwHBJWFEGxZQ0UL44BG8Sg3iT9US6FiIKXajCSnvHr8OjALtmSs6C9VKwefG/9YN7wE8/6W2V07TUhWm1lbXt8yaoTFmExbxU=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1032; 7:7jDIKuaYqUrUwqiS7Jkksnnw/LXdtGZ362voFbO3fM2FTzKXGfZ81oSXNEVI/0kqxXMxcVweUeSMBxnHr2loII4FULv1iIYr1cl9XvO8ZbBQdST9PXedGW3TI1S3GsdXHg/DSU49fmCcfLqt/BEgjgSmFAwJ+DS3Ap4MdsYptT5o773XiXNjGFGqecqnKtmA1xOjdLwCMxRHlEpuWf+6r0fJis0w+K6GOIqoAKUO9dt+kq+UBOZU5HHVLC65gLkXn6Y7s89NyK7LjDT5fLmPlUn5ZuAn2sbanQn96wkIzSCjdEzIP/RupXxYo9I/CsF+3m9cg7tblPk+UzEaT1BMtszJIMxxh9HtnCzhmzLNT0916f3xYcHbHxjrShPLOY8qIFh5dV/tqlliDP0b9Dta2QYRRpMi2AMjo7DZVIFKBCMQsOOuqLZU1GFJjR52vJ9nSoFFYMTjFvsSrL/R6tQaYDVsaCgAvHBn2nriNYsyAJXN2qJFsUnDevOQ7r+c8iEu7JQdekNx7RP77GnLmSphadL1llMFPI6K4sekKbV6hf4XVFBWQmL4sfXMbvDPn9kASV2mn2Y0DQ5Zvs0VnKBXFN9h8RfHlZ3z0PHwof7DKrIg2i/6Z5xzuHyg6JVw7fvP48+LPicqSquh2bm1DxoJ77YHVsRrjJmaettpCVXkKoVlxD7apj+DplsSz/ShLzbTQ7YO2w53x7r/wmuWLQa5+K8qvoeuBsztHkTNfKb8l4kzl/ZBIBgGcKbtv5YrULUEwwFJnlGlM6xH/AqOv+VnCh8ilCdZWwOxlhI9C8necYQ=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2017 18:41:04.3952 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0101MB1032
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 18:41:08 -0000

On 19 Jul 2017, at 20:37, Blumenthal, Uri - 0553 - MITLL wrote:

> I keep telling that this pool is drying up.

The organizations who need this the most are already working in 
all-crypto environments.  Nothing about that pool is going to change.

-----------------------------------
Roland Dobbins 


From nobody Wed Jul 19 12:26:18 2017
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 D298D131BA7 for ; Wed, 19 Jul 2017 12:26:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 x_QJdGg0gRrf for ; Wed, 19 Jul 2017 12:26:16 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 CF62C131BB4 for ; Wed, 19 Jul 2017 12:26:15 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id s70so3611446pfs.0 for ; Wed, 19 Jul 2017 12:26:15 -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=FHiFSATwM6LnND+reBDLuzkgf1TZsGPSbgP7aqgBZ0Y=; b=Ris2CWa6HRA3XfvpTTJZqSdW1NFKXKvjOQnj/VCfUem0dUzyOehYPvQPA1J9QjUC+6 JGbQIg7ZAHd3tDKWAsIbSBWtz94B4FBSzWAdc0EwcUtCoizupJdLig+Q79M2SJ7EyxGt z8VXH/tJF4tF9HaS46Bz5lfa0XVjtU3pBa1VPETXzzFbyNgtKdVx2Kphk6peDrEQQsdA SYHC+qe9alyMXJ4KbbtRMWLhyY3/5kkU1/q9wpClfJkYUDqD31vZFM6dFTjBSnOejuzX A5XdVaRIgU+ioQAzoXWTigO84tQWD/qbxaJOBdDDOdu/qhPhFHRHihSZ7LBm2OsXbYLd 6p5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FHiFSATwM6LnND+reBDLuzkgf1TZsGPSbgP7aqgBZ0Y=; b=JHedM+Q9Q1dqs78j3mkwjGjLqrQ1IdymHWsSaWZV6hA3rqfouUS8s3BPOCjCbhAeA/ C5er9rlV2ZwxOeDT28ktq+p9oOdVmoENEJd8pbyXxfZZOKzYAWdUxpasZQboREvyGyUv sBlCz1Hl101+2FJr7ZQq7ufIOPwvdgk0yB9B6pa0WDlv1tNAm8tPd9/RuekIOxHpBN4e qs3BNmd6bnQlqcN2wUTF4NFKunACyxYiGi5jB16Eyr/iQJF1C+D0em0YgNnR7C3AyCWi wuP2bPxLtjFdpNPepRAwwETtfLBBTOTxEMNrmHzilbkeA9eqWKwqHMSKETUTb1ByM9jc 1Yqg==
X-Gm-Message-State: AIVw113oazHvKGIUm8KnHjPJ7BAdb/bYZeaIZF780TtYa7NVmK4RLWcK YuOV1LD00BMixy05iuCpQfd5IIpLsZiP
X-Received: by 10.84.238.204 with SMTP id l12mr1329677pln.300.1500492375426; Wed, 19 Jul 2017 12:26:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 12:26:14 -0700 (PDT)
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 12:26:14 -0700 (PDT)
In-Reply-To: <0D618507-AE9F-4758-B3A4-646297D4DB96@arbor.net>
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <2FAFADF2-F791-406B-9519-EAB266AC2FCD@arbor.net> <1CA52ED8-3119-41CD-AD51-EA5DC7B77ADD@ll.mit.edu>  <03E785A6-5C65-4DB0-AFD7-65DD7B4C94B1@ll.mit.edu> <0D618507-AE9F-4758-B3A4-646297D4DB96@arbor.net>
From: Ted Lemon 
Date: Wed, 19 Jul 2017 21:26:14 +0200
Message-ID: 
To: Roland Dobbins 
Cc: "" , "Blumenthal, Uri - 0553 - MITLL" 
Content-Type: multipart/alternative; boundary="f403045fdf9c069ae50554b09b29"
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 19:26:18 -0000

--f403045fdf9c069ae50554b09b29
Content-Type: text/plain; charset="UTF-8"

So is it an accurate assessment that the reason you aren't using ipsec fur
this use case is that the APIs suck and your engines don't support them?

On Jul 19, 2017 8:41 PM, "Roland Dobbins"  wrote:

> On 19 Jul 2017, at 20:37, Blumenthal, Uri - 0553 - MITLL wrote:
>
> I keep telling that this pool is drying up.
>>
>
> The organizations who need this the most are already working in all-crypto
> environments.  Nothing about that pool is going to change.
>
> -----------------------------------
> Roland Dobbins 
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f403045fdf9c069ae50554b09b29
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


So is it an accurate assessment that the reason you aren&=
#39;t using ipsec fur this use case is that the APIs suck and your engines =
don't support them?

On Jul 19, 2017 8:41 PM, "Roland Dobbins" <rdobbins@arbor.net> wrote:
On 19 Jul 2017, at 20:37, Blum=
enthal, Uri - 0553 - MITLL wrote:





I keep telling that this pool is drying up.





The organizations who need this the most are already working in all-crypto =
environments.=C2=A0 Nothing about that pool is going to change.



-----------------------------------

Roland Dobbins <=
rdobbins@arbor.net>



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--f403045fdf9c069ae50554b09b29--


From nobody Wed Jul 19 12:29:15 2017
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 0BDA1131BB5 for ; Wed, 19 Jul 2017 12:29:14 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uexmLiuzaBmz for ; Wed, 19 Jul 2017 12:29:12 -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 48D8D129AF6 for ; Wed, 19 Jul 2017 12:29:12 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id w191so7987407wmw.1 for ; Wed, 19 Jul 2017 12:29:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cQS5aqEiWI85ErcMFBYku3/bh9nEPuCjz5WE5lfrHPw=; b=q7Le2yJvRMk0u6v5HXLcuAA19KQWkIdvxJiaIdSGXMJ1Xjm5w/KwmofE1or4k/DuwO sw/Lxdz9T4ONdB6ServqlqWKKrYmRaDxXh8IqxF8xvFVk6pI9sgjRw1vW2SvP78uvuLf 8cm+saFbR95C2kYgSVBHuE8/Nbdplj9g9x+sdXBne8yoaANNRPaIF3yzvui675oYsB7/ rGbariFpwYyfLzXUBLqDXgb3cFwtDlDA0D1yopCRImZmj+bu+sVuGtEg6XBmQU6dsZqb GFpcbFzrG0//H1dXR/5/TTaV30xG8qLksDsQnHis3LlHTYWnXcRIT4bT4UipXipuWBGo z6Jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cQS5aqEiWI85ErcMFBYku3/bh9nEPuCjz5WE5lfrHPw=; b=JnXPK6awFgSHfIe7L8NAbguzzwQuchY+fN5+CVdOiRUSKBBrt0dfOvBLu7H34XiYkD L2b4jz2w3F1YU9stm4jpItBIZT9BfBe+cKJeCg0nnBxq+9TVZlb2rfZicR5AVTNkJG3J yz6bfpXZuV9Cj+XebIPHtlJkoiKrbnMs/Wh/86VzNl1MQ9Isg/e1RskL0nIo0Tmh2dJd QrqdEdgDvotgMrmhkA3M2tNPV1xwrVHkR69qyuJdsWGk31h1yMRFxJ8fBXQe3B+1DE3O P0/Sd5g5JwY41R9Ki/T2UpbmQNOCwgyPtIHhhzi5AMI4DGk/Ji/Nmowe0IlmPPI2atsy 2szw==
X-Gm-Message-State: AIVw110Cjlhlg2nGiCh1KRsVFmYtOkbeqcF7YzJqzQUZtQ8WdeFbnIjG D/8tjfP1Xn6vdlfu+fLaz1Yho21o8LCQ3CA=
X-Received: by 10.28.23.1 with SMTP id 1mr748163wmx.106.1500492550591; Wed, 19 Jul 2017 12:29:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.24.198 with HTTP; Wed, 19 Jul 2017 12:29:09 -0700 (PDT)
In-Reply-To: 
References: 
From: Ryan Hamilton 
Date: Wed, 19 Jul 2017 12:29:09 -0700
Message-ID: 
To: Russ Housley 
Cc: IETF TLS 
Content-Type: multipart/alternative; boundary="001a1146855c77e5240554b0a55b"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 19:29:14 -0000

--001a1146855c77e5240554b0a55b
Content-Type: text/plain; charset="UTF-8"

Can you provide more context for those of us not in the room? What was the
hum in reference to?

On Wed, Jul 19, 2017 at 10:10 AM, Russ Housley  wrote:

> The hum told us that the room was roughly evenly split.  In hind sight, I
> wish the chairs had asked a second question.  If the split in the room was
> different for the second question, then I think we might have learned a bit
> more about what people are thinking.
>
> If a specification were available that used an extension that involved
> both the client and the server, would the working group adopt it, work on
> it, and publish it as an RFC?
>
> I was listening very carefully to the comments made by people in line.
> Clearly some people would hum for "no" to the above question, but it
> sounded like many felt that this would be a significant difference.  It
> would ensure that both server and client explicitly opt-in, and any party
> observing the handshake could see the extension was included or not.
>
> Russ
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a1146855c77e5240554b0a55b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Can you provide more context for those of us not in the ro=
om? What was the hum in reference to?

On Wed, Jul 19, 2017 at 10:10 AM, Russ Hous=
ley <housley@vigilsec.com> wrote:
The hum told us that the room was roughly evenly split.=C2=A0 In=
 hind sight, I wish the chairs had asked a second question.=C2=A0 If the sp=
lit in the room was different for the second question, then I think we migh=
t have learned a bit more about what people are thinking.



If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?



I was listening very carefully to the comments made by people in line.=C2=
=A0 Clearly some people would hum for "no" to the above question,=
 but it sounded like many felt that this would be a significant difference.=
=C2=A0 It would ensure that both server and client explicitly opt-in, and a=
ny party observing the handshake could see the extension was included or no=
t.



Russ

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a1146855c77e5240554b0a55b--


From nobody Wed Jul 19 12:30:00 2017
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 63018131BB5 for ; Wed, 19 Jul 2017 12:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 woeuEjEunZ2u for ; Wed, 19 Jul 2017 12:29:47 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 C57BA131BBC for ; Wed, 19 Jul 2017 12:29:47 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id s70so3638995pfs.0 for ; Wed, 19 Jul 2017 12:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5cetxLkc2kMzHQ5/aKUf/VDSKblXUEuJ0ljU8jDPVrs=; b=vB85HRcOUpSDGLmcyN6GaVwso+x1eo19wDnbKPCDfYlcq/spSYLtGrgvW035SFttmS 8UTNqz3FDxucMLA86oG4SVzSp+McMnGjkO7KprgYgw5k8/hQBJAtJOQ9zv0IKfdrWYYC PavrBypWOVuj3tLqGs+bqkW1/lpgnwAZiWWY9xeOIehE5nqcYFM9C89rdl4hr8PkMiTe xDgFEjdXaP0ha4utGsQTKbv8nvBVfpvckMF9fuQ8S2WJDH1OLR0Fmmucy4VRPF37PMoe UBZEuqjnE3NezThE0xyPBwjo0Gbw2suZKDKYyZpC2m+VPpR51rHvDC0sqF8cIvJnVfrc C5SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5cetxLkc2kMzHQ5/aKUf/VDSKblXUEuJ0ljU8jDPVrs=; b=LkDzaYJH3T/HEcj4EVGfxi6rA3trCQatTqCG+jBce/nSUxz+fVA6XmakB2/lcTeJGZ U3D3kWVuaFjQDTOpzrIJg3adG7DeknUPrBwfgyLOqLvhe6lLMbuig+TdxxM+V4bDEgqf QJmGlNtNkH2RumOHpEQrcCihLN1K/OJRvtfyob+US8Wv75klyIrE/+RHPCWx7a/kz1jP 9Lnr5CVYl0vGPBBbtMOEuiI/mjAuMZGyGNvUlsYuGDc6oUB5B97TS4EDC/kVRXT1N55H su19vN/CGRfEvxoA6YS6aLUbSCFBs2Ktz/uU5A43ri5tszzP9TKFqzB23F1XfmykFF94 DzvA==
X-Gm-Message-State: AIVw1130rP6zHeNLq6+CNFyO7+94jfMq9HC9si11Fhe9MKIYLyRwEQSV cC3a59BPM1H/8X5KmDEUbEkxOIIB5g==
X-Received: by 10.99.95.86 with SMTP id t83mr1116831pgb.351.1500492587425; Wed, 19 Jul 2017 12:29:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Wed, 19 Jul 2017 12:29:46 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Wed, 19 Jul 2017 12:29:46 -0700 (PDT)
In-Reply-To: 
References:    <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com>  <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>   <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net>        <9A49F3C7-DEC7-4FEA-9017-B48DAC1D1446@ll.mit.edu> <2FAFADF2-F791-406B-9519-EAB266AC2FCD@arbor.net> <1CA52ED8-3119-41CD-AD51-EA5DC7B77ADD@ll.mit.edu>  <03E785A6-5C65-4DB0-AFD7-65DD7B4C94B1@ll.mit.edu> <0D618507-AE9F-4758-B3A4-646297D4DB96@arbor.net> 
From: Watson Ladd 
Date: Wed, 19 Jul 2017 12:29:46 -0700
Message-ID: 
To: "Dobbins, Roland" 
Cc: "Blumenthal, Uri - 0558 - MITLL" , tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c09b42ca966100554b0a793"
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 19:29:52 -0000

--94eb2c09b42ca966100554b0a793
Content-Type: text/plain; charset="UTF-8"

On Jul 19, 2017 11:38 AM, "Roland Dobbins"  wrote:

On 19 Jul 2017, at 20:29, Watson Ladd wrote:

Now it turns out that the requirements on solutions came from
> organizational issues you never told us about.
>

The organizational issues have been described previously, both on the list
and in the meetings; and the technical issues are quite separate from the
organizational ones.  The one isn't the cause of the other.

In many cases, the organizational issues do not exist, yet the technical
ones remain.


What are the technical requirements?


There is a serious technical issue here; the only reason the organizational
issues were even mentioned was to provide context.


I still don't see a response to how you determine unauthorized access
> happened without being the authority on what access is authorized.
>

It's possible to have the relevant access policy information to hand
without being the authority oneself.


Why can't the enforcing mechanism log its enforcement?



Apparently exporting the PMS from clients and servers  isn't possible: I
> find that hard to believe.
>

It isn't practical from a performance nor a network architecture
perspective.


We're talking one extra encryption+transmission. How is this not possible?



Let's standardize an extension that exports an encrypted EMS and be done
> with this debate.
>

That does not meet the technical requirements.


Why not? It enables interception if both ends opt in with the encrypted
packets. (I see I made a typo: I meant PMS) what does the green draft do
this does not?


There's some quite useful and constructive discussion of possible
approaches taking place - I'm observing it with interest.

-----------------------------------
Roland Dobbins 

--94eb2c09b42ca966100554b0a793
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Jul 19, 2017 11:38 AM, "Roland Dobbins" <rdobbins@arbor.net> wrote:
On 19 Jul=
 2017, at 20:29, Watson Ladd wrote:





Now it turns out that the requirements on solutions came from

organizational issues you never told us about.





The organizational issues have been described previously, both on the list =
and in the meetings; and the technical issues are quite separate from the o=
rganizational ones.=C2=A0 The one isn't the cause of the other.



In many cases, the organizational issues do not exist, yet the technical on=
es remain.

What are the technical requirements?




There is a serious technical issue here; the only reason the organizational=
 issues were even mentioned was to provide context.






I still don't see a response to how you determine unauthorized access h=
appened without being the authority on what access is authorized.





It's possible to have the relevant access policy information to hand wi=
thout being the authority oneself.

Why can't the enforcing mechanism=
 log its enforcement?







Apparently exporting the PMS from clients and servers=C2=A0 isn't possi=
ble: I find that hard to believe.





It isn't practical from a performance nor a network architecture perspe=
ctive.

We're talking one extra encryption+transmission. How is this =
not possible?






Let's standardize an extension that exports an encrypted EMS and be don=
e with this debate.





That does not meet the technical requirements.
=


Why not? It enables int=
erception if both ends opt in with the encrypted packets. (I see I made a t=
ypo: I meant PMS) what does the green draft do this does not?



There's some quite useful and constructive discussion of possible appro=
aches taking place - I'm observing it with interest.



-----------------------------------

Roland Dobbins <=
rdobbins@arbor.net>





--94eb2c09b42ca966100554b0a793--


From nobody Wed Jul 19 13:25:21 2017
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 7E55A12420B for ; Wed, 19 Jul 2017 13:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 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_PASS=-0.001, URIBL_BLOCKED=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 Dal7d448gqgx for ; Wed, 19 Jul 2017 13:25:17 -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 A8F1F12EC3B for ; Wed, 19 Jul 2017 13:25:17 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (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 3xCT6g72n9z1J8c; Wed, 19 Jul 2017 22:25:15 +0200 (CEST)
X-purgate-ID: 152705::1500495916-00000810-4B15C08D/0/0
X-purgate-size: 3455
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 mail07.wdf.sap.corp (Postfix) with ESMTP id 3xCT6g4PP6zGp4w; Wed, 19 Jul 2017 22:25:15 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 919D11A6CB; Wed, 19 Jul 2017 22:25:15 +0200 (CEST)
In-Reply-To: 
To: Ted Lemon 
Date: Wed, 19 Jul 2017 22:25:15 +0200 (CEST)
CC: Stephen Farrell , "" 
Reply-To: mrex@sap.com
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: <20170719202515.919D11A6CB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 20:25:20 -0000

I just watched the presentation on static DH / TLS decryption in Enterprise
settings of todays TLS session

  https://youtu.be/fv1AIgRdKkY?t=4473

and I'm seriously appalled by the amount of cluelessness in the
Networking & IT Departments on the one hand, and by what seems like
woefully inadequate apps on the other hand.

I've been doing middleware development and customer support of
SSL/TLS-protected communication for our company's (legacy) app
as well as maintenance & customer support for the TLS stack we're
shipping with it for the past 17 years, and I can't stop shaking
my head about the perceived problems, that *NEVER*EVER* occurred
to me, nor our IT & Hosting and neither any of our customers using our app
(and I would definitely know about it).

Although we do ship our own TLS implementation, we don't have any APIs
to export cryptographic keys, simply because it's completely unnecessary.


With extremely few exceptions, an API-level trace at the endpoints
is totally sufficient for finding app-level problems, such as
unexpected "expensive" requests.  App-level traces on *EITHER* side
should provide *ALL* information that is necessary to determine _which_
particular requests are taking longer than expected.  If your Apps do
not provide meaningful traces, then you have an *APPS* problem, and
should be fixing or replacing apps, rather than mess around with TLS.


There were a few issues with F5 loadbalancers (that were just forwarding
traffic, _not_ acting as reverse proxy) related to a borked F5 option called
"FastL4forward", which occasionally caused the F5 box to truncate TCP streams
(the box received&ACKed 5 MByte of TCP data towards the TLS Server, but
forwarded only 74 KBytes to the client before closing the connection with
a TCP FIN towards the TLS client.

And once I saw another strange TCP-level data corruption caused by some Riverbed WAN accellerator.


I remember exactly _two_ occasions during that 17 years when I produced
a special instrumented version of our library for the server endpoint,
which dumped stuff into a local trace file, but I never ever thought
about exporting crypto keys (because it wouldn't help, and those
weren't _my_ keys (but those of a customer):

   (1) it dumped the decrypted RSA block from the ClientKeyExchange
       handshake message when encountering a PKCS#1 BT02 padding
       encoding failure

   (2) it dumped the final decrypted block of a TLS record for
       when the CBC-padding-verification failed the check.

(1) was caused by a bug in the long integer arithmetic of an F5 load balancer
    which ocassionally produced bogus (un-decryptable) PreMasterSecrets

(2) was caused by a design flaw in JavaSE 1.6 by Java's SSL when it was used with GenericBlockCipher over native-IO interfaces.


I firmly believe that if you have a desire to decrypt TLS-protected
traffic to debug APPS issues, then your APPS must be crap, and seriously
lack capabilities to trace/analyze endpoint behaviour at the app level.


With respect to "monitoring" SSL/TLS-protected traffic in the
enterprise environment:

At least here in Germany, we're in the lucky position that wiretapping
network traffic has been made a criminal offense in 2004.  If IT/Networking
folks in the enterprise settings don't want to spend up to 4 years behind
bars, they don't even try to decrypt SSL/TLS-protected traffic.

 
-Martin


From nobody Wed Jul 19 13:32:09 2017
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 DE5161316C2 for ; Wed, 19 Jul 2017 13:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_PDS_TO_EQ_FROM_NAME=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 RDXulQL7dUbG for ; Wed, 19 Jul 2017 13:32:06 -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 8457A131671 for ; Wed, 19 Jul 2017 13:32:06 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (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 3xCTGX3WNVz25wS; Wed, 19 Jul 2017 22:32:04 +0200 (CEST)
X-purgate-ID: 152705::1500496324-00000861-E18752A8/0/0
X-purgate-size: 1059
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 mail07.wdf.sap.corp (Postfix) with ESMTP id 3xCTGX2qJ1zGp1n; Wed, 19 Jul 2017 22:32:04 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5B2451A6CB; Wed, 19 Jul 2017 22:32:04 +0200 (CEST)
In-Reply-To: <20170719202515.919D11A6CB@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Wed, 19 Jul 2017 22:32:04 +0200 (CEST)
CC: Ted Lemon , "" 
Reply-To: mrex@sap.com
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: <20170719203204.5B2451A6CB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 20:32:08 -0000

Martin Rex wrote:
> 
> There were a few issues with F5 loadbalancers (that were just forwarding
> traffic, _not_ acting as reverse proxy) related to a borked F5 option called
> "FastL4forward", which occasionally caused the F5 box to truncate TCP streams
> (the box received&ACKed 5 MByte of TCP data towards the TLS Server, but
> forwarded only 74 KBytes to the client before closing the connection with
> a TCP FIN towards the TLS client.
> 
> And once I saw another strange TCP-level data corruption caused by
> some Riverbed WAN accellerator.

I forgot to mention how I analyzed the breakage created by the middleboxes:

network capture (tcpdump) with a IP-address capture filter for a dedicated
client machine was *perfectly* sufficient to determine the TCP-level breakage.

For the F5 cockup, we used a concurrent tcpdump capture on the box in both
directions, again with IP-address capture filter, in order to prove to the
vendor that his box is corrupting/truncating the TCP stream between
TLS client and TLS server.


-Martin


From nobody Wed Jul 19 14:25:28 2017
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 2219512EC19 for ; Wed, 19 Jul 2017 14:25:26 -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 (2048-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 Q9lqmyp7Ju9v for ; Wed, 19 Jul 2017 14:25:25 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 F1025129B53 for ; Wed, 19 Jul 2017 14:25:24 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6JLMDfu023997; Wed, 19 Jul 2017 22:25:20 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=RkCfilHJFlI/KFW0t4rbXEr/DxjMeM3MK86bwBot4+c=; b=ntsOVYP6kM97TQ08AbMnjBFoUet2vRD7yq2Rcmx3QS0Btovo8qIc994Blm12em3O92kl m9lAdv+bXimR0r3mlp88NXWF2r4y9nXjq4SUplhK9XlPY6VsuTwEQT2JEoQyyWJTLPoy We8ZRcY/dD5wnJ/Ig/inm/JmNQdhN6hMnh2pLnNOOMcCXW/nGs6vOAXd/cunjFxdSyYb 3ZOs0BAYI3njWWahKw0oTZ394VG4M/6KdyhtCrdoHXKNAxB5JiL0zH3V7R7suaLg038u ai2AGp+QbMEld66zsitaeDM8DIcuV+8XImI/dHDZmuKIuLVsTiTKtzIOQVxbus28mLaG rQ== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bt1abu8er-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 22:25:20 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6JLLA8M032452; Wed, 19 Jul 2017 17:25:19 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecudtca-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 17:25:19 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 17:25:18 -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.1263.000; Wed, 19 Jul 2017 17:25:18 -0400
From: "Salz, Rich" 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Ted Lemon 
CC: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJBchz4bEuxe60uC+rbloxSHrKJbn/OAgAACkwCAAAm5AIAAAWoAgAAB0ID///oQUA==
Date: Wed, 19 Jul 2017 21:25:17 +0000
Message-ID: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.152.189]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707190333
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707190333
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 21:25:26 -0000

PiBJIGZpbmQgdGhpcyBhIHZlcnkgYml6YXJyZSBvdXRjb21lIHRoYXQgd29ya3MgYWdhaW5zdCBv
dXIgY29sbGVjdGl2ZSBnb2Fscy4gSWYgdGhlcmUgaXMgbm8gbWVjaGFuaXNtIGF0IGFsbCwgdGhl
biBpdCBpcyBxdWl0ZSBsaWtlbHkgdGhhdCBvcmdhbml6YXRpb25zIHdpbGwgdXNlIHN0YXRpYy1E
SCBvciBzdGF5IG9uIFRMUzEuMi4gVGhvc2UgYXJlIGJhZCBvcHRpb25zLCBpbiBteSBvcGluaW9u
LCBiZWNhdXNlIHRoZXJlJ3Mgbm8gc2lnbmFsaW5nIG9yIG9wdC1pbiB0byB0aGUgY2xpZW50LiBX
ZSBjYW4gZG8gbXVjaCBiZXR0ZXIgdGhhbiB0aGF0LsKgDQoNCklmIGFuIG9yZ2FuaXphdGlvbiBu
ZWVkcyB0byBkZWNyeXB0IHRoZSBuZXR3b3JrIHRyYWZmaWMsIHRoZW4gaXQgc2hvdWxkIHByb2Jh
Ymx5IGNvbnRpbnVlIHRvIHVzZSBhIHNjaGVtZSB0aGF0IGhhcyBhIHN0YXRpYyBrZXkgc28gdGhh
dCBpdCBjYW4gZG8gdGhhdC4NCg0KQXQgbGVhc3QgZm9yIHRoZSBuZXh0IHRocmVlIHllYXJzLg0K
DQoNCg==


From nobody Wed Jul 19 14:34:17 2017
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 A509C126E64 for ; Wed, 19 Jul 2017 14:34: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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm3mPykuKXzp for ; Wed, 19 Jul 2017 14:34:13 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (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 108CC129AF3 for ; Wed, 19 Jul 2017 14:34:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500500051; l=2265; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=p4JgP9h11oQ0KJKq/cQl05WdSc/lad6LedYUpduSFS0=; b=EsofS0COE0T6nlQmJ6yM9sfDEBWokQBnASIqUaEa+tSPN734DhoYcSatl4rJ5iTXx9 KIfZsRc26GUQgcxpreI5Y8JxJSBocrqQFoYWpUs9ypMXnQ0wuTkmhftB7ctkfffUagyr xePSmlyFYsDRu3DTLOwTBOwvUCFoK67MBMCVA=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWWlmkPDB+7nwYIvSX1sH
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.91] (p508A6EE0.dip0.t-ipconnect.de [80.138.110.224]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id v047b6t6JLYB5zC (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Wed, 19 Jul 2017 23:34:11 +0200 (CEST)
To: tls@ietf.org
References: <20170719203204.5B2451A6CB@ld9781.wdf.sap.corp>
From: Roland Zink 
Message-ID: 
Date: Wed, 19 Jul 2017 23:34:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170719203204.5B2451A6CB@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 21:34:16 -0000

Am 19.07.2017 um 22:32 schrieb Martin Rex:
> Martin Rex wrote:
>> There were a few issues with F5 loadbalancers (that were just forwarding
>> traffic, _not_ acting as reverse proxy) related to a borked F5 option called
>> "FastL4forward", which occasionally caused the F5 box to truncate TCP streams
>> (the box received&ACKed 5 MByte of TCP data towards the TLS Server, but
>> forwarded only 74 KBytes to the client before closing the connection with
>> a TCP FIN towards the TLS client.
>>
>> And once I saw another strange TCP-level data corruption caused by
>> some Riverbed WAN accellerator.
> I forgot to mention how I analyzed the breakage created by the middleboxes:
>
> network capture (tcpdump) with a IP-address capture filter for a dedicated
> client machine was *perfectly* sufficient to determine the TCP-level breakage.
>
> For the F5 cockup, we used a concurrent tcpdump capture on the box in both
> directions, again with IP-address capture filter, in order to prove to the
> vendor that his box is corrupting/truncating the TCP stream between
> TLS client and TLS server.
>
In many companies the app is from one vendor and the loadbalancer from 
another one. Both vendors are telling you the other is causing the 
problem. Then you will have some fun to turn on undocumented app level 
tracing. However the proposed solution will have the same problem when 
the app doesn't support it.

One question to the company proponents, would you allow the end / home 
users the same capabilities? E.g. some equipment at home/cellular  is 
phoning back to the vendor. The owner of the equipment can't see what is 
transferred and need to trust the vendor, so should end users get the 
keys? It can be a similar problem, e.g. the app doesn't work as expected 
and the vendor says this must be the home / cellular network. How to 
proof that it is the app fault and not the home network?

Regards,
Roland

P.S. Be careful as I think preparing for wiretapping and having tools 
for it may already bring you behind bars in Germany, although I think 
this law wasn't used so far.


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


From nobody Wed Jul 19 15:50:44 2017
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 ED431126C2F for ; Wed, 19 Jul 2017 15:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZR-ydATlBxa for ; Wed, 19 Jul 2017 15:50:41 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2BA12EC48 for ; Wed, 19 Jul 2017 15:50:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 66D82BE39; Wed, 19 Jul 2017 23:50:38 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lghq2XstTEjq; Wed, 19 Jul 2017 23:50:37 +0100 (IST)
Received: from [31.133.148.54] (dhcp-9436.meeting.ietf.org [31.133.148.54]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2B3E3BE24; Wed, 19 Jul 2017 23:50:36 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500504637; bh=+yZUisY7osKnrHCMqpHuBaO7aJ9fhl6ZI9WD1gcRan0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lzY/txP/oDfQbMiWm5kyyqcKoWtiy9gvwW+hoJaw2BM4UdhGcDsY8NtLZy3uNtSoN 5jRqNXrgSTKxMGLMk7uppxZ39jYou92UVEFttAe6kF79oscMD8JVuixre9EljXYrO/ /qJ1FaR9/KT3YnI1D1TnJTlMghRgEZD0W8w6AyFc=
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Ted Lemon 
Cc: "" 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>  
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Wed, 19 Jul 2017 23:50:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R37Tp5Q7JMEMTDIcNXwQSM5xukRr7afdB"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 22:50:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--R37Tp5Q7JMEMTDIcNXwQSM5xukRr7afdB
Content-Type: multipart/mixed; boundary="2d77FQOlaMgtr2FrjcimHoEefh9Op4nmN";
 protected-headers="v1"
From: Stephen Farrell 
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= ,
 Ted Lemon 
Cc: "" 
Message-ID: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
 <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie>
 <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com>
 <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>
 
 
In-Reply-To: 

--2d77FQOlaMgtr2FrjcimHoEefh9Op4nmN
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 19/07/17 18:45, Colm MacC=C3=A1rthaigh wrote:
> For example, browser's
> incognito modes may refuse to support such sessions, if they knew what =
was
> going on.

That is a perfect example of the hideous dangers of all of this.
The implication in the above is that browsers would/should turn
on wiretapping support in the normal case.

S.


--2d77FQOlaMgtr2FrjcimHoEefh9Op4nmN--

--R37Tp5Q7JMEMTDIcNXwQSM5xukRr7afdB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZb+I4AAoJEC88hzaAX42iWWIH/iXTo7MrKcDRCVD34qLPoV2K
4gOEvHuQnvDbEK3LDrWnpmwB7NqV9pTb3HhG+74TLY0tVQKYOsXQIOKTLqATI1cj
Wc4Z1nUzIoHMyeVIHUhiSPxmD10IjlQTyPafNkVXWP2JMPjsx5huW5SsMgt1mFD+
38HiPk2yxy/3su4XJGx0u4gmO/X3GmfxsGuqkIw75+KXHF9n1IUA1k/gPT/FXfrl
SjqG+RdENMlfZfiaIlj3wLqa8vrvT9O/DzgYlai2u8pTHNOdZEaqVzYh5RI2XeXL
GrLHM0cbF0iUNWxOGSoynZLV7Y6IG0erGAEAXoN52qKfJmpZf7B4CRWVW39oGLk=
=u61t
-----END PGP SIGNATURE-----

--R37Tp5Q7JMEMTDIcNXwQSM5xukRr7afdB--


From nobody Wed Jul 19 15:58:11 2017
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 46EDD124D37 for ; Wed, 19 Jul 2017 15:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR8qm4PhesUh for ; Wed, 19 Jul 2017 15:58:06 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C281200ED for ; Wed, 19 Jul 2017 15:58:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DBFE0BE39; Wed, 19 Jul 2017 23:58:04 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FsZ74U2Ygi2; Wed, 19 Jul 2017 23:58:03 +0100 (IST)
Received: from [172.28.172.2] (unknown [185.51.72.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16964BE24; Wed, 19 Jul 2017 23:58:01 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500505083; bh=P84X4GMwnML5TaoqQurccKTRbiE/EsoG+uRcHGQommk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dYEEnCR5zmlWPki+P1Fgpm6aq9eK//goEi9MjNapgm2K2RCWgXv2BtVPdwjmCmgUd qP6vp0rf6pDWuP03+EnSKSTfL+CKlqyWTOgNhR3QNcQsCPK4kZa5O+jevJ9h2uLKQb uRc0vVYQu+MOazcPIQQmxKbQNcdzMIjkgbSv77MY=
To: mrex@sap.com, Ted Lemon 
Cc: "" 
References: <20170719202515.919D11A6CB@ld9781.wdf.sap.corp>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Wed, 19 Jul 2017 23:57:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170719202515.919D11A6CB@ld9781.wdf.sap.corp>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gF2ijWeHb4BM8qJR3AvP9D6XxlfwEuEnP"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 22:58:09 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gF2ijWeHb4BM8qJR3AvP9D6XxlfwEuEnP
Content-Type: multipart/mixed; boundary="l0lhvQKFR7bqpxjvKmjS2HtB0KfUP01lv";
 protected-headers="v1"
From: Stephen Farrell 
To: mrex@sap.com, Ted Lemon 
Cc: "" 
Message-ID: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
References: <20170719202515.919D11A6CB@ld9781.wdf.sap.corp>
In-Reply-To: <20170719202515.919D11A6CB@ld9781.wdf.sap.corp>

--l0lhvQKFR7bqpxjvKmjS2HtB0KfUP01lv
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Just to note that Martin's mail contains specific examples
and detailed argument. That should be the lowest bar that
needs to be met in this discussion, not the arm-waving about
"TLS as a DoS attack" or "what about grandma" nonsense that
we heard today. The contrast between such non-argument and
the care that has been taken, and continues to be taken, in
the development of TLS1.3 is stark.

S.

On 19/07/17 21:25, Martin Rex wrote:
> I just watched the presentation on static DH / TLS decryption in Enterp=
rise
> settings of todays TLS session
>=20
>   https://youtu.be/fv1AIgRdKkY?t=3D4473
>=20
> and I'm seriously appalled by the amount of cluelessness in the
> Networking & IT Departments on the one hand, and by what seems like
> woefully inadequate apps on the other hand.
>=20
> I've been doing middleware development and customer support of
> SSL/TLS-protected communication for our company's (legacy) app
> as well as maintenance & customer support for the TLS stack we're
> shipping with it for the past 17 years, and I can't stop shaking
> my head about the perceived problems, that *NEVER*EVER* occurred
> to me, nor our IT & Hosting and neither any of our customers using our =
app
> (and I would definitely know about it).
>=20
> Although we do ship our own TLS implementation, we don't have any APIs
> to export cryptographic keys, simply because it's completely unnecessar=
y.
>=20
>=20
> With extremely few exceptions, an API-level trace at the endpoints
> is totally sufficient for finding app-level problems, such as
> unexpected "expensive" requests.  App-level traces on *EITHER* side
> should provide *ALL* information that is necessary to determine _which_=

> particular requests are taking longer than expected.  If your Apps do
> not provide meaningful traces, then you have an *APPS* problem, and
> should be fixing or replacing apps, rather than mess around with TLS.
>=20
>=20
> There were a few issues with F5 loadbalancers (that were just forwardin=
g
> traffic, _not_ acting as reverse proxy) related to a borked F5 option c=
alled
> "FastL4forward", which occasionally caused the F5 box to truncate TCP s=
treams
> (the box received&ACKed 5 MByte of TCP data towards the TLS Server, but=

> forwarded only 74 KBytes to the client before closing the connection wi=
th
> a TCP FIN towards the TLS client.
>=20
> And once I saw another strange TCP-level data corruption caused by some=
 Riverbed WAN accellerator.
>=20
>=20
> I remember exactly _two_ occasions during that 17 years when I produced=

> a special instrumented version of our library for the server endpoint,
> which dumped stuff into a local trace file, but I never ever thought
> about exporting crypto keys (because it wouldn't help, and those
> weren't _my_ keys (but those of a customer):
>=20
>    (1) it dumped the decrypted RSA block from the ClientKeyExchange
>        handshake message when encountering a PKCS#1 BT02 padding
>        encoding failure
>=20
>    (2) it dumped the final decrypted block of a TLS record for
>        when the CBC-padding-verification failed the check.
>=20
> (1) was caused by a bug in the long integer arithmetic of an F5 load ba=
lancer
>     which ocassionally produced bogus (un-decryptable) PreMasterSecrets=

>=20
> (2) was caused by a design flaw in JavaSE 1.6 by Java's SSL when it was=
 used with GenericBlockCipher over native-IO interfaces.
>=20
>=20
> I firmly believe that if you have a desire to decrypt TLS-protected
> traffic to debug APPS issues, then your APPS must be crap, and seriousl=
y
> lack capabilities to trace/analyze endpoint behaviour at the app level.=

>=20
>=20
> With respect to "monitoring" SSL/TLS-protected traffic in the
> enterprise environment:
>=20
> At least here in Germany, we're in the lucky position that wiretapping
> network traffic has been made a criminal offense in 2004.  If IT/Networ=
king
> folks in the enterprise settings don't want to spend up to 4 years behi=
nd
> bars, they don't even try to decrypt SSL/TLS-protected traffic.
>=20
> =20
> -Martin
>=20


--l0lhvQKFR7bqpxjvKmjS2HtB0KfUP01lv--

--gF2ijWeHb4BM8qJR3AvP9D6XxlfwEuEnP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZb+P4AAoJEC88hzaAX42iKF8H/1NIik4ybNCSHZnWVLUDtMZk
XagIr8jgkKw0NqkGrNW56NjNqxZ7UY59/rBj+4tc4qCvW3bp7Y9BPZnO8Gg/SuxM
NwqlTupvXkEecs+i/I6D5STzxx97G6shAYukk+Yi7hHhj094tLt0Sf8uiAbJyESt
hLCkf6cSQRVUj2s+C+06J7DD1wil01JP4XBSFIPhq9viPHd6fZN2Z8SprIR7ftNa
xdcsFaHZkIb6pp7VRo5yspF2+zpE5MUQJ6NJfZ4WBUY775LoupMvGC3E+t6+sILo
vEDnQcz5NOJvQFpLrp+UKHD7cc3MNESSIyeRAZxD6RKRtkEkAUTinFqhaGB1Pt8=
=gRzB
-----END PGP SIGNATURE-----

--gF2ijWeHb4BM8qJR3AvP9D6XxlfwEuEnP--


From nobody Wed Jul 19 16:05:19 2017
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 7D2501200F3 for ; Wed, 19 Jul 2017 16:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 anyBunvIz_r4 for ; Wed, 19 Jul 2017 16:05:15 -0700 (PDT)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDE112778E for ; Wed, 19 Jul 2017 16:05:15 -0700 (PDT)
Received: by mail-yb0-x235.google.com with SMTP id c127so2512362ybf.4 for ; Wed, 19 Jul 2017 16:05:15 -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=ONv24w0xHscV3/XLYbWChFio6npzBJNwrjZANFt2fQA=; b=0yIWbI6IwZGv7UdBT0d42KN0Dd+39lx5dOxk9+Ob86qRs/jkdfOwhz84znnfGiticR zY7Wb+h+CBaFtnP+oX2jvoeUfilU2eZ15aVvE601xUtuw82Ub/UBamkO6mW9CGbtKnXi z5wwVa5Te+V/eRkOZTn5oVpkFLMtvl4uodctTnXT/Q6iZBwHv3mBWZI4RX38n1Z3Oj35 Puq8m2rtb1711QmNzsPQtfVH8FyYih+QtzUYhrrHquxalHAxlA0plyQ7C6NhoSqlCmXr 1QDbRTTtTGqsotwsd1n8AdSeeZpbmVUFIiA6NT3qF22V6oG+7YRreXCcZn+n77rXvI0O H2Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ONv24w0xHscV3/XLYbWChFio6npzBJNwrjZANFt2fQA=; b=EDbTxy+TUo7zB4MSDxKT5fRZmyeeKC+3Opx+DiXTtiq6IyzaGYVEr7s/XoTIIyiFLf UthsE06TJHGjEqOWHX5l83vZhGhoVpSLT2zyKMrdLxzAcqU9fInOUl2wMg+JjsstpS7e UIhq/59icJCYxhU8AF+l0ZzI9kUq+/r1cwQVwjTDje7c3AvZuPEyp51krNeEkcsirQPx d6Jy1P2LNFMq70vJWve3MwXV+YRQ98EHGcfxJHCbWOtTzP6hF5UdTFo3q8fR38mQ+LTl WXzJtAWZ5um7rpg7k1tUhiDjt16FgsnRb13x8eIzjtNSuOUnJZbd/LdLoJxYtX4DIUBx u7iw==
X-Gm-Message-State: AIVw113qAHunfN82w5Oj2tQn8VtBAug6NIYDp4znFYTKBTOPDrvPGGfo 5xP1TGr2yDTzreb9mbRUA8KxSIzRt5qlxIU=
X-Received: by 10.37.220.74 with SMTP id y71mr1659983ybe.220.1500505514344; Wed, 19 Jul 2017 16:05:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Wed, 19 Jul 2017 16:05:13 -0700 (PDT)
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>   
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 19 Jul 2017 16:05:13 -0700
Message-ID: 
To: Stephen Farrell 
Cc: Ted Lemon , "" 
Content-Type: multipart/alternative; boundary="94eb2c18f3282aac8a0554b3aa17"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 23:05:17 -0000

--94eb2c18f3282aac8a0554b3aa17
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 19, 2017 at 3:50 PM, Stephen Farrell 
wrote:

> That is a perfect example of the hideous dangers of all of this.
> The implication in the above is that browsers would/should turn
> on wiretapping support in the normal case.
>

Today browsers do turn on wiretapping support in the normal case. There's
nothing they can do about it, and it works right now.

If static-DH is permitted, and I don't mean if we release a document
describing it, I mean if we don't forbid static DH parameters; this will
also continue to be the case. My take: I think we should forbid static DH
for this reason.

Next, if proxies are deployed as the mechanism, this will also continue to
be the case. Again, nothing a browser can do, and I argue that real-world
security is left much much worse for users too.

On the other hand, if we standardize a signaled, opt-in, mechanism; then
browsers have more fine-grained options. I suspect that browsers would NOT
support this by default, just as they don't accept private CAs by default.
Instead the browser would have to configured per a corporate policy. But
they could /also/ choose to disable incognito mode in such circumstances,
to be more fair to end-users. It's an example of something that can't be
done today at all.

Such a mode is likely fine for the corporate users and what they want, but
is not so useful for intelligence agencies and so on, precisely because its
signaled and a bit more transparent. In real world terms, I would regard it
much /less/ likely to create the kind of MITM infrastructure that's useful
for that case.

-- 
Colm

--94eb2c18f3282aac8a0554b3aa17
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Wed, Jul 19, 2017 at 3:5=
0 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wr=
ote:
That is =
a perfect example of the hideous dangers of all of this.

The implication in the above is that browsers would/should turn

on wiretapping support in the normal case.

<=
div>Today browsers do turn on wiretapping support in the normal case. There=
's nothing they can do about it, and it works right now.=C2=A0

If static-DH is permitted, and I don't mean if we rele=
ase a document describing it, I mean if we don't forbid static DH param=
eters; this will also continue to be the case. My take: I think we should f=
orbid static DH for this reason.=C2=A0

Next, if pr=
oxies are deployed as the mechanism, this will also continue to be the case=
. Again, nothing a browser can do, and I argue that real-world security is =
left much much worse for users too.=C2=A0

On the o=
ther hand, if we standardize a signaled, opt-in, mechanism; then browsers h=
ave more fine-grained options. I suspect that browsers would NOT support th=
is by default, just as they don't accept private CAs by default. Instea=
d the browser would have to configured per a corporate policy. But they cou=
ld /also/ choose to disable incognito mode in such circumstances, to be mor=
e fair to end-users. It's an example of something that can't be don=
e today at all.

Such a mode is likely fine for the=
 corporate users and what they want, but is not so useful for intelligence =
agencies and so on, precisely because its signaled and a bit more transpare=
nt. In real world terms, I would regard it much /less/ likely to create the=
 kind of MITM infrastructure that's useful for that case.=C2=A0

-- 
Colm




--94eb2c18f3282aac8a0554b3aa17--


From nobody Wed Jul 19 16:10:13 2017
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 2623B131B9A for ; Wed, 19 Jul 2017 16:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 8HwaDMK9CDx7 for ; Wed, 19 Jul 2017 16:10:01 -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 99A2F129A9C for ; Wed, 19 Jul 2017 16:10:01 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id a12so6436195ywh.3 for ; Wed, 19 Jul 2017 16:10:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=95GZIQpBl+CkAzCou4bMW3LjVXAXfvhclrogQaXm56A=; b=rdkNOtGCkakJM3jwTC4EScPDhk7h31TYksMo5bpk65+6jKIZamygpYTT+o6xinP6gx q2fbmn5CfjiPDJwRDB1M1ndoQ/CXovc4w7bzIl2PLZKXiDZyrrGvnU5zQ5iYq9reV1r+ Z4+jctAY+n/1wYRxKGHsm8tagE6kCQ9utgHJMaqFQ/f4PI2593Dt/pBnBJEKV6hquFNj GUpbEiYimMsdKuoPcOdJWFUhEwlqdzDMq/WWz315jCc2szjwt8cRFgdEQv67xT4JeMNU gY7T9x9PCZmCcteZb42MP1qjVivR+M6dUuMYV2tQ3Mr8S87HttUTIgTXRhI3PX9AiShU iVhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=95GZIQpBl+CkAzCou4bMW3LjVXAXfvhclrogQaXm56A=; b=FrHrV5JDHvuknpEHlUlB0ghklZXo3BzS7pFrCfE6zCmNBPL8i91AIr7vWO7HkxfWlJ 2ecXRBrT+9AV845YnVhlCLTopRXEn5AOop5k77XXvhEm+oSzUtx2TyD36zcMG4mbX0F6 1Q5k6Gfhydc1fiNCU1+Zd9W9CHI2D3NXFaScSJsw2o3IOSSzugLz/7vbYY4vpyY7xQCv lWHPGhHdRaOasxY8t5CeN7WgVhYjUQkHP6K05z/nckpTzN201P/kZYhh80OI1W8d76EQ s40SJw+vNtPUpcS2dFmSfLVDvV/4VTajtaj+gPLOztAgzHuQNb685helckwciFhnz15s 0i3g==
X-Gm-Message-State: AIVw112z9lo5RdU6bfF4XSkrnwA7LKmpcg7q73Wv7WMtZC9ZdiFa4rgV VJk8Hb2Ei3ru/JyEhjw+0ofJlZy47w==
X-Received: by 10.13.229.132 with SMTP id o126mr1843018ywe.186.1500505800880;  Wed, 19 Jul 2017 16:10:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.170.132 with HTTP; Wed, 19 Jul 2017 16:09:40 -0700 (PDT)
In-Reply-To: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
From: Tony Arcieri 
Date: Wed, 19 Jul 2017 16:09:40 -0700
Message-ID: 
To: Benjamin Kaduk 
Cc: "" 
Content-Type: multipart/alternative; boundary="94eb2c07f9f03ebac00554b3bb30"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 23:10:12 -0000

--94eb2c07f9f03ebac00554b3bb30
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 19, 2017 at 6:09 AM, Benjamin Kaduk  wrote:

> As Stephen noted in his presentation, a lot of the proposals for passive
> decryption can be seen as trying to turn TLS from a two-party protocol into
> a three-party protocol.  Which is probably the right way to think about it,
> even when all (three) parties are within the same administrative domain.
>
> Stephen also said something about it being hard to shoehorn a three-party
> protocol into the API for a two party protocol.
>

Trying to turn a two-party protocol into a three party protocol is a
classical source of confused deputy vulnerabilities:

http://www.hpl.hp.com/techreports/2009/HPL-2009-20.pdf

This is why I have been such a strong proponent of using something like a
TLS extension for this sort of thing if it is to happen. At least that way
we get mutual client and server consent.

-- 
Tony Arcieri

--94eb2c07f9f03ebac00554b3bb30
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On W=
ed, Jul 19, 2017 at 6:09 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:

 =20

   =20
 =20
  

    As Stephen noted in his presentation, a lot of the proposals for
      passive decryption can be seen as trying to turn TLS from a
      two-party protocol into a three-party protocol.=C2=A0 Which is probab=
ly
      the right way to think about it, even when all (three) parties are
      within the same administrative domain.

      

      Stephen also said something about it being hard to shoehorn a
      three-party protocol into the API for a two party protocol.

Trying to turn a two-party protocol into =
a three party protocol is a classical source of confused deputy vulnerabili=
ties:


This is why I have been such a strong propo=
nent of using something like a TLS extension for this sort of thing if it i=
s to happen. At least that way we get mutual client and server consent.

-- 
Tony Arcieri




--94eb2c07f9f03ebac00554b3bb30--


From nobody Wed Jul 19 23:01:10 2017
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 3E5FE124217 for ; Wed, 19 Jul 2017 23:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 ScB0b3WORR_M for ; Wed, 19 Jul 2017 23:01:06 -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 94A23127866 for ; Wed, 19 Jul 2017 23:01:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E155830050A for ; Thu, 20 Jul 2017 02:01:05 -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 DaFyPYygMv26 for ; Thu, 20 Jul 2017 02:01:03 -0400 (EDT)
Received: from [5.5.33.129] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 31E723004CB; Thu, 20 Jul 2017 02:01:02 -0400 (EDT)
From: Russ Housley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_8E1BAAF5-5ADF-48DA-9767-3A21FE23D0A9"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 20 Jul 2017 02:01:03 -0400
In-Reply-To: 
Cc: IETF TLS 
To: Ted Lemon 
References:  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 06:01:08 -0000

--Apple-Mail=_8E1BAAF5-5ADF-48DA-9767-3A21FE23D0A9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Ted, if we use a new extension, then the server cannot include it unless =
the client offered it first.  I am thinking of an approach where the =
server would include information needed by the decryptor in the =
response.  So, if the client did not offer the extension, it would be a =
TLS protocol violation for the server to include it.

Russ


> On Jul 19, 2017, at 1:14 PM, Ted Lemon  wrote:
>=20
> Provably involved, or involved setting an evil bit?
>=20
> On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley > wrote:
> The hum told us that the room was roughly evenly split.  In hind =
sight, I wish the chairs had asked a second question.  If the split in =
the room was different for the second question, then I think we might =
have learned a bit more about what people are thinking.
>=20
> If a specification were available that used an extension that involved =
both the client and the server, would the working group adopt it, work =
on it, and publish it as an RFC?
>=20
> I was listening very carefully to the comments made by people in line. =
 Clearly some people would hum for "no" to the above question, but it =
sounded like many felt that this would be a significant difference.  It =
would ensure that both server and client explicitly opt-in, and any =
party observing the handshake could see the extension was included or =
not.
>=20
> Russ


--Apple-Mail=_8E1BAAF5-5ADF-48DA-9767-3A21FE23D0A9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Ted, if we use a new extension, then the server cannot =
include it unless the client offered it first.  I am thinking of an =
approach where the server would include information needed by the =
decryptor in the response.  So, if the client did not offer the =
extension, it would be a TLS protocol violation for the server to =
include it.

Russ


On Jul 19, 2017, at 1:14 PM, Ted Lemon <mellon@fugue.com> =
wrote:

Provably involved, or involved setting an evil =
bit?

On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley =
<housley@vigilsec.com> =
wrote:
The hum told us =
that the room was roughly evenly split.  In hind sight, I wish the =
chairs had asked a second question.  If the split in the room was =
different for the second question, then I think we might have learned a =
bit more about what people are thinking.



If a specification were available that used an extension that involved =
both the client and the server, would the working group adopt it, work =
on it, and publish it as an RFC?



I was listening very carefully to the comments made by people in =
line.  Clearly some people would hum for "no" to the above =
question, but it sounded like many felt that this would be a significant =
difference.  It would ensure that both server and client explicitly =
opt-in, and any party observing the handshake could see the extension =
was included or not.



Russ

=

--Apple-Mail=_8E1BAAF5-5ADF-48DA-9767-3A21FE23D0A9--


From nobody Wed Jul 19 23:07:26 2017
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 972CE126CC4 for ; Wed, 19 Jul 2017 23:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 jGEm6p3SCDLe for ; Wed, 19 Jul 2017 23:07:24 -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 352CE124217 for ; Wed, 19 Jul 2017 23:07:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 90F7730050A for ; Thu, 20 Jul 2017 02:07:22 -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 ML1s3J6jW3h4 for ; Thu, 20 Jul 2017 02:07:21 -0400 (EDT)
Received: from [5.5.33.129] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 683CF30042C; Thu, 20 Jul 2017 02:07:20 -0400 (EDT)
From: Russ Housley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_7429EDBB-E374-4F1C-9453-AF5294E584CF"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 20 Jul 2017 02:07:20 -0400
In-Reply-To: 
Cc: IETF TLS 
To: Ryan Hamilton 
References:  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 06:07:25 -0000

--Apple-Mail=_7429EDBB-E374-4F1C-9453-AF5294E584CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The agenda included:

- Data Center use of Static DH (30 min)
 https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ =


- National Cybersecurity Center of Excellence (NCCOE) project for
 visibility within the datacenter with TLS 1.3 (10min)
 aka implementing draft-green-tls-static-dh-in-tls13

- Discussion about the previous topic (40min)

At the start of the Discussion portion of the agenda, Stephen Farrell =
talked about https://github.com/sftcd/tinfoil =
.

At the end of the Discussion, the chairs asked for a hum about working =
on visibility in the datacenter, and the room was evenly split.

Russ


> On Jul 19, 2017, at 3:29 PM, Ryan Hamilton  wrote:
>=20
> Can you provide more context for those of us not in the room? What was =
the hum in reference to?
>=20
> On Wed, Jul 19, 2017 at 10:10 AM, Russ Housley > wrote:
> The hum told us that the room was roughly evenly split.  In hind =
sight, I wish the chairs had asked a second question.  If the split in =
the room was different for the second question, then I think we might =
have learned a bit more about what people are thinking.
>=20
> If a specification were available that used an extension that involved =
both the client and the server, would the working group adopt it, work =
on it, and publish it as an RFC?
>=20
> I was listening very carefully to the comments made by people in line. =
 Clearly some people would hum for "no" to the above question, but it =
sounded like many felt that this would be a significant difference.  It =
would ensure that both server and client explicitly opt-in, and any =
party observing the handshake could see the extension was included or =
not.
>=20
> Russ
>=20
>=20


--Apple-Mail=_7429EDBB-E374-4F1C-9453-AF5294E584CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

The agenda included:

- Data =
Center use of Static DH (30 min)
 https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-t=
ls13/

- National Cybersecurity Center =
of Excellence (NCCOE) project for
 visibility within =
the datacenter with TLS 1.3 (10min)
 aka implementing =
draft-green-tls-static-dh-in-tls13

- =
Discussion about the previous topic (40min)

At the start of the Discussion portion =
of the agenda, Stephen Farrell talked about https://github.com/sftcd/tinfoil.

At the end of the Discussion, the =
chairs asked for a hum about working on visibility in the datacenter, =
and the room was evenly split.

Russ


On Jul 19, 2017, at 3:29 PM, =
Ryan Hamilton <rch@google.com> wrote:

Can you provide more context for those of us not in the =
room? What was the hum in reference to?

On Wed, =
Jul 19, 2017 at 10:10 AM, Russ Housley <housley@vigilsec.com> wrote:
The hum told us that =
the room was roughly evenly split.  In hind sight, I wish the =
chairs had asked a second question.  If the split in the room was =
different for the second question, then I think we might have learned a =
bit more about what people are thinking.



If a specification were available that used an extension that involved =
both the client and the server, would the working group adopt it, work =
on it, and publish it as an RFC?



I was listening very carefully to the comments made by people in =
line.  Clearly some people would hum for "no" to the above =
question, but it sounded like many felt that this would be a significant =
difference.  It would ensure that both server and client explicitly =
opt-in, and any party observing the handshake could see the extension =
was included or not.



Russ







=

--Apple-Mail=_7429EDBB-E374-4F1C-9453-AF5294E584CF--


From nobody Wed Jul 19 23:13:15 2017
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 64E7E129B33 for ; Wed, 19 Jul 2017 23:13: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jevU6jcIgZAP for ; Wed, 19 Jul 2017 23:13:12 -0700 (PDT)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 849BD127866 for ; Wed, 19 Jul 2017 23:13:12 -0700 (PDT)
Received: by mail-pg0-x236.google.com with SMTP id 123so10245430pgj.1 for ; Wed, 19 Jul 2017 23:13:12 -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=D2bC7pg/69nnwccWCDb8MAv18zo+Z0r6GY6ngY61lWY=; b=BhH+h1zkg3KaDSFwau8tgO8kaEPlMBid5Yt7/OGlvJYddGVLZDgNbUlRfpdWrVjv0L f9CsT81BHLDu2fGq+9y5u2mBpQxnQKlhFRb0HMdj3ioDipN8dC0aFbPM/8eBerCNFNcB Uxk8TjkKCnKHS+dWwxvJOU9lg2u7RQEefTyrRlfNvKZczuUZnhzawFbQ0Tss+kaOCzXH KLpFZjlH2VecLqhT67FJ/KESDejja6JT3Do8Yp2Qm3G0tcgM4rFByVCqdVvxsFS8Vw0J lw1ylZOhIAWEgMulLnXlg0qkyT3X0e3V2zjvt634atv6hWOSrekkz7xtyl6i0sCnQPj3 eDCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D2bC7pg/69nnwccWCDb8MAv18zo+Z0r6GY6ngY61lWY=; b=tGyipKbRdpKibOWCMOaO7qPYsA31Kgpgtmn0XkIDhwM6BxRDRO7gjx3MZpV/RoeALJ uZoOJp6Rj1zy3zuH4hZ3kFJgg9gtdPTIhCNj2d2dONKgAQZv+52Pc/SP0YY5D7Sdx77o grALiO8WZ8G8JnN+rLsnRFOU0MoIKIZE9ah2DyQrdkrRKoTK1BwTXetB3dwc0op43DKR iNjLhnmE1BlgWrS+Adlyqf7peeHSARdEJ+I/OJbm1pmExKxkLeJo6VNdwqlvFOL0cY2x rMSgYDheJxnGVooBBqNum/kfnzdp9oHahC+ZuRXaKLixDNG5wly5hxB2gd7aUNwSZQK6 q8Og==
X-Gm-Message-State: AIVw112kOD7LCyAR611ianj8U795ScM8hxVBMJ9tBX+ypLijRPUJXH/Z +YuVsyzkubGxQ4xtjp+4CPaS+FO0c+VH
X-Received: by 10.98.7.87 with SMTP id b84mr2798690pfd.216.1500531192115; Wed, 19 Jul 2017 23:13:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 23:13:11 -0700 (PDT)
Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 23:13:11 -0700 (PDT)
In-Reply-To: 
References:   
From: Ted Lemon 
Date: Thu, 20 Jul 2017 08:13:11 +0200
Message-ID: 
To: Russ Housley 
Cc: "" 
Content-Type: multipart/alternative; boundary="001a1143ccc4ae49f20554b9a410"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 06:13:14 -0000

--001a1143ccc4ae49f20554b9a410
Content-Type: text/plain; charset="UTF-8"

I think that's okay, since this is only for use in applications where both
parties are in on the deal. But the problem with the static ecdh proposal
is the the server is not compelled to reveal that it is doing it.

On Jul 20, 2017 8:01 AM, "Russ Housley"  wrote:

> Ted, if we use a new extension, then the server cannot include it unless
> the client offered it first.  I am thinking of an approach where the server
> would include information needed by the decryptor in the response.  So, if
> the client did not offer the extension, it would be a TLS protocol
> violation for the server to include it.
>
> Russ
>
>
> On Jul 19, 2017, at 1:14 PM, Ted Lemon  wrote:
>
> Provably involved, or involved setting an evil bit?
>
> On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley 
> wrote:
>
>> The hum told us that the room was roughly evenly split.  In hind sight, I
>> wish the chairs had asked a second question.  If the split in the room was
>> different for the second question, then I think we might have learned a bit
>> more about what people are thinking.
>>
>> If a specification were available that used an extension that involved
>> both the client and the server, would the working group adopt it, work on
>> it, and publish it as an RFC?
>>
>> I was listening very carefully to the comments made by people in line.
>> Clearly some people would hum for "no" to the above question, but it
>> sounded like many felt that this would be a significant difference.  It
>> would ensure that both server and client explicitly opt-in, and any party
>> observing the handshake could see the extension was included or not.
>>
>> Russ
>>
>
>

--001a1143ccc4ae49f20554b9a410
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think that's okay, since this is only for use in ap=
plications where both parties are in on the deal. But the problem with the =
static ecdh proposal is the the server is not compelled to reveal that it i=
s doing it.=C2=A0

On Jul 20, 2017 8:01 AM, "Russ Housley" <housley@vigilsec.com> wrote:
Ted, if we use a new extension, then the server cannot include it unless =
the client offered it first.=C2=A0 I am thinking of an approach where the s=
erver would include information needed by the decryptor in the response.=C2=
=A0 So, if the client did not offer the extension, it would be a TLS protoc=
ol violation for the server to include it.

Russ


On Jul 19, 2017, a=
t 1:14 PM, Ted Lemon <mellon@fugue.com> wrote:

Provably involved, or invo=
lved setting an evil bit?

On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley <housley@vi=
gilsec.com> wrote:
The hum =
told us that the room was roughly evenly split.=C2=A0 In hind sight, I wish=
 the chairs had asked a second question.=C2=A0 If the split in the room was=
 different for the second question, then I think we might have learned a bi=
t more about what people are thinking.



If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?



I was listening very carefully to the comments made by people in line.=C2=
=A0 Clearly some people would hum for "no" to the above question,=
 but it sounded like many felt that this would be a significant difference.=
=C2=A0 It would ensure that both server and client explicitly opt-in, and a=
ny party observing the handshake could see the extension was included or no=
t.



Russ

<=
/blockquote>


--001a1143ccc4ae49f20554b9a410--


From nobody Wed Jul 19 23:40:29 2017
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 EB5D5127866 for ; Wed, 19 Jul 2017 23:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 HM9QMXgKgmE4 for ; Wed, 19 Jul 2017 23:40:24 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0109.outbound.protection.outlook.com [104.47.38.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C32124217 for ; Wed, 19 Jul 2017 23:40:24 -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=bbG902/PtoVLSHTIvkCrZB/OSX1jl0waNFE9t0I8d60=; b=UuxQcswA2km6Zy7vjVKsHIki7dpq/JC3B9Dk+Nxyhe2O5VEFUqaxikvEcLMw6NmqeZMYPCSSPXaSVwMynYe711VTP9JkMGOAosmuJpn2Guf4JvhivEsTg0GQqWXiz17Qap+oRqkLWZQfaTnAC4OlOvVY6JjV8y+VUDiV379RUkM=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0108.namprd21.prod.outlook.com (10.161.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.7; Thu, 20 Jul 2017 06:40:22 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::c8c3:4f7d:e655:1fb2]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::c8c3:4f7d:e655:1fb2%13]) with mapi id 15.01.1304.007; Thu, 20 Jul 2017 06:40:21 +0000
From: Andrei Popov 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Stephen Farrell 
CC: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJBeA74CtGrHzkK8oKin6MaiBqJbXOSAgAAClACAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB+TgA=
Date: Thu, 20 Jul 2017 06:40:21 +0000
Message-ID: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none; allcosts.net; dmarc=none action=none header.from=microsoft.com; 
x-originating-ip: [2001:67c:1232:184:f5ce:6e9b:d5c1:2697]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0108; 7:uB/1i2+6uKHDC2I4g1zhSfcPufvBgf1U25NwyJw6xM5C3iMmWntZ4ejWfKkLgRiQEqlqNqAyrTxKOH5KezNI4SCE7kGEm8xljUB1Vsk9oILbg5VCBPdjVV4/CYdgA47v2niVJtPEMMSqHKU1/Dym7Ze8TRdcu1omKpxlx6z1ryVjJGdXhzJp5nF4z1GuDG3yWPzcfe8WGKZVxPXMxAOfYycIYw5cjgOad3G5SrKDAwbSAz43LMm7SaXUddlvh1yQW6JHPVMcR5jUFaKUTP+wu1bJXvQhw5L7eeyQuS0SPF+6uiBo79i4H+yRDtFSp06sT9BlG3sdSPn1z5NlEWpyHg2yRc2SWvSfcT5zcFqBq0CvGgxMrivsgt1259sgo1qYPzMPOSmz1u1FXMY2QWq3oOnxxcl0Bb9DptLUUl5q3hFqw7Se7cCZMvs1bPGEB553PIECiPmy49koZJC8L4OwbPYDDpvBWuiM+nkCKpXufDacxM7r6eSKuUBSORNSyZzvMlUstdwl3murv0gWN1I1NAxf1pqKbcr36B9vg3KsZe0e8jd61z4VeCAFd1sudFH36Rr72Bg6dPeNvPOZoTMz78+SHadmqAv5saRPqsu8SICLar7zkbOjT9bpupDy0oTPeHQ/K6scOQb5HW+so2wiipfbHDQieiIFUNEoxU+VBXd3kBqF2Zuom6wVfRI31e5xA9k3mrBEkm34RKMvnasIoyMY9SwteE+06GEBvpGJ1jEMq9ek6aofoEzLGYCr8rHSdoS7gjvbRxifH0zM+VuI9jeqqFUUhkQiWdqWGnBpSa5ex75mbg+bY1w0DP5b7MgA
x-ms-office365-filtering-correlation-id: 0a0c8425-f621-4c44-0194-08d4cf3a31fb
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR21MB0108; 
x-ms-traffictypediagnostic: DM2PR21MB0108:
x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(32856632585715)(133145235818549)(26388249023172)(236129657087228)(192374486261705)(148574349560750)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0108; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0108; 
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39400400002)(39410400002)(39450400003)(39840400002)(39850400002)(24454002)(377454003)(7696004)(5250100002)(4326008)(81166006)(6116002)(790700001)(6506006)(102836003)(86362001)(72206003)(5660300001)(54356999)(76176999)(478600001)(2906002)(53546010)(2950100002)(8676002)(14454004)(25786009)(7736002)(93886004)(10290500003)(53936002)(50986999)(2900100001)(6246003)(74316002)(38730400002)(229853002)(6436002)(189998001)(5005710100001)(55016002)(6306002)(54896002)(236005)(99286003)(9686003)(10090500001)(9326002)(3660700001)(33656002)(3280700002)(8936002)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0108; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR21MB00915FC926FEE6F64324E62D8CA70DM2PR21MB0091namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 06:40:21.7950 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0108
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 06:40:27 -0000

--_000_DM2PR21MB00915FC926FEE6F64324E62D8CA70DM2PR21MB0091namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQ29sbSwNCg0KDQogICogICBUb2RheSBicm93c2VycyBkbyB0dXJuIG9uIHdpcmV0YXBwaW5n
IHN1cHBvcnQgaW4gdGhlIG5vcm1hbCBjYXNlLiBUaGVyZSdzIG5vdGhpbmcgdGhleSBjYW4gZG8g
YWJvdXQgaXQsIGFuZCBpdCB3b3JrcyByaWdodCBub3cuDQoNClRoaXMgaXMgbmV3cyB0byBtZTsg
d2hpY2ggYnJvd3NlcnMgZG8gdGhpcyAoc28gdGhhdCBJIGNhbiBhdm9pZCB1c2luZyB0aGVtKT8N
Cg0KVGhhbmtzLA0KDQpBbmRyZWkNCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBDb2xtIE1hY0PDoXJ0aGFpZ2gNClNlbnQ6IFRodXJzZGF5LCBK
dWx5IDIwLCAyMDE3IDE6MDUgQU0NClRvOiBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVs
bEBjcy50Y2QuaWU+DQpDYzogPHRsc0BpZXRmLm9yZz4gPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6
IFJlOiBbVExTXSBkYXRhY2VudGVyIFRMUyBkZWNyeXB0aW9uIGFzIGEgdGhyZWUtcGFydHkgcHJv
dG9jb2wNCg0KDQpPbiBXZWQsIEp1bCAxOSwgMjAxNyBhdCAzOjUwIFBNLCBTdGVwaGVuIEZhcnJl
bGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50
Y2QuaWU+PiB3cm90ZToNClRoYXQgaXMgYSBwZXJmZWN0IGV4YW1wbGUgb2YgdGhlIGhpZGVvdXMg
ZGFuZ2VycyBvZiBhbGwgb2YgdGhpcy4NClRoZSBpbXBsaWNhdGlvbiBpbiB0aGUgYWJvdmUgaXMg
dGhhdCBicm93c2VycyB3b3VsZC9zaG91bGQgdHVybg0Kb24gd2lyZXRhcHBpbmcgc3VwcG9ydCBp
biB0aGUgbm9ybWFsIGNhc2UuDQoNClRvZGF5IGJyb3dzZXJzIGRvIHR1cm4gb24gd2lyZXRhcHBp
bmcgc3VwcG9ydCBpbiB0aGUgbm9ybWFsIGNhc2UuIFRoZXJlJ3Mgbm90aGluZyB0aGV5IGNhbiBk
byBhYm91dCBpdCwgYW5kIGl0IHdvcmtzIHJpZ2h0IG5vdy4NCg0KSWYgc3RhdGljLURIIGlzIHBl
cm1pdHRlZCwgYW5kIEkgZG9uJ3QgbWVhbiBpZiB3ZSByZWxlYXNlIGEgZG9jdW1lbnQgZGVzY3Jp
YmluZyBpdCwgSSBtZWFuIGlmIHdlIGRvbid0IGZvcmJpZCBzdGF0aWMgREggcGFyYW1ldGVyczsg
dGhpcyB3aWxsIGFsc28gY29udGludWUgdG8gYmUgdGhlIGNhc2UuIE15IHRha2U6IEkgdGhpbmsg
d2Ugc2hvdWxkIGZvcmJpZCBzdGF0aWMgREggZm9yIHRoaXMgcmVhc29uLg0KDQpOZXh0LCBpZiBw
cm94aWVzIGFyZSBkZXBsb3llZCBhcyB0aGUgbWVjaGFuaXNtLCB0aGlzIHdpbGwgYWxzbyBjb250
aW51ZSB0byBiZSB0aGUgY2FzZS4gQWdhaW4sIG5vdGhpbmcgYSBicm93c2VyIGNhbiBkbywgYW5k
IEkgYXJndWUgdGhhdCByZWFsLXdvcmxkIHNlY3VyaXR5IGlzIGxlZnQgbXVjaCBtdWNoIHdvcnNl
IGZvciB1c2VycyB0b28uDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBpZiB3ZSBzdGFuZGFyZGl6ZSBh
IHNpZ25hbGVkLCBvcHQtaW4sIG1lY2hhbmlzbTsgdGhlbiBicm93c2VycyBoYXZlIG1vcmUgZmlu
ZS1ncmFpbmVkIG9wdGlvbnMuIEkgc3VzcGVjdCB0aGF0IGJyb3dzZXJzIHdvdWxkIE5PVCBzdXBw
b3J0IHRoaXMgYnkgZGVmYXVsdCwganVzdCBhcyB0aGV5IGRvbid0IGFjY2VwdCBwcml2YXRlIENB
cyBieSBkZWZhdWx0LiBJbnN0ZWFkIHRoZSBicm93c2VyIHdvdWxkIGhhdmUgdG8gY29uZmlndXJl
ZCBwZXIgYSBjb3Jwb3JhdGUgcG9saWN5LiBCdXQgdGhleSBjb3VsZCAvYWxzby8gY2hvb3NlIHRv
IGRpc2FibGUgaW5jb2duaXRvIG1vZGUgaW4gc3VjaCBjaXJjdW1zdGFuY2VzLCB0byBiZSBtb3Jl
IGZhaXIgdG8gZW5kLXVzZXJzLiBJdCdzIGFuIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHRoYXQgY2Fu
J3QgYmUgZG9uZSB0b2RheSBhdCBhbGwuDQoNClN1Y2ggYSBtb2RlIGlzIGxpa2VseSBmaW5lIGZv
ciB0aGUgY29ycG9yYXRlIHVzZXJzIGFuZCB3aGF0IHRoZXkgd2FudCwgYnV0IGlzIG5vdCBzbyB1
c2VmdWwgZm9yIGludGVsbGlnZW5jZSBhZ2VuY2llcyBhbmQgc28gb24sIHByZWNpc2VseSBiZWNh
dXNlIGl0cyBzaWduYWxlZCBhbmQgYSBiaXQgbW9yZSB0cmFuc3BhcmVudC4gSW4gcmVhbCB3b3Js
ZCB0ZXJtcywgSSB3b3VsZCByZWdhcmQgaXQgbXVjaCAvbGVzcy8gbGlrZWx5IHRvIGNyZWF0ZSB0
aGUga2luZCBvZiBNSVRNIGluZnJhc3RydWN0dXJlIHRoYXQncyB1c2VmdWwgZm9yIHRoYXQgY2Fz
ZS4NCg0KLS0NCkNvbG0NCg==

--_000_DM2PR21MB00915FC926FEE6F64324E62D8CA70DM2PR21MB0091namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv
TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo
dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg
TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u
b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K
CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv
bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx
LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg
RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU0ODUzNzY3MjsNCgltc28t
bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTM3MjIyMjk3MiAtMTcx
MjAwODQ1MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5
ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZh
bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N
CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs
MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n
czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt
aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm
b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1s
aXN0LWlkOjE3MjY3NjAxNjA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt
cGxhdGUtaWRzOjEwMzg0OTEyODQgMTcwMjY3MTgxNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4
OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs
MTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n
czsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0
IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPkhpIENvbG0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv
TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg
bGZvMiI+VG9kYXkgYnJvd3NlcnMgZG8gdHVybiBvbiB3aXJldGFwcGluZyBzdXBwb3J0IGluIHRo
ZSBub3JtYWwgY2FzZS4gVGhlcmUncyBub3RoaW5nIHRoZXkgY2FuIGRvIGFib3V0IGl0LCBhbmQg
aXQgd29ya3MgcmlnaHQgbm93LiZuYnNwOzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgaXMgbmV3cyB0byBt
ZTsgd2hpY2ggYnJvd3NlcnMgZG8gdGhpcyAoc28gdGhhdCBJIGNhbiBhdm9pZCB1c2luZyB0aGVt
KT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmRyZWk8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv
c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxz
cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs
ZiBPZiA8L2I+Q29sbSBNYWNDw6FydGhhaWdoPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBK
dWx5IDIwLCAyMDE3IDE6MDUgQU08YnI+DQo8Yj5Ubzo8L2I+IFN0ZXBoZW4gRmFycmVsbCAmbHQ7
c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDt0bHNAaWV0
Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb
VExTXSBkYXRhY2VudGVyIFRMUyBkZWNyeXB0aW9uIGFzIGEgdGhyZWUtcGFydHkgcHJvdG9jb2w8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCAxOSwgMjAxNyBhdCAz
OjUwIFBNLCBTdGVwaGVuIEZhcnJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJl
bGxAY3MudGNkLmllIiB0YXJnZXQ9Il9ibGFuayI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGF0IGlzIGEgcGVyZmVjdCBleGFtcGxlIG9mIHRoZSBoaWRlb3VzIGRh
bmdlcnMgb2YgYWxsIG9mIHRoaXMuPGJyPg0KVGhlIGltcGxpY2F0aW9uIGluIHRoZSBhYm92ZSBp
cyB0aGF0IGJyb3dzZXJzIHdvdWxkL3Nob3VsZCB0dXJuPGJyPg0Kb24gd2lyZXRhcHBpbmcgc3Vw
cG9ydCBpbiB0aGUgbm9ybWFsIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub2RheSBicm93c2VycyBkbyB0dXJuIG9uIHdp
cmV0YXBwaW5nIHN1cHBvcnQgaW4gdGhlIG5vcm1hbCBjYXNlLiBUaGVyZSdzIG5vdGhpbmcgdGhl
eSBjYW4gZG8gYWJvdXQgaXQsIGFuZCBpdCB3b3JrcyByaWdodCBub3cuJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHN0YXRpYy1E
SCBpcyBwZXJtaXR0ZWQsIGFuZCBJIGRvbid0IG1lYW4gaWYgd2UgcmVsZWFzZSBhIGRvY3VtZW50
IGRlc2NyaWJpbmcgaXQsIEkgbWVhbiBpZiB3ZSBkb24ndCBmb3JiaWQgc3RhdGljIERIIHBhcmFt
ZXRlcnM7IHRoaXMgd2lsbCBhbHNvIGNvbnRpbnVlIHRvIGJlIHRoZSBjYXNlLiBNeSB0YWtlOiBJ
IHRoaW5rIHdlIHNob3VsZCBmb3JiaWQgc3RhdGljIERIIGZvciB0aGlzIHJlYXNvbi4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmV4
dCwgaWYgcHJveGllcyBhcmUgZGVwbG95ZWQgYXMgdGhlIG1lY2hhbmlzbSwgdGhpcyB3aWxsIGFs
c28gY29udGludWUgdG8gYmUgdGhlIGNhc2UuIEFnYWluLCBub3RoaW5nIGEgYnJvd3NlciBjYW4g
ZG8sIGFuZCBJIGFyZ3VlIHRoYXQgcmVhbC13b3JsZCBzZWN1cml0eSBpcyBsZWZ0IG11Y2ggbXVj
aCB3b3JzZSBmb3IgdXNlcnMgdG9vLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB0aGUgb3RoZXIgaGFuZCwgaWYgd2Ugc3RhbmRh
cmRpemUgYSBzaWduYWxlZCwgb3B0LWluLCBtZWNoYW5pc207IHRoZW4gYnJvd3NlcnMgaGF2ZSBt
b3JlIGZpbmUtZ3JhaW5lZCBvcHRpb25zLiBJIHN1c3BlY3QgdGhhdCBicm93c2VycyB3b3VsZCBO
T1Qgc3VwcG9ydCB0aGlzIGJ5IGRlZmF1bHQsIGp1c3QgYXMgdGhleSBkb24ndCBhY2NlcHQgcHJp
dmF0ZSBDQXMgYnkgZGVmYXVsdC4gSW5zdGVhZCB0aGUgYnJvd3Nlcg0KIHdvdWxkIGhhdmUgdG8g
Y29uZmlndXJlZCBwZXIgYSBjb3Jwb3JhdGUgcG9saWN5LiBCdXQgdGhleSBjb3VsZCAvYWxzby8g
Y2hvb3NlIHRvIGRpc2FibGUgaW5jb2duaXRvIG1vZGUgaW4gc3VjaCBjaXJjdW1zdGFuY2VzLCB0
byBiZSBtb3JlIGZhaXIgdG8gZW5kLXVzZXJzLiBJdCdzIGFuIGV4YW1wbGUgb2Ygc29tZXRoaW5n
IHRoYXQgY2FuJ3QgYmUgZG9uZSB0b2RheSBhdCBhbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1Y2ggYSBtb2RlIGlzIGxpa2VseSBmaW5l
IGZvciB0aGUgY29ycG9yYXRlIHVzZXJzIGFuZCB3aGF0IHRoZXkgd2FudCwgYnV0IGlzIG5vdCBz
byB1c2VmdWwgZm9yIGludGVsbGlnZW5jZSBhZ2VuY2llcyBhbmQgc28gb24sIHByZWNpc2VseSBi
ZWNhdXNlIGl0cyBzaWduYWxlZCBhbmQgYSBiaXQgbW9yZSB0cmFuc3BhcmVudC4gSW4gcmVhbCB3
b3JsZCB0ZXJtcywgSSB3b3VsZCByZWdhcmQgaXQgbXVjaCAvbGVzcy8NCiBsaWtlbHkgdG8gY3Jl
YXRlIHRoZSBraW5kIG9mIE1JVE0gaW5mcmFzdHJ1Y3R1cmUgdGhhdCdzIHVzZWZ1bCBmb3IgdGhh
dCBjYXNlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Q29sbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_DM2PR21MB00915FC926FEE6F64324E62D8CA70DM2PR21MB0091namp_--


From nobody Wed Jul 19 23:53:51 2017
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 133C0127866 for ; Wed, 19 Jul 2017 23:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7Ahr72xWg2Bd for ; Wed, 19 Jul 2017 23:53:37 -0700 (PDT)
Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9445B124217 for ; Wed, 19 Jul 2017 23:53:37 -0700 (PDT)
Received: by mail-wr0-x243.google.com with SMTP id y67so8800454wrb.3 for ; Wed, 19 Jul 2017 23:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+r2MYrPs9+rNyM3htUk4gepoxFk3i3kLmc6maJSwLok=; b=CXylOXs9e59YFWXF8DvuLwtUHx8Wau7iCX67PtKcS7M0yBvjw6vpou7gTJr36z5rbl +A0Ve69dGSmnWGdeye3qNDbfv/VkqPFy2V206kdtgn5znS+zTmz/99trfjfTsThSL+AE brVYpJZEjUOwKMeTnVdLUiNJezgNCDK/1mK1ACUY4uPOmJcPZH32PPFtszHw8jJ6escx HFjlEekH9NDgccom87yOaSX+F3bdzK6pLf5chKQQmRzVAEzBOtThiYlEsK+WgovlUSBx aqSf7CaRJTAuKyI+172dupQy6mG/wNBIBZpQYhC8IZNUKR73un5xYtVU27rdxfEj2t1v 1zvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+r2MYrPs9+rNyM3htUk4gepoxFk3i3kLmc6maJSwLok=; b=XUv2gHIkTigY983q6+1jTF5NqQ7bE1IC5WwW1ky9zqWMy6xGyryTDEplkQ/PKnQ5P/ DqpZYJlRPMHVfmE6W51AY4ufN0QQiaK6KR20mYGam+0o/TFjXgnY+pIOZIxTlV31EqRl 5tPSVGEwcdW0pNVONcuX0Q99Duwn/A+hiomfUOUsTvpTWgN3bcafWd+e7BMNl3/VJ5qr F5Xzb2bYTX2bMfqptX+aGDL37f4CHLahihQbk7Ee6ZFL94Z0xKHNA+xAGBnnmyObUpsg nE7xGyihzBxJf5BmvpGYPsZcii2ak+jzt7o7bAdrUDTmRV/wPNXQJ+HKVDKtDLjMHBnO RnSQ==
X-Gm-Message-State: AIVw11204+uwlpo68PKdBP9E/9QD9gSIqvV9V6ABbkcel1qnYKUmeVkr IvZj3zS3cXXGgw==
X-Received: by 10.223.163.16 with SMTP id c16mr6475534wrb.173.1500533616127; Wed, 19 Jul 2017 23:53:36 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:7962:e0ed:8b4:d10e? ([2001:67c:1232:144:7962:e0ed:8b4:d10e]) by smtp.gmail.com with ESMTPSA id t14sm5269455wra.44.2017.07.19.23.53.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 23:53:35 -0700 (PDT)
From: Yoav Nir 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_8201FF65-9838-4E0E-B86F-0D9BF2928E9E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 20 Jul 2017 08:53:33 +0200
In-Reply-To: 
Cc: Ted Lemon , IETF TLS 
To: Russ Housley 
References:   
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 06:53:39 -0000

--Apple-Mail=_8201FF65-9838-4E0E-B86F-0D9BF2928E9E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8B8FF75B-3D43-4B67-A59D-9FE972EE9140"


--Apple-Mail=_8B8FF75B-3D43-4B67-A59D-9FE972EE9140
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 20 Jul 2017, at 8:01, Russ Housley  wrote:
>=20
> Ted, if we use a new extension, then the server cannot include it =
unless the client offered it first.  I am thinking of an approach where =
the server would include information needed by the decryptor in the =
response.  So, if the client did not offer the extension, it would be a =
TLS protocol violation for the server to include it.
>=20

So we also add an alert called =E2=80=9Ckey-export-needed=E2=80=9D in =
case the client does not include it.

That way a browser (as an example) can show the user why the connection =
was broken (=E2=80=9Cserver requires wiretapping to be enabled. Go to =
about:config  if that is OK and change the allow-wiretap =
setting to True=E2=80=9D)




--Apple-Mail=_8B8FF75B-3D43-4B67-A59D-9FE972EE9140
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 20 Jul 2017, at 8:01, Russ Housley <housley@vigilsec.com> wrote:

Ted, if we use =
a new extension, then the server cannot include it unless the client =
offered it first.  I am thinking of an approach where the server =
would include information needed by the decryptor in the response. =
 So, if the client did not offer the extension, it would be a TLS =
protocol violation for the server to include it.


So =
we also add an alert called =E2=80=9Ckey-export-needed=E2=80=9D in case =
the client does not include it.

That =
way a browser (as an example) can show the user why the connection was =
broken (=E2=80=9Cserver requires wiretapping to be enabled. Go to about:config if that is OK and =
change the allow-wiretap setting to True=E2=80=9D)



=

--Apple-Mail=_8B8FF75B-3D43-4B67-A59D-9FE972EE9140--

--Apple-Mail=_8201FF65-9838-4E0E-B86F-0D9BF2928E9E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJZcFNuAAoJELhJCxUKWMyZpaoIAKpVL2Zb2wRaa2v9D3LORGi/
MtvQVFQzSBbokF1JpbtQ/stUkO7vqXltYuxTAzpIAS7QyoVkxLpU6Kqj/TqxGZ73
xfkYagb5A4yLFpyRiNLyc2xiS7MXk4ZJmfhHfRTQdIRyOr/GE8l3MlAgK/oSW26W
a8cNZGwjvTUBuXkNIU5jxpXerYhvpYPxc54Gg97iXLO4J7Lna/g8seVfpozKxeHX
T6iO6xtgqe/+tofTm456+y3A6vfrnYlY3yDUA79RWIFbHkhFav246RRjjh9oG1K/
beFHiPgvLSXkD4247j6BG52YgaNYWmCiSZtV0CBHywlFdCvKqapOEieDlcTOQNo=
=i0HF
-----END PGP SIGNATURE-----

--Apple-Mail=_8201FF65-9838-4E0E-B86F-0D9BF2928E9E--


From nobody Wed Jul 19 23:57:08 2017
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 185F612869B for ; Wed, 19 Jul 2017 23:57:06 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 3e1TZqcnb7og for ; Wed, 19 Jul 2017 23:57:05 -0700 (PDT)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002: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 CCEE0127866 for ; Wed, 19 Jul 2017 23:57:04 -0700 (PDT)
Received: by mail-yb0-x233.google.com with SMTP id w187so4785029ybc.0 for ; Wed, 19 Jul 2017 23:57:04 -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=0HBHg3wGiVIIAQQHQs9awfB9xh2a9kbMFTGopaPDPxQ=; b=WGgLucLl8sCfKzLAnhuNjlXg24cQtjGT9J2NVKYV5lap4ItAwTdj66r+Pj168G/Dnw UbTtLH8R86/GNqDuUlxYilCxp4O9Fna3uMwX2Ns8PACJz+G796VxOhUAhrHbxuVHi1fV /ADm0tzOOWorhxS+3xXlr2SSr1PjjaP+i/4glbnUtsV8oqUpEGkm+bF5/xUKN4tPi4Fr b5pEPVAfWhLdVDee1rWFfMDLNXhLMr/DSsWE/0cMsvWj3zCZS39Eopa4o5hyh3gUJ/ZX 2YyRYpcxnT5q6U07YJy5i7G66YR6lqB9KUce6YfnPIHwDD3qjYmRYcJrM/vCThC0QSef fzBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0HBHg3wGiVIIAQQHQs9awfB9xh2a9kbMFTGopaPDPxQ=; b=iO/1t1VrDXZmcRuUkuL7WJjT49k3rRCbZQb/+zWgks2NOCOgYJqXX3xFhQlVulXzZN 5FIMSz8TqLBjuzVOsGYFjVUK2P66AoFehciU0vbW9jFfM31RNxsxsjXIgh/x0CTdzXnn boRPx61khj5H+LeNPg7ic02RZkUIYAjjGUiTDQG0Ux9aj3pwvXBfpBcYbwWqS9hS1YfD 5jR6hdt97cAVAFfZ1rRoISkuVpv5In9WNvKUUXU7+OJjJd8H+5poGgZEjXvKHm7aK+3z QkQxwmo0Hko32oQX6AcUnMwIFrVwkex4BTDCIfNXWt0CzHx2GQfFdn5ZgFc+8CX4ZWA+ vVkg==
X-Gm-Message-State: AIVw110IUovW0RWRpJCzFFI4u0C2L96Q4yPmIHpocx04/VcukAjW9TzN mFA3qKZQIcBmzn8WZYlD+Yr2WFhPc7J3
X-Received: by 10.37.74.133 with SMTP id x127mr2463938yba.69.1500533824082; Wed, 19 Jul 2017 23:57:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Wed, 19 Jul 2017 23:57:03 -0700 (PDT)
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>     
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 19 Jul 2017 23:57:03 -0700
Message-ID: 
To: Andrei Popov 
Cc: Stephen Farrell , "" 
Content-Type: multipart/alternative; boundary="001a113e8f908eead80554ba416d"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 06:57:06 -0000

--001a113e8f908eead80554ba416d
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 19, 2017 at 11:40 PM, Andrei Popov 
wrote:

> Hi Colm,
>
>
>
>    - Today browsers do turn on wiretapping support in the normal case.
>    There's nothing they can do about it, and it works right now.
>
> This is news to me; which browsers do this (so that I can avoid using
> them)?
>

Like I said, all of them. I don't know of a single browser that forces
DH-only and insists on unique DH parameters today, and it wouldn't be
practical.  So if we're going to refer to an operator who has the server's
private key using their own key to decrypt traffic as wire-tapping, then in
those terms currently all browsers have support for that turned on, as it's
part of existing versions of TLS.

-- 
Colm

--001a113e8f908eead80554ba416d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Jul 19, 2017 at 11:40 PM, Andrei Popov <Andrei.Popov@=
microsoft.com> wrote:











Hi Colm,


=C2=A0


    

  • Today browsers do turn on wiretapping support in the normal case. There&=
#39;s nothing they can do about it, and it works right now.=C2=A0=C2=A0


This is news to me; which browsers do this (=
so that I can avoid using them)?
Like I said, all of them. I don't know of a single browser=
 that forces DH-only and insists on unique DH parameters today, and it woul=
dn't be practical.=C2=A0 So if we're going to refer to an operator =
who has the server's private key using their own key to decrypt traffic=
 as wire-tapping, then in those terms currently all browsers have support f=
or that turned on, as it's part of existing versions of TLS.

-- 
Colm




--001a113e8f908eead80554ba416d--


From nobody Thu Jul 20 00:02:24 2017
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 C46091242F5 for ; Thu, 20 Jul 2017 00:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 hZBroh_Z75a6 for ; Thu, 20 Jul 2017 00:02:20 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9135F127866 for ; Thu, 20 Jul 2017 00:02:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 035F7232B7 for ; Thu, 20 Jul 2017 10:02:19 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id LAweFJkurnv3 for ; Thu, 20 Jul 2017 10:02:18 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C368527F for ; Thu, 20 Jul 2017 10:02:17 +0300 (EEST)
Date: Thu, 20 Jul 2017 10:02:17 +0300
From: Ilari Liusvaara 
To: tls@ietf.org
Message-ID: <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: [TLS] draft-ietf-tls-exported-authenticator questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 07:02:23 -0000

While reading/implementing draft-ietf-tls-exported-authenticator I came
across the following:

1)

The exporter labels are the opposite way around for handshake
contexts and finished keys, which makes little sense.

The text seems to imply that the finished key label the client
uses for sending is "EXPORTER-server authenticator finished key".

2)

In TLS 1.2, even if TLS PRF is not used, the hash function that
absolutely must exist is called "the hash function to use in the
Finished message computation" or "the hash function defined for the
Finished message computation" (and if TLS PRF is used, this hash is
the same hash function as the one underlying TLS PRF).

TLS 1.3 is less consistent:

- "the Hash algorithm for the handshake" (4.4.4)
- "KDF hash algorithm" (4.6.1)
- "the cipher suite hash algorithm" (7.1)
- "the [...] hash algorithm to be used with HKDF" (B.4)

... All those apparently refer to one and the same thing.

3)

What is the Hash() in

"Hash(Handshake Context || Certificate)" and
"Hash(Handshake Context || Certificate || CertificateVerify)"

?

I presume it is the same hash as the one took the output length of
in 2).

4)

What is "the hash function from the handshake" exactly? I presume it
is the same hash as in 3).


5)

Test vectors would be nice (use some deterministic signature, like
Ed25519)...

I have one set of vectors I dumped from my implementation, but no
idea if those are correct (for example, I assumed that the handshake
context and finished labels are the same way around, and the hash for
points 2 to 4 is the hash function defined for the Finished message
computation in the TLS connection the authenticator is to be created
from).



-Ilari


From nobody Thu Jul 20 00:33:40 2017
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 7D558126B72 for ; Thu, 20 Jul 2017 00:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2uY49KtHgi1W for ; Thu, 20 Jul 2017 00:33:35 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8526A126557 for ; Thu, 20 Jul 2017 00:33: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=BCqcA0bqQ/a92LxVIfGrhBEJFcIg05kKT0ZPnWMbpng=; b=gyXYUHmpWAejlfTDl7yHBPkdmNJJMXc+t2ykR+CBXz/N6nHpXNaWjmRijMwLWB3oFgrgf93O2r9zTJnT8ibZK+SBgEGAnAcYbyEi8517NXnxM3M8nsRHrXGoAHhKOA8I4w6J9xfTo3sIsCdjSathwmMEuSnUUYGZFMu+WQUWurM=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0089.namprd21.prod.outlook.com (10.161.141.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.7; Thu, 20 Jul 2017 07:33:33 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::c8c3:4f7d:e655:1fb2]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::c8c3:4f7d:e655:1fb2%13]) with mapi id 15.01.1304.007; Thu, 20 Jul 2017 07:33:33 +0000
From: Andrei Popov 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: Stephen Farrell , "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJBeA74CtGrHzkK8oKin6MaiBqJbXOSAgAAClACAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB+TgCAAAWGgIAAADdw
Date: Thu, 20 Jul 2017 07:33:33 +0000
Message-ID: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none; allcosts.net; dmarc=none action=none header.from=microsoft.com; 
x-originating-ip: [2001:67c:1232:184:f5ce:6e9b:d5c1:2697]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0089; 7:bR/3DcpqJTicvnW3y0UgceuA4+4dBgRjaeUzfWchnb9FGXQ3S+nWCsQlLVztigjHxB0HGrXY0EHy7ztLUUvRKNi9QR/6pi7ItGW0eYpWF30bCxadv/IzThGuoP/D/25Tg7eRB6M5VuzLVy+iqk849cF5gMptP9XymdLD8itA/f0xHTGY8+VfgT8TEwj3k68pQXGsYdfA8/jAsHjCFHa5hzRZ4+1424Of9nkr1v0UYqW4pboUaemtRHQHvDZjo7xqDs+OIs/cxs3rZ1+anrFlDYruKoeTLPuEh9+10eHgli656V7g6dMKH6y7znztWx4hlQmvE1EmD1cNmV/8SXBH5ZU1kvv0Jm3JJ4ZT2g2FaHh83USlz6PpGoeEMy+GKnhOPInuRoHP3fjm+EvLXc6Tr3aTOApVGOXJbAyHW4z+wRDMwyh3ZAmGjqvXjPIUqz9NbL2kEs6iDsY20oU0y5BeajMZIADHChPF+gNMK/ZNFXAN9EXMV16otRyj1ZB9TeCtJ+/RJYe+8S1DOp6vEXLSeumI+AIsIEUaTJYOcLP3H904X+3EBXKVdQMWMxc68wmmg2DrJhQXi7Kb/bs1x2o0kEVILVaZXp3vtwzXUIO5yiQ5RMs4skOC5Wi7EBlNJ7yxytfwd1Y2NBemvvR6+20hAjzhbrDgfgG/czvXEokAkC3XLuLhCPUzYZon9By5L/KcguFSV0QBzNqusKCZslJaG81Z5VEpUxG9/AKePIAeD6slz/qukvavnv/tka3ocDZbrq93HBGVfVkg0ncsP0eUdP+xzf8ipjfySxyc6K10JioxG588Wft9zeva44z9Iwkq
x-ms-office365-filtering-correlation-id: fa1f2a62-b7e4-449b-a196-08d4cf41a073
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR21MB0089; 
x-ms-traffictypediagnostic: DM2PR21MB0089:
x-exchange-antispam-report-test: UriScan:(151999592597050)(32856632585715)(158342451672863)(133145235818549)(26388249023172)(236129657087228)(148574349560750)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0089; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0089; 
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39450400003)(39840400002)(39860400002)(39410400002)(24454002)(377454003)(38730400002)(55016002)(99286003)(6436002)(93886004)(6916009)(229853002)(54906002)(10290500003)(6246003)(110136004)(53936002)(6306002)(54896002)(9686003)(236005)(5250100002)(74316002)(25786009)(86362001)(2900100001)(4326008)(53546010)(72206003)(7736002)(2950100002)(14454004)(478600001)(19609705001)(33656002)(102836003)(5660300001)(54356999)(50986999)(76176999)(8936002)(7696004)(8676002)(81166006)(189998001)(3660700001)(2906002)(10090500001)(790700001)(6506006)(6116002)(3280700002)(5005710100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0089; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR21MB00910D605F561667F655D1698CA70DM2PR21MB0091namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 07:33:33.6432 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0089
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 07:33:38 -0000

--_000_DM2PR21MB00910D605F561667F655D1698CA70DM2PR21MB0091namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWgsIEkgZ2V0IHdoYXQgeW914oCZcmUgc2F5aW5nLg0KDQpESCBwYXJhbWV0ZXIgcmV1c2UgZm9y
IHBlcmZvcm1hbmNlIHJlYXNvbnMgaXMgbm90IGEgZ29vZCB0aGluZywgYW5kIGl0IGlzIG5vdCBz
b21ldGhpbmcgcmVjb21tZW5kZWQgaW4gdGhlIFRMUyBSRkNzLiBCdXQgb2ZmZXJpbmcgc3RhbmRh
cmRpemVkIHdheXMgb2YgZXhwb3J0aW5nL2ltcG9ydGluZyBrZXlzIGZvciB3aXJldGFwcGluZy9z
dXJ2ZWlsbGFuY2UvZGlzY292ZXJ5L2FuYWx5c2lzIHB1cnBvc2VzIGlzIHF1aXRlIGRpZmZlcmVu
dC4gSWYgYSBicm93c2VyIHdlcmUgdG8gc3VwcG9ydCB0aGlzLCBJIHdvdWxkIHdhbnQgdG8gYXZv
aWQgdXNpbmcgc3VjaCBhIGJyb3dzZXIuDQoNCkluZHVzdHJ5IG9yIGNvcnBvcmF0ZSBzdGFuZGFy
ZHMgY291bGQgZGVmaW5lIGtleSBpbXBvcnQvZXhwb3J0L2VzY3JvdyBtZXRob2RzLCBhbmQgY2Vy
dGFpbmx5IFNXIHZlbmRvcnMgbWF5IGNob29zZSB0byBzdXBwb3J0IHRoZW0uDQpBdCB0aGUgSUVU
RiwgSU1ITywgd2UgY2FuIGJldHRlciBjb250cmlidXRlIGJ5IGZvY3VzaW5nIG9uIGtleSBwcm90
ZWN0aW9uLCBub24tZXhwb3J0YWJpbGl0eSBhbmQgYXR0ZXN0YXRpb24uDQoNCkNoZWVycywNCg0K
QW5kcmVpDQoNCkZyb206IENvbG0gTWFjQ8OhcnRoYWlnaCBbbWFpbHRvOmNvbG1AYWxsY29zdHMu
bmV0XQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgODo1NyBBTQ0KVG86IEFuZHJlaSBQ
b3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogU3RlcGhlbiBGYXJyZWxsIDxz
dGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsgPHRsc0BpZXRmLm9yZz4gPHRsc0BpZXRmLm9yZz4N
ClN1YmplY3Q6IFJlOiBbVExTXSBkYXRhY2VudGVyIFRMUyBkZWNyeXB0aW9uIGFzIGEgdGhyZWUt
cGFydHkgcHJvdG9jb2wNCg0KDQoNCk9uIFdlZCwgSnVsIDE5LCAyMDE3IGF0IDExOjQwIFBNLCBB
bmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9w
b3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSGkgQ29sbSwNCg0KDQogICogICBUb2RheSBicm93
c2VycyBkbyB0dXJuIG9uIHdpcmV0YXBwaW5nIHN1cHBvcnQgaW4gdGhlIG5vcm1hbCBjYXNlLiBU
aGVyZSdzIG5vdGhpbmcgdGhleSBjYW4gZG8gYWJvdXQgaXQsIGFuZCBpdCB3b3JrcyByaWdodCBu
b3cuDQpUaGlzIGlzIG5ld3MgdG8gbWU7IHdoaWNoIGJyb3dzZXJzIGRvIHRoaXMgKHNvIHRoYXQg
SSBjYW4gYXZvaWQgdXNpbmcgdGhlbSk/DQoNCkxpa2UgSSBzYWlkLCBhbGwgb2YgdGhlbS4gSSBk
b24ndCBrbm93IG9mIGEgc2luZ2xlIGJyb3dzZXIgdGhhdCBmb3JjZXMgREgtb25seSBhbmQgaW5z
aXN0cyBvbiB1bmlxdWUgREggcGFyYW1ldGVycyB0b2RheSwgYW5kIGl0IHdvdWxkbid0IGJlIHBy
YWN0aWNhbC4gIFNvIGlmIHdlJ3JlIGdvaW5nIHRvIHJlZmVyIHRvIGFuIG9wZXJhdG9yIHdobyBo
YXMgdGhlIHNlcnZlcidzIHByaXZhdGUga2V5IHVzaW5nIHRoZWlyIG93biBrZXkgdG8gZGVjcnlw
dCB0cmFmZmljIGFzIHdpcmUtdGFwcGluZywgdGhlbiBpbiB0aG9zZSB0ZXJtcyBjdXJyZW50bHkg
YWxsIGJyb3dzZXJzIGhhdmUgc3VwcG9ydCBmb3IgdGhhdCB0dXJuZWQgb24sIGFzIGl0J3MgcGFy
dCBvZiBleGlzdGluZyB2ZXJzaW9ucyBvZiBUTFMuDQoNCi0tDQpDb2xtDQo=

--_000_DM2PR21MB00910D605F561667F655D1698CA70DM2PR21MB0091namp_
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
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk
OjU1ODQ0NTc0ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzUwNjIzODk2O30NCkBsaXN0IGww
OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu
NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+
PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9
ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0
PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K
PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K
PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+QWgsIEkgZ2V0IHdoYXQgeW914oCZcmUgc2F5aW5nLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5E
SCBwYXJhbWV0ZXIgcmV1c2UgZm9yIHBlcmZvcm1hbmNlIHJlYXNvbnMgaXMgbm90IGEgZ29vZCB0
aGluZywgYW5kIGl0IGlzIG5vdCBzb21ldGhpbmcgcmVjb21tZW5kZWQgaW4gdGhlIFRMUyBSRkNz
LiBCdXQgb2ZmZXJpbmcgc3RhbmRhcmRpemVkIHdheXMgb2YgZXhwb3J0aW5nL2ltcG9ydGluZyBr
ZXlzDQogZm9yIDxzPndpcmV0YXBwaW5nL3N1cnZlaWxsYW5jZS9kaXNjb3ZlcnkvPC9zPmFuYWx5
c2lzIHB1cnBvc2VzIGlzIHF1aXRlIGRpZmZlcmVudC4gSWYgYSBicm93c2VyIHdlcmUgdG8gc3Vw
cG9ydCB0aGlzLCBJIHdvdWxkIHdhbnQgdG8gYXZvaWQgdXNpbmcgc3VjaCBhIGJyb3dzZXIuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPkluZHVzdHJ5IG9yIGNvcnBvcmF0ZSBzdGFuZGFyZHMgY291bGQgZGVmaW5l
IGtleSBpbXBvcnQvZXhwb3J0L2VzY3JvdyBtZXRob2RzLCBhbmQgY2VydGFpbmx5IFNXIHZlbmRv
cnMgbWF5IGNob29zZSB0byBzdXBwb3J0IHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BdCB0aGUgSUVURiwgSU1ITywgd2Ug
Y2FuIGJldHRlciBjb250cmlidXRlIGJ5IGZvY3VzaW5nIG9uIGtleSBwcm90ZWN0aW9uLCBub24t
ZXhwb3J0YWJpbGl0eSBhbmQgYXR0ZXN0YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPiBDb2xtIE1hY0PDoXJ0aGFpZ2ggW21haWx0bzpjb2xtQGFsbGNvc3RzLm5l
dF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAyMCwgMjAxNyA4OjU3IEFNPGJy
Pg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t
Jmd0Ozxicj4NCjxiPkNjOjwvYj4gU3RlcGhlbiBGYXJyZWxsICZsdDtzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllJmd0OzsgJmx0O3Rsc0BpZXRmLm9yZyZndDsgJmx0O3Rsc0BpZXRmLm9yZyZndDs8
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIGRhdGFjZW50ZXIgVExTIGRlY3J5cHRpb24g
YXMgYSB0aHJlZS1wYXJ0eSBwcm90b2NvbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdl
ZCwgSnVsIDE5LCAyMDE3IGF0IDExOjQwIFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1h
aWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Q
b3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow
aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+SGkgQ29sbSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9
ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzEiPg0KVG9kYXkgYnJvd3NlcnMgZG8gdHVybiBvbiB3aXJldGFwcGluZyBz
dXBwb3J0IGluIHRoZSBub3JtYWwgY2FzZS4gVGhlcmUncyBub3RoaW5nIHRoZXkgY2FuIGRvIGFi
b3V0IGl0LCBhbmQgaXQgd29ya3MgcmlnaHQgbm93LiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPlRoaXMgaXMgbmV3cyB0byBtZTsgd2hpY2ggYnJvd3NlcnMgZG8gdGhp
cyAoc28gdGhhdCBJIGNhbiBhdm9pZCB1c2luZyB0aGVtKT88L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+TGlrZSBJIHNhaWQsIGFsbCBvZiB0aGVtLiBJIGRvbid0IGtub3cgb2YgYSBzaW5nbGUg
YnJvd3NlciB0aGF0IGZvcmNlcyBESC1vbmx5IGFuZCBpbnNpc3RzIG9uIHVuaXF1ZSBESCBwYXJh
bWV0ZXJzIHRvZGF5LCBhbmQgaXQgd291bGRuJ3QgYmUgcHJhY3RpY2FsLiZuYnNwOyBTbyBpZiB3
ZSdyZSBnb2luZyB0byByZWZlciB0byBhbiBvcGVyYXRvciB3aG8gaGFzIHRoZSBzZXJ2ZXIncyBw
cml2YXRlIGtleSB1c2luZyB0aGVpcg0KIG93biBrZXkgdG8gZGVjcnlwdCB0cmFmZmljIGFzIHdp
cmUtdGFwcGluZywgdGhlbiBpbiB0aG9zZSB0ZXJtcyBjdXJyZW50bHkgYWxsIGJyb3dzZXJzIGhh
dmUgc3VwcG9ydCBmb3IgdGhhdCB0dXJuZWQgb24sIGFzIGl0J3MgcGFydCBvZiBleGlzdGluZyB2
ZXJzaW9ucyBvZiBUTFMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Db2xtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_DM2PR21MB00910D605F561667F655D1698CA70DM2PR21MB0091namp_--


From nobody Thu Jul 20 00:44:10 2017
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 E0684126557 for ; Thu, 20 Jul 2017 00:44:08 -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=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 SHyghHdjBZwT for ; Thu, 20 Jul 2017 00:44:05 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 5C3D113169C for ; Thu, 20 Jul 2017 00:44:04 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6K7g1i0021452; Thu, 20 Jul 2017 08:44:03 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=PTFACnupzT1EArRp2+TtC7zf0k6XaW1KA2upXwoYHOY=; b=XrjqdNYL4J9mo55ZyYAE3BS6zbwf/oB9x/BApRQS1RFshq0lP7tXQ4umYXhTZXqzlt6Y /TC9ue58C4kZHaqTPQmLgt0pbHzXNMPYsVv0A3Xob6wY4ulFdnuMiuJX+kfYZlE+urc7 G9GvIhfAW0ABVMC+63g3qSWa2zi/zllQGu9/6/BpXa0E0qIw3nJg4HQH7YePOikhak+B n1Ofr0tWD2QC8oKBUNd6UlMx0cZiuEf253g3kuD3sjMbvH8eicJmi/6CjXDmo8/xmCJm fBqmxKavfpMczD6uyuydFOT16VOnaQcppyaF7Us+Tdx27dlVs5d1C4ozjbE+H6R2tvLr Dg== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2bt1abw9nv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 08:44:03 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6K7fNfh016693; Thu, 20 Jul 2017 03:44:02 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2bqecv63ef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 03:44:02 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 00:44:00 -0700
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.1263.000; Thu, 20 Jul 2017 03:44:00 -0400
From: "Salz, Rich" 
To: Andrei Popov , =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJBchz4bEuxe60uC+rbloxSHrKJbn/OAgAACkwCAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB/KoCAAASqgIAACjOA//+/vOA=
Date: Thu, 20 Jul 2017 07:44:00 +0000
Message-ID: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.152.103]
Content-Type: multipart/alternative; boundary="_000_a5d8e3f6fdd24fae858ce5d1a4c3b36fusma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707200125
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707200125
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 07:44:09 -0000

--_000_a5d8e3f6fdd24fae858ce5d1a4c3b36fusma1exdag1mb1msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXTigJlzIGxpa2Ugc2F5aW5nIOKAnGFsbCBicm93c2VycyB0aGF0IHN1cHBvcnQgVExTIHN1cHBv
cnQgd2lyZXRhcHBpbmcgYmVjYXVzZSBvZiB0aGUgc3RhdGljIFJTQSBrZXkgZXhjaGFuZ2Uu4oCd
DQoNCkl04oCZcyBhIGxpdHRsZSBkaXNpbmdlbnVvdXMNCg==

--_000_a5d8e3f6fdd24fae858ce5d1a4c3b36fusma1exdag1mb1msgcorpak_
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
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K
CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp
b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1NTg0NDU3NDg7DQoJbXNvLWxpc3QtdGVt
cGxhdGUtaWRzOjM1MDYyMzg5Njt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs
Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3
Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt
c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt
Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl
dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww
OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE3
NzExOTg0OTI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjY5MzkxNDEwO30NCkBsaXN0IGwxOmxl
dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6
bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWlu
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wN
Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z
dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk
aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl
ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o
ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp
diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+SXTigJlzIGxpa2Ugc2F5aW5nIOKAnGFsbCBicm93c2VycyB0aGF0IHN1cHBvcnQgVExT
IHN1cHBvcnQgd2lyZXRhcHBpbmcgYmVjYXVzZSBvZiB0aGUgc3RhdGljIFJTQSBrZXkgZXhjaGFu
Z2Uu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkl04oCZcyBhIGxpdHRsZSBkaXNpbmdlbnVvdXM8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_a5d8e3f6fdd24fae858ce5d1a4c3b36fusma1exdag1mb1msgcorpak_--


From nobody Thu Jul 20 01:14:23 2017
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 E137212F24E for ; Wed, 19 Jul 2017 02:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ZdZ6g-UB241C for ; Wed, 19 Jul 2017 02:59:26 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 0FCAE129AD1 for ; Wed, 19 Jul 2017 02:59:26 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id i187so59638vke.4 for ; Wed, 19 Jul 2017 02:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=ba6dDZW2lsrKA4op8tLplREgoZC/av+9q/Zdtyu44ok=; b=lk2ss20lXZwBOb/WblJmlYBE3nabsY84fLl/PXb9/B3eGY6idDHcK7s5v9I8N+kPt+ PpKQgCGsjA4K2kUCQDP2A133HWGllWVAnfxZblqPC1odskqSWW9AtC+wJ7kqsI2FxyTO VS1Bp1PSNWBHT223ai0B2BYy594IeEjho53H4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ba6dDZW2lsrKA4op8tLplREgoZC/av+9q/Zdtyu44ok=; b=kXH90LoEOwJo9c/9zq2WEIQYcIsg9jadxVCuC+EH1x/1kVRh0efHSYPvzhnWMqWq89 J9/ofA8qmvBOrSW+7e5G9QgFR0R/j792jxh0UCDPs2pFYSiujxiO2WAiY5eHJg51tH9E 8v/PXR+C7XSehAaboVc3wqrlcIpV5qnQIp1xH4ILGB6hGG58Q2Ncuv6ly3ZrFmL9L9gx GoH6csnXG4TJm9SWFXzYRcEsiVwWKKlGg+YFV9p8beMwS5263mLFqAFs9GUCgcZpq38f Tz2EG9dnAJXMOBcz9bDE2wvkbDjJ0+PTSPtJT+EjW8ocWizXzSlFMbELdLbFeVEdNXrz M1gA==
X-Gm-Message-State: AIVw111jfWAsbrYCVLyLXQwp9/9d6/rfFP+mmD0g6Dy19BAd4xjeB0lR 1BNIXdsdwS1JMzLz8W1DkzAJKdauE/VG2jD5yA==
X-Received: by 10.31.52.74 with SMTP id b71mr1037553vka.18.1500458364279; Wed, 19 Jul 2017 02:59:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.72.137 with HTTP; Wed, 19 Jul 2017 02:59:03 -0700 (PDT)
From: Joseph Lorenzo Hall 
Date: Wed, 19 Jul 2017 11:59:03 +0200
Message-ID: 
To: "tls@ietf.org" , Sean Turner , Joseph Salowey 
Content-Type: multipart/alternative; boundary="001a114304f6cdb6030554a8af40"
Archived-At: 
X-Mailman-Approved-At: Thu, 20 Jul 2017 01:14:22 -0700
Subject: [TLS] notes for TLS WG Session 2 at IETF 99
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 19 Jul 2017 09:59:31 -0000

--001a114304f6cdb6030554a8af40
Content-Type: text/plain; charset="UTF-8"

are here and copied below (apologies for HTML, pad will disappear in 30
days):

https://pad.riseup.net/p/kZYK9HuZf85C

IETF99 TLS WG 2nd session (19-July-2017)

(all errors are JLH's)


   - Agenda/Administrivia


   - Exported Authenticators (EKR)


   - draft 21, hopefully close


   - WGLC #2 ended yesterday


   - Changes since -19


   - shorten HKDF labels


   - make post-handshake auth imp option


   - add per-ticket nonce, each ticket is assoc. w/ new PSK


   - new section 0-RTT anti-replay


   - Mandatory anti-replay (PR# 1059)


   - requires some bounded mechanism, but no specific technique


   - *Should we adopt this? Any objections?*


   - MT: every instance has to ensure that it only accepts the same 0-RTT
   once... which means an unbounded state problem


   - EKR: imp in NSS would guarantee "as 0-RTT"


   - ... "you must accept 0-RTT data once"


   - MT: We've got a window, only accept in that window, no guarantee
   either.


   - (No objections)


   - PR# 1053: Hashes that aren't hashes


   - HKDF-Expand-Label included a hash function that occasionally is not a
   hash.


   - essentially, SHA156(empty string) passed frequently to something else.


   - Probably worth saying "you can pass a null value, and not pass a hash"


   - EKR: any opinions?


   - MT: noticed while doing vectors draft, we do this once every
   handshake. I don't care.


   - EKR: there are two places that it can happen.


   - MT: still, I could care less.


   - Hannes: doesn't make sense to change since people have implemented
   like this.


   - RLB: I agree with MT and Hannes. Like the current mechanism, can opt
   with table of hash values.


   - Placeholder: NAT/Middleboxes


   - TLS 1.3 starting to show increased connection failure rates.


   - hard to meausre but 1-10%


   - Problem seems to be middleboxen


   - proposals are either make connection look more or less like TLS 1.2


   - Joe S: when will experiments complete?


   - EKR: depends on what we see. Will have data relatively soon, 4-8
   weeks. Takes a while to get into a release... but nightlies and betas give
   some indication of if it will work.


   - draft-ietf-tls-dnssec-chain-exstension (Melinda Shore)


   - completed WGLC on this draft. (
   https://www.ietf.org/proceedings/99/slides/slides-99-tls-sessb-dnssec-chain-validation-00.pdf)


   - excellent feedback so far.


   - (melinda summarizes changes)


   - record ordering (server canonicalization, yes or no?) No one came to
   mic.


   - use of _udp label for QUIC


   - Ted Hardie: reading of the draft is that UDP label used for DTLS and
   QUIC.


   - ...: you might have two different TLSA records, one for DTLS and one
   for QUIC. Maybe call it _quic?


   - Paul Woters: want to make sure we don't create a new plaintext
   reference


   - tell client imps how to handle unexpected/irrelevant/extraneous
   records?


   - Joe: we'll close on these remaining issues before reving the draft.


   - DTLS 1.3 (EKR)


   - first mentions something about exported authenticators:


   - certificate type extension goes in server [something] message.


   - odd thing is can have EE X.509 extension [somewhere] which is nuts.


   - Suggest we maintain the property where I change the entry in the table
   and [something]


   - Trying to keep 1.2 functionality.


   - Reminder: ACKs


   - implicit ACKs historically.


   - interacts badly with some TLS 1.3 features (like NST)


   - Solution: intro an explicit ACK


   - current proposal: SACK


   - kind of ripping off the QUIC structure.


   - MT: other thing with it being a handshake message is that it adds to
   the transcript record and that gets weird.


   - When should receivers ACK


   - supposed to ACK when you're not moving the state machine forward, when
   messages might have gotten lost, not for non-handshake messages


   - *If anyone thinks this is a bad strategy, please speak up.*


   - Joe S: how many people have had a chance to look at this? Not too many.


   - Janardhan Igengar: would be nice if this is not too complicated.


   - Reduced Header Format


   - MT: we currently have range between 20-64 reserved for us in this
   demux thing. We only use the lower half of the 20s... this uses the upper
   half of that range from 32 onwards. Can use that entire space and allows
   good distinguishing. Don't see us using too much more content types.


   - EKR: essentially the point of doing something different would be to
   have much longer sequence bits.


   - MT: not sure I've convinced Ian Swette [sp?]


   - SPT: thing about this is that the IoT will think we ned to make this
   smaller... this seems about as small as you can get to.


   - MT: one optimization we could make in addition, would be to remove the
   length.


   - EKR: but that would make the ACK'ing problematic (?)


   - MT: other way to do that is to do some internal framing... "I've got
   an ACK and some other stuff in here"


   - ... real challenge here are the cases when you're changing keys. would
   need internal lengths for those content types.


   - Connection IDs


   - have spent an enormous amount of time on this.


   - things behind NATs have problems rebinding.


   - also a serious privacy problem, none of the proposals I've seen are
   adequate let alone completely baked.


   - huge problem in the browser context, not so much in the mobile context.


   - proposal for DTLS is to kind of punt: have an optional but fixed
   Connection ID. Doesn't change across the connection.


   - We can add a new extension to negotiate functionality. Best scaling
   involves passing a token for each connection, yucky.


   - (EKR shows a proposal for a Connection ID extension)


   - IDs are used if a client offers and a server answers


   - Each side *sends* with the other's ID.


   - Happy to hear objections to this strategy.


   - Tobias G.: Connection ID is currently a very big problem in IoT space.


   - lake of entropy space in connection ID... 100k entropy doesn't work
   for IoT. need 10^6.


   - Need this ASAP.


   - Privacy concern is absolutely correct. Need to be able to reneg the
   client ID.


   - EKR: I've proposed reciever sets.


   - TG: want to avoid collision in the space... if the server controls
   that ID, you avoid collisions.


   - EKR: this design avoids that.


   - TG: can we do this in 1.3 please?


   - Hannes: data flows in two directions, similar to IPSEC.


   - Ted H: how does this impact RTCWeb?


   - EKR: wouldn't anticipate being able to use this for RTP.


   - ... unaware NAT rebinding typically assumes that one side has an open
   connection.


   - EKR: clarify, server picks ID for packets that come to him, client
   picks the IDs that come to them.


   - DKG: two questions: 1) IoT devices are unlikely to be mobile, do we
   have evidence for that? Seems like it's also active in things like
   vehicles; and 2) looks to me like a field for arbitrary metadata insertion
   in each packet and with long lengths, that looks like SPUD but we're not
   going to call it SPUD.


   - EKR: let me make my threat of violence clear, you need to solve it.


   - Yoav channeling Victor: why is this an assymetric connection ID scheme?


   - EKR: any symmetric scheme people want to pack the target into the
   connection ID. might not want to have a random ID.


   - MT: whole point of this is to mark packets so the reciever can get
   them to the right place.


   - MT: I think this is enough of an attractive target that I don't want
   to see this in DTLS 1.3, want to see that in a separate document... will
   address 1.2 as we can hit them at the same time.


   - EKR: structure of this is that we can easily add as an extension.


   - MT: if we just do this we don't get the ability to change over time,
   important for mobility. makes the arb metadata insertion better to deal
   with.


   - Christian Huitema: we need to do this right and not fast. Quick and
   dirty stuff is not going to cut it.


   - ... want to be able to reneg. probably want to make it optional so
   it's not in every packet. Want to have a constraint so that we don't get
   huge privacy holes.


   - EKR: what about this? Feel like QUIC got bogged down... proposal that
   got the most attention was an unencrypted connection ID. Should we build a
   fixed connection ID or something that constantly changes?


   - EKR can prepare a separate draft for this... may not change 1.2 as
   that's hard.


   - Jan I: [could not understand]


   - Ben Schwarts: in addition to privacy within a connection, if youre a
   client trying to keep track of a number of servers, it can be essentially a
   counter. May encourage clients to create a cross-connection... IDs are in a
   sequential range, these connections are all the same client. Would be nice
   to not do that.


   - EKR: this might require it being longer!


   - Hannes T: we wouldn't have a problem in IoT case if the NATs wouldn't
   exist or do rebinding or if the devices would more frequently send traffic.


   - ... vehicles will probably use cellular keeping the connex open.
   Always the chance to restart from scratch... connection ID wouldn't make a
   difference, need to start DTLS connection over again.


   - ... so sending a big ID is not going to help at all.


   - DKG (off mic): why have it then?


   - Hannes: we don't have it!


   - Tobias G: for these connections, mobile devices are in the use cases
   that I see. When you consider reneg, consider that main use case is devices
   with power constraints. So every RT etc. is very costly. Not reneg every
   time would be good. Would like things that we can tailor, customize.


   - Would rather have this really soon... problem is out there.


   - Would strongly urge the chairs to consider for 1.2


   - Jan I: could we constrain this to a smaller thing...


   - EKR: any number large enough to be useful will make DKG sad.


   - MT: any size that is useful, is useful (making the point that it's
   useful for good and bad)


   - SPT: will send an email for when DTLS will drop compared to TLS. Now
   is your chance to get to the mic.


   - Chair interrupt:


   - First thing: presenters are keeping it short and to the point. Hold
   points until after presentation.


   - Plenty of time for discussion.


   - Want to address both political and technical topics


   - *The main question: Is this subject something that the WG should
   consider? This = "passive decryption of traffic"*


   - *What technical solutions are available, becasue the WG gets change
   control if adopted.*


   - Impacts of TLS 1.3 on Eneterprise network operation (Steve Fenter,
   Matt Green, Russ Housely)


   - use cases:


   - wireshark PCAP decrypt


   - Fraud Monitoring


   - IDS/IPS


   - Malware Detection


   - Security incident response


   - Regulatory requirements


   - Layer 7 DDoS Protection


   - NPM/APM


   - When problem hits, no one knows where in this universe of 400 boxes
   the problem is.


   - I need packet level visibility in everywhere across these 400 boxes.


   - a month ago, got a problem in login failures and slowdowns.


   - sniffer guys called in to swoop in and save the day.


   - Many other guys getting called with severity 1 problems and need to
   decrypt


   - No way to identify the user bc CDN, decrypt the packets to find
   user_id or other elements.


   - one particular URL was giving 10s response time


   - Tier 2 load balancer, found the same symptom.... etc.


   - would need 5 proxies here and that doesn't scale... millions of
   dollars.


   - endpoint monitoring doesn't work, as you can't do full-scale pcap..
   because of NAT etc.


   - often need decrypted PCAP where there is no endpoint (e.g., firewalls
   don't often allow you to terminate)


   - tl;dr: a particular db call to a small single-threaded access table
   was slowing everything down.


   - If TLS 1.3 rolls out without static DH, severity 1 problems will drag
   out for weeks. Severity 2 will take months.


   - level of pain that enterprises aren't willing or able to handle.


   - if I have a problem that TLS causes, it's basically a DoS attack. *TLS
   1.3 is a DoS attack for us.*


   - Matt Green


   - This is not technically a problem: if you control the endpoints, you
   control the secrets.


   - How do you do this that doesn't harm the protocol?


   - possible solns:


   - endpoints being the servers, deliver session keys or MSs through an
   OOB channel. But # of keys can be very large.


   - have to deliver keys in a very timely manner, can't cache over much
   time


   - encode keys in band in the TLS protocol.


   - one option is to use a full extension and then include an in-bad
   inclusion.


   - unfortuantely, legacy systems don't include this functionality.


   - lots of different variants, some of very hard to detec.


   - Hovav: use DUAL-EC


   - Endpoints use (semi)-static keys


   - don't change the protocol, let's do something others can recognize.


   - No changes to 1.3


   - Easy to detect


   - Reduces FS, mitigated by key rotation.


   - Static DH draft


   - (Matt describes draft-green)


   - Security of Static DH


   - leave aside FS, it is cryptographically secure


   - FIPS 800-56A talks about using static DH. TLS 1.2 has DHS


   - concerns


   - easy to have imp flaws.


   - but easy to not affect most users.


   - Harm reduction


   - enterprises don't adopt 1.3, today they're using 1.2 with static RSA.


   - make some dramatic changes to endpoints to deliver session keys.


   - some really really bad ideas (won't go into)


   - Extensions (open to this)


   - pros: no significant protocol changes, well-understaood crypto,
   detectability.


   - Natl Cybersecurity Center of Excellence (Tim Polk)


   - Sponsor of a related draft.


   - NCCOE is all about implementation and adoption.


   - Have been hearing issues with meeting operation reqs for 1.3


   - Objective is to collab with industry, solve problems and get better
   security than we have today.


   - NCCoE will produce a proof of concept imp and a number of documents...
   want to prove that we can tighten up the life span of those keys that we
   are sharing in the enterprise.


   - Would produce an 1800 series practice guide that would say, "if you
   want to do what we did in the imp, do this."


   - would submit an IETF draft that showed what we did, what worked/did
   not, here are the key liftetimes that we think we can manage.


   - Proposal DOES NOT violate the IETF policy on wiretapping (Russ Housely)


   - RFC 2804 defines wiretapping and this is not that.


   - Want to get as much TLS nowledge from this WG as possible to produce
   as secure a thing as possible.


   - TINFOIL (Stephen Farrell)


   - This whole thing is a terrible idea, we shouldn't do it.


   - Stephen goes through the various arguments listed here:
   https://github.com/sftcd/tinfoil


   - not in scope for charter


   - could put TLS/DTLS 1.3 at risk


   - TLS is hard


   - 1.3 has undergone significant analysis so far, this has not


   - Static DH is not implementation robust


   - we have a case where law enforcement has tried to coerce a server
   operator to tap at TLS level


   - should in no way be a standards track document.


   - breaking TLS is not part of the WG charter.


   - ...


   - Question to group: should we document these arguments about breaking
   TLS?


   - Q&A:


   - PHB: agree with both sides. Problem here is coming from the PKI world,
   saw what happen to bluecoat and co. We didn't make WebPKI holes for them,
   so they blasted holes into it.


   - on the techincal side, don't like how you're doing it. I'd use a
   different DH share every time.


   - would like to have this such that if this makes it into the wild, it
   is not compat with legacy stuff


   - Paul Woters: want to quote RFC-someting-bis


   - talking about DH groups 22, 23, 24. 22 is must not. 23 and 24 will be
   must not soon, should not now.


   - Dan Harkins: there is IPR here out here from a past employer.


   - DKG: want to express disappointment with this draft.


   - export cipher suites was brought up. As recently as last year we've
   had problems with the fact that export cipher suites were standardized 20
   years ago.


   - The first time we see a problem with this might be soon... the last
   time we see a problem will be way way in the future.


   - Rich Salz: (applause)


   - I am torn between: prof. and personally I think this is not a good
   thing. Remember Dave Clarke's talk that we need to tilt the playing field
   for things that people use.


   - would like to see us wait two years for deployment exp. It's
   pre-mature. Let's revisit.


   - Darin Pettis:


   - We've been here before, part of a large financial organization. We've
   ditched RSA, we understand that.


   - We've explored technical options, and have not find a better way.


   - Roman from CMU:


   - didn't see discussion for security uses, esp. DFIR (incident response).


   - very key to do ad hoc instrumentation and this would help.


   - [Cisco business security group]:


   - Don't think security is served by seeing this as a black or white
   approach.


   - Reminds me of the old discussion of NATs.


   - Community is better served by ack'ing this problem and find a way to
   solve it.


   - Nalini Elkins:


   - There are very real problems from real people doing real things.


   - If you are hearing from real people that there are problems, behooves
   us to listen.


   - mnot:


   - this is not the first time we've seen this thing.


   - 2 years ago, proposals strongly made in HTTP.


   - We chose not to accept that work; reason is that HTTPS is explicitly a
   two-party protocol. Did not have a way to get the informed consent
   necessary to change the protocol.


   - You are changing the nature of the protocol pretty fundamentally.


   - Ted Hardie:


   - two points: FS is a feature of this protocol. This turns it off in
   certain contexts, not obvious to the end users that FS has been removed.
   Can't tell in the first connection if a key will be re-used. Need to have a
   way with features like this about 1) signal that it's being used; and 2)
   get agreements to use it from those communicating.


   - if it comes back with those changes, what's the domain analysis? Russ
   read us section 3 of RFC 2048, but not section 4, that says, "we're not
   taking a moral stand, but a technical stand". You MUST expect a technology
   to be used in places you might not expect. Analysis must take into account
   all of the domains of us.


   - Max Pala (cable labs):


   - agree with Stephen.


   - Most of the time this is a problem if your arch is outdated. No one
   will force you to do this... if you do deploy 1.3, should be conformant.


   - Ralph Droms:


   - Living the dream (laughter)


   - Want to emphasize keeping separate the fundamental abstract questions
   that are being discussed and the particular proposal that is on the table
   in this document.


   - Roland Dobbins:


   - Want to emphasize being able to troubleshoot and need visibility.


   - Often this needs to be on the wire.


   - They may face potential fines and liability if they don't take care of
   our information.


   - We don't want crypto that is proprietary or that is developed in
   smoke-filled rooms.


   - Jeff Hodges:


   - want to echo ralph and roland and a few other people.


   - There are enterprise needs here to do this thing.


   - We want to get to FS in the data center and we need a migration path
   that has been scrutinized by experts.


   - Christian Huitema:


   - want to support Stephen and Ted: take the Lavabit scenario.


   - A provider of a service is being compelled to turn on a feature so
   that someone can get their traffic.


   - This approach is very dangerous... you assume that you are using the
   same software in both DCs and on a server.


   - Don't like the feature that this is keeping the wire format unchanged.


   - We need a "big red flag" requirement so that this is only used in the
   DC.


   - Daniel Franke (Akamai):


   - like draft-00, not draft-01


   - draft-01 is standards track, not ok


   - Kenny Patterson:


   - There is nothing in the current draft that would force the rotation of
   keys.


   - suggestion: adopt the draft and force key rotation on each connection.


   - Sharon Goldberg (BU)


   - Want to support Stephen.


   - Not confied to DCs, do not support at all


   - Deb Cooley (NSA)


   - I believe if you take the draft here, you control the draft.


   - if you let this go underground, it will happen silently like what
   happened in the past with Static RSA.


   - Tara Tarikyee (OTF)


   - add voice to those disappointed in this draft.


   - there are a lot of people that depend on TLS for the practice of those
   rights.


   - *Questions the charis want answered (policy)*


   - *The main question: Is this subject something that the WG should
   consider?*


   - *this = "passive decryption of data center traffic"*


   - *subquestion: Is this wiretapping?*


   - Clarifying questions:


   - Stephen Farrell: don't believe that passive is correct here,
   draft-green allows active attacks. Allows the attacker to be active.


   - Ralph Droms: separate the solution in the draft from the mechanism.


   - Stephen: A, your saying your draft is broke.


   - ... not clear to me that there is any solution that allows passive
   that doesn't allow active.


   - DKG: we have considered this question for many weeks.


   - Lucy Lynch: take a hum first on whether or not the group should accept
   the draft and then take a more general hum.


   - Joe S: "decryption of data in the data center" ommiting the word
   "passive"


   - Hums: No clarity whatsoever. Seemed pretty even.


   - Stephen: want to take it to the list as to if the WG is interested in
   documenting reasons to not break 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 <%28202%29%20407-8825>, pgp:
https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

--001a114304f6cdb6030554a8af40
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


are here and copied below (apologies for HTML, pad will di=
sappear in 30 days):

https://pad.riseup.net/p/kZYK9HuZf85C

=

IETF99 TLS WG 2nd session (19-July-2017)

=

(all errors are JLH's)

  • Agenda/Ad=
ministrivia
  • Exported Authenticators (EKR)
  • draft 21, hopefully close
  • WGLC #2 ended yesterday
  • Changes sin=
ce -19
  • shorten HKDF labels
    make post-handshake auth imp option
  • add per-ticket nonce, each ticket is assoc. w/ new PSK<=
/li>
  • new section 0-RTT anti-replay
  • Mandatory anti-replay (PR# 1059)
  • =
requires some bounded mechanism, but no specific technique
=

  • Should we adopt this? =
Any objections?
  • MT: every instance has =
to ensure that it only accepts the same 0-RTT once... which means an unboun=
ded state problem
=

  • EKR: imp in NSS would guarant=
ee "as 0-RTT"
  • ... "you must acce=
pt 0-RTT data once"
  • MT: We've got a wi=
ndow, only accept in that window, no guarantee either.
  • (No objections)
  • PR# 1053: Hashes that=
 aren't hashes
  • HKDF-Expand-Label includ=
ed a hash function that occasionally is not a hash.
<=
div id=3D"gmail-magicdomid257749" class=3D"gmail-ace-line" style=3D"margin:=
0px;padding:0px;color:rgb(0,0,0);font-family:monospace;font-size:12px;font-=
style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-we=
ight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px;text-decoration-style:initi=
al;text-decoration-color:initial">
  • essentially, SHA156(empty string) passed frequently to something e=
lse.
  • Probably worth saying "you can pa=
ss a null value, and not pass a hash"
  • =
EKR: any opinions?
  • MT: noticed while doing ve=
ctors draft, we do this once every handshake. I don't care.
    • =

  • EKR: there are two places that it can happen.
    • <=
/ul>
  • MT: still, I could care less.
  • H=
annes: doesn't make sense to change since people have implemented like =
this.
  • RLB: I agree with MT and Hannes. Like the=
 current mechanism, can opt with table of hash values.
  • Placeholder: NAT/Middleboxes
  • TLS =
1.3 starting to show increased connection failure rates.
  • hard to meausre but 1-10%
  • Problem see=
ms to be middleboxen
  • proposals are either make =
connection look more or less like TLS 1.2
  • J=
oe S: when will experiments complete?
  • EKR: =
depends on what we see. Will have data relatively soon, 4-8 weeks. Takes a =
while to get into a release... but nightlies and betas give some indication=
 of if it will work.
  • draft-ietf-tls-dnssec-ch=
ain-exstension (Melinda Shore)
  • excellent feedback so far.
  • (melinda summa=
rizes changes)
  • record ordering (server canoni=
calization, yes or no?) No one came to mic.
    • use of _udp label for QUIC
    • =
Ted Hardie: rea=
ding of the draft is that UDP label used for DTLS and QUIC.
    • ...: you might have two different TLSA records, one for DT=
LS and one for QUIC. Maybe call it _quic?
    • P=
aul Woters: want to make sure we don't create a new plaintext reference=

    • tell client imps how to handle unexpected/i=
rrelevant/extraneous records?
    • =
Joe: we'll =
close on these remaining issues before reving the draft.
    • DTLS 1.3 (EKR)
    • first mentions so=
mething about exported authenticators:
    • cert=
ificate type extension goes in server [something] message.
    =

    • odd thing is can have EE X.509 extension [somewhere] which =
is nuts.
    • Suggest we maintain the property w=
here I change the entry in the table and [something]
    =

    • Trying to keep 1.2 functionality.
    • <=
ul class=3D"gmail-list-bullet3" style=3D"margin:0px 0px 0px 4.5em;padding:0=
px;list-style-type:square">
    • implicit ACKs historically=
.
    • interacts badly with some TLS 1.3 feature=
s (like NST)
    • Solution: intro an explicit AC=
K
    • current proposal: SACK
    • kind of ripping off the QUIC structure.
    =

    • MT: other thing with it being a handshake message is that it a=
dds to the transcript record and that gets weird.
    • When should receivers ACK
    • supposed to =
ACK when you're not moving the state machine forward, when messages mig=
ht have gotten lost, not for non-handshake messages
    <=
div id=3D"gmail-magicdomid257790" class=3D"gmail-ace-line" style=3D"margin:=
0px;padding:0px;color:rgb(0,0,0);font-family:monospace;font-size:12px;font-=
style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-we=
ight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px;text-decoration-style:initi=
al;text-decoration-color:initial">
    • If anyone thinks this is a ba=
d strategy, please speak up.
    • Joe S: how=
 many people have had a chance to look at this? Not too many.
      Janardhan Igengar: would be nice if this is not too com=
plicated.
    • Reduced Header Format
      MT: we currently have range between 20-64 reserved for =
us in this demux thing. We only use the lower half of the 20s... this uses =
the upper half of that range from 32 onwards. Can use that entire space and=
 allows good distinguishing. Don't see us using too much more content t=
ypes.
    • EKR: essentially the point of doing somet=
hing different would be to have much longer sequence bits.
    =

    • MT: not sure I've convinced Ian Swette [sp?]
      SPT: thing about this is that the IoT will think we ned=
 to make this smaller... this seems about as small as you can get to.
    • MT: one optimization we could make in addition, woul=
d be to remove the length.
    • EKR: but that would =
make the ACK'ing problematic (?)
    • MT: other =
way to do that is to do some internal framing... "I've got an ACK =
and some other stuff in here"
    • ... real cha=
llenge here are the cases when you're changing keys. would need interna=
l lengths for those content types.
    • Connection=
 IDs
    • have spent an enormous amount of time =
on this.
    • things behind NATs have problems r=
ebinding.
    • also a serious privacy problem, n=
one of the proposals I've seen are adequate let alone completely baked.=

    • huge problem in the browser context, not s=
o much in the mobile context.
    • proposal for =
DTLS is to kind of punt: have an optional but fixed Connection ID. Doesn=
9;t change across the connection.
    • We can ad=
d a new extension to negotiate functionality. Best scaling involves passing=
 a token for each connection, yucky.
    • (EKR s=
hows a proposal for a Connection ID extension)
    • IDs are used if a client offers and a server answers
    • Each side *sends* with the other's ID.
    • Happy to hear objections to this strategy.
    • Tobias G.: Connection ID is currently a very big problem in I=
oT space.
    • lake of entropy space in connection I=
D... 100k entropy doesn't work for IoT. need 10^6.
    • Need this ASAP.
    • Privacy concern is abso=
lutely correct. Need to be able to reneg the client ID.
    • EKR: I've proposed reciever sets.
    • =
TG: want to avoid collision in the space... if the server controls that ID,=
 you avoid collisions.
    • EKR: this design avoids =
that.
    • TG: can we do this in 1.3 please?<=
/li>
    • Hannes: data flows in two directions, similar to I=
PSEC.
    • Ted H: how does this impact RTCWeb?
    • EKR: wouldn't anticipate being able to use t=
his for RTP.
    • ... unaware NAT rebinding typicall=
y assumes that one side has an open connection.
    • EKR: clarify, server picks ID for packets that come to him, client pic=
ks the IDs that come to them.
    • DKG: two ques=
tions: 1) IoT devices are unlikely to be mobile, do we have evidence for th=
at? Seems like it's also active in things like vehicles; and 2) looks t=
o me like a field for arbitrary metadata insertion in each packet and with =
long lengths, that looks like SPUD but we're not going to call it SPUD.=

    • EKR: let me make my threat of violence clear, =
you need to solve it.
    • Yoav channeling Victo=
r: why is this an assymetric connection ID scheme?
    • EKR: any symmetric scheme people want to pack the target into the conne=
ction ID. might not want to have a random ID.
    • M=
T: whole point of this is to mark packets so the reciever can get them to t=
he right place.
  • MT: I think this is enough=
 of an attractive target that I don't want to see this in DTLS 1.3, wan=
t to see that in a separate document... will address 1.2 as we can hit them=
 at the same time.
    • EKR: structure of this is =
that we can easily add as an extension.
    • MT: if =
we just do this we don't get the ability to change over time, important=
 for mobility. makes the arb metadata insertion better to deal with.=

    • Christian Huitema: we need to do this right and n=
ot fast. Quick and dirty stuff is not going to cut it.
    • ... want to be able to reneg. probably want to make it optional so =
it's not in every packet. Want to have a constraint so that we don'=
t get huge privacy holes.
    • EKR: what about this?=
 Feel like QUIC got bogged down... proposal that got the most attention was=
 an unencrypted connection ID. Should we build a fixed connection ID or som=
ething that constantly changes?
    • =
EKR can prepare=
 a separate draft for this... may not change 1.2 as that's hard.=

    • Jan I: [could not understand]
    • Ben Schwarts: in addition to privacy within a connection, if y=
oure a client trying to keep track of a number of servers, it can be essent=
ially a counter. May encourage clients to create a cross-connection... IDs =
are in a sequential range, these connections are all the same client. Would=
 be nice to not do that.
    • EKR: this might requir=
e it being longer!
    • Hannes T: we wouldn'=
t have a problem in IoT case if the NATs wouldn't exist or do rebinding=
 or if the devices would more frequently send traffic.
    • ... vehicles will probably use cellular keeping the connex open. Al=
ways the chance to restart from scratch... connection ID wouldn't make =
a difference, need to start DTLS connection over again.
    • ... so sending a big ID is not going to help at all.
    • DKG (off mic): why have it then?
      • Tobias G: f=
or these connections, mobile devices are in the use cases that I see. When =
you consider reneg, consider that main use case is devices with power const=
raints. So every RT etc. is very costly. Not reneg every time would be good=
. Would like things that we can tailor, customize.
    • Would rather have this really soon... problem is out there.
      • =

    • Would strongly urge the chairs to consider for 1.2<=
/li>
    • Jan I: could we constrain this to a smaller thing.=
..
    • EKR: any number large enough to be useful w=
ill make DKG sad.
    =

    • MT: any size that is useful, =
is useful (making the point that it's useful for good and bad)
      =

    • SPT: will send an email for when DTLS will drop compa=
red to TLS. Now is your chance to get to the mic.
    • Chair interrupt:
    • First thing: presenters=
 are keeping it short and to the point. Hold points until after presentatio=
n.
    • Plenty of time for discussion.
      • =

      Want to address both political and technical topics
    • The main que=
stion: Is this subject something that the WG should consider? This =3D &quo=
t;passive decryption of traffic"
    • What technical solutions are available, b=
ecasue the WG gets change control if adopted.
    • Impacts of TLS 1.3 on Eneterprise network operation (Steve Fenter, Mat=
t Green, Russ Housely)
    • use cases:
      • =

      <=
li style=3D"margin:0px;padding:0px">wireshark PCAP decrypt
    • Fraud Monitoring
    • IDS/IPS
    • Malware Detection
    • Security=
 incident response
    • Regulatory requirements<=
/span>
    • Layer 7 DDoS Protection
    • NPM/APM
    • When problem hits, no on=
e knows where in this universe of 400 boxes the problem is.
    • I need packet level visibility in everywhere across these =
400 boxes.
    • a month ago, got a problem in =
login failures and slowdowns.
    • sniffer guys =
called in to swoop in and save the day.
    • Man=
y other guys getting called with severity 1 problems and need to decrypt
    • No way to identify the user bc CDN, decrypt=
 the packets to find user_id or other elements.
    • one particular URL was giving 10s response time
    =

    • Tier 2 load balancer, found the same symptom.... etc.
      would need 5 proxies here and that doesn't scal=
e... millions of dollars.
    • endpoint monitori=
ng doesn't work, as you can't do full-scale pcap.. because of NAT e=
tc.
    • often need decrypted PCAP where there is no=
 endpoint (e.g., firewalls don't often allow you to terminate)
      tl;dr: a particular db call to a small single-threa=
ded access table was slowing everything down.
    • If TLS 1.3 rolls out without static DH, severity 1 problems will drag out =
for weeks. Severity 2 will take months.
    • lev=
el of pain that enterprises aren't willing or able to handle.
    • if I have a problem that TLS causes, it's basica=
lly a DoS attack.=C2=A0TLS 1.3 is=
 a DoS attack for us.
    • Matt Green
      =

    • This is not technically a problem: if you control the=
 endpoints, you control the secrets.
    • How do y=
ou do this that doesn't harm the protocol?
    • =

      • endpoints being the serve=
rs, deliver session keys or MSs through an OOB channel. But # of keys can b=
e very large.
    • have to deliver keys in a very ti=
mely manner, can't cache over much time
    • encode keys in band in the TLS protocol.
    • o=
ne option is to use a full extension and then include an in-bad inclusion.<=
/span>
    • unfortuantely, legacy systems don't include=
 this functionality.
    • lots of different variants=
, some of very hard to detec.
    • Hovav: use DUAL-E=
C
    • Endpoints use (semi)-static keys
      don't change the protocol, let's do something o=
thers can recognize.
    • No changes to 1.3
      Easy to detect
    • Reduces FS, =
mitigated by key rotation.
    • Static DH draft
    • (Matt describes draft-green)
    • Security of Static DH
    • lea=
ve aside FS, it is cryptographically secure
    • FIPS 800-56A talks about using static DH. TLS 1.2 has DHS
    • concerns
    • <=
span class=3D"gmail-" style=3D"margin:0px;padding:1px 0px">easy to have imp=
 flaws.
    • but easy to not affect most users.=

    • Harm reduction
    • enterprises don't adopt 1.3, today they're using 1.2 with stati=
c RSA.
    • make some dramatic changes to endp=
oints to deliver session keys.
    • some really =
really bad ideas (won't go into)
    • Extens=
ions (open to this)
    • pros: no significant pr=
otocol changes, well-understaood crypto, detectability.
    • Natl Cybersecurity Center of Excellence (Tim Polk)
      • =

      Sponsor of a related draft.
      • Have been hearing issues with meeting operation reqs for 1.3
      <=
li style=3D"margin:0px;padding:0px">Objective is to collab with industry, solve problems a=
nd get better security than we have today.
    • NC=
CoE will produce a proof of concept imp and a number of documents... want t=
o prove that we can tighten up the life span of those keys that we are shar=
ing in the enterprise.
    • Would produce an 1800 =
series practice guide that would say, "if you want to do what we did i=
n the imp, do this."
    • would submit an IET=
F draft that showed what we did, what worked/did not, here are the key lift=
etimes that we think we can manage.
    • Proposal =
DOES NOT violate the IETF policy on wiretapping (Russ Housely)
      • <=
/ul>
    • RFC 2804 defines wiretapping and this is not that.=

      Want to get as much TLS nowledge from this WG as po=
ssible to produce as secure a thing as possible.
    • TINFOIL (Stephen Farrell)
    • =
This whole thin=
g is a terrible idea, we shouldn't do it.
    • not in scope for charter
    • could=
 put TLS/DTLS 1.3 at risk
    • TLS is hard
    • 1.3 has undergone significant analysis so far, t=
his has not
    • Static DH is not implementatio=
n robust
    • we have a case where law enforceme=
nt has tried to coerce a server operator to tap at TLS level
      should in no way be a standards track document.<=
/li>
    • breaking TLS is not part of the WG charter.=

    • ...
    • =
Question to gro=
up: should we document these arguments about breaking TLS?
    =

    • Q&A:
    • PHB: agree with both s=
ides. Problem here is coming from the PKI world, saw what happen to bluecoa=
t and co. We didn't make WebPKI holes for them, so they blasted holes i=
nto it.
    • on the techincal side, don't l=
ike how you're doing it. I'd use a different DH share every time.
    • would like to have this such that if this m=
akes it into the wild, it is not compat with legacy stuff
    <=
/div>
    • Paul Woters: want to quote RFC-someting-bis
    • talking about DH groups 22, 23, 24. 22 is must not. 23 and 24=
 will be must not soon, should not now.
    • Dan H=
arkins: there is IPR here out here from a past employer.
    • DKG: want to express disappointment with this draft.
    • export cipher suites was brought up. As recently as =
last year we've had problems with the fact that export cipher suites we=
re standardized 20 years ago.
    • The first tim=
e we see a problem with this might be soon... the last time we see a proble=
m will be way way in the future.
    • Rich Salz: (=
applause)
    • I am torn between: prof. and pers=
onally I think this is not a good thing. Remember Dave Clarke's talk th=
at we need to tilt the playing field for things that people use.
      =

    • would like to see us wait two years for deployment ex=
p. It's pre-mature. Let's revisit.
    • Da=
rin Pettis:
    • We've been here before, pa=
rt of a large financial organization. We've ditched RSA, we understand =
that.
    • We've explored technical options,=
 and have not find a better way.
    • Roman from C=
MU:
    • didn't see discussion for security =
uses, esp. DFIR (incident response).
    • very k=
ey to do ad hoc instrumentation and this would help.
    =

    • [Cisco business security group]:
    • =
Don't think security is served by seeing this as a black or white appro=
ach.
    • Reminds me of the old discussion of NA=
Ts.
    • Community is better served by ack'i=
ng this problem and find a way to solve it.
    • Nalini Elkins:
  • There are very real proble=
ms from real people doing real things.
    • If y=
ou are hearing from real people that there are problems, behooves us to lis=
ten.
    • mnot:
    • th=
is is not the first time we've seen this thing.
    <=
div id=3D"gmail-magicdomid257966" class=3D"gmail-ace-line" style=3D"margin:=
0px;padding:0px;color:rgb(0,0,0);font-family:monospace;font-size:12px;font-=
style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-we=
ight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px;text-decoration-style:initi=
al;text-decoration-color:initial">
    • 2 years ago, proposals strongly made in HTTP.
    • We chose not to accept that work; reason is that HTTPS is expl=
icitly a two-party protocol. Did not have a way to get the informed consent=
 necessary to change the protocol.
    • You are =
changing the nature of the protocol pretty fundamentally.
    <=
/div>
    • Ted Hardie:
    • two points: FS is =
a feature of this protocol. This turns it off in certain contexts, not obvi=
ous to the end users that FS has been removed. Can't tell in the first =
connection if a key will be re-used. Need to have a way with features like =
this about 1) signal that it's being used; and 2) get agreements to use=
 it from those communicating.
    • if it comes b=
ack with those changes, what's the domain analysis? Russ read us sectio=
n 3 of RFC 2048, but not section 4, that says, "we're not taking a=
 moral stand, but a technical stand". You MUST expect a technology to =
be used in places you might not expect. Analysis must take into account all=
 of the domains of us.
    • Max Pala (cable labs):=

    • agree with Stephen.
    =

    • Most of the time this is a problem if your arch is outdated. N=
o one will force you to do this... if you do deploy 1.3, should be conforma=
nt.
    • Ralph Droms:
    • Living the dream (laughter)
    • Want to emp=
hasize keeping separate the fundamental abstract questions that are being d=
iscussed and the particular proposal that is on the table in this document.=

    • Roland Dobbins:
    • Want to emphasize being able to troubleshoot and need visibility.
    • Often this needs to be on the wire.
      • =

      <=
li style=3D"margin:0px;padding:0px">They may face potential fines and liability if they do=
n't take care of our information.
    • We do=
n't want crypto that is proprietary or that is developed in smoke-fille=
d rooms.
    • Jeff Hodges:
    <=
div id=3D"gmail-magicdomid257984" class=3D"gmail-ace-line" style=3D"margin:=
0px;padding:0px;color:rgb(0,0,0);font-family:monospace;font-size:12px;font-=
style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-we=
ight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px;text-decoration-style:initi=
al;text-decoration-color:initial">
    • want to echo ralph and roland and a few other people.
      • <=
/ul>
      There are enterprise needs here to do this thing.
    • We want to get to FS in the data center and we n=
eed a migration path that has been scrutinized by experts.
    =

    • Christian Huitema:
    • want to su=
pport Stephen and Ted: take the Lavabit scenario.
    • A provider of a service is being compelled to turn on a feature so t=
hat someone can get their traffic.
    • This app=
roach is very dangerous... you assume that you are using the same software =
in both DCs and on a server.
    • Don't like=
 the feature that this is keeping the wire format unchanged.
      We need a "big red flag" requirement so that =
this is only used in the DC.
    • <=
span class=3D"gmail-" style=3D"margin:0px;padding:1px 0px">Daniel Franke (A=
kamai):
    • like draft-00, not draft-01=

    • draft-01 is standards track, not ok
    • Kenny Patterson:
    • There is=
 nothing in the current draft that would force the rotation of keys.=

    • suggestion: adopt the draft and force key rotatio=
n on each connection.
    • Sharon Goldberg (BU)
    • Want to support Stephen.
    • Not confied to DCs, do not support at all
    • Deb Cooley (NSA)
    • I believe if =
you take the draft here, you control the draft.
    • if you let this go underground, it will happen silently like what happ=
ened in the past with Static RSA.
    • Tara Tariky=
ee (OTF)
    • add voice to those disappointed in=
 this draft.
    • there are a lot of people that=
 depend on TLS for the practice of those rights.
    • Questions the charis want answered=
 (policy)
    • The main question: Is this subject something that the WG should consi=
der?
    • this =3D "passive decryption of data center traffic"
    • subquestion=
: Is this wiretapping?
    • Clarifying questio=
ns:
    • Stephen Farrell: don't believe that=
 passive is correct here, draft-green allows active attacks. Allows the att=
acker to be active.
    • Ralph Droms: separate the =
solution in the draft from the mechanism.
    • Steph=
en: A, your saying your draft is broke.
    • ... not=
 clear to me that there is any solution that allows passive that doesn'=
t allow active.
  • DKG: we have considered th=
is question for many weeks.
    • =
Lucy Lynch: tak=
e a hum first on whether or not the group should accept the draft and then =
take a more general hum.
    • Joe S: "decry=
ption of data in the data center" ommiting the word "passive"=
;
    • Hums: No clarity whatsoever. Seemed prett=
y even.
    • Stephen: want to take it to the list=
 as to if the WG is interested in documenting reasons to not break TLS.








    -- 
    Joseph Lorenzo Hall
    Chief Technologist, Center for Democrac=
y & Technology [https=
://www.cdt.org]
    1401 K ST NW STE 200, Washington DC 20005-3497
    e:=
 joe@cdt.org, p: 20=
2.407.8825, pgp: https://josephhall.org/gpg-key
    Fingerprint: 3CA2 8D7B 9F6D DB=
D3 4B10 =C2=A01607 5F86 6987 40A9 A871
    

--001a114304f6cdb6030554a8af40--


From nobody Thu Jul 20 01:54:48 2017
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 73449127735 for ; Thu, 20 Jul 2017 01:54:41 -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=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 lpm4KgD3taP8 for ; Thu, 20 Jul 2017 01:54:39 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 EDB20126B72 for ; Thu, 20 Jul 2017 01:54:38 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id o88so9949075pfk.3 for ; Thu, 20 Jul 2017 01:54:38 -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:cc; bh=rQJrflPVnBJUYz0YVW5rCvX1SP9PLbbwemlpHokPsL8=; b=lnM+AIdlyt8IpwI/ineotM4Nv6+e6lWNOFLyqKsNrug9R91mswcCXp1C24fezfxrQr mjilzGdyC/mUlvbyyxOM04jBq2ezEsezlClTOIznrHP12dZ5RRNnj8k0A9lLFzXyEHv0 lgtV9Jr8usNudQ76xk9f9KyPAEmzxjQNc9gT8iVNBgAVt2AY8MVRPHZLb9B692ziHgz5 1hKPluAbncbpFrkvBa6BHzdmFjuVmAuogIyO27t5ZRS+nv+BwDihG9aTLMz3TWDzx6qb gpWHr+V604x+TlcEwDxS064LHK/lwP+IQbzGP8v7+zIwpnja6lSGNBNgH+2xk8ylQ49j HiZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=rQJrflPVnBJUYz0YVW5rCvX1SP9PLbbwemlpHokPsL8=; b=c9qeOX2qzbV0DB7IJEAbjcOgNrb507RbWnzCxByQXF45DTg4E17ix0YlKI6QSWv3cE web/J/MAqey8Q498NcN673tzCHfpRxAlrSlFORZlEIcajtQb+fgVJhkvRrSXyCkdmI+2 SIbQVZUtU1IxTg1h0OX66BhM+fGY+N9tIyL0tMIuQ1DQPQ74esdwNJg/mewVYQ7qiz+j RBn/RwWu4M/5E++rNSkmIxLn1HFCyvy5pogif21j2BlJZRCY+LfvzpVa2520MzQYqolp q0o5XaG9WGNH/7PzhUwr85ifVdRRa34uzrWBIf5DX5hhFSmEIVrgx3a6jNOD79A6+ogN b4Uw==
X-Gm-Message-State: AIVw113///KYGUV5m8CqB2vzCun17OCXiAuf4ZllMR8uYqMMnACn0xPW hC9/MyAcbMDAteYCU+iVwMlryGtYCHZOPv0=
X-Received: by 10.84.231.15 with SMTP id f15mr3420816plk.253.1500540878580; Thu, 20 Jul 2017 01:54:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.137.2 with HTTP; Thu, 20 Jul 2017 01:54:18 -0700 (PDT)
From: Joseph Salowey 
Date: Thu, 20 Jul 2017 10:54:18 +0200
Message-ID: 
To: "saag@ietf.org" 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f403043607d809ff140554bbe6af"
Archived-At: 
Subject: [TLS] SAAG TLS working group report
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 08:54:41 -0000

--f403043607d809ff140554bbe6af
Content-Type: text/plain; charset="UTF-8"

TLS met on Monday afternoon and Wednesday morning.  For TLS 1.3, the
document has completed second working group last call.  There are ongoing
measurements to resolve the last open issue which we believe should
complete in 1-2 months.  Work on DTLS is going well and we expect it to go
to the IESG later this year.  DNSSEC chain validation and exported
authenticators work is nearing completion.   The group examined various
options for SNI encryption and decided to take it on as a working group
item.   We had presentations on the pros and cons of a  proposed mechanism
to decrypt TLS messages within the data center.   A hum indicated that
there was roughly equal support on both sides.  Therefore, well will
continue the discussion and it is unlikely that the draft will proceed in
its current form.

--f403043607d809ff140554bbe6af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    








    TLS met on Monday afternoon =
and Wednesday morning.=C2=A0 For TLS 1.3, the document has completed second=
 working group last call.=C2=A0 There are ongoing measurements to resolve t=
he last open issue which we believe should complete in 1-2 months.=C2=A0 Wo=
rk on DTLS is going well and we expect it to go to the IESG later this year=
.=C2=A0 DNSSEC chain validation and exported authenticators work is nearing=
 completion.=C2=A0 =C2=A0The group examined various options for SNI encrypt=
ion and decided to take it on as a working group item.=C2=A0 =C2=A0We had p=
resentations on the pros and cons of a =C2=A0proposed mechanism to decrypt =
TLS messages within the data center.=C2=A0 =C2=A0A hum indicated that there=
 was roughly equal support on both sides.=C2=A0 Therefore, well will contin=
ue the discussion and it is unlikely that the draft will proceed in its cur=
rent form.
    

    =C2=A0
    

--f403043607d809ff140554bbe6af--


From nobody Thu Jul 20 02:51:21 2017
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 0D7A413170E for ; Thu, 20 Jul 2017 02:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level: 
X-Spam-Status: No, score=-2.12 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, RCVD_IN_SORBS_SPAM=0.5] 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 Vh-ubrNcOKZw for ; Thu, 20 Jul 2017 02:51:18 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [212.227.20.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227C7131BFA for ; Thu, 20 Jul 2017 02:51:17 -0700 (PDT)
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 7F8615A7 for ; Thu, 20 Jul 2017 10:51:12 +0100 (BST)
Received: by mail-io0-f177.google.com with SMTP id g13so9664634ioj.5 for ; Thu, 20 Jul 2017 02:51:12 -0700 (PDT)
X-Gm-Message-State: AIVw110qPx0KsigSc7jTlFp+pOEIAsRVfxl5tYZAlowHq8U3/+glQcDq oJ5BqIac7CfWHjy0dCuKG3EP7Y9SbA==
X-Received: by 10.107.145.194 with SMTP id t185mr831851iod.16.1500544267308; Thu, 20 Jul 2017 02:51:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.37.2 with HTTP; Thu, 20 Jul 2017 02:51:06 -0700 (PDT)
From: Matt Caswell 
Date: Thu, 20 Jul 2017 10:51:06 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [TLS] SNI with early data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 09:51:20 -0000

I note in draft-21 the following text:

   When clients use a PSK obtained externally to send early data, then
   the following additional information MUST be provisioned to both
   parties:

   -  The TLS version number for use with this PSK

   -  The cipher suite for use with this PSK

   -  The Application-Layer Protocol Negotiation (ALPN) protocol
      [RFC7301], if any is to be used

   -  The Server Name Indication (SNI), if any is to be used

Later it says this:

   In order to accept early data, the server MUST have accepted a PSK
   cipher suite and selected the first key offered in the client's
   "pre_shared_key" extension.  In addition, it MUST verify that the
   following values are consistent with those negotiated in the
   connection during which the ticket was established.

   -  The TLS version number and cipher suite.

   -  The selected ALPN [RFC7301] protocol, if any.


The language about "during which the ticket was established" seems to
suggest that the following checks do not apply to an external PSK -
which I don't think is intended. Additionally there does not seem to
be a requirement on the server to check that the SNI is consistent.
So, there is a mandatory requirement for an external PSK to specify
the SNI, but no requirement on the server to check that it is actually
correct. Is this discrepancy intentional?

Matt


From nobody Thu Jul 20 02:58:05 2017
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 41F27131950 for ; Thu, 20 Jul 2017 02:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 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=-2.8, 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=isoc.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 mPkqWGBahP3K for ; Thu, 20 Jul 2017 02:58:01 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0064.outbound.protection.outlook.com [104.47.37.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FDC013157A for ; Thu, 20 Jul 2017 02:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=owcY8ui8o5r4QxeiVc6LXtxJ8yzo7A52gbhVEKqln3w=; b=KINXspeA2Hx8jHv3Cuu+e0BvD5M1HPUXN2LwDPQVeElyGuGohAuSOe0DWhQwCjY78AJcu7fsKBoq/lAaEUBcUNzOoyKIko0vW5lEtS7NAYk5VBS5v+yFFb2GjgRTXzh9iAkOrO2f8/dYf4M4t1YxP+RYCdf2gxcy2a2/rC2PuGw=
Received: from BN6PR06MB3395.namprd06.prod.outlook.com (10.174.235.153) by BN6PR06MB3396.namprd06.prod.outlook.com (10.174.235.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Thu, 20 Jul 2017 09:57:59 +0000
Received: from BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) by BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 09:57:59 +0000
From: Robin Wilton 
To: "tls@ietf.org" 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQHTAT0e/02z4cJx9Eqsiy9o8ZfN6w==
Date: Thu, 20 Jul 2017 09:57:59 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=isoc.org;
x-originating-ip: [178.255.154.107]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR06MB3396; 7:u9vRhNLOgVT9Ub+5DQiFrX1O9nfKIgFNooV/MBZPLpiwt1oNyIvtAONps2bVFkWtmlz7XAPiIP0xHh6Doi/XebKBKyQVStRF5kW/OyTpZwv8eTQ+kZF6jpEOpTqKzJu8oiqU8UnqrFzV+W0Qw0FqadimjubpUps++YRQwVVG192UcfT+ZdgwSfG1Q+nmBbvJTUzS8YrH/WAyCHFv89C2QtedZJQ+p7t6oVky4o7jcHrJdFVSosr2oQ1Mx4Gb5vCsj9+br1l6fWQOc7sd8jiVhrwBy68G9yJtYz6L17ao2+w/fXhUscymkMy4jNZ47YUZLydGhTV7/2TqspvkvM+LQN0+UB65nGStOKYM/peswHgZ5ivklaoLmygrpFMxq6RC9x95YGqfmuif4eD6XCpVUy70ASxl1LGfHr94cXqOvf3tHIuy9sj+Zmtepa3guncGbuxJYs6fiF4tSSulCqEOX9BkClpJNavv6OFkHBaPjz1PpHD37VubfiAu3eZyWsMKwBtCa7X7LrtnT/mmCDabpCT2rYSXBcWmkbQU8Rgi9TofWv17w4K8L0Hm5eUl7V0UfrzU2sCjvvOhROW/NQCfpK39nSm7oIm8hteis2yLEWtDNZt8ES0Ayb+pDuRYuLqrE6dbxvIGetHArEsK5WS/bnqpgqn4GZ8aJEeOyG51mOolkSYSQW/VlUb5+P1AatH1fWx3cEKpYuZ0vjhdRP+Z+O4QE2pI3pDKSwcJot5SIH8HzXUX5PaF7DDvzUIJXSXvhSVNfErEKe1u6dhUSM3PQ9PuKVBl2g1kocNXGHIz5uE=
x-ms-office365-filtering-correlation-id: 58b1124c-5820-4fb4-2b9e-08d4cf55cdc6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR06MB3396; 
x-ms-traffictypediagnostic: BN6PR06MB3396:
x-exchange-antispam-report-test: UriScan:(158342451672863)(236129657087228)(48057245064654); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR06MB3396; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR06MB3396; 
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(39400400002)(39410400002)(39450400003)(6506006)(2501003)(3660700001)(77096006)(478600001)(2906002)(8936002)(74316002)(8676002)(81166006)(1730700003)(86362001)(6606003)(6116002)(189998001)(6916009)(7736002)(229853002)(3846002)(6436002)(5660300001)(102836003)(7696004)(25786009)(3280700002)(53936002)(55016002)(33656002)(50986999)(561944003)(66066001)(19627405001)(2351001)(5640700003)(38730400002)(54896002)(54356999)(14454004)(110136004)(2900100001)(9686003)(99286003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB3396; H:BN6PR06MB3395.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR06MB3395E47F181D02D5772EEC81BFA70BN6PR06MB3395namp_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 09:57:59.5225 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3396
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 09:58:03 -0000

--_000_BN6PR06MB3395E47F181D02D5772EEC81BFA70BN6PR06MB3395namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Apologies for not replying "in thread" on this occasion, for noob reasons..=
. but here's the specific comment from Russ that I wanted to respond to:


________________________________

The hum told us that the room was roughly evenly split.  In hind sight, I w=
ish the chairs had asked a second question.  If the split in the room was d=
ifferent for the second question, then I think we might have learned a bit =
more about what people are thinking.

If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?

I was listening very carefully to the comments made by people in line.  Cle=
arly some people would hum for "no" to the above question, but it sounded l=
ike many felt that this would be a significant difference.  It would ensure=
 that both server and client explicitly opt-in, and any party observing the=
 handshake could see the extension was included or not.

Russ


=3D=3D=3D=3D


Stephen Farrell articulated a concern with that approach - namely, that if =
we are relying on a setting that is meant to ensure both parties must be aw=
are that static DH is in use, then a bad actor would find ways to suppress =
that notification. In your proposal, Russ, the notification mechanism would=
 take the form of an extension... so I think we would need to understand wh=
at the failsafe is, for instance if that extension is disabled, or not pres=
ent, in a given deployment of TLS.


There's an implicit assumption about the threat model, too, which I just wa=
nt to call out. The assumption is that a bad actor would suppress the notif=
ication so that the client is not aware that static DH is in use. For compl=
eteness, should we also consider whether there are attacks in which it's th=
e *server* whose notification is suppressed? (I can't think of such an atta=
ck, off the top of my head, but then, that's probably why I'm not a hacker.=
 ;^, )


Best wishes,

Robin

--_000_BN6PR06MB3395E47F181D02D5772EEC81BFA70BN6PR06MB3395namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








    

    Apologies for not replying "in thread" on this occasion, for n=
oob reasons... but here's the specific comment from Russ that I wanted to r=
espond to:
    


    

    

    

    

    The hum told us that the room was roughly evenly split.  In hind sight=
, I wish the chairs had asked a second question.  If the split in the room =
was different for the second question, then I think we might have learned a=
 bit more about what people are thinking.=0A=
=0A=
If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?=0A=
=0A=
I was listening very carefully to the comments made by people in line.  Cle=
arly some people would hum for "no" to the above question, but it=
 sounded like many felt that this would be a significant difference.  It wo=
uld ensure that both server and client explicitly opt-in, and any party obs=
erving the handshake could see the extension was included or not.=0A=
=0A=
Russ=0A=

    

    

    =3D=3D=3D=3D
    


    

    

    Stephen Farrell articulated a concern with that approach - namely, that =
if we are relying on a setting that is meant to ensure both parties must be=
 aware that static DH is in use, then a bad actor would find ways to suppre=
ss that notification. In your proposal,
 Russ, the notification mechanism would take the form of an extension... so=
 I think we would need to understand what the failsafe is, for instance if =
that extension is disabled, or not present, in a given deployment of TLS.


    

    

    There's an implicit assumption about the threat model, too, which I just=
 want to call out. The assumption is that a bad actor would suppress the no=
tification so that the client is not aware that static DH is in use. For co=
mpleteness, should we also consider
 whether there are attacks in which it's the *server* whose notification is=
 suppressed? (I can't think of such an attack, off the top of my head, but =
then, that's probably why I'm not a hacker. ;^, )
    


    

    

    Best wishes,
    

    Robin  
    

    

    



--_000_BN6PR06MB3395E47F181D02D5772EEC81BFA70BN6PR06MB3395namp_--


From nobody Thu Jul 20 03:42:10 2017
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 39E48131A86 for ; Thu, 20 Jul 2017 03:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Gqbg4TaDrgm for ; Thu, 20 Jul 2017 03:42:07 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4F7129AD1 for ; Thu, 20 Jul 2017 03:42:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CA66CBE39; Thu, 20 Jul 2017 11:42:05 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnPNPM5o12MR; Thu, 20 Jul 2017 11:42:04 +0100 (IST)
Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 31CC2BE2D; Thu, 20 Jul 2017 11:42:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500547324; bh=W9UWHfQD+Lm2NG3NND5oFCwwja2apA8CZPBub0b5aKI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=4fWotjAAS2X8eGsp8y6u/BCxdr+CV3PC7BKi7kBzs/Jf6lwcoZ4MCBj7nCBWmR9aK +C+hpkuf/zH/R+Oc62iyQZOvWfThitKQFnUgRLsgsJSUMbwRu5BRysUYxKtlMGpRPp qDETdErEiXbBOHIlbf//ysasFqdfEs+2jpQr+/iE=
To: Joseph Salowey 
Cc: "tls@ietf.org" 
References: 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Thu, 20 Jul 2017 11:42:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LIbv2jFQF8Ix3l879wV2xJOdAaECN0IlL"
Archived-At: 
Subject: Re: [TLS] SAAG TLS working group report
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 10:42:09 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--LIbv2jFQF8Ix3l879wV2xJOdAaECN0IlL
Content-Type: multipart/mixed; boundary="CI1QcEtTBfReF9vXwfqKewtCxnS3U8a25";
 protected-headers="v1"
From: Stephen Farrell 
To: Joseph Salowey 
Cc: "tls@ietf.org" 
Message-ID: 
Subject: Re: [TLS] SAAG TLS working group report
References: 
In-Reply-To: 

--CI1QcEtTBfReF9vXwfqKewtCxnS3U8a25
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Hi Joe,

On 20/07/17 09:54, Joseph Salowey wrote:
> We had presentations on the pros and cons of a  proposed mechanism
> to decrypt TLS messages within the data center.   A hum indicated that
> there was roughly equal support on both sides.  Therefore, well will
> continue the discussion and it is unlikely that the draft will proceed =
in
> its current form.

Thanks for that. Having chatted with Russ also, it seems like
I ought change the tinfoil repo from describing draft-green as
a current proposal to one of our long list of failed proposals.
If that's right, that's good IMO.

I guess I'll leave a watch-this-space marker in "current proposals"
for the next one;-(

Cheers,
S.



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


--CI1QcEtTBfReF9vXwfqKewtCxnS3U8a25--

--LIbv2jFQF8Ix3l879wV2xJOdAaECN0IlL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZcIj7AAoJEC88hzaAX42iCuEH/3yGFPTm5yPpC8VQuNBO+aqW
+rcWT9+8BDup1q2Ggft5tySC1wyicXZpj6/J8ykrYZDhTdPj8rVkkxO4DqflpL78
L/j5eJ7MWLlcfi6rMBsZyTxe8U8FdswoBSSFv0DmGnzCLKkmJd0BLYO6rIgJOK3D
CEiQpSvvHO5U9bOXqajiVDK+MfYVW3RjN51nSbakxIo6Mve59f5dU8v18VThre0n
hSGG1SFkhEm8Q2im2vnDHrPAfK0uU1vRCXBW4VJ5ph/nb0T+FV4ldvOZVOzXtI+S
vA0/UjVUUtFbTRnqcnMYyK/RhibLbrLWwNkvlJBY+YoM6AM0yn22ZSpLBRAklG0=
=LjCj
-----END PGP SIGNATURE-----

--LIbv2jFQF8Ix3l879wV2xJOdAaECN0IlL--


From nobody Thu Jul 20 04:04:00 2017
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 BB043131A8C for ; Thu, 20 Jul 2017 04:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 3xMxAa0NR7Ak for ; Thu, 20 Jul 2017 04:03:56 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17B6131BFA for ; Thu, 20 Jul 2017 04:03:55 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG01.res.venafi.com (10.1.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 05:03:53 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 05:03:53 -0600
From: Paul Turner 
To: Robin Wilton , "tls@ietf.org" 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQGZY5pvJzH4JA3szzi/CxpFoIjfXaLPvrHg
Date: Thu, 20 Jul 2017 11:03:53 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.50.120.225]
Content-Type: multipart/alternative; boundary="_000_bbd5d287b07d4e5aac7cbd3add41da03venaficom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 11:03:58 -0000

--_000_bbd5d287b07d4e5aac7cbd3add41da03venaficom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: tls@ietf.org
Subject: Re: [TLS] Is there a way forward after today's hum?


Apologies for not replying "in thread" on this occasion, for noob reasons..=
. but here's the specific comment from Russ that I wanted to respond to:



________________________________

The hum told us that the room was roughly evenly split.  In hind sight, I w=
ish the chairs had asked a second question.  If the split in the room was d=
ifferent for the second question, then I think we might have learned a bit =
more about what people are thinking.



If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?



I was listening very carefully to the comments made by people in line.  Cle=
arly some people would hum for "no" to the above question, but it sounded l=
ike many felt that this would be a significant difference.  It would ensure=
 that both server and client explicitly opt-in, and any party observing the=
 handshake could see the extension was included or not.



Russ

=3D=3D=3D=3D



Stephen Farrell articulated a concern with that approach - namely, that if =
we are relying on a setting that is meant to ensure both parties must be aw=
are that static DH is in use, then a bad actor would find ways to suppress =
that notification. In your proposal, Russ, the notification mechanism would=
 take the form of an extension... so I think we would need to understand wh=
at the failsafe is, for instance if that extension is disabled, or not pres=
ent, in a given deployment of TLS.



There's an implicit assumption about the threat model, too, which I just wa=
nt to call out. The assumption is that a bad actor would suppress the notif=
ication so that the client is not aware that static DH is in use. For compl=
eteness, should we also consider whether there are attacks in which it's th=
e *server* whose notification is suppressed? (I can't think of such an atta=
ck, off the top of my head, but then, that's probably why I'm not a hacker.=
 ;^, )



Best wishes,

Robin



Robin,



With respect to your threat concerns, can you be more clear about the threa=
ts you're considering? Here are a few things that come to mind:



  1.  TLS Server has all of the decrypted data and can provide that to a th=
ird party (whether compelled or otherwise) without any indication to the TL=
S client. This seems true TLS 1.3 today.
  2.  TLS Server has their ephemeral DH keys and session keys and can provi=
de them to a third party without any indication to the TLS client. This see=
ms true with TLS 1.3 today.
  3.  TLS Server can create a TLS server implementation that uses static DH=
 keys and provide them to a third party. The client can use methods to dete=
ct this (though there are measures and countermeasures here). This is true =
seems TLS 1.3 today.
  4.  TLS Client has all of the decrypted data and can provide that to a th=
ird party (whether compelled or otherwise) without any indication to the TL=
S server. This seems true in TLS 1.3 today.
  5.  TLS Client has their ephemeral DH keys and session keys and can provi=
de them to a third party without any indication to the TLS server. This see=
ms true with TLS 1.3 today.



I believe Russ was outlining a method where an extension would be added to =
TLS 1.3 that would provide for delivery of a decryption key to a third part=
y during the handshake (correct me if I got that wrong, Russ). Because it w=
ould be during the handshake, it would seem to be visible to the TLS  Clien=
t-in fact, the client would have to include the extension to begin with. If=
 the TLS client saw the extension and did not consent, it could abort the c=
onnection. If the TLS Server were attempting to provide access to the excha=
nged data to a third party, it would seem they could use 1, 2, or 3 above a=
nd not have to go to the trouble of attempting to subvert the mechanism tha=
t Russ proposes (and others have previously proposed).



Can you clarify?



Paul

--_000_bbd5d287b07d4e5aac7cbd3add41da03venaficom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









    

     
    

     
    

    

    

    From: TLS=
 [mailto:tls-bounces@ietf.org]
On Behalf Of Robin Wilton
    
Sent: Thursday, July 20, 2017 05:58
    
To: tls@ietf.org
    
Subject: Re: [TLS] Is there a way forward after today's hum?
    

    

    

     
    

    

    Apologies for not replying "in thread" =
on this occasion, for noob reasons... but here's the specific comment from =
Russ that I wanted to respond to:
    

     
    

    


    

    

    The hum told us=
 that the room was roughly evenly split.  In hind sight, I wish the ch=
airs had asked a second question.  If the split in the room was differ=
ent for the second question, then I think we might have learned a bit more =
about what people are thinking.
    

     
    

    If a specificat=
ion were available that used an extension that involved both the client and=
 the server, would the working group adopt it, work on it, and publish it a=
s an RFC?
    

     
    

    I was listening=
 very carefully to the comments made by people in line.  Clearly some =
people would hum for "no" to the above question, but it sounded l=
ike many felt that this would be a significant difference.  It would e=
nsure that both server and client explicitly opt-in, and any party observin=
g the handshake could see the extension was included or not.
    

     
    

    Russ=

    

    =3D=3D=3D=3D
    

     
    

    Stephen Farrell articulated a concern with that a=
pproach - namely, that if we are relying on a setting that is meant to ensu=
re both parties must be aware that static DH is
 in use, then a bad actor would find ways to suppress that notification. In=
 your proposal, Russ, the notification mechanism would take the form of an =
extension... so I think we would need to understand what the failsafe is, f=
or instance if that extension is
 disabled, or not present, in a given deployment of TLS.<=
/p>

     
    

    There's an implicit assumption about the threat m=
odel, too, which I just want to call out. The assumption is that a bad acto=
r would suppress the notification so that the
 client is not aware that static DH is in use. For completeness, should we =
also consider whether there are attacks in which it's the *server* whose no=
tification is suppressed? (I can't think of such an attack, off the top of =
my head, but then, that's probably
 why I'm not a hacker. ;^, )
    

     
    

    Best wishes,
    

    Robin 

    

     
    

    Robin,
    

     
    

    With respect to your threat concerns, can you be more clear about the t=
hreats you’re considering? Here are a few things that come to mind:
    

     
    

      

    1. TLS Server has all o=
f the decrypted data and can provide that to a third party (whether compell=
ed or otherwise) without any indication to the
 TLS client. This seems true TLS 1.3 today.
    2. TLS Server has their ephemera=
l DH keys and session keys and can provide them to a third party without an=
y indication to the TLS client. This
 seems true with TLS 1.3 today.
    3. TLS Server can create a TLS server implem=
entation that uses static DH keys and provide them to a third party. The cl=
ient can use methods to detect
 this (though there are measures and countermeasures here). This is true se=
ems TLS 1.3 today.
    4. TLS Client has all of the decrypted data and can provi=
de that to a third party (whether compelled or otherwise) without any indic=
ation to the
 TLS server. This seems true in TLS 1.3 today.
    5. TLS Client has their ephem=
eral DH keys and session keys and can provide them to a third party without=
 any indication to the TLS server. This
 seems true with TLS 1.3 today.
    

     
    

    I believe Russ was outlining a method where an extension would be added=
 to TLS 1.3 that would provide for delivery of a decryption key to a third =
party during the handshake (correct me if I
 got that wrong, Russ). Because it would be during the handshake, it would =
seem to be visible to the TLS  Client—in fact, the client would =
have to include the extension to begin with. If the TLS client saw the exte=
nsion and did not consent, it could abort the
 connection. If the TLS Server were attempting to provide access to the exc=
hanged data to a third party, it would seem they could use 1, 2, or 3 above=
 and not have to go to the trouble of attempting to subvert the mechanism t=
hat Russ proposes (and others have
 previously proposed). 
    

     
    

    Can you clarify?
    

     
    

    Paul
    

    

    



--_000_bbd5d287b07d4e5aac7cbd3add41da03venaficom_--


From nobody Thu Jul 20 04:25:37 2017
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 02C621270B4 for ; Thu, 20 Jul 2017 04:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 nQK4U2ty3WVV for ; Thu, 20 Jul 2017 04:25:31 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 F36BD131C03 for ; Thu, 20 Jul 2017 04:25:28 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id y129so13538572pgy.4 for ; Thu, 20 Jul 2017 04:25:28 -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=P3upmT5aNBLExztsDhc0PRR5Qh2kJZqJA00vDCHA4Yw=; b=Wgxza11vPag7Xl7VzQFchGuyVE9sMGIFcTksebgMuhsM/k0HqyvH7j9zss3v92WQ3f SiBBm287hQHReV1dQTOYYElJnjsUW9dehxi4lDbmqHtVfHUO25Z95sUK0S5QDFSZNZB5 amwQDi3uX/ItaQyiGmu71b1/txdzIzDU7rQ9pchlZoyTf2xtBmpu6bCnjUEC/dJlydhT 9yqe1j0DEPQoz7rWosIf3yk1jpv4ZaB+YICL+eXv6+3A64+FayEog9+TJxe0xfbgY6CC s47Qj2RBtJmbLM2h1kKjeQ3abvWjs8J0fBNKjBhQFub+7Unr8eyLzwDj5JI1yMgQvadc J9lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P3upmT5aNBLExztsDhc0PRR5Qh2kJZqJA00vDCHA4Yw=; b=Wyrkh5nSZwDpO2a/HXM5TFlezxumJYz2Jfu6OXoQRrccOnyPb1tvam4yMC1k8Bmzl7 bH5ElnnwyWAoAa1TlBq9W1QBR3kH52/JkvW6gvg6ibnniFi+WSyWhFfX93Aa7mfwBUGI kIAsY9lIy2/MiVkpRoF4JPKKYvLuNfKEoB7x2ZRwu6un2Dd6WdfdXDgVcpfZvqQ9MBhW oG5Grpo7mpkYXa4vuyrO/cdGVBIAhWUKLmIlxUA5NRnkcHbF4FAS06y+tqM3AlIRaEMl RYfpWCt5Vw8NhiDjlhvqXcrqM81rZiA8eJkeNaf+CzFAvAyiGKbrtKfzjaWLwqfTPbg4 00hQ==
X-Gm-Message-State: AIVw113pEwM1rPR0kIaoQxGluU8W9eIYn6i/e99RoP6LCh3rciNwEeut HopuXxkho0PUyvcZkZeVpC/B6M+tP83Y
X-Received: by 10.99.43.5 with SMTP id r5mr3461642pgr.135.1500549928429; Thu, 20 Jul 2017 04:25:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 04:25:27 -0700 (PDT)
Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 04:25:27 -0700 (PDT)
In-Reply-To: 
References:  
From: Ted Lemon 
Date: Thu, 20 Jul 2017 13:25:27 +0200
Message-ID: 
To: Paul Turner 
Cc: Robin Wilton , "" 
Content-Type: multipart/alternative; boundary="001a1146e2e073c5670554be01ad"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 11:25:34 -0000

--001a1146e2e073c5670554be01ad
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Paul, it would be trivial to normal that exchange to conceal from the
client that a static key is being used. No software mods required on either
end: just in the middle.

On Jul 20, 2017 1:04 PM, "Paul Turner"  wrote:

>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Apologies for not replying "in thread" on this occasion, for noob
> reasons... but here's the specific comment from Russ that I wanted to
> respond to:
>
>
> ------------------------------
>
> The hum told us that the room was roughly evenly split.  In hind sight, I=
 wish the chairs had asked a second question.  If the split in the room was=
 different for the second question, then I think we might have learned a bi=
t more about what people are thinking.
>
>
>
> If a specification were available that used an extension that involved bo=
th the client and the server, would the working group adopt it, work on it,=
 and publish it as an RFC?
>
>
>
> I was listening very carefully to the comments made by people in line.  C=
learly some people would hum for "no" to the above question, but it sounded=
 like many felt that this would be a significant difference.  It would ensu=
re that both server and client explicitly opt-in, and any party observing t=
he handshake could see the extension was included or not.
>
>
>
> Russ
>
> =3D=3D=3D=3D
>
>
>
> Stephen Farrell articulated a concern with that approach - namely, that i=
f
> we are relying on a setting that is meant to ensure both parties must be
> aware that static DH is in use, then a bad actor would find ways to
> suppress that notification. In your proposal, Russ, the notification
> mechanism would take the form of an extension... so I think we would need
> to understand what the failsafe is, for instance if that extension is
> disabled, or not present, in a given deployment of TLS.
>
>
>
> There's an implicit assumption about the threat model, too, which I just
> want to call out. The assumption is that a bad actor would suppress the
> notification so that the client is not aware that static DH is in use. Fo=
r
> completeness, should we also consider whether there are attacks in which
> it's the *server* whose notification is suppressed? (I can't think of suc=
h
> an attack, off the top of my head, but then, that's probably why I'm not =
a
> hacker. ;^, )
>
>
>
> Best wishes,
>
> Robin
>
>
>
> Robin,
>
>
>
> With respect to your threat concerns, can you be more clear about the
> threats you=E2=80=99re considering? Here are a few things that come to mi=
nd:
>
>
>
>    1. TLS Server has all of the decrypted data and can provide that to a
>    third party (whether compelled or otherwise) without any indication to=
 the
>    TLS client. This seems true TLS 1.3 today.
>    2. TLS Server has their ephemeral DH keys and session keys and can
>    provide them to a third party without any indication to the TLS client=
.
>    This seems true with TLS 1.3 today.
>    3. TLS Server can create a TLS server implementation that uses static
>    DH keys and provide them to a third party. The client can use methods =
to
>    detect this (though there are measures and countermeasures here). This=
 is
>    true seems TLS 1.3 today.
>    4. TLS Client has all of the decrypted data and can provide that to a
>    third party (whether compelled or otherwise) without any indication to=
 the
>    TLS server. This seems true in TLS 1.3 today.
>    5. TLS Client has their ephemeral DH keys and session keys and can
>    provide them to a third party without any indication to the TLS server=
.
>    This seems true with TLS 1.3 today.
>
>
>
> I believe Russ was outlining a method where an extension would be added t=
o
> TLS 1.3 that would provide for delivery of a decryption key to a third
> party during the handshake (correct me if I got that wrong, Russ). Becaus=
e
> it would be during the handshake, it would seem to be visible to the TLS
> Client=E2=80=94in fact, the client would have to include the extension to=
 begin
> with. If the TLS client saw the extension and did not consent, it could
> abort the connection. If the TLS Server were attempting to provide access
> to the exchanged data to a third party, it would seem they could use 1, 2=
,
> or 3 above and not have to go to the trouble of attempting to subvert the
> mechanism that Russ proposes (and others have previously proposed).
>
>
>
> Can you clarify?
>
>
>
> Paul
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a1146e2e073c5670554be01ad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    Paul, it would be trivial to normal that exchange to conc=
eal from the client that a static key is being used. No software mods requi=
red on either end: just in the middle.=C2=A0

    On Jul 20, 2017 1:04 PM, "Paul Turner=
" <PAUL.TURNER@venafi.com=
> wrote:
    






    

    

    =C2=A0
    

    =C2=A0
    

    

    

    From: TLS=
 [mailto:tls-boun=
ces@ietf.org]
On Behalf Of Robin Wilton
    
Sent: Thursday, July 20, 2017 05:58
    
To: tls@ietf.org
    
Subject: Re: [TLS] Is there a way forward after today's hum?<=
/u>
    

    

    

    =C2=A0
    

    

    Apologies for not replying "in thread" =
on this occasion, for noob reasons... but here's the specific comment f=
rom Russ that I wanted to respond to:
    

    =C2=A0
    

    


    

    

    The hum told us=
 that the room was roughly evenly split.=C2=A0 In hind sight, I wish the ch=
airs had asked a second question.=C2=A0 If the split in the room was differ=
ent for the second question, then I think we might have learned a bit more =
about what people are thinking.
    

    =C2=A0
    

    If a specificat=
ion were available that used an extension that involved both the client and=
 the server, would the working group adopt it, work on it, and publish it a=
s an RFC?
    

    =C2=A0
    

    I was listening=
 very carefully to the comments made by people in line.=C2=A0 Clearly some =
people would hum for "no" to the above question, but it sounded l=
ike many felt that this would be a significant difference.=C2=A0 It would e=
nsure that both server and client explicitly opt-in, and any party observin=
g the handshake could see the extension was included or not.<=
/span>
    

    =C2=A0
    

    Russ<=
/u>
    

    =3D=3D=3D=3D
    

    =C2=A0
    

    Stephen Farrell articulated a concern with that a=
pproach - namely, that if we are relying on a setting that is meant to ensu=
re both parties must be aware that static DH is
 in use, then a bad actor would find ways to suppress that notification. In=
 your proposal, Russ, the notification mechanism would take the form of an =
extension... so I think we would need to understand what the failsafe is, f=
or instance if that extension is
 disabled, or not present, in a given deployment of TLS.
    

    =C2=A0
    

    There's an implicit assumption about the thre=
at model, too, which I just want to call out. The assumption is that a bad =
actor would suppress the notification so that the
 client is not aware that static DH is in use. For completeness, should we =
also consider whether there are attacks in which it's the *server* whos=
e notification is suppressed? (I can't think of such an attack, off the=
 top of my head, but then, that's probably
 why I'm not a hacker. ;^, )
    

    =C2=A0
    

    Best wishes,
    

    Robin=C2=A0

    

    =C2=A0
    

    Robin,
    

    =C2=A0
    

    With respect to your threat concerns, can you be more clear about the t=
hreats you=E2=80=99re considering? Here are a few things that come to mind:=

    

    =C2=A0
    

      

    1. TLS Server has all of the decrypted data and=
 can provide that to a third party (whether compelled or otherwise) without=
 any indication to the
 TLS client. This seems true TLS 1.3 today.
    2. TLS Server has their ephemeral DH keys and session=
 keys and can provide them to a third party without any indication to the T=
LS client. This
 seems true with TLS 1.3 today.
    3. TLS Server can create a TLS server implementation that uses st=
atic DH keys and provide them to a third party. The client can use methods =
to detect
 this (though there are measures and countermeasures here). This is true se=
ems TLS 1.3 today.
    4. <=
span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">=
TLS Client has all of the decrypted data and can provide that to a third pa=
rty (whether compelled or otherwise) without any indication to the
 TLS server. This seems true in TLS 1.3 today.
      5. TLS Client has their ephemeral DH keys and sess=
ion keys and can provide them to a third party without any indication to th=
e TLS server. This
 seems true with TLS 1.3 today.
    

    =C2=A0
    

    I believe Russ was outlining a method where an extension would be added=
 to TLS 1.3 that would provide for delivery of a decryption key to a third =
party during the handshake (correct me if I
 got that wrong, Russ). Because it would be during the handshake, it would =
seem to be visible to the TLS=C2=A0 Client=E2=80=94in fact, the client woul=
d have to include the extension to begin with. If the TLS client saw the ex=
tension and did not consent, it could abort the
 connection. If the TLS Server were attempting to provide access to the exc=
hanged data to a third party, it would seem they could use 1, 2, or 3 above=
 and not have to go to the trouble of attempting to subvert the mechanism t=
hat Russ proposes (and others have
 previously proposed). 
    

    =C2=A0
    

    Can you clarify?
    

    =C2=A0
    

    Paul
    

    

    

    


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

    

--001a1146e2e073c5670554be01ad--


From nobody Thu Jul 20 04:35:49 2017
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 6A26F131C1E for ; Thu, 20 Jul 2017 04:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 enmIgg5DkPGB for ; Thu, 20 Jul 2017 04:35:30 -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 50C12131C17 for ; Thu, 20 Jul 2017 04:35:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A981B300546 for ; Thu, 20 Jul 2017 07:35:29 -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 BSRgold_HC48 for ; Thu, 20 Jul 2017 07:35:27 -0400 (EDT)
Received: from [5.5.33.149] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id A8B3D300278; Thu, 20 Jul 2017 07:35:26 -0400 (EDT)
From: Russ Housley 
Message-Id: <5B14DA7C-E6D4-4681-AEE5-23DD0949CE68@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BB5C3EFA-64AD-4D65-813E-F8DEE91DB9D8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 20 Jul 2017 07:35:28 -0400
In-Reply-To: 
Cc: IETF TLS 
To: Robin Wilton 
References: 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 11:35:43 -0000

--Apple-Mail=_BB5C3EFA-64AD-4D65-813E-F8DEE91DB9D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Jul 20, 2017, at 5:57 AM, Robin Wilton  wrote:
>=20
> Apologies for not replying "in thread" on this occasion, for noob =
reasons... but here's the specific comment from Russ that I wanted to =
respond to:
>=20
> The hum told us that the room was roughly evenly split.  In hind =
sight, I wish the chairs had asked a second question.  If the split in =
the room was different for the second question, then I think we might =
have learned a bit more about what people are thinking.
>=20
> If a specification were available that used an extension that involved =
both the client and the server, would the working group adopt it, work =
on it, and publish it as an RFC?
>=20
> I was listening very carefully to the comments made by people in line. =
 Clearly some people would hum for "no" to the above question, but it =
sounded like many felt that this would be a significant difference.  It =
would ensure that both server and client explicitly opt-in, and any =
party observing the handshake could see the extension was included or =
not.
>=20
> Russ
> =3D=3D=3D=3D
>=20
> Stephen Farrell articulated a concern with that approach - namely, =
that if we are relying on a setting that is meant to ensure both parties =
must be aware that static DH is in use, then a bad actor would find ways =
to suppress that notification. In your proposal, Russ, the notification =
mechanism would take the form of an extension... so I think we would =
need to understand what the failsafe is, for instance if that extension =
is disabled, or not present, in a given deployment of TLS.
>=20
> There's an implicit assumption about the threat model, too, which I =
just want to call out. The assumption is that a bad actor would suppress =
the notification so that the client is not aware that static DH is in =
use. For completeness, should we also consider whether there are attacks =
in which it's the *server* whose notification is suppressed? (I can't =
think of such an attack, off the top of my head, but then, that's =
probably why I'm not a hacker. ;^, )
>=20
> Best wishes,
> Robin =20


Robin:

I belive that such tampering would be detected by the finished message =
processing and the handshake would fail.

Russ



--Apple-Mail=_BB5C3EFA-64AD-4D65-813E-F8DEE91DB9D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


    On Jul 20, 2017, at 5:57 AM, Robin Wilton <wilton@isoc.org> =
wrote:

    Apologies for =
not replying "in thread" on this occasion, for noob reasons... but =
here's the specific comment from Russ that I wanted to respond =
to:

    The =
hum told us that the room was roughly evenly split.  In hind sight, I =
wish the chairs had asked a second question.  If the split in the room =
was different for the second question, then I think we might have =
learned a bit more about what people are thinking.

If a specification were available that used an extension that involved =
both the client and the server, would the working group adopt it, work =
on it, and publish it as an RFC?

I was listening very carefully to the comments made by people in line.  =
Clearly some people would hum for "no" to the above question, but it =
sounded like many felt that this would be a significant difference.  It =
would ensure that both server and client explicitly opt-in, and any =
party observing the handshake could see the extension was included or =
not.

Russ

    =3D=3D=3D=3D

    Stephen =
Farrell articulated a concern with that approach - namely, that if we =
are relying on a setting that is meant to ensure both parties must be =
aware that static DH is in use, then a bad actor would find ways to =
suppress that notification. In your proposal, Russ, the notification =
mechanism would take the form of an extension... so I think we would =
need to understand what the failsafe is, for instance if that extension =
is disabled, or not present, in a given deployment of TLS.

    There's an implicit assumption about the threat model, too, =
which I just want to call out. The assumption is that a bad actor would =
suppress the notification so that the client is not aware that static DH =
is in use. For completeness, should we also consider whether there are =
attacks in which it's the *server* whose notification is suppressed? (I =
can't think of such an attack, off the top of my head, but then, that's =
probably why I'm not a hacker. ;^, )

    Best =
wishes,
    Robin  


    Robin:

    I =
belive that such tampering would be detected by the finished message =
processing and the handshake would fail.

    Russ


    =

--Apple-Mail=_BB5C3EFA-64AD-4D65-813E-F8DEE91DB9D8--


From nobody Thu Jul 20 04:44:39 2017
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 E0E1812EC30 for ; Thu, 20 Jul 2017 04:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 nC3S3q0KPzNN for ; Thu, 20 Jul 2017 04:44:35 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590AD12EA7C for ; Thu, 20 Jul 2017 04:44:35 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 05:44:34 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 05:44:34 -0600
From: Paul Turner 
To: Ted Lemon , Paul Turner 
CC: Robin Wilton , "" 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQGZY5pvJzH4JA3szzi/CxpFoIjfXaLPvrHggAB0dYCAAAVSoA==
Date: Thu, 20 Jul 2017 11:44:34 +0000
Message-ID: <691913e7a5d1464e8dda20c8848f6149@venafi.com>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.197.5.35]
Content-Type: multipart/alternative; boundary="_000_691913e7a5d1464e8dda20c8848f6149venaficom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 11:44:37 -0000

--_000_691913e7a5d1464e8dda20c8848f6149venaficom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
VGVkIExlbW9uDQpTZW50OiBUaHVyc2RheSwgSnVseSAyMCwgMjAxNyAwNzoyNQ0KVG86IFBhdWwg
VHVybmVyIDxQQVVMLlRVUk5FUkB2ZW5hZmkuY29tPg0KQ2M6IFJvYmluIFdpbHRvbiA8d2lsdG9u
QGlzb2Mub3JnPjsgPHRsc0BpZXRmLm9yZz4gPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb
VExTXSBJcyB0aGVyZSBhIHdheSBmb3J3YXJkIGFmdGVyIHRvZGF5J3MgaHVtPw0KDQpQYXVsLCBp
dCB3b3VsZCBiZSB0cml2aWFsIHRvIG5vcm1hbCB0aGF0IGV4Y2hhbmdlIHRvIGNvbmNlYWwgZnJv
bSB0aGUgY2xpZW50IHRoYXQgYSBzdGF0aWMga2V5IGlzIGJlaW5nIHVzZWQuIE5vIHNvZnR3YXJl
IG1vZHMgcmVxdWlyZWQgb24gZWl0aGVyIGVuZDoganVzdCBpbiB0aGUgbWlkZGxlLg0KDQpUaGFu
a3MsIFRlZC4gQ2FuIHlvdSBleHBhbmQgb24gdGhpcz8NCg0KQWxzbywgY2FuIHlvdSBhbHNvIHB1
dCBpdCBpbiB0aGUgY29udGV4dCBvZiBhIHRocmVhdCBtb2RlbCBhcyBSb2JpbiBzdWdnZXN0ZWQ/
IEnigJl2ZSBzdWdnZXN0ZWQgc29tZSB0aGluZ3MgYmVsb3cgYnV0IG1heSBub3QgaGF2ZSBpdCBy
aWdodC4gV2h5IHdvdWxkIHRoZSBhdHRhY2tlciB0YWtlIHRoaXMgYXBwcm9hY2ggdmVyc3VzIHNv
bWUgb2YgdGhlIHJlYWRpbHkgYXZhaWxhYmxlIG1ldGhvZHM/DQoNClBhdWwNCg0KT24gSnVsIDIw
LCAyMDE3IDE6MDQgUE0sICJQYXVsIFR1cm5lciIgPFBBVUwuVFVSTkVSQHZlbmFmaS5jb208bWFp
bHRvOlBBVUwuVFVSTkVSQHZlbmFmaS5jb20+PiB3cm90ZToNCg0KDQpGcm9tOiBUTFMgW21haWx0
bzp0bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC
ZWhhbGYgT2YgUm9iaW4gV2lsdG9uDQpTZW50OiBUaHVyc2RheSwgSnVseSAyMCwgMjAxNyAwNTo1
OA0KVG86IHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtU
TFNdIElzIHRoZXJlIGEgd2F5IGZvcndhcmQgYWZ0ZXIgdG9kYXkncyBodW0/DQoNCg0KQXBvbG9n
aWVzIGZvciBub3QgcmVwbHlpbmcgImluIHRocmVhZCIgb24gdGhpcyBvY2Nhc2lvbiwgZm9yIG5v
b2IgcmVhc29ucy4uLiBidXQgaGVyZSdzIHRoZSBzcGVjaWZpYyBjb21tZW50IGZyb20gUnVzcyB0
aGF0IEkgd2FudGVkIHRvIHJlc3BvbmQgdG86DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpUaGUgaHVtIHRvbGQgdXMgdGhhdCB0aGUgcm9vbSB3YXMgcm91Z2hseSBl
dmVubHkgc3BsaXQuICBJbiBoaW5kIHNpZ2h0LCBJIHdpc2ggdGhlIGNoYWlycyBoYWQgYXNrZWQg
YSBzZWNvbmQgcXVlc3Rpb24uICBJZiB0aGUgc3BsaXQgaW4gdGhlIHJvb20gd2FzIGRpZmZlcmVu
dCBmb3IgdGhlIHNlY29uZCBxdWVzdGlvbiwgdGhlbiBJIHRoaW5rIHdlIG1pZ2h0IGhhdmUgbGVh
cm5lZCBhIGJpdCBtb3JlIGFib3V0IHdoYXQgcGVvcGxlIGFyZSB0aGlua2luZy4NCg0KDQoNCklm
IGEgc3BlY2lmaWNhdGlvbiB3ZXJlIGF2YWlsYWJsZSB0aGF0IHVzZWQgYW4gZXh0ZW5zaW9uIHRo
YXQgaW52b2x2ZWQgYm90aCB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyLCB3b3VsZCB0aGUgd29y
a2luZyBncm91cCBhZG9wdCBpdCwgd29yayBvbiBpdCwgYW5kIHB1Ymxpc2ggaXQgYXMgYW4gUkZD
Pw0KDQoNCg0KSSB3YXMgbGlzdGVuaW5nIHZlcnkgY2FyZWZ1bGx5IHRvIHRoZSBjb21tZW50cyBt
YWRlIGJ5IHBlb3BsZSBpbiBsaW5lLiAgQ2xlYXJseSBzb21lIHBlb3BsZSB3b3VsZCBodW0gZm9y
ICJubyIgdG8gdGhlIGFib3ZlIHF1ZXN0aW9uLCBidXQgaXQgc291bmRlZCBsaWtlIG1hbnkgZmVs
dCB0aGF0IHRoaXMgd291bGQgYmUgYSBzaWduaWZpY2FudCBkaWZmZXJlbmNlLiAgSXQgd291bGQg
ZW5zdXJlIHRoYXQgYm90aCBzZXJ2ZXIgYW5kIGNsaWVudCBleHBsaWNpdGx5IG9wdC1pbiwgYW5k
IGFueSBwYXJ0eSBvYnNlcnZpbmcgdGhlIGhhbmRzaGFrZSBjb3VsZCBzZWUgdGhlIGV4dGVuc2lv
biB3YXMgaW5jbHVkZWQgb3Igbm90Lg0KDQoNCg0KUnVzcw0KDQo9PT09DQoNCg0KDQpTdGVwaGVu
IEZhcnJlbGwgYXJ0aWN1bGF0ZWQgYSBjb25jZXJuIHdpdGggdGhhdCBhcHByb2FjaCAtIG5hbWVs
eSwgdGhhdCBpZiB3ZSBhcmUgcmVseWluZyBvbiBhIHNldHRpbmcgdGhhdCBpcyBtZWFudCB0byBl
bnN1cmUgYm90aCBwYXJ0aWVzIG11c3QgYmUgYXdhcmUgdGhhdCBzdGF0aWMgREggaXMgaW4gdXNl
LCB0aGVuIGEgYmFkIGFjdG9yIHdvdWxkIGZpbmQgd2F5cyB0byBzdXBwcmVzcyB0aGF0IG5vdGlm
aWNhdGlvbi4gSW4geW91ciBwcm9wb3NhbCwgUnVzcywgdGhlIG5vdGlmaWNhdGlvbiBtZWNoYW5p
c20gd291bGQgdGFrZSB0aGUgZm9ybSBvZiBhbiBleHRlbnNpb24uLi4gc28gSSB0aGluayB3ZSB3
b3VsZCBuZWVkIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUgZmFpbHNhZmUgaXMsIGZvciBpbnN0YW5j
ZSBpZiB0aGF0IGV4dGVuc2lvbiBpcyBkaXNhYmxlZCwgb3Igbm90IHByZXNlbnQsIGluIGEgZ2l2
ZW4gZGVwbG95bWVudCBvZiBUTFMuDQoNCg0KDQpUaGVyZSdzIGFuIGltcGxpY2l0IGFzc3VtcHRp
b24gYWJvdXQgdGhlIHRocmVhdCBtb2RlbCwgdG9vLCB3aGljaCBJIGp1c3Qgd2FudCB0byBjYWxs
IG91dC4gVGhlIGFzc3VtcHRpb24gaXMgdGhhdCBhIGJhZCBhY3RvciB3b3VsZCBzdXBwcmVzcyB0
aGUgbm90aWZpY2F0aW9uIHNvIHRoYXQgdGhlIGNsaWVudCBpcyBub3QgYXdhcmUgdGhhdCBzdGF0
aWMgREggaXMgaW4gdXNlLiBGb3IgY29tcGxldGVuZXNzLCBzaG91bGQgd2UgYWxzbyBjb25zaWRl
ciB3aGV0aGVyIHRoZXJlIGFyZSBhdHRhY2tzIGluIHdoaWNoIGl0J3MgdGhlICpzZXJ2ZXIqIHdo
b3NlIG5vdGlmaWNhdGlvbiBpcyBzdXBwcmVzc2VkPyAoSSBjYW4ndCB0aGluayBvZiBzdWNoIGFu
IGF0dGFjaywgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZCwgYnV0IHRoZW4sIHRoYXQncyBwcm9iYWJs
eSB3aHkgSSdtIG5vdCBhIGhhY2tlci4gO14sICkNCg0KDQoNCkJlc3Qgd2lzaGVzLA0KDQpSb2Jp
bg0KDQoNCg0KUm9iaW4sDQoNCg0KDQpXaXRoIHJlc3BlY3QgdG8geW91ciB0aHJlYXQgY29uY2Vy
bnMsIGNhbiB5b3UgYmUgbW9yZSBjbGVhciBhYm91dCB0aGUgdGhyZWF0cyB5b3XigJlyZSBjb25z
aWRlcmluZz8gSGVyZSBhcmUgYSBmZXcgdGhpbmdzIHRoYXQgY29tZSB0byBtaW5kOg0KDQoNCjEu
ICAgICBUTFMgU2VydmVyIGhhcyBhbGwgb2YgdGhlIGRlY3J5cHRlZCBkYXRhIGFuZCBjYW4gcHJv
dmlkZSB0aGF0IHRvIGEgdGhpcmQgcGFydHkgKHdoZXRoZXIgY29tcGVsbGVkIG9yIG90aGVyd2lz
ZSkgd2l0aG91dCBhbnkgaW5kaWNhdGlvbiB0byB0aGUgVExTIGNsaWVudC4gVGhpcyBzZWVtcyB0
cnVlIFRMUyAxLjMgdG9kYXkuDQoyLiAgICAgVExTIFNlcnZlciBoYXMgdGhlaXIgZXBoZW1lcmFs
IERIIGtleXMgYW5kIHNlc3Npb24ga2V5cyBhbmQgY2FuIHByb3ZpZGUgdGhlbSB0byBhIHRoaXJk
IHBhcnR5IHdpdGhvdXQgYW55IGluZGljYXRpb24gdG8gdGhlIFRMUyBjbGllbnQuIFRoaXMgc2Vl
bXMgdHJ1ZSB3aXRoIFRMUyAxLjMgdG9kYXkuDQozLiAgICAgVExTIFNlcnZlciBjYW4gY3JlYXRl
IGEgVExTIHNlcnZlciBpbXBsZW1lbnRhdGlvbiB0aGF0IHVzZXMgc3RhdGljIERIIGtleXMgYW5k
IHByb3ZpZGUgdGhlbSB0byBhIHRoaXJkIHBhcnR5LiBUaGUgY2xpZW50IGNhbiB1c2UgbWV0aG9k
cyB0byBkZXRlY3QgdGhpcyAodGhvdWdoIHRoZXJlIGFyZSBtZWFzdXJlcyBhbmQgY291bnRlcm1l
YXN1cmVzIGhlcmUpLiBUaGlzIGlzIHRydWUgc2VlbXMgVExTIDEuMyB0b2RheS4NCjQuICAgICBU
TFMgQ2xpZW50IGhhcyBhbGwgb2YgdGhlIGRlY3J5cHRlZCBkYXRhIGFuZCBjYW4gcHJvdmlkZSB0
aGF0IHRvIGEgdGhpcmQgcGFydHkgKHdoZXRoZXIgY29tcGVsbGVkIG9yIG90aGVyd2lzZSkgd2l0
aG91dCBhbnkgaW5kaWNhdGlvbiB0byB0aGUgVExTIHNlcnZlci4gVGhpcyBzZWVtcyB0cnVlIGlu
IFRMUyAxLjMgdG9kYXkuDQo1LiAgICAgVExTIENsaWVudCBoYXMgdGhlaXIgZXBoZW1lcmFsIERI
IGtleXMgYW5kIHNlc3Npb24ga2V5cyBhbmQgY2FuIHByb3ZpZGUgdGhlbSB0byBhIHRoaXJkIHBh
cnR5IHdpdGhvdXQgYW55IGluZGljYXRpb24gdG8gdGhlIFRMUyBzZXJ2ZXIuIFRoaXMgc2VlbXMg
dHJ1ZSB3aXRoIFRMUyAxLjMgdG9kYXkuDQoNCg0KDQpJIGJlbGlldmUgUnVzcyB3YXMgb3V0bGlu
aW5nIGEgbWV0aG9kIHdoZXJlIGFuIGV4dGVuc2lvbiB3b3VsZCBiZSBhZGRlZCB0byBUTFMgMS4z
IHRoYXQgd291bGQgcHJvdmlkZSBmb3IgZGVsaXZlcnkgb2YgYSBkZWNyeXB0aW9uIGtleSB0byBh
IHRoaXJkIHBhcnR5IGR1cmluZyB0aGUgaGFuZHNoYWtlIChjb3JyZWN0IG1lIGlmIEkgZ290IHRo
YXQgd3JvbmcsIFJ1c3MpLiBCZWNhdXNlIGl0IHdvdWxkIGJlIGR1cmluZyB0aGUgaGFuZHNoYWtl
LCBpdCB3b3VsZCBzZWVtIHRvIGJlIHZpc2libGUgdG8gdGhlIFRMUyAgQ2xpZW504oCUaW4gZmFj
dCwgdGhlIGNsaWVudCB3b3VsZCBoYXZlIHRvIGluY2x1ZGUgdGhlIGV4dGVuc2lvbiB0byBiZWdp
biB3aXRoLiBJZiB0aGUgVExTIGNsaWVudCBzYXcgdGhlIGV4dGVuc2lvbiBhbmQgZGlkIG5vdCBj
b25zZW50LCBpdCBjb3VsZCBhYm9ydCB0aGUgY29ubmVjdGlvbi4gSWYgdGhlIFRMUyBTZXJ2ZXIg
d2VyZSBhdHRlbXB0aW5nIHRvIHByb3ZpZGUgYWNjZXNzIHRvIHRoZSBleGNoYW5nZWQgZGF0YSB0
byBhIHRoaXJkIHBhcnR5LCBpdCB3b3VsZCBzZWVtIHRoZXkgY291bGQgdXNlIDEsIDIsIG9yIDMg
YWJvdmUgYW5kIG5vdCBoYXZlIHRvIGdvIHRvIHRoZSB0cm91YmxlIG9mIGF0dGVtcHRpbmcgdG8g
c3VidmVydCB0aGUgbWVjaGFuaXNtIHRoYXQgUnVzcyBwcm9wb3NlcyAoYW5kIG90aGVycyBoYXZl
IHByZXZpb3VzbHkgcHJvcG9zZWQpLg0KDQoNCg0KQ2FuIHlvdSBjbGFyaWZ5Pw0KDQoNCg0KUGF1
bA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExT
IG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K

--_000_691913e7a5d1464e8dda20c8848f6149venaficom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7
DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg
Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh
bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r
OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7
fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5
bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp
Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp
Zjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy
ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30N
CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0
IGwwDQoJe21zby1saXN0LWlkOjU0OTE5NjE4MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjIz
NjYzMjY4O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206
MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRMUyBbbWFpbHRv
OnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UZWQgTGVtb248YnI+
DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgMDc6MjU8YnI+DQo8Yj5Ubzo8
L2I+IFBhdWwgVHVybmVyICZsdDtQQVVMLlRVUk5FUkB2ZW5hZmkuY29tJmd0Ozxicj4NCjxiPkNj
OjwvYj4gUm9iaW4gV2lsdG9uICZsdDt3aWx0b25AaXNvYy5vcmcmZ3Q7OyAmbHQ7dGxzQGlldGYu
b3JnJmd0OyAmbHQ7dGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RM
U10gSXMgdGhlcmUgYSB3YXkgZm9yd2FyZCBhZnRlciB0b2RheSdzIGh1bT88bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPlBhdWwsIGl0IHdvdWxkIGJlIHRyaXZpYWwgdG8gbm9ybWFsIHRo
YXQgZXhjaGFuZ2UgdG8gY29uY2VhbCBmcm9tIHRoZSBjbGllbnQgdGhhdCBhIHN0YXRpYyBrZXkg
aXMgYmVpbmcgdXNlZC4gTm8gc29mdHdhcmUgbW9kcyByZXF1aXJlZCBvbiBlaXRoZXIgZW5kOiBq
dXN0IGluIHRoZSBtaWRkbGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLCBUZWQuIENhbiB5b3UgZXhw
YW5kIG9uIHRoaXM/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QWxzbywgY2FuIHlvdSBhbHNvIHB1dCBpdCBp
biB0aGUgY29udGV4dCBvZiBhIHRocmVhdCBtb2RlbCBhcyBSb2JpbiBzdWdnZXN0ZWQ/IEnigJl2
ZSBzdWdnZXN0ZWQgc29tZSB0aGluZ3MgYmVsb3cgYnV0IG1heSBub3QgaGF2ZSBpdCByaWdodC4g
V2h5IHdvdWxkIHRoZSBhdHRhY2tlciB0YWtlIHRoaXMNCiBhcHByb2FjaCB2ZXJzdXMgc29tZSBv
ZiB0aGUgcmVhZGlseSBhdmFpbGFibGUgbWV0aG9kcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UGF1bDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gSnVsIDIwLCAyMDE3
IDE6MDQgUE0sICZxdW90O1BhdWwgVHVybmVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86UEFV
TC5UVVJORVJAdmVuYWZpLmNvbSI+UEFVTC5UVVJORVJAdmVuYWZpLmNvbTwvYT4mZ3Q7IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVp
biI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu
LWxlZnQ6MS4waW4iPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj4gVExTIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5Sb2JpbiBXaWx0b248YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkg
MjAsIDIwMTcgMDU6NTg8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbVExTXSBJcyB0aGVyZSBhIHdheSBmb3J3YXJkIGFmdGVyIHRvZGF5J3MgaHVtPzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJtXzM4
OTgxNjY4MjUzMjE1NDc3OTBkaXZ0YWdkZWZhdWx0d3JhcHBlciI+DQo8cCBzdHlsZT0ibWFyZ2lu
LWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFwb2xvZ2llcyBmb3Igbm90IHJlcGx5aW5nICZxdW90
O2luIHRocmVhZCZxdW90OyBvbiB0aGlzIG9jY2FzaW9uLCBmb3Igbm9vYiByZWFzb25zLi4uIGJ1
dCBoZXJlJ3MgdGhlIHNwZWNpZmljIGNvbW1lbnQgZnJvbSBSdXNzIHRoYXQgSSB3YW50ZWQgdG8g
cmVzcG9uZCB0bzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6
MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu
dGVyIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs
YWNrIj4NCjxociBzaXplPSI1IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+
PC9kaXY+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPlRoZSBodW0gdG9sZCB1cyB0aGF0IHRoZSByb29tIHdhcyByb3VnaGx5
IGV2ZW5seSBzcGxpdC4mbmJzcDsgSW4gaGluZCBzaWdodCwgSSB3aXNoIHRoZSBjaGFpcnMgaGFk
IGFza2VkIGEgc2Vjb25kIHF1ZXN0aW9uLiZuYnNwOyBJZiB0aGUgc3BsaXQgaW4gdGhlIHJvb20g
d2FzIGRpZmZlcmVudCBmb3IgdGhlIHNlY29uZCBxdWVzdGlvbiwgdGhlbiBJIHRoaW5rIHdlIG1p
Z2h0IGhhdmUgbGVhcm5lZCBhIGJpdCBtb3JlIGFib3V0IHdoYXQgcGVvcGxlIGFyZSB0aGlua2lu
Zy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+SWYgYSBzcGVjaWZpY2F0aW9uIHdlcmUgYXZhaWxhYmxlIHRoYXQgdXNlZCBhbiBleHRlbnNp
b24gdGhhdCBpbnZvbHZlZCBib3RoIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXIsIHdvdWxkIHRo
ZSB3b3JraW5nIGdyb3VwIGFkb3B0IGl0LCB3b3JrIG9uIGl0LCBhbmQgcHVibGlzaCBpdCBhcyBh
biBSRkM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDox
LjBpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPkkgd2FzIGxpc3RlbmluZyB2ZXJ5IGNhcmVmdWxseSB0byB0aGUgY29tbWVudHMgbWFk
ZSBieSBwZW9wbGUgaW4gbGluZS4mbmJzcDsgQ2xlYXJseSBzb21lIHBlb3BsZSB3b3VsZCBodW0g
Zm9yICZxdW90O25vJnF1b3Q7IHRvIHRoZSBhYm92ZSBxdWVzdGlvbiwgYnV0IGl0IHNvdW5kZWQg
bGlrZSBtYW55IGZlbHQgdGhhdCB0aGlzIHdvdWxkIGJlIGEgc2lnbmlmaWNhbnQgZGlmZmVyZW5j
ZS4mbmJzcDsgSXQgd291bGQgZW5zdXJlIHRoYXQgYm90aCBzZXJ2ZXIgYW5kIGNsaWVudCBleHBs
aWNpdGx5IG9wdC1pbiwgYW5kIGFueSBwYXJ0eSBvYnNlcnZpbmcgdGhlIGhhbmRzaGFrZSBjb3Vs
ZCBzZWUgdGhlIGV4dGVuc2lvbiB3YXMgaW5jbHVkZWQgb3Igbm90Ljwvc3Bhbj48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SdXNzPC9zcGFuPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPj09
PT08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t
bGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3RlcGhlbiBGYXJyZWxsIGFydGljdWxhdGVkIGEgY29u
Y2VybiB3aXRoIHRoYXQgYXBwcm9hY2ggLSBuYW1lbHksIHRoYXQgaWYgd2UgYXJlIHJlbHlpbmcg
b24gYSBzZXR0aW5nIHRoYXQgaXMgbWVhbnQgdG8gZW5zdXJlIGJvdGggcGFydGllcyBtdXN0IGJl
IGF3YXJlIHRoYXQgc3RhdGljIERIDQogaXMgaW4gdXNlLCB0aGVuIGEgYmFkIGFjdG9yIHdvdWxk
IGZpbmQgd2F5cyB0byBzdXBwcmVzcyB0aGF0IG5vdGlmaWNhdGlvbi4gSW4geW91ciBwcm9wb3Nh
bCwgUnVzcywgdGhlIG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gd291bGQgdGFrZSB0aGUgZm9ybSBv
ZiBhbiBleHRlbnNpb24uLi4gc28gSSB0aGluayB3ZSB3b3VsZCBuZWVkIHRvIHVuZGVyc3RhbmQg
d2hhdCB0aGUgZmFpbHNhZmUgaXMsIGZvciBpbnN0YW5jZSBpZiB0aGF0IGV4dGVuc2lvbg0KIGlz
IGRpc2FibGVkLCBvciBub3QgcHJlc2VudCwgaW4gYSBnaXZlbiBkZXBsb3ltZW50IG9mIFRMUy48
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVm
dDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjpibGFjayI+VGhlcmUncyBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uIGFib3V0
IHRoZSB0aHJlYXQgbW9kZWwsIHRvbywgd2hpY2ggSSBqdXN0IHdhbnQgdG8gY2FsbCBvdXQuIFRo
ZSBhc3N1bXB0aW9uIGlzIHRoYXQgYSBiYWQgYWN0b3Igd291bGQgc3VwcHJlc3MgdGhlIG5vdGlm
aWNhdGlvbiBzbyB0aGF0IHRoZQ0KIGNsaWVudCBpcyBub3QgYXdhcmUgdGhhdCBzdGF0aWMgREgg
aXMgaW4gdXNlLiBGb3IgY29tcGxldGVuZXNzLCBzaG91bGQgd2UgYWxzbyBjb25zaWRlciB3aGV0
aGVyIHRoZXJlIGFyZSBhdHRhY2tzIGluIHdoaWNoIGl0J3MgdGhlICpzZXJ2ZXIqIHdob3NlIG5v
dGlmaWNhdGlvbiBpcyBzdXBwcmVzc2VkPyAoSSBjYW4ndCB0aGluayBvZiBzdWNoIGFuIGF0dGFj
aywgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZCwgYnV0IHRoZW4sIHRoYXQncyBwcm9iYWJseQ0KIHdo
eSBJJ20gbm90IGEgaGFja2VyLiA7XiwgKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl
PSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5CZXN0IHdpc2hl
cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6YmxhY2siPlJvYmluJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Sb2Jp
biw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XaXRoIHJlc3BlY3QgdG8geW91ciB0aHJl
YXQgY29uY2VybnMsIGNhbiB5b3UgYmUgbW9yZSBjbGVhciBhYm91dCB0aGUgdGhyZWF0cyB5b3Xi
gJlyZSBjb25zaWRlcmluZz8gSGVyZSBhcmUgYSBmZXcgdGhpbmdzIHRoYXQgY29tZSB0byBtaW5k
Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg
bGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0
Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj5UTFMgU2VydmVyIGhhcyBhbGwgb2YgdGhlIGRlY3J5cHRlZCBkYXRh
IGFuZCBjYW4gcHJvdmlkZSB0aGF0IHRvIGEgdGhpcmQgcGFydHkgKHdoZXRoZXIgY29tcGVsbGVk
IG9yIG90aGVyd2lzZSkgd2l0aG91dCBhbnkgaW5kaWNhdGlvbiB0byB0aGUgVExTIGNsaWVudC4g
VGhpcyBzZWVtcyB0cnVlDQogVExTIDEuMyB0b2RheS48L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWlu
O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0
eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt
ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw
YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VExTIFNlcnZlciBoYXMgdGhlaXIgZXBoZW1l
cmFsIERIIGtleXMgYW5kIHNlc3Npb24ga2V5cyBhbmQgY2FuIHByb3ZpZGUgdGhlbSB0byBhIHRo
aXJkIHBhcnR5IHdpdGhvdXQgYW55IGluZGljYXRpb24gdG8gdGhlIFRMUyBjbGllbnQuIFRoaXMg
c2VlbXMgdHJ1ZSB3aXRoIFRMUyAxLjMgdG9kYXkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjtt
c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls
ZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz
IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu
PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRMUyBTZXJ2ZXIgY2FuIGNyZWF0ZSBhIFRMUyBz
ZXJ2ZXIgaW1wbGVtZW50YXRpb24gdGhhdCB1c2VzIHN0YXRpYyBESCBrZXlzIGFuZCBwcm92aWRl
IHRoZW0gdG8gYSB0aGlyZCBwYXJ0eS4gVGhlIGNsaWVudCBjYW4gdXNlIG1ldGhvZHMgdG8gZGV0
ZWN0IHRoaXMgKHRob3VnaCB0aGVyZSBhcmUNCiBtZWFzdXJlcyBhbmQgY291bnRlcm1lYXN1cmVz
IGhlcmUpLiBUaGlzIGlzIHRydWUgc2VlbXMgVExTIDEuMyB0b2RheS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRl
bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd
PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv
c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VExTIENsaWVudCBoYXMgYWxs
IG9mIHRoZSBkZWNyeXB0ZWQgZGF0YSBhbmQgY2FuIHByb3ZpZGUgdGhhdCB0byBhIHRoaXJkIHBh
cnR5ICh3aGV0aGVyIGNvbXBlbGxlZCBvciBvdGhlcndpc2UpIHdpdGhvdXQgYW55IGluZGljYXRp
b24gdG8gdGhlIFRMUyBzZXJ2ZXIuIFRoaXMgc2VlbXMgdHJ1ZQ0KIGluIFRMUyAxLjMgdG9kYXku
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0
OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtp
ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj41LjxzcGFuIHN0
eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRM
UyBDbGllbnQgaGFzIHRoZWlyIGVwaGVtZXJhbCBESCBrZXlzIGFuZCBzZXNzaW9uIGtleXMgYW5k
IGNhbiBwcm92aWRlIHRoZW0gdG8gYSB0aGlyZCBwYXJ0eSB3aXRob3V0IGFueSBpbmRpY2F0aW9u
IHRvIHRoZSBUTFMgc2VydmVyLiBUaGlzIHNlZW1zIHRydWUgd2l0aCBUTFMgMS4zIHRvZGF5Ljwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYmVsaWV2ZSBSdXNzIHdhcyBvdXRsaW5pbmcg
YSBtZXRob2Qgd2hlcmUgYW4gZXh0ZW5zaW9uIHdvdWxkIGJlIGFkZGVkIHRvIFRMUyAxLjMgdGhh
dCB3b3VsZCBwcm92aWRlIGZvciBkZWxpdmVyeSBvZiBhIGRlY3J5cHRpb24ga2V5IHRvIGEgdGhp
cmQgcGFydHkgZHVyaW5nIHRoZSBoYW5kc2hha2UNCiAoY29ycmVjdCBtZSBpZiBJIGdvdCB0aGF0
IHdyb25nLCBSdXNzKS4gQmVjYXVzZSBpdCB3b3VsZCBiZSBkdXJpbmcgdGhlIGhhbmRzaGFrZSwg
aXQgd291bGQgc2VlbSB0byBiZSB2aXNpYmxlIHRvIHRoZSBUTFMmbmJzcDsgQ2xpZW504oCUaW4g
ZmFjdCwgdGhlIGNsaWVudCB3b3VsZCBoYXZlIHRvIGluY2x1ZGUgdGhlIGV4dGVuc2lvbiB0byBi
ZWdpbiB3aXRoLiBJZiB0aGUgVExTIGNsaWVudCBzYXcgdGhlIGV4dGVuc2lvbiBhbmQgZGlkIG5v
dCBjb25zZW50LA0KIGl0IGNvdWxkIGFib3J0IHRoZSBjb25uZWN0aW9uLiBJZiB0aGUgVExTIFNl
cnZlciB3ZXJlIGF0dGVtcHRpbmcgdG8gcHJvdmlkZSBhY2Nlc3MgdG8gdGhlIGV4Y2hhbmdlZCBk
YXRhIHRvIGEgdGhpcmQgcGFydHksIGl0IHdvdWxkIHNlZW0gdGhleSBjb3VsZCB1c2UgMSwgMiwg
b3IgMyBhYm92ZSBhbmQgbm90IGhhdmUgdG8gZ28gdG8gdGhlIHRyb3VibGUgb2YgYXR0ZW1wdGlu
ZyB0byBzdWJ2ZXJ0IHRoZSBtZWNoYW5pc20gdGhhdCBSdXNzIHByb3Bvc2VzDQogKGFuZCBvdGhl
cnMgaGF2ZSBwcmV2aW91c2x5IHByb3Bvc2VkKS4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+Q2FuIHlvdSBjbGFyaWZ5Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlBhdWw8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21h
cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KPGJyPg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0
PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4N
CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_691913e7a5d1464e8dda20c8848f6149venaficom_--


From nobody Thu Jul 20 04:52:10 2017
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 3B3B8131C16 for ; Thu, 20 Jul 2017 04:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 L9ThHtEjPE6c for ; Thu, 20 Jul 2017 04:51:57 -0700 (PDT)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 5D75D131C01 for ; Thu, 20 Jul 2017 04:51:57 -0700 (PDT)
Received: by mail-pg0-x22c.google.com with SMTP id s4so13788240pgr.5 for ; Thu, 20 Jul 2017 04:51:57 -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=ZctP4jJIwo1iVRGm3dDsWX7qtyFaPIsezhC/o9Bv+Uw=; b=AHOZ+NvpzduyRE63HnAqYaODJbTbsZ1d8Lyx5Tyms3ur7G/RVvFZxmp2odvfFR/9pS UgxQQIGPwC5KbYV6jU/nxgLA2JNcJYm+F2NffPxKgQVn8TjYa7AdBWArWNuambpPonyX MtNC8ree+fEOXkWPp8QLSXfaQAo6Q3hY6PxttBbbbV2VROkl+c6OTz35ipt8AvoCMl5E ++Loy4giBKJrAagVs/ihi2gxEyVb9heCaajSKnyrfXjIZNJkC577PFSFxN7ipZGmUoly pDN3LF5kAVwDWqbXAga7wAi9FFaWFCGLqf6VUyOGB6gApC7bvmUOHdrK2Ix8KgsOCNVH +tVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZctP4jJIwo1iVRGm3dDsWX7qtyFaPIsezhC/o9Bv+Uw=; b=tV601flyecSiVsuvfccSl0RYAmur8ed6ov25/JJkgYhOw7pt7iSaeAzztNUATIVXiH kpJI5M3KcKhR2QIE+FQVWBycsjqL9sRV393jr3dFL+oljCu1MuBLjxq1C7y3J9xccyRs PSzfd/cd3twZnoYShByxRxpZGCsWfnZb5X8J1YX/j3AqpWUOnN/DmTY1DWQ84IARkT5N +Af72hSPodl5e4ApJH5r2IQLlNxQy21Q/GKzDPkIP8ty9n/nu6y4PFBALvmZ1d9cHd6/ E87CgeibgXPvTIiD49bG7eGbvN3kc5X9VU5lcARJvtG6k6D2SSb+to6Wn9OevM2Mw7NV UhBA==
X-Gm-Message-State: AIVw110SvbmLbv/lNdmYzRvlFH4PWye7TbKiOnTChqTxPHgjk1hjwXw2 cqQjjyIAykqvrQGCaECSaCTeUWoImp5D
X-Received: by 10.84.131.109 with SMTP id 100mr3959188pld.19.1500551516601; Thu, 20 Jul 2017 04:51:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 04:51:16 -0700 (PDT)
In-Reply-To: <691913e7a5d1464e8dda20c8848f6149@venafi.com>
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com>
From: Ted Lemon 
Date: Thu, 20 Jul 2017 13:51:16 +0200
Message-ID: 
To: Paul Turner 
Cc: Robin Wilton , "" 
Content-Type: multipart/alternative; boundary="94eb2c1305901d63d60554be6089"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 11:52:08 -0000

--94eb2c1305901d63d60554be6089
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Paul, the reason to use the MiTM approach rather than simply hacking the
endpoint the attacker controls is that it may be much more convenient to be
running out-of-the-box software on the endpoint.   The MiTM isn't an
attacker from the perspective of the controlled endpoint; it is simply a
convenient way to conceal what is being done.

Having thought about it some more, as Russ points out, it might be too
expensive to be worth doing, because you'd have to hack the whole stream.
It would not, for example, be a useful passive attack, obviously.

That said, suppose this extension were added to everyone's TLS libraries.
Now the number of lines of code I'd have to #ifdef out to avoid setting the
evil bit would be much less than if it weren't.


On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner  wrote=
:

>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:25
> *To:* Paul Turner 
> *Cc:* Robin Wilton ;  
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Paul, it would be trivial to normal that exchange to conceal from the
> client that a static key is being used. No software mods required on eith=
er
> end: just in the middle.
>
>
>
> Thanks, Ted. Can you expand on this?
>
>
>
> Also, can you also put it in the context of a threat model as Robin
> suggested? I=E2=80=99ve suggested some things below but may not have it r=
ight. Why
> would the attacker take this approach versus some of the readily availabl=
e
> methods?
>
>
>
> Paul
>
>
>
> On Jul 20, 2017 1:04 PM, "Paul Turner"  wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Apologies for not replying "in thread" on this occasion, for noob
> reasons... but here's the specific comment from Russ that I wanted to
> respond to:
>
>
> ------------------------------
>
> The hum told us that the room was roughly evenly split.  In hind sight, I=
 wish the chairs had asked a second question.  If the split in the room was=
 different for the second question, then I think we might have learned a bi=
t more about what people are thinking.
>
>
>
> If a specification were available that used an extension that involved bo=
th the client and the server, would the working group adopt it, work on it,=
 and publish it as an RFC?
>
>
>
> I was listening very carefully to the comments made by people in line.  C=
learly some people would hum for "no" to the above question, but it sounded=
 like many felt that this would be a significant difference.  It would ensu=
re that both server and client explicitly opt-in, and any party observing t=
he handshake could see the extension was included or not.
>
>
>
> Russ
>
> =3D=3D=3D=3D
>
>
>
> Stephen Farrell articulated a concern with that approach - namely, that i=
f
> we are relying on a setting that is meant to ensure both parties must be
> aware that static DH is in use, then a bad actor would find ways to
> suppress that notification. In your proposal, Russ, the notification
> mechanism would take the form of an extension... so I think we would need
> to understand what the failsafe is, for instance if that extension is
> disabled, or not present, in a given deployment of TLS.
>
>
>
> There's an implicit assumption about the threat model, too, which I just
> want to call out. The assumption is that a bad actor would suppress the
> notification so that the client is not aware that static DH is in use. Fo=
r
> completeness, should we also consider whether there are attacks in which
> it's the *server* whose notification is suppressed? (I can't think of suc=
h
> an attack, off the top of my head, but then, that's probably why I'm not =
a
> hacker. ;^, )
>
>
>
> Best wishes,
>
> Robin
>
>
>
> Robin,
>
>
>
> With respect to your threat concerns, can you be more clear about the
> threats you=E2=80=99re considering? Here are a few things that come to mi=
nd:
>
>
>
> 1.     TLS Server has all of the decrypted data and can provide that to a
> third party (whether compelled or otherwise) without any indication to th=
e
> TLS client. This seems true TLS 1.3 today.
>
> 2.     TLS Server has their ephemeral DH keys and session keys and can
> provide them to a third party without any indication to the TLS client.
> This seems true with TLS 1.3 today.
>
> 3.     TLS Server can create a TLS server implementation that uses static
> DH keys and provide them to a third party. The client can use methods to
> detect this (though there are measures and countermeasures here). This is
> true seems TLS 1.3 today.
>
> 4.     TLS Client has all of the decrypted data and can provide that to a
> third party (whether compelled or otherwise) without any indication to th=
e
> TLS server. This seems true in TLS 1.3 today.
>
> 5.     TLS Client has their ephemeral DH keys and session keys and can
> provide them to a third party without any indication to the TLS server.
> This seems true with TLS 1.3 today.
>
>
>
> I believe Russ was outlining a method where an extension would be added t=
o
> TLS 1.3 that would provide for delivery of a decryption key to a third
> party during the handshake (correct me if I got that wrong, Russ). Becaus=
e
> it would be during the handshake, it would seem to be visible to the TLS
> Client=E2=80=94in fact, the client would have to include the extension to=
 begin
> with. If the TLS client saw the extension and did not consent, it could
> abort the connection. If the TLS Server were attempting to provide access
> to the exchanged data to a third party, it would seem they could use 1, 2=
,
> or 3 above and not have to go to the trouble of attempting to subvert the
> mechanism that Russ proposes (and others have previously proposed).
>
>
>
> Can you clarify?
>
>
>
> Paul
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c1305901d63d60554be6089
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    Paul, the reason to use the MiTM approach rather than simp=
ly hacking the endpoint the attacker controls is that it may be much more c=
onvenient to be running out-of-the-box software on the endpoint. =C2=A0 The=
 MiTM isn't an attacker from the perspective of the controlled endpoint=
; it is simply a convenient way to conceal what is being done.

    Having thought about it some more, as Russ points out, it might be t=
oo expensive to be worth doing, because you'd have to hack the whole st=
ream. =C2=A0 It would not, for example, be a useful passive attack, obvious=
ly.

    That said, suppose this extension were added t=
o everyone's TLS libraries. =C2=A0 Now the number of lines of code I=
9;d have to #ifdef out to avoid setting the evil bit would be much less tha=
n if it weren't.

    <=
br>
    On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner =
<PAUL.TURNER@venafi.com> wrote:
    






    

    

    =C2=A0
    

    =C2=A0
    

    From: TLS=
 [mailto:tls-boun=
ces@ietf.org]
On Behalf Of Ted Lemon
    
Sent: Thursday, July 20, 2017 07:25
    
To: Paul Turner <PAUL.TURNER@venafi.com>
    
Cc: Robin Wilton <wilton@isoc.org>; <tls@ietf.org> <tls@ietf.org>
    
Subject: Re: [TLS] Is there a way forward after today's hum?<=
/u>
    

    =C2=A0
    

    

    Paul, it would be trivial=
 to normal that exchange to conceal from the client that a static key is be=
ing used. No software mods required on either end: just in the middle.=C2=
=A0
    

    =C2=A0
    

    Thanks, Ted. Can you expand on this?

    

    =C2=A0
    

    Also, can you also put it in the context of a threa=
t model as Robin suggested? I=E2=80=99ve suggested some things below but ma=
y not have it right. Why would the attacker take this
 approach versus some of the readily available methods?
    

    =C2=A0
    

    Paul
    

    

    

    =C2=A0
    

    

    On Jul 20, 2017 1:04 PM, =
"Paul Turner" <PAUL.TURNER@venafi.com> wrote:
    

    

    

    

    
=C2=A0
    

    
=C2=A0
    

    

    

    
From: TLS [mailto:tls-bounces@ietf.org]
On Behalf Of Robin Wilton
    
Sent: Thursday, July 20, 2017 05:58
    
To: tls@ietf.org
    
Subject: Re: [TLS] Is there a way forward after today's hum?
    

    

    

    
=C2=A0
    

    

    Apologies for not replying "in thread"=
 on this occasion, for noob reasons... but here's the specific comment =
from Russ that I wanted to respond to:
    

    =C2=A0
    

    

    


    

    

    

    The hum told u=
s that the room was roughly evenly split.=C2=A0 In hind sight, I wish the c=
hairs had asked a second question.=C2=A0 If the split in the room was diffe=
rent for the second question, then I think we might have learned a bit more=
 about what people are thinking.
    

    =C2=A0<=
u>
    

    If a specifica=
tion were available that used an extension that involved both the client an=
d the server, would the working group adopt it, work on it, and publish it =
as an RFC?
    

    =C2=A0<=
u>
    

    I was listenin=
g very carefully to the comments made by people in line.=C2=A0 Clearly some=
 people would hum for "no" to the above question, but it sounded =
like many felt that this would be a significant difference.=C2=A0 It would =
ensure that both server and client explicitly opt-in, and any party observi=
ng the handshake could see the extension was included or not.=

    

    =C2=A0<=
u>
    

    Russ=

    

    =3D=3D=3D=3D
    

    =C2=A0
    

    Stephen Farrell articulated a concern with that =
approach - namely, that if we are relying on a setting that is meant to ens=
ure both parties must be aware that static DH
 is in use, then a bad actor would find ways to suppress that notification.=
 In your proposal, Russ, the notification mechanism would take the form of =
an extension... so I think we would need to understand what the failsafe is=
, for instance if that extension
 is disabled, or not present, in a given deployment of TLS.
    

    =C2=A0
    

    There's an implicit assumption about the thr=
eat model, too, which I just want to call out. The assumption is that a bad=
 actor would suppress the notification so that the
 client is not aware that static DH is in use. For completeness, should we =
also consider whether there are attacks in which it's the *server* whos=
e notification is suppressed? (I can't think of such an attack, off the=
 top of my head, but then, that's probably
 why I'm not a hacker. ;^, )
    

    =C2=A0
    

    Best wishes,
    

    Robin=C2=A0

    

    =C2=A0
    

    Robin,
    

    =C2=A0
    

    With respect to your threat concerns, can yo=
u be more clear about the threats you=E2=80=99re considering? Here are a fe=
w things that come to mind:
    

    =C2=A0
    

    
1.=C2=
=A0=C2=A0=C2=A0=C2=A0
TLS Server has all of the decrypted data and can prov=
ide that to a third party (whether compelled or otherwise) without any indi=
cation to the TLS client. This seems true
 TLS 1.3 today.
    

    
2.=C2=
=A0=C2=A0=C2=A0=C2=A0
TLS Server has their ephemeral DH keys and session ke=
ys and can provide them to a third party without any indication to the TLS =
client. This seems true with TLS 1.3 today.
    

    
3.=C2=
=A0=C2=A0=C2=A0=C2=A0
TLS Server can create a TLS server implementation tha=
t uses static DH keys and provide them to a third party. The client can use=
 methods to detect this (though there are
 measures and countermeasures here). This is true seems TLS 1.3 today.
    

    
4.=C2=
=A0=C2=A0=C2=A0=C2=A0
TLS Client has all of the decrypted data and can prov=
ide that to a third party (whether compelled or otherwise) without any indi=
cation to the TLS server. This seems true
 in TLS 1.3 today.
    

    
5.=C2=
=A0=C2=A0=C2=A0=C2=A0
TLS Client has their ephemeral DH keys and session ke=
ys and can provide them to a third party without any indication to the TLS =
server. This seems true with TLS 1.3 today.
    

    =C2=A0
    

    I believe Russ was outlining a method where =
an extension would be added to TLS 1.3 that would provide for delivery of a=
 decryption key to a third party during the handshake
 (correct me if I got that wrong, Russ). Because it would be during the han=
dshake, it would seem to be visible to the TLS=C2=A0 Client=E2=80=94in fact=
, the client would have to include the extension to begin with. If the TLS =
client saw the extension and did not consent,
 it could abort the connection. If the TLS Server were attempting to provid=
e access to the exchanged data to a third party, it would seem they could u=
se 1, 2, or 3 above and not have to go to the trouble of attempting to subv=
ert the mechanism that Russ proposes
 (and others have previously proposed). 
    

    =C2=A0
    

    Can you clarify?
    

    =C2=A0
    

    Paul
    

    

    

    

    

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

    

    

    

    

    



    

--94eb2c1305901d63d60554be6089--


From nobody Thu Jul 20 04:54:23 2017
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 89335131C16 for ; Thu, 20 Jul 2017 04:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w519mklgBpw2 for ; Thu, 20 Jul 2017 04:54:00 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE47131C19 for ; Thu, 20 Jul 2017 04:53:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CBB77BE4D; Thu, 20 Jul 2017 12:53:48 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8VnwZ7KzDJ3; Thu, 20 Jul 2017 12:53:47 +0100 (IST)
Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1C660BE4C; Thu, 20 Jul 2017 12:53:46 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500551627; bh=iSKOt9wGFv6eBqcwzRf657/V7og6quzT6YCQbRoOTNc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HB4OSpoQNDsDN6J7VikU52w4PX22jCkTa2GwIgsQydTmeJEDfF92hBCDeqUXgrRH1 IyIeAfKD5Fs6X/Nh2w8qUcTb0+In1TMfkJOBUSlL3eUgwt9SmDwMrj2Ecgoc9p37B/ 0SHJsznjfMo4pvRF1uCDC2ZERQGn9FJ3QBHgxKHQ=
To: Paul Turner , Ted Lemon 
Cc: Robin Wilton , "" 
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Thu, 20 Jul 2017 12:53:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <691913e7a5d1464e8dda20c8848f6149@venafi.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FCkKFdxOkgE5pfknKAIwEsHfpt4BSgmj8"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 11:54:03 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--FCkKFdxOkgE5pfknKAIwEsHfpt4BSgmj8
Content-Type: multipart/mixed; boundary="aNhTfwwMgCNfGAP7qTUCiRcD0t2sC3QK7";
 protected-headers="v1"
From: Stephen Farrell 
To: Paul Turner , Ted Lemon 
Cc: Robin Wilton , "" 
Message-ID: 
Subject: Re: [TLS] Is there a way forward after today's hum?
References: 
 
 
 <691913e7a5d1464e8dda20c8848f6149@venafi.com>
In-Reply-To: <691913e7a5d1464e8dda20c8848f6149@venafi.com>

--aNhTfwwMgCNfGAP7qTUCiRcD0t2sC3QK7
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 20/07/17 12:44, Paul Turner wrote:
>=20
> I believe Russ was outlining a method where an extension would be
> added to TLS 1.3 that would provide for delivery of a decryption key
> to a third party during the handshake (correct me if I got that
> wrong, Russ). Because it would be during the handshake, it would seem
> to be visible to the TLS  Client=E2=80=94in fact, the client would have=
 to
> include the extension to begin with. If the TLS client saw the
> extension and did not consent, it could abort the connection. If the
> TLS Server were attempting to provide access to the exchanged data to
> a third party, it would seem they could use 1, 2, or 3 above and not
> have to go to the trouble of attempting to subvert the mechanism that
> Russ proposes (and others have previously proposed).
Yeah, good try, but *which* third party?

The kind of (IMO) intractable questions that Would arise
include whether or not enterprise clients only want their
own snoopers to snoop and not everyone else's? And then
the naming issues become intractable. And of course in
many applications (e.g. SMTP) there's still >1 TLS session
in the mail e2e path. And in the web there can be >1 box
between the browser and content site. Yoav already brought
up another one about about:config, and, and, and...

In the end, this'd be another failed proposal is my bet.
I volunteer to help in the engineering of that if needed;-)

That's not to doubt or deride the folks posing illformed
requirements but because squaring circles is just not a
good plan.

S.


--aNhTfwwMgCNfGAP7qTUCiRcD0t2sC3QK7--

--FCkKFdxOkgE5pfknKAIwEsHfpt4BSgmj8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZcJnJAAoJEC88hzaAX42iOdEIAL1LP07M0Rt5EffMa592c2zs
dILUDrtSZp9NGRCjje5yr1jEXNs2v/i0K4BzFhIHXoNwFj2zTu1Eu8ejmg+E/JiY
jZengu+fMZfsZx01sauPGLHSCym/34RkmxQWiYMcSFfnHeXpaKxvx942T1BMHtst
0CmZlpgMOOpZurTK8/prBejge9bDTwWm/Sjer/5ovBzKyxnbUjKxrHFoXO3rqcFH
coT5UWxyxfSS7HEGy/1ljfCRzqKuHTW9OO2wSUSo/Z4yPWPQkjM0R0vJ0HdJRv+I
LEmA6IGcHg0x7Kgdzs12XlCVxsA4df9tssYFYotN+9eFL4sz4n2BxLXmEQ5S1r8=
=YqXJ
-----END PGP SIGNATURE-----

--FCkKFdxOkgE5pfknKAIwEsHfpt4BSgmj8--


From nobody Thu Jul 20 04:58:22 2017
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 98BCB131C23 for ; Thu, 20 Jul 2017 04:58:20 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=equio-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 TcmuIisVF9d0 for ; Thu, 20 Jul 2017 04:58:12 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C32412EA7C for ; Thu, 20 Jul 2017 04:58:12 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id o88so11547538pfk.3 for ; Thu, 20 Jul 2017 04:58:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=equio-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=gIwe/4DcQzasKtw7xAWtvOhdPOzp5z7qkEDjRP3brfk=; b=jAl/hMHHgO0bM2SLf4yplqxErNni4FOS5S2CYHk15NJJWeODtLgzJTtzwqJ/D7Y5UN N1qtX5txN7yIdrKOZJbZS+EksMZEp23HjWL79Jcz/omBmCpAFpy69yLD5jIDTr0d5cLE nc0iRSFQ+iGty4fqw3r4SsALj/+/5/Mm/MIROZzwtpURDDi6+Wk3EDCWf+m4Cq060Sdi OtC29m98IEWX95ToLBtjYIRQUF0DA4bb3f+rtLew59OG8vbNZuqUmYbOc7+HpEEvsHGp I816YCrHE+r1hBAA455qOmfkeDCYQEAAtdjR4+/gCLmGekEalM7z8hCvDsHQeynMmBEo +XRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=gIwe/4DcQzasKtw7xAWtvOhdPOzp5z7qkEDjRP3brfk=; b=iSyWSOpW7viejLpwb1qyhJyIThctNl8KVvFRWMjrybzf0l3pYDSEhCb1IwwtW/ic3u 0QHVIm4qPI3ENC6S3kfrfaIqVQWmJkWBO7gqGnIPOtTxt7avFxi/FI14bv2vzqJH+X/K XiG3TiCkxgQ4pwDwgZiRNhxYTRdSwpSMc7yqtmyXLHBcuQ+0rQc7XjEPnpkBwZbhQFJC gZ2p7r4dE8lbJDJXUxr6DMkp1w6tQOP7H8pdMq0UUwVyjOlmlkoHafBj92uEVomy/jFM XGO98WEpnrApFk+GrvBMKiWj8olt2x+9pE3vmTCqdnsYAA2r4O4Njcut8b2YBhGYny6F Ksfw==
X-Gm-Message-State: AIVw1100OLIvVtYYfNw3jHjL82l0xWTG8efuBacL7nlOmiDd7MTlTnLH HPd1fZuNuVLPOgxmrwhLYQ==
X-Received: by 10.84.132.110 with SMTP id 101mr3989100ple.203.1500551891952; Thu, 20 Jul 2017 04:58:11 -0700 (PDT)
Received: from 07WKSWIN150119 (35.sub-70-197-5.myvzw.com. [70.197.5.35]) by smtp.gmail.com with ESMTPSA id w66sm4440618pfi.63.2017.07.20.04.58.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 04:58:10 -0700 (PDT)
From: "Paul Turner" 
To: "'Ted Lemon'" , "'Paul Turner'" 
Cc: "'Robin Wilton'" , 
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com> 
In-Reply-To: 
Date: Thu, 20 Jul 2017 07:58:04 -0400
Message-ID: <015901d3014f$7512b200$5f381600$@equio.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_015A_01D3012D.EE05CCF0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQGZY5pvJzH4JA3szzi/CxpFoIjfXQLdWXcYAXcHzP4C7Y10YQLthJnBon5bW+A=
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 11:58:21 -0000

This is a multipart message in MIME format.

------=_NextPart_000_015A_01D3012D.EE05CCF0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=20

=20

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 07:51
To: Paul Turner 
Cc: Robin Wilton ;  
Subject: Re: [TLS] Is there a way forward after today's hum?

=20

Paul, the reason to use the MiTM approach rather than simply hacking the =
endpoint the attacker controls is that it may be much more convenient to =
be running out-of-the-box software on the endpoint.   The MiTM isn't an =
attacker from the perspective of the controlled endpoint; it is simply a =
convenient way to conceal what is being done.

=20

To make sure I understand your reference to MiTM, is that different than =
the third party in #2 and #3 below?

=20

Having thought about it some more, as Russ points out, it might be too =
expensive to be worth doing, because you'd have to hack the whole =
stream.   It would not, for example, be a useful passive attack, =
obviously.

=20

That said, suppose this extension were added to everyone's TLS =
libraries.   Now the number of lines of code I'd have to #ifdef out to =
avoid setting the evil bit would be much less than if it weren't.

=20

=20

On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner  > wrote:

=20

=20

From: TLS [mailto:tls-bounces@ietf.org  ] =
On Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 07:25
To: Paul Turner  =
>
Cc: Robin Wilton  >; =
 >  >
Subject: Re: [TLS] Is there a way forward after today's hum?

=20

Paul, it would be trivial to normal that exchange to conceal from the =
client that a static key is being used. No software mods required on =
either end: just in the middle.=20

=20

Thanks, Ted. Can you expand on this?=20

=20

Also, can you also put it in the context of a threat model as Robin =
suggested? I=E2=80=99ve suggested some things below but may not have it =
right. Why would the attacker take this approach versus some of the =
readily available methods?

=20

Paul

=20

On Jul 20, 2017 1:04 PM, "Paul Turner"  > wrote:

=20

=20

From: TLS [mailto:tls-bounces@ietf.org  ] =
On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: tls@ietf.org =20
Subject: Re: [TLS] Is there a way forward after today's hum?

=20

Apologies for not replying "in thread" on this occasion, for noob =
reasons... but here's the specific comment from Russ that I wanted to =
respond to:

=20


  _____ =20

The hum told us that the room was roughly evenly split.  In hind sight, =
I wish the chairs had asked a second question.  If the split in the room =
was different for the second question, then I think we might have =
learned a bit more about what people are thinking.
=20
If a specification were available that used an extension that involved =
both the client and the server, would the working group adopt it, work =
on it, and publish it as an RFC?
=20
I was listening very carefully to the comments made by people in line.  =
Clearly some people would hum for "no" to the above question, but it =
sounded like many felt that this would be a significant difference.  It =
would ensure that both server and client explicitly opt-in, and any =
party observing the handshake could see the extension was included or =
not.
=20
Russ

=3D=3D=3D=3D

=20

Stephen Farrell articulated a concern with that approach - namely, that =
if we are relying on a setting that is meant to ensure both parties must =
be aware that static DH is in use, then a bad actor would find ways to =
suppress that notification. In your proposal, Russ, the notification =
mechanism would take the form of an extension... so I think we would =
need to understand what the failsafe is, for instance if that extension =
is disabled, or not present, in a given deployment of TLS.

=20

There's an implicit assumption about the threat model, too, which I just =
want to call out. The assumption is that a bad actor would suppress the =
notification so that the client is not aware that static DH is in use. =
For completeness, should we also consider whether there are attacks in =
which it's the *server* whose notification is suppressed? (I can't think =
of such an attack, off the top of my head, but then, that's probably why =
I'm not a hacker. ;^, )

=20

Best wishes,

Robin =20

=20

Robin,

=20

With respect to your threat concerns, can you be more clear about the =
threats you=E2=80=99re considering? Here are a few things that come to =
mind:

=20

1.     TLS Server has all of the decrypted data and can provide that to =
a third party (whether compelled or otherwise) without any indication to =
the TLS client. This seems true TLS 1.3 today.

2.     TLS Server has their ephemeral DH keys and session keys and can =
provide them to a third party without any indication to the TLS client. =
This seems true with TLS 1.3 today.

3.     TLS Server can create a TLS server implementation that uses =
static DH keys and provide them to a third party. The client can use =
methods to detect this (though there are measures and countermeasures =
here). This is true seems TLS 1.3 today.

4.     TLS Client has all of the decrypted data and can provide that to =
a third party (whether compelled or otherwise) without any indication to =
the TLS server. This seems true in TLS 1.3 today.

5.     TLS Client has their ephemeral DH keys and session keys and can =
provide them to a third party without any indication to the TLS server. =
This seems true with TLS 1.3 today.

=20

I believe Russ was outlining a method where an extension would be added =
to TLS 1.3 that would provide for delivery of a decryption key to a =
third party during the handshake (correct me if I got that wrong, Russ). =
Because it would be during the handshake, it would seem to be visible to =
the TLS  Client=E2=80=94in fact, the client would have to include the =
extension to begin with. If the TLS client saw the extension and did not =
consent, it could abort the connection. If the TLS Server were =
attempting to provide access to the exchanged data to a third party, it =
would seem they could use 1, 2, or 3 above and not have to go to the =
trouble of attempting to subvert the mechanism that Russ proposes (and =
others have previously proposed).=20

=20

Can you clarify?

=20

Paul


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

=20


------=_NextPart_000_015A_01D3012D.EE05CCF0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


     
     
    From:<=
/b> =
TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ted =
Lemon
    Sent: Thursday, July 20, 2017 07:51
    To: Paul =
Turner <PAUL.TURNER@venafi.com>
    Cc: Robin Wilton =
<wilton@isoc.org>; <tls@ietf.org> =
<tls@ietf.org>
    Subject: Re: [TLS] Is there a way forward =
after today's hum?
     
    Paul, the reason to use the =
MiTM approach rather than simply hacking the endpoint the attacker =
controls is that it may be much more convenient to be running =
out-of-the-box software on the endpoint.   The MiTM isn't an =
attacker from the perspective of the controlled endpoint; it is simply a =
convenient way to conceal what is being done.
     
    To make sure =
I understand your reference to MiTM, is that different than the third =
party in #2 and #3 below?
     
    Having thought about it =
some more, as Russ points out, it might be too expensive to be worth =
doing, because you'd have to hack the whole stream.   It would not, =
for example, be a useful passive attack, =
obviously.
     
    That said, suppose this =
extension were added to everyone's TLS libraries.   Now the number =
of lines of code I'd have to #ifdef out to avoid setting the evil bit =
would be much less than if it weren't.
     
     
    On Thu, Jul 20, 2017 at =
1:44 PM, Paul Turner <PAUL.TURNER@venafi.com> =
wrote:
     =

     =

    From:<=
/b> =
TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ted =
Lemon
    Sent: Thursday, July 20, 2017 07:25
    To: Paul =
Turner <PAUL.TURNER@venafi.com>
    Cc: Robin =
Wilton <wilton@isoc.org>; <tls@ietf.org> =
<tls@ietf.org>
    Subject: Re: [TLS] Is =
there a way forward after today's hum?
     
    Paul, it would be trivial to normal that exchange to conceal from =
the client that a static key is being used. No software mods required on =
either end: just in the middle. 
     =

    Thanks, Ted. =
Can you expand on this? 
     =

    Also, can =
you also put it in the context of a threat model as Robin suggested? =
I=E2=80=99ve suggested some things below but may not have it right. Why =
would the attacker take this approach versus some of the readily =
available methods?
     =

    Paul
     
    On Jul 20, 2017 1:04 PM, "Paul Turner" <PAUL.TURNER@venafi.com> =
wrote:
     =

     =

    From:<=
/b> =
TLS [mailto:tls-bounces@ietf.org] On Behalf Of Robin =
Wilton
    Sent: Thursday, July 20, 2017 05:58
    To: tls@ietf.org
    Subject: Re: [TLS] Is there =
a way forward after today's hum?
     
    Apologies for not =
replying "in thread" on this occasion, for noob reasons... but =
here's the specific comment from Russ that I wanted to respond =
to:
     =

    The hum told us =
that the room was roughly evenly split.  In hind sight, I wish the =
chairs had asked a second question.  If the split in the room was =
different for the second question, then I think we might have learned a =
bit more about what people are thinking.
     
    If a =
specification were available that used an extension that involved both =
the client and the server, would the working group adopt it, work on it, =
and publish it as an RFC?
     
    I was listening =
very carefully to the comments made by people in line.  Clearly =
some people would hum for "no" to the above question, but it =
sounded like many felt that this would be a significant =
difference.  It would ensure that both server and client explicitly =
opt-in, and any party observing the handshake could see the extension =
was included or not.
     
    Russ
    =3D=3D=3D=3D
     =

    Stephen Farrell =
articulated a concern with that approach - namely, that if we are =
relying on a setting that is meant to ensure both parties must be aware =
that static DH is in use, then a bad actor would find ways to suppress =
that notification. In your proposal, Russ, the notification mechanism =
would take the form of an extension... so I think we would need to =
understand what the failsafe is, for instance if that extension is =
disabled, or not present, in a given deployment of =
TLS.
     =

    There's an =
implicit assumption about the threat model, too, which I just want to =
call out. The assumption is that a bad actor would suppress the =
notification so that the client is not aware that static DH is in use. =
For completeness, should we also consider whether there are attacks in =
which it's the *server* whose notification is suppressed? (I can't think =
of such an attack, off the top of my head, but then, that's probably why =
I'm not a hacker. ;^, )
     =

    Best =
wishes,
    Robin  =

     =

    Robin,=

     =

    With respect =
to your threat concerns, can you be more clear about the threats =
you=E2=80=99re considering? Here are a few things that come to =
mind:
     =

    1.     =
TLS Server =
has all of the decrypted data and can provide that to a third party =
(whether compelled or otherwise) without any indication to the TLS =
client. This seems true TLS 1.3 today.
    2.     =
TLS Server =
has their ephemeral DH keys and session keys and can provide them to a =
third party without any indication to the TLS client. This seems true =
with TLS 1.3 today.
    3.     =
TLS Server =
can create a TLS server implementation that uses static DH keys and =
provide them to a third party. The client can use methods to detect this =
(though there are measures and countermeasures here). This is true seems =
TLS 1.3 today.
    4.     =
TLS Client =
has all of the decrypted data and can provide that to a third party =
(whether compelled or otherwise) without any indication to the TLS =
server. This seems true in TLS 1.3 today.
    5.     =
TLS Client =
has their ephemeral DH keys and session keys and can provide them to a =
third party without any indication to the TLS server. This seems true =
with TLS 1.3 today.
     =

    I believe =
Russ was outlining a method where an extension would be added to TLS 1.3 =
that would provide for delivery of a decryption key to a third party =
during the handshake (correct me if I got that wrong, Russ). Because it =
would be during the handshake, it would seem to be visible to the =
TLS  Client=E2=80=94in fact, the client would have to include the =
extension to begin with. If the TLS client saw the extension and did not =
consent, it could abort the connection. If the TLS Server were =
attempting to provide access to the exchanged data to a third party, it =
would seem they could use 1, 2, or 3 above and not have to go to the =
trouble of attempting to subvert the mechanism that Russ proposes (and =
others have previously proposed). 
     =

    Can you =
clarify?
     =

    Paul
    =

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


From nobody Thu Jul 20 05:04:20 2017
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 45C6212EA7C for ; Thu, 20 Jul 2017 05:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 BAm_dmwE2Sqs for ; Thu, 20 Jul 2017 05:04:17 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B183F126E3A for ; Thu, 20 Jul 2017 05:04:17 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG01.res.venafi.com (10.1.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 06:04:16 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 06:04:16 -0600
From: Paul Turner 
To: Stephen Farrell , Paul Turner , Ted Lemon 
CC: Robin Wilton , "" 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQGZY5pvJzH4JA3szzi/CxpFoIjfXaLPvrHggAB0dYCAAAVSoIAAApaAgAAC7XA=
Date: Thu, 20 Jul 2017 12:04:16 +0000
Message-ID: <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.197.5.35]
Content-Type: multipart/alternative; boundary="_000_373f65c7c1e8483c9efdf06bbc5671cfvenaficom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 12:04:19 -0000

--_000_373f65c7c1e8483c9efdf06bbc5671cfvenaficom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIFttYWlsdG86dGxz
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IFRo
dXJzZGF5LCBKdWx5IDIwLCAyMDE3IDA3OjU0DQpUbzogUGF1bCBUdXJuZXIgPFBBVUwuVFVSTkVS
QHZlbmFmaS5jb20+OyBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpDYzogUm9iaW4gV2ls
dG9uIDx3aWx0b25AaXNvYy5vcmc+OyA8dGxzQGlldGYub3JnPiA8dGxzQGlldGYub3JnPg0KU3Vi
amVjdDogUmU6IFtUTFNdIElzIHRoZXJlIGEgd2F5IGZvcndhcmQgYWZ0ZXIgdG9kYXkncyBodW0/
DQoNCg0KDQoNCg0KDQoNCk9uIDIwLzA3LzE3IDEyOjQ0LCBQYXVsIFR1cm5lciB3cm90ZToNCg0K
Pg0KDQo+IEkgYmVsaWV2ZSBSdXNzIHdhcyBvdXRsaW5pbmcgYSBtZXRob2Qgd2hlcmUgYW4gZXh0
ZW5zaW9uIHdvdWxkIGJlDQoNCj4gYWRkZWQgdG8gVExTIDEuMyB0aGF0IHdvdWxkIHByb3ZpZGUg
Zm9yIGRlbGl2ZXJ5IG9mIGEgZGVjcnlwdGlvbiBrZXkNCg0KPiB0byBhIHRoaXJkIHBhcnR5IGR1
cmluZyB0aGUgaGFuZHNoYWtlIChjb3JyZWN0IG1lIGlmIEkgZ290IHRoYXQgd3JvbmcsDQoNCj4g
UnVzcykuIEJlY2F1c2UgaXQgd291bGQgYmUgZHVyaW5nIHRoZSBoYW5kc2hha2UsIGl0IHdvdWxk
IHNlZW0gdG8gYmUNCg0KPiB2aXNpYmxlIHRvIHRoZSBUTFMgIENsaWVudOKAlGluIGZhY3QsIHRo
ZSBjbGllbnQgd291bGQgaGF2ZSB0byBpbmNsdWRlDQoNCj4gdGhlIGV4dGVuc2lvbiB0byBiZWdp
biB3aXRoLiBJZiB0aGUgVExTIGNsaWVudCBzYXcgdGhlIGV4dGVuc2lvbiBhbmQNCg0KPiBkaWQg
bm90IGNvbnNlbnQsIGl0IGNvdWxkIGFib3J0IHRoZSBjb25uZWN0aW9uLiBJZiB0aGUgVExTIFNl
cnZlciB3ZXJlDQoNCj4gYXR0ZW1wdGluZyB0byBwcm92aWRlIGFjY2VzcyB0byB0aGUgZXhjaGFu
Z2VkIGRhdGEgdG8gYSB0aGlyZCBwYXJ0eSwNCg0KPiBpdCB3b3VsZCBzZWVtIHRoZXkgY291bGQg
dXNlIDEsIDIsIG9yIDMgYWJvdmUgYW5kIG5vdCBoYXZlIHRvIGdvIHRvDQoNCj4gdGhlIHRyb3Vi
bGUgb2YgYXR0ZW1wdGluZyB0byBzdWJ2ZXJ0IHRoZSBtZWNoYW5pc20gdGhhdCBSdXNzIHByb3Bv
c2VzDQoNCj4gKGFuZCBvdGhlcnMgaGF2ZSBwcmV2aW91c2x5IHByb3Bvc2VkKS4NCg0KWWVhaCwg
Z29vZCB0cnksIGJ1dCAqd2hpY2gqIHRoaXJkIHBhcnR5Pw0KDQoNCg0KTGV04oCZcyB1c2UgdGhl
IG9wcHJlc3NpdmUgZ292ZXJubWVudCBpbnN0aXR1dGlvbiB0aGF0IEkgYmVsaWV2ZSB5b3XigJl2
ZSBtZW50aW9uZWQgKHBhcmRvbiBtZSBpZiBJIGdvdCB0aGF0IHdyb25nKSB3aXRoIGEgY29ubmVj
dGlvbiBvdmVyIHRoZSBJbnRlcm5ldCBpbiB0aGlzIGNhc2UuIENhbiB5b3UgcmVwbHkgaW4gdGhh
dCBjb250ZXh0PyBJ4oCZbSB0cnVseSBpbnRlcmVzdGVkIGluIHVuZGVyc3RhbmRpbmcuIEl0IHdh
c27igJl0IGEg4oCcdHJ54oCdLg0KDQoNCg0KVGhlIGtpbmQgb2YgKElNTykgaW50cmFjdGFibGUg
cXVlc3Rpb25zIHRoYXQgV291bGQgYXJpc2UgaW5jbHVkZSB3aGV0aGVyIG9yIG5vdCBlbnRlcnBy
aXNlIGNsaWVudHMgb25seSB3YW50IHRoZWlyIG93biBzbm9vcGVycyB0byBzbm9vcCBhbmQgbm90
IGV2ZXJ5b25lIGVsc2Uncz8gQW5kIHRoZW4gdGhlIG5hbWluZyBpc3N1ZXMgYmVjb21lIGludHJh
Y3RhYmxlLiBBbmQgb2YgY291cnNlIGluIG1hbnkgYXBwbGljYXRpb25zIChlLmcuIFNNVFApIHRo
ZXJlJ3Mgc3RpbGwgPjEgVExTIHNlc3Npb24gaW4gdGhlIG1haWwgZTJlIHBhdGguIEFuZCBpbiB0
aGUgd2ViIHRoZXJlIGNhbiBiZSA+MSBib3ggYmV0d2VlbiB0aGUgYnJvd3NlciBhbmQgY29udGVu
dCBzaXRlLiBZb2F2IGFscmVhZHkgYnJvdWdodCB1cCBhbm90aGVyIG9uZSBhYm91dCBhYm91dDpj
b25maWcsIGFuZCwgYW5kLCBhbmQuLi4NCg0KDQoNCkluIHRoZSBlbmQsIHRoaXMnZCBiZSBhbm90
aGVyIGZhaWxlZCBwcm9wb3NhbCBpcyBteSBiZXQuDQoNCkkgdm9sdW50ZWVyIHRvIGhlbHAgaW4g
dGhlIGVuZ2luZWVyaW5nIG9mIHRoYXQgaWYgbmVlZGVkOy0pDQoNCg0KDQpUaGF0J3Mgbm90IHRv
IGRvdWJ0IG9yIGRlcmlkZSB0aGUgZm9sa3MgcG9zaW5nIGlsbGZvcm1lZCByZXF1aXJlbWVudHMg
YnV0IGJlY2F1c2Ugc3F1YXJpbmcgY2lyY2xlcyBpcyBqdXN0IG5vdCBhIGdvb2QgcGxhbi4NCg0K
DQoNClMuDQoNCg0K

--_000_373f65c7c1e8483c9efdf06bbc5671cfvenaficom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp
Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBUTFMgW21h
aWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXBoZW4gRmFycmVsbDxi
cj4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDIwLCAyMDE3IDA3OjU0PGJyPg0KVG86IFBhdWwgVHVy
bmVyICZsdDtQQVVMLlRVUk5FUkB2ZW5hZmkuY29tJmd0OzsgVGVkIExlbW9uICZsdDttZWxsb25A
ZnVndWUuY29tJmd0Ozxicj4NCkNjOiBSb2JpbiBXaWx0b24gJmx0O3dpbHRvbkBpc29jLm9yZyZn
dDs7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVj
dDogUmU6IFtUTFNdIElzIHRoZXJlIGEgd2F5IGZvcndhcmQgYWZ0ZXIgdG9kYXkncyBodW0/PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIDIwLzA3LzE3IDEyOjQ0LCBQYXVsIFR1cm5lciB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsgSSBiZWxpZXZlIFJ1c3Mgd2FzIG91dGxpbmlu
ZyBhIG1ldGhvZCB3aGVyZSBhbiBleHRlbnNpb24gd291bGQgYmUNCjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsgYWRk
ZWQgdG8gVExTIDEuMyB0aGF0IHdvdWxkIHByb3ZpZGUgZm9yIGRlbGl2ZXJ5IG9mIGEgZGVjcnlw
dGlvbiBrZXkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsgdG8gYSB0aGlyZCBwYXJ0eSBkdXJpbmcgdGhlIGhhbmRz
aGFrZSAoY29ycmVjdCBtZSBpZiBJIGdvdCB0aGF0IHdyb25nLA0KPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jmd0OyBSdXNz
KS4gQmVjYXVzZSBpdCB3b3VsZCBiZSBkdXJpbmcgdGhlIGhhbmRzaGFrZSwgaXQgd291bGQgc2Vl
bSB0byBiZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+Jmd0OyB2aXNpYmxlIHRvIHRoZSBUTFMmbmJzcDsgQ2xpZW504oCU
aW4gZmFjdCwgdGhlIGNsaWVudCB3b3VsZCBoYXZlIHRvIGluY2x1ZGUNCjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsg
dGhlIGV4dGVuc2lvbiB0byBiZWdpbiB3aXRoLiBJZiB0aGUgVExTIGNsaWVudCBzYXcgdGhlIGV4
dGVuc2lvbiBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsgZGlkIG5vdCBjb25zZW50LCBpdCBjb3VsZCBhYm9y
dCB0aGUgY29ubmVjdGlvbi4gSWYgdGhlIFRMUyBTZXJ2ZXIgd2VyZQ0KPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jmd0OyBh
dHRlbXB0aW5nIHRvIHByb3ZpZGUgYWNjZXNzIHRvIHRoZSBleGNoYW5nZWQgZGF0YSB0byBhIHRo
aXJkIHBhcnR5LA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jmd0OyBpdCB3b3VsZCBzZWVtIHRoZXkgY291bGQgdXNlIDEs
IDIsIG9yIDMgYWJvdmUgYW5kIG5vdCBoYXZlIHRvIGdvIHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mZ3Q7IHRoZSB0
cm91YmxlIG9mIGF0dGVtcHRpbmcgdG8gc3VidmVydCB0aGUgbWVjaGFuaXNtIHRoYXQgUnVzcyBw
cm9wb3Nlcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+Jmd0OyAoYW5kIG90aGVycyBoYXZlIHByZXZpb3VzbHkgcHJvcG9z
ZWQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPlllYWgsIGdvb2QgdHJ5LCBidXQgKndoaWNoKiB0aGlyZCBwYXJ0eT88bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5MZXTigJlzIHVzZSB0aGUgb3BwcmVzc2l2ZSBn
b3Zlcm5tZW50IGluc3RpdHV0aW9uIHRoYXQgSSBiZWxpZXZlIHlvdeKAmXZlIG1lbnRpb25lZCAo
cGFyZG9uIG1lIGlmIEkgZ290IHRoYXQgd3JvbmcpIHdpdGggYSBjb25uZWN0aW9uIG92ZXIgdGhl
IEludGVybmV0IGluIHRoaXMgY2FzZS4gQ2FuIHlvdSByZXBseSBpbiB0aGF0IGNvbnRleHQ/IEni
gJltIHRydWx5IGludGVyZXN0ZWQNCiBpbiB1bmRlcnN0YW5kaW5nLiBJdCB3YXNu4oCZdCBhIOKA
nHRyeeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGtpbmQgb2YgKElNTykg
aW50cmFjdGFibGUgcXVlc3Rpb25zIHRoYXQgV291bGQgYXJpc2UgaW5jbHVkZSB3aGV0aGVyIG9y
IG5vdCBlbnRlcnByaXNlIGNsaWVudHMgb25seSB3YW50IHRoZWlyIG93biBzbm9vcGVycyB0byBz
bm9vcCBhbmQgbm90IGV2ZXJ5b25lIGVsc2Uncz8gQW5kIHRoZW4gdGhlIG5hbWluZyBpc3N1ZXMg
YmVjb21lIGludHJhY3RhYmxlLg0KIEFuZCBvZiBjb3Vyc2UgaW4gbWFueSBhcHBsaWNhdGlvbnMg
KGUuZy4gU01UUCkgdGhlcmUncyBzdGlsbCAmZ3Q7MSBUTFMgc2Vzc2lvbiBpbiB0aGUgbWFpbCBl
MmUgcGF0aC4gQW5kIGluIHRoZSB3ZWIgdGhlcmUgY2FuIGJlICZndDsxIGJveCBiZXR3ZWVuIHRo
ZSBicm93c2VyIGFuZCBjb250ZW50IHNpdGUuIFlvYXYgYWxyZWFkeSBicm91Z2h0IHVwIGFub3Ro
ZXIgb25lIGFib3V0IGFib3V0OmNvbmZpZywgYW5kLCBhbmQsIGFuZC4uLjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPkluIHRoZSBlbmQsIHRoaXMnZCBiZSBhbm90aGVyIGZhaWxlZCBwcm9wb3NhbCBp
cyBteSBiZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+SSB2b2x1bnRlZXIgdG8gaGVscCBpbiB0aGUgZW5naW5lZXJpbmcg
b2YgdGhhdCBpZiBuZWVkZWQ7LSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGF0J3Mgbm90IHRv
IGRvdWJ0IG9yIGRlcmlkZSB0aGUgZm9sa3MgcG9zaW5nIGlsbGZvcm1lZCByZXF1aXJlbWVudHMg
YnV0IGJlY2F1c2Ugc3F1YXJpbmcgY2lyY2xlcyBpcyBqdXN0IG5vdCBhIGdvb2QgcGxhbi48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj5TLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_373f65c7c1e8483c9efdf06bbc5671cfvenaficom_--


From nobody Thu Jul 20 05:06:39 2017
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 F23D8131C1E for ; Thu, 20 Jul 2017 05:06:36 -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=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 66K5-Hw654xI for ; Thu, 20 Jul 2017 05:06:33 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 53EEF126E3A for ; Thu, 20 Jul 2017 05:06:33 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id q85so11682438pfq.1 for ; Thu, 20 Jul 2017 05:06:33 -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=NYCSm+nvjGqL03CNdncunIl7mo7oNl2OYHPTXB+w9AY=; b=cy1MqT5Ki2zaL2uHpV+zlytF6Fhq3r3SUCPR8KmGMtRu3K68zJ+rZ+m7RJWxgoN5rN DBzh98tHSympQNS2wdPsazZCyel9B4jph93d5e6UhFgUXLse4W8qwJaFnoaJbXxqW9Zz 91f/MNFSVidBhdKuHRO+0M5GGZR/lhb47Gdxr8yrN6hPT0yJRxl83buAXrP07JoJDelv IPDR8O1IQj5Z/tpimfgU5HxdjHJf2pFHOcpNJ6mjO7FbcW5Kx4/CflVnCKy53IImhcog EUr3zNgGPh3/yiscoLbxfks6Gj2oJR9tk2eZc3kz20DwVgVffwh5pXoaDyzzlyIkJl+D aCgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NYCSm+nvjGqL03CNdncunIl7mo7oNl2OYHPTXB+w9AY=; b=odXynpUzlX7lykB3gYGl5oSMNjGPSWR1O5W9Ogy7RXxZXW4Q5JfsWpVjEfRkEhg3iS NKPBPFoK9vO01ntbRa32/Gg7mIWDmF9OP0X1u3xso9AfDoL4tEDx626M6HmUmUpBcuqr mlo8fCfWNdootbiuH96aTCfQUVsGTUHIinMsEEX7PkvoJERSk3ZjSVIezGNteCe0mTyz Hp4SmFvAYFBG0uOIJo0/MYAOnVUGlY6g5C4cMeOd9iwbs5x4PRtio73gFB+EA1Ak4CzJ y3S8qbqYr00NZboKF3hGQyMWoIHBQO1A9plCinCEssExO8ghil7nEW/Cjh47DpH5BeTn OXpw==
X-Gm-Message-State: AIVw113Mhh1WgM4BM3rvsztI/aWC+HoH5bqG28/ZjcCFiQA4rCCndzoC 9pkAV1AtEvUw8d7mwx2eUeKcN9RlqPU5
X-Received: by 10.98.139.134 with SMTP id e6mr3586840pfl.111.1500552392662; Thu, 20 Jul 2017 05:06:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 05:05:51 -0700 (PDT)
In-Reply-To: <015901d3014f$7512b200$5f381600$@equio.com>
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com>  <015901d3014f$7512b200$5f381600$@equio.com>
From: Ted Lemon 
Date: Thu, 20 Jul 2017 14:05:51 +0200
Message-ID: 
To: Paul Turner 
Cc: Paul Turner , Robin Wilton ,  "" 
Content-Type: multipart/alternative; boundary="f403045c432254f7de0554be945d"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 12:06:37 -0000

--f403045c432254f7de0554be945d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It's a variant of (3).

What your threat models do not take into account is how these attacks
relate to the problem they are proposed to solve.   The reason we're even
having this discussion is because some data center operators feel that
having ephemeral keys is too onerous, and that they would like the IETF to
weaken TLS 1.3 to no longer require this.

So if you just consider this problem in the abstract as a serious of
potential threat models, you're somewhat missing the point.   From my
perspective, the problem here is that to address this use case, we are
being asked to make a change to TLS which will make every existing
implementation of TLS that conforms to the change weaker.

It is certainly true that TLS 1.3 isn't resistant to the threats you've
described; that's not the point.   The point is that TLS 1.3 makes each of
these threats substantially more expensive to pull off, with more moving
parts and more people with a need to know.   It does not make the attacks
impossible, or even impossible to do in secret.  It makes them harder, and
harder to do in secret.

On Thu, Jul 20, 2017 at 1:58 PM, Paul Turner  wrote:

>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:51
> *To:* Paul Turner 
> *Cc:* Robin Wilton ;  
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Paul, the reason to use the MiTM approach rather than simply hacking the
> endpoint the attacker controls is that it may be much more convenient to =
be
> running out-of-the-box software on the endpoint.   The MiTM isn't an
> attacker from the perspective of the controlled endpoint; it is simply a
> convenient way to conceal what is being done.
>
>
>
> To make sure I understand your reference to MiTM, is that different than
> the third party in #2 and #3 below?
>
>
>
> Having thought about it some more, as Russ points out, it might be too
> expensive to be worth doing, because you'd have to hack the whole stream.
> It would not, for example, be a useful passive attack, obviously.
>
>
>
> That said, suppose this extension were added to everyone's TLS libraries.
>   Now the number of lines of code I'd have to #ifdef out to avoid setting
> the evil bit would be much less than if it weren't.
>
>
>
>
>
> On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner 
> wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:25
> *To:* Paul Turner 
> *Cc:* Robin Wilton ;  
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Paul, it would be trivial to normal that exchange to conceal from the
> client that a static key is being used. No software mods required on eith=
er
> end: just in the middle.
>
>
>
> Thanks, Ted. Can you expand on this?
>
>
>
> Also, can you also put it in the context of a threat model as Robin
> suggested? I=E2=80=99ve suggested some things below but may not have it r=
ight. Why
> would the attacker take this approach versus some of the readily availabl=
e
> methods?
>
>
>
> Paul
>
>
>
> On Jul 20, 2017 1:04 PM, "Paul Turner"  wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Apologies for not replying "in thread" on this occasion, for noob
> reasons... but here's the specific comment from Russ that I wanted to
> respond to:
>
>
> ------------------------------
>
> The hum told us that the room was roughly evenly split.  In hind sight, I=
 wish the chairs had asked a second question.  If the split in the room was=
 different for the second question, then I think we might have learned a bi=
t more about what people are thinking.
>
>
>
> If a specification were available that used an extension that involved bo=
th the client and the server, would the working group adopt it, work on it,=
 and publish it as an RFC?
>
>
>
> I was listening very carefully to the comments made by people in line.  C=
learly some people would hum for "no" to the above question, but it sounded=
 like many felt that this would be a significant difference.  It would ensu=
re that both server and client explicitly opt-in, and any party observing t=
he handshake could see the extension was included or not.
>
>
>
> Russ
>
> =3D=3D=3D=3D
>
>
>
> Stephen Farrell articulated a concern with that approach - namely, that i=
f
> we are relying on a setting that is meant to ensure both parties must be
> aware that static DH is in use, then a bad actor would find ways to
> suppress that notification. In your proposal, Russ, the notification
> mechanism would take the form of an extension... so I think we would need
> to understand what the failsafe is, for instance if that extension is
> disabled, or not present, in a given deployment of TLS.
>
>
>
> There's an implicit assumption about the threat model, too, which I just
> want to call out. The assumption is that a bad actor would suppress the
> notification so that the client is not aware that static DH is in use. Fo=
r
> completeness, should we also consider whether there are attacks in which
> it's the *server* whose notification is suppressed? (I can't think of suc=
h
> an attack, off the top of my head, but then, that's probably why I'm not =
a
> hacker. ;^, )
>
>
>
> Best wishes,
>
> Robin
>
>
>
> Robin,
>
>
>
> With respect to your threat concerns, can you be more clear about the
> threats you=E2=80=99re considering? Here are a few things that come to mi=
nd:
>
>
>
> 1.     TLS Server has all of the decrypted data and can provide that to a
> third party (whether compelled or otherwise) without any indication to th=
e
> TLS client. This seems true TLS 1.3 today.
>
> 2.     TLS Server has their ephemeral DH keys and session keys and can
> provide them to a third party without any indication to the TLS client.
> This seems true with TLS 1.3 today.
>
> 3.     TLS Server can create a TLS server implementation that uses static
> DH keys and provide them to a third party. The client can use methods to
> detect this (though there are measures and countermeasures here). This is
> true seems TLS 1.3 today.
>
> 4.     TLS Client has all of the decrypted data and can provide that to a
> third party (whether compelled or otherwise) without any indication to th=
e
> TLS server. This seems true in TLS 1.3 today.
>
> 5.     TLS Client has their ephemeral DH keys and session keys and can
> provide them to a third party without any indication to the TLS server.
> This seems true with TLS 1.3 today.
>
>
>
> I believe Russ was outlining a method where an extension would be added t=
o
> TLS 1.3 that would provide for delivery of a decryption key to a third
> party during the handshake (correct me if I got that wrong, Russ). Becaus=
e
> it would be during the handshake, it would seem to be visible to the TLS
> Client=E2=80=94in fact, the client would have to include the extension to=
 begin
> with. If the TLS client saw the extension and did not consent, it could
> abort the connection. If the TLS Server were attempting to provide access
> to the exchanged data to a third party, it would seem they could use 1, 2=
,
> or 3 above and not have to go to the trouble of attempting to subvert the
> mechanism that Russ proposes (and others have previously proposed).
>
>
>
> Can you clarify?
>
>
>
> Paul
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>

--f403045c432254f7de0554be945d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    It's a variant of (3).

    What your th=
reat models do not take into account is how these attacks relate to the pro=
blem they are proposed to solve. =C2=A0 The reason we're even having th=
is discussion is because some data center operators feel that having epheme=
ral keys is too onerous, and that they would like the IETF to weaken TLS 1.=
3 to no longer require this.

    So if you just consid=
er this problem in the abstract as a serious of potential threat models, yo=
u're somewhat missing the point. =C2=A0 From my perspective, the proble=
m here is that to address this use case, we are being asked to make a chang=
e to TLS which will make every existing implementation of TLS that conforms=
 to the change weaker.

    It is certainly true that T=
LS 1.3 isn't resistant to the threats you've described; that's =
not the point. =C2=A0 The point is that TLS 1.3 makes each of these threats=
 substantially more expensive to pull off, with more moving parts and more =
people with a need to know. =C2=A0 It does not make the attacks impossible,=
 or even impossible to do in secret.=C2=A0 It makes them harder, and harder=
 to do in secret.

    On Thu, Jul 20, 2017 at 1:58 PM, Paul Turner =
<pturner@equio.co=
m> wrote:
    =C2=A0
    =C2=A0
    From: TLS [mailto:tls-bounces@ietf.org] On Behalf =
Of Ted Lemon
    Sent: Thursday, July 20, 2017 07:51
    To: Paul Turner <PAUL.TURNER@venafi.com>
    Cc: Robin Wi=
lton <wilton@isoc.o=
rg>; <tls@ietf.=
org> <tls@ietf.=
org>
    Subject: Re: [TLS] Is there a way forward after today=
's hum?
    =C2=A0
    Paul, the reason to use the MiTM approach rather than=
 simply hacking the endpoint the attacker controls is that it may be much m=
ore convenient to be running out-of-the-box software on the endpoint. =C2=
=A0 The MiTM isn't an attacker from the perspective of the controlled e=
ndpoint; it is simply a convenient way to conceal what is being done.
    =C2=A0
    To make sure I understand your reference to MiTM, is that d=
ifferent than the third party in #2 and #3 below?
    <=
div>
    =C2=A0
    Having thought about it some more, as Russ points out, it might=
 be too expensive to be worth doing, because you'd have to hack the who=
le stream. =C2=A0 It would not, for example, be a useful passive attack, ob=
viously.
    =C2=A0
    That said, suppose this extension were added to every=
one's TLS libraries. =C2=A0 Now the number of lines of code I'd hav=
e to #ifdef out to avoid setting the evil bit would be much less than if it=
 weren't.
    =C2=
=A0
    =C2=A0
    On Thu, Jul 20, 2017 at 1:44 =
PM, Paul Turner <PAUL.TURNER@venafi.com> wrote:
    =C2=A0
    =C2=A0
    From: TLS [mailto:tls-bounces@ietf.org<=
/a>] On Behalf Of Ted Lemon
    Sent: Thursday, July 20, 2017 =
07:25
    To: Paul Turner <    PAUL.TURNER@venafi.com>
    Cc: Robin Wil=
ton <wilton@isoc.or=
g>; <tls@ietf.o=
rg> <tls@ietf.o=
rg>
    Subject: Re: [TLS] Is there a way forward after today&=
#39;s hum?
    =C2=A0
    Paul, it would be trivial to normal that exchange to concea=
l from the client that a static key is being used. No software mods require=
d on either end: just in the middle.=C2=A0
    =C2=A0
    Thanks, Ted. Can you expand on t=
his? 
    =C2=A0
    Also, can you also put it in the context of a threat model as =
Robin suggested? I=E2=80=99ve suggested some things below but may not have =
it right. Why would the attacker take this approach versus some of the read=
ily available methods?
    =C2=A0
    Paul
    =C2=A0
    =

    On Jul 20, 2017 1:04 PM,=
 "Paul Turner" <PAUL.TURNER@venafi.com> wrote:
    =C2=
=A0
    =C2=A0
    From: TLS [mailto:tls-bounces@ietf.org] On =
Behalf Of Robin Wilton
    Sent: Thursday, July 20, 2017 05:58To: tls@ietf.org<=
/a>
    Subject: Re: [TLS] Is there a way forward after today's h=
um?
    =C2=A0
    Apologies for not replying "in thread" on this occ=
asion, for noob reasons... but here's the specific comment from Russ th=
at I wanted to respond to:
    =C2=A0
    The hum told us that the room was roughly evenly split.=C2=A0=
 In hind sight, I wish the chairs had asked a second question.=C2=A0 If the=
 split in the room was different for the second question, then I think we m=
ight have learned a bit more about what people are thinking.<=
u>
    =
=C2=A0
    If a specification were available that used an extension=
 that involved both the client and the server, would the working group adop=
t it, work on it, and publish it as an RFC?
    =C2=A0
    =
I was listening very carefully to the comments made by people in line.=C2=
=A0 Clearly some people would hum for "no" to the above question,=
 but it sounded like many felt that this would be a significant difference.=
=C2=A0 It would ensure that both server and client explicitly opt-in, and a=
ny party observing the handshake could see the extension was included or no=
t.
    =C2=A0
    Russ
    =3D=3D=3D=3D
    =C2=A0
    Stephen F=
arrell articulated a concern with that approach - namely, that if we are re=
lying on a setting that is meant to ensure both parties must be aware that =
static DH is in use, then a bad actor would find ways to suppress that noti=
fication. In your proposal, Russ, the notification mechanism would take the=
 form of an extension... so I think we would need to understand what the fa=
ilsafe is, for instance if that extension is disabled, or not present, in a=
 given deployment of TLS.
    =C2=A0
    There's an =
implicit assumption about the threat model, too, which I just want to call =
out. The assumption is that a bad actor would suppress the notification so =
that the client is not aware that static DH is in use. For completeness, sh=
ould we also consider whether there are attacks in which it's the *serv=
er* whose notification is suppressed? (I can't think of such an attack,=
 off the top of my head, but then, that's probably why I'm not a ha=
cker. ;^, )
    =C2=A0
    Best wishes,=

    Robin=C2=A0 
    =C2=A0
    Robin,
    =C2=A0
    With re=
spect to your threat concerns, can you be more clear about the threats you=
=E2=80=99re considering? Here are a few things that come to mind:=

    =C2=A0<=
/p>
    1.=C2=A0=C2=A0=C2=A0=C2=A0 TLS Server has all of the dec=
rypted data and can provide that to a third party (whether compelled or oth=
erwise) without any indication to the TLS client. This seems true TLS 1.3 t=
oday.
    2.=C2=A0=C2=A0=C2=A0=C2=A0 TL=
S Server has their ephemeral DH keys and session keys and can provide them =
to a third party without any indication to the TLS client. This seems true =
with TLS 1.3 today.
    3.=C2=A0=C2=A0=C2=A0=C2=
=A0 TLS Server can create a TLS server implementation that uses sta=
tic DH keys and provide them to a third party. The client can use methods t=
o detect this (though there are measures and countermeasures here). This is=
 true seems TLS 1.3 today.
    4.=C2=A0=C2=A0=
=C2=A0=C2=A0 TLS Client has all of the decrypted data and can provi=
de that to a third party (whether compelled or otherwise) without any indic=
ation to the TLS server. This seems true in TLS 1.3 today.=

    5.=C2=A0=C2=A0=C2=A0=C2=A0 TLS Client has their eph=
emeral DH keys and session keys and can provide them to a third party witho=
ut any indication to the TLS server. This seems true with TLS 1.3 today.
    =C2=A0<=
u>
    I believe Russ was outlining a me=
thod where an extension would be added to TLS 1.3 that would provide for de=
livery of a decryption key to a third party during the handshake (correct m=
e if I got that wrong, Russ). Because it would be during the handshake, it =
would seem to be visible to the TLS=C2=A0 Client=E2=80=94in fact, the clien=
t would have to include the extension to begin with. If the TLS client saw =
the extension and did not consent, it could abort the connection. If the TL=
S Server were attempting to provide access to the exchanged data to a third=
 party, it would seem they could use 1, 2, or 3 above and not have to go to=
 the trouble of attempting to subvert the mechanism that Russ proposes (and=
 others have previously proposed). 
    =C2=A0
    Can you clarify?
    =C2=A0
    Paul

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

    =C2=A0

    

--f403045c432254f7de0554be945d--


From nobody Thu Jul 20 05:21:56 2017
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 1FCA3131C06 for ; Thu, 20 Jul 2017 05:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scU1shdnu-Vl for ; Thu, 20 Jul 2017 05:21:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351CC131A5F for ; Thu, 20 Jul 2017 05:21:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D9017BE50; Thu, 20 Jul 2017 13:21:47 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfhki_uWXt_a; Thu, 20 Jul 2017 13:21:46 +0100 (IST)
Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 51E38BE4D; Thu, 20 Jul 2017 13:21:46 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500553306; bh=XAK9WL37bWod+tndBD9vHn3JJYk17x9UYqH+zvAjj3c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=F5R1tK9W4IBmLJtLTv+WRF+JpGjL8GKR4w0ZJgxwZK3SD/THVFa06vGGEpeyEStKG vuGCfCjhP3Ofao0LqQgyeL4F1cxWnZmVkk2A49Zl+iQy77hUQ+i1yRDTfX9+vH/hOW tcr19rKPCUZj4GJ1WO8rj+qFzUUA96/O2ekkyfzA=
To: Paul Turner , Ted Lemon 
Cc: Robin Wilton , "" 
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com>  <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Thu, 20 Jul 2017 13:21:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c1FE0JnaNdKBEKTwxqKgPh0bb0uKhB5aH"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 12:21:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--c1FE0JnaNdKBEKTwxqKgPh0bb0uKhB5aH
Content-Type: multipart/mixed; boundary="X71tDqSRvLCdksLLlhiAt9orKm0rgXhrB";
 protected-headers="v1"
From: Stephen Farrell 
To: Paul Turner , Ted Lemon 
Cc: Robin Wilton , "" 
Message-ID: 
Subject: Re: [TLS] Is there a way forward after today's hum?
References: 
 
 
 <691913e7a5d1464e8dda20c8848f6149@venafi.com>
 
 <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>
In-Reply-To: <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>

--X71tDqSRvLCdksLLlhiAt9orKm0rgXhrB
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Hiya,

On 20/07/17 13:04, Paul Turner wrote:
> Let=E2=80=99s use the oppressive government institution that I believe =
you=E2=80=99ve
> mentioned (pardon me if I got that wrong) with a connection over the
> Internet in this case.=20

Sorry, I'm not sure what you mean there, but guessing, yes,
there can be multiple nation state actors who would try to
compel use of this mitm, and for a proposal in this space
that also causes intractable problems when a connection is
supposed to be mitm'd by more than one of those, or one is
not clear which is the appropriate nation state attacker
to appease.

> Can you reply in that context? I=E2=80=99m truly
> interested in understanding. It wasn=E2=80=99t a =E2=80=9Ctry=E2=80=9D.=

Hopefully the above helps, but it may also help to say that
the appropriate context I'd consider for TLS is essentially
all the applications of TLS and all the deployments that'd
eventually be updated with whatever proposal is on the table.
(Prior to getting it off the table when it's shown to be
a bad plan:-)

Cheers,
S.




--X71tDqSRvLCdksLLlhiAt9orKm0rgXhrB--

--c1FE0JnaNdKBEKTwxqKgPh0bb0uKhB5aH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZcKBYAAoJEC88hzaAX42iuFsH/j6Nm9uZWF8gvozPWBBZ48IE
tH4STh0c46wyA9d9MlMnKsNLKGFJIz7Ji7hdUQnqsrENB+wuNolvqIAwBN4x/Xhh
CmRyKgVgjxYYMCLyTdqbpSeYEJyXwvZDImVvOWyuRMBzRX+Yu9cFXds2lgdI5W+s
frk5zBpqxUmR52pOIPR+6qhJl6NRaqMwZtAPYhaQGCFQTkbLrVL3z/kfxUPXOR30
8+z/tVIUBT4JUyr0nyJV3lMiuo1KJRDIGeVl3RiOah4N4s3j4mIy2Ubw+AL4/qWm
GqXLizNOEOH1bXSBllpZ0aMUoh74NJ3sydQRdpfHSLKv04MEpyJsrz+0F1p1Mns=
=AvMR
-----END PGP SIGNATURE-----

--c1FE0JnaNdKBEKTwxqKgPh0bb0uKhB5aH--


From nobody Thu Jul 20 05:27:32 2017
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 ED32E12EC30 for ; Thu, 20 Jul 2017 05:27:30 -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, RP_MATCHES_RCVD=-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=iij.ad.jp
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvhfiptq8tBz for ; Thu, 20 Jul 2017 05:27:29 -0700 (PDT)
Received: from omgo.iij.ad.jp (mo901.iij.ad.jp [202.232.31.77]) (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 5C215127058 for ; Thu, 20 Jul 2017 05:27:29 -0700 (PDT)
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Cc:Subject:From:In-Reply-To:References:Mime-Version: Content-Type:Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1500553642; x=1501763242; bh=X6zGPP4glJA6/NyU8OnbyX8wUs5HZLwBkbmF/I52Ufg=; b=x7U0Aqh5rJOONq y85Ce/iA8L2ksGwzn6UITthD6bhtTtm59UgXfILI+oTxXpWXVXe7Bt+FYcsAyPswluNqvDsBcmZjD nD3USXcF4o1hR1Jw0t05lIx3kMHCF+uQ8c1OgDPqvdwOqkraOKa+iLPXoDYKt+SNh9o818eHlGnba HwvB0c9gcun0wfsIupUCDKmXmLY2hQRiT/0YC6r+46J+2aW8tAGiIt9wPqt8WWl4x09r5bv28XnOv w1pLqvsu8BY2FarSiZb7OxHezWxuezjzLkPjotyNYNxMgFtcyBPkRVGD/uv4rL/LZQGbiXCyKmE0V MlpE4gBuZtP8Iy71Rj9w==;
Received: by omgo.iij.ad.jp (mo901) id v6KCRMpe001392; Thu, 20 Jul 2017 21:27:22 +0900
X-Iguazu-Qid: 33PuiKDfF3YaEw6jVQ
Date: Thu, 20 Jul 2017 21:27:18 +0900 (JST)
Message-Id: <20170720.212718.2253444584236714400.kazu@iij.ad.jp>
To: frodo@baggins.org
Cc: tls@ietf.org
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] SNI with early data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 12:27:31 -0000

Hi Matt,

You might be also interested in this issue:

https://github.com/tlswg/tls13-spec/issues/1040

--Kazu

> I note in draft-21 the following text:
> 
>    When clients use a PSK obtained externally to send early data, then
>    the following additional information MUST be provisioned to both
>    parties:
> 
>    -  The TLS version number for use with this PSK
> 
>    -  The cipher suite for use with this PSK
> 
>    -  The Application-Layer Protocol Negotiation (ALPN) protocol
>       [RFC7301], if any is to be used
> 
>    -  The Server Name Indication (SNI), if any is to be used
> 
> Later it says this:
> 
>    In order to accept early data, the server MUST have accepted a PSK
>    cipher suite and selected the first key offered in the client's
>    "pre_shared_key" extension.  In addition, it MUST verify that the
>    following values are consistent with those negotiated in the
>    connection during which the ticket was established.
> 
>    -  The TLS version number and cipher suite.
> 
>    -  The selected ALPN [RFC7301] protocol, if any.
> 
> 
> The language about "during which the ticket was established" seems to
> suggest that the following checks do not apply to an external PSK -
> which I don't think is intended. Additionally there does not seem to
> be a requirement on the server to check that the SNI is consistent.
> So, there is a mandatory requirement for an external PSK to specify
> the SNI, but no requirement on the server to check that it is actually
> correct. Is this discrepancy intentional?
> 
> Matt
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Thu Jul 20 06:29:25 2017
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 BED1E131B37 for ; Thu, 20 Jul 2017 06:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 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_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 Hi1MlpNkT_Zd for ; Thu, 20 Jul 2017 06:29:23 -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 C7609131C1C for ; Thu, 20 Jul 2017 06:29:22 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (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 3xCvrJ69FNz1HQL; Thu, 20 Jul 2017 15:29:20 +0200 (CEST)
X-purgate-ID: 152705::1500557360-00000810-FC7742B5/0/0
X-purgate-size: 1265
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 mail07.wdf.sap.corp (Postfix) with ESMTP id 3xCvrJ2wdVzGnvS; Thu, 20 Jul 2017 15:29:20 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 58B131A6CB; Thu, 20 Jul 2017 15:29:20 +0200 (CEST)
In-Reply-To: 
To: Russ Housley 
Date: Thu, 20 Jul 2017 15:29:20 +0200 (CEST)
CC: IETF TLS 
Reply-To: mrex@sap.com
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: <20170720132920.58B131A6CB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 13:29:25 -0000

I'm sorry, Russ, but I think this would be seriously deceiving.


Russ Housley wrote:
> 
> If a specification were available that used an extension that involved
> both the client and the server, would the working group adopt it, work
> on it, and publish it as an RFC?
> 
> I was listening very carefully to the comments made by people in line.
> Clearly some people would hum for "no" to the above question, but it
> sounded like many felt that this would be a significant difference.
> It would ensure that both server and client explicitly opt-in, and any
> party observing the handshake could see the extension was included or not.

Any party observing the handshake (read: a monitoring middlebox) would
see whether client proposed the extension and server confirmed the extension
in the clear part of the TLS handshake, and that very same monitoring
middlebox very very very probably would kill/prevent all TLS handshakes
without that extension being confirmed by the server from completing...

... at which point this is no longer a "rare and occasional voluntary
opt-in for debugging broken apps" but rather a policy enforcment known
as "coercion".

I am violently opposed to standardizing enfored wire-tapping for TLS.

-Martin


From nobody Thu Jul 20 06:35:48 2017
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 E95DD131B2D for ; Thu, 20 Jul 2017 06:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=isoc.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 ocQ8vSFc8ecC for ; Thu, 20 Jul 2017 06:35:44 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0073.outbound.protection.outlook.com [104.47.32.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC82131C33 for ; Thu, 20 Jul 2017 06:35:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IwqjNzFOmA693TVaJNPlnY7DqQjVxkLKRiOSW7f2r/w=; b=xyfEPm3riCmAWvjE0aO0G5+6tRzaitB+UgdY+jK/Y3piyOE+df0wZMgmwcXOAyTTin+of4+xxEOFSv5LNXej+DNR4ds63yshptkmNXtQLXlGXYwhIF1yzg/bCPb12IhO4XzzcWjSF3aebeCqbuqxjS4AQZ/FjXyjYQvWCXuJtB8=
Received: from BN6PR06MB3395.namprd06.prod.outlook.com (10.174.235.153) by BN6PR06MB3396.namprd06.prod.outlook.com (10.174.235.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Thu, 20 Jul 2017 13:35:41 +0000
Received: from BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) by BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 13:35:41 +0000
From: Robin Wilton 
To: Russ Housley 
CC: IETF TLS 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQHTAT0e/02z4cJx9Eqsiy9o8ZfN66JclhgAgAAfOKE=
Date: Thu, 20 Jul 2017 13:35:41 +0000
Message-ID: 
References: , <5B14DA7C-E6D4-4681-AEE5-23DD0949CE68@vigilsec.com>
In-Reply-To: <5B14DA7C-E6D4-4681-AEE5-23DD0949CE68@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=isoc.org;
x-originating-ip: [178.255.154.107]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR06MB3396; 7:0hpokNKF9k5WungIHiFPRGnAlYQNC0hlDZ+xYTChqLO4NURscVeFoVzxMQjiUGVUdGnvMjuEzhFUT0Dxx5oAVYzPU236EWePe5W71DOS7e9fSKkNhNX6+t0vTO/YVAQ26dJV383Qj1QwfjOYwMLu7cMerhhmwy2hyfE6VXKDxvwvGxecuKiluDxdIQKMBoz9QRsFC8JHS975RCQ0IG734KwZcIuLUGUPRx54gRQA8zR4dPQeH5DoXJZEqKSkqEwNOe2RqoWivAGNTPSgKalgazAihgKw+JU1/Az/4TIm3lAH8oARi/MC2RmWBo77M598p9q96ddQnQTEQm4RBKQ59bp6DEYs1cPlglCaQSUUpQGyla0NzFtCajkETH02jqn0TxtAJ/40Je9JbnHs5ym+LDX6lvocVWPn/WhpS4V9FuDgzPFfa0NOkNZl3f1loKjYyODyclG3UWH6MGbk31XphHAlR5GCzWQahhKG7kjrLYGvSNsGKzM3vlKXBdeKveNxGwZn2a8X0EPlp+YiDCAVAVekkTqHOIZlvTz3Ia8gqvc/uhhaiD+AmbaX+WHMRcaWc7WADoddGqPfwlcftU8CzyYnDYsIIw0r45bIh2O1UTyV3SxPR0zn2gpArQl8OAebSCM6vLLl3rPrsWTetNZKUSkbWUKo2s9ALgM0eOzO/I0PWpeiKcW01lnab46YVcAgafPJKbUFQKNKDjVRFBjtAIKk59gmnhJciUWmMDpqIAN0KIx3ONp3ttg2aUheIK22sFJ2Q1Nn0S2GhEa0rJti5u/epT9e1RigUROhoXCf0rs=
x-ld-processed: 89f84dfb-7285-4810-bc4d-8b9b5794554f,ExtAddr
x-ms-office365-filtering-correlation-id: 7394f506-54ad-4479-e104-08d4cf743727
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR06MB3396; 
x-ms-traffictypediagnostic: BN6PR06MB3396:
x-exchange-antispam-report-test: UriScan:(158342451672863)(236129657087228)(48057245064654)(247924648384137); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR06MB3396; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR06MB3396; 
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39400400002)(39410400002)(39450400003)(377454003)(24454002)(77096006)(6506006)(3660700001)(2906002)(478600001)(8936002)(74316002)(81166006)(8676002)(86362001)(6606003)(6116002)(7736002)(189998001)(6436002)(5660300001)(3846002)(229853002)(102836003)(6916009)(2950100002)(7696004)(25786009)(3280700002)(55016002)(33656002)(561944003)(66066001)(50986999)(19627405001)(53936002)(38730400002)(4326008)(54896002)(54356999)(236005)(2900100001)(9686003)(14454004)(110136004)(99286003)(76176999)(53546010)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB3396; H:BN6PR06MB3395.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR06MB3395B6AABD069E49D4C3C921BFA70BN6PR06MB3395namp_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 13:35:41.4108 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3396
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 13:35:47 -0000

--_000_BN6PR06MB3395B6AABD069E49D4C3C921BFA70BN6PR06MB3395namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




________________________________
From: Russ Housley 
Sent: Thursday, July 20, 2017 12:35 PM
To: Robin Wilton
Cc: IETF TLS
Subject: Re: [TLS] Is there a way forward after today's hum?


On Jul 20, 2017, at 5:57 AM, Robin Wilton > wrote:

Apologies for not replying "in thread" on this occasion, for noob reasons..=
. but here's the specific comment from Russ that I wanted to respond to:


________________________________

The hum told us that the room was roughly evenly split.  In hind sight, I w=
ish the chairs had asked a second question.  If the split in the room was d=
ifferent for the second question, then I think we might have learned a bit =
more about what people are thinking.

If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?

I was listening very carefully to the comments made by people in line.  Cle=
arly some people would hum for "no" to the above question, but it sounded l=
ike many felt that this would be a significant difference.  It would ensure=
 that both server and client explicitly opt-in, and any party observing the=
 handshake could see the extension was included or not.

Russ


=3D=3D=3D=3D

Stephen Farrell articulated a concern with that approach - namely, that if =
we are relying on a setting that is meant to ensure both parties must be aw=
are that static DH is in use, then a bad actor would find ways to suppress =
that notification. In your proposal, Russ, the notification mechanism would=
 take the form of an extension... so I think we would need to understand wh=
at the failsafe is, for instance if that extension is disabled, or not pres=
ent, in a given deployment of TLS.

There's an implicit assumption about the threat model, too, which I just wa=
nt to call out. The assumption is that a bad actor would suppress the notif=
ication so that the client is not aware that static DH is in use. For compl=
eteness, should we also consider whether there are attacks in which it's th=
e *server* whose notification is suppressed? (I can't think of such an atta=
ck, off the top of my head, but then, that's probably why I'm not a hacker.=
 ;^, )

Best wishes,
Robin


Robin:

I belive that such tampering would be detected by the finished message proc=
essing and the handshake would fail.

Russ

Thanks, Russ;

If I am analysing this correctly, there are two "tampering events" involved=
 here.

The first is: has someone tampered at the protocol/notification level to pr=
event the client from being notified that static DH is in use?

The second is: when the client decrypts traffic using whatever has resulted=
 from the key exchange protocol, can it tell whether the DH key that was us=
ed is a static one or not?

I don't know enough about your proposed extension to judge whether it's rea=
sonable to assume that the finished message processing would detect either =
of those or not (but I freely admit, that's my lack of knowledge).

Yrs.,
Robin



--_000_BN6PR06MB3395B6AABD069E49D4C3C921BFA70BN6PR06MB3395namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








    


    

    

    

    

    

    

    From: Russ Housley <hous=
ley@vigilsec.com>
    
Sent: Thursday, July 20, 2017 12:35 PM
    
To: Robin Wilton
    
Cc: IETF TLS
    
Subject: Re: [TLS] Is there a way forward after today's hum?    

     
    

    


    

    

    

    On Jul 20, 2017, at 5:57 AM, Robin Wilton <wilton@isoc.org> wrote:
    

    

    

    

    Apologies for n=
ot replying "in thread" on this occasion, for noob reasons... but=
 here's the specific comment from Russ that I wanted to respond to:
    


    

    

    

    

    The hum told us that the room was roughly evenly split.  In=
 hind sight, I wish the chairs had asked a second question.  If the split i=
n the room was different for the second question, then I think we might hav=
e learned a bit more about what people are thinking.=0A=
=0A=
If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?=0A=
=0A=
I was listening very carefully to the comments made by people in line.  Cle=
arly some people would hum for "no" to the above question, but it=
 sounded like many felt that this would be a significant difference.  It wo=
uld ensure that both server and client explicitly opt-in, and any party obs=
erving the handshake could see the extension was included or not.=0A=
=0A=
Russ=0A=

    

    

    =3D=3D=3D=3D


    

    

    Stephen Farrell=
 articulated a concern with that approach - namely, that if we are relying =
on a setting that is meant to ensure both parties must be aware that static=
 DH is in use, then a bad actor would
 find ways to suppress that notification. In your proposal, Russ, the notif=
ication mechanism would take the form of an extension... so I think we woul=
d need to understand what the failsafe is, for instance if that extension i=
s disabled, or not present, in a
 given deployment of TLS.
    


    

    

    There's an impl=
icit assumption about the threat model, too, which I just want to call out.=
 The assumption is that a bad actor would suppress the notification so that=
 the client is not aware that static
 DH is in use. For completeness, should we also consider whether there are =
attacks in which it's the *server* whose notification is suppressed? (I can=
't think of such an attack, off the top of my head, but then, that's probab=
ly why I'm not a hacker. ;^, )
    


    

    

    Best wishes,

    Robin  
    

    

    

    

    

    

    


    

    

    Robin:
    


    

    

    I belive that such tampering would be detected by the finished message=
 processing and the handshake would fail.
    


    

    

    Russ
    


    

    

    Thanks, Russ; 
    


    

    

    If I am analysing this correctly, there are two "tampering events=
" involved here.
    


    

    

    The first is: has someone tampered at the protocol/notification level =
to prevent the client from being notified that static DH is in use? 


    

    

    The second is: when the client decrypts traffic using whatever has res=
ulted from the key exchange protocol, can it tell whether the DH key t=
hat was used is a static one or not? 
    


    

    

    I don't know enough about your proposed extension to judge whether it'=
s reasonable to assume that the finished message processing would detect ei=
ther of those or not (but I freely admit, that's my lack of knowledge)=
.
    

    


    

    

    Yrs.,
    

    Robin
    


    

    

    

    

    

    



--_000_BN6PR06MB3395B6AABD069E49D4C3C921BFA70BN6PR06MB3395namp_--


From nobody Thu Jul 20 06:45:32 2017
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 D70571315FF for ; Thu, 20 Jul 2017 06:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=isoc.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 pC_yqPFESTGD for ; Thu, 20 Jul 2017 06:45:29 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0061.outbound.protection.outlook.com [104.47.41.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C97131B04 for ; Thu, 20 Jul 2017 06:45:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ozDwS4fHS/Oly2+ClKyssE2RAeVCzNfacyVzaGz3lmw=; b=buyRY4BvlQabGqEIN2IyJ7GGS53vc+uU2e7wRlx1JqLB3TBXAvtGamyoaeLJ7bC/kNoqDB9JNld/AwNg4OmSlc20n9CMVNzLhEdvIzvz/SOl8fj+MPlNKzv2RI0qZMm4LF83b9EI1Bo64r6zHFSlXNS32smPKv299fLHhnCuAJs=
Received: from BN6PR06MB3395.namprd06.prod.outlook.com (10.174.235.153) by BN6PR06MB3394.namprd06.prod.outlook.com (10.174.235.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Thu, 20 Jul 2017 13:45:26 +0000
Received: from BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) by BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 13:45:25 +0000
From: Robin Wilton 
To: Paul Turner , "tls@ietf.org" 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQHTAT0e/02z4cJx9Eqsiy9o8ZfN66JcjUWAgAAqlWY=
Date: Thu, 20 Jul 2017 13:45:25 +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: venafi.com; dkim=none (message not signed) header.d=none;venafi.com; dmarc=none action=none header.from=isoc.org;
x-originating-ip: [178.255.154.107]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR06MB3394; 7:Kzt6/84O7bRJ+KNDN4cm7H9DAavHdyqSVfEYsnalVYLrd1msK08nKR9XuOHa9GLGYaCI+1dqBqfUDz+jmUGZen6ik2pFt9yJb6PUclnFGrypl2SiWdHf9ljA5FiuqoK9FO64pwGvibnkstfiOBD5tCTA+toeEH/LF6a1CSbSdaw4RIFHK8YYOEoVGScFboWonh8Zf9Y5B0b499g5816EPkT/UAF/u8zLQ1oOFq1QZLyGKZqZeFW+ODnZka5xESqMcAErRMD9jFSVhlmR+BB43+xx1XwOUM4eN3NzX2skdlvFwFHOIFW8nHSGQykr2NLsR4no7twoqVKJmIii5QJ6fOc6YJ1P86FFYGf26GufEgA89aD0Egefxrv03EDUXfgV2F32ctyhxGhvQCGb4veoShfSggrP0YON1+zHjLhS1FDSEvWdfdmJEPfW25OoyzWcp9GahkWujxXDx9YdshPIJcbRYf5Zis9140MNOaCo0DQAl1d/5uBikWlUKh7WSr0GORPL/xsoGcbCNxOWFHiWAdkeYFxc5nTcrs3A3gPunm7gsTA1Ekytv6d8jlBDOvelF69olas/uhzWpKG8N1r88VI49wpN3PHdicD7xIYkEUS7CYe/CXlv9zTIqi3FW6nP59kaCQv4sKAKqHWUJhZ86nSdSHIyrFCYQllswdC9Ks0YVOlDF6nGR2dX1MOltfnFxD2Ep3ppZjPhoZeoaurUG6a8i3jl0ex6cIblaQDM9ojaDfsnyBKl1o48stNztYneGLbGvTiBBjar+Vzemi4gpwuG3MgaePp8vozxJDE2Uco=
x-ms-office365-filtering-correlation-id: bc2358ad-e10b-4c57-9c79-08d4cf75938d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR06MB3394; 
x-ms-traffictypediagnostic: BN6PR06MB3394:
x-exchange-antispam-report-test: UriScan:(158342451672863)(236129657087228)(48057245064654)(8454915177855)(25034144782879);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR06MB3394; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR06MB3394; 
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(39830400002)(377454003)(6436002)(86362001)(54356999)(53546010)(76176999)(8676002)(8936002)(50986999)(7696004)(5660300001)(25786009)(74316002)(66066001)(2900100001)(45080400002)(81166006)(14454004)(2906002)(561944003)(478600001)(7736002)(229853002)(6246003)(3660700001)(6506006)(77096006)(2950100002)(6606003)(2501003)(566704002)(3280700002)(19627405001)(6116002)(99286003)(54896002)(3846002)(102836003)(55016002)(53936002)(9686003)(33656002)(38730400002)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB3394; H:BN6PR06MB3395.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR06MB3395F759CF116550D2CF2996BFA70BN6PR06MB3395namp_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 13:45:25.8526 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3394
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 13:45:31 -0000

--_000_BN6PR06MB3395F759CF116550D2CF2996BFA70BN6PR06MB3395namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Paul - thanks for this; two comments inline.

I'm an Outlook Webmail n00b, so just in case "nesting" doesn't work, I have=
 marked them with @@@.


________________________________
From: Paul Turner 
Sent: Thursday, July 20, 2017 12:03 PM
To: Robin Wilton; tls@ietf.org
Subject: RE: [TLS] Is there a way forward after today's hum?



From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: tls@ietf.org
Subject: Re: [TLS] Is there a way forward after today's hum?


Apologies for not replying "in thread" on this occasion, for noob reasons..=
. but here's the specific comment from Russ that I wanted to respond to:



________________________________

The hum told us that the room was roughly evenly split.  In hind sight, I w=
ish the chairs had asked a second question.  If the split in the room was d=
ifferent for the second question, then I think we might have learned a bit =
more about what people are thinking.



If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?



I was listening very carefully to the comments made by people in line.  Cle=
arly some people would hum for "no" to the above question, but it sounded l=
ike many felt that this would be a significant difference.  It would ensure=
 that both server and client explicitly opt-in, and any party observing the=
 handshake could see the extension was included or not.



Russ

=3D=3D=3D=3D



Stephen Farrell articulated a concern with that approach - namely, that if =
we are relying on a setting that is meant to ensure both parties must be aw=
are that static DH is in use, then a bad actor would find ways to suppress =
that notification. In your proposal, Russ, the notification mechanism would=
 take the form of an extension... so I think we would need to understand wh=
at the failsafe is, for instance if that extension is disabled, or not pres=
ent, in a given deployment of TLS.



There's an implicit assumption about the threat model, too, which I just wa=
nt to call out. The assumption is that a bad actor would suppress the notif=
ication so that the client is not aware that static DH is in use. For compl=
eteness, should we also consider whether there are attacks in which it's th=
e *server* whose notification is suppressed? (I can't think of such an atta=
ck, off the top of my head, but then, that's probably why I'm not a hacker.=
 ;^, )



Best wishes,

Robin



Robin,



With respect to your threat concerns, can you be more clear about the threa=
ts you=92re considering? Here are a few things that come to mind:



  1.  TLS Server has all of the decrypted data and can provide that to a th=
ird party (whether compelled or otherwise) without any indication to the TL=
S client. This seems true TLS 1.3 today.
  2.  TLS Server has their ephemeral DH keys and session keys and can provi=
de them to a third party without any indication to the TLS client. This see=
ms true with TLS 1.3 today.
  3.  TLS Server can create a TLS server implementation that uses static DH=
 keys and provide them to a third party. The client can use methods to dete=
ct this (though there are measures and countermeasures here). This is true =
seems TLS 1.3 today.
  4.  TLS Client has all of the decrypted data and can provide that to a th=
ird party (whether compelled or otherwise) without any indication to the TL=
S server. This seems true in TLS 1.3 today.
  5.  TLS Client has their ephemeral DH keys and session keys and can provi=
de them to a third party without any indication to the TLS server. This see=
ms true with TLS 1.3 today.

@@@I'll have to give these proper thought when I have more bandwidth - so, =
I'm not ignoring these good questions/scenarios!




I believe Russ was outlining a method where an extension would be added to =
TLS 1.3 that would provide for delivery of a decryption key to a third part=
y during the handshake (correct me if I got that wrong, Russ).


@@@This seems somewhat different to static DH... are we now talking about a=
n alternative, more along key escrow lines?  Apologies if I missed somethin=
g earlier from Russ; I'll go back down the thread and see.


Because it would be during the handshake, it would seem to be visible to th=
e TLS  Client=97in fact, the client would have to include the extension to =
begin with. If the TLS client saw the extension and did not consent, it cou=
ld abort the connection. If the TLS Server were attempting to provide acces=
s to the exchanged data to a third party, it would seem they could use 1, 2=
, or 3 above and not have to go to the trouble of attempting to subvert the=
 mechanism that Russ proposes (and others have previously proposed).



Can you clarify?



Paul

--_000_BN6PR06MB3395F759CF116550D2CF2996BFA70BN6PR06MB3395namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable








    

    Hi Paul - thanks for this; two comments inline.
    

    I'm an Outlook Webmail n00b, so just in case "nesting" do=
esn't work, I have marked them with @@@.  
    

    

    

    

    

    From: Paul Turner <PAUL.=
TURNER@venafi.com>
    
Sent: Thursday, July 20, 2017 12:03 PM
    
To: Robin Wilton; tls@ietf.org
    
Subject: RE: [TLS] Is there a way forward after today's hum?    

     
    

    

    

    

     
    

     
    

    

    

    From: T=
LS [mailto:tls-bounces@ietf.org]
On Behalf Of Robin Wilton
    
Sent: Thursday, July 20, 2017 05:58
    
To: tls@ietf.org
    
Subject: Re: [TLS] Is there a way forward after today's hum?<=
/p>

    

    

     
    

    

    Apologies for not replying "in thread"=
 on this occasion, for noob reasons... but here's the specific comment from=
 Russ that I wanted to respond to:
    

     
    

    


    

    

    The hum told us=
 that the room was roughly evenly split.  In hind sight, I wish the ch=
airs had asked a second question.  If the split in the room was differ=
ent for the second question, then I think we might have learned a bit more =
about what people are thinking.
    

     

    If a specificat=
ion were available that used an extension that involved both the client and=
 the server, would the working group adopt it, work on it, and publish it a=
s an RFC?
    

     

    I was listening=
 very carefully to the comments made by people in line.  Clearly some =
people would hum for "no" to the above question, but it sounded l=
ike many felt that this would be a significant difference.  It would e=
nsure that both server and client explicitly opt-in, and any party observin=
g the handshake could see the extension was included or not.
    

     

    Russ

    =3D=3D=3D=3D
    

     
    

    Stephen Farrell articulated a concern with that =
approach - namely, that if we are relying on a setting that is meant to ens=
ure both parties must be aware that static DH
 is in use, then a bad actor would find ways to suppress that notification.=
 In your proposal, Russ, the notification mechanism would take the form of =
an extension... so I think we would need to understand what the failsafe is=
, for instance if that extension
 is disabled, or not present, in a given deployment of TLS.
    

     
    

    There's an implicit assumption about the threat =
model, too, which I just want to call out. The assumption is that a bad act=
or would suppress the notification so that the
 client is not aware that static DH is in use. For completeness, should we =
also consider whether there are attacks in which it's the *server* whose no=
tification is suppressed? (I can't think of such an attack, off the top of =
my head, but then, that's probably
 why I'm not a hacker. ;^, )
    

     
    

    Best wishes,
    

    Robin 

    

     
    

    Robin,
    

     
    

    With respect to your threat concerns, can you be more clear about the =
threats you=92re considering? Here are a few things that come to mind:
    

     
    

      

    1. TLS Server has all of the decrypted data an=
d can provide that to a third party (whether compelled or otherwise) withou=
t any indication to the TLS client. This seems
 true TLS 1.3 today.
    2. TLS Serve=
r has their ephemeral DH keys and session keys and can provide them to a th=
ird party without any indication to the TLS client. This seems true with TL=
S 1.3
 today.
    3. TLS Server can create a =
TLS server implementation that uses static DH keys and provide them to a th=
ird party. The client can use methods to detect this (though there
 are measures and countermeasures here). This is true seems TLS 1.3 today.<=
/span>
    4. TLS Client has all of the decryp=
ted data and can provide that to a third party (whether compelled or otherw=
ise) without any indication to the TLS server. This seems
 true in TLS 1.3 today.
    5. TLS Clie=
nt has their ephemeral DH keys and session keys and can provide them to a t=
hird party without any indication to the TLS server. This seems true with T=
LS 1.3
 today.
    

    @@=
@I'll have to give these proper thought when I have more bandwidth - s=
o, I'm not ignoring these good questions/scenarios!
    

    

    

     
    

    I believe Russ was outlining a method where an extension would be adde=
d to TLS 1.3 that would provide for delivery of a decryption key to a third=
 party during the handshake (correct me if I
 got that wrong, Russ). 
    


    

    

    @@@This seems somewhat different to static DH... are we now talki=
ng about an alternative, more along key escrow lines?  Apologies if I =
missed something earlier from Russ; I'll go back down
 the thread and see.
    


    

    

    Because it would be during the handshake, it would seem to be visible =
to the TLS  Client=97in fact, the client would have to include the ext=
ension to begin with. If the TLS client saw the extension
 and did not consent, it could abort the connection. If the TLS Server were=
 attempting to provide access to the exchanged data to a third party, it wo=
uld seem they could use 1, 2, or 3 above and not have to go to the trouble =
of attempting to subvert the mechanism
 that Russ proposes (and others have previously proposed). 
    

     
    

    Can you clarify?
    

     
    

    Paul
    

    

    

    

    

    



--_000_BN6PR06MB3395F759CF116550D2CF2996BFA70BN6PR06MB3395namp_--


From nobody Thu Jul 20 07:11:21 2017
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 B2A23126CD6 for ; Thu, 20 Jul 2017 07:11: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 Acn1KonF6dFZ for ; Thu, 20 Jul 2017 07:11:18 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003: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 1A45A120227 for ; Thu, 20 Jul 2017 07:11:18 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id 191so27641153oii.2 for ; Thu, 20 Jul 2017 07:11:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=F9ntQ229VMX6OQ7Vkvpn2zpu6peCBtDeoo1BYFbPdek=; b=AxcBP0zgvWBI88sTem/wHKX8fqTrZWUI6xm265oApaE2FT4mVi9IMCARnmN0Xqt/+Q z5kh2mO/c4ZiYSn+vO7w7+uS4K1wQYcXE4/4ycAW/WJGF9MR3wr4Tisx9RSZ4yxO8qp3 2fTc5VVitNH0cYpeNodL+Yh0bxbKnZuW6cDa+Eo2kIYO9bXp4DzDJVdboMf0Lv13sMZu bDxUNrxj0iYqk5dyochgZZAS9aA/p/esv4c6Z+i5SPJdVNVlys5Fzio8xRmV7gPQBqR+ b/lhwdyqgbKbpwA9EHKopmoocC25kyIBujTg8Ad6Aa6rQth9ND/rHzHo1CIDZe4WYmeB 32eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=F9ntQ229VMX6OQ7Vkvpn2zpu6peCBtDeoo1BYFbPdek=; b=tbOd36WHKrciHhGjUO8HWnWbvVjuwzbCMy7fUn6Nte8bcu+EZYFY+liwDpEtIU59uo bmihSNdqxMP8WJJmeaz9nPee42jZcEG4w9Q1u2Q1LaV5kCQkjEqsjuh7BgNzptxgJIYN QxBC10iz/Mj4ld4LZPoK/d39deDkI7msVpqdqdt+wpkqlAqrcyBNhOM2HYFDR48nKNIL m7gcvJJ4omHWEfateX6Flb7K0Pn2vo77UCQktpbSM4e3qiKDWfSbixn2jSKzG0oTJiGD QNVoqdU2FMSXTzTUqibnC8bwxWznPswpxlUg59yLwFQawuBl1QH1O5SdIy2EiZvr6HEY Ekfg==
X-Gm-Message-State: AIVw110tr9gsYUqORJA8Bz5FHmbr30ziUwWft3rmuOcn3TWpxyqZacyc xP3CZyL3McW2/1DW8TBJnY25Rl7phA==
X-Received: by 10.202.53.215 with SMTP id c206mr5464037oia.164.1500559877368;  Thu, 20 Jul 2017 07:11:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.5.6 with HTTP; Thu, 20 Jul 2017 07:11:16 -0700 (PDT)
Reply-To: noloader@gmail.com
In-Reply-To: 
References:  <5B14DA7C-E6D4-4681-AEE5-23DD0949CE68@vigilsec.com> 
From: Jeffrey Walton 
Date: Thu, 20 Jul 2017 10:11:16 -0400
Message-ID: 
To: Robin Wilton 
Cc: Russ Housley , IETF TLS 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 14:11:20 -0000

On Thu, Jul 20, 2017 at 9:35 AM, Robin Wilton  wrote:
>...
> If I am analysing this correctly, there are two "tampering events" involved
> here.
>
> The first is: has someone tampered at the protocol/notification level to
> prevent the client from being notified that static DH is in use?
>
> The second is: when the client decrypts traffic using whatever has resulted
> from the key exchange protocol, can it tell whether the DH key that was used
> is a static one or not?
>
> I don't know enough about your proposed extension to judge whether it's
> reasonable to assume that the finished message processing would detect
> either of those or not (but I freely admit, that's my lack of knowledge).

In my mind's eye, and stepping back to 10,000 feet, the security
engineering problem you are witnessing is:

   * The security community has advised "DH for perfect forward secrecy"
   * RSA key transport was deprecated because it does not provide PFS
   * The proposal does an end-around, and it breaks
expectations/security properties

The security community created the "reasonable expectation" of PFS
when using Diffie-Hellman. A typical developer who follows best
practices will expect it. It was pounded into heir heads. Cf.,
https://www.imperialviolet.org/2013/12/03/forwardsecretforjournalists.html
and https://www.imperialviolet.org/2013/06/27/botchingpfs.html.

The typical developer will not be able to make the distinction between
Diffie-Hellman Ephemeral and Static Diffie-Hellman modulo key vaulting
so traffic can be decrypted later. In the typical developer's eyes,
they have been told to do something because it has certain security
properties but it no longer holds.

The signalling indicates the loss of the security property typical
developers and users have come to expect.

Jeff


From nobody Thu Jul 20 07:41:00 2017
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 737951317A4 for ; Thu, 20 Jul 2017 07:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 D4M46WDD60Xk for ; Thu, 20 Jul 2017 07:40:57 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB8E131C7D for ; Thu, 20 Jul 2017 07:40:57 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG01.res.venafi.com (10.1.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 08:40:55 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 08:40:55 -0600
From: Paul Turner 
To: Stephen Farrell , Ted Lemon 
CC: Robin Wilton , "" 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQGZY5pvJzH4JA3szzi/CxpFoIjfXaLPvrHggAB0dYCAAAVSoIAAApaAgAAC7XCAAATkAIAAJt3g
Date: Thu, 20 Jul 2017 14:40:54 +0000
Message-ID: 
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com>  <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.197.8.30]
Content-Type: multipart/alternative; boundary="_000_cd9e13f908224dc59472cf0e599b56cevenaficom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 14:40:58 -0000

--_000_cd9e13f908224dc59472cf0e599b56cevenaficom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIFttYWlsdG86dGxz
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IFRo
dXJzZGF5LCBKdWx5IDIwLCAyMDE3IDA4OjIyDQpUbzogUGF1bCBUdXJuZXIgPFBBVUwuVFVSTkVS
QHZlbmFmaS5jb20+OyBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpDYzogUm9iaW4gV2ls
dG9uIDx3aWx0b25AaXNvYy5vcmc+OyA8dGxzQGlldGYub3JnPiA8dGxzQGlldGYub3JnPg0KU3Vi
amVjdDogUmU6IFtUTFNdIElzIHRoZXJlIGEgd2F5IGZvcndhcmQgYWZ0ZXIgdG9kYXkncyBodW0/
DQoNCg0KDQoNCg0KSGl5YSwNCg0KDQoNCk9uIDIwLzA3LzE3IDEzOjA0LCBQYXVsIFR1cm5lciB3
cm90ZToNCg0KPiBMZXTigJlzIHVzZSB0aGUgb3BwcmVzc2l2ZSBnb3Zlcm5tZW50IGluc3RpdHV0
aW9uIHRoYXQgSSBiZWxpZXZlIHlvdeKAmXZlDQoNCj4gbWVudGlvbmVkIChwYXJkb24gbWUgaWYg
SSBnb3QgdGhhdCB3cm9uZykgd2l0aCBhIGNvbm5lY3Rpb24gb3ZlciB0aGUNCg0KPiBJbnRlcm5l
dCBpbiB0aGlzIGNhc2UuDQoNCg0KDQpTb3JyeSwgSSdtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4g
dGhlcmUsIGJ1dCBndWVzc2luZywgeWVzLCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgbmF0aW9uIHN0
YXRlIGFjdG9ycyB3aG8gd291bGQgdHJ5IHRvIGNvbXBlbCB1c2Ugb2YgdGhpcyBtaXRtLCBhbmQg
Zm9yIGEgcHJvcG9zYWwgaW4gdGhpcyBzcGFjZSB0aGF0IGFsc28gY2F1c2VzIGludHJhY3RhYmxl
IHByb2JsZW1zIHdoZW4gYSBjb25uZWN0aW9uIGlzIHN1cHBvc2VkIHRvIGJlIG1pdG0nZCBieSBt
b3JlIHRoYW4gb25lIG9mIHRob3NlLCBvciBvbmUgaXMgbm90IGNsZWFyIHdoaWNoIGlzIHRoZSBh
cHByb3ByaWF0ZSBuYXRpb24gc3RhdGUgYXR0YWNrZXIgdG8gYXBwZWFzZS4NCg0KDQoNCknigJlt
IGFzc3VtaW5nIHRoYXQgeW914oCZcmUgcmVmZXJyaW5nIHRvIG11bHRpcGxlIG5hdGlvbnMgYmVp
bmcgYmV0d2VlbiB0aGUgVExTIGNsaWVudCBhbmQgc2VydmVyLiBJZiBhIFRMUyBjbGllbnQgaXMg
c2V0IHRvIG5vdCBpbmNsdWRlIHRoZSBleHRlbnNpb24sIGl0IHNlZW1zIHRoZSBUTFMgY2xpZW50
IHdvdWxkIHNpbXBseSBjbG9zZSB0aGUgY29ubmVjdGlvbi4gSXQgc2VlbXMgdGhlIGNsaWVudCBj
b3VsZCBjaG9vc2Ugd2hldGhlciBpdCB3YW50ZWQgdG8gYXBwZWFzZSB0aGUgbmF0aW9uIHN0YXRl
cy4gRGlkIEkgbWlzdW5kZXJzdGFuZD8NCg0KDQoNCj4gQ2FuIHlvdSByZXBseSBpbiB0aGF0IGNv
bnRleHQ/IEnigJltIHRydWx5IGludGVyZXN0ZWQgaW4gdW5kZXJzdGFuZGluZy4NCg0KPiBJdCB3
YXNu4oCZdCBhIOKAnHRyeeKAnS4NCg0KSG9wZWZ1bGx5IHRoZSBhYm92ZSBoZWxwcywgYnV0IGl0
IG1heSBhbHNvIGhlbHAgdG8gc2F5IHRoYXQgdGhlIGFwcHJvcHJpYXRlIGNvbnRleHQgSSdkIGNv
bnNpZGVyIGZvciBUTFMgaXMgZXNzZW50aWFsbHkgYWxsIHRoZSBhcHBsaWNhdGlvbnMgb2YgVExT
IGFuZCBhbGwgdGhlIGRlcGxveW1lbnRzIHRoYXQnZCBldmVudHVhbGx5IGJlIHVwZGF0ZWQgd2l0
aCB3aGF0ZXZlciBwcm9wb3NhbCBpcyBvbiB0aGUgdGFibGUuDQoNCg0KDQpBZ3JlZWQuICBJdCBp
cyBjcml0aWNhbCB0byBjb25zaWRlciBhbGwgb2YgdGhlIHBvc3NpYmxlIHVzZSBjYXNlcy4NCg0K
DQoNCihQcmlvciB0byBnZXR0aW5nIGl0IG9mZiB0aGUgdGFibGUgd2hlbiBpdCdzIHNob3duIHRv
IGJlIGEgYmFkIHBsYW46LSkNCg0KDQoNCkNoZWVycywNCg0KUy4NCg0KDQoNCg0KDQoNCg==

--_000_cd9e13f908224dc59472cf0e599b56cevenaficom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp
Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBUTFMgW21h
aWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXBoZW4gRmFycmVsbDxi
cj4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDIwLCAyMDE3IDA4OjIyPGJyPg0KVG86IFBhdWwgVHVy
bmVyICZsdDtQQVVMLlRVUk5FUkB2ZW5hZmkuY29tJmd0OzsgVGVkIExlbW9uICZsdDttZWxsb25A
ZnVndWUuY29tJmd0Ozxicj4NCkNjOiBSb2JpbiBXaWx0b24gJmx0O3dpbHRvbkBpc29jLm9yZyZn
dDs7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVj
dDogUmU6IFtUTFNdIElzIHRoZXJlIGEgd2F5IGZvcndhcmQgYWZ0ZXIgdG9kYXkncyBodW0/PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IaXlhLDxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPk9uIDIwLzA3LzE3IDEzOjA0LCBQYXVsIFR1cm5lciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mZ3Q7IExl
dOKAmXMgdXNlIHRoZSBvcHByZXNzaXZlIGdvdmVybm1lbnQgaW5zdGl0dXRpb24gdGhhdCBJIGJl
bGlldmUgeW914oCZdmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsgbWVudGlvbmVkIChwYXJkb24gbWUgaWYgSSBn
b3QgdGhhdCB3cm9uZykgd2l0aCBhIGNvbm5lY3Rpb24gb3ZlciB0aGUNCjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsg
SW50ZXJuZXQgaW4gdGhpcyBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNvcnJ5LCBJJ20g
bm90IHN1cmUgd2hhdCB5b3UgbWVhbiB0aGVyZSwgYnV0IGd1ZXNzaW5nLCB5ZXMsIHRoZXJlIGNh
biBiZSBtdWx0aXBsZSBuYXRpb24gc3RhdGUgYWN0b3JzIHdobyB3b3VsZCB0cnkgdG8gY29tcGVs
IHVzZSBvZiB0aGlzIG1pdG0sIGFuZCBmb3IgYSBwcm9wb3NhbCBpbiB0aGlzIHNwYWNlIHRoYXQg
YWxzbyBjYXVzZXMgaW50cmFjdGFibGUgcHJvYmxlbXMNCiB3aGVuIGEgY29ubmVjdGlvbiBpcyBz
dXBwb3NlZCB0byBiZSBtaXRtJ2QgYnkgbW9yZSB0aGFuIG9uZSBvZiB0aG9zZSwgb3Igb25lIGlz
IG5vdCBjbGVhciB3aGljaCBpcyB0aGUgYXBwcm9wcmlhdGUgbmF0aW9uIHN0YXRlIGF0dGFja2Vy
IHRvIGFwcGVhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SeKAmW0gYXNzdW1p
bmcgdGhhdCB5b3XigJlyZSByZWZlcnJpbmcgdG8gbXVsdGlwbGUgbmF0aW9ucyBiZWluZyBiZXR3
ZWVuIHRoZSBUTFMgY2xpZW50IGFuZCBzZXJ2ZXIuIElmIGEgVExTIGNsaWVudCBpcyBzZXQgdG8g
bm90IGluY2x1ZGUgdGhlIGV4dGVuc2lvbiwgaXQgc2VlbXMgdGhlIFRMUyBjbGllbnQgd291bGQg
c2ltcGx5IGNsb3NlIHRoZSBjb25uZWN0aW9uLg0KIEl0IHNlZW1zIHRoZSBjbGllbnQgY291bGQg
Y2hvb3NlIHdoZXRoZXIgaXQgd2FudGVkIHRvIGFwcGVhc2UgdGhlIG5hdGlvbiBzdGF0ZXMuIERp
ZCBJIG1pc3VuZGVyc3RhbmQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsgQ2Fu
IHlvdSByZXBseSBpbiB0aGF0IGNvbnRleHQ/IEnigJltIHRydWx5IGludGVyZXN0ZWQgaW4gdW5k
ZXJzdGFuZGluZy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsgSXQgd2FzbuKAmXQgYSDigJx0cnnigJ0uPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+SG9wZWZ1bGx5IHRoZSBhYm92ZSBoZWxwcywgYnV0IGl0IG1heSBhbHNvIGhlbHAgdG8gc2F5
IHRoYXQgdGhlIGFwcHJvcHJpYXRlIGNvbnRleHQgSSdkIGNvbnNpZGVyIGZvciBUTFMgaXMgZXNz
ZW50aWFsbHkgYWxsIHRoZSBhcHBsaWNhdGlvbnMgb2YgVExTIGFuZCBhbGwgdGhlIGRlcGxveW1l
bnRzIHRoYXQnZCBldmVudHVhbGx5IGJlIHVwZGF0ZWQgd2l0aCB3aGF0ZXZlcg0KIHByb3Bvc2Fs
IGlzIG9uIHRoZSB0YWJsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BZ3JlZWQu
Jm5ic3A7IEl0IGlzIGNyaXRpY2FsIHRvIGNvbnNpZGVyIGFsbCBvZiB0aGUgcG9zc2libGUgdXNl
IGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPihQcmlvciB0byBn
ZXR0aW5nIGl0IG9mZiB0aGUgdGFibGUgd2hlbiBpdCdzIHNob3duIHRvIGJlIGEgYmFkIHBsYW46
LSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Uy48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_cd9e13f908224dc59472cf0e599b56cevenaficom_--


From nobody Thu Jul 20 07:44:08 2017
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 C38E0131CAE for ; Thu, 20 Jul 2017 07:44:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJAULMcIYepe for ; Thu, 20 Jul 2017 07:44:03 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 BC440131C83 for ; Thu, 20 Jul 2017 07:44:03 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id w45so24702192uac.5 for ; Thu, 20 Jul 2017 07:44:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bhHpa1yoWhq2Ky6UdDsd/Y9o+7VC54gnz3H7k/bf3Cs=; b=AlubfjFToRWL/0RBAcwx7Q2ftYD81wPlbxrbNcdQQAca54fcioIWOyeTBKndNDIIQz taatq5dzQtouJZvJeRlQDCyLCAaQADVRUn/tf/sYhKh/wu/KPJXezjq0yThqjMaYiTT8 qWiMTfB4CzseFyQMd1i0FQyoI1dSsDpc6cBug=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bhHpa1yoWhq2Ky6UdDsd/Y9o+7VC54gnz3H7k/bf3Cs=; b=QulPl4gKsk1aol+Nop+r4cfO9aJrDfABZyfJZ+GM5BzxuVU4iwpAs2aVgl2TL9IlPh VjyPtk2iv3bsZdHzSRWlvhkHFc4fucWGfDzy8HEEBnXFPDJU9G5JHobIyAwnsQCpuxU6 Ds4Z32IvgqypGcrUORrKEYJFmlyiKjeXWiFrfKpStprfkALtr1mzM3142cDoESSKG3h9 nDhpSgcQn7JbdCyxWnWAioEwZyNpPpV5SHEi+/poqAe5frrM7U44H7ejfd7E7vLNMJfc uNu+Xe5gTzlRpk5PDJucMokR9TVraL83NKuwkLXD4H3Aq4BkDyymVrHhY7BZgr6ck6Pb oRAQ==
X-Gm-Message-State: AIVw112EjJg8vKBe4cJcMFivZFoDEiiXYPgQAQXN+QMhUllXqkRwHLTw 5mYWgAUf4pw7HM3G2fUs54NKl1zu23KR
X-Received: by 10.159.37.100 with SMTP id 91mr2439756uaz.147.1500561842600; Thu, 20 Jul 2017 07:44:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.195 with HTTP; Thu, 20 Jul 2017 07:43:41 -0700 (PDT)
In-Reply-To: 
References:    
From: Tom Ritter 
Date: Thu, 20 Jul 2017 09:43:41 -0500
Message-ID: 
To: Yoav Nir 
Cc: Russ Housley , IETF TLS 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 14:44:07 -0000

On 20 July 2017 at 01:53, Yoav Nir  wrote:
>
> On 20 Jul 2017, at 8:01, Russ Housley  wrote:
>
> Ted, if we use a new extension, then the server cannot include it unless =
the
> client offered it first.  I am thinking of an approach where the server
> would include information needed by the decryptor in the response.  So, i=
f
> the client did not offer the extension, it would be a TLS protocol violat=
ion
> for the server to include it.
>
>
> So we also add an alert called =E2=80=9Ckey-export-needed=E2=80=9D in cas=
e the client does
> not include it.
>
> That way a browser (as an example) can show the user why the connection w=
as
> broken (=E2=80=9Cserver requires wiretapping to be enabled. Go to about:c=
onfig if
> that is OK and change the allow-wiretap setting to True=E2=80=9D)


I previously expressed that I could support the extension mechanism -
I'm sympathetic to regulatory requirements and unhappy with, although
understanding of, what has become the 'standard mechanism' (breaking
crypto) to achieve them. I've looked at more than one 'end to end'
encrypted messenger that tosses in the 'third end' of key escrow.

But to suggest such a mechanism might ever be implemented in a web
browser throws my hackles up. The discussion has always been about
datacenter - the people concerned say "We don't want your datacenter
stuff in our protocol and the proponents say "No really, we only care
about the datacenter."

The concerns around some future government-mandated key escrow is very
real and very concerning.

-tom


From nobody Thu Jul 20 07:49:00 2017
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 D6040131CDD for ; Thu, 20 Jul 2017 07:48:54 -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=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 UlEClGW1pS20 for ; Thu, 20 Jul 2017 07:48:52 -0700 (PDT)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 12752131CDA for ; Thu, 20 Jul 2017 07:48:52 -0700 (PDT)
Received: by mail-pg0-x22c.google.com with SMTP id v190so15845724pgv.2 for ; Thu, 20 Jul 2017 07:48:52 -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=xu2GSUpGtI3fhtrDl87Oy69y0Yf9dL+xKYZ7AWZqrxk=; b=Hp1JdrXjdgZL//Uh3hBSuBlYM0HR/rjx/txV90uLoAvrL0k/0N6ge994VEWmAzYjov xdYfxjhwNMBqbDKpERzDiQGe/cn3Bd1X9qZUllOLvQ+fK7dKyrC5PNWjZiyJXzFEidTp 7E4IS222qQulj+zTAn4WC0f1X3f2Uud/VBFnaCpsPWA9jqHk7YxM7pmF05csAZ7uEZiA 4Ze0QqnB0MR4lhGGdmJweuCgcuC1GOardbePbSK9E09H8nuWmNrUQV96dWkjNN6Ff6jl KmT6prVbjPGvYyZf/WLRdP1Akhkv0/EjpUtY8M/ugd/+fYAN8t95kSflwJ5To3FSzPTy HzGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xu2GSUpGtI3fhtrDl87Oy69y0Yf9dL+xKYZ7AWZqrxk=; b=o/Ts+4eouOr5UVvKxY+cgRWSpp8X5q+d7mUOn3HiBT0BQ03D49KAP9f0l85Z6BUofQ Ljy75GTI043L37hP9BXdvO21QMovOZ13NLdeW3OANaflPy5rKKmlASesyxlhaaN2N+mt b7vBTSt9GuHwmZhG3rmrfA5ZwiYgHN5IS2jEmIra5Lz8ym6fZxnIxkTN5dS442Q+OL7s rtXv0QWt0UgqLNGSM3tHstrtyG0KJsPNsyuh7h2pCQVcNhqf5EmyAM9gp1l6yUoMGte8 Q62Zm5pwTZAQoZfWqagJM4MMbYURlmgoFEbqb39Zi4MLKWhzbSFrDYbuqCyBnaGHltjJ uLtg==
X-Gm-Message-State: AIVw112EFNhYpqKMzBmXQA2WrJPLro0cm3G+gTKfxG+AmB6UEmCaNUcB UYJx6RRUpaS0Rj/gUyRzsI3XQKZKdp5t
X-Received: by 10.98.139.134 with SMTP id e6mr4103858pfl.111.1500562131670; Thu, 20 Jul 2017 07:48:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 07:48:11 -0700 (PDT)
In-Reply-To: 
References:     
From: Ted Lemon 
Date: Thu, 20 Jul 2017 16:48:11 +0200
Message-ID: 
To: Tom Ritter 
Cc: Yoav Nir , IETF TLS 
Content-Type: multipart/alternative; boundary="f403045c4322d26dc50554c0d8b9"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 14:48:55 -0000

--f403045c4322d26dc50554c0d8b9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The problem is that one of the applications for web browsers is as a
replacement for 3270s (the first web browser).   That use case is said to
require this functionality.

On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter  wrote:

> On 20 July 2017 at 01:53, Yoav Nir  wrote:
> >
> > On 20 Jul 2017, at 8:01, Russ Housley  wrote:
> >
> > Ted, if we use a new extension, then the server cannot include it unles=
s
> the
> > client offered it first.  I am thinking of an approach where the server
> > would include information needed by the decryptor in the response.  So,
> if
> > the client did not offer the extension, it would be a TLS protocol
> violation
> > for the server to include it.
> >
> >
> > So we also add an alert called =E2=80=9Ckey-export-needed=E2=80=9D in c=
ase the client
> does
> > not include it.
> >
> > That way a browser (as an example) can show the user why the connection
> was
> > broken (=E2=80=9Cserver requires wiretapping to be enabled. Go to about=
:config if
> > that is OK and change the allow-wiretap setting to True=E2=80=9D)
>
>
> I previously expressed that I could support the extension mechanism -
> I'm sympathetic to regulatory requirements and unhappy with, although
> understanding of, what has become the 'standard mechanism' (breaking
> crypto) to achieve them. I've looked at more than one 'end to end'
> encrypted messenger that tosses in the 'third end' of key escrow.
>
> But to suggest such a mechanism might ever be implemented in a web
> browser throws my hackles up. The discussion has always been about
> datacenter - the people concerned say "We don't want your datacenter
> stuff in our protocol and the proponents say "No really, we only care
> about the datacenter."
>
> The concerns around some future government-mandated key escrow is very
> real and very concerning.
>
> -tom
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f403045c4322d26dc50554c0d8b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    The problem is that one of the applications for web browse=
rs is as a replacement for 3270s (the first web browser). =C2=A0 That use c=
ase is said to require this functionality.
    =

    On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter =
<to=
m@ritter.vg> wrote:
    On 20 July 2017 at 01:53, Yoav Nir <ynir.ietf@gmail.com> wrote:
    
>
    
> On 20 Jul 2017, at 8:01, Russ Housley <housley@vigilsec.com> wrote:
    
>
    
> Ted, if we use a new extension, then the server cannot include it unle=
ss the
    
> client offered it first.=C2=A0 I am thinking of an approach where the =
server
    
> would include information needed by the decryptor in the response.=C2=
=A0 So, if
    
> the client did not offer the extension, it would be a TLS protocol vio=
lation
    
> for the server to include it.
    
>
    
>
    
> So we also add an alert called =E2=80=9Ckey-export-needed=E2=80=9D in =
case the client does
    
> not include it.
    
>
    
> That way a browser (as an example) can show the user why the connectio=
n was
    
> broken (=E2=80=9Cserver requires wiretapping to be enabled. Go to abou=
t:config if
    
> that is OK and change the allow-wiretap setting to True=E2=80=9D)
    

    

    

    I previously expressed that I could support the extension mecha=
nism -
    
I'm sympathetic to regulatory requirements and unhappy with, although
understanding of, what has become the 'standard mechanism' (breakin=
g
    
crypto) to achieve them. I've looked at more than one 'end to end&#=
39;
    
encrypted messenger that tosses in the 'third end' of key escrow.

    
But to suggest such a mechanism might ever be implemented in a web
    
browser throws my hackles up. The discussion has always been about
    
datacenter - the people concerned say "We don't want your datacent=
er
    
stuff in our protocol and the proponents say "No really, we only care<=
br>
about the datacenter."
    

    
The concerns around some future government-mandated key escrow is very
    
real and very concerning.
    

    
-tom
    


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


    

--f403045c4322d26dc50554c0d8b9--


From nobody Thu Jul 20 07:50:31 2017
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 D75AE131CF6 for ; Thu, 20 Jul 2017 07:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 uhsoGhm3iFXM for ; Thu, 20 Jul 2017 07:50:22 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26A1131CFB for ; Thu, 20 Jul 2017 07:50:19 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 08:50:18 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 08:50:18 -0600
From: Paul Turner 
To: "mrex@sap.com" , Russ Housley 
CC: IETF TLS 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQFx3unXJzH4JA3szzi/CxpFoIjfXaMfDr8Q
Date: Thu, 20 Jul 2017 14:50:18 +0000
Message-ID: <3a0f16917ee24eaeaf32aa5a39327bc1@venafi.com>
References:  <20170720132920.58B131A6CB@ld9781.wdf.sap.corp>
In-Reply-To: <20170720132920.58B131A6CB@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.197.8.30]
Content-Type: multipart/alternative; boundary="_000_3a0f16917ee24eaeaf32aa5a39327bc1venaficom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 14:50:24 -0000

--_000_3a0f16917ee24eaeaf32aa5a39327bc1venaficom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
Sent: Thursday, July 20, 2017 09:29
To: Russ Housley 
Cc: IETF TLS 
Subject: Re: [TLS] Is there a way forward after today's hum?



I'm sorry, Russ, but I think this would be seriously deceiving.





Russ Housley wrote:

>

> If a specification were available that used an extension that involved

> both the client and the server, would the working group adopt it, work

> on it, and publish it as an RFC?

>

> I was listening very carefully to the comments made by people in line.

> Clearly some people would hum for "no" to the above question, but it

> sounded like many felt that this would be a significant difference.

> It would ensure that both server and client explicitly opt-in, and any

> party observing the handshake could see the extension was included or not=
.



Any party observing the handshake (read: a monitoring middlebox) would see =
whether client proposed the extension and server confirmed the extension in=
 the clear part of the TLS handshake, and that very same monitoring middleb=
ox very very very probably would kill/prevent all TLS handshakes without th=
at extension being confirmed by the server from completing...



Just to make sure I understand the scenario: The nation state has contacted=
 the TLS server owner and convinced/coerced them to provide contents of com=
munications. They've decided that instead of using options 1, 2, or 3 in my=
 earlier message (I can resend if that would help), they tell the TLS serve=
r owner that they would like them to use the extension method. If a client =
attempted to connect without including the extension, they would kill the c=
onnection. That seems like it protects the client from being eavesdropped, =
and they could discern that someone is attempting to listen. Can you expand=
 on how this would be deceiving?



... at which point this is no longer a "rare and occasional voluntary opt-i=
n for debugging broken apps" but rather a policy enforcment known as "coerc=
ion".



It seems a middlebox owner who is both powerful and intent enough to pursue=
 this would instead compel the TLS server owner to use options 1, 2, or 3.



I am violently opposed to standardizing enfored wire-tapping for TLS.



-Martin



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

--_000_3a0f16917ee24eaeaf32aa5a39327bc1venaficom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









    

     
    

     
    

    -----Original Message-----
    
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
    
Sent: Thursday, July 20, 2017 09:29
    
To: Russ Housley <housley@vigilsec.com>
    
Cc: IETF TLS <tls@ietf.org>
    
Subject: Re: [TLS] Is there a way forward after today's hum?
    

     
    

    I'm sorry, Russ, but I=
 think this would be seriously deceiving.
    

     
    

     
    

    Russ Housley wrote:
    

    > 
    

    > If a specificatio=
n were available that used an extension that involved

    

    > both the client a=
nd the server, would the working group adopt it, work

    

    > on it, and publis=
h it as an RFC?
    

    > 
    

    > I was listening v=
ery carefully to the comments made by people in line.
    

    > Clearly some peop=
le would hum for "no" to the above question, but it

    

    > sounded like many=
 felt that this would be a significant difference.
    

    > It would ensure t=
hat both server and client explicitly opt-in, and any

    

    > party observing t=
he handshake could see the extension was included or not.
    

     
    

    Any party observing th=
e handshake (read: a monitoring middlebox) would see whether client propose=
d the extension and server confirmed the extension in the clear part of the=
 TLS handshake, and that very same monitoring
 middlebox very very very probably would kill/prevent all TLS handshakes wi=
thout that extension being confirmed by the server from completing...<=
/o:p>
    

     
    

    Just to make sure I u=
nderstand the scenario: The nation state has contacted the TLS server owner=
 and convinced/coerced them to provide contents of communications. TheyR=
17;ve decided that instead of using options
 1, 2, or 3 in my earlier message (I can resend if that would help), they t=
ell the TLS server owner that they would like them to use the extension met=
hod. If a client attempted to connect without including the extension, they=
 would kill the connection. That
 seems like it protects the client from being eavesdropped, and they could =
discern that someone is attempting to listen. Can you expand on how this wo=
uld be deceiving?

    

     
    

    ... at which point thi=
s is no longer a "rare and occasional voluntary opt-in for debugging b=
roken apps" but rather a policy enforcment known as "coercion&quo=
t;.
    

     
    

    It seems a middlebox owner who is both powerful a=
nd intent enough to pursue this would instead compel the TLS server owner t=
o use options 1, 2, or 3.
    

     
    

    I am violently opposed=
 to standardizing enfored wire-tapping for TLS.
    

     
    

    -Martin
    

     
    

    ______________________=
_________________________
    

    TLS mailing list<=
/o:p>
    

    TLS@ietf.or=
g
    

    https://www.ietf.org/mailman/listinfo/tls<=
/p>

    



--_000_3a0f16917ee24eaeaf32aa5a39327bc1venaficom_--


From nobody Thu Jul 20 07:55:19 2017
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 0344B131D04 for ; Thu, 20 Jul 2017 07:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 CXzPDaRDzRwH for ; Thu, 20 Jul 2017 07:55:13 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A32131CD4 for ; Thu, 20 Jul 2017 07:55:13 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG01.res.venafi.com (10.1.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 08:55:11 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 08:55:11 -0600
From: Paul Turner 
To: Robin Wilton , "tls@ietf.org" 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQGZY5pvJzH4JA3szzi/CxpFoIjfXaLPvrHggACbkICAABN7IA==
Date: Thu, 20 Jul 2017 14:55:11 +0000
Message-ID: <9a8d7dff2d194620ae46eab31b643e0e@venafi.com>
References: ,  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.197.8.30]
Content-Type: multipart/alternative; boundary="_000_9a8d7dff2d194620ae46eab31b643e0evenaficom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 14:55:16 -0000

--_000_9a8d7dff2d194620ae46eab31b643e0evenaficom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks for your response.  Response to one of your comments below.

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 09:45
To: Paul Turner ; tls@ietf.org
Subject: Re: [TLS] Is there a way forward after today's hum?


Hi Paul - thanks for this; two comments inline.

I'm an Outlook Webmail n00b, so just in case "nesting" doesn't work, I have=
 marked them with @@@.

________________________________
From: Paul Turner >
Sent: Thursday, July 20, 2017 12:03 PM
To: Robin Wilton; tls@ietf.org
Subject: RE: [TLS] Is there a way forward after today's hum?



From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Robin Wilton
Sent: Thursday, July 20, 2017 05:58
To: tls@ietf.org
Subject: Re: [TLS] Is there a way forward after today's hum?


Apologies for not replying "in thread" on this occasion, for noob reasons..=
. but here's the specific comment from Russ that I wanted to respond to:



________________________________

The hum told us that the room was roughly evenly split.  In hind sight, I w=
ish the chairs had asked a second question.  If the split in the room was d=
ifferent for the second question, then I think we might have learned a bit =
more about what people are thinking.



If a specification were available that used an extension that involved both=
 the client and the server, would the working group adopt it, work on it, a=
nd publish it as an RFC?



I was listening very carefully to the comments made by people in line.  Cle=
arly some people would hum for "no" to the above question, but it sounded l=
ike many felt that this would be a significant difference.  It would ensure=
 that both server and client explicitly opt-in, and any party observing the=
 handshake could see the extension was included or not.



Russ

=3D=3D=3D=3D



Stephen Farrell articulated a concern with that approach - namely, that if =
we are relying on a setting that is meant to ensure both parties must be aw=
are that static DH is in use, then a bad actor would find ways to suppress =
that notification. In your proposal, Russ, the notification mechanism would=
 take the form of an extension... so I think we would need to understand wh=
at the failsafe is, for instance if that extension is disabled, or not pres=
ent, in a given deployment of TLS.



There's an implicit assumption about the threat model, too, which I just wa=
nt to call out. The assumption is that a bad actor would suppress the notif=
ication so that the client is not aware that static DH is in use. For compl=
eteness, should we also consider whether there are attacks in which it's th=
e *server* whose notification is suppressed? (I can't think of such an atta=
ck, off the top of my head, but then, that's probably why I'm not a hacker.=
 ;^, )



Best wishes,

Robin



Robin,



With respect to your threat concerns, can you be more clear about the threa=
ts you're considering? Here are a few things that come to mind:


1.      TLS Server has all of the decrypted data and can provide that to a =
third party (whether compelled or otherwise) without any indication to the =
TLS client. This seems true TLS 1.3 today.
2.      TLS Server has their ephemeral DH keys and session keys and can pro=
vide them to a third party without any indication to the TLS client. This s=
eems true with TLS 1.3 today.
3.      TLS Server can create a TLS server implementation that uses static =
DH keys and provide them to a third party. The client can use methods to de=
tect this (though there are measures and countermeasures here). This is tru=
e seems TLS 1.3 today.
4.      TLS Client has all of the decrypted data and can provide that to a =
third party (whether compelled or otherwise) without any indication to the =
TLS server. This seems true in TLS 1.3 today.
5.      TLS Client has their ephemeral DH keys and session keys and can pro=
vide them to a third party without any indication to the TLS server. This s=
eems true with TLS 1.3 today.
@@@I'll have to give these proper thought when I have more bandwidth - so, =
I'm not ignoring these good questions/scenarios!




I believe Russ was outlining a method where an extension would be added to =
TLS 1.3 that would provide for delivery of a decryption key to a third part=
y during the handshake (correct me if I got that wrong, Russ).



@@@This seems somewhat different to static DH... are we now talking about a=
n alternative, more along key escrow lines?  Apologies if I missed somethin=
g earlier from Russ; I'll go back down the thread and see.



I was assuming to Russ' comment above "an extension that involved both the =
client and the server", which is a different approach than static DH. I may=
 have misunderstood his message.



Because it would be during the handshake, it would seem to be visible to th=
e TLS  Client-in fact, the client would have to include the extension to be=
gin with. If the TLS client saw the extension and did not consent, it could=
 abort the connection. If the TLS Server were attempting to provide access =
to the exchanged data to a third party, it would seem they could use 1, 2, =
or 3 above and not have to go to the trouble of attempting to subvert the m=
echanism that Russ proposes (and others have previously proposed).



Can you clarify?



Paul

--_000_9a8d7dff2d194620ae46eab31b643e0evenaficom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









    

    Thanks for your response.  Response to one of =
your comments below.
    

     
    

    

    

    From: TLS=
 [mailto:tls-bounces@ietf.org]
On Behalf Of Robin Wilton
    
Sent: Thursday, July 20, 2017 09:45
    
To: Paul Turner <PAUL.TURNER@venafi.com>; tls@ietf.org
    
Subject: Re: [TLS] Is there a way forward after today's hum?
    

    

    

     
    

    

    Hi Paul - thanks for this; two comments inline.
    

    I'm an Outlook Webmail n00b, so just in case=
 "nesting" doesn't work, I have marked them with @@@.  =

    

    
 
    

    

    


    

    

    

    From: Paul Turner <PAUL.TURNER@venafi.com>
    
Sent: Thursday, July 20, 2017 12:03 PM
    
To: Robin Wilton; tls@ietf.org
Subject: RE: [TLS] Is there a way forward after today's hum?    <=
span style=3D"font-family:"Calibri",sans-serif;color:black">

    

    

     
    

    

    

    

    

    
 
    

    
 
    

    

    

    
From: TLS [mailto:tls-bounces@ietf.org]
On Behalf Of Robin Wilton
    
Sent: Thursday, July 20, 2017 05:58
    
To: tls@ietf.org
    
Subject: Re: [TLS] Is there a way forward after today's hum?    <=
span style=3D"font-family:"Calibri",sans-serif;color:black">=

    

    

    

    
&nbs=
p;
    

    

    Apologies for not replying "in thread"=
 on this occasion, for noob reasons... but here's the specific comment from=
 Russ that I wanted to respond to:
    

     
    

    

    


    

    

    

    The hum told u=
s that the room was roughly evenly split.  In hind sight, I wish the c=
hairs had asked a second question.  If the split in the room was diffe=
rent for the second question, then I think we might have learned a bit more=
 about what people are thinking.
    

     
    

    If a specifica=
tion were available that used an extension that involved both the client an=
d the server, would the working group adopt it, work on it, and publish it =
as an RFC?
    

     
    

    I was listenin=
g very carefully to the comments made by people in line.  Clearly some=
 people would hum for "no" to the above question, but it sounded =
like many felt that this would be a significant difference.  It would =
ensure that both server and client explicitly opt-in, and any party observi=
ng the handshake could see the extension was included or not.
    

     
    

    Russ
    

    =3D=3D=3D=3D
    

     
    

    Stephen Farrell articulated a concern with that =
approach - namely, that if we are relying on a setting that is meant to ens=
ure both parties must be aware that static DH
 is in use, then a bad actor would find ways to suppress that notification.=
 In your proposal, Russ, the notification mechanism would take the form of =
an extension... so I think we would need to understand what the failsafe is=
, for instance if that extension
 is disabled, or not present, in a given deployment of TLS.
    

     
    

    There's an implicit assumption about the threat =
model, too, which I just want to call out. The assumption is that a bad act=
or would suppress the notification so that the
 client is not aware that static DH is in use. For completeness, should we =
also consider whether there are attacks in which it's the *server* whose no=
tification is suppressed? (I can't think of such an attack, off the top of =
my head, but then, that's probably
 why I'm not a hacker. ;^, )
    

     
    

    Best wishes,
    

    Robin 

    

     
    

    Robin,
    

     
    

    With respect to your threat conc=
erns, can you be more clear about the threats you’re considering? Her=
e are a few things that come to mind:
    

     
    

    
1.     
TLS Server has all of the decry=
pted data and can provide that to a third party (whether compelled or other=
wise) without any indication to the TLS client.
 This seems true TLS 1.3 today.
    

    
2.     
TLS Server has their ephemeral =
DH keys and session keys and can provide them to a third party without any =
indication to the TLS client. This seems true
 with TLS 1.3 today.
    

    
3.     
TLS Server can create a TLS ser=
ver implementation that uses static DH keys and provide them to a third par=
ty. The client can use methods to detect this
 (though there are measures and countermeasures here). This is true seems T=
LS 1.3 today.
    

    
4.     
TLS Client has all of the decry=
pted data and can provide that to a third party (whether compelled or other=
wise) without any indication to the TLS server.
 This seems true in TLS 1.3 today.
    

    
5.     
TLS Client has their ephemeral =
DH keys and session keys and can provide them to a third party without any =
indication to the TLS server. This seems true
 with TLS 1.3 today.
    

    

    @@@I'll have=
 to give these proper thought when I have more bandwidth - so, I'm not=
 ignoring these good questions/scenarios!
    

    

    

     
    

    

     
    

    I believe Russ was outlining a m=
ethod where an extension would be added to TLS 1.3 that would provide for d=
elivery of a decryption key to a third party during
 the handshake (correct me if I got that wrong, Russ). <=
/span>
    

     
    

    @@@This seems somewhat different=
 to static DH... are we now talking about an alternative, more along k=
ey escrow lines?  Apologies if I missed something earlier
 from Russ; I'll go back down the thread and see.
    

     
    

    I was assuming to Russ’ comment above “an extension that involved both the client and the server&=
#8221;, which is a different approach than static DH. I may have misunderst=
ood
 his message.
    

     
    

    Because it would be during the h=
andshake, it would seem to be visible to the TLS  Client—in fact=
, the client would have to include the extension to begin
 with. If the TLS client saw the extension and did not consent, it could ab=
ort the connection. If the TLS Server were attempting to provide access to =
the exchanged data to a third party, it would seem they could use 1, 2, or =
3 above and not have to go to the
 trouble of attempting to subvert the mechanism that Russ proposes (and oth=
ers have previously proposed).

    

     
    

    Can you clarify?
    

     
    

    Paul
    

    

    

    

    

    

    



--_000_9a8d7dff2d194620ae46eab31b643e0evenaficom_--


From nobody Thu Jul 20 07:57:48 2017
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 865EF13178B for ; Thu, 20 Jul 2017 07:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-TUbytFye-Q for ; Thu, 20 Jul 2017 07:57:44 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91309131473 for ; Thu, 20 Jul 2017 07:57:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 20852BE4C; Thu, 20 Jul 2017 15:57:43 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYzsInUObSGP; Thu, 20 Jul 2017 15:57:42 +0100 (IST)
Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2A60BE2F; Thu, 20 Jul 2017 15:57:41 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500562662; bh=EdW1tLmSeFmzE96uPUz/kjGIppEUWTstFM+8ZIrvVDE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=22H4+/Sxd4ClEVg2t+71zDMVqGfa/OqPLSc90Z21WErjMCMAuvip4Q9XNupCn6vjF 4RkEu9Pzh6KoDiOtCD+C91awodxsv/PQj/U+1+h0cSNSerWw9EYFC4IcT+y+ad2HKm e7xZIGpnrVU2ccBNUGjgIScrmpOZEOxX+RDpX7tQ=
To: Paul Turner , Ted Lemon 
Cc: Robin Wilton , "" 
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com>  <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>  
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <4b3855e4-0d37-bf25-5215-1ff179c13c59@cs.tcd.ie>
Date: Thu, 20 Jul 2017 15:57:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6lU8aRWV2jS4uImUNDxHfaBihFEvGqGXu"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 14:57:47 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6lU8aRWV2jS4uImUNDxHfaBihFEvGqGXu
Content-Type: multipart/mixed; boundary="V1NL7McJUMiTtK2E9mDdjAOPWnjJOI7og";
 protected-headers="v1"
From: Stephen Farrell 
To: Paul Turner , Ted Lemon 
Cc: Robin Wilton , "" 
Message-ID: <4b3855e4-0d37-bf25-5215-1ff179c13c59@cs.tcd.ie>
Subject: Re: [TLS] Is there a way forward after today's hum?
References: 
 
 
 <691913e7a5d1464e8dda20c8848f6149@venafi.com>
 
 <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>
 
 
In-Reply-To: 

--V1NL7McJUMiTtK2E9mDdjAOPWnjJOI7og
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 20/07/17 15:40, Paul Turner wrote:
> I=E2=80=99m assuming that you=E2=80=99re referring to multiple nations =
being between
> the TLS client and server. If a TLS client is set to not include the
> extension, it seems the TLS client would simply close the connection.
> It seems the client could choose whether it wanted to appease the
> nation states.=20

Through how many nations states did this email travel between you
and I? Mail is maybe worse than the web, but that's just with our
current deployments but who knows when they'll migrate a 5G VM for
a web server close to my base station?

I'd assert there's no way TLS clients in general could know when
to set or unset the "please wiretap me" evil bit in a ClientHello,
regardless of how complex a configuration is used.

Cheers,
S.








--V1NL7McJUMiTtK2E9mDdjAOPWnjJOI7og--

--6lU8aRWV2jS4uImUNDxHfaBihFEvGqGXu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZcMTkAAoJEC88hzaAX42iaDcH/3W9j3i9xcULu2jblb1jaxfH
s5Uq/TTJOskFRlEtdrz9aZKnpBmmp+AcynzrAKKzmQAHycNK3rV7OWi2Q7L5cIo7
QKA6cAsJBByFt2UJw0cN9Kdbx/ujrhoe2JcK+Me8oV9RvihGuyGEW6zY8oTHG/CY
lyqXt3OnCZLE2IEiDHucIoXzJKAfbURPLxAXVRiNw5yyIAjSH6W8ydsP049HXnS/
gx3T86hZOJJ/DwxMDeW6GmXaMOTo+KCt2uOAnpaNfZ46BM8/9Iqjvbx0B1Ah3bOG
se8xY+jXPlxZUrYzDldwL7wx8kUT6vObTSkrjhGGLOxz2Y3qyMsbRrDk9mHJo2E=
=YjgY
-----END PGP SIGNATURE-----

--6lU8aRWV2jS4uImUNDxHfaBihFEvGqGXu--


From nobody Thu Jul 20 08:08:05 2017
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 A6DA7131CC2 for ; Thu, 20 Jul 2017 08:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 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, 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=equio-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 PGvCA0QqSeIc for ; Thu, 20 Jul 2017 08:08:01 -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 16987131532 for ; Thu, 20 Jul 2017 08:08:01 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id e199so13279710pfh.2 for ; Thu, 20 Jul 2017 08:08:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=equio-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=ozcVyRaUw3ugqQ89yg0IcoEeWloioegbi9NLOJLS0kc=; b=MLamE9mPQHu4+PWer+l3tpCDxccngUHs2M8bNPpncIJBOq/xGfy4EidZPXrT3ym+JB 2dz29vpDqzWqpNqk/KjYIEOKlHQPf69Y9AREEvC4xqj7lhGZXNljRKvFbYGCfgjDKCOU vyU3mKMh9EvU//xBLCHnXNtBt1cBDWHn53NZK+HdhlaSZ19g8ckEDoMmfG6NGwgUQThF gBxkrJ2KkZRd1PGoWtsSj9qRbBgHxRxzDBBcKKbBD1JwXmwvxFAsUCF4g3LhoSLq5/8F V+kXWkDuoKgQvs4cYeDgjBzbjNdsM4dEP7hiVdCuIAfuVDME1j0UAREEMiD7LyUNPBHk 405Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=ozcVyRaUw3ugqQ89yg0IcoEeWloioegbi9NLOJLS0kc=; b=odQP9a/TZ/llp9W8uiktcCWNU68ciw8lTg2xqLcjuL/RuwpB9EZ2xJ1nwgscTYWEAY A99dFa9tGgprlvm+ZKfyrY95E7sbvA7UCj030IFF4BsnNsVXI4Bo4m4Zwp5gYf+Q5Eco jZNo3UGJLaC7tLAWRMAUfIaiyBBcugz6QqPSGJtGvrf1DRaBlmK4HrsX+j7AjrGLrua6 F0b1EFweGNkluSU9uJtToznB3EwuquHafCyXYYVwMw/dIHiU1HIq0HLrEwZ6jeEQPEAQ Nwn3I8Vl9V0DL4NDsRDxnIywARTbA6kvsYNEuAWMUKuA3wJRwruOSBrgs4MdkmXFRYPs 6jJA==
X-Gm-Message-State: AIVw110tmQtqFHE9qL5UulkgrPupg01y4EdFjazwSuuQ5k1ma5M2NrSg a6b6QEe9NxvDDNqaNstIfQ==
X-Received: by 10.99.102.68 with SMTP id a65mr4140966pgc.252.1500563280116; Thu, 20 Jul 2017 08:08:00 -0700 (PDT)
Received: from 07WKSWIN150119 (30.sub-70-197-8.myvzw.com. [70.197.8.30]) by smtp.gmail.com with ESMTPSA id j193sm5049131pfc.95.2017.07.20.08.07.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 08:07:58 -0700 (PDT)
From: "Paul Turner" 
To: "'Tom Ritter'" , "'Yoav Nir'" 
Cc: "'IETF TLS'" 
References:     
In-Reply-To: 
Date: Thu, 20 Jul 2017 11:07:52 -0400
Message-ID: <01a201d30169$f8c68530$ea538f90$@equio.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01D30148.71B72F20"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQFQKzWnUe0W/VWuIePV8AuCJ9hOWgF3s++XAXyk/AwCMzwq1AFKohfsoy7plRA=
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 15:08:03 -0000

This is a multipart message in MIME format.

------=_NextPart_000_01A3_01D30148.71B72F20
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=20

=20

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Tom Ritter
Sent: Thursday, July 20, 2017 10:44
To: Yoav Nir 
Cc: IETF TLS 
Subject: Re: [TLS] Is there a way forward after today's hum?

=20

On 20 July 2017 at 01:53, Yoav Nir <  =
ynir.ietf@gmail.com> wrote:

>=20

> On 20 Jul 2017, at 8:01, Russ Housley <  =
housley@vigilsec.com> wrote:

>=20

> Ted, if we use a new extension, then the server cannot include it=20

> unless the client offered it first.  I am thinking of an approach=20

> where the server would include information needed by the decryptor in=20

> the response.  So, if the client did not offer the extension, it would =


> be a TLS protocol violation for the server to include it.

>=20

>=20

> So we also add an alert called =E2=80=9Ckey-export-needed=E2=80=9D in =
case the client=20

> does not include it.

>=20

> That way a browser (as an example) can show the user why the=20

> connection was broken (=E2=80=9Cserver requires wiretapping to be =
enabled. Go=20

> to about:config if that is OK and change the allow-wiretap setting to=20

> True=E2=80=9D)

=20

=20

I previously expressed that I could support the extension mechanism - =
I'm sympathetic to regulatory requirements and unhappy with, although =
understanding of, what has become the 'standard mechanism' (breaking

crypto) to achieve them. I've looked at more than one 'end to end'

encrypted messenger that tosses in the 'third end' of key escrow.

=20

But to suggest such a mechanism might ever be implemented in a web =
browser throws my hackles up. The discussion has always been about =
datacenter - the people concerned say "We don't want your datacenter =
stuff in our protocol and the proponents say "No really, we only care =
about the datacenter."

=20

The concerns around some future government-mandated key escrow is very =
real and very concerning.

=20

It seems like that problem exists today with TLS 1.3. If a government is =
powerful enough to mandate key escrow, wouldn=E2=80=99t they also be =
power enough to mandate implementing static DH with TLS 1.3 (so that =
they key escrow is possible). In addition, based on this level of =
influence, couldn=E2=80=99t they alternatively require TLS server owners =
to provide them unencrypted data.=20

=20

-tom

=20

_______________________________________________

TLS mailing list

  TLS@ietf.org

  =
https://www.ietf.org/mailman/listinfo/tls


------=_NextPart_000_01A3_01D30148.71B72F20
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


     
     
    -----Original Message-----
    From: TLS =
[mailto:tls-bounces@ietf.org] On Behalf Of Tom Ritter
    Sent: Thursday, =
July 20, 2017 10:44
    To: Yoav Nir <ynir.ietf@gmail.com>
    Cc: =
IETF TLS <tls@ietf.org>
    Subject: Re: [TLS] Is there a way =
forward after today's hum?
     
    On 20 July 2017 at 01:53, Yoav Nir <ynir.ietf@gmail.com> wrote:
    > 
    > On 20 Jul 2017, at =
8:01, Russ Housley <housley@vigilsec.com> wrote:
    > 
    > Ted, if we use a =
new extension, then the server cannot include it 
    > unless the client =
offered it first.=C2=A0 I am thinking of an approach 
    > where the server =
would include information needed by the decryptor in 
    > the response.=C2=A0 =
So, if the client did not offer the extension, it would =

    > =
be a TLS protocol violation for the server to include =
it.
    > 
    > 
    > So we also add an =
alert called =E2=80=9Ckey-export-needed=E2=80=9D in case the client =

    > =
does not include it.
    > 
    > That way a browser =
(as an example) can show the user why the 
    > connection was =
broken (=E2=80=9Cserver requires wiretapping to be enabled. Go =

    > =
to about:config if that is OK and change the allow-wiretap setting to =

    > =
True=E2=80=9D)
     
     
    I previously expressed that I could support =
the extension mechanism - I'm sympathetic to regulatory requirements and =
unhappy with, although understanding of, what has become the 'standard =
mechanism' (breaking
    crypto) to achieve them. I've looked at more =
than one 'end to end'
    encrypted messenger that tosses in the 'third =
end' of key escrow.
     
    But to suggest such a mechanism might ever be =
implemented in a web browser throws my hackles up. The discussion has =
always been about datacenter - the people concerned say "We don't =
want your datacenter stuff in our protocol and the proponents say =
"No really, we only care about the =
datacenter."
     
    The concerns around some future =
government-mandated key escrow is very real and very =
concerning.
     
    It seems like that =
problem exists today with TLS 1.3. If a government is powerful enough to =
mandate key escrow, wouldn=E2=80=99t they also be power enough to =
mandate implementing static DH with TLS 1.3 (so that they key escrow is =
possible). In addition, based on this level of influence, =
couldn=E2=80=99t they alternatively require TLS server owners to provide =
them unencrypted data. 
     
    -tom
     
    ______________________________________________=
_
    TLS =
mailing list
    TLS@ietf.org
    https://www.ietf.org/mail=
man/listinfo/tls
    
------=_NextPart_000_01A3_01D30148.71B72F20--


From nobody Thu Jul 20 08:20:22 2017
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 65821131CE6 for ; Thu, 20 Jul 2017 08:20:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWL-AReFren3 for ; Thu, 20 Jul 2017 08:20:13 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 8B692131CFE for ; Thu, 20 Jul 2017 08:20:13 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id 80so25640819uas.0 for ; Thu, 20 Jul 2017 08:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=67J3j0/nzb49wKQDf6RRM0kFk8fln9Y998LPZRt1Wv8=; b=rSRZIJNaV4cdVRbU0gtwHy39RCdlKPtmLwrXlRN2t97r4mCebcdbXOV6knug/W+gge Hq9kpkg9SgkOPXDto6/R5XQ0vNOCLVuMjv6uxxTaejLQuvQGZDKFCeL3JgGiZGK8ZyuN 0yZ8d15Ks3syJAnnb1lBP1KtdEOVbZK4VMBDs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=67J3j0/nzb49wKQDf6RRM0kFk8fln9Y998LPZRt1Wv8=; b=uWJeNL1ivjhYoAS9GdRqGAFp1Oi8ABWL5hJvFKMUhbbEjGdJc06fSvFJviFTe9JYzP GGVr7nY8fVH0m7WvUuU9Qc4amM51DCFJQqwtrSnx/1cGdolzNL79ZljfWSntqu1NfgFM XtYejx9KXRAcRlllpD+DYYiNGwpB52PNRGNTHn+hy2nF36GzqPwzeUTVpGhIPYuOwFK8 uODaqpYqqwPeU24L1qUPifWWtJiCLXrP5qTLp3H2VxK06omTgwlzGYjdkmePX3l+4hvf X7t1+YJA4oM4AS2/gk4ybFgYCX2eRM9BAGw56mOMa3fOVidKI+iXpNZKj+zSy/09VNxw C+Tw==
X-Gm-Message-State: AIVw111zrhnXp6dk1nK0uO+NWWoVhEeIN9pRPFFo5IIMvSRWQMYPnzIy 1f8nINGoaD76d/V5QKTk3JE/7ZmrGUhGz4Q=
X-Received: by 10.159.37.100 with SMTP id 91mr2511853uaz.147.1500564012515; Thu, 20 Jul 2017 08:20:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.195 with HTTP; Thu, 20 Jul 2017 08:19:51 -0700 (PDT)
In-Reply-To: <01a201d30169$f8c68530$ea538f90$@equio.com>
References:      <01a201d30169$f8c68530$ea538f90$@equio.com>
From: Tom Ritter 
Date: Thu, 20 Jul 2017 10:19:51 -0500
Message-ID: 
To: Paul Turner 
Cc: Yoav Nir , IETF TLS 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 15:20:18 -0000

On 20 July 2017 at 10:07, Paul Turner  wrote:
> It seems like that problem exists today with TLS 1.3. If a government is
> powerful enough to mandate key escrow, wouldn=E2=80=99t they also be powe=
r enough to
> mandate implementing static DH with TLS 1.3 (so that they key escrow is
> possible). In addition, based on this level of influence, couldn=E2=80=99=
t they
> alternatively require TLS server owners to provide them unencrypted data.


Anything's possible, but it there's a difference between:

"I demand you implement a new mechanism to securely ship me crypto
keys or plaintext, do something for which there is no standard
mechanism or agreement."

and

"If you flip this existing setting right here in OpenSSL, and stick
this public key right here, it will automatically satisfy our
requirements."

I recall one of the arguments that Apple made against the FBI was that
they were asking them to do something novel that required significant
amounts of work, testing, had never been done before, etc. IANAL but I
think this is standard argument to show the request is unreasonable
and overly burdensome. Removing that argument concerns me.
(US-centric view if that isn't apparent.)

-tom


From nobody Thu Jul 20 08:23:31 2017
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 E628D131CE6 for ; Thu, 20 Jul 2017 08:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 5x7ubT_hMfkf for ; Thu, 20 Jul 2017 08:23:28 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A94131C43 for ; Thu, 20 Jul 2017 08:23:21 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 09:23:20 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 09:23:20 -0600
From: Paul Turner 
To: Stephen Farrell , Ted Lemon 
CC: Robin Wilton , "" 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQGZY5pvJzH4JA3szzi/CxpFoIjfXaLPvrHggAB0dYCAAAVSoIAAApaAgAAC7XCAAATkAIAAJt3ggAAEtQCAAAcpsA==
Date: Thu, 20 Jul 2017 15:23:19 +0000
Message-ID: <6a05aa8a00b847b9aac5fd020a57c928@venafi.com>
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com>  <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>   <4b3855e4-0d37-bf25-5215-1ff179c13c59@cs.tcd.ie>
In-Reply-To: <4b3855e4-0d37-bf25-5215-1ff179c13c59@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.197.8.30]
Content-Type: multipart/alternative; boundary="_000_6a05aa8a00b847b9aac5fd020a57c928venaficom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 15:23:30 -0000

--_000_6a05aa8a00b847b9aac5fd020a57c928venaficom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIFttYWlsdG86dGxz
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IFRo
dXJzZGF5LCBKdWx5IDIwLCAyMDE3IDEwOjU4DQpUbzogUGF1bCBUdXJuZXIgPFBBVUwuVFVSTkVS
QHZlbmFmaS5jb20+OyBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpDYzogUm9iaW4gV2ls
dG9uIDx3aWx0b25AaXNvYy5vcmc+OyA8dGxzQGlldGYub3JnPiA8dGxzQGlldGYub3JnPg0KU3Vi
amVjdDogUmU6IFtUTFNdIElzIHRoZXJlIGEgd2F5IGZvcndhcmQgYWZ0ZXIgdG9kYXkncyBodW0/
DQoNCg0KDQoNCg0KDQoNCk9uIDIwLzA3LzE3IDE1OjQwLCBQYXVsIFR1cm5lciB3cm90ZToNCg0K
PiBJ4oCZbSBhc3N1bWluZyB0aGF0IHlvdeKAmXJlIHJlZmVycmluZyB0byBtdWx0aXBsZSBuYXRp
b25zIGJlaW5nIGJldHdlZW4NCg0KPiB0aGUgVExTIGNsaWVudCBhbmQgc2VydmVyLiBJZiBhIFRM
UyBjbGllbnQgaXMgc2V0IHRvIG5vdCBpbmNsdWRlIHRoZQ0KDQo+IGV4dGVuc2lvbiwgaXQgc2Vl
bXMgdGhlIFRMUyBjbGllbnQgd291bGQgc2ltcGx5IGNsb3NlIHRoZSBjb25uZWN0aW9uLg0KDQo+
IEl0IHNlZW1zIHRoZSBjbGllbnQgY291bGQgY2hvb3NlIHdoZXRoZXIgaXQgd2FudGVkIHRvIGFw
cGVhc2UgdGhlDQoNCj4gbmF0aW9uIHN0YXRlcy4NCg0KDQoNClRocm91Z2ggaG93IG1hbnkgbmF0
aW9ucyBzdGF0ZXMgZGlkIHRoaXMgZW1haWwgdHJhdmVsIGJldHdlZW4geW91IGFuZCBJPyBNYWls
IGlzIG1heWJlIHdvcnNlIHRoYW4gdGhlIHdlYiwgYnV0IHRoYXQncyBqdXN0IHdpdGggb3VyIGN1
cnJlbnQgZGVwbG95bWVudHMgYnV0IHdobyBrbm93cyB3aGVuIHRoZXknbGwgbWlncmF0ZSBhIDVH
IFZNIGZvciBhIHdlYiBzZXJ2ZXIgY2xvc2UgdG8gbXkgYmFzZSBzdGF0aW9uPw0KDQoNCg0KQ2Fu
IHlvdSBjbGFyaWZ5IG9uIHRoZSBzY2VuYXJpbyBhIGJpdD8gSXMgb25lIG9yIG1vcmUgb2YgdGhl
IE1UQXMgaW4gdGhlIG5hdGlvbiBzdGF0ZSAodGhhdCB3YW50cyB0byBsaXN0ZW4pPyBJZiBzbywg
aXQgc2VlbXMgdGhlIG5hdGlvbiBzdGF0ZSBjYW4gZ2V0IHRvIHRoZSBkYXRhIHdpdGggb3B0aW9u
cyAxLCAyLCAgb3IgMyBpbiBteSBlYXJsaWVyIG1lc3NhZ2UgKG9wdGlvbnMgdGhhdCBhcmUgYXZh
aWxhYmxlIHdpdGggVExTIDEuMyB0b2RheSkuIFRoZXkgZG9u4oCZdCBoYXZlIHRvIGF0dGVtcHQg
dG8gY2lyY3VtdmVudCB0aGUgbWV0aG9kIFJ1c3MgZWx1ZGVkIHRvIGF0IHRoZSBiZWdpbm5pbmcg
b2YgdGhpcyB0aHJlYWQuDQoNCg0KDQpJJ2QgYXNzZXJ0IHRoZXJlJ3Mgbm8gd2F5IFRMUyBjbGll
bnRzIGluIGdlbmVyYWwgY291bGQga25vdyB3aGVuIHRvIHNldCBvciB1bnNldCB0aGUgInBsZWFz
ZSB3aXJldGFwIG1lIiBldmlsIGJpdCBpbiBhIENsaWVudEhlbGxvLCByZWdhcmRsZXNzIG9mIGhv
dyBjb21wbGV4IGEgY29uZmlndXJhdGlvbiBpcyB1c2VkLg0KDQoNCg0KSXQgc2VlbXMgbGlrZSB0
aGUgZ3VpZGFuY2Ugd291bGQgYmUgZm9yIGFsbCBUTFMgY2xpZW50cyB0byBOT1QgaW5jbHVkZSB0
aGUgZXh0ZW5zaW9uIGJ5IGRlZmF1bHQuIEFueW9uZSB3aG8gd2FudGVkIHRvIGVuYWJsZSBpdCBv
biB0aGVpciBUTFMgY2xpZW50IHdvdWxkIGhhdmUgdG8gZXhwbGljaXRseSB0dXJuIGl0IG9uIHRo
cm91Z2ggY29uZmlndXJhdGlvbi4gU2luY2UgdGhlIGNsaWVudCB3b3VsZG7igJl0IGluY2x1ZGUg
dGhlIGV4dGVuc2lvbiBhbmQgdGhlIHNlcnZlciB3b3VsZCBrbm93IHRoYXQgdGhlIGNsaWVudCB3
b3VsZCBhYm9ydCB0aGUgY29ubmVjdGlvbiBpZiBpdCBpbmNsdWRlZCB0aGUgZXh0ZW5zaW9uIGlu
IHJldHVybiAoYSB2aW9sYXRpb24gb2YgVExTIDEuMyksIHRoZSBzZXJ2ZXIgd291bGQgc2ltcGx5
IHByb2NlZWQgaW4ga2lsbGluZyB0aGUgY29ubmVjdGlvbiBpdHNlbGYuIEl0IGRvZXNu4oCZdCBz
ZWVtIGxpa2UgdGhlcmUgd291bGQgYmUgdGhlIG5lZWQgZm9yIGNvbXBsZXggY29uZmlndXJhdGlv
biBkZWNpc2lvbnMgdG8gYmUgbWFkZSBieSBUTFMgY2xpZW50IHVzZXJzIHdobyBoYXZlIG5vIGlu
dGVudGlvbiBvZiBlbmFibGluZyBpdC4gSXMgdGhhdCBjb3JyZWN0Pw0KDQoNCg0KQ2hlZXJzLA0K
DQpTLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg==

--_000_6a05aa8a00b847b9aac5fd020a57c928venaficom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp
Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBUTFMgW21h
aWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXBoZW4gRmFycmVsbDxi
cj4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDIwLCAyMDE3IDEwOjU4PGJyPg0KVG86IFBhdWwgVHVy
bmVyICZsdDtQQVVMLlRVUk5FUkB2ZW5hZmkuY29tJmd0OzsgVGVkIExlbW9uICZsdDttZWxsb25A
ZnVndWUuY29tJmd0Ozxicj4NCkNjOiBSb2JpbiBXaWx0b24gJmx0O3dpbHRvbkBpc29jLm9yZyZn
dDs7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVj
dDogUmU6IFtUTFNdIElzIHRoZXJlIGEgd2F5IGZvcndhcmQgYWZ0ZXIgdG9kYXkncyBodW0/PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIDIwLzA3LzE3IDE1OjQw
LCBQYXVsIFR1cm5lciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mZ3Q7IEnigJltIGFzc3VtaW5nIHRoYXQgeW91
4oCZcmUgcmVmZXJyaW5nIHRvIG11bHRpcGxlIG5hdGlvbnMgYmVpbmcgYmV0d2Vlbg0KPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+Jmd0OyB0aGUgVExTIGNsaWVudCBhbmQgc2VydmVyLiBJZiBhIFRMUyBjbGllbnQgaXMgc2V0
IHRvIG5vdCBpbmNsdWRlIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jmd0OyBleHRlbnNpb24sIGl0IHNlZW1zIHRo
ZSBUTFMgY2xpZW50IHdvdWxkIHNpbXBseSBjbG9zZSB0aGUgY29ubmVjdGlvbi48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m
Z3Q7IEl0IHNlZW1zIHRoZSBjbGllbnQgY291bGQgY2hvb3NlIHdoZXRoZXIgaXQgd2FudGVkIHRv
IGFwcGVhc2UgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mZ3Q7IG5hdGlvbiBzdGF0ZXMuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+VGhyb3VnaCBob3cgbWFueSBuYXRpb25zIHN0YXRlcyBkaWQgdGhpcyBlbWFpbCB0
cmF2ZWwgYmV0d2VlbiB5b3UgYW5kIEk/IE1haWwgaXMgbWF5YmUgd29yc2UgdGhhbiB0aGUgd2Vi
LCBidXQgdGhhdCdzIGp1c3Qgd2l0aCBvdXIgY3VycmVudCBkZXBsb3ltZW50cyBidXQgd2hvIGtu
b3dzIHdoZW4gdGhleSdsbCBtaWdyYXRlIGEgNUcgVk0gZm9yIGEgd2ViIHNlcnZlcg0KIGNsb3Nl
IHRvIG15IGJhc2Ugc3RhdGlvbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DYW4g
eW91IGNsYXJpZnkgb24gdGhlIHNjZW5hcmlvIGEgYml0PyBJcyBvbmUgb3IgbW9yZSBvZiB0aGUg
TVRBcyBpbiB0aGUgbmF0aW9uIHN0YXRlICh0aGF0IHdhbnRzIHRvIGxpc3Rlbik/IElmIHNvLCBp
dCBzZWVtcyB0aGUgbmF0aW9uIHN0YXRlIGNhbiBnZXQgdG8gdGhlIGRhdGEgd2l0aCBvcHRpb25z
IDEsIDIsJm5ic3A7IG9yIDMgaW4gbXkgZWFybGllciBtZXNzYWdlDQogKG9wdGlvbnMgdGhhdCBh
cmUgYXZhaWxhYmxlIHdpdGggVExTIDEuMyB0b2RheSkuIFRoZXkgZG9u4oCZdCBoYXZlIHRvIGF0
dGVtcHQgdG8gY2lyY3VtdmVudCB0aGUgbWV0aG9kIFJ1c3MgZWx1ZGVkIHRvIGF0IHRoZSBiZWdp
bm5pbmcgb2YgdGhpcyB0aHJlYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkknZCBh
c3NlcnQgdGhlcmUncyBubyB3YXkgVExTIGNsaWVudHMgaW4gZ2VuZXJhbCBjb3VsZCBrbm93IHdo
ZW4gdG8gc2V0IG9yIHVuc2V0IHRoZSAmcXVvdDtwbGVhc2Ugd2lyZXRhcCBtZSZxdW90OyBldmls
IGJpdCBpbiBhIENsaWVudEhlbGxvLCByZWdhcmRsZXNzIG9mIGhvdyBjb21wbGV4IGEgY29uZmln
dXJhdGlvbiBpcyB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkl0IHNlZW1z
IGxpa2UgdGhlIGd1aWRhbmNlIHdvdWxkIGJlIGZvciBhbGwgVExTIGNsaWVudHMgdG8gTk9UIGlu
Y2x1ZGUgdGhlIGV4dGVuc2lvbiBieSBkZWZhdWx0LiBBbnlvbmUgd2hvIHdhbnRlZCB0byBlbmFi
bGUgaXQgb24gdGhlaXIgVExTIGNsaWVudCB3b3VsZCBoYXZlIHRvIGV4cGxpY2l0bHkgdHVybiBp
dCBvbiB0aHJvdWdoIGNvbmZpZ3VyYXRpb24uDQogU2luY2UgdGhlIGNsaWVudCB3b3VsZG7igJl0
IGluY2x1ZGUgdGhlIGV4dGVuc2lvbiBhbmQgdGhlIHNlcnZlciB3b3VsZCBrbm93IHRoYXQgdGhl
IGNsaWVudCB3b3VsZCBhYm9ydCB0aGUgY29ubmVjdGlvbiBpZiBpdCBpbmNsdWRlZCB0aGUgZXh0
ZW5zaW9uIGluIHJldHVybiAoYSB2aW9sYXRpb24gb2YgVExTIDEuMyksIHRoZSBzZXJ2ZXIgd291
bGQgc2ltcGx5IHByb2NlZWQgaW4ga2lsbGluZyB0aGUgY29ubmVjdGlvbiBpdHNlbGYuIEl0IGRv
ZXNu4oCZdA0KIHNlZW0gbGlrZSB0aGVyZSB3b3VsZCBiZSB0aGUgbmVlZCBmb3IgY29tcGxleCBj
b25maWd1cmF0aW9uIGRlY2lzaW9ucyB0byBiZSBtYWRlIGJ5IFRMUyBjbGllbnQgdXNlcnMgd2hv
IGhhdmUgbm8gaW50ZW50aW9uIG9mIGVuYWJsaW5nIGl0LiBJcyB0aGF0IGNvcnJlY3Q/PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5TLjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_6a05aa8a00b847b9aac5fd020a57c928venaficom_--


From nobody Thu Jul 20 08:26:23 2017
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 A0571131CE2 for ; Thu, 20 Jul 2017 08:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgUtk0ibSEQB for ; Thu, 20 Jul 2017 08:26:20 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B32131C43 for ; Thu, 20 Jul 2017 08:26:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7C765BE38; Thu, 20 Jul 2017 16:26:18 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odWS6STcnzCO; Thu, 20 Jul 2017 16:26:17 +0100 (IST)
Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 09E09BE2F; Thu, 20 Jul 2017 16:26:16 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500564377; bh=L7+xNmJm4zjeykqQV5xnlKT3vejl72DNmWp4o6DlmDM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kpdajk4EYKAp0/OK0exdjC0qV2vVIHNy7oBFFPRa/WqMDY3QINK0L8Lbc1VUT3+V6 bZ/RXOLwOM49iM0jehuijrJ2RsltI9bIPtt6dFhgUluJkUvglX0mDfOvFTZV5BWT25 NDO6Cv7CnnsbYBQjSqQfMGkO6BzjBWa+gufSSCZ8=
To: Paul Turner , Ted Lemon 
Cc: Robin Wilton , "" 
References:    <691913e7a5d1464e8dda20c8848f6149@venafi.com>  <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>   <4b3855e4-0d37-bf25-5215-1ff179c13c59@cs.tcd.ie> <6a05aa8a00b847b9aac5fd020a57c928@venafi.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Thu, 20 Jul 2017 16:26:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <6a05aa8a00b847b9aac5fd020a57c928@venafi.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0caReDpK5M2BefDtxinVubsvx9Gc6r24w"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 15:26:23 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0caReDpK5M2BefDtxinVubsvx9Gc6r24w
Content-Type: multipart/mixed; boundary="j11sUMbmVHeXE6tAG6i6dBS0fCrqNFIJ6";
 protected-headers="v1"
From: Stephen Farrell 
To: Paul Turner , Ted Lemon 
Cc: Robin Wilton , "" 
Message-ID: 
Subject: Re: [TLS] Is there a way forward after today's hum?
References: 
 
 
 <691913e7a5d1464e8dda20c8848f6149@venafi.com>
 
 <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>
 
 
 <4b3855e4-0d37-bf25-5215-1ff179c13c59@cs.tcd.ie>
 <6a05aa8a00b847b9aac5fd020a57c928@venafi.com>
In-Reply-To: <6a05aa8a00b847b9aac5fd020a57c928@venafi.com>

--j11sUMbmVHeXE6tAG6i6dBS0fCrqNFIJ6
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 20/07/17 16:23, Paul Turner wrote:
>> I'd assert there's no way TLS clients in general could know when to
>> set or unset the "please wiretap me" evil bit in a ClientHello,
>> regardless of how complex a configuration is used.
> =20
>=20
> It seems like the guidance would be for all TLS clients to NOT
> include the extension by default. Anyone who wanted to enable it on
> their TLS client would have to explicitly turn it on through
> configuration. Since the client wouldn=E2=80=99t include the extension =
and
> the server would know that the client would abort the connection if
> it included the extension in return (a violation of TLS 1.3), the
> server would simply proceed in killing the connection itself. It
> doesn=E2=80=99t seem like there would be the need for complex configura=
tion
> decisions to be made by TLS client users who have no intention of
> enabling it. Is that correct?
No. What's correct is never even defining this at all.

If you think there's some other correct state of affairs I will
read the I-D you write describing that. (And then debunk it:-)

S.


--j11sUMbmVHeXE6tAG6i6dBS0fCrqNFIJ6--

--0caReDpK5M2BefDtxinVubsvx9Gc6r24w
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZcMuXAAoJEC88hzaAX42iussH/i5OYyzk8HnParVT2N9eA8a8
tpHQa2ROJGWlrjOZ2ByFU+O+NnVvgYkbgRFNq6Vge/yeM0K95HIZy4S3t1/CZXU2
qtOIfEHJt4lZzhcEEOynPN7zubmfJ4uAUuTL6AskiUCsLZNqvSXn7N+QGxmUKq8p
VZVW+zxY/NjMBpjpOHmpGcCq6rAFKusjgGTnH0PzFqXD2vh1E9R7BFCpTp5R2r4I
qlZyS3wWgS+3Se6iumnIX20MEsUhtsOB2sJeejic7h+xUihb7qESHh/cBm0sUd5Y
cp2ljOfP6HZQwDNai7RhY3k5aiPQSPYXB3828P92cK0GaL/hjNpf6qiOsvQbOmQ=
=rZVS
-----END PGP SIGNATURE-----

--0caReDpK5M2BefDtxinVubsvx9Gc6r24w--


From nobody Thu Jul 20 08:29:09 2017
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 C5DD21318A3 for ; Thu, 20 Jul 2017 08:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 764VbsBFJJNB for ; Thu, 20 Jul 2017 08:29:06 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544F5131746 for ; Thu, 20 Jul 2017 08:29:06 -0700 (PDT)
Received: from AWS-EXG01.res.venafi.com (10.50.110.17) by SLC-EXG01.res.venafi.com (10.1.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 09:29:04 -0600
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 09:29:02 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 09:29:01 -0600
From: Paul Turner 
To: Tom Ritter 
CC: Yoav Nir , IETF TLS 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQFQKzWnJzH4JA3szzi/CxpFoIjfXQF3s++XAXyk/AwCMzwq1AFKohfsAST5QOECNGnt5aMUJTCQ
Date: Thu, 20 Jul 2017 15:29:01 +0000
Message-ID: <6153a25746a246f9be26350adbc58213@venafi.com>
References:      <01a201d30169$f8c68530$ea538f90$@equio.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.197.8.30]
Content-Type: multipart/alternative; boundary="_000_6153a25746a246f9be26350adbc58213venaficom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 15:29:08 -0000

--_000_6153a25746a246f9be26350adbc58213venaficom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9tIFJpdHRlciBbbWFp
bHRvOnRvbUByaXR0ZXIudmddDQpTZW50OiBUaHVyc2RheSwgSnVseSAyMCwgMjAxNyAxMToyMA0K
VG86IFBhdWwgVHVybmVyIDxwdHVybmVyQGVxdWlvLmNvbT4NCkNjOiBZb2F2IE5pciA8eW5pci5p
ZXRmQGdtYWlsLmNvbT47IElFVEYgVExTIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RM
U10gSXMgdGhlcmUgYSB3YXkgZm9yd2FyZCBhZnRlciB0b2RheSdzIGh1bT8NCg0KDQoNCk9uIDIw
IEp1bHkgMjAxNyBhdCAxMDowNywgUGF1bCBUdXJuZXIgPHB0dXJuZXJAZXF1aW8uY29tPG1haWx0
bzpwdHVybmVyQGVxdWlvLmNvbT4+IHdyb3RlOg0KDQo+IEl0IHNlZW1zIGxpa2UgdGhhdCBwcm9i
bGVtIGV4aXN0cyB0b2RheSB3aXRoIFRMUyAxLjMuIElmIGEgZ292ZXJubWVudA0KDQo+IGlzIHBv
d2VyZnVsIGVub3VnaCB0byBtYW5kYXRlIGtleSBlc2Nyb3csIHdvdWxkbuKAmXQgdGhleSBhbHNv
IGJlIHBvd2VyDQoNCj4gZW5vdWdoIHRvIG1hbmRhdGUgaW1wbGVtZW50aW5nIHN0YXRpYyBESCB3
aXRoIFRMUyAxLjMgKHNvIHRoYXQgdGhleQ0KDQo+IGtleSBlc2Nyb3cgaXMgcG9zc2libGUpLiBJ
biBhZGRpdGlvbiwgYmFzZWQgb24gdGhpcyBsZXZlbCBvZg0KDQo+IGluZmx1ZW5jZSwgY291bGRu
4oCZdCB0aGV5IGFsdGVybmF0aXZlbHkgcmVxdWlyZSBUTFMgc2VydmVyIG93bmVycyB0byBwcm92
aWRlIHRoZW0gdW5lbmNyeXB0ZWQgZGF0YS4NCg0KDQoNCg0KDQpBbnl0aGluZydzIHBvc3NpYmxl
LCBidXQgaXQgdGhlcmUncyBhIGRpZmZlcmVuY2UgYmV0d2VlbjoNCg0KDQoNCiJJIGRlbWFuZCB5
b3UgaW1wbGVtZW50IGEgbmV3IG1lY2hhbmlzbSB0byBzZWN1cmVseSBzaGlwIG1lIGNyeXB0byBr
ZXlzIG9yIHBsYWludGV4dCwgZG8gc29tZXRoaW5nIGZvciB3aGljaCB0aGVyZSBpcyBubyBzdGFu
ZGFyZCBtZWNoYW5pc20gb3IgYWdyZWVtZW50LiINCg0KDQoNCmFuZA0KDQoNCg0KIklmIHlvdSBm
bGlwIHRoaXMgZXhpc3Rpbmcgc2V0dGluZyByaWdodCBoZXJlIGluIE9wZW5TU0wsIGFuZCBzdGlj
ayB0aGlzIHB1YmxpYyBrZXkgcmlnaHQgaGVyZSwgaXQgd2lsbCBhdXRvbWF0aWNhbGx5IHNhdGlz
Znkgb3VyIHJlcXVpcmVtZW50cy4iDQoNCg0KDQpUaGFua3MgZm9yIHRoaXMgY2xhcmlmaWNhdGlv
bi4gSSBhZ3JlZSB0aGF0IGFueXRoaW5nIGlzIHBvc3NpYmxlIGluIGJvdGggZGlyZWN0aW9ucy4g
UnVzcyBvcGVuZWQgdGhpcyBkaXNjdXNzaW9uIGJ5IGFza2luZyBhYm91dCBhbiBhbHRlcm5hdGl2
ZSB0byBzdGF0aWMgREguIEluIHRoaXMgbW9kZWwsIEnigJl2ZSBhc3N1bWVkIHRoZSBjbGllbnQg
d291bGQgbmVlZCB0byBleHBsaWNpdGx5IG9wdC1pbiBieSBpbmNsdWRpbmcgYW4gZXh0ZW5zaW9u
IGluIGl0cyBDbGllbnRIZWxsby4gVGhlcmUgYXJlIG9idmlvdXNseSBkZXRhaWxzIHRvIHdvcmsg
b3V0IGJ1dCBpZiBpdCB3ZXJlIHBvc3NpYmxlIHRvIHByb3ZpZGUgYSBtZXRob2QgbGlrZSB0aGF0
LCBpdCBzZWVtcyBsaWtlIGl0IHdvdWxkIHRod2FydCB0aGUgc2Vjb25kIG9wdGlvbi4gV291bGQg
aXQ/DQoNCg0KDQpJIHJlY2FsbCBvbmUgb2YgdGhlIGFyZ3VtZW50cyB0aGF0IEFwcGxlIG1hZGUg
YWdhaW5zdCB0aGUgRkJJIHdhcyB0aGF0IHRoZXkgd2VyZSBhc2tpbmcgdGhlbSB0byBkbyBzb21l
dGhpbmcgbm92ZWwgdGhhdCByZXF1aXJlZCBzaWduaWZpY2FudCBhbW91bnRzIG9mIHdvcmssIHRl
c3RpbmcsIGhhZCBuZXZlciBiZWVuIGRvbmUgYmVmb3JlLCBldGMuIElBTkFMIGJ1dCBJIHRoaW5r
IHRoaXMgaXMgc3RhbmRhcmQgYXJndW1lbnQgdG8gc2hvdyB0aGUgcmVxdWVzdCBpcyB1bnJlYXNv
bmFibGUgYW5kIG92ZXJseSBidXJkZW5zb21lLiBSZW1vdmluZyB0aGF0IGFyZ3VtZW50IGNvbmNl
cm5zIG1lLg0KDQooVVMtY2VudHJpYyB2aWV3IGlmIHRoYXQgaXNuJ3QgYXBwYXJlbnQuKQ0KDQoN
Cg0KLXRvbQ0K

--_000_6153a25746a246f9be26350adbc58213venaficom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp
Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBUb20gUml0
dGVyIFttYWlsdG86dG9tQHJpdHRlci52Z10gPGJyPg0KU2VudDogVGh1cnNkYXksIEp1bHkgMjAs
IDIwMTcgMTE6MjA8YnI+DQpUbzogUGF1bCBUdXJuZXIgJmx0O3B0dXJuZXJAZXF1aW8uY29tJmd0
Ozxicj4NCkNjOiBZb2F2IE5pciAmbHQ7eW5pci5pZXRmQGdtYWlsLmNvbSZndDs7IElFVEYgVExT
ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtUTFNdIElzIHRoZXJlIGEg
d2F5IGZvcndhcmQgYWZ0ZXIgdG9kYXkncyBodW0/PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+T24gMjAgSnVseSAyMDE3IGF0IDEwOjA3LCBQYXVsIFR1cm5lciAm
bHQ7PGEgaHJlZj0ibWFpbHRvOnB0dXJuZXJAZXF1aW8uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6
d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+cHR1cm5lckBlcXVpby5jb208L3NwYW4+
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jmd0OyBJdCBzZWVtcyBsaWtlIHRoYXQgcHJvYmxlbSBl
eGlzdHMgdG9kYXkgd2l0aCBUTFMgMS4zLiBJZiBhIGdvdmVybm1lbnQNCjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsg
aXMgcG93ZXJmdWwgZW5vdWdoIHRvIG1hbmRhdGUga2V5IGVzY3Jvdywgd291bGRu4oCZdCB0aGV5
IGFsc28gYmUgcG93ZXINCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZndDsgZW5vdWdoIHRvIG1hbmRhdGUgaW1wbGVtZW50
aW5nIHN0YXRpYyBESCB3aXRoIFRMUyAxLjMgKHNvIHRoYXQgdGhleQ0KPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jmd0OyBr
ZXkgZXNjcm93IGlzIHBvc3NpYmxlKS4gSW4gYWRkaXRpb24sIGJhc2VkIG9uIHRoaXMgbGV2ZWwg
b2YNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPiZndDsgaW5mbHVlbmNlLCBjb3VsZG7igJl0IHRoZXkgYWx0ZXJuYXRpdmVs
eSByZXF1aXJlIFRMUyBzZXJ2ZXIgb3duZXJzIHRvIHByb3ZpZGUgdGhlbSB1bmVuY3J5cHRlZCBk
YXRhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFueXRoaW5nJ3MgcG9z
c2libGUsIGJ1dCBpdCB0aGVyZSdzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuOjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPiZxdW90O0kgZGVtYW5kIHlvdSBpbXBsZW1lbnQgYSBuZXcgbWVjaGFuaXNtIHRv
IHNlY3VyZWx5IHNoaXAgbWUgY3J5cHRvIGtleXMgb3IgcGxhaW50ZXh0LCBkbyBzb21ldGhpbmcg
Zm9yIHdoaWNoIHRoZXJlIGlzIG5vIHN0YW5kYXJkIG1lY2hhbmlzbSBvciBhZ3JlZW1lbnQuJnF1
b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YW5kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+JnF1
b3Q7SWYgeW91IGZsaXAgdGhpcyBleGlzdGluZyBzZXR0aW5nIHJpZ2h0IGhlcmUgaW4gT3BlblNT
TCwgYW5kIHN0aWNrIHRoaXMgcHVibGljIGtleSByaWdodCBoZXJlLCBpdCB3aWxsIGF1dG9tYXRp
Y2FsbHkgc2F0aXNmeSBvdXIgcmVxdWlyZW1lbnRzLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPlRoYW5rcyBmb3IgdGhpcyBjbGFyaWZpY2F0aW9uLiBJIGFncmVlIHRoYXQg
YW55dGhpbmcgaXMgcG9zc2libGUgaW4gYm90aCBkaXJlY3Rpb25zLiBSdXNzIG9wZW5lZCB0aGlz
IGRpc2N1c3Npb24gYnkgYXNraW5nIGFib3V0IGFuIGFsdGVybmF0aXZlIHRvIHN0YXRpYyBESC4g
SW4gdGhpcyBtb2RlbCwgSeKAmXZlIGFzc3VtZWQgdGhlIGNsaWVudCB3b3VsZCBuZWVkDQogdG8g
ZXhwbGljaXRseSBvcHQtaW4gYnkgaW5jbHVkaW5nIGFuIGV4dGVuc2lvbiBpbiBpdHMgQ2xpZW50
SGVsbG8uIFRoZXJlIGFyZSBvYnZpb3VzbHkgZGV0YWlscyB0byB3b3JrIG91dCBidXQgaWYgaXQg
d2VyZSBwb3NzaWJsZSB0byBwcm92aWRlIGEgbWV0aG9kIGxpa2UgdGhhdCwgaXQgc2VlbXMgbGlr
ZSBpdCB3b3VsZCB0aHdhcnQgdGhlIHNlY29uZCBvcHRpb24uIFdvdWxkIGl0PzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj5JIHJlY2FsbCBvbmUgb2YgdGhlIGFyZ3VtZW50cyB0aGF0IEFw
cGxlIG1hZGUgYWdhaW5zdCB0aGUgRkJJIHdhcyB0aGF0IHRoZXkgd2VyZSBhc2tpbmcgdGhlbSB0
byBkbyBzb21ldGhpbmcgbm92ZWwgdGhhdCByZXF1aXJlZCBzaWduaWZpY2FudCBhbW91bnRzIG9m
IHdvcmssIHRlc3RpbmcsIGhhZCBuZXZlciBiZWVuIGRvbmUgYmVmb3JlLCBldGMuIElBTkFMIGJ1
dA0KIEkgdGhpbmsgdGhpcyBpcyBzdGFuZGFyZCBhcmd1bWVudCB0byBzaG93IHRoZSByZXF1ZXN0
IGlzIHVucmVhc29uYWJsZSBhbmQgb3Zlcmx5IGJ1cmRlbnNvbWUuIFJlbW92aW5nIHRoYXQgYXJn
dW1lbnQgY29uY2VybnMgbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KFVTLWNlbnRyaWMgdmlldyBpZiB0aGF0IGlzbid0
IGFwcGFyZW50Lik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tdG9tPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_6153a25746a246f9be26350adbc58213venaficom_--


From nobody Thu Jul 20 08:38:31 2017
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 B335913188D for ; Thu, 20 Jul 2017 08:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 H5AdlqmNfoio for ; Thu, 20 Jul 2017 08:38:27 -0700 (PDT)
Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (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 489A212EC46 for ; Thu, 20 Jul 2017 08:38:27 -0700 (PDT)
Received: from [91.183.52.43] (helo=[192.168.1.189]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1dYDWz-0007vO-B6 for tls@ietf.org; Thu, 20 Jul 2017 17:38:25 +0200
To: "tls@ietf.org" 
References:    <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net>  <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>  <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie>  <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com>   
From: Simon Friedberger 
Message-ID: <8d485710-d55e-28b9-3197-ad2d9880f5eb@a-oben.org>
Date: Thu, 20 Jul 2017 17:38:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 15:38:30 -0000

I would like to point out that a lot of this discussion seems to hinge
on the following argument:


On 17/07/17 13:04, Roland Dobbins wrote:
> On 16 Jul 2017, at 11:14, Salz, Rich wrote:
>
>> I really want to hear an answer to that question from folks who say
>> they need TLS 1.3 but without it.
>
> Being able to continue to utilize vetted, well-understood,
> standards-based cryptography on intranets once regulatory bodies such
> as PCI/DSS mandate TLS 1.3 or above - which will happen, at some point
> in the not-too-distant future.

So the only reason not to use TLS 1.2 for these use cases is that it is
assumed that some regulator will in the future prohibit not using it.

(I don't think TLS 1.2 is going away any time soon so it will continue
to be vetted, well-understood and standards-based.)

I think it is up to those regulators to do their job properly and not
require TLS 1.3 for situations when it does not fullfil the requirements.
Or conversely if regulators still require TLS 1.3 although it does not
support the desired traffic inspection maybe they have made that
decision with good reason.


From nobody Thu Jul 20 08:45:22 2017
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 8CD9C131746 for ; Thu, 20 Jul 2017 08:45:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiNLqhdE06tT for ; Thu, 20 Jul 2017 08:45:20 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 361F21252BA for ; Thu, 20 Jul 2017 08:45:20 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id 35so26257635uax.3 for ; Thu, 20 Jul 2017 08:45:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6b4ebNb3Cq4Cpvyh1bH5veOhUCO76dLiEPamlHdG1Mo=; b=mi8CyFGE4OBaN8Jb+iOhNvDcaFcNpWTVjXQE+W788DQcFCccrEX7FjHbq4bj+8qa4R jv/6CR5e1yaXbnLsPnTNa8PGI1h+d1stYBCrrh6GhDwAeuB0wDi2LSo9/yFD66J0Nn4b kEy9Wr/GpbOUm7SsM5TLkzdDxty4gzxOmpl2E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6b4ebNb3Cq4Cpvyh1bH5veOhUCO76dLiEPamlHdG1Mo=; b=R9ddvYnCMAZCIyT8K2ZbN8fxB0f9+dnJ4qceZgmK5G5XYgzt+AYBxbkHwRxSSuCaIl Rr43S1NIAB427uVq+T5c1AjgRPefAMsXqN75YujEjhlXx0Ftwr/ySvG9WOmPzM8jhtLv FmS9v1z0kyhjkoJLnyWMXJRatqLN9kQLmZDhv0hKXaZH4xp+O4QrC3h1TQlOSRaUcTze TStl0tq5/AFnf8TNha/Y8vJlgKWs3ZLv49eruuQBf/JsORVWVPbEv5lMhYWDIZZhzFWX D/HzqLP3az6LVxMcD3AitIUJMGJIsTGJ+DVVwdixEx3fb3ZLZkjjputvZfoKymYNXBdO qIDg==
X-Gm-Message-State: AIVw112gK35/WbZ0zEtc/20b86UlXeRkUdJdnjFEcpHPpZYm2ySkVr9b I0BmokZCz0kgkG9bmO5ecTR6ktve1FKG
X-Received: by 10.31.61.88 with SMTP id k85mr205312vka.19.1500565519122; Thu, 20 Jul 2017 08:45:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.195 with HTTP; Thu, 20 Jul 2017 08:44:58 -0700 (PDT)
In-Reply-To: <6153a25746a246f9be26350adbc58213@venafi.com>
References:      <01a201d30169$f8c68530$ea538f90$@equio.com>  <6153a25746a246f9be26350adbc58213@venafi.com>
From: Tom Ritter 
Date: Thu, 20 Jul 2017 10:44:58 -0500
Message-ID: 
To: Paul Turner 
Cc: Yoav Nir , IETF TLS 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 15:45:21 -0000

On 20 July 2017 at 10:29, Paul Turner  wrote:
> Thanks for this clarification. I agree that anything is possible in both
> directions. Russ opened this discussion by asking about an alternative to
> static DH. In this model, I=E2=80=99ve assumed the client would need to e=
xplicitly
> opt-in by including an extension in its ClientHello. There are obviously
> details to work out but if it were possible to provide a method like that=
,
> it seems like it would thwart the second option. Would it?

Not when the target of the request is Facebook for their Messenger
App. Or Google for the Gmail app, or Hangouts. Or Skype.

What percentage of TLS protected communication takes place between a
client and server developed by the same company? All of that is
immediately at risk.

What about 360 Browser (one of the popular Chinese-made web browsers)?
Hell, they _still_ aren't validating SSL certificates!![0] The dynamic
for them (both technical and political) is quite different than for
what we tend to think of as 'browsers'.

I get the impression you're assuming that 'the' (for nebulous values
of 'the') government isn't going to ask a web browser to support the
mechanism, and they would only go to the webservers. But because it's
an offer/accept mechanism, there's an argument that goes "Hey
Browser-Maker make all of your installs _offer_ to encrypt to our
escrow key, and if the server doesn't accept it, don't." "Hey
US-Company, make all of your web servers support escrowing to our key
if the client offers to. If the client doesn't offer, don't."

The more I think about standardizing such a mechanism the more nervous
I get we will be building something that is too likely to be used,
even if not expansively, against the ideals we have espoused in 2804
and elsewhere.

-tom

[0] Yea. Really. It was this case a little bit ago for 99% of sites on
the web and I'll make you a bet it's still the case today.


From nobody Thu Jul 20 09:33:45 2017
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 5ABE1131A76 for ; Thu, 20 Jul 2017 09:33:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OIjGhxGKXSfv for ; Thu, 20 Jul 2017 09:33:42 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 23CF01318A3 for ; Thu, 20 Jul 2017 09:33:42 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id k71so19498272wrc.2 for ; Thu, 20 Jul 2017 09:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jOIONR+KcXHJffbqfCKXG1/fMkBw7PU+pblikw9ollg=; b=waNXHF3blTX6hbCtgcJQ8YSENT1uKh9FjugnxnURn3IAiQwsHhQqcIorFcBbAgqbxi VC/rGfxzy6BfIHcoM2lTPQqMuUT3UD5tWBROade4K+yRvRx++EVInVEdtTAhobs1MrMn 3gduAuujaWwM5onL4v7x6l6dT6mXhLuWA3Y7A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jOIONR+KcXHJffbqfCKXG1/fMkBw7PU+pblikw9ollg=; b=YftBZ4NLJPigOH498lqPip9NgkGayX7BXlOySSKF+Fi+2F5NsSIbnqwR/S1DPYtihd KR42g0M0vovdn3p8b5MrpiyrpgUMQXcVjNSZOBGIC5wLu92u+zwK/7oosiLm6msudZTI I4cQBE63a4Vjh38rTjLXHPv9gpEjBTP4H0m5f3kXSeTBDrdvIafHNV95bEg63vl0vq9z +gPmjO8azMqDh4H7vl0AfZrYucPg5f4iHRgOOYEuds9+PLbHs/rdjOBCMzkqpGBIJRbV o8jAvgrUWmbcXm9r410ayUYYeeBG5YwosDfHdBb4Ib8LwIWqKZ9sywd+aCCjJ0PSbWdj iRXg==
X-Gm-Message-State: AIVw113W0LFKROl4DGcXZF4oNx4/yzQWUPRamRnKMjAZmbG9nALlM0qh BPuT00FSXxKMSqwbcn/CyavaBpcfBY+i
X-Received: by 10.223.160.174 with SMTP id m43mr7061487wrm.194.1500568420705;  Thu, 20 Jul 2017 09:33:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.234.22 with HTTP; Thu, 20 Jul 2017 09:33:40 -0700 (PDT)
In-Reply-To: <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII>
References:  <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII>
From: Watson Ladd 
Date: Thu, 20 Jul 2017 09:33:40 -0700
Message-ID: 
To: Ilari Liusvaara 
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a114b56d6ada1230554c24f3f"
Archived-At: 
Subject: Re: [TLS] draft-ietf-tls-exported-authenticator questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 16:33:44 -0000

--001a114b56d6ada1230554c24f3f
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 20, 2017 at 12:02 AM, Ilari Liusvaara 
wrote:

> While reading/implementing draft-ietf-tls-exported-authenticator I came
> across the following:
>
> 1)
>
> The exporter labels are the opposite way around for handshake
> contexts and finished keys, which makes little sense.
>
> The text seems to imply that the finished key label the client
> uses for sending is "EXPORTER-server authenticator finished key".
>

That is clearly bug. Thanks for commenting.

>
> 2)
>
> In TLS 1.2, even if TLS PRF is not used, the hash function that
> absolutely must exist is called "the hash function to use in the
> Finished message computation" or "the hash function defined for the
> Finished message computation" (and if TLS PRF is used, this hash is
> the same hash function as the one underlying TLS PRF).
>
> TLS 1.3 is less consistent:
>
> - "the Hash algorithm for the handshake" (4.4.4)
> - "KDF hash algorithm" (4.6.1)
> - "the cipher suite hash algorithm" (7.1)
> - "the [...] hash algorithm to be used with HKDF" (B.4)
>
> ... All those apparently refer to one and the same thing.
>
> 3)
>
> What is the Hash() in
>
> "Hash(Handshake Context || Certificate)" and
> "Hash(Handshake Context || Certificate || CertificateVerify)"
>
> ?
>
> I presume it is the same hash as the one took the output length of
> in 2).
>

That is what I interpreted it as.

>
> 4)
>
> What is "the hash function from the handshake" exactly? I presume it
> is the same hash as in 3).
>

It's sad that there is not a hash function determined by negotiation in
TLS. What text would identify it?

>
>
> 5)
>
> Test vectors would be nice (use some deterministic signature, like
> Ed25519)...
>
> I have one set of vectors I dumped from my implementation, but no
> idea if those are correct (for example, I assumed that the handshake
> context and finished labels are the same way around, and the hash for
> points 2 to 4 is the hash function defined for the Finished message
> computation in the TLS connection the authenticator is to be created
> from).
>

There is a site at leftshark.tls13.com that uses this extension. It hasn't
been updated for the latest draft just yet

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

--001a114b56d6ada1230554c24f3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Thu, Jul 20, 2017 at 12:02 AM, Ilari Liusvaara <=
;ilariliusvaa=
ra@welho.com> wrote:
    While =
reading/implementing draft-ietf-tls-exported-authenticator I came
    
across the following:
    

    
1)
    

    
The exporter labels are the opposite way around for handshake
    
contexts and finished keys, which makes little sense.
    

    
The text seems to imply that the finished key label the client
    
uses for sending is "EXPORTER-server authenticator finished key".=


    That is clearly bug. Thanks for commen=
ting.
    

    
2)
    

    
In TLS 1.2, even if TLS PRF is not used, the hash function that
    
absolutely must exist is called "the hash function to use in the
    
Finished message computation" or "the hash function defined for t=
he
    
Finished message computation" (and if TLS PRF is used, this hash is
the same hash function as the one underlying TLS PRF).
    

    
TLS 1.3 is less consistent:
    

    
- "the Hash algorithm for the handshake" (4.4.4)
    
- "KDF hash algorithm" (4.6.1)
    
- "the cipher suite hash algorithm" (7.1)
    
- "the [...] hash algorithm to be used with HKDF" (B.4)
    

    
... All those apparently refer to one and the same thing.
    

    
3)
    

    
What is the Hash() in
    

    
"Hash(Handshake Context || Certificate)" and
    
"Hash(Handshake Context || Certificate || CertificateVerify)"
    

    
?
    

    
I presume it is the same hash as the one took the output length of
    
in 2).

    That is what I interpreted it as=
.=C2=A0
    

    
4)
    

    
What is "the hash function from the handshake" exactly? I presume=
 it
    
is the same hash as in 3).

    It's sad=
 that there is not a hash function determined by negotiation in TLS. What t=
ext would identify it?
    

    

    
5)
    

    
Test vectors would be nice (use some deterministic signature, like
    
Ed25519)...
    

    
I have one set of vectors I dumped from my implementation, but no
    
idea if those are correct (for example, I assumed that the handshake
    
context and finished labels are the same way around, and the hash for
    
points 2 to 4 is the hash function defined for the Finished message
    
computation in the TLS connection the authenticator is to be created
    
from).

    There is a site at leftshark.tls13.com that uses this extension.=
 It hasn't been updated for the latest draft just yet=C2=A0
    

    

    

    
-Ilari
    

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


    

--001a114b56d6ada1230554c24f3f--


From nobody Thu Jul 20 09:44:02 2017
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 C6C4C127B60 for ; Thu, 20 Jul 2017 09:44:00 -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 biOHQPvXpLKW for ; Thu, 20 Jul 2017 09:43:59 -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 55B6F129B15 for ; Thu, 20 Jul 2017 09:43:59 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id a12so15060588ywh.3 for ; Thu, 20 Jul 2017 09:43:59 -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=eNEpreL1hgL1SLp693KexCrIXVMbzbCaZv0SVaEz2hY=; b=RuOTJuwP76eYJLwaBPpjWKJCfpXWejtQJKJR4kEUNpX3JyGfh7vmiLxUH96HG0MC92 PVB5Xh/eKpYCKk+acee8GK6HwQKpG07JFNAnWZvX76NHLiHeKdn8nkm1sTagx7faQm9X nfx9VZq4+MssS3JzwV3qDhmq0Uqxk71N1yiUiWhet3yW0ZN/su8swC0E6zelxh8GB1T/ eMF+AA8Cbp0ueHJdAV+XgaZhCKMvu9x2K20lv/qXnnmWxjlWXyp8ndfpMmuCMDOdUz1A ZeDnhscLyK4MhfehzaMm3IcjC4lh4CSiyqhyrQV9FsznpP+0MTqbU5VBcbL/Id7z3ekz xUZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eNEpreL1hgL1SLp693KexCrIXVMbzbCaZv0SVaEz2hY=; b=MQjxBAlqvTDiAR8s7yi5v76V5eiMzwMC2o/6zgFbBIRdk6J7dLE7vDWIs7EYV/7vpV O2QmaRs01V56k/qZTD74YO6iqxRdQ8YuQH/3Gv0R+y46GVDU4tC//iGAGk0tpZ1KhB/y kK3JqIgmUBCRKNgGG6hdDJHkBdVi57PKHZmLjp61ISGosdArvOwCPcoSjPlPLOALGjVT C/z53IrW3op+ZG+/SUHbdJsjO8bAIzKciAnSmuc6LuKnrLKD84EukKWEJvyM0CeUbvSB jM1yhO+STEIMLnVWpHxGL2guKdI1F1Y9rXbs08pk9aFRO9F0BhT4F58hiOkusJ+hwNkw GQbw==
X-Gm-Message-State: AIVw111gyGKSuKj0fO/jpFRFpN8eeBUik9pMXV/yc1tSVomjhTMbCJyy Ts5bqpgzeV9he6R++vZVfsALcvsYXDfLlpk=
X-Received: by 10.129.177.74 with SMTP id p71mr3605127ywh.388.1500569038371; Thu, 20 Jul 2017 09:43:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Thu, 20 Jul 2017 09:43:57 -0700 (PDT)
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>        
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 20 Jul 2017 09:43:57 -0700
Message-ID: 
To: "Salz, Rich" 
Cc: Andrei Popov , "" 
Content-Type: multipart/alternative; boundary="94eb2c13d5c27e851a0554c2744d"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 16:44:01 -0000

--94eb2c13d5c27e851a0554c2744d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 20, 2017 at 12:44 AM, Salz, Rich  wrote:

> It=E2=80=99s like saying =E2=80=9Call browsers that support TLS support w=
iretapping
> because of the static RSA key exchange.=E2=80=9D
>
>
>
> It=E2=80=99s a little disingenuous
>


It sure is! and hyperbolic, but that's the term that people keep applying,
so it's clarifying to use it consistently whenever we talk about this.

While I'm at it, I can't make sense of:

"Using the RSA key to decrypt traffic to your server is wire-tapping."
"Using the RSA key to impersonate and MITM your server isn't wire-tapping."

We'll still support the latter, which is much worse than the former :( I
can't see how offering something /between/ the two, more secure than the
latter, isn't a net improvement on where we'll be with TLS1.3.

--=20
Colm

--94eb2c13d5c27e851a0554c2744d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Thu, Jul 20, 2017 at 12:44 AM, Salz, Rich <rsalz@akamai.com><=
/span> wrote:
    






    

    

    It=E2=80=99s like saying =E2=80=9Call browsers that=
 support TLS support wiretapping because of the static RSA key exchange.=E2=
=80=9D
    

    =C2=A0
    

    It=E2=80=99s a little disingenuous
    =



    It sure is! and hyper=
bolic, but that's the term that people keep applying, so it's clari=
fying to use it consistently whenever we talk about this.=C2=A0
    <=
br>
    While I'm at it, I can't make sense of:
    "Using the RSA key to decrypt traffic to your server is wi=
re-tapping."
    "Using the RSA key to impersonate and MITM=
 your server isn't wire-tapping."

    We'=
ll still support the latter, which is much worse than the former :( I can&#=
39;t see how offering something /between/ the two, more secure than the lat=
ter, isn't a net improvement on where we'll be with TLS1.3.=C2=A0

    -- 
    Colm
    

    

--94eb2c13d5c27e851a0554c2744d--


From nobody Thu Jul 20 09:46:47 2017
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 45C12131D1D; Thu, 20 Jul 2017 09:46:45 -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.57.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150056920528.22673.8666714430219272177.idtracker@ietfa.amsl.com>
Date: Thu, 20 Jul 2017 09:46:45 -0700
Archived-At: 
Subject: [TLS] The TLS WG has placed draft-thomson-tls-record-limit in state "Candidate for WG Adoption"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list 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, 20 Jul 2017 16:46:45 -0000

The TLS WG has placed draft-thomson-tls-record-limit in state
Candidate for WG Adoption (entered by Sean Turner)

The document is available at
https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/


From nobody Thu Jul 20 09:48:33 2017
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 112DA131D14; Thu, 20 Jul 2017 09:48:31 -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.57.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150056931106.22393.7391499761537798716.idtracker@ietfa.amsl.com>
Date: Thu, 20 Jul 2017 09:48:31 -0700
Archived-At: 
Subject: [TLS] The TLS WG has placed draft-huitema-tls-sni-encryption in state "Candidate for WG Adoption"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list 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, 20 Jul 2017 16:48:31 -0000

The TLS WG has placed draft-huitema-tls-sni-encryption in state
Candidate for WG Adoption (entered by Sean Turner)

The document is available at
https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/


From nobody Thu Jul 20 09:55:31 2017
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 6F820131AFC for ; Thu, 20 Jul 2017 09:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JszLH4Iu6iKd for ; Thu, 20 Jul 2017 09:55:27 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32453129B15 for ; Thu, 20 Jul 2017 09:55:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F41E1BE39; Thu, 20 Jul 2017 17:55:24 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYIiH5wQbAn9; Thu, 20 Jul 2017 17:55:23 +0100 (IST)
Received: from [31.133.148.54] (dhcp-9436.meeting.ietf.org [31.133.148.54]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 10825BE38; Thu, 20 Jul 2017 17:55:22 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500569723; bh=60PrBDskPIU7M4Y4kuBUqvxXwrfrHJ3re0bYexr3H2Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nfkG+jl/h0n0SIdIa0qnO7KsMluq5Pi4nVAxyd3wtD5xBT69Lk4WebTSpMI32wwe7 Xl7ZJPg0+EUnO1rjIWVJZpVyVhmE9ImRz1ZTIylqrKB6Soks8sqJvV5aWG3Z7Wp0ZS ZUp+hfjMWzla4AnfGSr6Zg4k6RewDvGhlF1zx3/w=
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , "Salz, Rich" 
Cc: "" 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>         
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <09123555-1e27-c6e7-9e3a-fd87df868991@cs.tcd.ie>
Date: Thu, 20 Jul 2017 17:55:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GtqAUKNuieDCGsp9O3rcNwRonl6MB3LeO"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 16:55:29 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--GtqAUKNuieDCGsp9O3rcNwRonl6MB3LeO
Content-Type: multipart/mixed; boundary="wwFNJHbo2KJQwR9IL1eOqAJ36j2ASnoUR";
 protected-headers="v1"
From: Stephen Farrell 
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= ,
 "Salz, Rich" 
Cc: "" 
Message-ID: <09123555-1e27-c6e7-9e3a-fd87df868991@cs.tcd.ie>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
 <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie>
 <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com>
 <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>
 
 
 
 
 
 
 
 
 
In-Reply-To: 

--wwFNJHbo2KJQwR9IL1eOqAJ36j2ASnoUR
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 20/07/17 17:43, Colm MacC=C3=A1rthaigh wrote:
> that's the term that people keep applying,

That term was appropriate for draft-green as justified in [1]
That's disputed by some folks but it's the correct term.

Claiming that current browsers "support" wiretapping is plain
odd to me and not that useful for the discussion but isn't a
TLS protocol issue as we don't currently have, and don't have
a WG proposal for a draft-green like wiretapping API as part
of the TLS WG set of RFCs.

S.

[1] https://github.com/sftcd/tinfoil#why-is-this-wiretapping


--wwFNJHbo2KJQwR9IL1eOqAJ36j2ASnoUR--

--GtqAUKNuieDCGsp9O3rcNwRonl6MB3LeO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZcOB5AAoJEC88hzaAX42iVF0IAKCwYRxmO9UkIy8OpPvoHHXy
9AvOwpcUy7ZviqWThWXMIt1Olp1xgztzCrp+UXLOMys2iFYDk6ahzM6xTfm1DRV4
YetCAZz5oVMsRTTR2xMPNNPgcwZQsbW1YoDm0SpfVf9zO1IplJZBTxYA/8RCU772
oGGV9athoXm7FiVOJCUsfncmuIZi8YnCjkwgFkDFtYlRabTAtvRl3HsbQHPTUK8F
X1EbNpyN2t+b3fQaYln9Vnqoj6+HpKciv6NuhugF4oB0NVORUshexfVnDNJ3cGGl
8TP7b9F3wh3J9XHocptF0m9qG9M0LdpzMQsuPoGoESpOHu+dCXZhgryxWLh1TvY=
=4QV7
-----END PGP SIGNATURE-----

--GtqAUKNuieDCGsp9O3rcNwRonl6MB3LeO--


From nobody Thu Jul 20 10:08:20 2017
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 7C6B7131B2B for ; Thu, 20 Jul 2017 10:08:16 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 2c1WPrW_grLM for ; Thu, 20 Jul 2017 10:08:15 -0700 (PDT)
Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 E4CFC127B60 for ; Thu, 20 Jul 2017 10:08:14 -0700 (PDT)
Received: by mail-yb0-x236.google.com with SMTP id v129so4759278ybv.5 for ; Thu, 20 Jul 2017 10:08:14 -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=df5hNmTxzd0Y40J28Qi6dKkwe3TrhaLM8uSe7VFmOTQ=; b=YvDS2cFdckKblwvTO/Di7+u2/nL3T/SCOsrWN+8n4aHu1jdVABZUEuGuu9DPxFCTmN G8imDLgSyYaliLHGZEA8fiGsaTbV8o1cGsP9kHbfN6hMwvMiSs825sE3wBKJDpxKfNqw MPTO+ZRdWFxvfJ7ccfjpopU3E7ZBRcyU/cure+zZ59OMj5cl2IhmNHb4LYtrtoSzsyMx 7AXln5ysmF4v1b6azDmjFY4ZxnLS63AbsbHuB7KyvIzfI+PNUmODmgmA+7W2VZsllTG3 aCPv0smop/g0oIQudjXCwzuOgKFRyNZ0syBPdmKai2a3nRt0MqOAaYS7BviVUKdtCVRF g4zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=df5hNmTxzd0Y40J28Qi6dKkwe3TrhaLM8uSe7VFmOTQ=; b=IQdQpZ+tB/le1Mbir97onT64JiNd6NzJTjUKmq7orDT27giS5nCqo341xi7jGoBSB3 w/kMT5SIqbv8R05/KRW+CeAhReVmBo5q2SM4Sm17ne1ePvcCTnV6gs6HtIfca3t4N8Nw Vcqzs6aHTbKe3LrhKUDeg4txd5/eeVKd9aLYFA2/ddWoTFlN2LObsXdj9rThdnSY2Tga KvhaVpy2YbYE15x0QnVf5otrXmlWiZRcmEPD2xzvyOVDpg5pgP85o8itjmI8Wn2GoQBA kUZIHCZdLZcBodNMA5jkLK7cYEmKM66LC+iXXYQBjuHZnl/TFIMGxQ6MeGdk1No7ujTi EofA==
X-Gm-Message-State: AIVw112xbJ6d0Hzngp11vidGSPqPP0CKgoaYAgYgudpFI9YmdUMRa6Of Lvt6WhYspIhBcx1HCEMVtVQISo4Kxsnr
X-Received: by 10.37.220.74 with SMTP id y71mr3987316ybe.220.1500570493968; Thu, 20 Jul 2017 10:08:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Thu, 20 Jul 2017 10:08:12 -0700 (PDT)
In-Reply-To: <09123555-1e27-c6e7-9e3a-fd87df868991@cs.tcd.ie>
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>          <09123555-1e27-c6e7-9e3a-fd87df868991@cs.tcd.ie>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 20 Jul 2017 10:08:12 -0700
Message-ID: 
To: Stephen Farrell 
Cc: "Salz, Rich" , "" 
Content-Type: multipart/alternative; boundary="94eb2c18f32841037a0554c2cb47"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 17:08:16 -0000

--94eb2c18f32841037a0554c2cb47
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell 
wrote:

> On 20/07/17 17:43, Colm MacC=C3=A1rthaigh wrote:
> > that's the term that people keep applying,
>
> That term was appropriate for draft-green as justified in [1]
> That's disputed by some folks but it's the correct term.
>

If you maintain that draft-green is Wiretapping, then that is also the
correct term for what is happening today. Today, operators are using a
static key, used on the endpoints they control, to decrypt traffic
passively. The only difference is DH vs RSA, and I know you'll agree that's
not material.

Claiming that current browsers "support" wiretapping is plain
> odd to me and not that useful for the discussion but isn't a
> TLS protocol issue as we don't currently have, and don't have
> a WG proposal for a draft-green like wiretapping API as part
> of the TLS WG set of RFCs.
>

It is odd ... and I'm being deliberately provocative to get at the
doublethink. It is impossible to consider this mode wiretapping and not
claim the browsers support it today. Plainly, they do.

We don't live in an abstract theoretical world in which this is not already
happening, and is not already possible. It will also continue to be
possible to MITM traffic, if you have the RSA key, and some dh-static
opponents even advocate for this. I have seen no intellectually consistent
explanation for why that is ok, why that won't be abused by coercive
authorities, and hence why it is not better to have something in between;
that gives providers what they claim to need, but not the coercers.

--=20
Colm

--94eb2c18f32841037a0554c2cb47
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell <=
stephen.farr=
ell@cs.tcd.ie> wrote:
    On 20/07/17 17:43, Colm MacC=C3=A1rthaigh wrote:
    
> that's the term that people keep applying,
    

    
That term was appropriate for draft-green as justified in [1]
    
That's disputed by some folks but it's the correct term.

    If you maintain that draft-green is Wiretapping, =
then that is also the correct term for what is happening today. Today, oper=
ators are using a static key, used on the endpoints they control, to decryp=
t traffic passively. The only difference is DH vs RSA, and I know you'l=
l agree that's not material.=C2=A0

    
Claiming that current browsers "support" wiretapping is plain
    
odd to me and not that useful for the discussion but isn't a
    
TLS protocol issue as we don't currently have, and don't have
    
a WG proposal for a draft-green like wiretapping API as part
    
of the TLS WG set of RFCs.

    It is odd ..=
. and I'm being deliberately provocative to get at the doublethink. It =
is impossible to consider this mode wiretapping and not claim the browsers =
support it today. Plainly, they do.

    We don't l=
ive in an abstract theoretical world in which this is not already happening=
, and is not already possible. It will also continue to be possible to MITM=
 traffic, if you have the RSA key, and some dh-static opponents even advoca=
te for this. I have seen no intellectually consistent explanation for why t=
hat is ok, why that won't be abused by coercive authorities, and hence =
why it is not better to have something in between; that gives providers wha=
t they claim to need, but not the coercers.=C2=A0

    -- 
    C=
olm
    

    

--94eb2c18f32841037a0554c2cb47--


From nobody Thu Jul 20 10:11:03 2017
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 7E551131AA9 for ; Thu, 20 Jul 2017 10:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 CD3-BXQxZReh for ; Thu, 20 Jul 2017 10:11:00 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 EBD9613192B for ; Thu, 20 Jul 2017 10:10:59 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6KH6nUW026615; Thu, 20 Jul 2017 18:10:54 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=jrOEDYCDq3wEYtb0c8rDQ7WTOaLRwYzDJy7/Px9cgJ4=; b=UDWo6vSeSpau7BwIm1q4/Xs7VaU/KnTv9OV/QTQZ+VKt8bV2B7wLRKNGNyErrAO64jt2 dUukuN785iKayzaOgSbdziQh+tQsw5eVHi3IwO/MHAW/0RlwdwqtbAg1WX8/hXTeRPVb C3UvPt3Uk9Hlo1IDTiGDmFAqY/kzjwo+ZfGcM3B8lI0hRandA7mKDzFCCxutorhi92At 7ZcKeWv/RmJuhQrBtN2tbDoRRCGOws27KaijdjjoMHNIndaEFmS2PC/3IPQrM0dNUH3l Rk8rXjlmlF0t+8JkKir6//4fEC1Z0BiyDEXLmrRKo9DvO9t85EfvBFItB3o4ZwN/6pV1 ww== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2btsmmswph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 18:10:53 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6KHAdNk009657; Thu, 20 Jul 2017 13:10:53 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecuh02d-1; Thu, 20 Jul 2017 13:10:53 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id DEA851FFA2; Thu, 20 Jul 2017 17:10:52 +0000 (GMT)
To: Matt Caswell , "tls@ietf.org" 
References: 
From: Benjamin Kaduk 
Message-ID: 
Date: Thu, 20 Jul 2017 12:10:52 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C0D24F4283895A6B9EECA0BA"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707200264
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707200262
Archived-At: 
Subject: Re: [TLS] SNI with early data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 17:11:01 -0000

This is a multi-part message in MIME format.
--------------C0D24F4283895A6B9EECA0BA
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/20/2017 04:51 AM, Matt Caswell wrote:
> I note in draft-21 the following text:
>
>    When clients use a PSK obtained externally to send early data, then
>    the following additional information MUST be provisioned to both
>    parties:
>
>    -  The TLS version number for use with this PSK
>
>    -  The cipher suite for use with this PSK
>
>    -  The Application-Layer Protocol Negotiation (ALPN) protocol
>       [RFC7301], if any is to be used
>
>    -  The Server Name Indication (SNI), if any is to be used

These are in addition to the hash algorithm provisioned with the
external psk that is needed for 1-RTT operation, as mentioned somewhat
in passing in section 4.2.10

> Later it says this:
>
>    In order to accept early data, the server MUST have accepted a PSK
>    cipher suite and selected the first key offered in the client's
>    "pre_shared_key" extension.  In addition, it MUST verify that the
>    following values are consistent with those negotiated in the
>    connection during which the ticket was established.
>
>    -  The TLS version number and cipher suite.
>
>    -  The selected ALPN [RFC7301] protocol, if any.
>
>
> The language about "during which the ticket was established" seems to
> suggest that the following checks do not apply to an external PSK -
> which I don't think is intended. Additionally there does not seem to

These values are a subset of those listed above.  I believe this block
of text only applies to NST-provisioned PSKs being used for early data,
as the previous text applies to external PSKs being used for early
data.  So, since the previous list is a superset, there is no problem
caused by this text not applying to external PSKs.

> be a requirement on the server to check that the SNI is consistent.
> So, there is a mandatory requirement for an external PSK to specify
> the SNI, but no requirement on the server to check that it is actually
> correct. Is this discrepancy intentional?
>

I'm not sure I fully understand what you are saying.
The text says that (for external PSKs) the SNI must be provisioned to
both parties, which to me implies that the server must only use the
given PSK for early data with the specified SNI.  (That is, that the
server has to check.)

For tickets, the requirement that SNI must match the original connection
is mentioned in section 4.6.1 (NewSessionTicket).

In short ... I don't see any problems here.  Do you still see a problem?

-Ben


--------------C0D24F4283895A6B9EECA0BA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 07/20/2017 04:51 AM, Matt Caswell wrote:
    
    
    
      
    I note in draft-21 the following text:

   When clients use a PSK obtained externally to send early data, then
   the following additional information MUST be provisioned to both
   parties:

   -  The TLS version number for use with this PSK

   -  The cipher suite for use with this PSK

   -  The Application-Layer Protocol Negotiation (ALPN) protocol
      [RFC7301], if any is to be used

   -  The Server Name Indication (SNI), if any is to be used

    
    
    
    
    
    These are in addition to the hash algorithm provisioned with the
    external psk that is needed for 1-RTT operation, as mentioned
    somewhat in passing in section 4.2.10
    
    
    
    
    
      
    Later it says this:

   In order to accept early data, the server MUST have accepted a PSK
   cipher suite and selected the first key offered in the client's
   "pre_shared_key" extension.  In addition, it MUST verify that the
   following values are consistent with those negotiated in the
   connection during which the ticket was established.

   -  The TLS version number and cipher suite.

   -  The selected ALPN [RFC7301] protocol, if any.


The language about "during which the ticket was established" seems to
suggest that the following checks do not apply to an external PSK -
which I don't think is intended. Additionally there does not seem to
    
    
    
    
    
    These values are a subset of those listed above.  I believe this
    block of text only applies to NST-provisioned PSKs being used for
    early data, as the previous text applies to external PSKs being used
    for early data.  So, since the previous list is a superset, there is
    no problem caused by this text not applying to external PSKs.
    
    
    
    
    
      
    be a requirement on the server to check that the SNI is consistent.
So, there is a mandatory requirement for an external PSK to specify
the SNI, but no requirement on the server to check that it is actually
correct. Is this discrepancy intentional?


    
    
    
    
    
    I'm not sure I fully understand what you are saying.
    
    The text says that (for external PSKs) the SNI must be provisioned
    to both parties, which to me implies that the server must only use
    the given PSK for early data with the specified SNI.  (That is, that
    the server has to check.)
    
    
    
    For tickets, the requirement that SNI must match the original
    connection is mentioned in section 4.6.1 (NewSessionTicket).
    
    
    
    In short ... I don't see any problems here.  Do you still see a
    problem?
    
    
    
    -Ben
    
    
    
  


--------------C0D24F4283895A6B9EECA0BA--


From nobody Thu Jul 20 10:21:53 2017
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 E8A3B12700F for ; Thu, 20 Jul 2017 10:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3yG4nijN4RA for ; Thu, 20 Jul 2017 10:21:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6351131D0A for ; Thu, 20 Jul 2017 10:21:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CC927BE39; Thu, 20 Jul 2017 18:21:46 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSHaDvT_Mcfm; Thu, 20 Jul 2017 18:21:45 +0100 (IST)
Received: from [31.133.148.54] (dhcp-9436.meeting.ietf.org [31.133.148.54]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 34F9BBE38; Thu, 20 Jul 2017 18:21:45 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500571305; bh=QtJpE9HrmhmSF/Mqi6tlzjJ8zR/KSP4RQsr/r18hmCM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UGbjNsm75IWSVlmgWOV0G8IealFp4Fc19jZgZAiLpwCrzMQbaf/UMJZTaGV+yHqiE fyDNh7ylNXWf+Pcl1cHhQPnJhVWhw6ajT7YKg75JYbBmG9epP3DjAbLhSEowUZiSmZ ZQs9H93IIFUhxO0mhdeX7F+l1lEn2gTJ2Cdu6iJY=
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= 
Cc: "Salz, Rich" , "" 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>          <09123555-1e27-c6e7-9e3a-fd87df868991@cs.tcd.ie> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Thu, 20 Jul 2017 18:21:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mLgEUiT42qx0vPQnNIj8DISPFM6hoXq0L"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 17:21:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mLgEUiT42qx0vPQnNIj8DISPFM6hoXq0L
Content-Type: multipart/mixed; boundary="2DgXHtd5vTO4d51MhU9QhoDm47DQH4LrB";
 protected-headers="v1"
From: Stephen Farrell 
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= 
Cc: "Salz, Rich" , "" 
Message-ID: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com>
 <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie>
 <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com>
 <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>
 
 
 
 
 
 
 
 
 
 <09123555-1e27-c6e7-9e3a-fd87df868991@cs.tcd.ie>
 
In-Reply-To: 

--2DgXHtd5vTO4d51MhU9QhoDm47DQH4LrB
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 20/07/17 18:08, Colm MacC=C3=A1rthaigh wrote:
> On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell 
> wrote:
>=20
>> On 20/07/17 17:43, Colm MacC=C3=A1rthaigh wrote:
>>> that's the term that people keep applying,
>>
>> That term was appropriate for draft-green as justified in [1]
>> That's disputed by some folks but it's the correct term.
>>
>=20
> If you maintain that draft-green is Wiretapping, then that is also the
> correct term for what is happening today. Today, operators are using a
> static key, used on the endpoints they control, to decrypt traffic
> passively. The only difference is DH vs RSA, and I know you'll agree th=
at's
> not material.
>=20
> Claiming that current browsers "support" wiretapping is plain
>> odd to me and not that useful for the discussion but isn't a
>> TLS protocol issue as we don't currently have, and don't have
>> a WG proposal for a draft-green like wiretapping API as part
>> of the TLS WG set of RFCs.
>>
>=20
> It is odd ... and I'm being deliberately provocative to get at the
> doublethink. It is impossible to consider this mode wiretapping and not=

> claim the browsers support it today. Plainly, they do.

In what sense does a browser "support" a server leaking a private
key via some proprietary interface? That makes zero sense to me
and seems sheer hyperbole, as you said yourself. And not useful.

>=20
> We don't live in an abstract theoretical world in which this is not alr=
eady

More hyperbole is less useful.

> happening, and is not already possible.=20

When using crypto in a network protocol, it is impossible to know
or not know that a peer is implementing crypto well or badly.

> It will also continue to be
> possible to MITM traffic, if you have the RSA key, and some dh-static
> opponents even advocate for this. I have seen no intellectually consist=
ent
> explanation for why that is ok,=20

I never said it was "ok." I said it wasn't part of the TLS RFCs.

The point here is to not specify mechanisms that enable wiretapping
to the extent that is feasible (you seem to assume that all uses
of crypto "support" wiretapping, since it's always possible for an
implementation to leak keys - that's gibberish IMO, but I'm using
the term in your sense in this paragraph).

> why that won't be abused by coercive
> authorities,=20

It could be. It'd still be abuse IMO.

> and hence why it is not better to have something in between;

"something in between" is just nonsense sorry. Your strawman
proposition that we define all crypto as "supporting" wiretapping
being nonsense, means that so is that bogus pseudo-compromise.

But given that this aspect isn't really useful discussion, I
hope we can leave it there.

Cheers,
S.


> that gives providers what they claim to need, but not the coercers.


>=20


--2DgXHtd5vTO4d51MhU9QhoDm47DQH4LrB--

--mLgEUiT42qx0vPQnNIj8DISPFM6hoXq0L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZcOaoAAoJEC88hzaAX42ihoEH/A5V75Mul6H3VRlv/yDKhXiY
ssGd3ExRLKbChInsrubBCyfAP1c6g/uNA6XH90Kf3pnMNxPLnHvvBxm4BRDbGZ6Y
b+3UcRn8ebMAeFLtV3CUNBMsrOOT/LihSxD3WpG7scAdzfrCA/Dz5dS4VUu9rMM1
y8xlUc0Tw7goDBVgiqt1CN5FB1kHb5+lyyfOHA8IF50pf6/VPN9v5Skwr1iLoyUS
YbLFOX15EgtKWKCp7/zOVAyaB88AdHe4dOtAjPPtF8xMFqyfrw1GOyBNWXuDydS0
82gCdoYXfS4w+IW0uYCtmGTStIpX1T5GA7rbqTMK7E5SxtYPkfmcasvdZgyCrJ0=
=y3DF
-----END PGP SIGNATURE-----

--mLgEUiT42qx0vPQnNIj8DISPFM6hoXq0L--


From nobody Thu Jul 20 11:39:55 2017
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 091DE131B7F for ; Thu, 20 Jul 2017 11:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 ONjEpkJNC_AD for ; Thu, 20 Jul 2017 11:39:51 -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 E99BB131B67 for ; Thu, 20 Jul 2017 11:39:50 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id x125so16498378ywa.0 for ; Thu, 20 Jul 2017 11:39:50 -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=FFi/PHQ0jIfYTaQSgcL42lWqk23G8AFQ71MBXaYg7BE=; b=gAagYl5t12NPsn3D+Z8pEpAWoRSZotVoC5LdsBR+N0Qqh2f5m9oCWzYixn94gIILjw 6EDZawwWKPXLNhMDe/JLIkQKB8JPl+z+Qz6cs8BjVQBsFxvKuuOVq3Uha6aI/lgaR8h+ vRY0D9IaEuLQIjbYtFcCzHD0ey3KzP23MyVhuvmzjIfKGFTQrwOMpBj6+IHPvlc5xl+z AfU1entKvEXjo0x7gfMxrjCV80G1MWQoWcCVMXZw4aw/qAS//uUfxSTN9ghhV3o6/1ad rPSxsficdg2OmI8n6LklLPuHfNMqqSFSI6dVtzrySEeQk9pXPwKqTqOeOhX+isw+I8Q1 Sp0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FFi/PHQ0jIfYTaQSgcL42lWqk23G8AFQ71MBXaYg7BE=; b=Xhc+EIGPQX12h5tkdTIvMrDiNsYHOeTkNJpdu3SphlkrqMwU4OWgxMeUZODrV0ThcH ZPtvKaHpo502yZJaJ79FcCoXSP3VrLFj+VWA/d8jmGI0Y2AcDxq6BkNHRABkiaKec5xj zrpMGdxlayq/YgIk1LSg/H/ilGRvNXQcpB0C1ieVBm22VDkI2wKxM2k+UxPmHDumz2ME c+VbW2KJwvPxkr9vokOeZEzpqZVsmAhbUv6/B8iwOL4tayHQGfH3rptflBxF1/xU4sIf o0mFv5VijBZNPBJEdIqAApdAWZ/M7dc0EjKh0Ss3aCM2vd+zuqc8b8N7yFf3JEcfX64T RniA==
X-Gm-Message-State: AIVw1135trQAH+TJQo/CUHjic9y9eUkgnOVmwZTi3Ov9wJgw5X1Ct0Lo FywfFWnXN2JVjFhmeevGQx3otpUwJnWu
X-Received: by 10.129.69.7 with SMTP id s7mr3925377ywa.104.1500575990186; Thu, 20 Jul 2017 11:39:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Thu, 20 Jul 2017 11:39:49 -0700 (PDT)
In-Reply-To: 
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie>          <09123555-1e27-c6e7-9e3a-fd87df868991@cs.tcd.ie>  
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 20 Jul 2017 11:39:49 -0700
Message-ID: 
To: Stephen Farrell 
Cc: "Salz, Rich" , "" 
Content-Type: multipart/alternative; boundary="f403045f355cdab2eb0554c41201"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 18:39:53 -0000

--f403045f355cdab2eb0554c41201
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 20, 2017 at 10:21 AM, Stephen Farrell  wrote:

> >
> > It is odd ... and I'm being deliberately provocative to get at the
> > doublethink. It is impossible to consider this mode wiretapping and not
> > claim the browsers support it today. Plainly, they do.
>
> In what sense does a browser "support" a server leaking a private
> key via some proprietary interface? That makes zero sense to me
> and seems sheer hyperbole, as you said yourself. And not useful.
>

I think it's most useful to focus on the real world, and what works and
doesn't work in the real world, and the implications for user security,
again in the real world.  I don't think it's useful to engage in
disconnected arguments and debate that lack that focus.

In the real world, the kind of wiretapping you are talking about works
today, people are using it, so plainly it is supported. Let's stay grounded
in that reality.

> happening, and is not already possible.
>
> When using crypto in a network protocol, it is impossible to know
> or not know that a peer is implementing crypto well or badly.
>

It absolutely is possible to know that a peer is implementing crypto badly;
for example if they use RC4, or have static DH parameters, those can be
detected. I can't fathom why those concerned with the problems of static-DH
are not advocating for dynamic-DH as a requirement. At a minimum that seems
like the most concrete real-world action that will prevent it. If nothing
is done, then static-DH remains possible.


> > It will also continue to be
> > possible to MITM traffic, if you have the RSA key, and some dh-static
> > opponents even advocate for this. I have seen no intellectually
> consistent
> > explanation for why that is ok,
>
> I never said it was "ok." I said it wasn't part of the TLS RFCs.
>
> The point here is to not specify mechanisms that enable wiretapping
> to the extent that is feasible


Two observations:

1. as static-DH  makes plain, TLS1.3 continues to enable this kind of
wiretapping. Are you proposing a modification? Do you then agree with my
suggestion that static-DH be actively forbidden and that clients can reject
duplicate DH params?

2. My concern is to specify things that will improve real-world security.
This should always be our goal.

(you seem to assume that all uses
> of crypto "support" wiretapping, since it's always possible for an
> implementation to leak keys - that's gibberish IMO, but I'm using
> the term in your sense in this paragraph).


That's not gibberish and it's a really really important point. It *is*
always possible to leak keys, or plaintext. We can't ignore that. That's
part of the security model. Our task is then to make it as unlikely as
possible and to accommodate the needs of users in ways that discourage it.

> why that won't be abused by coercive
> > authorities,
>
> It could be. It'd still be abuse IMO.
>

I think it's a lot less likely that signaled, opt-in, infrastructure would
be used by coercive authorities. It works ok in the corporate cases, where
they control both ends, but  for the coercers, they couldn't just show up
and say "Use a static DH and give us the key" to anyone. Instead they'd
have to say "enable this option that browsers don't enable by default".
This doesn't seem realistic.

-- 
Colm

--f403045f355cdab2eb0554c41201
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On Thu, Jul 20, 2017 at 10:21 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
    
>
    
> It is odd ... and I'm being deliberately provocative to get at the=

    
> doublethink. It is impossible to consider this mode wiretapping and no=
t
    
> claim the browsers support it today. Plainly, they do.
    

    
    In what sense does a browser "support" a server leaking a =
private
    
key via some proprietary interface? That makes zero sense to me
    
and seems sheer hyperbole, as you said yourself. And not useful.

    I think it's most useful to focus on the real=
 world, and what works and doesn't work in the real world, and the impl=
ications for user security, again in the real world.=C2=A0 I don't thin=
k it's useful to engage in disconnected arguments and debate that lack =
that focus.
    =C2=A0
    In the real world, the kind of wiret=
apping you are talking about works today, people are using it, so plainly i=
t is supported. Let's stay grounded in that reality.=C2=A0
    
> happening, and is not already possible.
    

    
    When using crypto in a network protocol, it is impossible to know
or not know that a peer is implementing crypto well or badly.

    It absolutely is possible to know that a peer is imp=
lementing crypto badly; for example if they use RC4, or have static DH para=
meters, those can be detected. I can't fathom why those concerned with =
the problems of static-DH are not advocating for dynamic-DH as a requiremen=
t. At a minimum that seems like the most concrete real-world action that wi=
ll prevent it. If nothing is done, then static-DH remains possible.=C2=A0
    =C2=A0
    
> It will also continue to be
    
> possible to MITM traffic, if you have the RSA key, and some dh-static<=
br>
> opponents even advocate for this. I have seen no intellectually consis=
tent
    
> explanation for why that is ok,
    

    
    I never said it was "ok." I said it wasn't part of the=
 TLS RFCs.
    

    
The point here is to not specify mechanisms that enable wiretapping
    
to the extent that is feasible

    Two observat=
ions:=C2=A0

    1. as static-DH =C2=A0makes plain, TLS=
1.3 continues to enable this kind of wiretapping. Are you proposing a modif=
ication? Do you then agree with my suggestion that static-DH be actively fo=
rbidden and that clients can reject duplicate DH params?=C2=A0
    2. My concern is to specify things that will improve real-worl=
d security. This should always be our goal. =C2=A0

     (you seem to assume that all uses
    
of crypto "support" wiretapping, since it's always possible f=
or an
    
implementation to leak keys - that's gibberish IMO, but I'm using
the term in your sense in this paragraph).

    =
That's not gibberish and it's a really really important point. It *=
is* always possible to leak keys, or plaintext. We can't ignore that. T=
hat's part of the security model. Our task is then to make it as unlike=
ly as possible and to accommodate the needs of users in ways that discourag=
e it.=C2=A0

    
> why that won't be abused by coercive
    
> authorities,
    

    
    It could be. It'd still be abuse IMO.

    <=
/div>
    I think it's a lot less likely that signaled, opt-in, infrast=
ructure would be used by coercive authorities. It works ok in the corporate=
 cases, where they control both ends, but =C2=A0for the coercers, they coul=
dn't just show up and say "Use a static DH and give us the key&quo=
t; to anyone. Instead they'd have to say "enable this option that =
browsers don't enable by default".=C2=A0 This doesn't seem rea=
listic.=C2=A0
    =C2=A0
    -- 
    Colm
    

    

--f403045f355cdab2eb0554c41201--


From nobody Thu Jul 20 12:21:17 2017
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 02417131B76 for ; Thu, 20 Jul 2017 12:21:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cem.me
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hrqPj41B4rr for ; Thu, 20 Jul 2017 12:21:14 -0700 (PDT)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 BE999131B9D for ; Thu, 20 Jul 2017 12:21:14 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id w45so30521184uac.5 for ; Thu, 20 Jul 2017 12:21:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OvBtcSsT9LXQ9zopLK5KTY3zFdqfECNmimAgFDGXMP0=; b=cPG9rAZvQtxr9LVXYccfgRTLK1yR1QgWDdZ6mlIfORn2Dvbk195BGB6iEIuX5/Nfuz Pq7I/51GE0zewJQrp0T23Bq0IK5zuFjubxjkXsbMCS++moRNmeQNWkTl0tKMf3hCQlgh jfUb/6KCtwiWyfk8se5RgkPpRw0dVB/bZU7M0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OvBtcSsT9LXQ9zopLK5KTY3zFdqfECNmimAgFDGXMP0=; b=TcphJWjvXLNzVn891P2GZc626nbsOojQsVmtUe7KAT6eKSnJupjnfFrpvEWe5WHbBC iYmicDXhO+EF2OuQDhvayHMGjNKJ7Ue/asbj9mBLpgLdf4THhguoCk2HcDtek3/JenT3 dhqS73vfSLz9Q8pkQHB8lkWIWa7bMSLO3OXwJgiirYx/7Udoov7toPQm35Lh7uxQCQ/S kctTvDlxHc3YTvyDeRbvYXBCw8tcyRKN4N0dlQwycgLnjvtFc2vOBayUwAOKdafdpkI9 OdNOhsiUfm2GEohhqzHnJlzAmpQdetQkVp9UJuyda9NOSHqsUUL1Z1EbAr4Id4MktVdn 9NOA==
X-Gm-Message-State: AIVw111lfDcWhDOpQjQ9QYAHVSUCT1qf+7X+M8ivZVKoYSmhW02dJcJi TzW+etmv9DRtC0hN8gn4MRb9//UpzPV0sqr6WQ==
X-Received: by 10.159.48.8 with SMTP id h8mr2676585uab.196.1500578473686; Thu, 20 Jul 2017 12:21:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.37.174 with HTTP; Thu, 20 Jul 2017 12:21:12 -0700 (PDT)
X-Originating-IP: [2600:1700:1100:a6a0::41]
In-Reply-To: <8d485710-d55e-28b9-3197-ad2d9880f5eb@a-oben.org>
References:    <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net>  <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>  <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie>  <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com>    <8d485710-d55e-28b9-3197-ad2d9880f5eb@a-oben.org>
From: Carl Mehner 
Date: Thu, 20 Jul 2017 14:21:12 -0500
Message-ID: 
To: Simon Friedberger 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 19:21:16 -0000

On Thu, Jul 20, 2017 at 10:38 AM, Simon Friedberger
 wrote:
> I would like to point out that a lot of this discussion seems to hinge
> on the following argument:
>
>
> On 17/07/17 13:04, Roland Dobbins wrote:
>> On 16 Jul 2017, at 11:14, Salz, Rich wrote:
>>
>>> I really want to hear an answer to that question from folks who say
>>> they need TLS 1.3 but without it.
>>
>> Being able to continue to utilize vetted, well-understood,
>> standards-based cryptography on intranets once regulatory bodies such
>> as PCI/DSS mandate TLS 1.3 or above - which will happen, at some point
>> in the not-too-distant future.
>
> So the only reason not to use TLS 1.2 for these use cases is that it is
> assumed that some regulator will in the future prohibit not using it.
>
> (I don't think TLS 1.2 is going away any time soon so it will continue
> to be vetted, well-understood and standards-based.)
>
> I think it is up to those regulators to do their job properly and not
> require TLS 1.3 for situations when it does not fullfil the requirements.
> Or conversely if regulators still require TLS 1.3 although it does not
> support the desired traffic inspection maybe they have made that
> decision with good reason.

I think using TLS 1.2 and waiting will only work up to a point. When
the regulators do require TLS 1.3 (and that may be years and years
away), enterprises still need somewhere to go in order to use things
like IDS and IPS, to look into where application issues are happening,
and all the other reasons that are laid out for needing this draft.

What's unclear is: Are these organizations willing to take their
current networking and application designs and begin to slowly rework
it to support a TLS 1.3-only (real-ephemeral-keys-only) style
architecture by the time it is required?
I can say from my enterprise perspective, enterprises have been
working toward that goal since it was announced that RSA key exchange
was going away several years ago. We're working with software vendors
to get the logs that we need from endpoints, making sure that IDS/IPS
vendors that currently break open streams of TLS cipher text using RSA
keys are able to switch over to doing TLS termination (with good
configurations), or use load balancers that can terminate TLS and loop
it up into an IDS/IPS/WAF before sending the plaintext stream off into
a new encrypted direction.

It's not an overnight change, but it is a practical one, and one that
could end up making these complicated applications that "need"
static-key-style decryption work more effectively and efficiently.


From nobody Thu Jul 20 12:51:33 2017
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 3EF98131B9E for ; Thu, 20 Jul 2017 12:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 TWOOUwrx-_Lu for ; Thu, 20 Jul 2017 12:51:29 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0128.outbound.protection.outlook.com [104.47.38.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE36131B8D for ; Thu, 20 Jul 2017 12:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x0cN4qqAzTrvc3/z4xUDKwC1I5mQL3YaFs4OySqln+Y=; b=UBHejRg8oF6dz/zh5G/wD2tTJaZlav9rG3wDdj+PZ0FDgd9c6a6vSBN8XtabyeLWjmm2Ws1plfX4BtBrdcTqWXjArR9k4NWepH1qsNjmpMV5csfdpZNqNULGR/bWs2q2/MDBWyt2GWwqAm0xfWyb5l78vZpM+YIjOhFkOlKX8cY=
Authentication-Results: cem.me; dkim=none (message not signed) header.d=none;cem.me; dmarc=none action=none header.from=arbor.net;
Received: from [172.16.1.3] (88.208.89.131) by DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Thu, 20 Jul 2017 19:51:26 +0000
From: "Roland Dobbins" 
To: "Carl Mehner" 
Cc: "Simon Friedberger" , "tls@ietf.org" 
Date: Thu, 20 Jul 2017 21:51:15 +0200
Message-ID: 
In-Reply-To: 
References:    <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net>  <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>  <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie>  <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com>    <8d485710-d55e-28b9-3197-ad2d9880f5eb@a-oben.org> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [88.208.89.131]
X-ClientProxiedBy: AM5P189CA0018.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:15::31) To DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 30fdde9e-4b60-4b7d-1463-08d4cfa8b5b8
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; 
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 3:pkOB8XJmI0CqVbDXK7BKD9cI73fFMPdngnJ8AKEZh9UaepSkXQBsvmNh/VWYU7zcRYKZBiYcNI7x5kduW+WPvIOBAsGnOu+4n0tAsF/8rC0ttaM330RTZJPsMtEF1Ga+7oBo8FKnoY35fMTwoOyFUKeHC9M29CleKu4JbnJnIDq7/9pOd5C/qrJ37nz+o0rkL4MwwnUNTZBJyiMqqxYXIlD6NJh0mdp6j5cbNF/AaoNnu6RA78YoG5ELxrEWFNAutxxUIsLPw++lwmx7ZEQOXgyoh9Cm4yz+gVsZ3tfENa4APcAAzWZuweq4n8C8rISL/7g9WPYpVRpcH4VMi54q0a6m1HDiKMHQvufWWC/twgxqKAoDm+f2Y2PpnAoszvqw+IvTpA+fQCQH/PAGNxu4Alq+ZXtoaSrdVts72mFhzR3viZrjz57Ub+6DhN7lmQOJx2tlOHf4M36Fv5cPxtGAp8tfzwnCoZAJRRzK88KCNAc6k/jCSnQ2ghMObxHH1AWoMI3IjZp2XS2KSrfvLAT67f9gdZVAmlFp+GJIQVzWQKQNQmYdBAxevfRdr+DvOAZgOlEuL6FhFhJm+x5TMyG+uI8gNvTKw9DXZ4qblC0QSbYIeq1U5cecKmtNMUBA6RzlE76mXzZmONAS5IE6kgTinytkXXP1+oz1lq2cl9hYPqFt6p0JNSolEoSp5dyIX153sALO9tH+sYwXmVztlYio0PK3rVEeio6rzNZEPd0iYw0=
X-MS-TrafficTypeDiagnostic: DM2PR0101MB1037:
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 25:1JyLW4t/KB6mwuPTyuKuj8RrqGCPxicMgKiWzTaS9S1Kup86W5ZBobE1cI+2jGVPm2evkn/LheYXgq1mB05iIQA1ofmzzMOAxTG+PZIDeOIdCtDSl5uW/ySNnYqDCiC/NSQRiLanZRXHDbQGKaeERJiku1KMvbB5S0Oke8LyJuQ8iNgpARHKKSi5WOhoLtpxwi9QvlsodANmtak9RU2VPNNFcoXwcG8yOpiff4BuhI0fNXqDjbnEzdJ9nle1tSgXIiLfiXGtvIsMCuJ0jY7ht3OCSi8sht22Rs7NJioWbbvPE81fBFYrjBkGyGYqsefMLlyU7PpTSE6io/6QWsSsdMKSIfeJbBUtolB7UA/AGf4wXGKL+VygJG2kTszB94wMMmkrH2H7X5x4JTJmuGXNVaj19yRrYenvMn3Fy8RQxOC1XEKV75D9IBl1qkbMd/xObrgbskiMG6ZClxdZn4ohPwoFbB/fO7Rl2SI7EpkgnVjcVxN5+KJKNLH5IqcMVhTivz7InO9FJuxg57wA55cs+w7chBISZbahxMnnz7Uz+9h12HX3GNEqTv3OHyIRHlwDx348OVt3xfjQEiaXA4thTiGp5InCipsGCSCQ7TWVYFm2Jija6IVikpkKqqNqhHADh1/QTWXftma/hknl8IySOb5svZUMmUssjCr2hNlyW/nTmj5fVGEnjNyTNk2xeWX0uTsA3LxxXVTSMxnqLAGlaPELqztp9ZCaFgFdhhXbulFmM2KoGXM9fcC8yZv7ayW0QFpb8lU5fJYdzgUqjoyq784zCPiZJkCKpQ4g+5zzuj0/PndIdl1kDeZTaNwLzq4nNgpEQFQp03hnr8KlAOtel4XcKDHO+tyIi2IoMWD50biDh88XxRTMmLS1FyMGWSnWb8MCcWSnuFORVK2cN54OlV3z2APuOKnL4LnfO8xqK/c=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 31:lpeMXQTwKxOuG9F0CdNgc9uhQhXuHW1UeQxfT6YgN34MyDF21Ed30NiFmBLl2ncw5XTbR/S82xO0kLhKO2pf9eYJ0j5i4C/WufFovK9IuhsegrX8xxQBU8K8NV8/GJlv73YyqkQkd9PwomYT+WX87wQaOkH/zpATCQQGiHBbGHS4R7zUglxIynWx81s56sg5fUI7Nm3QgC4z+E+yEGzkH1Jv2cURKOjiCZc3HrUKpWvZEOB2FVdIqDRh+LNzwHOX58AQb+5X7NqNMHKR4BrigA++Y//WLEEXyCqP9yD8f2BYqRFkDW/T+/hxvkdXC16n1UpAyqkhA/1Z8//H51JOVriEFCUHwDBZSfrDn3pWRB4ABvRZ2IdNDwtpYlX9hMPnHgy7OrfBBKs8zkXrNnYvC0hInJL4eFr/WToLaRiZjnaZf5IH6OiaZ55MVtI77mP5YLsoG98/gxe7fb+Ou2vPxa/GqrmZOdX9DxhzDi3F3we3znoJPMBI40ymS/hYr1DWZ/Gb+z6VDSf8TNRD0UoCb+wcq16PrXMt8ssS8OniFTpz7yJn1cKAzOU4+KAnwTjFfcUULqX1NoULq5TpUBrwBaVlsqlnQFQhNjngsmjkmjRlRbospLlXhz6wQULcdaf3dMjSQIUsaykf87z+6DeUNZ4nkFbUdjPIkaFlXtZraA2hUBy3WU2ISqv3SDLPTtnDPt4l+CIoYEZMpH6OR9IyqQ==
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 20:4csk+uM3u2XfL1XYxdr8L1TfwRdVNTAz53gEtxPogxTVxTa48flBm7B2R4HqCxs6i9LeeZKnyrTA2xYA770++mSBQhfo2z75S6303KFZC6QVZXr3FtYc+rDMdKrkd0cbiR0j4A3GCwys6X08xUpSnNcW5orSQw1eIcHDmc6fe4bYtT8vy4jWmPj2Lf7y4wSP3FsMBG3OxSYNcMeyhkF9Z2/Y4Pc/jT0e3AtXDOt7hVWIsfCgJtAUszg++O0spm3MmB6tGMiXQW4Qsh43olj3op063YBmez4GcyjA879AXGEZEbha06bf+lQ+vKZQimQa6FdFgn6nm4qnupkruwbtN5ZUnGuil4L6Zo5i2StG1axqpbErDC2xx+p2soSR3G4kJsR9lShe8J6vZP8n5vc8mN7hxTmU6TRB7r0ymwn92rPRJqq8Y9aQyBDyELu4PicJpZ1uMRu2g5pawJtfQifI+HID5k5WFm/lfTqpMDwYaE6/zagVNHXBGAmXjBKJAnMC
X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(236129657087228)(247924648384137); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(2017060910075)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 4:JyhKmQwC2lrVhtDoo1ic0vnn/Huu1nnEhhBitHKS?= =?us-ascii?Q?FL2kqABygr8nxn7DBDPuvTa3GbaBW2SSSIlXkMkFhCG+Qa5i1iLNlWW5L4i/?= =?us-ascii?Q?lmxv2IDC6npGbOOZ1UDulpXXEJrM8dMpURCkpJimxjbdSqnhTn2NGtaLSmY3?= =?us-ascii?Q?+qNsIZN/ouo7JFYEtsEdkxuy5XIQrFszpV9w0AF70tTdrtUhSBxxxRlkhPMX?= =?us-ascii?Q?nIpilqgdj7GFptoKpHH34hLAawwcczoLs1l6+khgosSNplLgoZPWvc2n8JBZ?= =?us-ascii?Q?4zm49BRE95Ws6Rj5NDF/f/C1nnLGbAFkeGRXILPQ/dNgDjrZJlPwZU0bW0tg?= =?us-ascii?Q?nuJvua0H0Iqwm/9yylAr6WhHWWWbuZJ0VuNlkCFjp0iO+K9WB0MtvqZgB01L?= =?us-ascii?Q?HuTOnlCRIOR1Rl694lZ8hnITtBUGxbESuWhUewB3LEdyj2aaI17tWaOqDnpR?= =?us-ascii?Q?HlCn6pPxsptzk6PxT7KVhxgeJN8tAgBPl9m2gSnDobm2IU0XaMgSf5gUExRl?= =?us-ascii?Q?VZUY/JfBeeulcEjLGOq/fUsZhm3za03qUbMTfD6XZpHVp2IUrIF+SrNoZd8i?= =?us-ascii?Q?winTSqNh9DuZDWS4Mya4F6zk2lXD9y+D/il3Jga8YZvmTR8FwUTa4hSAP/bP?= =?us-ascii?Q?KoTLHuXTP6RNOQQCz0NxLseoZmDyW/Og+LkaemPW0j4aMOJdtXqzNi0Gi3Sb?= =?us-ascii?Q?i7SRPwpEiXWTzxQdHv5bWGdjaUF7WDd8w36KMeA+2Z9kwu2BiXi06UgxZqeq?= =?us-ascii?Q?lILgi1C22q/D/WIXH0ADxvWZN8pSTV4NA5/6cdAXnIKtCZAKIs/T3jh45V1w?= =?us-ascii?Q?aPQZ8tiihFzyneSsZqxz5Rwu0isMfXjM0JfuYbVkOvi03YB4Hz9RDKR0ZzSZ?= =?us-ascii?Q?IkGhZDFxXSiqdP26xX6vRfLS3P25Gx/KhEoNLz6ma+R8MklY9oDAVMYK9CTa?= =?us-ascii?Q?qkiaTKwUHiGydWevhBsmCTZSJd96FGfbMHW0aXqwO3gIgv0VwS5PK2AtHwQN?= =?us-ascii?Q?2aGgmRQNFNvB2XrbMM9MCoq9lfyLxvIMHytDcDtpCKPdbhwURn9epADoU3QK?= =?us-ascii?Q?r+k+fy6MSv2Hv4eupIMNM9m2GFogU1ZHHTcVh613pAS6c3HhaxALgHE3gr3F?= =?us-ascii?Q?buF6dirY7/T0EOzQP4LVfpe346nfR/2j9FtmBYP99Dd9eZKffWnBXTTqvjPC?= =?us-ascii?Q?YT4SKNjmm8DUNe/dBh7Ywpjku1APPufB1yNiveVfqKfs2IInSAIbmHKmy4c0?= =?us-ascii?Q?8TjRFtVNxGZxXUDxUywASif29jzOU6UemR1Eo/Kj?=
X-Forefront-PRVS: 0374433C81
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39850400002)(39410400002)(39400400002)(39840400002)(39450400003)(24454002)(8676002)(77096006)(229853002)(6116002)(7736002)(6486002)(305945005)(2906002)(82746002)(42186005)(53546010)(53936002)(7350300001)(3846002)(81166006)(110136004)(478600001)(83716003)(86362001)(50226002)(54906002)(6246003)(6916009)(38730400002)(5660300001)(93886004)(230783001)(33656002)(4326008)(66066001)(189998001)(76176999)(25786009)(47776003)(36756003)(6666003)(5003940100001)(50986999)(50466002)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:[172.16.1.3]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 23:97yhBCLJxt03m/OneW2bqZq4gFMHszQQ/804j2w?= =?us-ascii?Q?JDLOjGOPdm9Zl4TXE3tYFoOP7400I7NOAsalZvNJ9CktO7tQHjEiLlSpQhEa?= =?us-ascii?Q?srALwwoeyg9T6ORIOW/PtqMFzi/wHfRAHIzT9MWMYGxQbvDJKpHWcN1aOB30?= =?us-ascii?Q?JakvNIDZainKNGPCJxQAV7n7MTJ7whQ1WJflBw8u2LfF9MdQ2Mc2pRKPpFSo?= =?us-ascii?Q?Pw2JsQzOy/rS1ntV6kacVzi/tt1NSPPQsn3KvF/d78J/fLuko3zPvPwMt8WU?= =?us-ascii?Q?+PXHjKSLki9ea/WGCTMCo750CYHyNrZ0RxP+rH8oRDU3TponulGCxtO4JKNL?= =?us-ascii?Q?lcc9cUlrgs5rchuaX/FeV3TKWLj8yQia58wyhzLUKFDqjUsHQDJpN5sGiGHp?= =?us-ascii?Q?kCif+ne4pePB8Nbo0SDKsv2Jns/FyVK5bQCiJQOzJV2laOP4CV+uZayIDWis?= =?us-ascii?Q?ppXGT2clN5FpX7iCDSc8trO3gEcwmwHIgp/BiNq6GiEVZ0HxTika66WNyGae?= =?us-ascii?Q?eBoCmuoMEx6xiSSrKphYgZrrSOwT8nkfaxOhwBhiQn1CKHdFZyImwgP87gvG?= =?us-ascii?Q?RNEsm/obLVfw4kKlMoOo4Nuv8IoeLHQcQvbtpdCb0PsVLa51FynPwJfG8d0C?= =?us-ascii?Q?I7J1OoNBEw0TdQyf2xOWTL78R4uKwwUhk35uG4JgCezUGLejmNHq1ArXQSQx?= =?us-ascii?Q?iifJLQ+S63UfUIDRAnseyhYuBUhqTJg37XiTofuqzwzybJZINtNdzD76kyhD?= =?us-ascii?Q?9ZWZWHOXqsR7P/gO5FE2Or9ekUt49w+35qL6HxrArHABe/dY7CxSKm3TaBVi?= =?us-ascii?Q?kL1v/kmwPrH44u0XhW5/k58/fT5XV2S17Hk42m8UkA18bsNKUjJlQbVNvK15?= =?us-ascii?Q?yPU3KuTPq1+i1l5WjK6i09oeCatp7/GjfQIfWIH5O3it85rhteTZRIa8frTT?= =?us-ascii?Q?rqUfPKohLbQOFhDOGVV0dw1SsSE2hVY/6T7u2sHjV78aGjVlbCClMjPFCmJc?= =?us-ascii?Q?wvLXOQ+Jk5oJiMXXAqS2mXBwtk7FxlJP9WGvmLRWDQ2AXeAFCynzvBiER9yF?= =?us-ascii?Q?jir+gJ/oqkg0ihPFY0KONev7BO78tbCCCFVzmD38EyWSmsN7AifUJhHmpnyy?= =?us-ascii?Q?bKTdtRlP3ActdChbktWLFzl2IXH8CqpMaGmKHTkYsELNlAEjfavxQ63ioXOE?= =?us-ascii?Q?9tf09Afi9glNdEVARgZXrZ7h+ivzkUe1/ABHcGY3dGaMntNUmzzHyHu8H1aj?= =?us-ascii?Q?TwRaKYl8bjzdaCnsIpLg=3D?=
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 6:qOPrNUBndhqEQuAYf0vvseM4zcL8tv9fVZJvWTSA?= =?us-ascii?Q?XsG8wb8yMTVuxHov5aDOelR893YeiUs2bqAc5B16b/OiWY4nSnVjlCmZuiGy?= =?us-ascii?Q?1geSJnXGZvp7DgpqiwsryEsqNAr7S1SYapquxOBnAAJHs9HFJddJhca+xEBS?= =?us-ascii?Q?YseYK3fIzwu1ntYQsrAC2zG8R7rVUzCiT7CnZS5A7rWewSc/7KNG1c2hndra?= =?us-ascii?Q?1RTzi1VQf0N1+lJPjOFCDrzjhupXB/YjOel5zkTsikGlRwwEK4uLtwBNtdZt?= =?us-ascii?Q?OIDYyeZI6iTJndaQ2mlpVr87TyYkdGr1QVyazpDNgi0mJViL/xaikvXE0BBA?= =?us-ascii?Q?nDCDNz4ekC6fYzWRttYRzlfcayKdebpfPOhzh7PqyxcWk2MOCEXGF/Jpme7h?= =?us-ascii?Q?GqZWL+sK0gydcsg7w3DoYC7ULc91sjOk2zuDc93XabBeFBjLej5wpFuy7i10?= =?us-ascii?Q?kJCmoqADhzWLjqLuttBXVT3ZrqRTDhQNJiC/QPSC5QorLtysXdEbymqNC2NC?= =?us-ascii?Q?DwvMzv9BkLGuCKBeqWSr+aaQNRZixKeh3p2z/lLaNRYdjXYUFvaLXQnsL1NT?= =?us-ascii?Q?Aq4+jynJV1tzcp5JZu3j43woy2XdPbdVyU2eVeMj4TUc2GZs95kh6mHYOg4n?= =?us-ascii?Q?KMmfAGXKDFH4PqkCqAmZ5vLxxD5li5bq7R9PLB9XjQMmXurUrcSF8sdqj35i?= =?us-ascii?Q?B8/xcPNKWdI+or5u904BqFhSfD5QDyyrs4hRfzVG+fymKi4x2DUOtU8Bw/JT?= =?us-ascii?Q?UEBOD/xPtMgtcivYt18wI9c66cpxkAmNP/Bz0CH2Q7Sad29yqV003k/WXLIX?= =?us-ascii?Q?kcVUrCpafZZeTlqvB/5l886RvVoXvosw2kpc7MKkL47pBr0NUdimSLLjCYm6?= =?us-ascii?Q?lN+ew55cSkDo6gyGaxQ67g/CWFk8QM4JXnnp/azhkcxhasPJmxI914oOkSer?= =?us-ascii?Q?Kl0Q7E2eWjz6XtGM5idsHpCXVEj7f+aFx3ADWucO5YFfNGyLcwuuzJVTI2Z2?= =?us-ascii?Q?01o=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 5:ugxCB/hbkroCzjxlSWZSP/x3Z3uWu85m/f5WzSIp3MK0s8XqjP0xfjniQlS8DNbXNuSwv82mhLIZ81AN5k0qlxIUExuNnlPRwIX/iJ7O8lqEarcOJ7RMVJ9nP5ja+fZWLmuYFCsTQ8JkQTUNQU7a7tUB6g9ANzFqLd8kcltz1yD1FG22DgnpKDiDvY7FP/tQIT8TOVoAvcUfGzoxtYO7oMLicP1npoBQpgqIiNJiaodV86gkMocXPtARVXvuAp2Iaoq8wqjHPaJk9/WfrC0b0tWWZLB4w0B7cxIc1fj/ku/0FSzA2pHgZqcwSA6L9T7K6bpWtluXQHeo4+gB7nShzlYL3Nd2GecOfuuLLuawyGJC9gtGHZdcraptc0s37GfZLsjQ4owsbzKuprEsDlrkyEisAn/GZarYyfY585A9X66IYe6LtdivpgUloYbbF2j1WnyrdcWRH86PzJGOvon7twQ+O67IGiDI9CkqM/ayxu1BzBDVUD1I4p+chK75Z05c; 24:RvUPH6yg0ronX5wFYKhX82gTZHGWDluIkwdglyjngKGJtv3xxg9yC9DaWwEak1kKSmkLR/nAPd1vUiZ7pf0hH/IUVarwB5ffXSZd//IOuMY=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 7:sq0IoLYfOzGg1W0BTh3AZ3SF3f7OkaZLc3Mk2jvNnLgjkPhrjEEP4cShEeHV81Cf5Gc8bDyXCDsuDzJ0w+6D0JHYp4REhZ8YEnm061s8m0ZdJME77XvXeRUnJ/uwLebhkI+GR8GzvWM5KKnQFodH4Xq0lxk8mnKSfSkrLEqkG40+dq3RyopzYbhBmr8IBwk4K4vToUk+jY6TQiu7wJYIzgyHAjhXdEN1h7+A1Iw75xyovPPte7PNusZ964RznAys9xmMRf3CHN1t1OEzS7mGitpCzvuYZwswEeqhKNePVRghVj1JG3on/i3rSfG4uwZgAeNsmm604DGSaa92nFcvsqDtgfDhPeyEWDCTps1AAvjLN1pSzY1rhFNSQ6rp1bpilfe2yRYjw4p00fW33oVhdZW1y/SQIvt1lS87Uns9DZSRMDEGYDSGlHmPL1HSBSYgoDxjF0u8UdfbaKe7Eqn3+AfjLKrLOOjkl0OLX49cqHwQO7DLCUReLbL6EWt5/RaqB4kQs0wAns8YT66MjvXpjDvbsdq1xaaFOgHCZisX+xnnFe0StpvIlpY4quYtW+AQDaPpgaOUMzomXQogbuhgJzrtxwFGlqDPaBcjOaKzviFvnVHV5AkWYLVJTpT3fQIC0MXkwymkIDKUr9VYNLhLjSkwDBF3Pok0BVTDULCQTUnp18GmCMy15UlBJyo1X+5qbwKtvJYpIRHx7GhfiE7FNVfM+0hTxKUyr/NAxqbwNWnZf3A22sq0nhib6UuLehQVTONRdbaKX0Ccpd1Rj91dCOkM9s2Nc+m7eQXWVAbqHT4=
X-OriginatorOrg: arbor.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2017 19:51:26.8621 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 19:51:31 -0000

On 20 Jul 2017, at 21:21, Carl Mehner wrote:

> It's not an overnight change, but it is a practical one, and one that 
> could end up making these complicated applications that "need" 
> static-key-style decryption work more effectively and efficiently.

The problems of capex, opex, scale, additional complexity, and 
potentially broadening the attack surface via additional inline 
termination are also considerations - these tradeoffs may work for some 
organizations, but don't for many.

Whether or not one can obtain sufficient application/service 
instrumentation is also highly situationally-specific.

-----------------------------------
Roland Dobbins 


From nobody Thu Jul 20 13:01:20 2017
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 3C1FC129B35 for ; Thu, 20 Jul 2017 13:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 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_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 lD6p9rabo9Ns for ; Thu, 20 Jul 2017 13:01:17 -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 CC5C9131BA8 for ; Thu, 20 Jul 2017 13:01:16 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (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 3xD4XV6Qcqz1JGR; Thu, 20 Jul 2017 22:01:14 +0200 (CEST)
X-purgate-ID: 152705::1500580874-00000861-DCD1006B/0/0
X-purgate-size: 2993
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 mail07.wdf.sap.corp (Postfix) with ESMTP id 3xD4XV566lzGp1F; Thu, 20 Jul 2017 22:01:14 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AA2F91A6CB; Thu, 20 Jul 2017 22:01:14 +0200 (CEST)
In-Reply-To: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 20 Jul 2017 22:01:14 +0200 (CEST)
CC: Stephen Farrell , "" 
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 20:01:19 -0000

Colm MacC=E1rthaigh wrote:
>=20
> If you maintain that draft-green is Wiretapping, then that is also the
> correct term for what is happening today. Today, operators are using a
> static key, used on the endpoints they control, to decrypt traffic
> passively. The only difference is DH vs RSA, and I know you'll agree that=
's
> not material.


What I'm currently seeing in the installed base for getting at the plaintext
of TLS-protected traffic, are these two approaches:

(1) Server-side:  Reverse-proxy

(2) Client-side:  TLS-intercepting proxy

and neither of these needs to break TLS and neither needs to break forward
secrecy of the SSL/TLS-protected(!) communication.


While Server-side reverse proxies (1) _might_ be used to "inspect/monitor"
traffic, more often it seems to be used for scaling / load-balancing
to multiple backend servers of a server farm.  We ship such functionality
for the backend specifically for scaling/load-balancing, and for placing
the SSL termination point into a DMZ (firewalled backend servers).
We a proprietary scheme to forward SSL/TLS client certs from the
reverse proxy to the backend servers.


(2) is often used by so-called "AV-Software" of the "Internet Security"
kind, and studies have shown over and over again just how badly many of
that stuff breaks security (by botching the TLS server certificate
validation and/or server endpoint identification).


I also see (2) being used by some of our customers in the form of
TLS intercepting internet proxies, mostly in countries that lack
constitutional strong privacy protections (US, UK&CommonWealth, middle EAST=
).
It regularly breaks outgoing communication scenarios and confused
application admins, because the fake TLS server certificates will be
rejected by our app client unless the trust in explicitly configured.
Something which IT/networking departments occasionally fail to properly
explain to their colleague application admins.

Whenever outgoing communication requires the use of SSL/TLS client certs,
existing TLS intercepting proxies don't work (and I'm really glad that they
break).  A growing number of legal/governmental data exchange scenarios
use SSL/TLS client certs (something I really appreciate, because the use
of client certs fixes a number of problems).  :-)



Personally, I consider server-side reverse proxies primarily as an
implementation detail of the backend (how workload is distributed
within the backend).

The client-side TLS intercepting proxies, however, are a constant security
problem, and unless it is a ***TRUELY*** voluntary, consenting opt-in,
and running on the same machine as the user, and with the user in full
control on whether and how that intercepting proxy is used.

If presence & use of a TLS intercepting proxy is the result of anything
along the lines of "compliance", "policy" or "conformance", then it is
wire-tapping, with a probability near certainty.


-Martin


From nobody Thu Jul 20 13:15:11 2017
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 A2D4A131B9C for ; Thu, 20 Jul 2017 13:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 xayn6KjTrxMQ for ; Thu, 20 Jul 2017 13:15:06 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id DEB0D131B90 for ; Thu, 20 Jul 2017 13:15:05 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6KKF4op040681 for ; Thu, 20 Jul 2017 16:15:04 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB0GJJTXEJ9Nke26Xc5y2RlZKJbn/KAgAAClACAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB/KoCAAASqgIAACjOAgAAC6wCAAJbcgIAAAy8AgAADmACAADBYAP//wM6A
Date: Thu, 20 Jul 2017 20:15:03 +0000
Message-ID: <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp>
In-Reply-To: <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583412103_2119082059"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707200312
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 20:15:10 -0000

--B_3583412103_2119082059
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Maybe we are better off just retrofitting RSA-key-transport back into TLS-1=
.3? In that case at least the peer could refuse this method of key establish=
ment, and one could safely assume that if a peer insists on that key establi=
shment mechanism, this session will be surveilled?

If I had to choose between the two evils, RSA-key-transport seems a lesser =
one (or at least a more obvious/visible one).
--
Regards,
Uri Blumenthal

On 7/20/17, 16:01, "TLS on behalf of Martin Rex"  wrote:

    Colm MacC=C3=A1rthaigh wrote:
    >=20
    > If you maintain that draft-green is Wiretapping, then that is also th=
e
    > correct term for what is happening today. Today, operators are using =
a
    > static key, used on the endpoints they control, to decrypt traffic
    > passively. The only difference is DH vs RSA, and I know you'll agree =
that's
    > not material.
   =20
   =20
    What I'm currently seeing in the installed base for getting at the plai=
ntext
    of TLS-protected traffic, are these two approaches:
   =20
    (1) Server-side:  Reverse-proxy
   =20
    (2) Client-side:  TLS-intercepting proxy
   =20
    and neither of these needs to break TLS and neither needs to break forw=
ard
    secrecy of the SSL/TLS-protected(!) communication.
   =20
   =20
    While Server-side reverse proxies (1) _might_ be used to "inspect/monit=
or"
    traffic, more often it seems to be used for scaling / load-balancing
    to multiple backend servers of a server farm.  We ship such functionali=
ty
    for the backend specifically for scaling/load-balancing, and for placin=
g
    the SSL termination point into a DMZ (firewalled backend servers).
    We a proprietary scheme to forward SSL/TLS client certs from the
    reverse proxy to the backend servers.
   =20
   =20
    (2) is often used by so-called "AV-Software" of the "Internet Security"
    kind, and studies have shown over and over again just how badly many of
    that stuff breaks security (by botching the TLS server certificate
    validation and/or server endpoint identification).
   =20
   =20
    I also see (2) being used by some of our customers in the form of
    TLS intercepting internet proxies, mostly in countries that lack
    constitutional strong privacy protections (US, UK&CommonWealth, middle =
EAST).
    It regularly breaks outgoing communication scenarios and confused
    application admins, because the fake TLS server certificates will be
    rejected by our app client unless the trust in explicitly configured.
    Something which IT/networking departments occasionally fail to properly
    explain to their colleague application admins.
   =20
    Whenever outgoing communication requires the use of SSL/TLS client cert=
s,
    existing TLS intercepting proxies don't work (and I'm really glad that =
they
    break).  A growing number of legal/governmental data exchange scenarios
    use SSL/TLS client certs (something I really appreciate, because the us=
e
    of client certs fixes a number of problems).  :-)
   =20
   =20
   =20
    Personally, I consider server-side reverse proxies primarily as an
    implementation detail of the backend (how workload is distributed
    within the backend).
   =20
    The client-side TLS intercepting proxies, however, are a constant secur=
ity
    problem, and unless it is a ***TRUELY*** voluntary, consenting opt-in,
    and running on the same machine as the user, and with the user in full
    control on whether and how that intercepting proxy is used.
   =20
    If presence & use of a TLS intercepting proxy is the result of anything
    along the lines of "compliance", "policy" or "conformance", then it is
    wire-tapping, with a probability near certainty.
   =20
   =20
    -Martin
   =20
    _______________________________________________
    TLS mailing list
    TLS@ietf.org
    https://www.ietf.org/mailman/listinfo/tls
   =20

--B_3583412103_2119082059
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU
WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO
DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A
97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN
YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR
COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x
dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01
c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ
KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G
/F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL
e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c
A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgOzYhz6blsdqVvIE3
fJEZvqx0fMIjfXi9u0M1Oj3BQfgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzIwMjAxNTAzWjANBgkqhkiG9w0BAQEFAASCAQABL/1TOkgBWoCSmtG+
YuilV2WIXS7qErev+RiUZxBv/bRq8bUR7LwlyBnljS5pMAYlRwBK0JeBk1DGh5YP7oN0BM3b
P1kIaPCN9EzZ5yE1sbQyR/bVRBT/Da2mRDzeUHCBSzGA2myPqj8YBmD4bT9xrYtxGAV1hfQw
HfLh0iyHjmiyOhOv+eiN5M0wYIfgBCymFlQdTUu7loTuR1xgfCER7jlZGw/8ofh3HhZi3tYA
y4dMHOLF+OTDeZWuWXVzKmxCc0+FfX8baFEnJVZUu79zI1strwMBBLNgnhsRFzq441FVOrDg
Gdhzg65SqSNkFY+0c3Q6kEv9wmxUVOAbff5B

--B_3583412103_2119082059--


From nobody Thu Jul 20 13:32:47 2017
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 A3990131BAC for ; Thu, 20 Jul 2017 13:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 7BQ6nBI3HUwU for ; Thu, 20 Jul 2017 13:32: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 75F86124D68 for ; Thu, 20 Jul 2017 13:32:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id EE5EB39763; Thu, 20 Jul 2017 23:32: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 2Z7zaULtiGUE; Thu, 20 Jul 2017 23:32:40 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 9E0F52313; Thu, 20 Jul 2017 23:32:38 +0300 (EEST)
Date: Thu, 20 Jul 2017 23:32:38 +0300
From: Ilari Liusvaara 
To: "Blumenthal, Uri - 0553 - MITLL" 
Cc: "" 
Message-ID: <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 20:32:46 -0000

On Thu, Jul 20, 2017 at 08:15:03PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> Maybe we are better off just retrofitting RSA-key-transport back
> into TLS-1.3? In that case at least the peer could refuse this
> method of key establishment, and one could safely assume that if a
> peer insists on that key establishment mechanism, this session will
> be surveilled?
> 
> If I had to choose between the two evils, RSA-key-transport seems a
> lesser one (or at least a more obvious/visible one).

This has in fact been requested. Kenny Paterson said about the request:

-----------------------------------------------------------------------
My view concerning your request: no. 

Rationale: We're trying to build a more secure internet.
-----------------------------------------------------------------------

Furthermore, AFAICT, adding RSA key transport would cause major
problems with the way TLS 1.3 does its handshake: It assumes that
whatever the key exchange is, it is two-message client-goes-first,
where static RSA key exchange is two-message server-goes-first (three
messages as client-goes-first).

There is straightforward way to make a valid key exchange out of
RSA. However, the result is very slow for client, and is in fact
forward-secure.


-Ilari


From nobody Thu Jul 20 13:42:15 2017
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 F0A62131B74 for ; Thu, 20 Jul 2017 13:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 RdDtBiNiSnXe for ; Thu, 20 Jul 2017 13:42:12 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3345B1316A1 for ; Thu, 20 Jul 2017 13:42:12 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6KKgBUT007318; Thu, 20 Jul 2017 16:42:11 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Ilari Liusvaara 
CC: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB0GJJTXEJ9Nke26Xc5y2RlZKJbn/KAgAAClACAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB/KoCAAASqgIAACjOAgAAC6wCAAJbcgIAAAy8AgAADmACAADBYAP//wM6AgABH+AD//7+cAA==
Date: Thu, 20 Jul 2017 20:42:10 +0000
Message-ID: <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII>
In-Reply-To: <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583413730_1809210182"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707200317
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 20:42:14 -0000

--B_3583413730_1809210182
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

On 7/20/17, 16:32, "ilariliusvaara@welho.com on behalf of Ilari Liusvaara" =
 wrote:
> Maybe we are better off just retrofitting RSA-key-transport back
    > into TLS-1.3?=20
   =20
    This has in fact been requested. Kenny Paterson said about the request:
     ----------------------------------------------------------------------=
-
    My view concerning your request: no.=20
    Rationale: We're trying to build a more secure internet.

My rationale to resurrect it: others are trying to push TLS-1.3 into an inv=
isibly-insecure state. If we must satisfy them (and I=E2=80=99m not at all sure we=
 should), then this is the most obvious way to at least avoid the =E2=80=9Cinsecur=
ity=E2=80=9D being silently pushed upon you. At the very least you=E2=80=99d have an opt=
ion to continue under surveillance or abort connection.=20


--B_3583413730_1809210182
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU
WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO
DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A
97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN
YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR
COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x
dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01
c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ
KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G
/F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL
e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c
A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgwiGjybxtNLcfYnCT
UNxDMXYYDnznFvqCj5sZ18x1snIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzIwMjA0MjEwWjANBgkqhkiG9w0BAQEFAASCAQAb++k99tdsfrVw5ocS
oxKDLOlP/4Oz1zaBeayGyG8ah94mZWFjEX8USwI3env7qnggryfHynSJALp4NZM3Mo3m+z9h
+Sm1v11Y2okAufZ43cUpAeis5bzvPTTz/Pe+2a4G6pvQHXs+uPyUFMGutoifTgGoermHAuja
N+ggVC3to28XYTWUlloIEnzZOfp6JdcCxpHMdUg5lOgXj1g3pI3N2Rc4d8ztEIfJsetWtEBn
LYRexGtylEInV8hQdVKR3Jcng/li+XZy6LG35CwV7kppUruvTVzYc0S8V896JgMzGhJW0R9+
IJC8RprTaKbTkJYstcbxuS28+wHclNSiiFov

--B_3583413730_1809210182--


From nobody Thu Jul 20 16:14:55 2017
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 83A5C1243F3 for ; Thu, 20 Jul 2017 16:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 MtNjSbiJsHR1 for ; Thu, 20 Jul 2017 16:14:53 -0700 (PDT)
Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (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 D2808127599 for ; Thu, 20 Jul 2017 16:14:52 -0700 (PDT)
Received: from [81.164.186.174] (helo=[192.168.0.233]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1dYKeg-00037A-Q8 for tls@ietf.org; Fri, 21 Jul 2017 01:14:51 +0200
References:  <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net>  <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>  <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie>  <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com>    <8d485710-d55e-28b9-3197-ad2d9880f5eb@a-oben.org> 
To: "tls@ietf.org" 
From: Simon Friedberger 
Message-ID: 
Date: Fri, 21 Jul 2017 01:14:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 20 Jul 2017 23:14:54 -0000

On 20/07/17 21:21, Carl Mehner wrote:
> On Thu, Jul 20, 2017 at 10:38 AM, Simon Friedberger
>  wrote:
> I think using TLS 1.2 and waiting will only work up to a point. When
> the regulators do require TLS 1.3 (and that may be years and years
> away), enterprises still need somewhere to go in order to use things
> like IDS and IPS, to look into where application issues are happening,
> and all the other reasons that are laid out for needing this draft.
I agree up to the last point. As you say later there are alternatives
and of course vendors of IDS solutions are not going to implement any of
the potentially more complicated solutions if they don't have to. But it
is entirely possible.
> What's unclear is: Are these organizations willing to take their
> current networking and application designs and begin to slowly rework
> it to support a TLS 1.3-only (real-ephemeral-keys-only) style
> architecture by the time it is required?
For business reasons they essentially must they that they wont but
should TLS 1.3 be accepted as-is they will either do it or be replaced
by more competitive businesses.
> I can say from my enterprise perspective, enterprises have been
> working toward that goal since it was announced that RSA key exchange
> was going away several years ago. We're working with software vendors
> to get the logs that we need from endpoints, making sure that IDS/IPS
> vendors that currently break open streams of TLS cipher text using RSA
> keys are able to switch over to doing TLS termination (with good
> configurations), or use load balancers that can terminate TLS and loop
> it up into an IDS/IPS/WAF before sending the plaintext stream off into
> a new encrypted direction.
>
> It's not an overnight change, but it is a practical one, and one that
> could end up making these complicated applications that "need"
> static-key-style decryption work more effectively and efficiently.
Yes!


From nobody Fri Jul 21 03:00:47 2017
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 94B5A129AA0 for ; Fri, 21 Jul 2017 03:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.09
X-Spam-Level: 
X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 us6QQ1CWRmQP for ; Fri, 21 Jul 2017 03:00:38 -0700 (PDT)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 63592127869 for ; Fri, 21 Jul 2017 03:00:37 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 57B27C0E98 for ; Fri, 21 Jul 2017 05:00:37 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 9C064C0D5E; Fri, 21 Jul 2017 05:00:36 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 643AFFE054; Fri, 21 Jul 2017 06:00:36 -0400 (EDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2C795FE048; Fri, 21 Jul 2017 06:00:36 -0400 (EDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (unknown [216.32.180.179]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Fri, 21 Jul 2017 06:00:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com;  s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CEde2N2Zf9Og7kLUiehkPB60U+jXQkZ4yo9JFdvsTek=; b=JZDDGNHFx7mTgbVlPk4AxSQ0J4TxWxoxvl96cLaed/34BgtOgixv7KpuDc8XglVqoZep5/vPEWuksb5XlpLsfPmdEaaQ4Gq4eeArlrB/WH74Bc6SWJvcqF4+l75tJb2UYWRYkRSnW/pgLW6ivs56BwHqOlRInIZ0b3jAvre4c6U=
Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Fri, 21 Jul 2017 10:00:34 +0000
Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1261.024; Fri, 21 Jul 2017 10:00:34 +0000
From: "Ackermann, Michael" 
To: Ted Lemon , Tom Ritter 
CC: IETF TLS 
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQHTALIHGHbk6fNWM0K8v0MY8OYdeqJbY6YAgADWGICAAA6rgIAAg1uAgAABQoCAAT7EEA==
Date: Fri, 21 Jul 2017 10:00:34 +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=MAckermann@bcbsm.com; 
x-originating-ip: [2001:67c:1232:144:3022:b590:1454:7e6d]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 20:R1N2VnBfiCMk5JOVew38L1FTzWJtsRD3UO82GnUPegSuboORhsvh0UHgEmqI38AYoljOWu3fyZH6lqEyqiGvPxGzCjrirH6F/vdkcRHvrT5USoKchlW6GpLb5TBOrncv/6LmoXqpvNCjuxVW3q+8ZFuaOzQn1W0nX6jw+g1slQo=
x-ms-office365-filtering-correlation-id: 1946392e-bfad-4811-ba6b-08d4d01f544c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1368; 
x-ms-traffictypediagnostic: CY4PR14MB1368:
x-exchange-antispam-report-test: UriScan:(151999592597050)(158342451672863)(278428928389397)(26388249023172)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1368; 
x-forefront-prvs: 0375972289
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39410400002)(39400400002)(199003)(189002)(377454003)(24454002)(74316002)(53936002)(5660300001)(236005)(38730400002)(6306002)(9686003)(33656002)(54896002)(97736004)(966005)(7696004)(106356001)(86362001)(478600001)(6506006)(101416001)(6436002)(6246003)(105586002)(99286003)(19609705001)(81166006)(8676002)(55016002)(2900100001)(14454004)(80792005)(68736007)(2906002)(606006)(81156014)(76176999)(50986999)(53546010)(54356999)(25786009)(4326008)(72206003)(93886004)(8936002)(189998001)(77096006)(6116002)(7736002)(3660700001)(790700001)(3280700002)(2950100002)(102836003)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR14MB13688CC2BB22F6CC44452615D7A40CY4PR14MB1368namp_"
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 10:00:34.2250 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm02.z120.zixworks.com
X-VPM-GROUP-ID: 3f0c6eab-b2ef-41e2-bcb3-f74ff101b594
X-VPM-MSG-ID: b1217ad9-b2da-45ee-b567-d2c775df1b8b
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 10:00:46 -0000

--_000_CY4PR14MB13688CC2BB22F6CC44452615D7A40CY4PR14MB1368namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGVkDQpZb3UgbWF5IGJlIGF3YXJlIHRoYXQgbW9zdCBlbnRlcnByaXNlcyBoYXZlIGJlZW4g
bWlncmF0aW5nIGF3YXkgZnJvbSAzMjcwIGZvciAyMCB5ZWFycyBvciBtb3JlLiAgVmVyeSBs
aXR0bGUgc3RpbGwgZXhpc3RzLiAgICAgIFdoYXQgbGl0dGxlIGRvZXMgZXhpc3QgaXMgdXN1
YWxseSBpbXBsZW1lbnRlZCB2aWEgdG4zMjcwLiAgIEluIHRoZSBicm93c2VyIHNjZW5hcmlv
IHlvdSBkZXNjcmliZSBJIHdvdWxkIGV4cGVjdCB0aGUgU2VydmVyIHNpZGUgdG8gYmUgYSB0
bjMyNzAgc2VydmVyLCAgYnV0IHlvdSB3aWxsIGhhdmUgdG8gZmlsbCBpbiB0aGUgZGV0YWls
cyBvZiB0aGUgdXNlIGNhc2UgeW91IGFyZSBkZXNjcmliaW5nLCAgdG8gYmUgc3VyZS4NCg0K
SSBob3BlIHRoZSBhYm92ZSBoZWxwcywgIGJ1dCBteSByZWFsIHF1ZXN0aW9uIGlzIHdoeSB3
b3VsZCB0aGlzIGJlIHNwZWNpYWwgb3IgZXZlbiByZWxldmFudCB0byB0aGUgVExTMS4zIGRp
c2N1c3Npb24uDQoNCkF0dGVtcHRpbmcgdG8gYWRkcmVzcyBzcGVjaWZpYyBhcHBsaWNhdGlv
bnMgb3IgaW1wbGVtZW50YXRpb25zIHdvdWxkIHNlZW0gb25seSBhZGQgY29uZnVzaW9uIElN
SE8uDQoNClRoYW5rcw0KDQpNaWtlDQoNCg0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2VudDogVGh1cnNkYXks
IEp1bHkgMjAsIDIwMTcgMTA6NDggQU0NClRvOiBUb20gUml0dGVyIDx0b21Acml0dGVyLnZn
Pg0KQ2M6IElFVEYgVExTIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gSXMg
dGhlcmUgYSB3YXkgZm9yd2FyZCBhZnRlciB0b2RheSdzIGh1bT8NCg0KVGhlIHByb2JsZW0g
aXMgdGhhdCBvbmUgb2YgdGhlIGFwcGxpY2F0aW9ucyBmb3Igd2ViIGJyb3dzZXJzIGlzIGFz
IGEgcmVwbGFjZW1lbnQgZm9yIDMyNzBzICh0aGUgZmlyc3Qgd2ViIGJyb3dzZXIpLiAgIFRo
YXQgdXNlIGNhc2UgaXMgc2FpZCB0byByZXF1aXJlIHRoaXMgZnVuY3Rpb25hbGl0eS4NCg0K
T24gVGh1LCBKdWwgMjAsIDIwMTcgYXQgNDo0MyBQTSwgVG9tIFJpdHRlciA8dG9tQHJpdHRl
ci52ZzxtYWlsdG86dG9tQHJpdHRlci52Zz4+IHdyb3RlOg0KT24gMjAgSnVseSAyMDE3IGF0
IDAxOjUzLCBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eW5pci5pZXRm
QGdtYWlsLmNvbT4+IHdyb3RlOg0KPg0KPiBPbiAyMCBKdWwgMjAxNywgYXQgODowMSwgUnVz
cyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbTxtYWlsdG86aG91c2xleUB2aWdpbHNl
Yy5jb20+PiB3cm90ZToNCj4NCj4gVGVkLCBpZiB3ZSB1c2UgYSBuZXcgZXh0ZW5zaW9uLCB0
aGVuIHRoZSBzZXJ2ZXIgY2Fubm90IGluY2x1ZGUgaXQgdW5sZXNzIHRoZQ0KPiBjbGllbnQg
b2ZmZXJlZCBpdCBmaXJzdC4gIEkgYW0gdGhpbmtpbmcgb2YgYW4gYXBwcm9hY2ggd2hlcmUg
dGhlIHNlcnZlcg0KPiB3b3VsZCBpbmNsdWRlIGluZm9ybWF0aW9uIG5lZWRlZCBieSB0aGUg
ZGVjcnlwdG9yIGluIHRoZSByZXNwb25zZS4gIFNvLCBpZg0KPiB0aGUgY2xpZW50IGRpZCBu
b3Qgb2ZmZXIgdGhlIGV4dGVuc2lvbiwgaXQgd291bGQgYmUgYSBUTFMgcHJvdG9jb2wgdmlv
bGF0aW9uDQo+IGZvciB0aGUgc2VydmVyIHRvIGluY2x1ZGUgaXQuDQo+DQo+DQo+IFNvIHdl
IGFsc28gYWRkIGFuIGFsZXJ0IGNhbGxlZCDigJxrZXktZXhwb3J0LW5lZWRlZOKAnSBpbiBj
YXNlIHRoZSBjbGllbnQgZG9lcw0KPiBub3QgaW5jbHVkZSBpdC4NCj4NCj4gVGhhdCB3YXkg
YSBicm93c2VyIChhcyBhbiBleGFtcGxlKSBjYW4gc2hvdyB0aGUgdXNlciB3aHkgdGhlIGNv
bm5lY3Rpb24gd2FzDQo+IGJyb2tlbiAo4oCcc2VydmVyIHJlcXVpcmVzIHdpcmV0YXBwaW5n
IHRvIGJlIGVuYWJsZWQuIEdvIHRvIGFib3V0OmNvbmZpZyBpZg0KPiB0aGF0IGlzIE9LIGFu
ZCBjaGFuZ2UgdGhlIGFsbG93LXdpcmV0YXAgc2V0dGluZyB0byBUcnVl4oCdKQ0KDQpJIHBy
ZXZpb3VzbHkgZXhwcmVzc2VkIHRoYXQgSSBjb3VsZCBzdXBwb3J0IHRoZSBleHRlbnNpb24g
bWVjaGFuaXNtIC0NCkknbSBzeW1wYXRoZXRpYyB0byByZWd1bGF0b3J5IHJlcXVpcmVtZW50
cyBhbmQgdW5oYXBweSB3aXRoLCBhbHRob3VnaA0KdW5kZXJzdGFuZGluZyBvZiwgd2hhdCBo
YXMgYmVjb21lIHRoZSAnc3RhbmRhcmQgbWVjaGFuaXNtJyAoYnJlYWtpbmcNCmNyeXB0bykg
dG8gYWNoaWV2ZSB0aGVtLiBJJ3ZlIGxvb2tlZCBhdCBtb3JlIHRoYW4gb25lICdlbmQgdG8g
ZW5kJw0KZW5jcnlwdGVkIG1lc3NlbmdlciB0aGF0IHRvc3NlcyBpbiB0aGUgJ3RoaXJkIGVu
ZCcgb2Yga2V5IGVzY3Jvdy4NCg0KQnV0IHRvIHN1Z2dlc3Qgc3VjaCBhIG1lY2hhbmlzbSBt
aWdodCBldmVyIGJlIGltcGxlbWVudGVkIGluIGEgd2ViDQpicm93c2VyIHRocm93cyBteSBo
YWNrbGVzIHVwLiBUaGUgZGlzY3Vzc2lvbiBoYXMgYWx3YXlzIGJlZW4gYWJvdXQNCmRhdGFj
ZW50ZXIgLSB0aGUgcGVvcGxlIGNvbmNlcm5lZCBzYXkgIldlIGRvbid0IHdhbnQgeW91ciBk
YXRhY2VudGVyDQpzdHVmZiBpbiBvdXIgcHJvdG9jb2wgYW5kIHRoZSBwcm9wb25lbnRzIHNh
eSAiTm8gcmVhbGx5LCB3ZSBvbmx5IGNhcmUNCmFib3V0IHRoZSBkYXRhY2VudGVyLiINCg0K
VGhlIGNvbmNlcm5zIGFyb3VuZCBzb21lIGZ1dHVyZSBnb3Zlcm5tZW50LW1hbmRhdGVkIGtl
eSBlc2Nyb3cgaXMgdmVyeQ0KcmVhbCBhbmQgdmVyeSBjb25jZXJuaW5nLg0KDQotdG9tDQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMg
bWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCgoKVGhlIGluZm9ybWF0
aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVu
dGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk
dWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3Ug
YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmll
ZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlv
biBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhl
IHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50
ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQg
bWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGln
YW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29y
cG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3Mg
YW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLgo=

--_000_CY4PR14MB13688CC2BB22F6CC44452615D7A40CY4PR14MB1368namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89
InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu
OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj
aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov
L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9
IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt
ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl
cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv
bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN
Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u
TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy
bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7
DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9l
bnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt
YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv
eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv
dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n
PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk
U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U
ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPllvdSBtYXkgYmUgYXdhcmUgdGhhdCBtb3N0IGVudGVycHJpc2VzIGhh
dmUgYmVlbiBtaWdyYXRpbmcgYXdheSBmcm9tIDMyNzAgZm9yIDIwIHllYXJzIG9yIG1vcmUu
Jm5ic3A7IFZlcnkgbGl0dGxlIHN0aWxsIGV4aXN0cy4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5i
c3A7Jm5ic3A7V2hhdCBsaXR0bGUgZG9lcyBleGlzdCBpcyB1c3VhbGx5IGltcGxlbWVudGVk
DQogdmlhIHRuMzI3MC4mbmJzcDsmbmJzcDsgSW4gdGhlIGJyb3dzZXIgc2NlbmFyaW8geW91
IGRlc2NyaWJlIEkgd291bGQgZXhwZWN0IHRoZSBTZXJ2ZXIgc2lkZSB0byBiZSBhIHRuMzI3
MCBzZXJ2ZXIsJm5ic3A7IGJ1dCB5b3Ugd2lsbCBoYXZlIHRvIGZpbGwgaW4gdGhlIGRldGFp
bHMgb2YgdGhlIHVzZSBjYXNlIHlvdSBhcmUgZGVzY3JpYmluZywmbmJzcDsgdG8gYmUgc3Vy
ZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGhvcGUgdGhlIGFib3Zl
IGhlbHBzLCZuYnNwOyBidXQgbXkgcmVhbCBxdWVzdGlvbiBpcyB3aHkgd291bGQgdGhpcyBi
ZSBzcGVjaWFsIG9yIGV2ZW4gcmVsZXZhbnQgdG8gdGhlIFRMUzEuMyBkaXNjdXNzaW9uLiAm
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXR0ZW1wdGluZyB0byBhZGRyZXNz
IHNwZWNpZmljIGFwcGxpY2F0aW9ucyBvciBpbXBsZW1lbnRhdGlvbnMgd291bGQgc2VlbSBv
bmx5IGFkZCBjb25mdXNpb24gSU1ITy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U
aGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWlrZTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP
ZiA8L2I+VGVkIExlbW9uPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDIwLCAy
MDE3IDEwOjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBUb20gUml0dGVyICZsdDt0b21Acml0dGVy
LnZnJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBUTFMgJmx0O3Rsc0BpZXRmLm9yZyZndDs8
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIElzIHRoZXJlIGEgd2F5IGZvcndhcmQg
YWZ0ZXIgdG9kYXkncyBodW0/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhlIHByb2JsZW0gaXMgdGhhdCBvbmUgb2YgdGhlIGFwcGxpY2F0aW9ucyBmb3Ig
d2ViIGJyb3dzZXJzIGlzIGFzIGEgcmVwbGFjZW1lbnQgZm9yIDMyNzBzICh0aGUgZmlyc3Qg
d2ViIGJyb3dzZXIpLiAmbmJzcDsgVGhhdCB1c2UgY2FzZSBpcyBzYWlkIHRvIHJlcXVpcmUg
dGhpcyBmdW5jdGlvbmFsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMjAsIDIwMTcgYXQgNDo0MyBQTSwgVG9tIFJp
dHRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbUByaXR0ZXIudmciIHRhcmdldD0iX2JsYW5r
Ij50b21Acml0dGVyLnZnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y
aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIDIwIEp1bHkgMjAxNyBhdCAwMTo1MywgWW9hdiBO
aXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5bmlyLmlldGZAZ21haWwuY29tIj55bmlyLmlldGZA
Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMjAgSnVs
IDIwMTcsIGF0IDg6MDEsIFJ1c3MgSG91c2xleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhvdXNs
ZXlAdmlnaWxzZWMuY29tIj5ob3VzbGV5QHZpZ2lsc2VjLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi
cj4NCiZndDs8YnI+DQomZ3Q7IFRlZCwgaWYgd2UgdXNlIGEgbmV3IGV4dGVuc2lvbiwgdGhl
biB0aGUgc2VydmVyIGNhbm5vdCBpbmNsdWRlIGl0IHVubGVzcyB0aGU8YnI+DQomZ3Q7IGNs
aWVudCBvZmZlcmVkIGl0IGZpcnN0LiZuYnNwOyBJIGFtIHRoaW5raW5nIG9mIGFuIGFwcHJv
YWNoIHdoZXJlIHRoZSBzZXJ2ZXI8YnI+DQomZ3Q7IHdvdWxkIGluY2x1ZGUgaW5mb3JtYXRp
b24gbmVlZGVkIGJ5IHRoZSBkZWNyeXB0b3IgaW4gdGhlIHJlc3BvbnNlLiZuYnNwOyBTbywg
aWY8YnI+DQomZ3Q7IHRoZSBjbGllbnQgZGlkIG5vdCBvZmZlciB0aGUgZXh0ZW5zaW9uLCBp
dCB3b3VsZCBiZSBhIFRMUyBwcm90b2NvbCB2aW9sYXRpb248YnI+DQomZ3Q7IGZvciB0aGUg
c2VydmVyIHRvIGluY2x1ZGUgaXQuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFNv
IHdlIGFsc28gYWRkIGFuIGFsZXJ0IGNhbGxlZCDigJxrZXktZXhwb3J0LW5lZWRlZOKAnSBp
biBjYXNlIHRoZSBjbGllbnQgZG9lczxicj4NCiZndDsgbm90IGluY2x1ZGUgaXQuPGJyPg0K
Jmd0Ozxicj4NCiZndDsgVGhhdCB3YXkgYSBicm93c2VyIChhcyBhbiBleGFtcGxlKSBjYW4g
c2hvdyB0aGUgdXNlciB3aHkgdGhlIGNvbm5lY3Rpb24gd2FzPGJyPg0KJmd0OyBicm9rZW4g
KOKAnHNlcnZlciByZXF1aXJlcyB3aXJldGFwcGluZyB0byBiZSBlbmFibGVkLiBHbyB0byBh
Ym91dDpjb25maWcgaWY8YnI+DQomZ3Q7IHRoYXQgaXMgT0sgYW5kIGNoYW5nZSB0aGUgYWxs
b3ctd2lyZXRhcCBzZXR0aW5nIHRvIFRydWXigJ0pPGJyPg0KPGJyPg0KPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBwcmV2aW91c2x5
IGV4cHJlc3NlZCB0aGF0IEkgY291bGQgc3VwcG9ydCB0aGUgZXh0ZW5zaW9uIG1lY2hhbmlz
bSAtPGJyPg0KSSdtIHN5bXBhdGhldGljIHRvIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzIGFu
ZCB1bmhhcHB5IHdpdGgsIGFsdGhvdWdoPGJyPg0KdW5kZXJzdGFuZGluZyBvZiwgd2hhdCBo
YXMgYmVjb21lIHRoZSAnc3RhbmRhcmQgbWVjaGFuaXNtJyAoYnJlYWtpbmc8YnI+DQpjcnlw
dG8pIHRvIGFjaGlldmUgdGhlbS4gSSd2ZSBsb29rZWQgYXQgbW9yZSB0aGFuIG9uZSAnZW5k
IHRvIGVuZCc8YnI+DQplbmNyeXB0ZWQgbWVzc2VuZ2VyIHRoYXQgdG9zc2VzIGluIHRoZSAn
dGhpcmQgZW5kJyBvZiBrZXkgZXNjcm93Ljxicj4NCjxicj4NCkJ1dCB0byBzdWdnZXN0IHN1
Y2ggYSBtZWNoYW5pc20gbWlnaHQgZXZlciBiZSBpbXBsZW1lbnRlZCBpbiBhIHdlYjxicj4N
CmJyb3dzZXIgdGhyb3dzIG15IGhhY2tsZXMgdXAuIFRoZSBkaXNjdXNzaW9uIGhhcyBhbHdh
eXMgYmVlbiBhYm91dDxicj4NCmRhdGFjZW50ZXIgLSB0aGUgcGVvcGxlIGNvbmNlcm5lZCBz
YXkgJnF1b3Q7V2UgZG9uJ3Qgd2FudCB5b3VyIGRhdGFjZW50ZXI8YnI+DQpzdHVmZiBpbiBv
dXIgcHJvdG9jb2wgYW5kIHRoZSBwcm9wb25lbnRzIHNheSAmcXVvdDtObyByZWFsbHksIHdl
IG9ubHkgY2FyZTxicj4NCmFib3V0IHRoZSBkYXRhY2VudGVyLiZxdW90Ozxicj4NCjxicj4N
ClRoZSBjb25jZXJucyBhcm91bmQgc29tZSBmdXR1cmUgZ292ZXJubWVudC1tYW5kYXRlZCBr
ZXkgZXNjcm93IGlzIHZlcnk8YnI+DQpyZWFsIGFuZCB2ZXJ5IGNvbmNlcm5pbmcuPGJyPg0K
PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIi
Pi10b208L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt
YWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCgoKPEJSPgo8aHRtbD4KIDxwPlRoZSBpbmZvcm1hdGlvbiBj
b250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGhpZ2hseSBjb25maWRlbnRpYWwg
YW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChz
KSB0byB3aG9tIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBkaXJlY3RlZC4gSWYgeW91IGFyZSBu
b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhh
dCBhbnkgdmlld2luZywgY29weWluZywgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gb2Yg
dGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5IHRoZSBzZW5k
ZXIsIGJ5IGVsZWN0cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFueSB1bmludGVuZGVk
IHJlY2VpcHQgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRob3V0IG1ha2lu
ZyBhbnkgY29waWVzLjwvcD4KIDxwPkJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGln
YW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29y
cG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3Mg
YW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLjwvcD4KICA8L2h0bWw+Cgo=

--_000_CY4PR14MB13688CC2BB22F6CC44452615D7A40CY4PR14MB1368namp_--



From nobody Fri Jul 21 03:14:45 2017
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 65045127869 for ; Fri, 21 Jul 2017 03:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level: 
X-Spam-Status: No, score=-2.12 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, RCVD_IN_SORBS_SPAM=0.5] 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 RdcMVnqERoDv for ; Fri, 21 Jul 2017 03:14:43 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [212.227.20.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA1A127337 for ; Fri, 21 Jul 2017 03:14:42 -0700 (PDT)
Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id E19114B9 for ; Fri, 21 Jul 2017 11:14:40 +0100 (BST)
Received: by mail-io0-f176.google.com with SMTP id q2so20758752ioe.3 for ; Fri, 21 Jul 2017 03:14:40 -0700 (PDT)
X-Gm-Message-State: AIVw112J51KIVrsuuoJARaR+01S/VtpukKkp92CLDztspBSgiO9cqV7z dMotq89TcaeAUJDnaJEby5ZQhqJ7vA==
X-Received: by 10.107.9.137 with SMTP id 9mr6999080ioj.131.1500632079258; Fri, 21 Jul 2017 03:14:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.37.2 with HTTP; Fri, 21 Jul 2017 03:14:38 -0700 (PDT)
In-Reply-To: 
References:  
From: Matt Caswell 
Date: Fri, 21 Jul 2017 11:14:38 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Benjamin Kaduk 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] SNI with early data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 10:14:44 -0000

On 20/07/17 18:10, Benjamin Kaduk wrote:
> On 07/20/2017 04:51 AM, Matt Caswell wrote:
>> I note in draft-21 the following text:
>>
>>    When clients use a PSK obtained externally to send early data, then
>>    the following additional information MUST be provisioned to both
>>    parties:
>>
>>    -  The TLS version number for use with this PSK
>>
>>    -  The cipher suite for use with this PSK
>>
>>    -  The Application-Layer Protocol Negotiation (ALPN) protocol
>>       [RFC7301], if any is to be used
>>
>>    -  The Server Name Indication (SNI), if any is to be used
>
> These are in addition to the hash algorithm provisioned with the
> external psk that is needed for 1-RTT operation, as mentioned somewhat
> in passing in section 4.2.10
>
>> Later it says this:
>>
>>    In order to accept early data, the server MUST have accepted a PSK
>>    cipher suite and selected the first key offered in the client's
>>    "pre_shared_key" extension.  In addition, it MUST verify that the
>>    following values are consistent with those negotiated in the
>>    connection during which the ticket was established.
>>
>>    -  The TLS version number and cipher suite.
>>
>>    -  The selected ALPN [RFC7301] protocol, if any.
>>
>>
>> The language about "during which the ticket was established" seems to
>> suggest that the following checks do not apply to an external PSK -
>> which I don't think is intended. Additionally there does not seem to
>
> These values are a subset of those listed above.  I believe this block
> of text only applies to NST-provisioned PSKs being used for early data,
> as the previous text applies to external PSKs being used for early
> data.

Interesting because I assumed the intention was the opposite. I'm not
sure why this restriction should only apply to NST-provisioned PSKs.


>  So, since the previous list is a superset, there is no problem
> caused by this text not applying to external PSKs.

The earlier text is about what needs to be *provisioned* to both
parties. This text is about what MUST be verified on the server. I
think these are two subtly different things. I see no reason to
exclude SNI from requiring to be verified, nor do I see a reason to
restrict it to NST PSKs only. Either you MUST do it for both types of
PSK or you don't need to do it at all. What is the benefit of
complicating things by providing a partial list that MUST be verified
for one type of PSK only?

If this block of text is about NST PSKs only then the implication is
that a server MAY tolerate discrepancies in ALPN for external PSK. At
least that is the way I read it (although I don't think that was the
intention).

>
>> be a requirement on the server to check that the SNI is consistent.
>> So, there is a mandatory requirement for an external PSK to specify
>> the SNI, but no requirement on the server to check that it is actually
>> correct. Is this discrepancy intentional?
>>
>
> I'm not sure I fully understand what you are saying.
> The text says that (for external PSKs) the SNI must be provisioned to
> both parties, which to me implies that the server must only use the
> given PSK for early data with the specified SNI.  (That is, that the
> server has to check.)

It does not imply that to me. It says it has to be provisioned. That
fact that NST PSK MUST verify, implies to me that non-NST PSKs may
tolerate discrepancies.

>
> For tickets, the requirement that SNI must match the original connection
> is mentioned in section 4.6.1 (NewSessionTicket).

Again...why only for NST PSKs?

>
> In short ... I don't see any problems here.  Do you still see a problem?

Yes - given that we have different interpretations of the same text I
still see a problem. I think it should be a lot more explicit, and
remove the discrepancies between NST PSKs and external PSKs.

There is another example of this, earlier on in section 4.2.9:

"The parameters for the 0-RTT data (symmetric cipher suite, ALPN
protocol, etc.) are the same as those which were negotiated in the
connection which established the PSK."

This implicitly seems to only apply to NST PSKs. Why not external PSKs too?

Matt


From nobody Fri Jul 21 03:16:08 2017
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 DF0A2129B7F for ; Fri, 21 Jul 2017 03:16:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CI_bicHHUZcy for ; Fri, 21 Jul 2017 03:15:59 -0700 (PDT)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 13F14127869 for ; Fri, 21 Jul 2017 03:15:59 -0700 (PDT)
Received: by mail-pg0-x234.google.com with SMTP id 125so26974729pgi.3 for ; Fri, 21 Jul 2017 03:15:59 -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=amUK3QOtAU8UoyE78Ef3wgkkhFfkyCw+L/4ikdxKdlA=; b=d53VPS6cZElAN/OHN06T2+bfzTTpjmPLWiCf5HA/R1hmkIdRCxZy/9PAnIHXoyzJrq KteJrnKI5JrtSd8zWm2/7EqtCgf8IuoHkIVbBgQfNu4GjOIv21gG9f07bDYFkBHJOHpL CmXAiUZk9eV8+io+2X1HQAvvYObKxh52h51w7eF1aZvay0PM7kyUAc/7Ljzio3r9W3Wg JEsXkvNmCjVuEHEdLsXqi7Y4qkcd3xNBZ+51cUXPCyWXG+Gqc3B2kStglnCZYAbHfkEB jeigAlwS2t+3Nzi9QxaJd3QR4m3CDJxA+vIJ56HAvl1yciWJs13F2N19m4z00Ql82vGG P18A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=amUK3QOtAU8UoyE78Ef3wgkkhFfkyCw+L/4ikdxKdlA=; b=cLU4yy4UdY8cw4PSMrMQmeCO6bbwSpSWsvxPiXljHj2T86PjIPEI4Md+RwfIs8wXp3 so78LGziycaxwR4h7SXz7W8f5RuDM8f88HGOfK0CekkSC525BNSNz0btE/eXT3X2pS6G Yu3+Uz4AKiXhu8SvfszXMILe5F0GGGWYIQUdX5zl3+qNHy9w0LAc0OKtgteMMMLq1GPr SBr47DSpCGTwMbJn9d6ToCCIiXJziyUysbSpp+QmDFVlLUzt5b5disvad/9okjKRi2i/ hso72zhozLfxIkddop5ZniHcCtXXhagXRWucq/70ONpKtUV2R21IYNVjgaCPtDZI0VUZ TuLg==
X-Gm-Message-State: AIVw110jO/LF5KIEnFMAAbQeYFY723bcjhOhn+eYDxvvJ48r5AH8Ryvq gjqp8GSjkLFHt3JS8DRtvxSn8yLAZN11
X-Received: by 10.98.18.69 with SMTP id a66mr7088103pfj.33.1500632158644; Fri, 21 Jul 2017 03:15:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.130 with HTTP; Fri, 21 Jul 2017 03:15:18 -0700 (PDT)
In-Reply-To: 
References:       
From: Ted Lemon 
Date: Fri, 21 Jul 2017 12:15:18 +0200
Message-ID: 
To: "Ackermann, Michael" 
Cc: Tom Ritter , IETF TLS 
Content-Type: multipart/alternative; boundary="001a1145b83ac1405c0554d126f8"
Archived-At: 
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 10:16:02 -0000

--001a1145b83ac1405c0554d126f8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As I said in the previous message, the 3270 was the original web browser.
What I mean by that is that the 3270 transaction model is basically a
primitive version of http: you throw up a page, the user enters some data,
then the user hits send and all the data goes to the server at once.   The
reason the 3270 is no longer widely used is because it's been replaced by
web browsers.

Mentioning that in passing probably made my message less clear; the point
is that the 3270<->mainframe model of operation comes with very different
assumptions than the web browser<->service provider model, and one of the
problems you have is that what you are doing is really the former and not
the latter.


On Fri, Jul 21, 2017 at 12:00 PM, Ackermann, Michael 
wrote:

> Ted
>
> You may be aware that most enterprises have been migrating away from 3270
> for 20 years or more.  Very little still exists.      What little does
> exist is usually implemented via tn3270.   In the browser scenario you
> describe I would expect the Server side to be a tn3270 server,  but you
> will have to fill in the details of the use case you are describing,  to =
be
> sure.
>
>
>
> I hope the above helps,  but my real question is why would this be specia=
l
> or even relevant to the TLS1.3 discussion.
>
>
>
> Attempting to address specific applications or implementations would seem
> only add confusion IMHO.
>
>
>
> Thanks
>
>
>
> Mike
>
>
>
>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 10:48 AM
> *To:* Tom Ritter 
> *Cc:* IETF TLS 
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> The problem is that one of the applications for web browsers is as a
> replacement for 3270s (the first web browser).   That use case is said to
> require this functionality.
>
>
>
> On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter  wrote:
>
> On 20 July 2017 at 01:53, Yoav Nir  wrote:
> >
> > On 20 Jul 2017, at 8:01, Russ Housley  wrote:
> >
> > Ted, if we use a new extension, then the server cannot include it unles=
s
> the
> > client offered it first.  I am thinking of an approach where the server
> > would include information needed by the decryptor in the response.  So,
> if
> > the client did not offer the extension, it would be a TLS protocol
> violation
> > for the server to include it.
> >
> >
> > So we also add an alert called =E2=80=9Ckey-export-needed=E2=80=9D in c=
ase the client
> does
> > not include it.
> >
> > That way a browser (as an example) can show the user why the connection
> was
> > broken (=E2=80=9Cserver requires wiretapping to be enabled. Go to about=
:config if
> > that is OK and change the allow-wiretap setting to True=E2=80=9D)
>
> I previously expressed that I could support the extension mechanism -
> I'm sympathetic to regulatory requirements and unhappy with, although
> understanding of, what has become the 'standard mechanism' (breaking
> crypto) to achieve them. I've looked at more than one 'end to end'
> encrypted messenger that tosses in the 'third end' of key escrow.
>
> But to suggest such a mechanism might ever be implemented in a web
> browser throws my hackles up. The discussion has always been about
> datacenter - the people concerned say "We don't want your datacenter
> stuff in our protocol and the proponents say "No really, we only care
> about the datacenter."
>
> The concerns around some future government-mandated key escrow is very
> real and very concerning.
>
> -tom
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> The information contained in this communication is highly confidential an=
d
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Bl=
ue
> Shield Association.
>

--001a1145b83ac1405c0554d126f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    As I said in the previous message, the 3270 was the origin=
al web browser. =C2=A0 What I mean by that is that the 3270 transaction mod=
el is basically a primitive version of http: you throw up a page, the user =
enters some data, then the user hits send and all the data goes to the serv=
er at once. =C2=A0 The reason the 3270 is no longer widely used is because =
it's been replaced by web browsers.

    Mentioning that =
in passing probably made my message less clear; the point is that the 3270&=
lt;->mainframe model of operation comes with very different assumptions =
than the web browser<->service provider model, and one of the problem=
s you have is that what you are doing is really the former and not the latt=
er.


    On Fri, Jul 21, 2017 at 12:00 PM, Ackermann, Michael <=
;MAckermann@bcbsm=
.com> wrote:
    






    

    

    Ted
    

    You may be aware that most enterprises have been mi=
grating away from 3270 for 20 years or more.=C2=A0 Very little still exists=
.=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0What little does exist is usually implement=
ed
 via tn3270.=C2=A0=C2=A0 In the browser scenario you describe I would expec=
t the Server side to be a tn3270 server,=C2=A0 but you will have to fill in=
 the details of the use case you are describing,=C2=A0 to be sure.=C2=A0

    

    =C2=A0
    

    I hope the above helps,=C2=A0 but my real question =
is why would this be special or even relevant to the TLS1.3 discussion. =C2=
=A0
    

    =C2=A0
    

    Attempting to address specific applications or impl=
ementations would seem only add confusion IMHO.

    

    =C2=A0
    

    Thanks
    

    =C2=A0
    

    Mike
    

    =C2=A0
    

    =C2=A0
    

    =C2=A0
    


    From: TLS [mailto:tls-bounces@ietf.org]
On Behalf Of Ted Lemon
    
Sent: Thursday, July 20, 2017 10:48 AM
    
To: Tom Ritter <tom@ritter.vg>
    
Cc: IETF TLS <t=
ls@ietf.org>
    
Subject: Re: [TLS] Is there a way forward after today's hum?<=
/u>
    

    =C2=A0
    

    

    The problem is that one of the applications for web =
browsers is as a replacement for 3270s (the first web browser). =C2=A0 That=
 use case is said to require this functionality.
    

    

    

    =C2=A0
    

    

    On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter <tom@ritter.vg> wrote:=

    

    

    

    

    On 20 July 2017 at 01=
:53, Yoav Nir <=
ynir.ietf@gmail.com> wrote:
    
>
    
> On 20 Jul 2017, at 8:01, Russ Housley <housley@vigilsec.com> wrote:
    
>
    
> Ted, if we use a new extension, then the server cannot include it unle=
ss the
    
> client offered it first.=C2=A0 I am thinking of an approach where the =
server
    
> would include information needed by the decryptor in the response.=C2=
=A0 So, if
    
> the client did not offer the extension, it would be a TLS protocol vio=
lation
    
> for the server to include it.
    
>
    
>
    
> So we also add an alert called =E2=80=9Ckey-export-needed=E2=80=9D in =
case the client does
    
> not include it.
    
>
    
> That way a browser (as an example) can show the user why the connectio=
n was
    
> broken (=E2=80=9Cserver requires wiretapping to be enabled. Go to abou=
t:config if
    
> that is OK and change the allow-wiretap setting to True=E2=80=9D)
    

    

    

    

    

    I previously expressed that I could support the exte=
nsion mechanism -
    
I'm sympathetic to regulatory requirements and unhappy with, although
understanding of, what has become the 'standard mechanism' (breakin=
g
    
crypto) to achieve them. I've looked at more than one 'end to end&#=
39;
    
encrypted messenger that tosses in the 'third end' of key escrow.

    
But to suggest such a mechanism might ever be implemented in a web
    
browser throws my hackles up. The discussion has always been about
    
datacenter - the people concerned say "We don't want your datacent=
er
    
stuff in our protocol and the proponents say "No really, we only care<=
br>
about the datacenter."
    

    
The concerns around some future government-mandated key escrow is very
    
real and very concerning.
    

    
-tom
    

    

    


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

    

    

    

    

    =C2=A0
    

    

    

    




    

 
    The information contained in this communication is highly confidential =
and is intended solely for the use of the individual(s) to whom this commun=
ication is directed. If you are not the intended recipient, you are hereby =
notified that any viewing, copying, disclosure or distribution of this info=
rmation is prohibited. Please notify the sender, by electronic mail or tele=
phone, of any unintended receipt and delete the original message without ma=
king any copies.
    
 
    Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan ar=
e nonprofit corporations and independent licensees of the Blue Cross and Bl=
ue Shield Association.
    
 =20



    

--001a1145b83ac1405c0554d126f8--


From nobody Fri Jul 21 03:29:28 2017
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 B7BF7129B7F for ; Fri, 21 Jul 2017 03:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 C2a2iaabd1FC for ; Fri, 21 Jul 2017 03:29:20 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 DD7A5127337 for ; Fri, 21 Jul 2017 03:29:19 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id r76so5734295pfj.2 for ; Fri, 21 Jul 2017 03:29:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NwVo+n23Cr/hwYtbWR+5dSKxZYxRRHs7UOd5MOr5pWc=; b=skacd6cpCJy4C/GNeR5NwZ1tcTsHKXYIq9XsoSYOC5Mst5qy+2AdmyPFmmL9otT+bl cmyBT4cCOjazIFiq0GrqP2h9BFQZ9ZlxADNEyWa/fZIDfx1Sd4b0KfXtDfgXTJVinLXF tpizkTeEn2pfqkwd0EDHpq1DrJpzbrP3E47HsaYanpLlvjOWR/6/nVg1sLSKqZpaNitW VYWdCcjLrEuEv8ZowoEYHEQs+SiyZCWJe0f09OQyJdEcjlVisU3KVinPXvR0Se0fq2ks KWMqiLfog/og1ys+z37y60XhJ099+R13GQP/y4pz+H4w6cdBm0IFm6A/WNTnbpPPQmdU QeFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NwVo+n23Cr/hwYtbWR+5dSKxZYxRRHs7UOd5MOr5pWc=; b=kSCpU9tTnuh+e33u79/CDYbMbUZE6KL2ooeQqPcJSDvdrWrgCKCwAKOCwxlrL91DUn uYZXX1yE2iNYJ4YC8n8rc5/2zA6k7OSSunYUMzMRGFphllZErvwxaPaCmH+dhGhp3yEv iPQE3PFaCpSjHrNDM3eJ3R4P/k8sVmEZnd1DUV4T2JIk+KWM716Mz+T4rkA03mjcwRhH oOZYhHoOPIaYtpuZHpWz6B8/6I/ASfABWutdmt3fbNU7rddRJWLr27bzl+Y4U0x4O+vm lJOQK4v3bOsA/42CtwBhCn1orEAEj5VeRCqAZsNrxM6jzjnr/jtN3i3/Z8rGzBv2PsgD Z/8g==
X-Gm-Message-State: AIVw113eewvVLRBFLEhD4a5TGqL74WoZELNzEypq/5yywzRZShPiOoMF f7DEwPjbIc9jUSvCbcfkxA+fZAW9RFSn
X-Received: by 10.99.117.11 with SMTP id q11mr6827529pgc.69.1500632958117; Fri, 21 Jul 2017 03:29:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.180.193 with HTTP; Fri, 21 Jul 2017 03:28:37 -0700 (PDT)
In-Reply-To: 
References: 
From: Kathleen Moriarty 
Date: Fri, 21 Jul 2017 06:28:37 -0400
Message-ID: 
To: Joseph Lorenzo Hall 
Cc: "tls@ietf.org" , Sean Turner , Joseph Salowey 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] notes for TLS WG Session 2 at IETF 99
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 10:29:25 -0000

Hi,

The email seems to be missing some text that was in the etherpad (or
reordered maybe), so here it is again:

IETF99 TLS WG 2nd session (19-July-2017)

(all errors are JLH's)

Agenda/Administrivia

Exported Authenticators (EKR)

draft 21, hopefully close

WGLC #2 ended yesterday

Changes since -19

shorten HKDF labels

make post-handshake auth imp option

add per-ticket nonce, each ticket is assoc. w/ new PSK

new section 0-RTT anti-replay

Mandatory anti-replay (PR# 1059)

requires some bounded mechanism, but no specific technique

Should we adopt this? Any objections?

MT: every instance has to ensure that it only accepts the same 0-RTT
once... which means an unbounded state problem

EKR: imp in NSS would guarantee "as 0-RTT"

... "you must accept 0-RTT data once"

MT: We've got a window, only accept in that window, no guarantee either.

(No objections)

PR# 1053: Hashes that aren't hashes

HKDF-Expand-Label included a hash function that occasionally is not a hash.

essentially, SHA156(empty string) passed frequently to something else.

Probably worth saying "you can pass a null value, and not pass a hash"

EKR: any opinions?

MT: noticed while doing vectors draft, we do this once every
handshake. I don't care.

EKR: there are two places that it can happen.

MT: still, I could care less.

Hannes: doesn't make sense to change since people have implemented like this.

RLB: I agree with MT and Hannes. Like the current mechanism, can opt
with table of hash values.

Placeholder: NAT/Middleboxes

TLS 1.3 starting to show increased connection failure rates.

hard to meausre but 1-10%

Problem seems to be middleboxen

proposals are either make connection look more or less like TLS 1.2

Joe S: when will experiments complete?

EKR: depends on what we see. Will have data relatively soon, 4-8
weeks. Takes a while to get into a release... but nightlies and betas
give some indication of if it will work.

draft-ietf-tls-dnssec-chain-exstension (Melinda Shore)

completed WGLC on this draft.
(https://www.ietf.org/proceedings/99/slides/slides-99-tls-sessb-dnssec-chain-validation-00.pdf)

excellent feedback so far.

(melinda summarizes changes)

record ordering (server canonicalization, yes or no?) No one came to mic.

use of _udp label for QUIC

Ted Hardie: reading of the draft is that UDP label used for DTLS and QUIC.

...: you might have two different TLSA records, one for DTLS and one
for QUIC. Maybe call it _quic?

Paul Woters: want to make sure we don't create a new plaintext reference

tell client imps how to handle unexpected/irrelevant/extraneous records?

Joe: we'll close on these remaining issues before reving the draft.

DTLS 1.3 (EKR)

first mentions something about exported authenticators:

certificate type extension goes in server [something] message.

odd thing is can have EE X.509 extension [somewhere] which is nuts.

Suggest we maintain the property where I change the entry in the table
and [something]

Trying to keep 1.2 functionality.

Reminder: ACKs

implicit ACKs historically.

interacts badly with some TLS 1.3 features (like NST)

Solution: intro an explicit ACK

current proposal: SACK

kind of ripping off the QUIC structure.

MT: other thing with it being a handshake message is that it adds to
the transcript record and that gets weird.

When should receivers ACK

supposed to ACK when you're not moving the state machine forward, when
messages might have gotten lost, not for non-handshake messages

If anyone thinks this is a bad strategy, please speak up.

Joe S: how many people have had a chance to look at this? Not too many.

Janardhan Igengar: would be nice if this is not too complicated.

Reduced Header Format

MT: we currently have range between 20-64 reserved for us in this
demux thing. We only use the lower half of the 20s... this uses the
upper half of that range from 32 onwards. Can use that entire space
and allows good distinguishing. Don't see us using too much more
content types.

EKR: essentially the point of doing something different would be to
have much longer sequence bits.

MT: not sure I've convinced Ian Swette [sp?]

SPT: thing about this is that the IoT will think we ned to make this
smaller... this seems about as small as you can get to.

MT: one optimization we could make in addition, would be to remove the length.

EKR: but that would make the ACK'ing problematic (?)

MT: other way to do that is to do some internal framing... "I've got
an ACK and some other stuff in here"

... real challenge here are the cases when you're changing keys. would
need internal lengths for those content types.

Connection IDs

have spent an enormous amount of time on this.

things behind NATs have problems rebinding.

also a serious privacy problem, none of the proposals I've seen are
adequate let alone completely baked.

huge problem in the browser context, not so much in the mobile context.

proposal for DTLS is to kind of punt: have an optional but fixed
Connection ID. Doesn't change across the connection.

We can add a new extension to negotiate functionality. Best scaling
involves passing a token for each connection, yucky.

(EKR shows a proposal for a Connection ID extension)

IDs are used if a client offers and a server answers

Each side *sends* with the other's ID.

Happy to hear objections to this strategy.

Tobias G.: Connection ID is currently a very big problem in IoT space.

lake of entropy space in connection ID... 100k entropy doesn't work
for IoT. need 10^6.

Need this ASAP.

Privacy concern is absolutely correct. Need to be able to reneg the client ID.

EKR: I've proposed reciever sets.

TG: want to avoid collision in the space... if the server controls
that ID, you avoid collisions.

EKR: this design avoids that.

TG: can we do this in 1.3 please?

Hannes: data flows in two directions, similar to IPSEC.

Ted H: how does this impact RTCWeb?

EKR: wouldn't anticipate being able to use this for RTP.

... unaware NAT rebinding typically assumes that one side has an open
connection.

EKR: clarify, server picks ID for packets that come to him, client
picks the IDs that come to them.

DKG: two questions: 1) IoT devices are unlikely to be mobile, do we
have evidence for that? Seems like it's also active in things like
vehicles; and 2) looks to me like a field for arbitrary metadata
insertion in each packet and with long lengths, that looks like SPUD
but we're not going to call it SPUD.

EKR: let me make my threat of violence clear, you need to solve it.

Yoav channeling Victor: why is this an assymetric connection ID scheme?

EKR: any symmetric scheme people want to pack the target into the
connection ID. might not want to have a random ID.

MT: whole point of this is to mark packets so the reciever can get
them to the right place.

MT: I think this is enough of an attractive target that I don't want
to see this in DTLS 1.3, want to see that in a separate document...
will address 1.2 as we can hit them at the same time.

EKR: structure of this is that we can easily add as an extension.

MT: if we just do this we don't get the ability to change over time,
important for mobility. makes the arb metadata insertion better to
deal with.

Christian Huitema: we need to do this right and not fast. Quick and
dirty stuff is not going to cut it.

... want to be able to reneg. probably want to make it optional so
it's not in every packet. Want to have a constraint so that we don't
get huge privacy holes.

EKR: what about this? Feel like QUIC got bogged down... proposal that
got the most attention was an unencrypted connection ID. Should we
build a fixed connection ID or something that constantly changes?

EKR can prepare a separate draft for this... may not change 1.2 as that's hard.

Jan I: [could not understand]

Ben Schwarts: in addition to privacy within a connection, if youre a
client trying to keep track of a number of servers, it can be
essentially a counter. May encourage clients to create a
cross-connection... IDs are in a sequential range, these connections
are all the same client. Would be nice to not do that.

EKR: this might require it being longer!

Hannes T: we wouldn't have a problem in IoT case if the NATs wouldn't
exist or do rebinding or if the devices would more frequently send
traffic.

... vehicles will probably use cellular keeping the connex open.
Always the chance to restart from scratch... connection ID wouldn't
make a difference, need to start DTLS connection over again.

... so sending a big ID is not going to help at all.

DKG (off mic): why have it then?

Hannes: we don't have it!

Tobias G: for these connections, mobile devices are in the use cases
that I see. When you consider reneg, consider that main use case is
devices with power constraints. So every RT etc. is very costly. Not
reneg every time would be good. Would like things that we can tailor,
customize.

Would rather have this really soon... problem is out there.

Would strongly urge the chairs to consider for 1.2

Jan I: could we constrain this to a smaller thing...

EKR: any number large enough to be useful will make DKG sad.

MT: any size that is useful, is useful (making the point that it's
useful for good and bad)

SPT: will send an email for when DTLS will drop compared to TLS. Now
is your chance to get to the mic.

Chair interrupt:

First thing: presenters are keeping it short and to the point. Hold
points until after presentation.

Plenty of time for discussion.

Want to address both political and technical topics

The main question: Is this subject something that the WG should
consider? This = "passive decryption of traffic"

What technical solutions are available, becasue the WG gets change
control if adopted.

Impacts of TLS 1.3 on Eneterprise network operation (Steve Fenter,
Matt Green, Russ Housely)

use cases:

wireshark PCAP decrypt

Fraud Monitoring

IDS/IPS

Malware Detection

Security incident response

Regulatory requirements

Layer 7 DDoS Protection

NPM/APM

When problem hits, no one knows where in this universe of 400 boxes
the problem is.

I need packet level visibility in everywhere across these 400 boxes.

a month ago, got a problem in login failures and slowdowns.

sniffer guys called in to swoop in and save the day.

Many other guys getting called with severity 1 problems and need to decrypt

No way to identify the user bc CDN, decrypt the packets to find
user_id or other elements.

one particular URL was giving 10s response time

Tier 2 load balancer, found the same symptom.... etc.

would need 5 proxies here and that doesn't scale... millions of dollars.

endpoint monitoring doesn't work, as you can't do full-scale pcap..
because of NAT etc.

often need decrypted PCAP where there is no endpoint (e.g., firewalls
don't often allow you to terminate)

tl;dr: a particular db call to a small single-threaded access table
was slowing everything down.

If TLS 1.3 rolls out without static DH, severity 1 problems will drag
out for weeks. Severity 2 will take months.

level of pain that enterprises aren't willing or able to handle.

if I have a problem that TLS causes, it's basically a DoS attack. TLS
1.3 is a DoS attack for us.

Matt Green

This is not technically a problem: if you control the endpoints, you
control the secrets.

How do you do this that doesn't harm the protocol?

possible solns:

endpoints being the servers, deliver session keys or MSs through an
OOB channel. But # of keys can be very large.

have to deliver keys in a very timely manner, can't cache over much time

encode keys in band in the TLS protocol.

one option is to use a full extension and then include an in-bad inclusion.

unfortuantely, legacy systems don't include this functionality.

lots of different variants, some of very hard to detec.

Hovav: use DUAL-EC

Endpoints use (semi)-static keys

don't change the protocol, let's do something others can recognize.

No changes to 1.3

Easy to detect

Reduces FS, mitigated by key rotation.

Static DH draft

(Matt describes draft-green)

Security of Static DH

leave aside FS, it is cryptographically secure

FIPS 800-56A talks about using static DH. TLS 1.2 has DHS

concerns

easy to have imp flaws.

but easy to not affect most users.

Harm reduction

enterprises don't adopt 1.3, today they're using 1.2 with static RSA.

make some dramatic changes to endpoints to deliver session keys.

some really really bad ideas (won't go into)

Extensions (open to this)

pros: no significant protocol changes, well-understaood crypto, detectability.

Natl Cybersecurity Center of Excellence (Tim Polk)

Sponsor of a related draft.

NCCOE is all about implementation and adoption.

Have been hearing issues with meeting operation reqs for 1.3

Objective is to collab with industry, solve problems and get better
security than we have today.

NCCoE will produce a proof of concept imp and a number of documents...
want to prove that we can tighten up the life span of those keys that
we are sharing in the enterprise.

Would produce an 1800 series practice guide that would say, "if you
want to do what we did in the imp, do this."

would submit an IETF draft that showed what we did, what worked/did
not, here are the key liftetimes that we think we can manage.

Proposal DOES NOT violate the IETF policy on wiretapping (Russ Housely)

RFC 2804 defines wiretapping and this is not that.

Want to get as much TLS nowledge from this WG as possible to produce
as secure a thing as possible.

TINFOIL (Stephen Farrell)

This whole thing is a terrible idea, we shouldn't do it.

Stephen goes through the various arguments listed here:
https://github.com/sftcd/tinfoil

not in scope for charter

could put TLS/DTLS 1.3 at risk

TLS is hard

1.3 has undergone significant analysis so far, this has not

Static DH is not implementation robust

we have a case where law enforcement has tried to coerce a server
operator to tap at TLS level

should in no way be a standards track document.

breaking TLS is not part of the WG charter.

...

Question to group: should we document these arguments about breaking TLS?

Q&A:

PHB: agree with both sides. Problem here is coming from the PKI world,
saw what happen to bluecoat and co. We didn't make WebPKI holes for
them, so they blasted holes into it.

on the techincal side, don't like how you're doing it. I'd use a
different DH share every time.

would like to have this such that if this makes it into the wild, it
is not compat with legacy stuff

Paul Woters: want to quote RFC-someting-bis

talking about DH groups 22, 23, 24. 22 is must not. 23 and 24 will be
must not soon, should not now.

Dan Harkins: there is IPR here out here from a past employer.

DKG: want to express disappointment with this draft.

export cipher suites was brought up. As recently as last year we've
had problems with the fact that export cipher suites were standardized
20 years ago.

The first time we see a problem with this might be soon... the last
time we see a problem will be way way in the future.

Rich Salz: (applause)

I am torn between: prof. and personally I think this is not a good
thing. Remember Dave Clarke's talk that we need to tilt the playing
field for things that people use.

would like to see us wait two years for deployment exp. It's
pre-mature. Let's revisit.

Darin Pettis:

We've been here before, part of a large financial organization. We've
ditched RSA, we understand that.

We've explored technical options, and have not find a better way.

Roman from CMU:

didn't see discussion for security uses, esp. DFIR (incident response).

very key to do ad hoc instrumentation and this would help.

[Cisco business security group]:

Don't think security is served by seeing this as a black or white approach.

Reminds me of the old discussion of NATs.

Community is better served by ack'ing this problem and find a way to solve it.

Nalini Elkins:

There are very real problems from real people doing real things.

If you are hearing from real people that there are problems, behooves
us to listen.

mnot:

this is not the first time we've seen this thing.

2 years ago, proposals strongly made in HTTP.

We chose not to accept that work; reason is that HTTPS is explicitly a
two-party protocol. Did not have a way to get the informed consent
necessary to change the protocol.

You are changing the nature of the protocol pretty fundamentally.

Ted Hardie:

two points: FS is a feature of this protocol. This turns it off in
certain contexts, not obvious to the end users that FS has been
removed. Can't tell in the first connection if a key will be re-used.
Need to have a way with features like this about 1) signal that it's
being used; and 2) get agreements to use it from those communicating.

if it comes back with those changes, what's the domain analysis? Russ
read us section 3 of RFC 2048, but not section 4, that says, "we're
not taking a moral stand, but a technical stand". You MUST expect a
technology to be used in places you might not expect. Analysis must
take into account all of the domains of us.

Max Pala (cable labs):

agree with Stephen.

Most of the time this is a problem if your arch is outdated. No one
will force you to do this... if you do deploy 1.3, should be
conformant.

Ralph Droms:

Living the dream (laughter)

Want to emphasize keeping separate the fundamental abstract questions
that are being discussed and the particular proposal that is on the
table in this document.

Roland Dobbins:

Want to emphasize being able to troubleshoot and need visibility.

Often this needs to be on the wire.

They may face potential fines and liability if they don't take care of
our information.

We don't want crypto that is proprietary or that is developed in
smoke-filled rooms.

Jeff Hodges:

want to echo ralph and roland and a few other people.

There are enterprise needs here to do this thing.

We want to get to FS in the data center and we need a migration path
that has been scrutinized by experts.

Christian Huitema:

want to support Stephen and Ted: take the Lavabit scenario.

A provider of a service is being compelled to turn on a feature so
that someone can get their traffic.

This approach is very dangerous... you assume that you are using the
same software in both DCs and on a server.

Don't like the feature that this is keeping the wire format unchanged.

We need a "big red flag" requirement so that this is only used in the DC.

Daniel Franke (Akamai):

like draft-00, not draft-01

draft-01 is standards track, not ok

Kenny Patterson:

There is nothing in the current draft that would force the rotation of keys.

suggestion: adopt the draft and force key rotation on each connection.

Sharon Goldberg (BU)

Want to support Stephen.

Not confied to DCs, do not support at all

Deb Cooley (NSA)

I believe if you take the draft here, you control the draft.

if you let this go underground, it will happen silently like what
happened in the past with Static RSA.

Tara Tarikyee (OTF)

add voice to those disappointed in this draft.

there are a lot of people that depend on TLS for the practice of those rights.

Questions the charis want answered (policy)

The main question: Is this subject something that the WG should consider?

this = "passive decryption of data center traffic"

subquestion: Is this wiretapping?

Clarifying questions:

Stephen Farrell: don't believe that passive is correct here,
draft-green allows active attacks. Allows the attacker to be active.

Ralph Droms: separate the solution in the draft from the mechanism.

Stephen: A, your saying your draft is broke.

... not clear to me that there is any solution that allows passive
that doesn't allow active.

DKG: we have considered this question for many weeks.

Lucy Lynch: take a hum first on whether or not the group should accept
the draft and then take a more general hum.

Joe S: "decryption of data in the data center" ommiting the word "passive"

Hums: No clarity whatsoever. Seemed pretty even.

Stephen: want to take it to the list as to if the WG is interested in
documenting reasons to not break TLS.





On Wed, Jul 19, 2017 at 5:59 AM, Joseph Lorenzo Hall  wrote:
> are here and copied below (apologies for HTML, pad will disappear in 30
> days):
>
> https://pad.riseup.net/p/kZYK9HuZf85C
>
> IETF99 TLS WG 2nd session (19-July-2017)
>
> (all errors are JLH's)
>
> Agenda/Administrivia
>
> Exported Authenticators (EKR)
>
> draft 21, hopefully close
>
> WGLC #2 ended yesterday
>
> Changes since -19
>
> shorten HKDF labels
>
> make post-handshake auth imp option
>
> add per-ticket nonce, each ticket is assoc. w/ new PSK
>
> new section 0-RTT anti-replay
>
> Mandatory anti-replay (PR# 1059)
>
> requires some bounded mechanism, but no specific technique
>
> Should we adopt this? Any objections?
>
> MT: every instance has to ensure that it only accepts the same 0-RTT once...
> which means an unbounded state problem
>
> EKR: imp in NSS would guarantee "as 0-RTT"
>
> ... "you must accept 0-RTT data once"
>
> MT: We've got a window, only accept in that window, no guarantee either.
>
> (No objections)
>
> PR# 1053: Hashes that aren't hashes
>
> HKDF-Expand-Label included a hash function that occasionally is not a hash.
>
> essentially, SHA156(empty string) passed frequently to something else.
>
> Probably worth saying "you can pass a null value, and not pass a hash"
>
> EKR: any opinions?
>
> MT: noticed while doing vectors draft, we do this once every handshake. I
> don't care.
>
> EKR: there are two places that it can happen.
>
> MT: still, I could care less.
>
> Hannes: doesn't make sense to change since people have implemented like
> this.
>
> RLB: I agree with MT and Hannes. Like the current mechanism, can opt with
> table of hash values.
>
> Placeholder: NAT/Middleboxes
>
> TLS 1.3 starting to show increased connection failure rates.
>
> hard to meausre but 1-10%
>
> Problem seems to be middleboxen
>
> proposals are either make connection look more or less like TLS 1.2
>
> Joe S: when will experiments complete?
>
> EKR: depends on what we see. Will have data relatively soon, 4-8 weeks.
> Takes a while to get into a release... but nightlies and betas give some
> indication of if it will work.
>
> draft-ietf-tls-dnssec-chain-exstension (Melinda Shore)
>
> completed WGLC on this draft.
> (https://www.ietf.org/proceedings/99/slides/slides-99-tls-sessb-dnssec-chain-validation-00.pdf)
>
> excellent feedback so far.
>
> (melinda summarizes changes)
>
> record ordering (server canonicalization, yes or no?) No one came to mic.
>
> use of _udp label for QUIC
>
> Ted Hardie: reading of the draft is that UDP label used for DTLS and QUIC.
>
> ...: you might have two different TLSA records, one for DTLS and one for
> QUIC. Maybe call it _quic?
>
> Paul Woters: want to make sure we don't create a new plaintext reference
>
> tell client imps how to handle unexpected/irrelevant/extraneous records?
>
> Joe: we'll close on these remaining issues before reving the draft.
>
> DTLS 1.3 (EKR)
>
> first mentions something about exported authenticators:
>
> certificate type extension goes in server [something] message.
>
> odd thing is can have EE X.509 extension [somewhere] which is nuts.
>
> Suggest we maintain the property where I change the entry in the table and
> [something]
>
> Trying to keep 1.2 functionality.
>
> Reminder: ACKs
>
> implicit ACKs historically.
>
> interacts badly with some TLS 1.3 features (like NST)
>
> Solution: intro an explicit ACK
>
> current proposal: SACK
>
> kind of ripping off the QUIC structure.
>
> MT: other thing with it being a handshake message is that it adds to the
> transcript record and that gets weird.
>
> When should receivers ACK
>
> supposed to ACK when you're not moving the state machine forward, when
> messages might have gotten lost, not for non-handshake messages
>
> If anyone thinks this is a bad strategy, please speak up.
>
> Joe S: how many people have had a chance to look at this? Not too many.
>
> Janardhan Igengar: would be nice if this is not too complicated.
>
> Reduced Header Format
>
> MT: we currently have range between 20-64 reserved for us in this demux
> thing. We only use the lower half of the 20s... this uses the upper half of
> that range from 32 onwards. Can use that entire space and allows good
> distinguishing. Don't see us using too much more content types.
>
> EKR: essentially the point of doing something different would be to have
> much longer sequence bits.
>
> MT: not sure I've convinced Ian Swette [sp?]
>
> SPT: thing about this is that the IoT will think we ned to make this
> smaller... this seems about as small as you can get to.
>
> MT: one optimization we could make in addition, would be to remove the
> length.
>
> EKR: but that would make the ACK'ing problematic (?)
>
> MT: other way to do that is to do some internal framing... "I've got an ACK
> and some other stuff in here"
>
> ... real challenge here are the cases when you're changing keys. would need
> internal lengths for those content types.
>
> Connection IDs
>
> have spent an enormous amount of time on this.
>
> things behind NATs have problems rebinding.
>
> also a serious privacy problem, none of the proposals I've seen are adequate
> let alone completely baked.
>
> huge problem in the browser context, not so much in the mobile context.
>
> proposal for DTLS is to kind of punt: have an optional but fixed Connection
> ID. Doesn't change across the connection.
>
> We can add a new extension to negotiate functionality. Best scaling involves
> passing a token for each connection, yucky.
>
> (EKR shows a proposal for a Connection ID extension)
>
> IDs are used if a client offers and a server answers
>
> Each side *sends* with the other's ID.
>
> Happy to hear objections to this strategy.
>
> Tobias G.: Connection ID is currently a very big problem in IoT space.
>
> lake of entropy space in connection ID... 100k entropy doesn't work for IoT.
> need 10^6.
>
> Need this ASAP.
>
> Privacy concern is absolutely correct. Need to be able to reneg the client
> ID.
>
> EKR: I've proposed reciever sets.
>
> TG: want to avoid collision in the space... if the server controls that ID,
> you avoid collisions.
>
> EKR: this design avoids that.
>
> TG: can we do this in 1.3 please?
>
> Hannes: data flows in two directions, similar to IPSEC.
>
> Ted H: how does this impact RTCWeb?
>
> EKR: wouldn't anticipate being able to use this for RTP.
>
> ... unaware NAT rebinding typically assumes that one side has an open
> connection.
>
> EKR: clarify, server picks ID for packets that come to him, client picks the
> IDs that come to them.
>
> DKG: two questions: 1) IoT devices are unlikely to be mobile, do we have
> evidence for that? Seems like it's also active in things like vehicles; and
> 2) looks to me like a field for arbitrary metadata insertion in each packet
> and with long lengths, that looks like SPUD but we're not going to call it
> SPUD.
>
> EKR: let me make my threat of violence clear, you need to solve it.
>
> Yoav channeling Victor: why is this an assymetric connection ID scheme?
>
> EKR: any symmetric scheme people want to pack the target into the connection
> ID. might not want to have a random ID.
>
> MT: whole point of this is to mark packets so the reciever can get them to
> the right place.
>
> MT: I think this is enough of an attractive target that I don't want to see
> this in DTLS 1.3, want to see that in a separate document... will address
> 1.2 as we can hit them at the same time.
>
> EKR: structure of this is that we can easily add as an extension.
>
> MT: if we just do this we don't get the ability to change over time,
> important for mobility. makes the arb metadata insertion better to deal
> with.
>
> Christian Huitema: we need to do this right and not fast. Quick and dirty
> stuff is not going to cut it.
>
> ... want to be able to reneg. probably want to make it optional so it's not
> in every packet. Want to have a constraint so that we don't get huge privacy
> holes.
>
> EKR: what about this? Feel like QUIC got bogged down... proposal that got
> the most attention was an unencrypted connection ID. Should we build a fixed
> connection ID or something that constantly changes?
>
> EKR can prepare a separate draft for this... may not change 1.2 as that's
> hard.
>
> Jan I: [could not understand]
>
> Ben Schwarts: in addition to privacy within a connection, if youre a client
> trying to keep track of a number of servers, it can be essentially a
> counter. May encourage clients to create a cross-connection... IDs are in a
> sequential range, these connections are all the same client. Would be nice
> to not do that.
>
> EKR: this might require it being longer!
>
> Hannes T: we wouldn't have a problem in IoT case if the NATs wouldn't exist
> or do rebinding or if the devices would more frequently send traffic.
>
> ... vehicles will probably use cellular keeping the connex open. Always the
> chance to restart from scratch... connection ID wouldn't make a difference,
> need to start DTLS connection over again.
>
> ... so sending a big ID is not going to help at all.
>
> DKG (off mic): why have it then?
>
> Hannes: we don't have it!
>
> Tobias G: for these connections, mobile devices are in the use cases that I
> see. When you consider reneg, consider that main use case is devices with
> power constraints. So every RT etc. is very costly. Not reneg every time
> would be good. Would like things that we can tailor, customize.
>
> Would rather have this really soon... problem is out there.
>
> Would strongly urge the chairs to consider for 1.2
>
> Jan I: could we constrain this to a smaller thing...
>
> EKR: any number large enough to be useful will make DKG sad.
>
> MT: any size that is useful, is useful (making the point that it's useful
> for good and bad)
>
> SPT: will send an email for when DTLS will drop compared to TLS. Now is your
> chance to get to the mic.
>
> Chair interrupt:
>
> First thing: presenters are keeping it short and to the point. Hold points
> until after presentation.
>
> Plenty of time for discussion.
>
> Want to address both political and technical topics
>
> The main question: Is this subject something that the WG should consider?
> This = "passive decryption of traffic"
>
> What technical solutions are available, becasue the WG gets change control
> if adopted.
>
> Impacts of TLS 1.3 on Eneterprise network operation (Steve Fenter, Matt
> Green, Russ Housely)
>
> use cases:
>
> wireshark PCAP decrypt
>
> Fraud Monitoring
>
> IDS/IPS
>
> Malware Detection
>
> Security incident response
>
> Regulatory requirements
>
> Layer 7 DDoS Protection
>
> NPM/APM
>
> When problem hits, no one knows where in this universe of 400 boxes the
> problem is.
>
> I need packet level visibility in everywhere across these 400 boxes.
>
> a month ago, got a problem in login failures and slowdowns.
>
> sniffer guys called in to swoop in and save the day.
>
> Many other guys getting called with severity 1 problems and need to decrypt
>
> No way to identify the user bc CDN, decrypt the packets to find user_id or
> other elements.
>
> one particular URL was giving 10s response time
>
> Tier 2 load balancer, found the same symptom.... etc.
>
> would need 5 proxies here and that doesn't scale... millions of dollars.
>
> endpoint monitoring doesn't work, as you can't do full-scale pcap.. because
> of NAT etc.
>
> often need decrypted PCAP where there is no endpoint (e.g., firewalls don't
> often allow you to terminate)
>
> tl;dr: a particular db call to a small single-threaded access table was
> slowing everything down.
>
> If TLS 1.3 rolls out without static DH, severity 1 problems will drag out
> for weeks. Severity 2 will take months.
>
> level of pain that enterprises aren't willing or able to handle.
>
> if I have a problem that TLS causes, it's basically a DoS attack. TLS 1.3 is
> a DoS attack for us.
>
> Matt Green
>
> This is not technically a problem: if you control the endpoints, you control
> the secrets.
>
> How do you do this that doesn't harm the protocol?
>
> possible solns:
>
> endpoints being the servers, deliver session keys or MSs through an OOB
> channel. But # of keys can be very large.
>
> have to deliver keys in a very timely manner, can't cache over much time
>
> encode keys in band in the TLS protocol.
>
> one option is to use a full extension and then include an in-bad inclusion.
>
> unfortuantely, legacy systems don't include this functionality.
>
> lots of different variants, some of very hard to detec.
>
> Hovav: use DUAL-EC
>
> Endpoints use (semi)-static keys
>
> don't change the protocol, let's do something others can recognize.
>
> No changes to 1.3
>
> Easy to detect
>
> Reduces FS, mitigated by key rotation.
>
> Static DH draft
>
> (Matt describes draft-green)
>
> Security of Static DH
>
> leave aside FS, it is cryptographically secure
>
> FIPS 800-56A talks about using static DH. TLS 1.2 has DHS
>
> concerns
>
> easy to have imp flaws.
>
> but easy to not affect most users.
>
> Harm reduction
>
> enterprises don't adopt 1.3, today they're using 1.2 with static RSA.
>
> make some dramatic changes to endpoints to deliver session keys.
>
> some really really bad ideas (won't go into)
>
> Extensions (open to this)
>
> pros: no significant protocol changes, well-understaood crypto,
> detectability.
>
> Natl Cybersecurity Center of Excellence (Tim Polk)
>
> Sponsor of a related draft.
>
> NCCOE is all about implementation and adoption.
>
> Have been hearing issues with meeting operation reqs for 1.3
>
> Objective is to collab with industry, solve problems and get better security
> than we have today.
>
> NCCoE will produce a proof of concept imp and a number of documents... want
> to prove that we can tighten up the life span of those keys that we are
> sharing in the enterprise.
>
> Would produce an 1800 series practice guide that would say, "if you want to
> do what we did in the imp, do this."
>
> would submit an IETF draft that showed what we did, what worked/did not,
> here are the key liftetimes that we think we can manage.
>
> Proposal DOES NOT violate the IETF policy on wiretapping (Russ Housely)
>
> RFC 2804 defines wiretapping and this is not that.
>
> Want to get as much TLS nowledge from this WG as possible to produce as
> secure a thing as possible.
>
> TINFOIL (Stephen Farrell)
>
> This whole thing is a terrible idea, we shouldn't do it.
>
> Stephen goes through the various arguments listed here:
> https://github.com/sftcd/tinfoil
>
> not in scope for charter
>
> could put TLS/DTLS 1.3 at risk
>
> TLS is hard
>
> 1.3 has undergone significant analysis so far, this has not
>
> Static DH is not implementation robust
>
> we have a case where law enforcement has tried to coerce a server operator
> to tap at TLS level
>
> should in no way be a standards track document.
>
> breaking TLS is not part of the WG charter.
>
> ...
>
> Question to group: should we document these arguments about breaking TLS?
>
> Q&A:
>
> PHB: agree with both sides. Problem here is coming from the PKI world, saw
> what happen to bluecoat and co. We didn't make WebPKI holes for them, so
> they blasted holes into it.
>
> on the techincal side, don't like how you're doing it. I'd use a different
> DH share every time.
>
> would like to have this such that if this makes it into the wild, it is not
> compat with legacy stuff
>
> Paul Woters: want to quote RFC-someting-bis
>
> talking about DH groups 22, 23, 24. 22 is must not. 23 and 24 will be must
> not soon, should not now.
>
> Dan Harkins: there is IPR here out here from a past employer.
>
> DKG: want to express disappointment with this draft.
>
> export cipher suites was brought up. As recently as last year we've had
> problems with the fact that export cipher suites were standardized 20 years
> ago.
>
> The first time we see a problem with this might be soon... the last time we
> see a problem will be way way in the future.
>
> Rich Salz: (applause)
>
> I am torn between: prof. and personally I think this is not a good thing.
> Remember Dave Clarke's talk that we need to tilt the playing field for
> things that people use.
>
> would like to see us wait two years for deployment exp. It's pre-mature.
> Let's revisit.
>
> Darin Pettis:
>
> We've been here before, part of a large financial organization. We've
> ditched RSA, we understand that.
>
> We've explored technical options, and have not find a better way.
>
> Roman from CMU:
>
> didn't see discussion for security uses, esp. DFIR (incident response).
>
> very key to do ad hoc instrumentation and this would help.
>
> [Cisco business security group]:
>
> Don't think security is served by seeing this as a black or white approach.
>
> Reminds me of the old discussion of NATs.
>
> Community is better served by ack'ing this problem and find a way to solve
> it.
>
> Nalini Elkins:
>
> There are very real problems from real people doing real things.
>
> If you are hearing from real people that there are problems, behooves us to
> listen.
>
> mnot:
>
> this is not the first time we've seen this thing.
>
> 2 years ago, proposals strongly made in HTTP.
>
> We chose not to accept that work; reason is that HTTPS is explicitly a
> two-party protocol. Did not have a way to get the informed consent necessary
> to change the protocol.
>
> You are changing the nature of the protocol pretty fundamentally.
>
> Ted Hardie:
>
> two points: FS is a feature of this protocol. This turns it off in certain
> contexts, not obvious to the end users that FS has been removed. Can't tell
> in the first connection if a key will be re-used. Need to have a way with
> features like this about 1) signal that it's being used; and 2) get
> agreements to use it from those communicating.
>
> if it comes back with those changes, what's the domain analysis? Russ read
> us section 3 of RFC 2048, but not section 4, that says, "we're not taking a
> moral stand, but a technical stand". You MUST expect a technology to be used
> in places you might not expect. Analysis must take into account all of the
> domains of us.
>
> Max Pala (cable labs):
>
> agree with Stephen.
>
> Most of the time this is a problem if your arch is outdated. No one will
> force you to do this... if you do deploy 1.3, should be conformant.
>
> Ralph Droms:
>
> Living the dream (laughter)
>
> Want to emphasize keeping separate the fundamental abstract questions that
> are being discussed and the particular proposal that is on the table in this
> document.
>
> Roland Dobbins:
>
> Want to emphasize being able to troubleshoot and need visibility.
>
> Often this needs to be on the wire.
>
> They may face potential fines and liability if they don't take care of our
> information.
>
> We don't want crypto that is proprietary or that is developed in
> smoke-filled rooms.
>
> Jeff Hodges:
>
> want to echo ralph and roland and a few other people.
>
> There are enterprise needs here to do this thing.
>
> We want to get to FS in the data center and we need a migration path that
> has been scrutinized by experts.
>
> Christian Huitema:
>
> want to support Stephen and Ted: take the Lavabit scenario.
>
> A provider of a service is being compelled to turn on a feature so that
> someone can get their traffic.
>
> This approach is very dangerous... you assume that you are using the same
> software in both DCs and on a server.
>
> Don't like the feature that this is keeping the wire format unchanged.
>
> We need a "big red flag" requirement so that this is only used in the DC.
>
> Daniel Franke (Akamai):
>
> like draft-00, not draft-01
>
> draft-01 is standards track, not ok
>
> Kenny Patterson:
>
> There is nothing in the current draft that would force the rotation of keys.
>
> suggestion: adopt the draft and force key rotation on each connection.
>
> Sharon Goldberg (BU)
>
> Want to support Stephen.
>
> Not confied to DCs, do not support at all
>
> Deb Cooley (NSA)
>
> I believe if you take the draft here, you control the draft.
>
> if you let this go underground, it will happen silently like what happened
> in the past with Static RSA.
>
> Tara Tarikyee (OTF)
>
> add voice to those disappointed in this draft.
>
> there are a lot of people that depend on TLS for the practice of those
> rights.
>
> Questions the charis want answered (policy)
>
> The main question: Is this subject something that the WG should consider?
>
> this = "passive decryption of data center traffic"
>
> subquestion: Is this wiretapping?
>
> Clarifying questions:
>
> Stephen Farrell: don't believe that passive is correct here, draft-green
> allows active attacks. Allows the attacker to be active.
>
> Ralph Droms: separate the solution in the draft from the mechanism.
>
> Stephen: A, your saying your draft is broke.
>
> ... not clear to me that there is any solution that allows passive that
> doesn't allow active.
>
> DKG: we have considered this question for many weeks.
>
> Lucy Lynch: take a hum first on whether or not the group should accept the
> draft and then take a more general hum.
>
> Joe S: "decryption of data in the data center" ommiting the word "passive"
>
> Hums: No clarity whatsoever. Seemed pretty even.
>
> Stephen: want to take it to the list as to if the WG is interested in
> documenting reasons to not break 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen


From nobody Fri Jul 21 06:23:24 2017
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 209A11317D5 for ; Fri, 21 Jul 2017 06:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 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=-0.001, 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 MFyprCdrRjG9 for ; Fri, 21 Jul 2017 06:23:21 -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 33BDE12EBF7 for ; Fri, 21 Jul 2017 06:23:21 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C35389782C for ; Fri, 21 Jul 2017 13:23:20 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C35389782C
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C35389782C
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 928528BE20 for ; Fri, 21 Jul 2017 13:23:20 +0000 (UTC)
From: Hubert Kario 
To: tls@ietf.org
Date: Fri, 21 Jul 2017 15:23:13 +0200
Message-ID: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart8341702.FB2rcLZfQP"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 21 Jul 2017 13:23:20 +0000 (UTC)
Archived-At: 
Subject: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 13:23:23 -0000

--nextPart8341702.FB2rcLZfQP
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Signature Algorithms for ECDSA now define both the curve and the hash=20
algorithm:

          ecdsa_secp256r1_sha256(0x0403),
          ecdsa_secp384r1_sha384(0x0503),
          ecdsa_secp521r1_sha512(0x0603),

This is in contrast to the TLS 1.2 protocol, where any hash can be used wit=
h=20
any curve.

There are good reasons for that change:
 - less combinations to test
 - establishes the low water mart for security

I see few problems with that though:
 1). there are not insignificant number of clients that advertise support f=
or=20
      all (at least P-256 and P-384) curves, but don't advertise support fo=
r=20
      hashes stronger than SHA-256 with ECDSA[1]=20
 2). This is inconsistent with RSA-PSS behaviour, where key size is complet=
ely
      detached from the used hash algorithm.
 3). This is not how ECDSA signatures in X.509 work, so it doesn't actually=
=20
      limit the signatures on certificates (in other words, as an implement=
er
      you need to support all hashes with all curves either way)

With the implementers hat on, I'd prefer to drop the curves from signature=
=20
algorithm names/specifications and return to TLS 1.2 behaviour.
With my security hat on, I'd say that we should set the minimal key sizes f=
or=20
RSA-PSS signatures too, as we did with ECDSA.

Any other ideas?


 1 - Nick Sullivan from Cloudflare provided me with some stats from random=
=20
50000 client hellos from early 2017:

Sigalgs:
ECDSA + SHA-256 =3D 39104 (78.2%)
ECDSA + (SHA-256 + SHA-384 + SHA-512) =3D 28678 (57.4%)
ECDSA + (SHA-256 + SHA-384 + !SHA-512) =3D 8934 (17.9%)
ECDSA + (SHA-256 + !SHA-384 + !SHA-512) =3D 1492 (2.98%)

Note: many of the 1492 seem to be on iOS and only support:
[RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]

Curves:
none =3D 757 (1.51%)
P-256 =3D 49243 (98.5%)
P-384 =3D 49233 (98.5%)
P-256 + P-384 =3D 49233 (98.5%)
P-256 + !P-384 =3D 10 (0.02%)
!P-256 + P-384 =3D 0 (0%)
=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 115, 612 00  Brno, Czech Republic
--nextPart8341702.FB2rcLZfQP
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

iQIcBAABCgAGBQJZcgBCAAoJEJKo0bgB0vX1v+IP/1KpW3+i8zmK+QssbavS1DHF
vWUXp7lnE+1y33DBwwC8+bwksrhGXcsfPkzNBl518JSOzUVPs1X+PBZl8wvG23A5
hCiv7jDZse96EV7JX9uKchTyEinioMO4r8uwFywNcY4QaUSiCmblmVHajXGSn/OR
F5DOtvP0yg2oVehLABoeM25+juRTHgv3dcK7XwvPUDzBWgW4/m1RYMfpv/SLVSYc
N57UwPIxDy8y3SRiRu5cSWsWJ90OdaBMwxG+1halbZAC3wMIDFk6iuwjewEgA5eT
eIfDb5xr9NyyU9T9qnwb0Zk2/xcrz29RSzCoTUH4u9Nf/t35XEr0VCSYUrPbAl49
tKek22bA9fKPIWez+CE39L5G81asQZHp4SCN+b23nbejxNPVq8YSq/YZE6Ul1ZSb
lyrOrQ2FJXALE1kU7Kri51F1tANsVNGze47Lok/OTqI5zzwhk+sQo0kigR4KEO0/
K+1fncVrijGVtdlbgciBRmW3SYHtL36EME1+7DL65WkOnmsDq3+3U5Qwy7AkWrqL
WMQ2feLiwiI/XhqXP3xpYQH49lofTYHIFIom+b+q0guFNnTnoWg9QnVlP3I/x2Js
ek9Lt8pyItVsjZPtAYvGJlkfhP3OeE59CioM3anS/1SaLcNf1AYslL9HcLZalhH1
/NA50tklIvWfthVVLfV1
=tkRt
-----END PGP SIGNATURE-----

--nextPart8341702.FB2rcLZfQP--


From nobody Fri Jul 21 06:38:40 2017
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 684BF131DB6 for ; Fri, 21 Jul 2017 06:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 9xNubU47HucX for ; Fri, 21 Jul 2017 06:38:36 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 64EC0131723 for ; Fri, 21 Jul 2017 06:38:36 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6LDXSaJ025536; Fri, 21 Jul 2017 14:38:34 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=yMQkmxF68GE0h7dPxrzPSHSlKeYprHA6gA2UbOtmxcY=; b=J9Y//SZ0teYa5v/iSvT9dcaqU9wcp8+DvtIC41xTCcVx8bLLn7QTXsF4m0fT9HjaFdAg nr2Hy/5CBBUJ9UhJyxh5iwZH13cvm4tmXkcONAMTWrVI2b4ypy6E6waJu8rtwtI25/mx toOCCIOIiIWs1Jv6Z3f+XIXZKjW/xFOXqFB9wYILocVdYt1NpaPfxmtFpJZz8elMXB6i SGfPkaE1Gf1r4vExxmHSnwl+IZmPMUCm1oqK2g+L0RtSe8M/D7HSsWOFxGLJaJL46BKS 9STYzMO9+Emx7HM2qlXtwY16FB999SJT/sNCwYeyGwgRNcrLX/k0h5TyVcC+hFDmR/eX 2g== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2btsmmwp30-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 14:38:33 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6LDUkXL016118; Fri, 21 Jul 2017 09:38:32 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecum96h-1; Fri, 21 Jul 2017 09:38:32 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 684AB1FC72; Fri, 21 Jul 2017 13:38:32 +0000 (GMT)
To: Hubert Kario , tls@ietf.org
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com>
From: Benjamin Kaduk 
Message-ID: <2a648a63-8299-1a9c-776e-f5d043371055@akamai.com>
Date: Fri, 21 Jul 2017 08:38:32 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com>
Content-Type: multipart/alternative; boundary="------------E07E90BF7B1D3EE2D05C7224"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707210213
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210213
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 13:38:38 -0000

This is a multi-part message in MIME format.
--------------E07E90BF7B1D3EE2D05C7224
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/21/2017 08:23 AM, Hubert Kario wrote:
> Signature Algorithms for ECDSA now define both the curve and the hash 
> algorithm:
>
>           ecdsa_secp256r1_sha256(0x0403),
>           ecdsa_secp384r1_sha384(0x0503),
>           ecdsa_secp521r1_sha512(0x0603),
>
> This is in contrast to the TLS 1.2 protocol, where any hash can be used with 
> any curve.

I assume you saw
https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
raised a different question in this same general area.

I do not see how the response here cannot be the same as it was there:
namely, that the current formulation is assumed to have WG consensus,
having been through two WGLCs; there would need to be rather strong
reasons to make changes at this stage.

-Ben


> There are good reasons for that change:
>  - less combinations to test
>  - establishes the low water mart for security
>
> I see few problems with that though:
>  1). there are not insignificant number of clients that advertise support for 
>       all (at least P-256 and P-384) curves, but don't advertise support for 
>       hashes stronger than SHA-256 with ECDSA[1] 
>  2). This is inconsistent with RSA-PSS behaviour, where key size is completely
>       detached from the used hash algorithm.
>  3). This is not how ECDSA signatures in X.509 work, so it doesn't actually 
>       limit the signatures on certificates (in other words, as an implementer
>       you need to support all hashes with all curves either way)
>
> With the implementers hat on, I'd prefer to drop the curves from signature 
> algorithm names/specifications and return to TLS 1.2 behaviour.
> With my security hat on, I'd say that we should set the minimal key sizes for 
> RSA-PSS signatures too, as we did with ECDSA.
>
> Any other ideas?
>
>
>  1 - Nick Sullivan from Cloudflare provided me with some stats from random 
> 50000 client hellos from early 2017:
>
> Sigalgs:
> ECDSA + SHA-256 = 39104 (78.2%)
> ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
> ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
> ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)
>
> Note: many of the 1492 seem to be on iOS and only support:
> [RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]
>
> Curves:
> none = 757 (1.51%)
> P-256 = 49243 (98.5%)
> P-384 = 49233 (98.5%)
> P-256 + P-384 = 49233 (98.5%)
> P-256 + !P-384 = 10 (0.02%)
> !P-256 + P-384 = 0 (0%)
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------E07E90BF7B1D3EE2D05C7224
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 07/21/2017 08:23 AM, Hubert Kario wrote:
    
    
    
      
    Signature Algorithms for ECDSA now define both the curve and the hash 
algorithm:

          ecdsa_secp256r1_sha256(0x0403),
          ecdsa_secp384r1_sha384(0x0503),
          ecdsa_secp521r1_sha512(0x0603),

This is in contrast to the TLS 1.2 protocol, where any hash can be used with 
any curve.

    
    
    
    
    
    I assume you saw
    https://www.ietf.org/mail-archive/web/tls/current/msg23714.html
    which raised a different question in this same general area.
    
    
    
    I do not see how the response here cannot be the same as it was
    there: namely, that the current formulation is assumed to have WG
    consensus, having been through two WGLCs; there would need to be
    rather strong reasons to make changes at this stage.
    
    
    
    -Ben
    
    
    
    
    
    
    
      
    There are good reasons for that change:
 - less combinations to test
 - establishes the low water mart for security

I see few problems with that though:
 1). there are not insignificant number of clients that advertise support for 
      all (at least P-256 and P-384) curves, but don't advertise support for 
      hashes stronger than SHA-256 with ECDSA[1] 
 2). This is inconsistent with RSA-PSS behaviour, where key size is completely
      detached from the used hash algorithm.
 3). This is not how ECDSA signatures in X.509 work, so it doesn't actually 
      limit the signatures on certificates (in other words, as an implementer
      you need to support all hashes with all curves either way)

With the implementers hat on, I'd prefer to drop the curves from signature 
algorithm names/specifications and return to TLS 1.2 behaviour.
With my security hat on, I'd say that we should set the minimal key sizes for 
RSA-PSS signatures too, as we did with ECDSA.

Any other ideas?


 1 - Nick Sullivan from Cloudflare provided me with some stats from random 
50000 client hellos from early 2017:

Sigalgs:
ECDSA + SHA-256 = 39104 (78.2%)
ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)

Note: many of the 1492 seem to be on iOS and only support:
[RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]

Curves:
none = 757 (1.51%)
P-256 = 49243 (98.5%)
P-384 = 49233 (98.5%)
P-256 + P-384 = 49233 (98.5%)
P-256 + !P-384 = 10 (0.02%)
!P-256 + P-384 = 0 (0%)

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

    
    
    
    
    
  


--------------E07E90BF7B1D3EE2D05C7224--


From nobody Fri Jul 21 06:42:02 2017
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 9337D131E16 for ; Fri, 21 Jul 2017 06:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level: 
X-Spam-Status: No, score=-2.609 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, T_HK_NAME_DR=0.01, URIBL_BLOCKED=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 NBC2QxA56gel for ; Fri, 21 Jul 2017 06:41:58 -0700 (PDT)
Received: from claranet-outbound-smtp00.uk.clara.net (claranet-outbound-smtp00.uk.clara.net [195.8.89.33]) by ietfa.amsl.com (Postfix) with ESMTP id 522AB131E09 for ; Fri, 21 Jul 2017 06:41:58 -0700 (PDT)
Received: from host86-161-69-224.range86-161.btcentralplus.com ([86.161.69.224]:46979 helo=[192.168.1.75]) by relay00.mail.eu.clara.net (relay.clara.net [81.171.239.30]:10465) with esmtpa (authdaemon_plain:drh) id 1dYYBl-00046J-0x  for tls@ietf.org (return-path ); Fri, 21 Jul 2017 13:41:54 +0000
To: tls@ietf.org
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com>
From: Dr Stephen Henson 
Message-ID: <20a46494-8fd2-2cbf-556d-070b48056d4d@drh-consultancy.co.uk>
Date: Fri, 21 Jul 2017 14:41:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 13:42:01 -0000

On 21/07/2017 14:23, Hubert Kario wrote:
> Signature Algorithms for ECDSA now define both the curve and the hash 
> algorithm:
> 
> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
> ecdsa_secp521r1_sha512(0x0603),
> 
> This is in contrast to the TLS 1.2 protocol, where any hash can be used
> with any curve.
> 
> There are good reasons for that change: - less combinations to test -
> establishes the low water mart for security
> 
> I see few problems with that though: 1). there are not insignificant number
> of clients that advertise support for all (at least P-256 and P-384)
> curves, but don't advertise support for hashes stronger than SHA-256 with
> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
> completely detached from the used hash algorithm. 3). This is not how ECDSA
> signatures in X.509 work, so it doesn't actually limit the signatures on
> certificates (in other words, as an implementer you need to support all
> hashes with all curves either way)
> 

There is another and significant problem with the change. In TLS 1.2 support
for a curve was indicated in the supported curves extension and it implied
support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
supported groups extension are for ECDH only. Support for a curve for ECDSA is
indicated in the signature algorithms extension.

I agree though that there is an anomaly here. For example AFAICS in
certificates for TLS1.3 you're allowed (with some caveats) to use a
P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
allowed at all. Is that likely to be a problem in practice? Are there many
such certificates about in the wild?

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/


From nobody Fri Jul 21 07:28:07 2017
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 95EB6131A5F for ; Fri, 21 Jul 2017 07:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 y3cQd5FAAONk for ; Fri, 21 Jul 2017 07:27:56 -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 9FA3E131E22 for ; Fri, 21 Jul 2017 07:27:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 062053004CA for ; Fri, 21 Jul 2017 10:27:56 -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 dB3CYw70EIHX for ; Fri, 21 Jul 2017 10:27:52 -0400 (EDT)
Received: from [5.5.33.189] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id EE902300434; Fri, 21 Jul 2017 10:27:50 -0400 (EDT)
From: Russ Housley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C9DC66DE-7428-4A6F-937B-20E78E20CC48"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 21 Jul 2017 10:27:48 -0400
In-Reply-To: 
Cc: Sean Turner , IETF TLS , IETF LURK 
To: Nick Sullivan 
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 14:27:59 -0000

--Apple-Mail=_C9DC66DE-7428-4A6F-937B-20E78E20CC48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Nick:

Thanks for this summary.  This resolves my previous concerns.

Russ


> On Jul 18, 2017, at 7:06 AM, Nick Sullivan =
 wrote:
>=20
> Sean,
>=20
> We've had some additional discussions in person here at IETF 99 with =
folks who were in the proxy certificates and short-lived certs camp, and =
we think there is now more agreement that the mechanism described in =
this draft is superior to the alternatives. I've included a summary of =
some of the pros and cons of the approaches:
>=20
> Proxy certificates vs. Delegated Credentials
> Pro proxy certificates:
> - Already deployed in some industries, though not on the Web.
> - Fits the conceptual model that public key =3D=3D certificate.
> Con proxy certificates:
> - Proxy certificates adds additional complexity to the delegation =
other than limiting the time period (full X.509, additional constraints  =
such as hostname).
> - Encourages implementers to reuse PKIX libraries rather than build =
code as part of TLS:
> -- There have been problems and inconsistencies around pathlen and =
constraints enforcement in existing PKIX libraries.
> -- Modifying these libraries is more complex and risk prone than =
delegated creds (which can easily be implemented in TLS as demonstrated =
by the 3 interoperable implementations at the IETF 98 hackathon).
> - In proxy certificates, pathing is SKI dependent, not directly tied =
to EE cert. This is a binding weaker than delegated credentials which =
includes a signature over the EE certificate.
>=20
> Short-lived certs vs. Delegated Credentials
> Pro short-lived certs:
> - Short lived certs work with existing libraries, no new code changes.
> Con short-lived certs:
> - Not widely available from CAs, especially for EV.
> - Potentially problematic to the CT ecosystem (all certificates must =
be logged in CT, which may bloat them).
> - Introduces a high-risk operational dependency on external party:
> -- Requires frequent exchanges with an external Certificate Authority =
(must provide proof of domain possession to CA vs. internally managed =
credential minter for delegated credentials).
> -- There is no fallback if the CA has outage. With delegated =
credentials you can fall back to a LURK-style protocol with the =
long-lived certificate key.
>=20
> Given these comparisons, we think the proposed draft is the superior =
option and would like to continue the discussion about adopting it.
>=20
> Nick
>=20
> On Fri, May 19, 2017 at 12:58 AM Sean Turner > wrote:
> All,
>=20
> During the WG call for adoption, a couple of questions were raised =
about comparison/analysis of sub-certs versus proxy and/or short-lived =
certificates.  There is some discussion currently in the draft, but the =
chairs feel that these issues need further discussion (and elaboration =
in the draft) prior to WG adoption.  So let=E2=80=99s keep the =
conversation going.
>=20
> J&S
>=20
> > On Apr 12, 2017, at 15:31, Sean Turner > wrote:
> >
> > All,
> >
> > At our IETF 98 session, there was support in the room to adopt =
draft-rescorla-tls-subcerts [0].  We need to confirm this support on the =
list so please let the list know whether you support adoption of the =
draft and are willing to review/comment on the draft before 20170429.  =
If you object to its adoption, please let us know why.
> >
> > Clearly, the WG is going to need to work through the trade-offs =
between short-lived certificates and sub-certs because both seem, to =
some, to be addressing the same problem.
> >
> > Cheers,
> >
> > J&S
> >
> > [0] =
https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts =

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


--Apple-Mail=_C9DC66DE-7428-4A6F-937B-20E78E20CC48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Nick:

    Thanks for this summary.  This resolves my previous =
concerns.

    Russ


    On Jul 18, 2017, at 7:06 AM, Nick Sullivan <nicholas.sullivan@gmail.com> wrote:

    Sean,

    We've had some additional discussions in person here at IETF =
99 with folks who were in the proxy certificates and short-lived certs =
camp, and we think there is now more agreement that the mechanism =
described in this draft is superior to the alternatives. I've included a =
summary of some of the pros and cons of the approaches:

    Proxy certificates vs. Delegated Credentials
    Pro proxy =
certificates:
    - Already deployed in some industries, though not on the =
Web.
    - Fits the conceptual model that public key =3D=3D =
certificate.
    Con proxy =
certificates:
    - Proxy certificates adds additional complexity to the =
delegation other than limiting the time period (full X.509, additional =
constraints  such as hostname).
    - Encourages implementers to reuse PKIX libraries rather than =
build code as part of TLS:
    -- There have been problems and =
inconsistencies around pathlen and constraints enforcement in existing =
PKIX libraries.
    -- Modifying these libraries is more =
complex and risk prone than delegated creds (which can easily be =
implemented in TLS as demonstrated by the 3 interoperable =
implementations at the IETF 98 hackathon).
    - In proxy certificates, pathing is SKI dependent, not =
directly tied to=20
EE cert. This is a binding weaker than delegated credentials which =
includes a=20
signature over the EE certificate.

    Short-lived certs vs. Delegated Credentials
    Pro short-lived =
certs:
    - Short lived certs work with existing libraries, no new code =
changes.
    Con short-lived =
certs:
    - Not widely available from CAs, especially for EV.
    - Potentially problematic to the CT ecosystem (all =
certificates must be logged in CT, which may bloat them).
    - Introduces a high-risk operational dependency on external =
party:
    -- Requires frequent exchanges with an external =
Certificate Authority (must provide proof of domain possession to CA vs. =
internally managed credential minter for delegated credentials).
    -- There is no fallback if the CA has outage. With delegated =
credentials you can fall back to a LURK-style protocol with the =
long-lived certificate key.

    Given these comparisons, we think the =
proposed draft is the superior option and would like to continue the =
discussion about adopting it.

    Nick

    On Fri, May 19, 2017 =
at 12:58 AM Sean Turner <sean@sn3rd.com> wrote:
    All,
    

    
During the WG call for adoption, a couple of questions were raised about =
comparison/analysis of sub-certs versus proxy and/or short-lived =
certificates.  There is some discussion currently in the draft, but =
the chairs feel that these issues need further discussion (and =
elaboration in the draft) prior to WG adoption.  So let=E2=80=99s =
keep the conversation going.
    

    
J&S
    

    
> On Apr 12, 2017, at 15:31, Sean Turner <sean@sn3rd.com> wrote:
    
>
    
> All,
    
>
    
> At our IETF 98 session, there was support in the room to adopt =
draft-rescorla-tls-subcerts [0].  We need to confirm this support =
on the list so please let the list know whether you support adoption of =
the draft and are willing to review/comment on the draft before =
20170429.  If you object to its adoption, please let us know =
why.
    
>
    
> Clearly, the WG is going to need to work through the trade-offs =
between short-lived certificates and sub-certs because both seem, to =
some, to be addressing the same problem.
    
>
    
> Cheers,
    
>
    
> J&S
    
>
    
> [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcer=
ts
    

    
_______________________________________________
    
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=_C9DC66DE-7428-4A6F-937B-20E78E20CC48--


From nobody Fri Jul 21 07:35:15 2017
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 D60DF131E26 for ; Fri, 21 Jul 2017 07:35:07 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DGzF0zJU-TnX for ; Fri, 21 Jul 2017 07:35: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 C86EA131E28 for ; Fri, 21 Jul 2017 07:35:05 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 65612C073D77; Fri, 21 Jul 2017 14:35:05 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 65612C073D77
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 65612C073D77
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0AE0A77524; Fri, 21 Jul 2017 14:35:04 +0000 (UTC)
From: Hubert Kario 
To: Benjamin Kaduk 
Cc: tls@ietf.org
Date: Fri, 21 Jul 2017 16:34:57 +0200
Message-ID: <3673860.07CCjCncdc@pintsize.usersys.redhat.com>
In-Reply-To: <2a648a63-8299-1a9c-776e-f5d043371055@akamai.com>
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <2a648a63-8299-1a9c-776e-f5d043371055@akamai.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2874102.2MQ6dZQO0x"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 21 Jul 2017 14:35:05 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 14:35:08 -0000

--nextPart2874102.2MQ6dZQO0x
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> > Signature Algorithms for ECDSA now define both the curve and the hash
> >=20
> > algorithm:
> >           ecdsa_secp256r1_sha256(0x0403),
> >           ecdsa_secp384r1_sha384(0x0503),
> >           ecdsa_secp521r1_sha512(0x0603),
> >=20
> > This is in contrast to the TLS 1.2 protocol, where any hash can be used
> > with any curve.
>=20
> I assume you saw
> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
> raised a different question in this same general area.
>=20
> I do not see how the response here cannot be the same as it was there:
> namely, that the current formulation is assumed to have WG consensus,
> having been through two WGLCs; there would need to be rather strong
> reasons to make changes at this stage.

MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory (MUST)=
=20
and no word about any of the other two.

given that we already have CAs that use P-384 for signatures. I'd say this =
is=20
a big conflict between theory and practice.

> > There are good reasons for that change:
> >  - less combinations to test
> >  - establishes the low water mart for security
> >=20
> > I see few problems with that though:
> >  1). there are not insignificant number of clients that advertise suppo=
rt
> >  for> =20
> >       all (at least P-256 and P-384) curves, but don't advertise support
> >       for
> >       hashes stronger than SHA-256 with ECDSA[1]
> > =20
> >  2). This is inconsistent with RSA-PSS behaviour, where key size is
> >  completely> =20
> >       detached from the used hash algorithm.
> > =20
> >  3). This is not how ECDSA signatures in X.509 work, so it doesn't
> >  actually
> > =20
> >       limit the signatures on certificates (in other words, as an
> >       implementer
> >       you need to support all hashes with all curves either way)
> >=20
> > With the implementers hat on, I'd prefer to drop the curves from signat=
ure
> > algorithm names/specifications and return to TLS 1.2 behaviour.
> > With my security hat on, I'd say that we should set the minimal key siz=
es
> > for RSA-PSS signatures too, as we did with ECDSA.
> >=20
> > Any other ideas?
> >=20
> >  1 - Nick Sullivan from Cloudflare provided me with some stats from ran=
dom
> >=20
> > 50000 client hellos from early 2017:
> >=20
> > Sigalgs:
> > ECDSA + SHA-256 =3D 39104 (78.2%)
> > ECDSA + (SHA-256 + SHA-384 + SHA-512) =3D 28678 (57.4%)
> > ECDSA + (SHA-256 + SHA-384 + !SHA-512) =3D 8934 (17.9%)
> > ECDSA + (SHA-256 + !SHA-384 + !SHA-512) =3D 1492 (2.98%)
> >=20
> > Note: many of the 1492 seem to be on iOS and only support:
> > [RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]
> >=20
> > Curves:
> > none =3D 757 (1.51%)
> > P-256 =3D 49243 (98.5%)
> > P-384 =3D 49233 (98.5%)
> > P-256 + P-384 =3D 49233 (98.5%)
> > P-256 + !P-384 =3D 10 (0.02%)
> > !P-256 + P-384 =3D 0 (0%)
> >=20
> >=20
> > _______________________________________________
> > 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 115, 612 00  Brno, Czech Republic
--nextPart2874102.2MQ6dZQO0x
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

iQIcBAABCgAGBQJZchERAAoJEJKo0bgB0vX1AnMP/R5TZ7WWbK8cuB6s5V2NnlVg
XiwxUu9frPqMA1PREOWAHvhBYy6JlwNW4EaPYIEjjrEGXJE35sOOSt3Txg1PIav9
SSlEixiLWEcrx6VMdWupX2XeNYcTv5jvL+1GE9+N82Aub53cXXixmDBcRoqPd6d9
yHq61Gm7DsWfAm2CxFxCiXjnNNIDSXmqI2zlzEleB2kiR3BOPWNKnf9LmHPFoBKh
UQvtxoYNzRaFtIvPU3IBXflhnkK8xQGnTZZG35GHh4D+7bTu4FsLseql9GeVSwJ5
hcZUnSkx4ta/ZiGvH132ClKnqZRYnROXK6XU9wm6ZyADFdiCrrCsCb+SrYBrC0mN
BkuyQntPJGsHplX7HNNJR/TQEkvOrEfQLMkHv3RgXiUA3FkXRQqHZDdrlo1MDsKu
MhLpODmvbxgjwNlDS7tnmLtdCVUQ2J02SOvqL3ulcfbrq0zRXbN5brVwU/3t6FL5
s9NjLGZU7AF3vMniHbX1DO7U0MnM60WnPXWSx7Iw9Jhov0sIf5P2Mr6UMzIF29jx
W6gnoJ79zlU1PtBTlDF/UHTFJTmHyy9ZeK09j8loQIs7pXirNhXNL2RKm6E9+WHm
jlZI5lQ37CdqVcJV0C+IUbPBKcSmzTBFa5NJNJQvCl7wBsmMicXIwdAOGo6AUJrT
bvy/hG/xVuTjL5v8Qrfo
=4pyS
-----END PGP SIGNATURE-----

--nextPart2874102.2MQ6dZQO0x--


From nobody Fri Jul 21 08:01:01 2017
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 B257A131892 for ; Fri, 21 Jul 2017 08:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 8ARoONzK5ktY for ; Fri, 21 Jul 2017 08:00:58 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 75C43131771 for ; Fri, 21 Jul 2017 08:00:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C7F6066637 for ; Fri, 21 Jul 2017 18:00:56 +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 W4w9J7KnKNzd for ; Fri, 21 Jul 2017 18:00:56 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 6AE332318 for ; Fri, 21 Jul 2017 18:00:55 +0300 (EEST)
Date: Fri, 21 Jul 2017 18:00:55 +0300
From: Ilari Liusvaara 
To: tls@ietf.org
Message-ID: <20170721150055.7gn2twhlz7ocu7tn@LK-Perkele-VII>
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <20a46494-8fd2-2cbf-556d-070b48056d4d@drh-consultancy.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20a46494-8fd2-2cbf-556d-070b48056d4d@drh-consultancy.co.uk>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 15:01:01 -0000

On Fri, Jul 21, 2017 at 02:41:50PM +0100, Dr Stephen Henson wrote:
> On 21/07/2017 14:23, Hubert Kario wrote:
> > Signature Algorithms for ECDSA now define both the curve and the hash 
> > algorithm:
> > 
> > ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
> > ecdsa_secp521r1_sha512(0x0603),
> > 
> > This is in contrast to the TLS 1.2 protocol, where any hash can be used
> > with any curve.
> > 
> > There are good reasons for that change: - less combinations to test -
> > establishes the low water mart for security
> > 
> > I see few problems with that though: 1). there are not insignificant number
> > of clients that advertise support for all (at least P-256 and P-384)
> > curves, but don't advertise support for hashes stronger than SHA-256 with
> > ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
> > completely detached from the used hash algorithm. 3). This is not how ECDSA
> > signatures in X.509 work, so it doesn't actually limit the signatures on
> > certificates (in other words, as an implementer you need to support all
> > hashes with all curves either way)
> > 
> 
> There is another and significant problem with the change. In TLS 1.2 support
> for a curve was indicated in the supported curves extension and it implied
> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
> supported groups extension are for ECDH only. Support for a curve for ECDSA is
> indicated in the signature algorithms extension.

I suppose some new dual-version TLS 1.2/1.3 libraries might have the
same issue as mine: supported groups is just plain ignored for ECDSA,
and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.

> I agree though that there is an anomaly here. For example AFAICS in
> certificates for TLS1.3 you're allowed (with some caveats) to use a
> P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
> allowed at all. Is that likely to be a problem in practice? Are there many
> such certificates about in the wild?

Actually, P-256+SHA512 is allowed with a caveat, even if the
certificate is not self-signed. And with the same caveat, server can
send a certificate signed with P-256+SHA3-512, despite TLS
codepoint for it having never existed (not many clients can validate it
through).




-Ilari






From nobody Fri Jul 21 09:31:05 2017
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 EA3DD131B71 for ; Fri, 21 Jul 2017 09:31:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 D2q8C_lBEqXU for ; Fri, 21 Jul 2017 09:31:02 -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 78C5D131B5C for ; Fri, 21 Jul 2017 09:31:02 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id w191so12582457wmw.1 for ; Fri, 21 Jul 2017 09:31:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QDRV/4+HV/0kp+DdAC0h+dGeunDvl/jKlGtMr2NccIU=; b=jReFQtLEL6GVXbd62MW/Ki8+6Tq1dFb9EAWJ0AmtVddimtZFuE9CFHR+TQFnqPaf6V oCu3LfurJlZklfJ7kdH/IEzoM7LzrctmIrFB3O/FZgoCI4hXvzylSAQHXF6oYMV+JUpi FiTDqoGYHoe2S+qDZB821WZL8EsvFDsIuLtNI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QDRV/4+HV/0kp+DdAC0h+dGeunDvl/jKlGtMr2NccIU=; b=TtCigKqlPxksE6CdLcbh7xKo46EzVJjQiXzBk9j99OhsYa9ByFSc7esKlbrduEoKNS +fwnvG6dz+6jqGHEyIEShRkf+nZYoVNsRdcLEuGl3Nn9JUYAJmrP4mB0+L/btwE+Mid6 nd2TJm1gEWZdFh1uYL4cSQsF6Km0JvnO12EEvpYgMfpxaksiJXSQbZNa+VaoYvhiI6na Vkr2fnqh6nKzg46IF1bum9Dw1+u8PHyoYPHRhr3n85XyKEtNwMQKdyGdTQZ4Vb6t7VYM 53lZGT1NQQr5lVLpyxldEDuy1EpHxT1oIi9Sr4CTP5XU7CGGHr+w5L5BW8og6mVtNpOP 5ukg==
X-Gm-Message-State: AIVw111+PBI8yTopeAwRuER0fahFqrMq4sNHI+w+Rv0ja0CkW96yUyoE bu0Rg4JEvfPjyKmxWhBak3khD+46tyhh4iY=
X-Received: by 10.28.67.68 with SMTP id q65mr5169661wma.159.1500654661027; Fri, 21 Jul 2017 09:31:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.234.22 with HTTP; Fri, 21 Jul 2017 09:31:00 -0700 (PDT)
In-Reply-To: <20170721150055.7gn2twhlz7ocu7tn@LK-Perkele-VII>
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <20a46494-8fd2-2cbf-556d-070b48056d4d@drh-consultancy.co.uk> <20170721150055.7gn2twhlz7ocu7tn@LK-Perkele-VII>
From: Watson Ladd 
Date: Fri, 21 Jul 2017 09:31:00 -0700
Message-ID: 
To: Ilari Liusvaara 
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0d3c280069360554d66470"
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 16:31:05 -0000

--94eb2c0d3c280069360554d66470
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 21, 2017 at 8:00 AM, Ilari Liusvaara 
wrote:

> On Fri, Jul 21, 2017 at 02:41:50PM +0100, Dr Stephen Henson wrote:
> > On 21/07/2017 14:23, Hubert Kario wrote:
> > > Signature Algorithms for ECDSA now define both the curve and the hash
> > > algorithm:
> > >
> > > ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503),
> > > ecdsa_secp521r1_sha512(0x0603),
> > >
> > > This is in contrast to the TLS 1.2 protocol, where any hash can be used
> > > with any curve.
> > >
> > > There are good reasons for that change: - less combinations to test -
> > > establishes the low water mart for security
> > >
> > > I see few problems with that though: 1). there are not insignificant
> number
> > > of clients that advertise support for all (at least P-256 and P-384)
> > > curves, but don't advertise support for hashes stronger than SHA-256
> with
> > > ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key
> size is
> > > completely detached from the used hash algorithm. 3). This is not how
> ECDSA
> > > signatures in X.509 work, so it doesn't actually limit the signatures
> on
> > > certificates (in other words, as an implementer you need to support all
> > > hashes with all curves either way)
> > >
> >
> > There is another and significant problem with the change. In TLS 1.2
> support
> > for a curve was indicated in the supported curves extension and it
> implied
> > support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
> > supported groups extension are for ECDH only. Support for a curve for
> ECDSA is
> > indicated in the signature algorithms extension.
>
> I suppose some new dual-version TLS 1.2/1.3 libraries might have the
> same issue as mine: supported groups is just plain ignored for ECDSA,
> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
>
> > I agree though that there is an anomaly here. For example AFAICS in
> > certificates for TLS1.3 you're allowed (with some caveats) to use a
> > P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512
> is not
> > allowed at all. Is that likely to be a problem in practice? Are there
> many
> > such certificates about in the wild?
>
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).
>

But this doesn't affect security if i understand the model correctly.

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

--94eb2c0d3c280069360554d66470
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Fri, Jul 21, 2017 at 8:00 AM, Ilari Liusvaara <=
ilariliusvaar=
a@welho.com> wrote:
    On Fri, Jul 21, 2017 at 02:41:50PM +0100, Dr Stephen Henson wrote=
:
    
> On 21/07/2017 14:23, Hubert Kario wrote:
    
> > Signature Algorithms for ECDSA now define both the curve and the =
hash
    
> > algorithm:
    
> >
    
> > ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x050=
3),
    
> > ecdsa_secp521r1_sha512(0x0603),
    
> >
    
> > This is in contrast to the TLS 1.2 protocol, where any hash can b=
e used
    
> > with any curve.
    
> >
    
> > There are good reasons for that change: - less combinations to te=
st -
    
> > establishes the low water mart for security
    
> >
    
> > I see few problems with that though: 1). there are not insignific=
ant number
    
> > of clients that advertise support for all (at least P-256 and P-3=
84)
    
> > curves, but don't advertise support for hashes stronger than =
SHA-256 with
    
> > ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where k=
ey size is
    
> > completely detached from the used hash algorithm. 3). This is not=
 how ECDSA
    
> > signatures in X.509 work, so it doesn't actually limit the si=
gnatures on
    
> > certificates (in other words, as an implementer you need to suppo=
rt all
    
> > hashes with all curves either way)
    
> >
    
>
    
> There is another and significant problem with the change. In TLS 1.2 s=
upport
    
> for a curve was indicated in the supported curves extension and it imp=
lied
    
> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the=

    
> supported groups extension are for ECDH only. Support for a curve for =
ECDSA is
    
> indicated in the signature algorithms extension.
    

    
    I suppose some new dual-version TLS 1.2/1.3 libraries might have the=

    
same issue as mine: supported groups is just plain ignored for ECDSA,
    
and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
    

    
> I agree though that there is an anomaly here. For example AFAICS in
> certificates for TLS1.3 you're allowed (with some caveats) to use =
a
    
> P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512=
 is not
    
> allowed at all. Is that likely to be a problem in practice? Are there =
many
    
> such certificates about in the wild?
    

    
    Actually, P-256+SHA512 is allowed with a caveat, even if the
    
certificate is not self-signed. And with the same caveat, server can
    
send a certificate signed with P-256+SHA3-512, despite TLS
    
codepoint for it having never existed (not many clients can validate it
    
through).

    But this doesn't affect s=
ecurity if i understand the model correctly.
    

    

    

    

    
-Ilari
    


    

    

    

    

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


    

--94eb2c0d3c280069360554d66470--


From nobody Fri Jul 21 10:46:55 2017
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 88DF6131C4E for ; Fri, 21 Jul 2017 10:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 ST3SfDuF79hY for ; Fri, 21 Jul 2017 10:46:51 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4C4C6129B15 for ; Fri, 21 Jul 2017 10:46:51 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6LHgAH3022796; Fri, 21 Jul 2017 18:46:46 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=Fl19w1ILms7yUSCjPNd9753xDAWcN8NRs7SFg5g1BhQ=; b=fdFW0Z9ktYJouX1o9I604TpByzorEjo49jqoUjrHp0WZChsElXTxuv1rt/h9j4tsza6H xFW8jCGbkfbjdxrTV4ypoq8u4viul0LQ40enm6fA1pP/CGatY6UApd5chmgPV8m6saP8 88tz2bnUe4c31ypPI4w3dra0rJGRx/X/osWlWcnU36UnTg983IYlx5K44H5xOiLYUpMb Ga/OFIZsBWLs+Xcj5hHNVWth9XXq9K+ebUxYe4STEDaXbAUpUKS/dkdXODAJGE98QLQN shaTEvhCDIjQIOiz+wR+8etX3cme2Pl8SFj1fwQXHefYIHYM56qtehU4seOlx9N8SAkh pg== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2btxg55g0k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 18:46:46 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6LHk15w014474; Fri, 21 Jul 2017 13:46:46 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bqecvtabc-1; Fri, 21 Jul 2017 13:46:45 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 89D0880061; Fri, 21 Jul 2017 11:46:45 -0600 (MDT)
To: Matt Caswell 
Cc: "tls@ietf.org" 
References:   
From: Benjamin Kaduk 
Message-ID: 
Date: Fri, 21 Jul 2017 12:46:45 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4FD3A4853C92AD717431439D"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707210276
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210275
Archived-At: 
Subject: Re: [TLS] SNI with early data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 17:46:53 -0000

This is a multi-part message in MIME format.
--------------4FD3A4853C92AD717431439D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

I put some proposed tidying in
https://github.com/tlswg/tls13-spec/pull/1061 .

More inline.

On 07/21/2017 05:14 AM, Matt Caswell wrote:
> On 20/07/17 18:10, Benjamin Kaduk wrote:
>> On 07/20/2017 04:51 AM, Matt Caswell wrote:
>>> I note in draft-21 the following text:
>>>
>>>    When clients use a PSK obtained externally to send early data, then
>>>    the following additional information MUST be provisioned to both
>>>    parties:
>>>
>>>    -  The TLS version number for use with this PSK
>>>
>>>    -  The cipher suite for use with this PSK
>>>
>>>    -  The Application-Layer Protocol Negotiation (ALPN) protocol
>>>       [RFC7301], if any is to be used
>>>
>>>    -  The Server Name Indication (SNI), if any is to be used
>> These are in addition to the hash algorithm provisioned with the
>> external psk that is needed for 1-RTT operation, as mentioned somewhat
>> in passing in section 4.2.10
>>
>>> Later it says this:
>>>
>>>    In order to accept early data, the server MUST have accepted a PSK
>>>    cipher suite and selected the first key offered in the client's
>>>    "pre_shared_key" extension.  In addition, it MUST verify that the
>>>    following values are consistent with those negotiated in the
>>>    connection during which the ticket was established.
>>>
>>>    -  The TLS version number and cipher suite.
>>>
>>>    -  The selected ALPN [RFC7301] protocol, if any.
>>>
>>>
>>> The language about "during which the ticket was established" seems to
>>> suggest that the following checks do not apply to an external PSK -
>>> which I don't think is intended. Additionally there does not seem to
>> These values are a subset of those listed above.  I believe this block
>> of text only applies to NST-provisioned PSKs being used for early data,
>> as the previous text applies to external PSKs being used for early
>> data.
> Interesting because I assumed the intention was the opposite. I'm not
> sure why this restriction should only apply to NST-provisioned PSKs.

Because a similar (slightly stronger) restriction already applies to
external PSKs, but is elsewhere in the document?

>
>>  So, since the previous list is a superset, there is no problem
>> caused by this text not applying to external PSKs.
> The earlier text is about what needs to be *provisioned* to both
> parties. This text is about what MUST be verified on the server. I
> think these are two subtly different things. I see no reason to
> exclude SNI from requiring to be verified, nor do I see a reason to

SNI must be verified in order to use the ticket for 1-RTT, which is a
prerequisite for using it for 0-RTT.  That's just covered elsewhere in
the document, and the editor apparently didn't see a need to repeat the
requirement here.

> restrict it to NST PSKs only. Either you MUST do it for both types of
> PSK or you don't need to do it at all. What is the benefit of
> complicating things by providing a partial list that MUST be verified
> for one type of PSK only?

Yes, you MUST do it for both types.  It's just (prior to my pull
request) specified in different parts of the spec, due to how it evolved.

Perhaps this requires my understanding of what it means to "provision a
PSK with associated values", namely, that the given PSK is only defined
for use with those values, and (e.g.) a server that negotiates the use
of that PSK with different value(s) is in violation of the spec.  Maybe
"provisioning a PSK with associated values" can be interpreted
differently, though, but I'm still unclear on what exactly such an
alternate interpretation would be.

> If this block of text is about NST PSKs only then the implication is
> that a server MAY tolerate discrepancies in ALPN for external PSK. At
> least that is the way I read it (although I don't think that was the
> intention).

[I'd just be repeating myself if I added something here.]

>>> be a requirement on the server to check that the SNI is consistent.
>>> So, there is a mandatory requirement for an external PSK to specify
>>> the SNI, but no requirement on the server to check that it is actually
>>> correct. Is this discrepancy intentional?
>>>
>> I'm not sure I fully understand what you are saying.
>> The text says that (for external PSKs) the SNI must be provisioned to
>> both parties, which to me implies that the server must only use the
>> given PSK for early data with the specified SNI.  (That is, that the
>> server has to check.)
> It does not imply that to me. It says it has to be provisioned. That
> fact that NST PSK MUST verify, implies to me that non-NST PSKs may
> tolerate discrepancies.

So ... what does it mean to have it provisioned and then not do anything
with it?  In such an interpretation, the text about needing to provision
those values along with the PSK has no practical effect, making it "dead
code" that should not have been in the spec in the first place.  An
interpretation where that text is not "dead code" seems much more plausible.

-Ben

>> For tickets, the requirement that SNI must match the original connection
>> is mentioned in section 4.6.1 (NewSessionTicket).
> Again...why only for NST PSKs?
>
>> In short ... I don't see any problems here.  Do you still see a problem?
> Yes - given that we have different interpretations of the same text I
> still see a problem. I think it should be a lot more explicit, and
> remove the discrepancies between NST PSKs and external PSKs.
>
> There is another example of this, earlier on in section 4.2.9:
>
> "The parameters for the 0-RTT data (symmetric cipher suite, ALPN
> protocol, etc.) are the same as those which were negotiated in the
> connection which established the PSK."
>
> This implicitly seems to only apply to NST PSKs. Why not external PSKs too?
>
> Matt


--------------4FD3A4853C92AD717431439D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I put some proposed tidying in
    https://github.com/tlswg/tls13-spec/pull/1061 .
    
    
    
    More inline.
    
    
    
    On 07/21/2017 05:14 AM, Matt Caswell wrote:
    
    
    
      
    On 20/07/17 18:10, Benjamin Kaduk wrote:

    
      
    
        
    On 07/20/2017 04:51 AM, Matt Caswell wrote:

    
        
    
          
    I note in draft-21 the following text:

   When clients use a PSK obtained externally to send early data, then
   the following additional information MUST be provisioned to both
   parties:

   -  The TLS version number for use with this PSK

   -  The cipher suite for use with this PSK

   -  The Application-Layer Protocol Negotiation (ALPN) protocol
      [RFC7301], if any is to be used

   -  The Server Name Indication (SNI), if any is to be used

    
        
    
        
    These are in addition to the hash algorithm provisioned with the
external psk that is needed for 1-RTT operation, as mentioned somewhat
in passing in section 4.2.10


    
        
    
          
    Later it says this:

   In order to accept early data, the server MUST have accepted a PSK
   cipher suite and selected the first key offered in the client's
   "pre_shared_key" extension.  In addition, it MUST verify that the
   following values are consistent with those negotiated in the
   connection during which the ticket was established.

   -  The TLS version number and cipher suite.

   -  The selected ALPN [RFC7301] protocol, if any.


The language about "during which the ticket was established" seems to
suggest that the following checks do not apply to an external PSK -
which I don't think is intended. Additionally there does not seem to

    
        
    
        
    These values are a subset of those listed above.  I believe this block
of text only applies to NST-provisioned PSKs being used for early data,
as the previous text applies to external PSKs being used for early
data.

    
      
    
      
    Interesting because I assumed the intention was the opposite. I'm not
sure why this restriction should only apply to NST-provisioned PSKs.

    
    
    
    
    
    Because a similar (slightly stronger) restriction already applies to
    external PSKs, but is elsewhere in the document?
    
    
    
    
    
      
    

    
      
    
        
     So, since the previous list is a superset, there is no problem
caused by this text not applying to external PSKs.

    
      
    
      
    The earlier text is about what needs to be *provisioned* to both
parties. This text is about what MUST be verified on the server. I
think these are two subtly different things. I see no reason to
exclude SNI from requiring to be verified, nor do I see a reason to
    
    
    
    
    
    SNI must be verified in order to use the ticket for 1-RTT, which is
    a prerequisite for using it for 0-RTT.  That's just covered
    elsewhere in the document, and the editor apparently didn't see a
    need to repeat the requirement here.
    
    
    
    
    
      
    restrict it to NST PSKs only. Either you MUST do it for both types of
PSK or you don't need to do it at all. What is the benefit of
complicating things by providing a partial list that MUST be verified
for one type of PSK only?

    
    
    
    
    
    Yes, you MUST do it for both types.  It's just (prior to my pull
    request) specified in different parts of the spec, due to how it
    evolved.
    
    
    
    Perhaps this requires my understanding of what it means to
    "provision a PSK with associated values", namely, that the given PSK
    is only defined for use with those values, and (e.g.) a server that
    negotiates the use of that PSK with different value(s) is in
    violation of the spec.  Maybe "provisioning a PSK with associated
    values" can be interpreted differently, though, but I'm still
    unclear on what exactly such an alternate interpretation would be.
    
    
    
    
    
      
    If this block of text is about NST PSKs only then the implication is
that a server MAY tolerate discrepancies in ALPN for external PSK. At
least that is the way I read it (although I don't think that was the
intention).

    
    
    
    
    
    [I'd just be repeating myself if I added something here.]
    
    
    
    
    
      
    
      
    
        
    
        
    
          
    be a requirement on the server to check that the SNI is consistent.
So, there is a mandatory requirement for an external PSK to specify
the SNI, but no requirement on the server to check that it is actually
correct. Is this discrepancy intentional?


    
        
    
        
    I'm not sure I fully understand what you are saying.
The text says that (for external PSKs) the SNI must be provisioned to
both parties, which to me implies that the server must only use the
given PSK for early data with the specified SNI.  (That is, that the
server has to check.)

    
      
    
      
    It does not imply that to me. It says it has to be provisioned. That
fact that NST PSK MUST verify, implies to me that non-NST PSKs may
tolerate discrepancies.

    
    
    
    
    
    So ... what does it mean to have it provisioned and then not do
    anything with it?  In such an interpretation, the text about needing
    to provision those values along with the PSK has no practical
    effect, making it "dead code" that should not have been in the spec
    in the first place.  An interpretation where that text is not "dead
    code" seems much more plausible.
    
    
    
    -Ben
    
    
    
    
    
      
    
      
    
        
    For tickets, the requirement that SNI must match the original connection
is mentioned in section 4.6.1 (NewSessionTicket).

    
      
    
      
    Again...why only for NST PSKs?


    
      
    
        
    In short ... I don't see any problems here.  Do you still see a problem?

    
      
    
      
    Yes - given that we have different interpretations of the same text I
still see a problem. I think it should be a lot more explicit, and
remove the discrepancies between NST PSKs and external PSKs.

There is another example of this, earlier on in section 4.2.9:

"The parameters for the 0-RTT data (symmetric cipher suite, ALPN
protocol, etc.) are the same as those which were negotiated in the
connection which established the PSK."

This implicitly seems to only apply to NST PSKs. Why not external PSKs too?

Matt

    
    
    
    
    
  


--------------4FD3A4853C92AD717431439D--


From nobody Fri Jul 21 12:37:49 2017
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 5A4861315FE for ; Fri, 21 Jul 2017 12:37:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 J97N4I3go1am for ; Fri, 21 Jul 2017 12:37:45 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 87EEF131B5B for ; Fri, 21 Jul 2017 12:37:45 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6LJb9LH000907; Fri, 21 Jul 2017 20:37:44 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=qVHd1IaicJy4slVMkus77XWwvYKBKdoVjyWidmshtp4=; b=kellTT+63yx8ZQJqFuoejR0r8Qzeu7feYigYgj9v4VImCmpaSkZBwIBl6xrAMzhryHBB uxtmL9ZGG+hW9Ew5JBN4bVVBThS3LR7SK8RF5v40681HR5VfG3qLGmoNkHI2WA0YviFS yLWVByW7jOfMyQhD45T9WkSojey4q1G0yrkEnI2usM1FHJyeYjbPbcPxcLRFYRHTp691 lfhwPWcWljnNNT4gkJOm2Utw9CiaioiATfAQkfcv0eJLMuBGRdfTOpr57Amjl3HkF2Y0 N0nBcCsQF8RKGR053FgK/F08WccuByD5kupnOn6UBw/Dg9p8SQ5CoTF5WQK7PBILtXEk /A== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2bs7vssyfq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 20:37:43 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6LJa6Xp017509; Fri, 21 Jul 2017 15:37:42 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bqecvthu6-1; Fri, 21 Jul 2017 15:37:42 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 82DCB20066; Fri, 21 Jul 2017 13:37:42 -0600 (MDT)
To: Hubert Kario 
Cc: tls@ietf.org
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <2a648a63-8299-1a9c-776e-f5d043371055@akamai.com> <3673860.07CCjCncdc@pintsize.usersys.redhat.com>
From: Benjamin Kaduk 
Message-ID: <6f6bf32f-5c73-9213-969a-2fdf1a4c48a2@akamai.com>
Date: Fri, 21 Jul 2017 14:37:42 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <3673860.07CCjCncdc@pintsize.usersys.redhat.com>
Content-Type: multipart/alternative; boundary="------------E40CB803024DDF1B4E8D1225"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707210306
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210307
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 19:37:47 -0000

This is a multi-part message in MIME format.
--------------E40CB803024DDF1B4E8D1225
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/21/2017 09:34 AM, Hubert Kario wrote:
> On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
>> On 07/21/2017 08:23 AM, Hubert Kario wrote:
>>> Signature Algorithms for ECDSA now define both the curve and the hash
>>>
>>> algorithm:
>>>           ecdsa_secp256r1_sha256(0x0403),
>>>           ecdsa_secp384r1_sha384(0x0503),
>>>           ecdsa_secp521r1_sha512(0x0603),
>>>
>>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
>>> with any curve.
>> I assume you saw
>> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
>> raised a different question in this same general area.
>>
>> I do not see how the response here cannot be the same as it was there:
>> namely, that the current formulation is assumed to have WG consensus,
>> having been through two WGLCs; there would need to be rather strong
>> reasons to make changes at this stage.
> MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory (MUST) 
> and no word about any of the other two.
>
> given that we already have CAs that use P-384 for signatures. I'd say this is 
> a big conflict between theory and practice.
>

I'm afraid I don't understand this remark.  There is the caveat to which
Ilari alludes, that the server can send whatever chain it has, if the
server can't send a chain that complies with the client's
signature_algorithms.  Since certificate validation is assumed to be
largely a function of the PKI library and not really in scope for the
TLS spec itself, this is not particularly problematic.  The other main
usage of the signature_algorithms limits what can be used in
CertificateVerify, which is directly relevant to TLS and depends on the
key attested to in the certificate.  Are you claiming that there are
servers that only possess certificates with p384 keys (i.e., no RSA or
p256 or other fallback cert)?

-Ben

--------------E40CB803024DDF1B4E8D1225
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 07/21/2017 09:34 AM, Hubert Kario wrote:
    
    
    
      
    On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:

    
      
    
        
    On 07/21/2017 08:23 AM, Hubert Kario wrote:

    
        
    
          
    Signature Algorithms for ECDSA now define both the curve and the hash

algorithm:
          ecdsa_secp256r1_sha256(0x0403),
          ecdsa_secp384r1_sha384(0x0503),
          ecdsa_secp521r1_sha512(0x0603),

This is in contrast to the TLS 1.2 protocol, where any hash can be used
with any curve.

    
        
    
        
    I assume you saw
https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
raised a different question in this same general area.

I do not see how the response here cannot be the same as it was there:
namely, that the current formulation is assumed to have WG consensus,
having been through two WGLCs; there would need to be rather strong
reasons to make changes at this stage.

    
      
    
      
    MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory (MUST) 
and no word about any of the other two.

given that we already have CAs that use P-384 for signatures. I'd say this is 
a big conflict between theory and practice.


    
    
    
    
    
    I'm afraid I don't understand this remark.  There is the caveat to
    which Ilari alludes, that the server can send whatever chain it has,
    if the server can't send a chain that complies with the client's
    signature_algorithms.  Since certificate validation is assumed to be
    largely a function of the PKI library and not really in scope for
    the TLS spec itself, this is not particularly problematic.  The
    other main usage of the signature_algorithms limits what can be used
    in CertificateVerify, which is directly relevant to TLS and depends
    on the key attested to in the certificate.  Are you claiming that
    there are servers that only possess certificates with p384 keys
    (i.e., no RSA or p256 or other fallback cert)?
    
    
    
    -Ben
    
  


--------------E40CB803024DDF1B4E8D1225--


From nobody Fri Jul 21 12:46:05 2017
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 EF6FB131B91 for ; Fri, 21 Jul 2017 12:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 W0uXILRxz5dd for ; Fri, 21 Jul 2017 12:46:02 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 6BC80131B6E for ; Fri, 21 Jul 2017 12:46:02 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6LJfwxl021478; Fri, 21 Jul 2017 20:45:58 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=GwDpaTOJNfKJM9iJJWpI7O6jnQ0Kf86yJr3SXXVCGvQ=; b=XNTcYdENU8FI151ZOqzQjfns4wi5MmvBj2U0PT00XPKKrV3nbTx8FBgaB/HUw5CEAtqd ZkL0t6Xv1i4vCFfK7L25x+DCDz+vOkU4YLbnms8LnBT23hLTsRBypHzsb0Vri8MVL9I4 ziJHsAGLOqm61Bscj8mJzNIGxf/ChVX8LWtbPW1nhGFqLhcIOXn4jq6CsjhT+/sQp0w4 jMwiAH4U8hIkCsKQmiE32Au2WaYjU70gITsIHQZ830iRsepDbVwLe5IVX8hJX4qI2AIc XA/jCHm4VE2bsfM6iXFpqYmC1FiMBZa6ot94CG7fc+5Tu0SHs4MMHmFOxoPvBbgQA4s4 uQ== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2btxg55vqw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 20:45:58 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6LJeoIm023675; Fri, 21 Jul 2017 15:45:57 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecv57w5-1; Fri, 21 Jul 2017 15:45:57 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 0B9391FC7E; Fri, 21 Jul 2017 19:45:56 +0000 (GMT)
To: Dr Stephen Henson , tls@ietf.org
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <20a46494-8fd2-2cbf-556d-070b48056d4d@drh-consultancy.co.uk>
From: Dr Benjamin Kaduk 
Message-ID: 
Date: Fri, 21 Jul 2017 14:45:56 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20a46494-8fd2-2cbf-556d-070b48056d4d@drh-consultancy.co.uk>
Content-Type: multipart/alternative; boundary="------------475F490657F2B3A038618E01"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707210308
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210308
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 19:46:04 -0000

This is a multi-part message in MIME format.
--------------475F490657F2B3A038618E01
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
> On 21/07/2017 14:23, Hubert Kario wrote:
>> Signature Algorithms for ECDSA now define both the curve and the hash 
>> algorithm:
>>
>> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
>> ecdsa_secp521r1_sha512(0x0603),
>>
>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
>> with any curve.
>>
>> There are good reasons for that change: - less combinations to test -
>> establishes the low water mart for security
>>
>> I see few problems with that though: 1). there are not insignificant number
>> of clients that advertise support for all (at least P-256 and P-384)
>> curves, but don't advertise support for hashes stronger than SHA-256 with
>> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
>> completely detached from the used hash algorithm. 3). This is not how ECDSA
>> signatures in X.509 work, so it doesn't actually limit the signatures on
>> certificates (in other words, as an implementer you need to support all
>> hashes with all curves either way)
>>
> There is another and significant problem with the change. In TLS 1.2 support
> for a curve was indicated in the supported curves extension and it implied
> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
> supported groups extension are for ECDH only. Support for a curve for ECDSA is
> indicated in the signature algorithms extension.

Could you say a bit more about why you believe this to be a problem?  On
the face of it, it seems that the previous state overloaded a single
field to mean multiple only semi-related things, whereas the new
formulation keeps things more orthogonal and easier to implement in a
modular way.  That is, groups are for key exchange, and signature
algorithms are for signing, and there is no muddy overlap between them.

Thanks,

Ben

--------------475F490657F2B3A038618E01
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
    
    
    
      
    On 21/07/2017 14:23, Hubert Kario wrote:

    
      
    
        
    Signature Algorithms for ECDSA now define both the curve and the hash 
algorithm:

ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
ecdsa_secp521r1_sha512(0x0603),

This is in contrast to the TLS 1.2 protocol, where any hash can be used
with any curve.

There are good reasons for that change: - less combinations to test -
establishes the low water mart for security

I see few problems with that though: 1). there are not insignificant number
of clients that advertise support for all (at least P-256 and P-384)
curves, but don't advertise support for hashes stronger than SHA-256 with
ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
completely detached from the used hash algorithm. 3). This is not how ECDSA
signatures in X.509 work, so it doesn't actually limit the signatures on
certificates (in other words, as an implementer you need to support all
hashes with all curves either way)


    
      
    
      
    There is another and significant problem with the change. In TLS 1.2 support
for a curve was indicated in the supported curves extension and it implied
support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
supported groups extension are for ECDH only. Support for a curve for ECDSA is
indicated in the signature algorithms extension.
    
    
    
    
    
    Could you say a bit more about why you believe this to be a
    problem?  On the face of it, it seems that the previous state
    overloaded a single field to mean multiple only semi-related things,
    whereas the new formulation keeps things more orthogonal and easier
    to implement in a modular way.  That is, groups are for key
    exchange, and signature algorithms are for signing, and there is no
    muddy overlap between them.
    
    
    
    Thanks,
    
    
    
    Ben
    
  


--------------475F490657F2B3A038618E01--


From nobody Fri Jul 21 12:55:27 2017
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 C1768131A62 for ; Fri, 21 Jul 2017 12:55:26 -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, HTML_MESSAGE=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=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 WDMiDG0ilUWe for ; Fri, 21 Jul 2017 12:55:25 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 92AA91296C9 for ; Fri, 21 Jul 2017 12:55:25 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6LJqckk030407 for ; Fri, 21 Jul 2017 20:55:22 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=wSwKY3PRdO0/nFZWcSS5pxR48dQ6bAqhYoUrkSTXrZM=; b=Dgb1r+BL3StMkK5oDPsuCJCW+t1zay9NU4NtDFAunoxImEtQQFeLfJDZ71UTFa0KVx40 1ZLcA0GyI3k/t3/P391VXbH+gftyoVKY6LGiNAq90Oq2s8+vTwCC2Zgs9QJ/d1zW23M9 ZfiszPqmuC1kShG+es0gkdvFszSO6l4EFOqXMaPK5Lw6zd6VOG/fh7+J/tJ96dOlVy/P yhISQGrhZ7oPz/TvBASXy1viZ6e/NVAnPfxg13JuTHQuYqEa78VFU5vZvrlwGqKVQq1/ D9UcmRLLkCFx+lIzwIFcWXoy//H0hlyVpt86cZyik6oO2+6o6uYS9lDsN9X4e7hFsxKO FA== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2btxg55wm1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 21 Jul 2017 20:55:22 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6LJotIh030269 for ; Fri, 21 Jul 2017 15:55:21 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecv58nf-1 for ; Fri, 21 Jul 2017 15:55:21 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 86A4C1FC7E for ; Fri, 21 Jul 2017 19:55:21 +0000 (GMT)
To: tls@ietf.org
References:  <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII>
From: Benjamin Kaduk 
Message-ID: 
Date: Fri, 21 Jul 2017 14:55:21 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII>
Content-Type: multipart/alternative; boundary="------------A838C0B4A68FEDED56F20D8B"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=13 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210310
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=13 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210311
Archived-At: 
Subject: Re: [TLS] draft-ietf-tls-exported-authenticator questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 19:55:27 -0000

This is a multi-part message in MIME format.
--------------A838C0B4A68FEDED56F20D8B
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Unrelated to Ilari's questions, I wonder if we want to say anything
about certificate_request_context values being unique across both in-TLS
post-handshake auth and exported authenticators.

-Ben

--------------A838C0B4A68FEDED56F20D8B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    Unrelated to Ilari's questions, I wonder if we want to say anything
    about certificate_request_context values being unique across both
    in-TLS post-handshake auth and exported authenticators.
    
    
    
    -Ben
    
  


--------------A838C0B4A68FEDED56F20D8B--


From nobody Fri Jul 21 12:58:18 2017
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 4394E129B25 for ; Fri, 21 Jul 2017 12:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01, URIBL_BLOCKED=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 PgcLdfsOuKEd for ; Fri, 21 Jul 2017 12:58:15 -0700 (PDT)
Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1E01296C9 for ; Fri, 21 Jul 2017 12:58:15 -0700 (PDT)
Received: from host86-161-69-224.range86-161.btcentralplus.com ([86.161.69.224]:16224 helo=[192.168.1.75]) by relay02.mail.eu.clara.net (relay.clara.net [81.171.239.32]:10465) with esmtpa (authdaemon_plain:drh) id 1dYe3q-0006qP-9K  (return-path ); Fri, 21 Jul 2017 19:58:08 +0000
To: Dr Benjamin Kaduk , tls@ietf.org
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <20a46494-8fd2-2cbf-556d-070b48056d4d@drh-consultancy.co.uk> 
From: Dr Stephen Henson 
Message-ID: <96e9b9b8-bd22-6898-8a4e-c80a98996e48@drh-consultancy.co.uk>
Date: Fri, 21 Jul 2017 20:58:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 19:58:17 -0000

-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/
On 21/07/2017 20:45, Dr Benjamin Kaduk wrote:
> On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
>> On 21/07/2017 14:23, Hubert Kario wrote:
>>> Signature Algorithms for ECDSA now define both the curve and the hash 
>>> algorithm:
>>>
>>> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
>>> ecdsa_secp521r1_sha512(0x0603),
>>>
>>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
>>> with any curve.
>>>
>>> There are good reasons for that change: - less combinations to test -
>>> establishes the low water mart for security
>>>
>>> I see few problems with that though: 1). there are not insignificant number
>>> of clients that advertise support for all (at least P-256 and P-384)
>>> curves, but don't advertise support for hashes stronger than SHA-256 with
>>> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
>>> completely detached from the used hash algorithm. 3). This is not how ECDSA
>>> signatures in X.509 work, so it doesn't actually limit the signatures on
>>> certificates (in other words, as an implementer you need to support all
>>> hashes with all curves either way)
>>>
>> There is another and significant problem with the change. In TLS 1.2 support
>> for a curve was indicated in the supported curves extension and it implied
>> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
>> supported groups extension are for ECDH only. Support for a curve for ECDSA is
>> indicated in the signature algorithms extension.
> 
> Could you say a bit more about why you believe this to be a problem?  On the
> face of it, it seems that the previous state overloaded a single field to mean
> multiple only semi-related things, whereas the new formulation keeps things more
> orthogonal and easier to implement in a modular way.  That is, groups are for
> key exchange, and signature algorithms are for signing, and there is no muddy
> overlap between them.
> 

I didn't mean there was a problem with the current spec, I meant there was a
problem with the proposed change: i.e. to remove the curve requirement from
signature algorithms.

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/


From nobody Fri Jul 21 13:21:18 2017
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 C0910124E15 for ; Fri, 21 Jul 2017 13:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01, URIBL_BLOCKED=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 7wXZI91FAlDE for ; Fri, 21 Jul 2017 13:21:15 -0700 (PDT)
Received: from claranet-outbound-smtp08.uk.clara.net (claranet-outbound-smtp08.uk.clara.net [195.8.89.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2085312009C for ; Fri, 21 Jul 2017 13:21:15 -0700 (PDT)
Received: from host86-161-69-224.range86-161.btcentralplus.com ([86.161.69.224]:25438 helo=[192.168.1.75]) by relay08.mail.eu.clara.net (relay.clara.net [81.171.239.38]:10465) with esmtpa (authdaemon_plain:drh) id 1dYeQB-0000xY-SB  for tls@ietf.org (return-path ); Fri, 21 Jul 2017 20:21:13 +0000
To: tls@ietf.org
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <20a46494-8fd2-2cbf-556d-070b48056d4d@drh-consultancy.co.uk> <20170721150055.7gn2twhlz7ocu7tn@LK-Perkele-VII>
From: Dr Stephen Henson 
Message-ID: <5a5ec21c-5b8a-08d9-dfb1-cd78d3054339@drh-consultancy.co.uk>
Date: Fri, 21 Jul 2017 21:21:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170721150055.7gn2twhlz7ocu7tn@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 21 Jul 2017 20:21:17 -0000

On 21/07/2017 16:00, Ilari Liusvaara wrote:
> 
> I suppose some new dual-version TLS 1.2/1.3 libraries might have the
> same issue as mine: supported groups is just plain ignored for ECDSA,
> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
> 

That is potentially a problem yes.

Suppose a server has an EE certificate with a P-256 public key and the client
preference order is ecdsa_secp384r1_sha384, ecdsa_secp256r1_sha256. For TLS 1.3
it will use ecdsa_secp256r1_sha256 and sign TLS messages using P-256+SHA256.

In TLS 1.2 the same preference list means sha384+ecdsa, sha256+ecdsa without the
curve restriction. In this case the server might sign the message using
P-256+SHA384 because the client prefers it. That isn't allowed in TLS 1.3 but is
in TLS 1.2. A client which enforces the TLS 1.3 signature algorithm rules for
TLS 1.2 might abort the connection at that point.

>> I agree though that there is an anomaly here. For example AFAICS in
>> certificates for TLS1.3 you're allowed (with some caveats) to use a
>> P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
>> allowed at all. Is that likely to be a problem in practice? Are there many
>> such certificates about in the wild?
> 
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).
> 

Yes you're right, the caveat of not otherwise having any suitable chain allows
that case.

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/


From nobody Fri Jul 21 22:17:12 2017
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 BEDFA129ACD for ; Fri, 21 Jul 2017 22:17:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ft1vvpJIxwOS for ; Fri, 21 Jul 2017 22:17:09 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 16C351294A2 for ; Fri, 21 Jul 2017 22:17:09 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id s4so36198025pgr.5 for ; Fri, 21 Jul 2017 22:17:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RTCCr7Om4mRsZKrFtcUDWx4jOMUYSvGnUjwfJnz/R4g=; b=XexCv3NN03A4PyTGnK1U5p6g2kaVsYvdpsuCxSUNuPEEtjElX2ZchbKq3ZElPeb0js cI+CCpeO16FfGLV0K6L11xBnzJ7pIqcyuqVts+aj7U5Lzx+86VUTYm8vfLNN4fPDvbsz uvIuP7gRfjzRCpB9kSgBMo7UKSnd2ZMcyegap+W9gCUwkgvmpkf4VhHHBmBKCBM4RuzY YUULCKH/DYhMYYktNjFcYHaNOTH7laMB/R7G+J6TkWLIQTbTRbce402bg5EliMAMO8X4 lyJak+ma8SrXDoWgs4cSwrlftYyKyeTzPjO/ynAUgVVwsXJSz+sto3ermYZQQhlHct1p AIpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RTCCr7Om4mRsZKrFtcUDWx4jOMUYSvGnUjwfJnz/R4g=; b=cUD/rf72/iUGWeE0+0cRR1kywjLr9IEQjsf1Dv8iu8Mvot17/oy3moiScDb/7WpUyi JA0AzWRu5L1YGVwMEoonsOg682dfEm6OZ1tkVFt+b8N59hA86WANW18tuP2mZj2cDp4f sYjnbIbmOHBtFefV/xQTFb0ayqTN4ejrMCMDPUUop1WqQAOyvXjV4SpWws5sWYSw1QBF CgvxpihbFdQYqlOWjiBSN8Z9EzgtHtFdgULAwfYTpx//l2nLZEqRbTj3DQuQ+sxJZlNo UqStmNsKPm5wCQevhXtJv46JByjp57dtuciR5bOYaU29X8ShlverpRDWPhHHdhlXHSxn RK6A==
X-Gm-Message-State: AIVw1124XApX8xQHdNrZID0bKsgdEDyuZ4mtvCW8jyk6ochUpFd3OyDS alVMRLc1uEtyDydNQFTOj+zLCKmTCBfP
X-Received: by 10.99.142.73 with SMTP id k70mr9457826pge.86.1500700628720; Fri, 21 Jul 2017 22:17:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Fri, 21 Jul 2017 22:17:08 -0700 (PDT)
In-Reply-To: 
References:  <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII> 
From: Watson Ladd 
Date: Fri, 21 Jul 2017 22:17:08 -0700
Message-ID: 
To: Benjamin Kaduk 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] draft-ietf-tls-exported-authenticator questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 22 Jul 2017 05:17:11 -0000

On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk  wrote:
> Unrelated to Ilari's questions, I wonder if we want to say anything about
> certificate_request_context values being unique across both in-TLS
> post-handshake auth and exported authenticators.

This context is not a security sensitive thing: it is for disambiguation.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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


From nobody Fri Jul 21 22:35:04 2017
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 C0A681294A2 for ; Fri, 21 Jul 2017 22:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 AcjivgqAIykp for ; Fri, 21 Jul 2017 22:35:00 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id A191E126D85 for ; Fri, 21 Jul 2017 22:35:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 1FDC139E4E; Sat, 22 Jul 2017 08:34:59 +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 Idfy8uF-dVvc; Sat, 22 Jul 2017 08:34:58 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D412D2313; Sat, 22 Jul 2017 08:34:54 +0300 (EEST)
Date: Sat, 22 Jul 2017 08:34:54 +0300
From: Ilari Liusvaara 
To: Watson Ladd 
Cc: Benjamin Kaduk , "tls@ietf.org" 
Message-ID: <20170722053454.5tvj52zpknbq2bqr@LK-Perkele-VII>
References:  <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII>  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] draft-ietf-tls-exported-authenticator questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 22 Jul 2017 05:35:03 -0000

On Fri, Jul 21, 2017 at 10:17:08PM -0700, Watson Ladd wrote:
> On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk  wrote:
> > Unrelated to Ilari's questions, I wonder if we want to say anything about
> > certificate_request_context values being unique across both in-TLS
> > post-handshake auth and exported authenticators.
> 
> This context is not a security sensitive thing: it is for disambiguation.

I'm not so sure about that.

If crc is repeated within a connection, then the old certificate
message can be replayed.

If crc is guessed, then reply can be pregenerated anytime during
connection.

However, neither seems crticial, but might be of magnitude to note.


-Ilari


From nobody Fri Jul 21 22:42:11 2017
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 63B4A1274D2 for ; Fri, 21 Jul 2017 22:42:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 L-s9DDAvioNB for ; Fri, 21 Jul 2017 22:42:09 -0700 (PDT)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 34AD8126D85 for ; Fri, 21 Jul 2017 22:42:09 -0700 (PDT)
Received: by mail-pg0-x232.google.com with SMTP id v190so36460830pgv.2 for ; Fri, 21 Jul 2017 22:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X8h8YeGbQIgHC1UwWS3/jQyIfQdA8cGXMd/BGd10900=; b=ow1KTghJehoy/szjpTsZv+XHjz6cMpiBP6ax6rfWRK2emqhGmc3viv0bKLLb/1EjiD 4DQT749rQjJbi4XuWrdxSEt4J7JWO/ue1zR9Jh2t8Ph8JM/UbBx0Kbr5VrHhoB0TusBQ YYktvikxUwW1pK7CX6Q78R1+U51K/rjZpE8UL6sGSOxBWHkistQv6+G3pofHFzp1Fg5h gDi6+RFp47O0l8rmNrLToRM9suYW8JpcOjfGtDwjHK+t8PwYaSWHb5/I7nuKlpYFXAi5 /pYC35YIU7LOUjXR1yss2IENmxtYIJXSoCgfuTgogMVnMNLsXGDATK8uXO3B0LSM42qu oWqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X8h8YeGbQIgHC1UwWS3/jQyIfQdA8cGXMd/BGd10900=; b=HvAJTSHpM12QBeTyKqyoaTQlCVrl1uZ171QBQdwWOOJwOuHNPPaG+NHmXlhTkMHw1L wCCqjwvzj4Ul6rEmjNRKIINf5Kt4qoJmyMZWv6BL000hWbNJe8N1tIchWWjsUOBRKv0e 6sN/ZS5e82eDpyTOJeNc9arI9CcmugWRFU+cTd7Z1RIIsjvdza/5+GjQ/vBvAoPKxa/3 wjFgJFjAy9cJfPMCHDVIm0O0mAaRa7JzsoHO7dLXL/9nYZ6nZOqYwGeiKPfISuvL+nzF FlBk+Rc5EJ6ePkZdYjo5mjiFLSFWkPn/UoGtmorFmi3GnU+vzj21KP0mMDFQTV6jMsCa DOzw==
X-Gm-Message-State: AIVw111kLx8CDtbdvRA4SZOr1PUtqIwS2lc0ddDZiHJEc124ng6sJ604 dm61XVKOVKFVFn3SVwLF4OasvobxRdcZ
X-Received: by 10.99.114.73 with SMTP id c9mr9648711pgn.267.1500702128858; Fri, 21 Jul 2017 22:42:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Fri, 21 Jul 2017 22:42:08 -0700 (PDT)
In-Reply-To: <20170722053454.5tvj52zpknbq2bqr@LK-Perkele-VII>
References:  <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII>   <20170722053454.5tvj52zpknbq2bqr@LK-Perkele-VII>
From: Watson Ladd 
Date: Fri, 21 Jul 2017 22:42:08 -0700
Message-ID: 
To: Ilari Liusvaara 
Cc: Benjamin Kaduk , "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] draft-ietf-tls-exported-authenticator questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 22 Jul 2017 05:42:10 -0000

On Fri, Jul 21, 2017 at 10:34 PM, Ilari Liusvaara
 wrote:
> On Fri, Jul 21, 2017 at 10:17:08PM -0700, Watson Ladd wrote:
>> On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk  wrote:
>> > Unrelated to Ilari's questions, I wonder if we want to say anything about
>> > certificate_request_context values being unique across both in-TLS
>> > post-handshake auth and exported authenticators.
>>
>> This context is not a security sensitive thing: it is for disambiguation.
>
> I'm not so sure about that.
>
> If crc is repeated within a connection, then the old certificate
> message can be replayed.
>
> If crc is guessed, then reply can be pregenerated anytime during
> connection.
>
> However, neither seems crticial, but might be of magnitude to note.

Yes, if we want  freshness then we need a challenge-response protocol.
I don't recall if the H2 draft does.

>
>
> -Ilari



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


From nobody Sat Jul 22 01:13:55 2017
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 543B8131C4F for ; Sat, 22 Jul 2017 01:13:54 -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 0clyNyvRqULu for ; Sat, 22 Jul 2017 01:13:53 -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 1A8B612783A for ; Sat, 22 Jul 2017 01:13:53 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id q2so29189945ioe.3 for ; Sat, 22 Jul 2017 01:13:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cKhr1sZoIxRtcohBtGMuZqWLvhPmJfJWg921JSk5e6o=; b=QkmU2OXy/Ny0GUn8kTbW+hTUt+2e8qeT74ePfdRgaI25MDSt4dch/ohEa+y3oY5qdS WEl++S74H7imVQYwoeVU6ahn5TpeBYYHnscbPXqBkSB+0ijPU35kzUH1pMHBMRGEUmd8 JqQCUOYCv96VToTXbRCIIxKlZyjYO/67iTfiHUKiOOU8r9IQJN2Yo6DfVSYZ7Umt1tDT oT5bpOso9YGDugfSzqnO5F/ticj9erD7JHPoknRu1khWHuHE2/KukHnHHeU7p5FGGuXc ZVPG90fdGRaJX4pcgpLeT1q9Z9EDrxMHr8Ci5t5xeY/Lzy2fc+uSZCjz3zQ95Qepuu77 Y+3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cKhr1sZoIxRtcohBtGMuZqWLvhPmJfJWg921JSk5e6o=; b=KQxUzAZMYUiB3nXwUESc56PXYyXdN6NyZFJv15SxeYx0OlsuMa2PfIzy4XYfho4TiL 1BuT3dqTi3RxrsjvoHM4cZxG1k08tuVghld8Abqys+z34pY9ojDBS1IeZH1F+MleJehL pytREYxGJq5zwPfK8bWRcRnOl+Ayv8I88AAwg8goT1qld+Ux0KNImMx9wJeZZMQyHUh8 /vAHvy/BPetXeiAMzvCxzS7AM7M4wHwd6NFeTtheh8Ge9l1Y5CyrgYQzszV27oSMfIkV 4ttnJWZs2UrqjXn3+a5lTj7riXqf7os+ekTMEpC2sHcIkhapCXTsrUALhb1bfkmtcK/X qD0Q==
X-Gm-Message-State: AIVw113oOSrNB1PdjAePZUxmRlMVFiiqNYYUjl17lHrJ06VMQo5/jpcU 9rOYZh8vZpsVxckjLA6mA0cqohfFuA==
X-Received: by 10.107.179.135 with SMTP id c129mr10681763iof.74.1500711232427;  Sat, 22 Jul 2017 01:13:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.26 with HTTP; Sat, 22 Jul 2017 01:13:51 -0700 (PDT)
In-Reply-To: 
References:  <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII>   <20170722053454.5tvj52zpknbq2bqr@LK-Perkele-VII> 
From: Martin Thomson 
Date: Sat, 22 Jul 2017 10:13:51 +0200
Message-ID: 
To: Watson Ladd 
Cc: Ilari Liusvaara , "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] draft-ietf-tls-exported-authenticator questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 22 Jul 2017 08:13:54 -0000

On 22 July 2017 at 07:42, Watson Ladd  wrote:
>> If crc is repeated within a connection, then the old certificate
>> message can be replayed.
>>
>> If crc is guessed, then reply can be pregenerated anytime during
>> connection.
>>
>> However, neither seems crticial, but might be of magnitude to note.
>
> Yes, if we want  freshness then we need a challenge-response protocol.
> I don't recall if the H2 draft does.

It cannot.

The question is whether freshness regarding the request is necessary,
or whether it is just freshness with respect to connection that we
need.  That is, was the response generated for this connection, or was
it generated in response to a specific request.  I think that a
binding to the connection is sufficient.

In terms of use cases, the current design is a much better fit.  It
allows for spontaneous assertions of identity rather than requiring a
request/response exchange.

If we need request/response - which I don't think we do - then that
should be integral to this mechanism.  I don't want to rely on the
using protocol doing the right thing.


From nobody Sun Jul 23 00:02:50 2017
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 102B5131C3A for ; Sun, 23 Jul 2017 00:02:48 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 r_QU-Lq8llcC for ; Sun, 23 Jul 2017 00:02:46 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id C252F12741D for ; Sun, 23 Jul 2017 00:02:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 07F6637710; Sun, 23 Jul 2017 10:02:43 +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 kJ7K5OXLtIjT; Sun, 23 Jul 2017 10:02:42 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id ADA662316; Sun, 23 Jul 2017 10:02:40 +0300 (EEST)
Date: Sun, 23 Jul 2017 10:02:40 +0300
From: Ilari Liusvaara 
To: "Blumenthal, Uri - 0553 - MITLL" 
Cc: "" 
Message-ID: <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 07:02:48 -0000

On Thu, Jul 20, 2017 at 08:42:10PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> On 7/20/17, 16:32, "ilariliusvaara@welho.com on behalf of Ilari Liusvaara"  wrote:
> > Maybe we are better off just retrofitting RSA-key-transport back
>     > into TLS-1.3? 
>     
>     This has in fact been requested. Kenny Paterson said about the request:
>      -----------------------------------------------------------------------
>     My view concerning your request: no. 
>     Rationale: We're trying to build a more secure internet.
> 
> My rationale to resurrect it: others are trying to push TLS-1.3 into
> an invisibly-insecure state. If we must satisfy them (and I’m not at
> all sure we should), then this is the most obvious way to at least
> avoid the “insecurity†being silently pushed upon you. At the very
> least you’d have an option to continue under surveillance or abort
> connection. 

This isn't just matter of what is considered "secure enough" to
include. There are fundamential technical constraints that prevent
adding static RSA back.

Early on, there were all sorts of really fundamential decisions on how
TLS 1.3 works. The results of these decisions are baked deeply in the
protocol, and are extremely hard to change. These decisions were
already very apparent in draft-02, over 3 years ago, despite -02 being
unimplementable.

One implication of those assumptions is that any asymmetric key
exchange in TLS 1.3 is at least potentially forward secure[1] (the
actual constraints on asymmetric key exchanges are even stronger
than that, but this weaker version suffices here). Static RSA is not
even potentially forward-secure, so it can not be added.

If you try to add back RSA using the most straightforward method,
what you get is not an analog of static RSA from TLS 1.2. The result
would be closer to RSA_EXPORT from TLS 1.0.


On the other hand, there is no way to construct a key exchange that is
always forward-secure. Either endpoint can always act in a way that
destroys forward-security (even without leaking any per-connection
information), but can not be detected (DH share reuse is considered
detectable) by the other end.


[1] "potentially forward secure" means that there exists interoperating
client and server implementations, so that the key exchange is forward-
secure.


-Ilari


From nobody Sun Jul 23 05:43:42 2017
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 DD8C1129AE7 for ; Sun, 23 Jul 2017 05:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 dIPodEBUeu3U for ; Sun, 23 Jul 2017 05:43:37 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 40F6B129AA8 for ; Sun, 23 Jul 2017 05:43:36 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6NChZK0025273; Sun, 23 Jul 2017 08:43:35 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Ilari Liusvaara 
CC: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB0GJJTXEJ9Nke26Xc5y2RlZKJbn/KAgAAClACAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB/KoCAAASqgIAACjOAgAAC6wCAAJbcgIAAAy8AgAADmACAADBYAP//wM6AgABH+AD//7+cAIAEFRUAgABfPoA=
Date: Sun, 23 Jul 2017 12:43:34 +0000
Message-ID: 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>
In-Reply-To: <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; boundary="Apple-Mail-188BDBAB-6538-4A33-B1D8-046571304AA3"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-23_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707230199
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 12:43:40 -0000

--Apple-Mail-188BDBAB-6538-4A33-B1D8-046571304AA3
Content-Type: text/plain;
	charset=windows-1251
Content-Transfer-Encoding: base64

SWxhcmksDQoNCkkgZ290IHlvdXIgcG9pbnQuDQoNCkJ1dCBpbiB2aWV3IG9mIHRoZSByZXF1ZXN0
IHRoaXMgV0cgaXMgZGlzY3Vzc2luZyBub3csIEkgc2VlIG9ubHkgdHdvIHJlYXNvbmFibGUgKElN
SE8pIG9waW5pb246IA0KMS4gVGVsbCB0aG9zZSByZXF1ZXN0b3JzIHRvIGdvIGF3YXkgYmVjYXVz
ZSBUTFMgMS4zIGhhcyBiZWVuIGRlc2lnbmVkIHRvIGFsd2F5cyBiZSBmb3J3YXJkLXNlY3VyZTsg
b3IgDQoyLiBBZGQgYSAqZGV0ZWN0YWJsZSogbm9uLVBGUyBrZXkgZXhjaGFuZ2Ugc28gdGhvc2Ug
cmVxdWVzdG9ycyB3b3VsZCBoYXZlIHNvbWV0aGluZyB0aGV5IGNhbiBsaXZlIHdpdGgsIGFuZCB0
aGUgcmVzdCBvZiB1cyBjb3VsZCBhdCBsZWFzdCBhZ3JlZSBvciBkaXNhZ3JlZSB0byBhIG5vbi1Q
RlMgc2Vzc2lvbiBlc3RhYmxpc2htZW50IG9uIGEgcGVyLXNlc3Npb24gb3IgYSBwZXItZW50aXR5
IGJhc2lzLiANCg0KSSBkbyBub3Qga25vdyB3aGF0IG1lY2hhbmlzbSBjb3VsZCBkbyB0aGUgbGF0
dGVyLCBvciBvZmYgaXQgZXZlbiBleGlzdHMuIEJ1dCBmb2xkaW5nIGFuIFJTQSBtZXRob2QgaW4g
c2VlbXMgdG8gZG8gdGhlIGpvYi4gSSdkIHNheSBpdCdzIGZpbmUgaWYgaXQgYm9ycm93cyBmcm9t
IDEuMCwgYXMgaXQgaXNuJ3QgZ29pbmcgdG8gYmUgdGhlIG1vc3Qgc2VjdXJlIHNldHRpbmcgYW55
d2F5Lg0KDQpSZWdhcmRzLA0KVXJpDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiBPbiBKdWwg
MjMsIDIwMTcsIGF0IDAzOjAyLCBJbGFyaSBMaXVzdmFhcmEgPGlsYXJpbGl1c3ZhYXJhQHdlbGhv
LmNvbT4gd3JvdGU6DQo+IA0KPj4gT24gVGh1LCBKdWwgMjAsIDIwMTcgYXQgMDg6NDI6MTBQTSAr
MDAwMCwgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMIHdyb3RlOg0KPj4+IE9uIDcvMjAv
MTcsIDE2OjMyLCAiaWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tIG9uIGJlaGFsZiBvZiBJbGFyaSBM
aXVzdmFhcmEiIDxpbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20+IHdyb3RlOg0KPj4+IE1heWJlIHdl
IGFyZSBiZXR0ZXIgb2ZmIGp1c3QgcmV0cm9maXR0aW5nIFJTQS1rZXktdHJhbnNwb3J0IGJhY2sN
Cj4+PiBpbnRvIFRMUy0xLjM/IA0KPj4gDQo+PiAgICBUaGlzIGhhcyBpbiBmYWN0IGJlZW4gcmVx
dWVzdGVkLiBLZW5ueSBQYXRlcnNvbiBzYWlkIGFib3V0IHRoZSByZXF1ZXN0Og0KPj4gICAgIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+PiAgICBNeSB2aWV3IGNvbmNlcm5pbmcgeW91ciByZXF1ZXN0OiBuby4g
DQo+PiAgICBSYXRpb25hbGU6IFdlJ3JlIHRyeWluZyB0byBidWlsZCBhIG1vcmUgc2VjdXJlIGlu
dGVybmV0Lg0KPj4gDQo+PiBNeSByYXRpb25hbGUgdG8gcmVzdXJyZWN0IGl0OiBvdGhlcnMgYXJl
IHRyeWluZyB0byBwdXNoIFRMUy0xLjMgaW50bw0KPj4gYW4gaW52aXNpYmx5LWluc2VjdXJlIHN0
YXRlLiBJZiB3ZSBtdXN0IHNhdGlzZnkgdGhlbSAoYW5kIEmSbSBub3QgYXQNCj4+IGFsbCBzdXJl
IHdlIHNob3VsZCksIHRoZW4gdGhpcyBpcyB0aGUgbW9zdCBvYnZpb3VzIHdheSB0byBhdCBsZWFz
dA0KPj4gYXZvaWQgdGhlIJNpbnNlY3VyaXR5lCBiZWluZyBzaWxlbnRseSBwdXNoZWQgdXBvbiB5
b3UuIEF0IHRoZSB2ZXJ5DQo+PiBsZWFzdCB5b3WSZCBoYXZlIGFuIG9wdGlvbiB0byBjb250aW51
ZSB1bmRlciBzdXJ2ZWlsbGFuY2Ugb3IgYWJvcnQNCj4+IGNvbm5lY3Rpb24uIA0KPiANCj4gVGhp
cyBpc24ndCBqdXN0IG1hdHRlciBvZiB3aGF0IGlzIGNvbnNpZGVyZWQgInNlY3VyZSBlbm91Z2gi
IHRvDQo+IGluY2x1ZGUuIFRoZXJlIGFyZSBmdW5kYW1lbnRpYWwgdGVjaG5pY2FsIGNvbnN0cmFp
bnRzIHRoYXQgcHJldmVudA0KPiBhZGRpbmcgc3RhdGljIFJTQSBiYWNrLg0KPiANCj4gRWFybHkg
b24sIHRoZXJlIHdlcmUgYWxsIHNvcnRzIG9mIHJlYWxseSBmdW5kYW1lbnRpYWwgZGVjaXNpb25z
IG9uIGhvdw0KPiBUTFMgMS4zIHdvcmtzLiBUaGUgcmVzdWx0cyBvZiB0aGVzZSBkZWNpc2lvbnMg
YXJlIGJha2VkIGRlZXBseSBpbiB0aGUNCj4gcHJvdG9jb2wsIGFuZCBhcmUgZXh0cmVtZWx5IGhh
cmQgdG8gY2hhbmdlLiBUaGVzZSBkZWNpc2lvbnMgd2VyZQ0KPiBhbHJlYWR5IHZlcnkgYXBwYXJl
bnQgaW4gZHJhZnQtMDIsIG92ZXIgMyB5ZWFycyBhZ28sIGRlc3BpdGUgLTAyIGJlaW5nDQo+IHVu
aW1wbGVtZW50YWJsZS4NCj4gDQo+IE9uZSBpbXBsaWNhdGlvbiBvZiB0aG9zZSBhc3N1bXB0aW9u
cyBpcyB0aGF0IGFueSBhc3ltbWV0cmljIGtleQ0KPiBleGNoYW5nZSBpbiBUTFMgMS4zIGlzIGF0
IGxlYXN0IHBvdGVudGlhbGx5IGZvcndhcmQgc2VjdXJlWzFdICh0aGUNCj4gYWN0dWFsIGNvbnN0
cmFpbnRzIG9uIGFzeW1tZXRyaWMga2V5IGV4Y2hhbmdlcyBhcmUgZXZlbiBzdHJvbmdlcg0KPiB0
aGFuIHRoYXQsIGJ1dCB0aGlzIHdlYWtlciB2ZXJzaW9uIHN1ZmZpY2VzIGhlcmUpLiBTdGF0aWMg
UlNBIGlzIG5vdA0KPiBldmVuIHBvdGVudGlhbGx5IGZvcndhcmQtc2VjdXJlLCBzbyBpdCBjYW4g
bm90IGJlIGFkZGVkLg0KPiANCj4gSWYgeW91IHRyeSB0byBhZGQgYmFjayBSU0EgdXNpbmcgdGhl
IG1vc3Qgc3RyYWlnaHRmb3J3YXJkIG1ldGhvZCwNCj4gd2hhdCB5b3UgZ2V0IGlzIG5vdCBhbiBh
bmFsb2cgb2Ygc3RhdGljIFJTQSBmcm9tIFRMUyAxLjIuIFRoZSByZXN1bHQNCj4gd291bGQgYmUg
Y2xvc2VyIHRvIFJTQV9FWFBPUlQgZnJvbSBUTFMgMS4wLg0KPiANCj4gDQo+IE9uIHRoZSBvdGhl
ciBoYW5kLCB0aGVyZSBpcyBubyB3YXkgdG8gY29uc3RydWN0IGEga2V5IGV4Y2hhbmdlIHRoYXQg
aXMNCj4gYWx3YXlzIGZvcndhcmQtc2VjdXJlLiBFaXRoZXIgZW5kcG9pbnQgY2FuIGFsd2F5cyBh
Y3QgaW4gYSB3YXkgdGhhdA0KPiBkZXN0cm95cyBmb3J3YXJkLXNlY3VyaXR5IChldmVuIHdpdGhv
dXQgbGVha2luZyBhbnkgcGVyLWNvbm5lY3Rpb24NCj4gaW5mb3JtYXRpb24pLCBidXQgY2FuIG5v
dCBiZSBkZXRlY3RlZCAoREggc2hhcmUgcmV1c2UgaXMgY29uc2lkZXJlZA0KPiBkZXRlY3RhYmxl
KSBieSB0aGUgb3RoZXIgZW5kLg0KPiANCj4gDQo+IFsxXSAicG90ZW50aWFsbHkgZm9yd2FyZCBz
ZWN1cmUiIG1lYW5zIHRoYXQgdGhlcmUgZXhpc3RzIGludGVyb3BlcmF0aW5nDQo+IGNsaWVudCBh
bmQgc2VydmVyIGltcGxlbWVudGF0aW9ucywgc28gdGhhdCB0aGUga2V5IGV4Y2hhbmdlIGlzIGZv
cndhcmQtDQo+IHNlY3VyZS4NCj4gDQo+IA0KPiAtSWxhcmkNCj4gDQo=

--Apple-Mail-188BDBAB-6538-4A33-B1D8-046571304AA3
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw
ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM
aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe
Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN
SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb
sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy
oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4
MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk
jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U
AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd
8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq
hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg
1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4
HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d
Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK
+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC
ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh
Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s
biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8
F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ
KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g
mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01
Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj
ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK
vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew
JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk
hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI
hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL
KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w
DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB
bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne
qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+
BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s
6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M
yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT
AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV
BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw
KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL
ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN
AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p
6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M
F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC
AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME
GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs
Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov
L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t
aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2
oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG
AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l
ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg
Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D
kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1
RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO
Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G
/HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9
Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD
VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM
IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTcwNzIzMTI0MzMzWjAjBgkqhkiG9w0BCQQxFgQU9qXXiwW+N9iS
uF0Fb6M9CFN3ehMwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAFrmSCiRqIBUOe6QBCSh2O5EedW8JaxiIVCzv0pj
FQJcpiXwnB2fpuP6DxhS1dbZSV29dUzkgDsjVziGf2gQQb+fzGi+nQYnr9TiildQf4xAekMjW1G3
1oohPMeqS0d3hJWkoj4ZnpAKRLZ84Wr695JtxGsZh9SIJcXgI5RS9iDT/+pr95MoqUMguR8/8dBD
p/i++dQ3R6eE2GdKTmCLarg9MqQeohdGc4Y/yxSjdAjwviR5oGLlVG4rdxqY2hbBlwaS9zjboKhc
WygYpMgdthfHDtOf3/JBeIDml9TH4RNO22bWQ8HPgPs806m7XLVObNaWkAyPaL36Uvc5kxzJemcA
AAAAAAA=

--Apple-Mail-188BDBAB-6538-4A33-B1D8-046571304AA3--


From nobody Sun Jul 23 07:33:33 2017
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 7E86F129AD1 for ; Sun, 23 Jul 2017 07:33: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=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 mcj6v6E-A3TW for ; Sun, 23 Jul 2017 07:33:30 -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 10F1D126C2F for ; Sun, 23 Jul 2017 07:33:29 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id y126so44711797qke.4 for ; Sun, 23 Jul 2017 07:33:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WScJCeJYJrqL6Q4VPhAiBiIgFgO30rUO/4VmZ8/Igec=; b=erI9OQWn2wnVkFTfiXxPa91oJHVXb8AMs81uWuOz549FMRNyG3EOf0wR0CqYuYcJzi RXxlFX/RN3kploHjSQz+L6ukVi64Mgwy0RgK7g43E2HYUE788ilvMcayPp1OdSQA0V5s PgnsmhxNoqRLjemX1Mz5i0lQ0QgGq9aodKRoVODWP4mll+hIACf5vpJYz+MmIbWLqvMS BP++TYhjjslnGA8H5diXY+b77BrqbyhqcK8u9P/rPPkKV4+4ncwEZsg4XvMxLwm+U32e CN7Of0al0ULOzPnA5lwVJJhk/KQXgV4NdHF4GO0FJOE9JNQAQqQjlRXZoRU+3KNR2zaF kIGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WScJCeJYJrqL6Q4VPhAiBiIgFgO30rUO/4VmZ8/Igec=; b=NrbzyXObm0mTDEMLHpWHxDnG2lX3mtptIvVKdtPi+L+M1PPuJ9LVTjmzp/6GaZxLh3 d1qt481B0J0CKFYNgnKJVN0sGuIVIzg6BZof9nUVYtuXmOFNbzNdU/YmEs06Fw75S/uH FvNkQBVb5oxCSs8UAo8HstjQIJPsACPZk67bmcq+ipdmqP4u0PxNbfMw8Pwl8PLKIjGF qO3oYknzVMkeZnVGejm5b15bPPsPJad42x7QaI//pyEb+5GiTb/JWk5RK0sq8plh7jA+ OeWu36bGADJENcxgRObGouJpjfEO433zQTVamK2QgxzhW7telYV73vxyqwVhYNA04wV6 q20w==
X-Gm-Message-State: AIVw113I1VUDT+Dqx7FJm+lyM+VCFz9lbkkI/8zc/RqBxNDJhcawkL8B 3GcrtjtCNPjWgsb3gjWf5g==
X-Received: by 10.55.19.29 with SMTP id d29mr17067245qkh.296.1500820408906; Sun, 23 Jul 2017 07:33:28 -0700 (PDT)
Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i9sm7233937qtc.66.2017.07.23.07.33.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Jul 2017 07:33:27 -0700 (PDT)
From: Ted Lemon 
Message-Id: <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BCE45AE1-4CCF-41CF-B779-12E0FAB509A5"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 23 Jul 2017 10:33:26 -0400
In-Reply-To: 
Cc: Ilari Liusvaara , "" 
To: "Blumenthal, Uri - 0553 - MITLL" 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 14:33:31 -0000

--Apple-Mail=_BCE45AE1-4CCF-41CF-B779-12E0FAB509A5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I did a little bit of rubber-duck debugging on this proposal with Andrea =
on the way back from Boston this morning.   It's actually better for the =
server to secretly use a static key than to negotiate.   Stephen has =
already explained why: if this is a negotiation, then it's possible for =
a third party to simply block any negotiation that doesn't allow it.   =
We have no control over evil endpoints, and it's silly to pretend =
otherwise.   Pretending otherwise makes us less secure, not more secure.


--Apple-Mail=_BCE45AE1-4CCF-41CF-B779-12E0FAB509A5
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

I did a little bit of rubber-duck debugging on this proposal with Andrea on the way back from Boston this morning.   It's actually better for the server to secretly use a static key than to negotiate.   Stephen has already explained why: if this is a negotiation, then it's possible for a third party to simply block any negotiation that doesn't allow it.   We have no control over evil endpoints, and it's silly to pretend otherwise.   Pretending otherwise makes us less secure, not more secure.

    
--Apple-Mail=_BCE45AE1-4CCF-41CF-B779-12E0FAB509A5--


From nobody Sun Jul 23 09:05:58 2017
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 7FB8112714F for ; Sun, 23 Jul 2017 09:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 G45WbSIL4Yg6 for ; Sun, 23 Jul 2017 09:05:56 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 246A912704A for ; Sun, 23 Jul 2017 09:05:55 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6NG5si1031690; Sun, 23 Jul 2017 12:05:54 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Ted Lemon 
CC: Ilari Liusvaara , "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB0GJJTXEJ9Nke26Xc5y2RlZKJbn/KAgAAClACAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB/KoCAAASqgIAACjOAgAAC6wCAAJbcgIAAAy8AgAADmACAADBYAP//wM6AgABH+AD//7+cAIAEFRUAgABfPoCAAB60AIAAGdEA
Date: Sun, 23 Jul 2017 16:05:52 +0000
Message-ID: 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>
In-Reply-To: <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; boundary="Apple-Mail-B6B58679-BB31-44BB-8715-985F33239231"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-23_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707230253
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 16:05:57 -0000

--Apple-Mail-B6B58679-BB31-44BB-8715-985F33239231
Content-Type: multipart/alternative;
	boundary=Apple-Mail-83FB55C9-F473-42A4-97DA-451DFC38D4C2
Content-Transfer-Encoding: 7bit


--Apple-Mail-83FB55C9-F473-42A4-97DA-451DFC38D4C2
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

I think there's no way the connection can be established if the third party i=
n control of the network does not allow that.=20

My only goal here is to leave fewer possibilities to set the eavesdropping s=
ilently.

Regards,
Uri

Sent from my iPhone

> On Jul 23, 2017, at 10:33, Ted Lemon  wrote:
>=20
> I did a little bit of rubber-duck debugging on this proposal with Andrea o=
n the way back from Boston this morning.   It's actually better for the serv=
er to secretly use a static key than to negotiate.   Stephen has already exp=
lained why: if this is a negotiation, then it's possible for a third party t=
o simply block any negotiation that doesn't allow it.   We have no control o=
ver evil endpoints, and it's silly to pretend otherwise.   Pretending otherw=
ise makes us less secure, not more secure.
>=20

--Apple-Mail-83FB55C9-F473-42A4-97DA-451DFC38D4C2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


    I think there's no way the connection can be established if the third party in control of the network does not allow that. 

    My only goal here is to leave fewer possibilities to set the eavesdropping silently.

    Regards,
    Uri

    Sent from my iPhone

    On Jul 23, 2017, at 10:33, Ted Lemon <mellon@fugue.com> wrote:

    
I did a little bit of rubber-duck debugging on this proposal with Andrea on the way back from Boston this morning.   It's actually better for the server to secretly use a static key than to negotiate.   Stephen has already explained why: if this is a negotiation, then it's possible for a third party to simply block any negotiation that doesn't allow it.   We have no control over evil endpoints, and it's silly to pretend otherwise.   Pretending otherwise makes us less secure, not more secure.

    
--Apple-Mail-83FB55C9-F473-42A4-97DA-451DFC38D4C2--

--Apple-Mail-B6B58679-BB31-44BB-8715-985F33239231
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw
ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM
aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe
Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN
SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb
sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy
oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4
MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk
jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U
AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd
8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq
hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg
1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4
HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d
Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK
+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC
ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh
Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s
biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8
F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ
KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g
mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01
Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj
ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK
vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew
JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk
hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI
hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL
KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w
DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB
bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne
qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+
BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s
6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M
yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT
AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV
BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw
KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL
ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN
AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p
6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M
F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC
AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME
GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs
Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov
L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t
aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2
oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG
AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l
ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg
Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D
kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1
RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO
Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G
/HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9
Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD
VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM
IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTcwNzIzMTYwNTUwWjAjBgkqhkiG9w0BCQQxFgQUzre62y2Apv2g
FvG8vp2xSEC6SjMwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAIBBTlZ+fED7663dAyunJnLLZ3Ln9fkZjqNBIpMI
dx5YA3jotaGIGWqfulrIwxXARihCd/4RXJa6v/FAhWUai1Dch9ZahN51tXgiZzmlzRTzgpWAzoQ8
n5/VV2BXA0mJX8nxF9S3BItniahQOllUi6FmwoJbI8A3bgachfwvoO8FQhEQrGvUGRLsOmtzj2Xj
+vvGSakVqDfm6aKslJU8sscremwHygo3cPcYbc2X2PAEfwz4GeRR2yRo1I7Ix8d/Wc2NRonLmqAT
Nrrxr84vsqlLE2pMriUyfF8gSzzX1BwCRyfj1WCvvTUvTuvuwb2mZVppmBoyuQipZf0MnRG6tg0A
AAAAAAA=

--Apple-Mail-B6B58679-BB31-44BB-8715-985F33239231--


From nobody Sun Jul 23 09:16:10 2017
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 D5A2612714F for ; Sun, 23 Jul 2017 09:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65Ghu6FCZGZD for ; Sun, 23 Jul 2017 09:16:04 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0751241FC for ; Sun, 23 Jul 2017 09:16:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0D85ABE2C; Sun, 23 Jul 2017 17:16:03 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiOV24H885NR; Sun, 23 Jul 2017 17:16:01 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1FE97BE24; Sun, 23 Jul 2017 17:16:01 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500826561; bh=FlrJH1Cyd3QpEmO5dDnIS4mb/GxXnixk6FZ12eV09ow=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kJZmYkI/p3vNn7Odm85TPuEaxhYNC4bh6UClmiVytpbn69vuea7D99PMl80hp11K0 Ys9wsCaPyDQCrSaQjA3zoR5D++AlwmlcyN2D33kU+CuL25KRLJXX9K07cUHTc046Lt ewqUTkQkus3yJnWOejY2chFOlaTqqT1TbBk1Cg+Y=
To: "Blumenthal, Uri - 0553 - MITLL" , Ilari Liusvaara 
Cc: "" 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <3ca53a31-52c4-3f87-2e4c-fb5965d43eee@cs.tcd.ie>
Date: Sun, 23 Jul 2017 17:16:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bj6SsuuKOnCMX7ctxqiOutBOwcO4Nb3R5"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 16:16:08 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--bj6SsuuKOnCMX7ctxqiOutBOwcO4Nb3R5
Content-Type: multipart/mixed; boundary="a6kCbRSOMBNNA89VTtUdSTMlhRxvQebWC";
 protected-headers="v1"
From: Stephen Farrell 
To: "Blumenthal, Uri - 0553 - MITLL" ,
 Ilari Liusvaara 
Cc: "" 
Message-ID: <3ca53a31-52c4-3f87-2e4c-fb5965d43eee@cs.tcd.ie>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
References: 
 <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp>
 <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu>
 <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII>
 <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu>
 <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>
 
In-Reply-To: 

--a6kCbRSOMBNNA89VTtUdSTMlhRxvQebWC
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 23/07/17 13:43, Blumenthal, Uri - 0553 - MITLL wrote:
> Ilari,
>=20
> I got your point.
>=20
> But in view of the request this WG is discussing now, I see only two
> reasonable (IMHO) opinion: 1. Tell those requestors to go away
> because TLS 1.3 has been designed to always be forward-secure; or 2.
> Add a *detectable* non-PFS key exchange so those requestors would
> have something they can live with, and the rest of us could at least
> agree or disagree to a non-PFS session establishment on a per-session
> or a per-entity basis.

In Prague some folks were considering another option:

3. Encourage folks who currently use static RSA keys for third
party decryption to put in place a migration plan that gets them
to FS without breaking TLS1.3. IOW, given they can continue to
use TLS1.2 for some years to come, there's no rush, and plenty
of time for transition plans to be put in place. (That'd I think
imply some work in the ops area of the IETF if there's any IETF
work needed at all, but nothing in the TLS wg.)

While I'd (probably entirely predictably:-) be against your
option 2 above, I'd also note that that'd entirely screw up any
ideas we might have of finishing TLS1.3 in the near term. Anyone
who'd argue for such changes needs to be clear that they're also
arguing for another year's delay.

Cheers,
S.

>=20
> I do not know what mechanism could do the latter, or off it even
> exists. But folding an RSA method in seems to do the job. I'd say
> it's fine if it borrows from 1.0, as it isn't going to be the most
> secure setting anyway.
>=20
> Regards, Uri
>=20
> Sent from my iPhone
>=20
>> On Jul 23, 2017, at 03:02, Ilari Liusvaara
>>  wrote:
>>=20
>>> On Thu, Jul 20, 2017 at 08:42:10PM +0000, Blumenthal, Uri - 0553
>>> - MITLL wrote:
>>>> On 7/20/17, 16:32, "ilariliusvaara@welho.com on behalf of Ilari
>>>> Liusvaara"  wrote: Maybe we are
>>>> better off just retrofitting RSA-key-transport back into
>>>> TLS-1.3?
>>>=20
>>> This has in fact been requested. Kenny Paterson said about the
>>> request:=20
>>> ---------------------------------------------------------------------=
--
>>>
>>>=20
My view concerning your request: no.
>>> Rationale: We're trying to build a more secure internet.
>>>=20
>>> My rationale to resurrect it: others are trying to push TLS-1.3
>>> into an invisibly-insecure state. If we must satisfy them (and
>>> I=E2=80=99m not at all sure we should), then this is the most obvious=
 way
>>> to at least avoid the =E2=80=9Cinsecurity=E2=80=9D being silently pus=
hed upon
>>> you. At the very least you=E2=80=99d have an option to continue under=

>>> surveillance or abort connection.
>>=20
>> This isn't just matter of what is considered "secure enough" to=20
>> include. There are fundamential technical constraints that prevent=20
>> adding static RSA back.
>>=20
>> Early on, there were all sorts of really fundamential decisions on
>> how TLS 1.3 works. The results of these decisions are baked deeply
>> in the protocol, and are extremely hard to change. These decisions
>> were already very apparent in draft-02, over 3 years ago, despite
>> -02 being unimplementable.
>>=20
>> One implication of those assumptions is that any asymmetric key=20
>> exchange in TLS 1.3 is at least potentially forward secure[1] (the=20
>> actual constraints on asymmetric key exchanges are even stronger=20
>> than that, but this weaker version suffices here). Static RSA is
>> not even potentially forward-secure, so it can not be added.
>>=20
>> If you try to add back RSA using the most straightforward method,=20
>> what you get is not an analog of static RSA from TLS 1.2. The
>> result would be closer to RSA_EXPORT from TLS 1.0.
>>=20
>>=20
>> On the other hand, there is no way to construct a key exchange that
>> is always forward-secure. Either endpoint can always act in a way
>> that destroys forward-security (even without leaking any
>> per-connection information), but can not be detected (DH share
>> reuse is considered detectable) by the other end.
>>=20
>>=20
>> [1] "potentially forward secure" means that there exists
>> interoperating client and server implementations, so that the key
>> exchange is forward- secure.
>>=20
>>=20
>> -Ilari
>>=20
>>=20
>>=20
>> _______________________________________________ TLS mailing list=20
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls


--a6kCbRSOMBNNA89VTtUdSTMlhRxvQebWC--

--bj6SsuuKOnCMX7ctxqiOutBOwcO4Nb3R5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZdMvAAAoJEC88hzaAX42iYWMH/0fSDL7uFkVqKA08SjtD3DGO
nUNTsV5D/Hi0Ztps2U/xD7jryoB8ZwyyUQhgh3XQks7E0hil9jlfvCRepUPofetW
eJRZ72plzNxCiRV227fa6ZhtG6LayDWUeJpA7zxhWSnmNgQ2fOPqNRnPEkCgcYVJ
UNUqbpnluEsw8bimUh6geo4qXX9mJb9ipCWa7h/5yqMwS6UlkcCcftAufj1uCx0h
RokEGGGkyPmZbLd6jNb+jMU/a4pY1cHOdOnhoR8fGyRYV33TXXCsApmxQAknaYQH
Fvn/jF2zTe3Yw6pW8xu9vvEVIDa0W7hsoUOiVJE6pkrGI+4bdwDgEoar6HanpvA=
=7AW/
-----END PGP SIGNATURE-----

--bj6SsuuKOnCMX7ctxqiOutBOwcO4Nb3R5--


From nobody Sun Jul 23 09:23:42 2017
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 9AD23129B2A for ; Sun, 23 Jul 2017 09:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 uR4jeqFV7atd for ; Sun, 23 Jul 2017 09:23:38 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB601241FC for ; Sun, 23 Jul 2017 09:23:38 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6NGNWTH040463; Sun, 23 Jul 2017 12:23:32 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Stephen Farrell 
CC: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB0GJJTXEJ9Nke26Xc5y2RlZKJbn/KAgAAClACAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB/KoCAAASqgIAACjOAgAAC6wCAAJbcgIAAAy8AgAADmACAADBYAP//wM6AgABH+AD//7+cAIAEFRUAgABfPoCAADtcAIAAAhgA
Date: Sun, 23 Jul 2017 16:23:31 +0000
Message-ID: 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <3ca53a31-52c4-3f87-2e4c-fb5965d43eee@cs.tcd.ie>
In-Reply-To: <3ca53a31-52c4-3f87-2e4c-fb5965d43eee@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; boundary="Apple-Mail-6283F613-11E8-4ED3-A922-CDA49C36B79C"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-23_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707230256
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 16:23:41 -0000

--Apple-Mail-6283F613-11E8-4ED3-A922-CDA49C36B79C
Content-Type: text/plain;
	charset=windows-1251
Content-Transfer-Encoding: base64

SSdkIGJlIHBlcmZlY3RseSBoYXBweSB3aXRoIFRMUyAxLjMgaGF2aW5nIG5vdGhpbmcgYnV0IFBG
UywgYW5kIHRob3NlIGluIG5lZWQgb2YgdGhlIHBsYWludGV4dCBnZXR0aW5nIGl0IGZyb20gdGhl
IGVuZHBvaW50IE9PQi4NCg0KUmVnYXJkcywNClVyaQ0KDQpTZW50IGZyb20gbXkgaVBob25lDQoN
Cj4gT24gSnVsIDIzLCAyMDE3LCBhdCAxMjoxNiwgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZh
cnJlbGxAY3MudGNkLmllPiB3cm90ZToNCj4gDQo+IA0KPiANCj4+IE9uIDIzLzA3LzE3IDEzOjQz
LCBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEwgd3JvdGU6DQo+PiBJbGFyaSwNCj4+IA0K
Pj4gSSBnb3QgeW91ciBwb2ludC4NCj4+IA0KPj4gQnV0IGluIHZpZXcgb2YgdGhlIHJlcXVlc3Qg
dGhpcyBXRyBpcyBkaXNjdXNzaW5nIG5vdywgSSBzZWUgb25seSB0d28NCj4+IHJlYXNvbmFibGUg
KElNSE8pIG9waW5pb246IDEuIFRlbGwgdGhvc2UgcmVxdWVzdG9ycyB0byBnbyBhd2F5DQo+PiBi
ZWNhdXNlIFRMUyAxLjMgaGFzIGJlZW4gZGVzaWduZWQgdG8gYWx3YXlzIGJlIGZvcndhcmQtc2Vj
dXJlOyBvciAyLg0KPj4gQWRkIGEgKmRldGVjdGFibGUqIG5vbi1QRlMga2V5IGV4Y2hhbmdlIHNv
IHRob3NlIHJlcXVlc3RvcnMgd291bGQNCj4+IGhhdmUgc29tZXRoaW5nIHRoZXkgY2FuIGxpdmUg
d2l0aCwgYW5kIHRoZSByZXN0IG9mIHVzIGNvdWxkIGF0IGxlYXN0DQo+PiBhZ3JlZSBvciBkaXNh
Z3JlZSB0byBhIG5vbi1QRlMgc2Vzc2lvbiBlc3RhYmxpc2htZW50IG9uIGEgcGVyLXNlc3Npb24N
Cj4+IG9yIGEgcGVyLWVudGl0eSBiYXNpcy4NCj4gDQo+IEluIFByYWd1ZSBzb21lIGZvbGtzIHdl
cmUgY29uc2lkZXJpbmcgYW5vdGhlciBvcHRpb246DQo+IA0KPiAzLiBFbmNvdXJhZ2UgZm9sa3Mg
d2hvIGN1cnJlbnRseSB1c2Ugc3RhdGljIFJTQSBrZXlzIGZvciB0aGlyZA0KPiBwYXJ0eSBkZWNy
eXB0aW9uIHRvIHB1dCBpbiBwbGFjZSBhIG1pZ3JhdGlvbiBwbGFuIHRoYXQgZ2V0cyB0aGVtDQo+
IHRvIEZTIHdpdGhvdXQgYnJlYWtpbmcgVExTMS4zLiBJT1csIGdpdmVuIHRoZXkgY2FuIGNvbnRp
bnVlIHRvDQo+IHVzZSBUTFMxLjIgZm9yIHNvbWUgeWVhcnMgdG8gY29tZSwgdGhlcmUncyBubyBy
dXNoLCBhbmQgcGxlbnR5DQo+IG9mIHRpbWUgZm9yIHRyYW5zaXRpb24gcGxhbnMgdG8gYmUgcHV0
IGluIHBsYWNlLiAoVGhhdCdkIEkgdGhpbmsNCj4gaW1wbHkgc29tZSB3b3JrIGluIHRoZSBvcHMg
YXJlYSBvZiB0aGUgSUVURiBpZiB0aGVyZSdzIGFueSBJRVRGDQo+IHdvcmsgbmVlZGVkIGF0IGFs
bCwgYnV0IG5vdGhpbmcgaW4gdGhlIFRMUyB3Zy4pDQo+IA0KPiBXaGlsZSBJJ2QgKHByb2JhYmx5
IGVudGlyZWx5IHByZWRpY3RhYmx5Oi0pIGJlIGFnYWluc3QgeW91cg0KPiBvcHRpb24gMiBhYm92
ZSwgSSdkIGFsc28gbm90ZSB0aGF0IHRoYXQnZCBlbnRpcmVseSBzY3JldyB1cCBhbnkNCj4gaWRl
YXMgd2UgbWlnaHQgaGF2ZSBvZiBmaW5pc2hpbmcgVExTMS4zIGluIHRoZSBuZWFyIHRlcm0uIEFu
eW9uZQ0KPiB3aG8nZCBhcmd1ZSBmb3Igc3VjaCBjaGFuZ2VzIG5lZWRzIHRvIGJlIGNsZWFyIHRo
YXQgdGhleSdyZSBhbHNvDQo+IGFyZ3VpbmcgZm9yIGFub3RoZXIgeWVhcidzIGRlbGF5Lg0KPiAN
Cj4gQ2hlZXJzLA0KPiBTLg0KPiANCj4+IA0KPj4gSSBkbyBub3Qga25vdyB3aGF0IG1lY2hhbmlz
bSBjb3VsZCBkbyB0aGUgbGF0dGVyLCBvciBvZmYgaXQgZXZlbg0KPj4gZXhpc3RzLiBCdXQgZm9s
ZGluZyBhbiBSU0EgbWV0aG9kIGluIHNlZW1zIHRvIGRvIHRoZSBqb2IuIEknZCBzYXkNCj4+IGl0
J3MgZmluZSBpZiBpdCBib3Jyb3dzIGZyb20gMS4wLCBhcyBpdCBpc24ndCBnb2luZyB0byBiZSB0
aGUgbW9zdA0KPj4gc2VjdXJlIHNldHRpbmcgYW55d2F5Lg0KPj4gDQo+PiBSZWdhcmRzLCBVcmkN
Cj4+IA0KPj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPj4gDQo+Pj4gT24gSnVsIDIzLCAyMDE3LCBh
dCAwMzowMiwgSWxhcmkgTGl1c3ZhYXJhDQo+Pj4gPGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbT4g
d3JvdGU6DQo+Pj4gDQo+Pj4+IE9uIFRodSwgSnVsIDIwLCAyMDE3IGF0IDA4OjQyOjEwUE0gKzAw
MDAsIEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMNCj4+Pj4gLSBNSVRMTCB3cm90ZToNCj4+Pj4+IE9u
IDcvMjAvMTcsIDE2OjMyLCAiaWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tIG9uIGJlaGFsZiBvZiBJ
bGFyaQ0KPj4+Pj4gTGl1c3ZhYXJhIiA8aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tPiB3cm90ZTog
TWF5YmUgd2UgYXJlDQo+Pj4+PiBiZXR0ZXIgb2ZmIGp1c3QgcmV0cm9maXR0aW5nIFJTQS1rZXkt
dHJhbnNwb3J0IGJhY2sgaW50bw0KPj4+Pj4gVExTLTEuMz8NCj4+Pj4gDQo+Pj4+IFRoaXMgaGFz
IGluIGZhY3QgYmVlbiByZXF1ZXN0ZWQuIEtlbm55IFBhdGVyc29uIHNhaWQgYWJvdXQgdGhlDQo+
Pj4+IHJlcXVlc3Q6IA0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiANCj4+Pj4gDQo+IE15IHZp
ZXcgY29uY2VybmluZyB5b3VyIHJlcXVlc3Q6IG5vLg0KPj4+PiBSYXRpb25hbGU6IFdlJ3JlIHRy
eWluZyB0byBidWlsZCBhIG1vcmUgc2VjdXJlIGludGVybmV0Lg0KPj4+PiANCj4+Pj4gTXkgcmF0
aW9uYWxlIHRvIHJlc3VycmVjdCBpdDogb3RoZXJzIGFyZSB0cnlpbmcgdG8gcHVzaCBUTFMtMS4z
DQo+Pj4+IGludG8gYW4gaW52aXNpYmx5LWluc2VjdXJlIHN0YXRlLiBJZiB3ZSBtdXN0IHNhdGlz
ZnkgdGhlbSAoYW5kDQo+Pj4+IEmSbSBub3QgYXQgYWxsIHN1cmUgd2Ugc2hvdWxkKSwgdGhlbiB0
aGlzIGlzIHRoZSBtb3N0IG9idmlvdXMgd2F5DQo+Pj4+IHRvIGF0IGxlYXN0IGF2b2lkIHRoZSCT
aW5zZWN1cml0eZQgYmVpbmcgc2lsZW50bHkgcHVzaGVkIHVwb24NCj4+Pj4geW91LiBBdCB0aGUg
dmVyeSBsZWFzdCB5b3WSZCBoYXZlIGFuIG9wdGlvbiB0byBjb250aW51ZSB1bmRlcg0KPj4+PiBz
dXJ2ZWlsbGFuY2Ugb3IgYWJvcnQgY29ubmVjdGlvbi4NCj4+PiANCj4+PiBUaGlzIGlzbid0IGp1
c3QgbWF0dGVyIG9mIHdoYXQgaXMgY29uc2lkZXJlZCAic2VjdXJlIGVub3VnaCIgdG8gDQo+Pj4g
aW5jbHVkZS4gVGhlcmUgYXJlIGZ1bmRhbWVudGlhbCB0ZWNobmljYWwgY29uc3RyYWludHMgdGhh
dCBwcmV2ZW50IA0KPj4+IGFkZGluZyBzdGF0aWMgUlNBIGJhY2suDQo+Pj4gDQo+Pj4gRWFybHkg
b24sIHRoZXJlIHdlcmUgYWxsIHNvcnRzIG9mIHJlYWxseSBmdW5kYW1lbnRpYWwgZGVjaXNpb25z
IG9uDQo+Pj4gaG93IFRMUyAxLjMgd29ya3MuIFRoZSByZXN1bHRzIG9mIHRoZXNlIGRlY2lzaW9u
cyBhcmUgYmFrZWQgZGVlcGx5DQo+Pj4gaW4gdGhlIHByb3RvY29sLCBhbmQgYXJlIGV4dHJlbWVs
eSBoYXJkIHRvIGNoYW5nZS4gVGhlc2UgZGVjaXNpb25zDQo+Pj4gd2VyZSBhbHJlYWR5IHZlcnkg
YXBwYXJlbnQgaW4gZHJhZnQtMDIsIG92ZXIgMyB5ZWFycyBhZ28sIGRlc3BpdGUNCj4+PiAtMDIg
YmVpbmcgdW5pbXBsZW1lbnRhYmxlLg0KPj4+IA0KPj4+IE9uZSBpbXBsaWNhdGlvbiBvZiB0aG9z
ZSBhc3N1bXB0aW9ucyBpcyB0aGF0IGFueSBhc3ltbWV0cmljIGtleSANCj4+PiBleGNoYW5nZSBp
biBUTFMgMS4zIGlzIGF0IGxlYXN0IHBvdGVudGlhbGx5IGZvcndhcmQgc2VjdXJlWzFdICh0aGUg
DQo+Pj4gYWN0dWFsIGNvbnN0cmFpbnRzIG9uIGFzeW1tZXRyaWMga2V5IGV4Y2hhbmdlcyBhcmUg
ZXZlbiBzdHJvbmdlciANCj4+PiB0aGFuIHRoYXQsIGJ1dCB0aGlzIHdlYWtlciB2ZXJzaW9uIHN1
ZmZpY2VzIGhlcmUpLiBTdGF0aWMgUlNBIGlzDQo+Pj4gbm90IGV2ZW4gcG90ZW50aWFsbHkgZm9y
d2FyZC1zZWN1cmUsIHNvIGl0IGNhbiBub3QgYmUgYWRkZWQuDQo+Pj4gDQo+Pj4gSWYgeW91IHRy
eSB0byBhZGQgYmFjayBSU0EgdXNpbmcgdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIG1ldGhvZCwg
DQo+Pj4gd2hhdCB5b3UgZ2V0IGlzIG5vdCBhbiBhbmFsb2cgb2Ygc3RhdGljIFJTQSBmcm9tIFRM
UyAxLjIuIFRoZQ0KPj4+IHJlc3VsdCB3b3VsZCBiZSBjbG9zZXIgdG8gUlNBX0VYUE9SVCBmcm9t
IFRMUyAxLjAuDQo+Pj4gDQo+Pj4gDQo+Pj4gT24gdGhlIG90aGVyIGhhbmQsIHRoZXJlIGlzIG5v
IHdheSB0byBjb25zdHJ1Y3QgYSBrZXkgZXhjaGFuZ2UgdGhhdA0KPj4+IGlzIGFsd2F5cyBmb3J3
YXJkLXNlY3VyZS4gRWl0aGVyIGVuZHBvaW50IGNhbiBhbHdheXMgYWN0IGluIGEgd2F5DQo+Pj4g
dGhhdCBkZXN0cm95cyBmb3J3YXJkLXNlY3VyaXR5IChldmVuIHdpdGhvdXQgbGVha2luZyBhbnkN
Cj4+PiBwZXItY29ubmVjdGlvbiBpbmZvcm1hdGlvbiksIGJ1dCBjYW4gbm90IGJlIGRldGVjdGVk
IChESCBzaGFyZQ0KPj4+IHJldXNlIGlzIGNvbnNpZGVyZWQgZGV0ZWN0YWJsZSkgYnkgdGhlIG90
aGVyIGVuZC4NCj4+PiANCj4+PiANCj4+PiBbMV0gInBvdGVudGlhbGx5IGZvcndhcmQgc2VjdXJl
IiBtZWFucyB0aGF0IHRoZXJlIGV4aXN0cw0KPj4+IGludGVyb3BlcmF0aW5nIGNsaWVudCBhbmQg
c2VydmVyIGltcGxlbWVudGF0aW9ucywgc28gdGhhdCB0aGUga2V5DQo+Pj4gZXhjaGFuZ2UgaXMg
Zm9yd2FyZC0gc2VjdXJlLg0KPj4+IA0KPj4+IA0KPj4+IC1JbGFyaQ0KPj4+IA0KPj4+IA0KPj4+
IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFRM
UyBtYWlsaW5nIGxpc3QgDQo+Pj4gVExTQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdGxzDQo+IA0K
--Apple-Mail-6283F613-11E8-4ED3-A922-CDA49C36B79C
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw
ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM
aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe
Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN
SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb
sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy
oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4
MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk
jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U
AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd
8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq
hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg
1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4
HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d
Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK
+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC
ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh
Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s
biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8
F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ
KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g
mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01
Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj
ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK
vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew
JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk
hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI
hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL
KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w
DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB
bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne
qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+
BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s
6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M
yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT
AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV
BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw
KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL
ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN
AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p
6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M
F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC
AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME
GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs
Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov
L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t
aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2
oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG
AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l
ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg
Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D
kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1
RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO
Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G
/HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9
Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD
VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM
IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTcwNzIzMTYyMzMwWjAjBgkqhkiG9w0BCQQxFgQUTlQUlkfp6lK6
76O0nqz7XTnHj5IwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAH5jd10jP/lNlAqTqInrwwNkd4bCfhSiPJoxRP15
S9/vIVXnoxaxNViroGfgNKPx9pp4gk0QKgFmIVn+KwYkqV9CY36pn/kVvXNDXqX6DwErcY2QwFks
AG2jox5MAaMGJCv2XeubemGbgJzCXqaiTVAtPxLevLnq2Rfkcty3UFII4g2JrpIT5qmc2AP+aGnF
Eu7x3tH5SERvhGwuQKrx6rnwbh9WQmZ1hqsJbXCgbbr5riUoBAtMZMxrHRVz2Ag0qCof7EfzFNgF
jFNjVBj5iRXO0WVDWA/j4tRpd+cztkAP8JUakHvDKxdpmAhxL0MqU28h63mmOGLNOqLESbDksNEA
AAAAAAA=

--Apple-Mail-6283F613-11E8-4ED3-A922-CDA49C36B79C--


From nobody Sun Jul 23 12:37:17 2017
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 061DB126D46 for ; Sun, 23 Jul 2017 12:37:16 -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, MIME_QP_LONG_LINE=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 n56YqfV60d4I for ; Sun, 23 Jul 2017 12:37:14 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B191252BA for ; Sun, 23 Jul 2017 12:37:14 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id d136so46312601qkg.3 for ; Sun, 23 Jul 2017 12:37:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6h7crByhMCCo4MPtkyFOA5tyMW6Umb7h9Fyjsd9nR2Q=; b=zS4MdgPyNSzaMICwVNkkwMqgKSKTXBBOT60M8LOHV8u9pGNjqfS+QuTQc1Jvm9xjff pqIK+0nGS3uIfQu6RlJgqEtFuBkILmLaCfdHIw6ZxzQ+WsFTpojklABr3EML60Zql5Q4 9+oSS2PPBd1REbftV6qyV+Lr16+eeLuuLJ/rEmtpt/IAtWJUhnlrl8MmQ6xtENjeRmwG fRTx4axUeYmLIVr7r/ZeQ5WciQYtbywKrQCJTzmebZvEWbcM8ekHZr2S9C4cKLjYWr0T U1F/WhlCFuXC0wkFyH5z5uTwmSgahuLtJ1jxFJkDLDmO7OAzyLcEc9sFxM2CmsXz7MOg 7mHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6h7crByhMCCo4MPtkyFOA5tyMW6Umb7h9Fyjsd9nR2Q=; b=eUyXwZ7AqqRgAjuGXeGAaXak43DeI6Oe/m9tfbJe0JnhEv5HklLEt17SsSQH6IB1gR n7B7TBE2yLE8+maYUCTVVYz9rLT1nYIJpLDCEibOE8khOY760JVY5yd50Mvyct6ylB4v 8IpKVpTkBM4RVE8ZY8onPgXiZLsgPRqbfGG1I0N15yDmtnCuVRKDZWge3ZVyNUbrrLHP CzbVqQ0NHE/fFDVxS3xTBVCZtqgq5hXXQN+Ydk8ptlfIXnUSam8Oo8EZYB+3fKiuspFS 8d/auYFT9frWoD+Up+n2dY2hwCTAcp8XPTnctlHQ1EziUwZUOw+uHcHB01IeemJwPte/ utXQ==
X-Gm-Message-State: AIVw1129kLYUd3tnuQaef84sX+oDkDnhX1VgzgHDd6gVgfHeGVPGjuXR M/M5l/p2TDNfyxVlxKDrfQ==
X-Received: by 10.55.27.97 with SMTP id b94mr18698292qkb.309.1500838632966; Sun, 23 Jul 2017 12:37:12 -0700 (PDT)
Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 5sm6892006qkk.75.2017.07.23.12.37.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Jul 2017 12:37:12 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-FD2E1DAC-28CA-4F15-A203-6EBFBDAC6FDA
Mime-Version: 1.0 (1.0)
From: Ted Lemon 
X-Mailer: iPad Mail (15A5318g)
In-Reply-To: 
Date: Sun, 23 Jul 2017 15:37:11 -0400
Cc: Ilari Liusvaara , "" 
Content-Transfer-Encoding: 7bit
Message-Id: <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com> 
To: "Blumenthal, Uri - 0553 - MITLL" 
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 19:37:16 -0000

--Apple-Mail-FD2E1DAC-28CA-4F15-A203-6EBFBDAC6FDA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL  wrote:
> I think there's no way the connection can be established if the third part=
y in control of the network does not allow that.=20

This is why it=E2=80=99s hard to reason well about this stuff=E2=80=94we ten=
d to get the threat models wrong.   The attack that negotiating enables is n=
ot that a third party can block all connections. They can always block all c=
onnections.

What the attack enables is blocking only those connections that don=E2=80=99=
t negotiate a downgrade. So if you negotiate a downgrade, you get to look at=
 your content, but if you don=E2=80=99t negotiate the downgrade, you don=E2=80=
=99t. This allows a MiTM to coerce end users into negotiating downgrades.

Of course the far end can just not downgrade, but it may have downgrading en=
abled either for debugging purposes, never intending that all connections be=
 downgraded, or because the operator didn=E2=80=99t configure the server cor=
rectly.   If it=E2=80=99s not in the standard, it can still be enabled by op=
erators who are violating the end user=E2=80=99s trust, but won=E2=80=99t ha=
ppen by accident and won=E2=80=99t be possible to coerce with a MiTM attack.=
=20=

--Apple-Mail-FD2E1DAC-28CA-4F15-A203-6EBFBDAC6FDA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    On Jul 23, 2017, at 12:05 P=
M, Blumenthal, Uri - 0553 - MITLL <uri@=
ll.mit.edu> wrote:
    I think ther=
e's no way the connection can be established if the third party in control o=
f the network does not allow that. 

    This is why it=E2=80=99s hard to reason well about this stuff=E2=80=
=94we tend to get the threat models wrong.   The attack that negotiatin=
g enables is not that a third party can block all connections. They can alwa=
ys block all connections.

    What the atta=
ck enables is blocking only those connections that don=E2=80=99t negotiate a=
 downgrade. So if you negotiate a downgrade, you get to look at your content=
, but if you don=E2=80=99t negotiate the downgrade, you don=E2=80=99t. This a=
llows a MiTM to coerce end users into negotiating downgrades.

    =

    Of course the far end can just not downgrade, but it may have dow=
ngrading enabled either for debugging purposes, never intending that all con=
nections be downgraded, or because the operator didn=E2=80=99t configure the=
 server correctly.   If it=E2=80=99s not in the standard, it can still b=
e enabled by operators who are violating the end user=E2=80=99s trust, but w=
on=E2=80=99t happen by accident and won=E2=80=99t be possible to coerce with=
 a MiTM attack. 
    =

--Apple-Mail-FD2E1DAC-28CA-4F15-A203-6EBFBDAC6FDA--


From nobody Sun Jul 23 14:38:02 2017
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 1F48F12ECCE for ; Sun, 23 Jul 2017 14:37:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 og6-D39Fetwz for ; Sun, 23 Jul 2017 14:37:53 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 61062127867 for ; Sun, 23 Jul 2017 14:37:53 -0700 (PDT)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dZOZT-0005aN-Sn for tls@ietf.org; Sun, 23 Jul 2017 23:37:52 +0200
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dZOZS-0004Sw-7j for tls@ietf.org; Sun, 23 Jul 2017 17:37:51 -0400
Received: (qmail 4491 invoked from network); 23 Jul 2017 21:37:49 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Jul 2017 21:37:48 -0000
To: tls@ietf.org
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>
From: Christian Huitema 
Message-ID: <318b4504-08b3-e2db-026b-a79ea4d1aec2@huitema.net>
Date: Sun, 23 Jul 2017 14:37:46 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>
Content-Type: multipart/alternative; boundary="------------778AB9981D25B4F2AA589C43"
X-Originating-IP: 168.144.250.223
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.17)
X-Recommended-Action: accept
X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23mh8X3andYQdWZYMgV8Y6GtdeLtSl0HbbXg+s ehKFyiAEGtIdfkvDNWcf2iA7z8p0YOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRP6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyc3azBLlqnENrF/E3Tt6iEPeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17fNhfekBTUX9xNtWKgIxLAi2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe93qlFit1PvkPF7Ua1AOSWcb0i13zjCiwPgdt77s k1WBMw==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 21:37:55 -0000

This is a multi-part message in MIME format.
--------------778AB9981D25B4F2AA589C43
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 7/23/2017 12:37 PM, Ted Lemon wrote:
> On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL
> > wrote:
>> I think there's no way the connection can be established if the third
>> party in control of the network does not allow that.=20
>
> This is why it=92s hard to reason well about this stuff=97we tend to ge=
t
> the threat models wrong.   The attack that negotiating enables is not
> that a third party can block all connections. They can always block
> /all/ connections.
>
> What the attack enables is blocking only those connections that don=92t=

> negotiate a downgrade. So if you negotiate a downgrade, you get to
> look at your content, but if you don=92t negotiate the downgrade, you
> don=92t. This allows a MiTM to coerce end users into negotiating downgr=
ades.

Speaking of threat model, one of the main threats is the "Lavabit" case:
a server is asked to somehow implement a backdoor so existing clients.
In that case, it is very useful for clients to detect that something has
changed. They can move away and use another server.

We are also concerned with the "open library" case, in which the
backdoor ends up being implemented by default in popular libraries. If
that happens, the backdoor can be instantiated via a simple
configuration parameter, and coercion becomes that much easier.
Publishing an RFC describing the back door would of course increase the
risk that the corresponding code ends in the common libraries, and that
is reason enough to not publish such a text.

-- Christian Huitema



--------------778AB9981D25B4F2AA589C43
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
    
    
    
    
    
    On 7/23/2017 12:37 PM, Ted Lemon wrote:
    
    
    
    
    
      
      
    On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL
        <uri@ll.mit.edu>
        wrote:
    
      
    
        
    
          
          
    I think there's no way the connection can be established
            if the third party in control of the network does not allow
            that. 
    
        
    
      
    
      

    
      
    
      
    This is why it’s hard to reason well about this stuff—we tend
        to get the threat models wrong.   The attack that negotiating
        enables is not that a third party can block all connections.
        They can always block all connections.
    
      

    
      
    
      
    What the attack enables is blocking only those connections
        that don’t negotiate a downgrade. So if you negotiate a
        downgrade, you get to look at your content, but if you don’t
        negotiate the downgrade, you don’t. This allows a MiTM to coerce
        end users into negotiating downgrades.
    
    
    
    
    
    Speaking of threat model, one of the main threats is the "Lavabit"
    case: a server is asked to somehow implement a backdoor so existing
    clients. In that case, it is very useful for clients to detect that
    something has changed. They can move away and use another server.
    
    
    
    We are also concerned with the "open library" case, in which the
    backdoor ends up being implemented by default in popular libraries.
    If that happens, the backdoor can be instantiated via a simple
    configuration parameter, and coercion becomes that much easier.
    Publishing an RFC describing the back door would of course increase
    the risk that the corresponding code ends in the common libraries,
    and that is reason enough to not publish such a text.
    
    
    
    -- Christian Huitema
    
    
    
    
    
  


--------------778AB9981D25B4F2AA589C43--


From nobody Sun Jul 23 15:16:49 2017
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 BD856126CC4 for ; Sun, 23 Jul 2017 15:16:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 51mQBWF6HcF4 for ; Sun, 23 Jul 2017 15:16:47 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 18035126C23 for ; Sun, 23 Jul 2017 15:16:46 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id t37so7453631qtg.5 for ; Sun, 23 Jul 2017 15:16:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=I/W4/LKByVMB95JWvHacp9bWAw7HZMnNDM/amj7gQVI=; b=JGsOO1dICTfB9N/f8lTxxCmLgWgyszrqe5mURokU+5VINjLoFRGfiMcvaCjCTnS+fS wwqgAwsoRc1uyRsebxk5C8mA+a6LkNUmAsarrQtmQV4PysLs5Nul6QYzfXceLGSPsGfI XjJ2Gy5Y5YWJ6HC9+00PO0DZ7spDtafuV7d8JyflRVCteJlk7eezGFTnhlP4RRMrwj3p OQLfWegKRUM+ULn4Ef4zvNDFdWPLR/crJDnZUwnhbvp8MZx3+56TCAU+yGdzpp8jg0T2 xbxd/lTIdiLAR98rZ8ieNl1RUUyvoeQ72DaskGpwBXwwKAKQ1RDFYR///SlbTCQsgV+8 Fx0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=I/W4/LKByVMB95JWvHacp9bWAw7HZMnNDM/amj7gQVI=; b=rGFVlGd9ZyDZRjDLesD7sLIGS/bZpuS1PcC9uj3wMBUIZwZxZxoEjIOZnu2UPjLVOn dCH04mBlgvX6+QK9ep5oZ+2mFK9iyRYyiPmLGhMVM9QBfpW5Jy+0iMFyKQowQjFK1HqZ jzbUfD9zjxdra8+7Kx89uKBR1EIOU3wvxaklGgw7La2BoGsdwG9zZAF93SttR3jHkfNn Rwj2JOrqspgAJleqq5belSq85J8mcOFCe4TpO2gAGXW+RAaGZvvwNvumxHq2ExNGwhY8 vdGHwAtCyyR4du3CU6rUN0B3hD0erSnNMwJRT/LK+1lX9k0TP7y3hsbuk8yrJe0TtmcZ 6u6A==
X-Gm-Message-State: AIVw113uF8b0/gs+hODyv7VXUuuRd/peDfYCLDhDoERmYLSzjLTz4IrI VjeJCFRLdz4U/RMh
X-Received: by 10.237.57.199 with SMTP id m65mr17560420qte.243.1500848205960;  Sun, 23 Jul 2017 15:16:45 -0700 (PDT)
Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id h41sm3886356qta.45.2017.07.23.15.16.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Jul 2017 15:16:44 -0700 (PDT)
From: Ted Lemon 
Message-Id: <9429A78D-CE9A-4627-9F04-1B7FAF87CEB4@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C56A83B5-D539-46EC-ACAF-720D2FA6C118"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 23 Jul 2017 18:16:42 -0400
In-Reply-To: <318b4504-08b3-e2db-026b-a79ea4d1aec2@huitema.net>
Cc: tls@ietf.org
To: Christian Huitema 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com> <318b4504-08b3-e2db-026b-a79ea4d1aec2@huitema.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 22:16:49 -0000

--Apple-Mail=_C56A83B5-D539-46EC-ACAF-720D2FA6C118
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Jul 23, 2017, at 5:37 PM, Christian Huitema  =
wrote:
> Speaking of threat model, one of the main threats is the "Lavabit" =
case: a server is asked to somehow implement a backdoor so existing =
clients. In that case, it is very useful for clients to detect that =
something has changed. They can move away and use another server.

Clients cannot detect this backdoor.   They can be informed of it, but =
they can't detect it.


--Apple-Mail=_C56A83B5-D539-46EC-ACAF-720D2FA6C118
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Jul 23, 2017, at 5:37 PM, Christian Huitema <huitema@huitema.net>=
 wrote:
    Speaking of threat model, one of the main =
threats is the "Lavabit" case: a server is asked to somehow implement a =
backdoor so existing clients. In that case, it is very useful for =
clients to detect that something has changed. They can move away and use =
another server.

    Clients=
 cannot detect this backdoor.   They can be informed of it, but =
they can't detect it.

    =

--Apple-Mail=_C56A83B5-D539-46EC-ACAF-720D2FA6C118--


From nobody Sun Jul 23 15:28:51 2017
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 4157D12420B for ; Sun, 23 Jul 2017 15:28:50 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 N_LSCpIDajG2 for ; Sun, 23 Jul 2017 15:28:49 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53841200FC for ; Sun, 23 Jul 2017 15:28:48 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id a9so11035824oih.0 for ; Sun, 23 Jul 2017 15:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LsTP91Kiay4vRpAyow9sE66uEg0sydjiiQG3Y3T9S10=; b=beXHhlW1kS2dwcJ4q/uFl8Zl0qBv6/Z5CedSbkUKiWEhOD6Qxx0Qzleoja9NgKITuL Y4P1htfb15k/X2u9eKNOhh77DMQVxl5jO9piOb8DY29eN7Eii0Q0tpqBmp9NIrJ5lHgO HXFnTxHiCs4UyUwk4LIkn6oeixgD/rGee26zL+1xkcDj4bnDuxtcbsho9nnN0RMFk+Ln Nx5YXmqFwimplcEkm+uRYqUGRKQoALJbDKjL4t/tSm9GZyRiIhkqmliJMLdE0TD50nO/ 2ezNv1El2uE2ioxmkpgrPyX6MFuC3lzySsLO9U9nqojZJcR0lMYKOLZwA2WFiny5ggtm Aoag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=LsTP91Kiay4vRpAyow9sE66uEg0sydjiiQG3Y3T9S10=; b=cRzR9DqtEmbcOxTBc0R1vaS1CgazPhOIyeDe5QFFkP1ntZ+woJeXrnFB7fQ5c5DcXg 0e5eOT6sDDNZgn32YGOoJ2n5VfMY7mZ+GqkbG6Vzh/iCaqURHKTaBU+k7P9vhNnrL8rW TIelMgCX5oUcyeWgoTmYSTZoiSUBCH7xPlgiOmD5aBa4sFsyr5YxW3VCYvUNGBr8QxBR k3k3FBB8+aLyin9P0RtlflLAZuowc2YVu211RB8MC3JL2RWhwh8wMY5CDjJtprmLxEsf /zlqvR2zThdZc1T6wlGG/OrLkt1e26wh0p11mC5FVgDkcrLb6KtrDjT2TItCJ5EHANWp qWJQ==
X-Gm-Message-State: AIVw113GciryHYJs0R7vQdZI0kt4cogdqLQHSUS17x6V9fAzXiIIGHdv 7I61OQMjS5GUPyBIMsnITagb4Ojvzzy/
X-Received: by 10.202.76.8 with SMTP id z8mr6333197oia.69.1500848928293; Sun, 23 Jul 2017 15:28:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.98.28 with HTTP; Sun, 23 Jul 2017 15:28:47 -0700 (PDT)
Reply-To: noloader@gmail.com
In-Reply-To: <318b4504-08b3-e2db-026b-a79ea4d1aec2@huitema.net>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com> <318b4504-08b3-e2db-026b-a79ea4d1aec2@huitema.net>
From: Jeffrey Walton 
Date: Sun, 23 Jul 2017 18:28:47 -0400
Message-ID: 
To: Christian Huitema 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 23 Jul 2017 22:28:50 -0000

On Sun, Jul 23, 2017 at 5:37 PM, Christian Huitema  wrote:
> ...
> Speaking of threat model, one of the main threats is the "Lavabit" case: a
> server is asked to somehow implement a backdoor so existing clients. In that
> case, it is very useful for clients to detect that something has changed.
> They can move away and use another server.

That existed long before LavaBit. Hushmail FTW!

I was saddened to see a Canadian company cooperate with US law
enforcement by backdooring their applet. (Give credit where credit is
due).

Jeff


From nobody Sun Jul 23 18:01:44 2017
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 F02F512F268 for ; Sun, 23 Jul 2017 18:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 R-xQRiy9M59C for ; Sun, 23 Jul 2017 18:01:40 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id B28DA129B30 for ; Sun, 23 Jul 2017 18:01:40 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6O11c36013930; Sun, 23 Jul 2017 21:01:38 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
Message-ID: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FC9EA3E-E8C1-441A-BD8B-0C6783BACF11"
MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 23 Jul 2017 21:01:37 -0400
In-Reply-To: <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>
CC: "" 
To: Ted Lemon 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>
X-Mailer: Apple Mail (2.3273)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-23_17:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707240012
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 01:01:43 -0000

--Apple-Mail=_3FC9EA3E-E8C1-441A-BD8B-0C6783BACF11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Jul 23, 2017, at 15:37, Ted Lemon  wrote:
> On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL =
> wrote:
>> I think there's no way the connection can be established if the third =
party in control of the network does not allow that.=20
>=20
> This is why it=E2=80=99s hard to reason well about this stuff=E2=80=94we=
 tend to get the threat models wrong.   The attack that negotiating =
enables is not that a third party can block all connections. They can =
always block all connections. What the attack enables is blocking only =
those connections that don=E2=80=99t negotiate a downgrade. So if you =
negotiate a downgrade, you get to look at your content, but if you =
don=E2=80=99t negotiate the downgrade, you don=E2=80=99t. This allows a =
MiTM to coerce end users into negotiating downgrades.

That is clear and AFAIK unavoidable. And not my (main) concern.

What I am trying to avoid is the ability to *surreptitiously* subvert a =
protocol that=E2=80=99s assumed to be secure. IMHO it is fine if one =
end-point is faced with a choice of either agreeing to an =
=E2=80=9Ceavesdropping=E2=80=9D connection or aborting because of no =
(remaining) common cipher-suites. What I don=E2=80=99t want to see is =
one end negotiating a connection that =E2=80=9Cshould=E2=80=9D be secure =
based on the exchange parameters, but in fact leaking keys=E2=80=A6 What =
I want in such a case is a negotiation that clearly states what has been =
done. Then the end-point would make a conscious decision to either =
connect and access data despite being surveilled, or avoid both =
surveillance and service.

> Of course the far end can just not downgrade, but it may have =
downgrading enabled either for debugging purposes, never intending that =
all connections be downgraded, or because the operator didn=E2=80=99t =
configure the server correctly. =20

My main concern is the =E2=80=9Cinvisible=E2=80=9D downgrade (that the =
operator has no say about), not an operator error.

> If it=E2=80=99s not in the standard, it can still be enabled by =
operators who are violating the end user=E2=80=99s trust, but won=E2=80=99=
t happen by accident and won=E2=80=99t be possible to coerce with a MiTM =
attack.=20

I see your point. I don=E2=80=99t share your concern, but don=E2=80=99t =
object to it either.


--Apple-Mail=_3FC9EA3E-E8C1-441A-BD8B-0C6783BACF11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

On Jul 23, 2017, at 15:37, Ted Lemon <mellon@fugue.com> =
wrote:
    On Jul =
23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> =
wrote:
    I think there's no way the connection can be established if =
the third party in control of the network does not allow =
that. 

    This is why it=E2=80=99s hard to reason =
well about this stuff=E2=80=94we tend to get the threat models wrong. =
  The attack that negotiating enables is not that a third party can =
block all connections. They can always block all connections. What the attack enables is blocking =
only those connections that don=E2=80=99t negotiate a downgrade. So if =
you negotiate a downgrade, you get to look at your content, but if you =
don=E2=80=99t negotiate the downgrade, you don=E2=80=99t. This allows a =
MiTM to coerce end users into negotiating =
downgrades.

    That =
is clear and AFAIK unavoidable. And not my (main) concern.

    What I am trying to avoid is the ability to =
*surreptitiously* subvert a protocol that=E2=80=99s assumed to be =
secure. IMHO it is fine if one end-point is faced with a choice of =
either agreeing to an =E2=80=9Ceavesdropping=E2=80=9D connection or =
aborting because of no (remaining) common cipher-suites. What I don=E2=80=99=
t want to see is one end negotiating a connection that =E2=80=9Cshould=E2=80=
=9D be secure based on the exchange parameters, but in fact leaking =
keys=E2=80=A6 What I want in such a case is a negotiation that clearly =
states what has been done. Then the end-point would make a conscious =
decision to either connect and access data despite being surveilled, or =
avoid both surveillance and service.

    Of =
course the far end can just not downgrade, but it may have downgrading =
enabled either for debugging purposes, never intending that all =
connections be downgraded, or because the operator didn=E2=80=99t =
configure the server correctly.  

    My main concern is the =E2=80=9Cinvisible=E2=80=9D =
downgrade (that the operator has no say about), not an operator =
error.

     If it=E2=80=99s not in the =
standard, it can still be enabled by operators who are violating the end =
user=E2=80=99s trust, but won=E2=80=99t happen by accident and won=E2=80=99=
t be possible to coerce with a MiTM =
attack. 

    I see =
your point. I don=E2=80=99t share your concern, but don=E2=80=99t object =
to it either.

    =

--Apple-Mail=_3FC9EA3E-E8C1-441A-BD8B-0C6783BACF11--


From felix.wyss@genesys.com  Sun Jul 23 10:17:50 2017
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 97A5E129AA0 for ; Sun, 23 Jul 2017 10:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=genesys.com header.b=k3pTYe9A; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=genesys.com header.b=K1CLqy8I
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMRc3LuIkSUy for ; Sun, 23 Jul 2017 10:17:47 -0700 (PDT)
Received: from us-smtp-delivery-154.mimecast.com (us-smtp-delivery-154.mimecast.com [216.205.24.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E254F120725 for ; Sun, 23 Jul 2017 10:17:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=genesys.com; s=mimecast20160503; t=1500830265; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=w0LHnlmx7qzJC/oEGedvKAAsudK7btjikx4o+aupGe0=; b=k3pTYe9ARVyKWTKpHqFg1Y9XSwKLRP4yOoYthEWGLbS7G8aaRsZLkXlpsRp8QjW9K7Z39JT/smSj/kg448RMKV4ahvgZxxLqV+WxNGB+10dUeuIOHW9JyJI9SqPBvbX4TfzNY2Ntu2SLkRA+P4lXSC+wbjblanydegx8/dHPsDM=
Received: from webmail-us.genesys.com (208.79.170.203 [208.79.170.203]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-105-mHelJPa3Pxi5cCyudpaFyw-2; Sun, 23 Jul 2017 13:17:44 -0400
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (207.46.163.23) by webmail-us.genesys.com (10.20.102.22) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 23 Jul 2017 10:17:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=genesys.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pulKfi3PxA21QdwgfahFS5KSJttnfZX79Hm/r64EXe4=; b=K1CLqy8I/xJ+a6/IoBagg0HcGePsb1UuIuEBO/WPsupnAMql+7j+V3/zmtRIMVG1rPw9MKO56o/erhq+42RyB9S5zdtccKbYBQbzDYaBQFcH9V4jaIIv7bf87fvY4TWrW3pkYtovzUs9YRFtjFFxcN55s6jF+eGRJ5a617PbBmo=
Received: from MWHPR1001MB2335.namprd10.prod.outlook.com (10.174.167.157) by MWHPR1001MB2333.namprd10.prod.outlook.com (10.174.167.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Sun, 23 Jul 2017 17:17:06 +0000
Received: from MWHPR1001MB2335.namprd10.prod.outlook.com ([10.174.167.157]) by MWHPR1001MB2335.namprd10.prod.outlook.com ([10.174.167.157]) with mapi id 15.01.1282.017; Sun, 23 Jul 2017 17:17:06 +0000
From: Felix Wyss 
To: Ted Lemon , "Blumenthal, Uri - 0553 - MITLL" 
CC: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB9s0c0IhkYUEqc/kGJh0JOpKJbXOSAgAACkwCAAAm5AIAAAWsAgAAB0ICAAFVNAIAABBuAgAB/KYCAAASrgIAACjOAgAAC6wCAAJbcgIAAAy4AgAADmQCAADBYAIAAA9yAgAAE6gCAAAKqAIAD0gcAgABfPwCAAB6yAIAATz8A
Date: Sun, 23 Jul 2017 17:17:05 +0000
Message-ID: 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>
In-Reply-To: <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [62.167.199.44]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR1001MB2333; 20:QjD57yDnQZbIxscWx8ccBmKYZuQHkrC4Kv920RWUFriAf8mz351NJSU2hzLos0AwdA5EnQRlEz15nll1fb1afg0FIK8nvhBh/l6cWWgh6HDNXWLCbbcYZ2ydVIljDmQuOIDaAtS3t7DSErlChydU0ZCLyN9V35h3Y9684XGmBgg=
x-ms-office365-filtering-correlation-id: e2a91ca9-7886-4787-c529-08d4d1eea4bd
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR1001MB2333; 
x-ms-traffictypediagnostic: MWHPR1001MB2333:
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR1001MB2333; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR1001MB2333; 
x-forefront-prvs: 0377802854
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39410400002)(39450400003)(39400400002)(199003)(189002)(189998001)(3280700002)(105586002)(3660700001)(93886004)(6512007)(54896002)(229853002)(6306002)(83716003)(33656002)(2906002)(86362001)(478600001)(82746002)(36756003)(97736004)(5660300001)(3846002)(72206003)(106356001)(6116002)(102836003)(14454004)(53546010)(7736002)(2900100001)(4326008)(8676002)(81156014)(81166006)(6436002)(25786009)(2171002)(6486002)(66066001)(77096006)(68736007)(8936002)(6506006)(99286003)(76176999)(54356999)(50986999)(53936002)(101416001)(38730400002)(2950100002)(6246003)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1001MB2333; H:MWHPR1001MB2335.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2017 17:17:05.9279 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 785ce69c-90cf-4dc7-a882-eaf312d1d15d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1001MB2333
X-OriginatorOrg: genesys.com
X-MC-Unique: mHelJPa3Pxi5cCyudpaFyw-2
Content-Type: multipart/alternative; boundary="_000_EC5396F698D24A0494E51618BC8A2C5Dgenesyscom_"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 05:31:55 -0000

--_000_EC5396F698D24A0494E51618BC8A2C5Dgenesyscom_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SG93IGFib3V0IHJlcXVpcmluZyBhIHJlY29yZCBvZiBhIGZpeGVkIHNpemUgdGhhdCBlaXRoZXIg
Y29udGFpbnMgdGhlIHNlc3Npb24ga2V5IGVuY3J5cHRlZCB3aXRoIGEg4oCcbGVha2luZyBrZXni
gJ0gb3IgdGhlIG91dHB1dCBvZiBhIHN0cmVhbSBjaXBoZXIga2V5ZWQgd2l0aCB0aGUgc2Vzc2lv
biBrZXkuICBBIDNyZCBwYXJ0eSBvYnNlcnZlciB3b3VsZCBub3QgYmUgYWJsZSB0byBkZXRlcm1p
bmUgd2hldGhlciB0aGUgc2Vzc2lvbiBrZXkgaXMgYmVpbmcgbGVha2VkIGJ1dCB0aGUgY2xpZW50
IGNhbiB0ZWxsIGFuZCBhY3QgYWNjb3JkaW5nbHkuDQoNCi0tRmVsaXgNCg0KRnJvbTogVExTIDx0
bHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3Vl
LmNvbT4NCkRhdGU6IFN1bmRheSwgSnVseSAyMywgMjAxNyBhdCAxNjozNA0KVG86ICJCbHVtZW50
aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEwiIDx1cmlAbGwubWl0LmVkdT4NCkNjOiAiPHRsc0BpZXRm
Lm9yZz4iIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gZGF0YWNlbnRlciBUTFMg
ZGVjcnlwdGlvbiBhcyBhIHRocmVlLXBhcnR5IHByb3RvY29sDQoNCkkgZGlkIGEgbGl0dGxlIGJp
dCBvZiBydWJiZXItZHVjayBkZWJ1Z2dpbmcgb24gdGhpcyBwcm9wb3NhbCB3aXRoIEFuZHJlYSBv
biB0aGUgd2F5IGJhY2sgZnJvbSBCb3N0b24gdGhpcyBtb3JuaW5nLiAgIEl0J3MgYWN0dWFsbHkg
YmV0dGVyIGZvciB0aGUgc2VydmVyIHRvIHNlY3JldGx5IHVzZSBhIHN0YXRpYyBrZXkgdGhhbiB0
byBuZWdvdGlhdGUuICAgU3RlcGhlbiBoYXMgYWxyZWFkeSBleHBsYWluZWQgd2h5OiBpZiB0aGlz
IGlzIGEgbmVnb3RpYXRpb24sIHRoZW4gaXQncyBwb3NzaWJsZSBmb3IgYSB0aGlyZCBwYXJ0eSB0
byBzaW1wbHkgYmxvY2sgYW55IG5lZ290aWF0aW9uIHRoYXQgZG9lc24ndCBhbGxvdyBpdC4gICBX
ZSBoYXZlIG5vIGNvbnRyb2wgb3ZlciBldmlsIGVuZHBvaW50cywgYW5kIGl0J3Mgc2lsbHkgdG8g
cHJldGVuZCBvdGhlcndpc2UuICAgUHJldGVuZGluZyBvdGhlcndpc2UgbWFrZXMgdXMgbGVzcyBz
ZWN1cmUsIG5vdCBtb3JlIHNlY3VyZS4NCg0K
--_000_EC5396F698D24A0494E51618BC8A2C5Dgenesyscom_
Content-Type: text/html; charset=UTF-8
Content-ID: <51FF2185D0A625429542FED41E8E9231@namprd10.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4
dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5
bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K
Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl
OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy
Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX
b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl
IiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91dCByZXF1aXJp
bmcgYSByZWNvcmQgb2YgYSBmaXhlZCBzaXplIHRoYXQgZWl0aGVyIGNvbnRhaW5zIHRoZSBzZXNz
aW9uIGtleSBlbmNyeXB0ZWQgd2l0aCBhIOKAnGxlYWtpbmcga2V54oCdIG9yIHRoZSBvdXRwdXQg
b2YgYSBzdHJlYW0gY2lwaGVyIGtleWVkIHdpdGggdGhlIHNlc3Npb24ga2V5LiZuYnNwOyBBIDNy
ZCBwYXJ0eSBvYnNlcnZlciB3b3VsZCBub3QgYmUgYWJsZSB0byBkZXRlcm1pbmUgd2hldGhlciB0
aGUNCiBzZXNzaW9uIGtleSBpcyBiZWluZyBsZWFrZWQgYnV0IHRoZSBjbGllbnQgY2FuIHRlbGwg
YW5kIGFjdCBhY2NvcmRpbmdseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1GZWxpeDxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh
Y2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y
OmJsYWNrIj5UTFMgJmx0O3Rscy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgVGVk
IExlbW9uICZsdDttZWxsb25AZnVndWUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXks
IEp1bHkgMjMsIDIwMTcgYXQgMTY6MzQ8YnI+DQo8Yj5UbzogPC9iPiZxdW90O0JsdW1lbnRoYWws
IFVyaSAtIDA1NTMgLSBNSVRMTCZxdW90OyAmbHQ7dXJpQGxsLm1pdC5lZHUmZ3Q7PGJyPg0KPGI+
Q2M6IDwvYj4mcXVvdDsmbHQ7dGxzQGlldGYub3JnJmd0OyZxdW90OyAmbHQ7dGxzQGlldGYub3Jn
Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1RMU10gZGF0YWNlbnRlciBUTFMgZGVjcnlw
dGlvbiBhcyBhIHRocmVlLXBhcnR5IHByb3RvY29sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBkaWQgYSBsaXR0bGUgYml0IG9mIHJ1YmJlci1kdWNrIGRl
YnVnZ2luZyBvbiB0aGlzIHByb3Bvc2FsIHdpdGggQW5kcmVhIG9uIHRoZSB3YXkgYmFjayBmcm9t
IEJvc3RvbiB0aGlzIG1vcm5pbmcuICZuYnNwOyBJdCdzIGFjdHVhbGx5IGJldHRlciBmb3IgdGhl
IHNlcnZlciB0byBzZWNyZXRseSB1c2UgYSBzdGF0aWMga2V5IHRoYW4gdG8gbmVnb3RpYXRlLiAm
bmJzcDsgU3RlcGhlbg0KIGhhcyBhbHJlYWR5IGV4cGxhaW5lZCB3aHk6IGlmIHRoaXMgaXMgYSBu
ZWdvdGlhdGlvbiwgdGhlbiBpdCdzIHBvc3NpYmxlIGZvciBhIHRoaXJkIHBhcnR5IHRvIHNpbXBs
eSBibG9jayBhbnkgbmVnb3RpYXRpb24gdGhhdCBkb2Vzbid0IGFsbG93IGl0LiAmbmJzcDsgV2Ug
aGF2ZSBubyBjb250cm9sIG92ZXIgZXZpbCBlbmRwb2ludHMsIGFuZCBpdCdzIHNpbGx5IHRvIHBy
ZXRlbmQgb3RoZXJ3aXNlLiAmbmJzcDsgUHJldGVuZGluZyBvdGhlcndpc2UgbWFrZXMgdXMNCjxp
Pmxlc3M8L2k+Jm5ic3A7c2VjdXJlLCBub3QgPGk+bW9yZTwvaT4mbmJzcDtzZWN1cmUuIDxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=
--_000_EC5396F698D24A0494E51618BC8A2C5Dgenesyscom_--


From nobody Mon Jul 24 02:28:58 2017
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 A79221317CC for ; Mon, 24 Jul 2017 02:28:56 -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 NO-DJsVnN2p3 for ; Mon, 24 Jul 2017 02:28:55 -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 16D1712EC4B for ; Mon, 24 Jul 2017 02:28:55 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id d145so41460339qkc.2 for ; Mon, 24 Jul 2017 02:28:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TqqV6cGRbSyTkrk4Xnki+Y3mlYdXTClHY1k8e3InMtU=; b=wRPAOGB9M1DAEGxSJcjP9gl4DVPcl68fe6hjsvzzBP9f/SXrZ05Cd1ojR7jm1adMlU asCRKTgELxg/SLHqvB4ana6JsgpIuAgEEi2fAhiX6iK3udulltM4sxYVEpHhdOeO5whh wErL6qCr62A57enYhaHhhTnPAvpqtDJRDp9TyU/vGg4TXvc8mEvPv8hHY07/ttsrMZdK OZ0QIQiUDJABqtIxRx2prZ6gxJr6f7d5ZQHu+8NgaK/AQ6a4/vmZjcd8HtCAeEGDXYCS QaqX0TanpNhkwcnO9su95By4rNReFYHmYDNnAGsZ97IvEhYfR3wP+rhWoa1D7EPqCZjW 8qGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TqqV6cGRbSyTkrk4Xnki+Y3mlYdXTClHY1k8e3InMtU=; b=t+e7/EaBUoiSLfczZJ+/C0yRGMhQZ9rycvxojKK8/QWqVQxdUG/0fMRw+bvWRJDRBy tMttFagYPUrKxTFCxv6jyrckHf3pXlWNVIt6p1YMuviXqR2dUi/C7z6dAoyfLuZY+Ix0 Kzu7RbhRvoi1h919ahFSSH76Kw1lpK2a/Sdwdtspo4vGddxfJEo62ez1wRNs1F8RVWVk 9Z3QfwIOfX0WBLE/tBQHYqWJi20M+ebiTwlVKrd9I07m++y9CI1g47rJ6W094CxWdnOZ RfVm1rJOUugBL+vIokEYJBunAWS8Nz8LfxkD0PccpbFPIVTeCc9UAgtCKzwCCihnNmhJ 3UzA==
X-Gm-Message-State: AIVw112oitCC+QF9sWJR/AZG5nax1+VOViQ8T8D0l2nmemkq5iJB+R2Q eavFS9FmBa/0PxJg6DFKmQ==
X-Received: by 10.55.111.2 with SMTP id k2mr20734626qkc.230.1500888534137; Mon, 24 Jul 2017 02:28:54 -0700 (PDT)
Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id l3sm1447097qkb.83.2017.07.24.02.28.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 02:28:53 -0700 (PDT)
From: Ted Lemon 
Message-Id: <388DA0F2-E3FC-47D2-B97C-D244ACE50E61@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A53E675E-CDDD-426F-AFFB-78C632D97EDF"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 24 Jul 2017 05:28:52 -0400
In-Reply-To: 
Cc: "" 
To: "Blumenthal, Uri - 0553 - MITLL" 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 09:28:57 -0000

--Apple-Mail=_A53E675E-CDDD-426F-AFFB-78C632D97EDF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL =
 wrote:
> What I am trying to avoid is the ability to *surreptitiously* subvert =
a protocol that=E2=80=99s assumed to be secure.

You don't seem to be hearing what I'm trying to say.   What you are =
proposing is physically impossible.   It is always possible to =
surreptitiously subvert the protocol.   This is not an achievable goal.  =
 What you get if you implement what you are proposing is a protocol =
that's easier for an on-path attacker to subvert, not a protocol that is =
harder for an end-point attacker to subvert.


--Apple-Mail=_A53E675E-CDDD-426F-AFFB-78C632D97EDF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL =
<uri@ll.mit.edu> =
wrote:
    What I am trying to avoid is the =
ability to *surreptitiously* subvert a protocol that=E2=80=99s assumed =
to be secure.

    You don't seem to be hearing what I'm trying to say.   =
What you are proposing is physically impossible.   It is always =
possible to surreptitiously subvert the protocol.   This is not an =
achievable goal.   What you get if you implement what you are =
proposing is a protocol that's easier for an on-path attacker to =
subvert, not a protocol that is harder for an end-point attacker to =
subvert.

    =

--Apple-Mail=_A53E675E-CDDD-426F-AFFB-78C632D97EDF--


From nobody Mon Jul 24 02:41:26 2017
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 4E83E12EC4B for ; Mon, 24 Jul 2017 02:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML41HBd6eS4d for ; Mon, 24 Jul 2017 02:41:23 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085E712EC06 for ; Mon, 24 Jul 2017 02:41:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A96FCBDD8; Mon, 24 Jul 2017 10:41:20 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qmFZhE4CF2s; Mon, 24 Jul 2017 10:41:20 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B0E0EBE2C; Mon, 24 Jul 2017 10:41:18 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500889278; bh=up75oVk3HAad9zy7HdB3yw/rF/AyZpzrGKVs46J5/Nc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gDf++ZD+gIDWoT2S38VmKA5X4/hvYVptnAg3VK+WTnl8KxsXi7ZtLDXEM1SgmdRP4 3ewQq5SstAbTfv67utpdC28JyX5DsvdVQvI6kwrmlS8OGsuJJvRnmcps39s+vc9oXT xSuCYXgxR7FMu4httit8mZO7jWdS3/Ch21rHlmm0=
To: Felix Wyss , Ted Lemon , "Blumenthal, Uri - 0553 - MITLL" 
Cc: "" 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <636eb20e-f4e4-0fac-b5da-c12ccc1d6c6b@cs.tcd.ie>
Date: Mon, 24 Jul 2017 10:41:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nrDC0gP9Tp20OiHKu9HRr5etKIi8Tu9N2"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 09:41:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--nrDC0gP9Tp20OiHKu9HRr5etKIi8Tu9N2
Content-Type: multipart/mixed; boundary="KPM3UOXVk4g87Ma3VTACgr1EAN6Gkn9pn";
 protected-headers="v1"
From: Stephen Farrell 
To: Felix Wyss , Ted Lemon ,
 "Blumenthal, Uri - 0553 - MITLL" 
Cc: "" 
Message-ID: <636eb20e-f4e4-0fac-b5da-c12ccc1d6c6b@cs.tcd.ie>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
References: 
 <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp>
 <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu>
 <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII>
 <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu>
 <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>
 
 <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>
 
In-Reply-To: 

--KPM3UOXVk4g87Ma3VTACgr1EAN6Gkn9pn
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


It's fascinating that people cannot seem to stop picking at
the scab remaining after draft-green. I really think we'd be
wiser to just let the wound heal. (And get on with the work
that this WG has been chartered to do, which does not include
wiretapping.)

On 23/07/17 18:17, Felix Wyss wrote:
> How about requiring a record of a fixed size that either contains the
> session key encrypted with a =E2=80=9Cleaking key=E2=80=9D or the outpu=
t of a stream
> cipher keyed with the session key.  A 3rd party observer would not be
> able to determine whether the session key is being leaked but the
> client can tell and act accordingly.

The relevant signal is that a TLS deployment is able to be
wiretapped. It doesn't matter how that signal is sent, via
rfc1149 or in-band. Adding your putative field (which is
eerily reminiscent of a Clipper LEAF) is such a signal, and
it doesn't matter what content is in the field today, the
"local" authorities will see that and send you the key to
use for them.

See also the many earlier points about consent, naming etc
etc.

S.

>=20
> --Felix
>=20
> From: TLS  on behalf of Ted Lemon
>  Date: Sunday, July 23, 2017 at 16:34 To:
> "Blumenthal, Uri - 0553 - MITLL"  Cc:
> ""  Subject: Re: [TLS] datacenter TLS
> decryption as a three-party protocol
>=20
> I did a little bit of rubber-duck debugging on this proposal with
> Andrea on the way back from Boston this morning.   It's actually
> better for the server to secretly use a static key than to negotiate.
> Stephen has already explained why: if this is a negotiation, then
> it's possible for a third party to simply block any negotiation that
> doesn't allow it.   We have no control over evil endpoints, and it's
> silly to pretend otherwise.   Pretending otherwise makes us less
> secure, not more secure.
>=20
>=20
>=20
> _______________________________________________ TLS mailing list=20
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>=20


--KPM3UOXVk4g87Ma3VTACgr1EAN6Gkn9pn--

--nrDC0gP9Tp20OiHKu9HRr5etKIi8Tu9N2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZdcC9AAoJEC88hzaAX42i77MIAKoBNmpZ2D13boW2m0xWTIR0
hGIrjDoBI2nDlEol/tgBjS4x8jLb30UEIBsxneAVF9sf6QO5pPvLM7zl9IT9i9gh
qDJGepS+H0Lj1wiMb5ZIRBkWvW+GslTzmxfokYTSU/tYg77b9GPF5sHtqzkL1D+e
69pQruR88848x00wtVDOJNeByvKy8UjrDUOvuYukOregZdLL0XWoR7dVdJUpnKnd
yCwhFsJyfRk5qyajuKIJbDDYrbNyIXZZnJyVYibT25le3cbs6uUOU5o1uPZNqQkx
Xa1AfZQPA5wkloxSOSl2msVV4FF2VAK+1eRni4VqvcyHdYzB3KrTlMQd2s761Jg=
=TK7f
-----END PGP SIGNATURE-----

--nrDC0gP9Tp20OiHKu9HRr5etKIi8Tu9N2--


From nobody Mon Jul 24 03:49:11 2017
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 AF802131C88 for ; Mon, 24 Jul 2017 03:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 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=-0.001, 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 U4D0ddJ39fTu for ; Mon, 24 Jul 2017 03:49:07 -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 B1FFA131C86 for ; Mon, 24 Jul 2017 03:49:07 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4A1B04DB01; Mon, 24 Jul 2017 10:49:07 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4A1B04DB01
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 4A1B04DB01
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E54107046E; Mon, 24 Jul 2017 10:49:06 +0000 (UTC)
From: Hubert Kario 
To: Benjamin Kaduk 
Cc: tls@ietf.org
Date: Mon, 24 Jul 2017 12:49:00 +0200
Message-ID: <166770404.4ZRqQnPX1I@pintsize.usersys.redhat.com>
In-Reply-To: <6f6bf32f-5c73-9213-969a-2fdf1a4c48a2@akamai.com>
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <3673860.07CCjCncdc@pintsize.usersys.redhat.com> <6f6bf32f-5c73-9213-969a-2fdf1a4c48a2@akamai.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1710038.rJCjEoHWqz"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 24 Jul 2017 10:49:07 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 10:49:10 -0000

--nextPart1710038.rJCjEoHWqz
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> On 07/21/2017 09:34 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> >> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> >>> Signature Algorithms for ECDSA now define both the curve and the hash
> >>>=20
> >>> algorithm:
> >>>           ecdsa_secp256r1_sha256(0x0403),
> >>>           ecdsa_secp384r1_sha384(0x0503),
> >>>           ecdsa_secp521r1_sha512(0x0603),
> >>>=20
> >>> This is in contrast to the TLS 1.2 protocol, where any hash can be us=
ed
> >>> with any curve.
> >>=20
> >> I assume you saw
> >> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
> >> raised a different question in this same general area.
> >>=20
> >> I do not see how the response here cannot be the same as it was there:
> >> namely, that the current formulation is assumed to have WG consensus,
> >> having been through two WGLCs; there would need to be rather strong
> >> reasons to make changes at this stage.
> >=20
> > MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory
> > (MUST)
> > and no word about any of the other two.
> >=20
> > given that we already have CAs that use P-384 for signatures. I'd say t=
his
> > is a big conflict between theory and practice.
>=20
> I'm afraid I don't understand this remark.  There is the caveat to which
> Ilari alludes, that the server can send whatever chain it has, if the
> server can't send a chain that complies with the client's
> signature_algorithms.  Since certificate validation is assumed to be
> largely a function of the PKI library and not really in scope for the
> TLS spec itself, this is not particularly problematic. =20

true; that disjoint between "stuff that TLS library is supposed to do" and=
=20
"stuff that PKI library is supposed to do" could be spelled out more=20
explicitly in the RFC though

> The other main
> usage of the signature_algorithms limits what can be used in
> CertificateVerify, which is directly relevant to TLS and depends on the
> key attested to in the certificate.  Are you claiming that there are
> servers that only possess certificates with p384 keys (i.e., no RSA or
> p256 or other fallback cert)?

Yes, there are servers that have P-384 keys. Not sure if they have a dual=20
stack (but that is unlikely as only about 30% of servers with ECDSA certs h=
ave=20
also RSA cert).


On Friday, 21 July 2017 17:00:55 CEST Ilari Liusvaara wrote:
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).

the reverse is true too - if your TLS library supports some combinations, t=
he=20
PKIX library MUST support them
=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 115, 612 00  Brno, Czech Republic
--nextPart1710038.rJCjEoHWqz
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

iQIcBAABCgAGBQJZddCcAAoJEJKo0bgB0vX1F6cP/3bLv8Gzr18IZRRXZh3RJg2P
8U1VHavsKHdwbJES031c9h7j34OGYuvcni9SY4b51PPMei5HJCmzx/C2shR+3ZJp
GoWjnn6WKWS6jfVgk13/ADbmIGg9t5lnH53WfS3XYftseQqIa2Z0BlRpWaTmPcZj
IvTBFNH6bcdAL+pgkhlgU6XYfKfna6Ocd/kwUrSCnC3D7ifcozk3DFKZAFmC4dp4
wtdA0xst1mw6+KwldrL5JVYxra0j5CMv6sGMfFOCk5pfe+ey91yNw5no++nM0I31
DBLxhSeayGq2NEFxaw4nh1hmDC7UBwFFUBLrs1wNHVE/Z8JPe7XuGzBd7hJkm/HX
ZPAsbMY9WkVIUZOoa9sUa94LzbPGUZ38tYin4Vn1DF/hffIP8XeAD2KWW8K/OetU
ew3Elr3HbwdQYHwD9TjbEfPg+NsxVCLXcNTKrSHaOUmnXXPG4Ee+NwDkzpWNvmFF
lEjQfjh0W4b5ywnDN6hOGsIb4I8QtRbQyUX/PZRCr4dQ7AZ6k01etEDSnqu3qqop
23A4hGm8pVsrxNt/E166i/3LxoyJHU+6DrpAGlxFMnCnvNXpQwgqV5kM1KCmnXmD
TtYcGrris295lJV0Wyo+AQjQrNXh8qOfBt7c0AmOjEsLbKp8/GJeIRSR+E4oOzZY
7MBw3DOk/8P3CGd/Wlar
=bSAi
-----END PGP SIGNATURE-----

--nextPart1710038.rJCjEoHWqz--


From nobody Mon Jul 24 06:09:58 2017
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 ED632131CED for ; Mon, 24 Jul 2017 06:09: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, 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=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 QtkpoPWJ_xZi for ; Mon, 24 Jul 2017 06:09:54 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 61EFA1276AF for ; Mon, 24 Jul 2017 06:09:54 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6OD6jxD030825; Mon, 24 Jul 2017 14:09:52 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=8RxQfp4a+JZ0P5w4H+eN+uQ17P+PUciBiOp6L+LIMI0=; b=FUp1WBaTUnAhsWxXA01djDFqSs2RsyEB5SR4uY4hMQgZfx0Mc+4LuIo5J/cTDccbzsj2 EeLO27lPubwGctBdkxow6qqi/ndH2U7+tdcuLCCxPw6O9mU9n+OsClde1Za8N6nZPqM4 Gf/lXBlP7Wd6RTunLi4sl3HH+mV381LSbkaMKTQk+9ggxA5KuCtFwtW+y3gZ7auX8Ji9 kYke+i/9YtZklZcwJcsC/IjTIRyWgB4cio/J9MqO91gFZOCkA3CimENAhUwjxHjZFgKH bH4gRSSDnGXZ997tW859hgP3KKQpXfjA+xD6kNydISuU15yPvLTtnclsss1d9CeVeSiu Dw== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2bux87qu6j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 14:09:52 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6OD62Cc013816; Mon, 24 Jul 2017 09:09:50 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bv21vc76t-1; Mon, 24 Jul 2017 09:09:49 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 7E34580063; Mon, 24 Jul 2017 07:09:49 -0600 (MDT)
To: Hubert Kario 
Cc: tls@ietf.org
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <3673860.07CCjCncdc@pintsize.usersys.redhat.com> <6f6bf32f-5c73-9213-969a-2fdf1a4c48a2@akamai.com> <166770404.4ZRqQnPX1I@pintsize.usersys.redhat.com>
From: Benjamin Kaduk 
Message-ID: <19a5f6c2-20fd-3bf9-f40c-4684c5cbf4f2@akamai.com>
Date: Mon, 24 Jul 2017 08:09:48 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <166770404.4ZRqQnPX1I@pintsize.usersys.redhat.com>
Content-Type: multipart/alternative; boundary="------------90E0147FAD1D1B64755DE6C8"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707240201
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240201
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 13:09:56 -0000

This is a multi-part message in MIME format.
--------------90E0147FAD1D1B64755DE6C8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/24/2017 05:49 AM, Hubert Kario wrote:
> On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
>> I'm afraid I don't understand this remark. There is the caveat to which
>> Ilari alludes, that the server can send whatever chain it has, if the
>> server can't send a chain that complies with the client's
>> signature_algorithms.  Since certificate validation is assumed to be
>> largely a function of the PKI library and not really in scope for the
>> TLS spec itself, this is not particularly problematic.  
> true; that disjoint between "stuff that TLS library is supposed to do" and 
> "stuff that PKI library is supposed to do" could be spelled out more 
> explicitly in the RFC though

I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
don't have high hopes that it won't just get closed with no action.

>> The other main
>> usage of the signature_algorithms limits what can be used in
>> CertificateVerify, which is directly relevant to TLS and depends on the
>> key attested to in the certificate.  Are you claiming that there are
>> servers that only possess certificates with p384 keys (i.e., no RSA or
>> p256 or other fallback cert)?
> Yes, there are servers that have P-384 keys. Not sure if they have a dual 
> stack (but that is unlikely as only about 30% of servers with ECDSA certs have 
> also RSA cert).

To clarify, you are arguing that P-384 should also be listed as MTI?

-Ben

--------------90E0147FAD1D1B64755DE6C8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 07/24/2017 05:49 AM, Hubert Kario wrote:
    
    
    
      
    On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:

    
      
    I'm afraid I don't understand this remark.
        There is the caveat to which
        
    Ilari alludes, that the server can send whatever chain it has, if the
server can't send a chain that complies with the client's
signature_algorithms.  Since certificate validation is assumed to be
largely a function of the PKI library and not really in scope for the
TLS spec itself, this is not particularly problematic.  

    
      
    
      
    true; that disjoint between "stuff that TLS library is supposed to do" and 
"stuff that PKI library is supposed to do" could be spelled out more 
explicitly in the RFC though

    
    
    
    
    
    I pasted that into https://github.com/tlswg/tls13-spec/issues/1062
    but I don't have high hopes that it won't just get closed with no
    action.
    
    
    
    
    
      
    
      
    
        
    The other main
usage of the signature_algorithms limits what can be used in
CertificateVerify, which is directly relevant to TLS and depends on the
key attested to in the certificate.  Are you claiming that there are
servers that only possess certificates with p384 keys (i.e., no RSA or
p256 or other fallback cert)?

    
      
    
      
    Yes, there are servers that have P-384 keys. Not sure if they have a dual 
stack (but that is unlikely as only about 30% of servers with ECDSA certs have 
also RSA cert).

    
    
    
    
    
    To clarify, you are arguing that P-384 should also be listed as MTI?
    
    
    
    -Ben
    
  


--------------90E0147FAD1D1B64755DE6C8--


From nobody Mon Jul 24 06:48:35 2017
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 B7E52131771; Mon, 24 Jul 2017 06:48:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 plLUuvVe6uiO; Mon, 24 Jul 2017 06:48:32 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20EA31294A2; Mon, 24 Jul 2017 06:48:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLF05757; Mon, 24 Jul 2017 13:48:29 +0000 (GMT)
Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 24 Jul 2017 14:48:27 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.23]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Mon, 24 Jul 2017 19:18:14 +0530
From: Raja ashok 
To: "draft-ietf-tls-rfc4492bis@ietf.org" ,  "ynir.ietf@gmail.com" , "simon@josefsson.org" , "mpg@elzevir.fr" 
CC: "" 
Thread-Topic: Doubts in draft-ietf-tls-rfc4492bis 
Thread-Index: AdMEg33Y1sNXVb48TGyzduKZxxrIdA==
Date: Mon, 24 Jul 2017 13:48:13 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.213.121]
Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2301151BLREML503MBXchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.5975FAAD.00E9, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.9.23, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4f8ac3bb38c9d632011c8f52bcd84687
Archived-At: 
Subject: [TLS] Doubts in draft-ietf-tls-rfc4492bis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 13:48:34 -0000

--_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2301151BLREML503MBXchi_
Content-Type: multipart/alternative;
	boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2301151BLREML503MBXchi_"

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2301151BLREML503MBXchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgTmlyLCBKb3NlZnNzb24gJiBQZWdvdXJpZSwNCg0KQXMgcGVyIHNlY3Rpb24gNS4yIHNlcnZl
ciBzaG91bGQgc2VuZCBvbmx5ICJTdXBwb3J0ZWQgUG9pbnQgRm9ybWF0IiBleHRlbnNpb25zIGlu
IHNlcnZlciBoZWxsbyBtZXNzYWdlLiBBbmQgaXQgZG9lc24ndCByZXF1aXJlIHRvIHNlbmQgIlN1
cHBvcnRlZCBFbGxpcHRpYyBDdXJ2ZSIgZXh0ZW5zaW9ucy4gQmVjYXVzZSBvZiB0aGlzIGlmIHNl
cnZlciBpcyBzdXBwb3J0aW5nIG9ubHkgZmV3IEN1cnZlcyBhbmQgaWYgaXQgcmVjZWl2ZXMgdW5z
dXBwb3J0ZWQgRWxsaXB0aWMgY3VydmUgaW4gY2xpZW50IGNlcnRpZmljYXRlIG1lc3NhZ2UsIHRo
ZW4gc2VydmVyIG1pZ2h0IG5vdCBiZSBhYmxlIHRvIGNvbnRpbnVlIHRoZSBoYW5kc2hha2UuDQpU
aGlzIG1ha2VzIChEKVRMUyBzZXJ2ZXIgc2hvdWxkIG1hbmRhdG9yeSBpbXBsZW1lbnQgYWxsIHRo
ZSBjdXJ2ZXMgbWVudGlvbmVkIGluICJOYW1lZEN1cnZlIi4gQnV0IEkgZmVlbCBtYW5kYXRpbmcg
KEQpVExTIHNlcnZlciB0byBzdXBwb3J0IGFsbCBOYW1lZEN1cnZlIGlzIG5vdCBmZWFzaWJsZSwg
YXMgaW4gZnV0dXJlIGlmIG5ldyBuYW1lZCBjdXJ2ZXMgYXJlIGRlZmluZWQgdGhlbiB1cGRhdGlu
ZyBsZWdhY3kgc2VydmVyIGlzIG5vdCBlYXN5LiBBbmQgYWxzbyBjb25zdHJhaW50IChEKVRMUyBz
ZXJ2ZXIgZ2VuZXJhbGx5IGRvZXNuJ3Qgc3VwcG9ydCBhbGwgdGhlIGN1cnZlcy4NClBsZWFzZSBw
cm92aWRlIHlvdXIgc3VnZ2VzdGlvbiBvbiB0aGlzLiBJZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdy
b25nLCBwbGVhc2UgY29ycmVjdCBtZS4NCg0KUmVnYXJkcywNCkFzaG9rDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpbQ29tcGFueV9sb2dvXQ0KDQpSYWphIEFzaG9rIFYgSw0K
SHVhd2VpIFRlY2hub2xvZ2llcw0KQmFuZ2Fsb3JlLCBJbmRpYQ0KaHR0cDovL3d3dy5odWF3ZWku
Y29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ksb7Tyrz+vLDG5Li9vP66rNPQ
u6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX
6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw/MCotauyu8/e09rIq7K/u/Kyv7fW
tdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQq1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8
/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhDQpUaGlzIGUtbWFp
bCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZy
b20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRp
dHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1h
dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1p
dGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRp
c3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVu
dChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwg
cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBh
bmQgZGVsZXRlIGl0IQ0KDQo=

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2301151BLREML503MBXchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable









    

    Hi Nir, Josefsson & Pegourie,
    

     
    

    As per section 5.2 server should send only "Sup=
ported Point Format" extensions in server hello message. And it doesn'=
t require to send "Supported Elliptic Curve" extensions. Because =
of this if server is supporting only few Curves and if
 it receives unsupported Elliptic curve in client certificate message, then=
 server might not be able to continue the handshake.

    

    

    This makes (D)TLS server should mandatory implement =
all the curves mentioned in "NamedCurve". But I feel mandating (D=
)TLS server to support all NamedCurve is not feasible, as in future if new =
named curves are defined then updating legacy
 server is not easy. And also constraint (D)TLS server generally doesn't su=
pport all the curves.
    

    

    Please provide your suggestion on this. If my unders=
tanding is wrong, please correct me.
    

     
    

    Regards,
    

    Ashok
    

     
    

    

    

    

    3D"Company_logo"
    

    
Raja Ashok V K
    
    Huawei Technologies
    
Bangalore, India
    
http://www.huawei.com 
    

    

    

    

    =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=
=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=
=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=
=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
    
    =D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=
=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=
=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=
=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
    
    =B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=
=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=
=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=
=A1
    
    This e-mail and its attachments contain confide=
ntial information from HUAWEI, which

    
is intended only for the person or entity whose address is listed above. An=
y use of the

    
information contained herein in any way (including, but not limited to, tot=
al or partial

    
disclosure, reproduction, or dissemination) by persons other than the inten=
ded 
    
recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by

    
phone or email immediately and delete it!
    

     
    

    



--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2301151BLREML503MBXchi_--

--_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2301151BLREML503MBXchi_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=6737;
	creation-date="Mon, 24 Jul 2017 13:48:13 GMT";
	modification-date="Mon, 24 Jul 2017 13:48:13 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA
AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA
AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA
AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB
AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A
AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA////////
/////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD/////////
////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA
AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A
AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA
AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg
AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS
AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF
U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA
AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA
TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA
AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA
AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB
bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA
AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl
QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u
ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN
BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA
AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM
QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT
ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O
Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB
IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB
AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR
obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF
tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR
AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV
NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA
AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6
6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs
VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns
U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9
w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh
fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX
146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh
SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t
bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo
JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb
qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv
/QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F
ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4
HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v
6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m
+u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6
tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ
JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r
WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z
OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB
AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA
AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq
AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8
CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox
ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA
BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB
AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf
Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM
DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM
DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED
EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA
AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV
UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0
pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB
UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz
hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/
APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3
0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl
/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP
UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+
qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW
9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq
FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp
VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku
cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf
Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0
PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C
OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us
XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j
QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6
jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n
0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT
gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf
UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj
Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI
BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04
MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA
AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh
CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp
anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV
1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK
C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy
0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm
5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge
ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn
yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr
aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g
dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf
03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l
6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo
9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai
uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45
RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV
zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc
TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM
v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S
reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8
V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM
qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/
thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le
LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x
ke3tRX0lRQB//9k=

--_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2301151BLREML503MBXchi_--


From nobody Mon Jul 24 07:03:41 2017
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 B4984131828 for ; Mon, 24 Jul 2017 07:03:39 -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=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 C38zgRURebkW for ; Mon, 24 Jul 2017 07:03:37 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 5DFDA127B60 for ; Mon, 24 Jul 2017 07:03:37 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6OE2Kg2006535; Mon, 24 Jul 2017 15:03:30 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding; s=jan2016.eng; bh=j7Amxi1RXoETGAX5ZzOG35TCyCWHQFZZe0OGRb4x+Jg=; b=RAHP5+L9Dx7Ja854xQ5DQ8fhzjsTq0gFg6aGroUU1e2GU7S/0p0mNjeKFjrWUaQa+9hs Mhhg8qZkN89IpxwhBAniPz4LfeFTt3hwVK5d/r6fGfg0SEp642IBDSsa+b3xF6fXfL4w n3i/yyBZHuL8W4badk3lDJY9V6dICIJizV2bbfKQ03x4BpplRIKVTji1Kc1WzILD8sA1 BwqlT08sPm49CGP09IR/L3ZeYCzvXGIOoTnhxV34cEDJbz+OanyQZhB7qUktOMnFFMGP EYSAhdsbm2/azW5WKOUNKs4Pu8WZXrTfAwg9C4qve0lMWBFZ0u1kvbvXjXxiF1CpzSn7 JA== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2buy49yvbc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 15:03:30 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6OE0fZh015634; Mon, 24 Jul 2017 10:03:29 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bv21vcb82-1; Mon, 24 Jul 2017 10:03:29 -0400
Received: from bos-mpeve.kendall.corp.akamai.com (blr-wpxnq.kendall.corp.akamai.com [172.19.32.175]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 9C2242006A; Mon, 24 Jul 2017 08:03:28 -0600 (MDT)
From: Brian Sniffen 
To: Ted Lemon , "Blumenthal\, Uri - 0553 - MITLL" 
Cc: "\" 
In-Reply-To: <388DA0F2-E3FC-47D2-B97C-D244ACE50E61@fugue.com>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>  <388DA0F2-E3FC-47D2-B97C-D244ACE50E61@fugue.com>
Date: Mon, 24 Jul 2017 10:03:28 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240217
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240217
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 14:03:40 -0000

Ted Lemon  writes:

> On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL  wrote:
>> What I am trying to avoid is the ability to *surreptitiously* subvert a =
protocol that=E2=80=99s assumed to be secure.
>
> You don't seem to be hearing what I'm trying to say.   What you are
> proposing is physically impossible.

Is it?  I could imagine making the server ECDH share dependent on the
client ECDH share, plus a local random value.  At the end of the
session, the server discloses that random value, showing that it
properly constructed a fresh ECDH share.

Then the client has an opportunity to notice---this session didn't have
a (retrospective) proof of proper generation of the server ECDH share,
and so may involve key reuse in a dangerous way.

This doesn't stop the server from logging the session key, of course.

I *think* the shape I describe above fits into an extension, so (a) it
doesn't have to be done to ship TLS 1.3, and (b) it can be available for
use in general purpose browsers, and then disabled for the "enterprise"
case, and (c) I don't have to worry through the performance implications
of not being able to pre-generate a stack of ECDH shares.

-Brian

--=20
Brian Sniffen 
Information Security: Safety, Adversarial Resilience, Tools, Compliance
/(* Akamai - Faster Forward


From nobody Mon Jul 24 07:19:15 2017
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 B565613167B for ; Mon, 24 Jul 2017 07:19: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 LYQJp2fcSNWI for ; Mon, 24 Jul 2017 07:19:11 -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 41BCE127B60 for ; Mon, 24 Jul 2017 07:19:11 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id k2so13788370qkf.0 for ; Mon, 24 Jul 2017 07:19:11 -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=rEjRQRxPIJ1yNhKov87XhqmTKJnpwc7oPVBpU1i7/SQ=; b=TjJVDx5l0f80YqjDJxD1M6B7p5O7WGrzIUVee4V/p3PyxHkA5L0B9KHjP+fRIIdkBA NWZEJgkgLgf/c4AdKQ6ULuzwf/+uCp/Kz+x3Rv/zmbAMXp5tZH6eZ95ikJit7ujnnSQp HqsXeTG2YECXqZ5EMqcZphFCbEfZhdhZZJ6sM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rEjRQRxPIJ1yNhKov87XhqmTKJnpwc7oPVBpU1i7/SQ=; b=laaWRU6/nsCWBwSX8QUKCiJQ5Y1I0gl7He1Yr4BzE3GEBAQySE61YwmcYvmnPCQNxy nmjz0+CjfNm50usntluvkoLXcktj7DJO+3Rm9w2V/MjXK6RXwdjWTxkuY7T7Ghu9AOUx GT2nEIemKrlnd+OZIfJLwuus4+PUn/OoCOYCDZdl/jvcbx7RA0ELWyOI/GtF6sJvLnPT NHlSbIZLr9QwmReDtnqDRH1SLZoO/qht3nfq60oHfBsru79RZ8+KV63LOcCB2dN0AJNe TSfdvCpgKPYq3ouCVpvVt4zwcLOowROxUbWfz1oGpAAJOWcED72ly7/8kHSfptAtrwTu +Y/w==
X-Gm-Message-State: AIVw1139CXAADHAV9cNihJJSfeftHFpPO0GA4jYpBdqju3Nwn/pXoLFo z0q64aJF7Aw26Kj1fmdV4+M69Z4lGu6L
X-Received: by 10.55.112.71 with SMTP id l68mr9078964qkc.10.1500905950014; Mon, 24 Jul 2017 07:19:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.128.194 with HTTP; Mon, 24 Jul 2017 07:19:09 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>  <388DA0F2-E3FC-47D2-B97C-D244ACE50E61@fugue.com> 
From: Kyle Rose 
Date: Mon, 24 Jul 2017 10:19:09 -0400
Message-ID: 
To: Brian Sniffen 
Cc: Ted Lemon , "Blumenthal, Uri - 0553 - MITLL" , "" 
Content-Type: multipart/alternative; boundary="001a114fdedefe22a9055510e563"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 14:19:14 -0000

--001a114fdedefe22a9055510e563
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen  wrote=
:

> Ted Lemon  writes:
>
> > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL <
> uri@ll.mit.edu> wrote:
> >> What I am trying to avoid is the ability to *surreptitiously* subvert =
a
> protocol that=E2=80=99s assumed to be secure.
> >
> > You don't seem to be hearing what I'm trying to say.   What you are
> > proposing is physically impossible.
>
> Is it?  I could imagine making the server ECDH share dependent on the
> client ECDH share, plus a local random value.  At the end of the
> session, the server discloses that random value, showing that it
> properly constructed a fresh ECDH share.
>
> Then the client has an opportunity to notice---this session didn't have
> a (retrospective) proof of proper generation of the server ECDH share,
> and so may involve key reuse in a dangerous way.
>
> This doesn't stop the server from logging the session key, of course.
>

Of course, this is precisely the point. All your proposal does is
complicate the process of sharing sessions with a third-party: it doesn't
stop an endpoint from surreptitiously doing evil. (Your proposal is
interesting, but because it neatly solves the problem of DH share reuse
without requiring some kind of CT-like infrastructure, not because it
somehow addresses the evil endpoint problem. On the downside, it also may
have implications for amplification DoS.)

Kyle

--001a114fdedefe22a9055510e563
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On M=
on, Jul 24, 2017 at 10:03 AM, Brian Sniffen <bsniffen@akamai.com&g=
t; wrote:
    Ted Lem=
on <mellon@fugue.com> writes:=

    

    
> On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
    
>> What I am trying to avoid is the ability to *surreptitiously* subv=
ert a protocol that=E2=80=99s assumed to be secure.
    
>
    
> You don't seem to be hearing what I'm trying to say.=C2=A0 =C2=
=A0What you are
    
> proposing is physically impossible.
    

    
    Is it?=C2=A0 I could imagine making the server ECDH share dependent =
on the
    
client ECDH share, plus a local random value.=C2=A0 At the end of the
    
session, the server discloses that random value, showing that it
    
properly constructed a fresh ECDH share.
    

    
Then the client has an opportunity to notice---this session didn't have=

    
a (retrospective) proof of proper generation of the server ECDH share,
    
and so may involve key reuse in a dangerous way.
    

    
This doesn't stop the server from logging the session key, of course.

    Of course, this is precisely the point. =
All your proposal does is complicate the process of sharing sessions with a=
 third-party: it doesn't stop an endpoint from surreptitiously doing ev=
il. (Your proposal is interesting, but because it neatly solves the problem=
 of DH share reuse without requiring some kind of CT-like infrastructure, n=
ot because it somehow addresses the evil endpoint problem. On the downside,=
 it also may have implications for amplification DoS.)

    <=
div class=3D"gmail_quote">Kyle
    

--001a114fdedefe22a9055510e563--


From nobody Mon Jul 24 07:27:48 2017
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 DD7F1131D2E for ; Mon, 24 Jul 2017 07:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 CQV87cpYRD5M for ; Mon, 24 Jul 2017 07:27:45 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5079131D2C for ; Mon, 24 Jul 2017 07:27:45 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Mon, 24 Jul 2017 08:27:44 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Mon, 24 Jul 2017 08:27:44 -0600
From: Paul Turner 
To: Stephen Farrell , Felix Wyss , Ted Lemon , "Blumenthal, Uri - 0553 - MITLL" 
CC: "" 
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQLjIzDh+DfM73wUWUCicUafPHZk8gIxXkcLAod5MSYCHjiQVgFemIY0AcHCQMABGLREcgIXSjIvAjM4Da8CjXjxxJ+zYq6g
Date: Mon, 24 Jul 2017 14:27:44 +0000
Message-ID: <855f7890734c4bdb9d65ce961712a6e0@venafi.com>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <636eb20e-f4e4-0fac-b5da-c12ccc1d6c6b@cs.tcd.ie>
In-Reply-To: <636eb20e-f4e4-0fac-b5da-c12ccc1d6c6b@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [174.228.131.57]
Content-Type: multipart/alternative; boundary="_000_855f7890734c4bdb9d65ce961712a6e0venaficom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 14:27:47 -0000

--_000_855f7890734c4bdb9d65ce961712a6e0venaficom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCkl0J3MgZmFzY2luYXRpbmcgdGhhdCBwZW9wbGUgY2Fubm90IHNlZW0gdG8gc3RvcCBwaWNr
aW5nIGF0IHRoZSBzY2FiIHJlbWFpbmluZyBhZnRlciBkcmFmdC1ncmVlbi4gSSByZWFsbHkgdGhp
bmsgd2UnZCBiZSB3aXNlciB0byBqdXN0IGxldCB0aGUgd291bmQgaGVhbC4gKEFuZCBnZXQgb24g
d2l0aCB0aGUgd29yayB0aGF0IHRoaXMgV0cgaGFzIGJlZW4gY2hhcnRlcmVkIHRvIGRvLCB3aGlj
aCBkb2VzIG5vdCBpbmNsdWRlDQoNCndpcmV0YXBwaW5nLikNCg0KDQoNClNvcnJ5IHRvIGFzayBm
b3IgdGhpcyBzbyBsYXRlIGluIHRoZSBjb252ZXJzYXRpb24gYnV0IGNhbiB5b3UgcG9pbnQgbWUg
dG8gdGhlIGRlZmluaXRpb24gb2YgdGhlIHRlcm0g4oCcd2lyZXRhcHBpbmfigJ0geW914oCZcmUg
dXNpbmc/DQoNCg0KDQpQYXVsDQo=

--_000_855f7890734c4bdb9d65ce961712a6e0venaficom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp
Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JdCdzIGZhc2Np
bmF0aW5nIHRoYXQgcGVvcGxlIGNhbm5vdCBzZWVtIHRvIHN0b3AgcGlja2luZyBhdCB0aGUgc2Nh
YiByZW1haW5pbmcgYWZ0ZXIgZHJhZnQtZ3JlZW4uIEkgcmVhbGx5IHRoaW5rIHdlJ2QgYmUgd2lz
ZXIgdG8ganVzdCBsZXQgdGhlIHdvdW5kIGhlYWwuIChBbmQgZ2V0IG9uIHdpdGggdGhlIHdvcmsg
dGhhdCB0aGlzIFdHIGhhcyBiZWVuIGNoYXJ0ZXJlZA0KIHRvIGRvLCB3aGljaCBkb2VzIG5vdCBp
bmNsdWRlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+d2lyZXRhcHBpbmcuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Tb3JyeSB0byBhc2sgZm9yIHRoaXMg
c28gbGF0ZSBpbiB0aGUgY29udmVyc2F0aW9uIGJ1dCBjYW4geW91IHBvaW50IG1lIHRvIHRoZSBk
ZWZpbml0aW9uIG9mIHRoZSB0ZXJtIOKAnHdpcmV0YXBwaW5n4oCdIHlvdeKAmXJlIHVzaW5nPw0K
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGF1bDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_855f7890734c4bdb9d65ce961712a6e0venaficom_--


From nobody Mon Jul 24 07:29:26 2017
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 D3552131D2E for ; Mon, 24 Jul 2017 07:29:24 -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=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 w0Yn9al6CUGj for ; Mon, 24 Jul 2017 07:29:23 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 5F912131D2C for ; Mon, 24 Jul 2017 07:29:23 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6OEQrtR017296; Mon, 24 Jul 2017 15:29:18 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type; s=jan2016.eng; bh=QkAOGyZiDo4qvjCfZKYUaUVDKHPpCYO6SZ09Zr77ack=; b=PtvGRCZTL7nscrmkfqFxNCc1i8MUkoDUi6frI331qBC/6+1SsMEbxjEQDWyDmwucq0CT TIpmmSVPtLK+8zuIU0cQ/mxQvdbJ2oXSWMPDluPktMJaeEJSZGzWrL24uPNZx661Zmmf HDOioJAiyvKe2bvmOyaM/x2aqgd0d+4XnsSEdUnbJ7QPXdihuUvIrGINOAz/l4zfXffw 5BRnbIbURPfoh/w/N8NOt8UDUSPRpE111ef82+7CGCv2EZDZYcVxFM4pzCIhIKEfoIvl iQn5BiL/gFL7EutqkGc2D/rZC3digvgO7ugYHOEaZne2i4CJpBTyX6YH6mAL/Mv7qWEB Pg== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2buusb0je7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 15:29:18 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6OEQUHo005903; Mon, 24 Jul 2017 10:29:18 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bv21ue88x-1; Mon, 24 Jul 2017 10:29:17 -0400
Received: from bos-mpeve.kendall.corp.akamai.com (blr-wpxnq.kendall.corp.akamai.com [172.19.32.175]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id D291D1FC71; Mon, 24 Jul 2017 14:29:17 +0000 (GMT)
From: Brian Sniffen 
To: Kyle Rose 
Cc: Ted Lemon , "Blumenthal\, Uri - 0553 - MITLL" , "\" 
In-Reply-To: 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>  <388DA0F2-E3FC-47D2-B97C-D244ACE50E61@fugue.com>  
Date: Mon, 24 Jul 2017 10:29:17 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240224
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240224
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 14:29:25 -0000

Kyle Rose  writes:

> On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen  wrote:
>
>> I could imagine making the server ECDH share dependent on the
>> client ECDH share, plus a local random value.  At the end of the
>> session, the server discloses that random value, showing that it
>> properly constructed a fresh ECDH share.
>>
>> Then the client has an opportunity to notice---this session didn't have
>> a (retrospective) proof of proper generation of the server ECDH share,
>> and so may involve key reuse in a dangerous way.
>>
>> This doesn't stop the server from logging the session key, of course.
>>
>
> Of course, this is precisely the point. All your proposal does is
> complicate the process of sharing sessions with a third-party: it doesn't
> stop an endpoint from surreptitiously doing evil.

Yes, but it adds a storage requirement in proportion to the number of
evil acts taken.  For the same reason we find large-key cryptography
interesting---now the adversary has to smuggle out megabytes---we might
like this.

> (Your proposal is
> interesting, but because it neatly solves the problem of DH share reuse
> without requiring some kind of CT-like infrastructure, not because it
> somehow addresses the evil endpoint problem. On the downside, it also may
> have implications for amplification DoS.)

Yes: I'd expect a large operator to drop support for this extension
under load, exactly when they switch to pre-generated ECDH keys.  When
they must further switch to re-used keys, that will be silent.

Conversation elsewhere raises a practical point: browsers don't want to
alert the user on every aborted connection.  But a bad server can
accept&send this extension, reuse a ECDH share, and then RST the
connection rather than properly terminate it.  All I can offer there is
the idea that the client *should* alert when *it* closes the connection
and doesn't get back a proof of proper key generation.

-Brian

-- 
Brian Sniffen 
Information Security: Safety, Adversarial Resilience, Tools, Compliance
/(* Akamai - Faster Forward


From nobody Mon Jul 24 07:33:37 2017
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 C9FFA131D2F for ; Mon, 24 Jul 2017 07:33:36 -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=equio-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 Y6r--exPI7sQ for ; Mon, 24 Jul 2017 07:33:35 -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 474E9131D2C for ; Mon, 24 Jul 2017 07:33:35 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id j32so23196793iod.0 for ; Mon, 24 Jul 2017 07:33:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=equio-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=YuDt4gAr2iKjW07D16Ceu9KhKGNg8J6T1SVlqUn/3WI=; b=s69KqiZnGNjrwndvYoXvJlkpEsWlU5P7WOhuw8wX5x9kKBHcju8mto6riEG6Xatg3n t5doB/IdxL8tYMZbd6Jm21+2KCv6QHN9wfnoE94nSPcjGNryjcr95OwAJTuIP5eqrgTJ f0CeGn1DMAMO0c5IpqaL8vhTecRt+2rll/RLqqnu3kto6qZfI9swExZdTZJKSiOegHSd CNUHtdVTluN4EowUSwt1xzYyBitw8VZy8/lTSXkaxRSsVFc0ukoUB79HieogCLtc9Sjj QqeWDXAtFSQdiRnC8dNKISynS1dYIUI7ZHxeaN7GT070+LSvmSAE55LRML6V1xl/16QH gPvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=YuDt4gAr2iKjW07D16Ceu9KhKGNg8J6T1SVlqUn/3WI=; b=A2N0QlNv4wM10gXz9hbvCy+x2cnj0Xv/b0SAu7+7rwhAjjNqFNWVjm6+dF8NUda3Q4 53zEm86Tgkd5E7gDnxxRvJsfWxZ8hVnFx3o2kQIuJjVRDI054xE5ZCgltc4taGCc+b92 kpRv+tD+B0KWSfEykJZZNAiTLkpO3k0Jac4UgOw1wToiU+4xMNdHeMGD8QuISQCG86p7 2sa8h6Vol+cEl13qmSwjEPiDxssKlJJCqz/ODJKl+biWFmowlI1sR3Au/EXLwaltVRHu gDfPa9zteAbe74amqLH7deQm2QPBq1cbHW546RMlP3xDRDk1GNhhfNDyiuXUoUL5gGDe b4vg==
X-Gm-Message-State: AIVw111yP1Cdvs+1gnBqbCjxpcSb/ZlQkHVaoAsZyDTn8oGBYWYMkF6V fjWsvUaToOau0Pez
X-Received: by 10.107.137.30 with SMTP id l30mr17294416iod.279.1500906814629;  Mon, 24 Jul 2017 07:33:34 -0700 (PDT)
Received: from 07WKSWIN150119 (57.sub-174-228-131.myvzw.com. [174.228.131.57]) by smtp.gmail.com with ESMTPSA id u67sm4916865ioi.68.2017.07.24.07.33.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 07:33:33 -0700 (PDT)
From: "Paul Turner" 
To: "'Kyle Rose'" , "'Brian Sniffen'" 
Cc: 
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>  <388DA0F2-E3FC-47D2-B97C-D244ACE50E61@fugue.com>  
In-Reply-To: 
Date: Mon, 24 Jul 2017 10:33:14 -0400
Message-ID: <044801d30489$d62e3720$828aa560$@equio.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0449_01D30468.4F1F0820"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQLjIzDh+DfM73wUWUCicUafPHZk8gIxXkcLAod5MSYCHjiQVgFemIY0AcHCQMABGLREcgIXSjIvAuyAMowBpmNuTAGvqFrLAqrWDH8BhwVpKgGpUFbUn3ijLAA=
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 14:33:37 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0449_01D30468.4F1F0820
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=20

Of course, this is precisely the point. All your proposal does is =
complicate the process of sharing sessions with a third-party: it =
doesn't stop an endpoint from surreptitiously doing evil.

=20

Is the objective to have the protocol prevent an endpoint =
=E2=80=9Csurreptitiously doing evil=E2=80=9D? Also, can you define what =
you mean by evil?

=20


------=_NextPart_000_0449_01D30468.4F1F0820
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


     
    Of course, this is =
precisely the point. All your proposal does is complicate the process of =
sharing sessions with a third-party: it doesn't stop an endpoint from =
surreptitiously doing evil.
     
    Is the =
objective to have the protocol prevent an endpoint =
=E2=80=9Csurreptitiously doing evil=E2=80=9D? Also, can you define what =
you mean by evil?
     
    
------=_NextPart_000_0449_01D30468.4F1F0820--


From nobody Mon Jul 24 07:46:11 2017
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 1998D131DB2 for ; Mon, 24 Jul 2017 07:46:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CqZwbbOl97IL for ; Mon, 24 Jul 2017 07:46:09 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 BDE24131D2C for ; Mon, 24 Jul 2017 07:46:08 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id s6so22236075qtc.1 for ; Mon, 24 Jul 2017 07:46:08 -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=RMlbTTE7ffu3y3eVR9cWqpGntkKJj+pYuacbqB2Oxi8=; b=TwvdoxmEhmBOri4wpA6VBsbEBAg5EyIVRMDE5nP8uw3XsnmvCMFk2MT+M2TBZxyPcz 3PD2LnWSoeFo9Z3ZmHHk1r8pX+QxsEoBWAGncU+X7b8eUll5bHHNwtijQe4iX2uIXsCL yiEeCIA8NXlDwoDACcBGNdUbKF/Hso7zbpnRc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RMlbTTE7ffu3y3eVR9cWqpGntkKJj+pYuacbqB2Oxi8=; b=U9dsFEPZgjPMV8rMGrT1EhD/ns5txrYnAWNNDsgZWCgzjDGtSnYVnmfnntLdCccgjE x+XOS8S19RLoIV/ENmRcz0ZmB2wgKBo/ioHs2TfeM6+mwC5i/sKGhzkt3naJ/LMqYvyW NYChdNHYdrrVaYpfIkoGnF0Q5qie3/Xrrl3K+tq+CP75A404uhY5XOBftQ+5GerNa+wy U6fXsEiME0DfP+Y5/PWC55ZodQ8dXthvRJ9irfY8dIaA1Xg6RJSEDxs8kaheIhduHY1y a2ijBfuNGQLwE2d/YqRIPqihiJVDMOTUEAdClXgnaYazYVhr1wxs7y98Yjf3ILSqaRKJ 9POw==
X-Gm-Message-State: AIVw110y1zCUPO95LZWf5RGSwtS1t5YLmHD9REqcngv2BOe8lMB1spuz O5Lm/iJfP5Ij+D0dcS+wmuMwmxITkeNb+/I3gg==
X-Received: by 10.237.49.194 with SMTP id 60mr20090826qth.73.1500907567503; Mon, 24 Jul 2017 07:46:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.128.194 with HTTP; Mon, 24 Jul 2017 07:46:06 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: <044801d30489$d62e3720$828aa560$@equio.com>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>  <388DA0F2-E3FC-47D2-B97C-D244ACE50E61@fugue.com>   <044801d30489$d62e3720$828aa560$@equio.com>
From: Kyle Rose 
Date: Mon, 24 Jul 2017 10:46:06 -0400
Message-ID: 
To: Paul Turner 
Cc: Brian Sniffen , "" 
Content-Type: multipart/alternative; boundary="001a114f67646723fb055511469b"
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 14:46:10 -0000

--001a114f67646723fb055511469b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 24, 2017 at 10:33 AM, Paul Turner  wrote:

>
>
> Of course, this is precisely the point. All your proposal does is
> complicate the process of sharing sessions with a third-party: it doesn't
> stop an endpoint from surreptitiously doing evil.
>
>
>
> Is the objective to have the protocol prevent an endpoint =E2=80=9Csurrep=
titiously
> doing evil=E2=80=9D?
>

To the extent it can, it should (within bounds of performance,
deployability, etc.). Many of us have been pointing out that there are
limits to what's possible, and tradeoffs involved in other facets.

Also, can you define what you mean by evil?
>

I am using it as shorthand in this conversation for the general notion of
actively enabling pervasive surveillance, which might be logging keys to a
government server or using a government-generated DH share, among other
possibilities. I am happy to use a different phrasing, but this one is
useful because it's pithy: it invokes intent, which separates it
conceptually from other classes of peer trust violations.

Kyle

--001a114f67646723fb055511469b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On M=
on, Jul 24, 2017 at 10:33 AM, Paul Turner <pturner@equio.com> wrote:
    =C2=A0=

    Of course, this is precisely the point. All your proposal=
 does is complicate the process of sharing sessions with a third-party: it =
doesn't stop an endpoint from surreptitiously doing evil.=

    =C2=A0
    Is the objective to have the protocol prevent an endpoint =E2=80=
=9Csurreptitiously doing evil=E2=80=9D?
    <=
/div>

    To the extent it can, it should=
 (within bounds of performance, deployability, etc.). Many of us have been =
pointing out that there are limits to what's possible, and tradeoffs in=
volved in other facets.

     Also, can you defin=
e what you mean by evil?

    I am using it as shorthand in this conversatio=
n for the general notion of actively enabling pervasive surveillance, which=
 might be logging keys to a government server or using a government-generat=
ed DH share, among other possibilities. I am happy to use a different phras=
ing, but this one is useful because it's pithy: it invokes intent, whic=
h separates it conceptually from other classes of peer trust violations.

    Kyle

    

--001a114f67646723fb055511469b--


From nobody Mon Jul 24 07:58:24 2017
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 926D0131C32 for ; Mon, 24 Jul 2017 07:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 MI2yXDbC9TEs for ; Mon, 24 Jul 2017 07:58: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 77BC8127058 for ; Mon, 24 Jul 2017 07:58:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 8171D222A6; Mon, 24 Jul 2017 17:58:18 +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 2TTiDNgGewob; Mon, 24 Jul 2017 17:58:18 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 437B1C4; Mon, 24 Jul 2017 17:58:16 +0300 (EEST)
Date: Mon, 24 Jul 2017 17:58:16 +0300
From: Ilari Liusvaara 
To: Raja ashok 
Cc: "" 
Message-ID: <20170724145815.xuhzjqsbnf5eardr@LK-Perkele-VII>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 14:58:23 -0000

On Mon, Jul 24, 2017 at 01:48:13PM +0000, Raja ashok wrote:
> Hi Nir, Josefsson & Pegourie,
> 
> As per section 5.2 server should send only "Supported Point Format"
> extensions in server hello message. And it doesn't require to send
> "Supported Elliptic Curve" extensions. Because of this if server is
> supporting only few Curves and if it receives unsupported Elliptic
> curve in client certificate message, then server might not be able
> to continue the handshake.

In TLS 1.2, the client sends the list of curves (and other groups
and DHFs) it supports. The server picks one if it can.

Thus if there is at least one common curve that both client and
server support, then the group selection will succeed (if there
is none, then no matter what one does things won't work).

The actual curve server selected is transmitted in ServerKeyExchange
message.


In TLS 1.3, things get bit more complicated, since client can
signal it supports a group without sending a share for it (if
server selects such group, it needs to tell the client to retry
using HelloRetryRequest message). The server group selection is
in KeyShare extension in ServerHello message.


-Ilari


From nobody Mon Jul 24 08:04:24 2017
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 03C95131DFF for ; Mon, 24 Jul 2017 08:04:22 -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 q8AxcS5eTvaj for ; Mon, 24 Jul 2017 08:04:20 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 421B1131DAA for ; Mon, 24 Jul 2017 08:04:20 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id v205so18894034itf.1 for ; Mon, 24 Jul 2017 08:04:20 -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:cc :content-transfer-encoding:message-id:references:to; bh=BrbhOtQKUvE/TCk/xeyBslvNJU5imytT9LUDqQmHBwI=; b=Vj4lqO8WCSKaNNA+t0zH7VIP5cSxzARk15iPiKpCzfXYgSQovUMOj8dBUoe/dXimGg XAvskT6UvSVtUIgwq7E7nFb/YQxBqHso4jFq60j/Aa/X4SJtuQ37q8F1Ma2VUSoNHJQ9 2Cv6GTBvY37/jW3X4pYEFawmsMFQM67cg9kK8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BrbhOtQKUvE/TCk/xeyBslvNJU5imytT9LUDqQmHBwI=; b=cyrYnCtv6iOYkNayLqTWM4hTZTRHmndqKSK64hZwy1YIUv9x/fho9rhkkbrnsOHbd2 XQ1jSBkP1CIJ4ErmBPwOkUzWNbvMfhsZfDPl6KNDbmTdiG2fbftMg7UHnYnY3hDEKO8J D93BHp4fUXkGv7rLXUgF7xzcuCbxW7NlqmAlqJ5uZMrRjkrS6pWCxSydOYc5CpmpXY8H /IJxyIZ3tKCGnhaR3//FIVEHAy+9TV51xhvNbdRKQWgbeyaQbpW1TuxF/x7cvJqcOA6B +63oEW8QA/S7Se2nB1fYTFB88m3Y4pZolGXwsRoNvNDBVX0Gzd2fcwTHCZOHEve/BZYm L1+A==
X-Gm-Message-State: AIVw110xYGFpdUfnfKM289OI9zZczWxGn4kpD6Lj+xp6eA/YXsGTwf// LODYx+C78O5D3d3MUoUbNQ==
X-Received: by 10.36.131.199 with SMTP id d190mr6947023ite.75.1500908659522; Mon, 24 Jul 2017 08:04:19 -0700 (PDT)
Received: from [5.5.33.95] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id f19sm4008480itf.27.2017.07.24.08.04.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 08:04:18 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Turner 
In-Reply-To: <855f7890734c4bdb9d65ce961712a6e0@venafi.com>
Date: Mon, 24 Jul 2017 17:04:14 +0200
Cc: "" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <117AB406-6D6A-4F34-B201-72D2B7C92CE2@sn3rd.com>
References:  <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <636eb20e-f4e4-0fac-b5da-c12ccc1d6c6b@cs.tcd.ie> <855f7890734c4bdb9d65ce961712a6e0@venafi.com>
To: Paul Turner 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 15:04:22 -0000

> On Jul 24, 2017, at 16:27, Paul Turner  wrote:
>=20
> =20
> It's fascinating that people cannot seem to stop picking at the scab =
remaining after draft-green. I really think we'd be wiser to just let =
the wound heal. (And get on with the work that this WG has been =
chartered to do, which does not include
> wiretapping.)
> =20
> Sorry to ask for this so late in the conversation but can you point me =
to the definition of the term =E2=80=9Cwiretapping=E2=80=9D you=E2=80=99re=
 using?

Paul,

Check out https://datatracker.ietf.org/doc/rfc2804/

spt


From nobody Mon Jul 24 08:15:21 2017
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 DB057131E0C for ; Mon, 24 Jul 2017 08:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoC6yYg-MOS8 for ; Mon, 24 Jul 2017 08:15:17 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951B3131E36 for ; Mon, 24 Jul 2017 08:15:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6B650BE50 for ; Mon, 24 Jul 2017 16:15:11 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJE1I576a4-U for ; Mon, 24 Jul 2017 16:15:11 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 344B0BE2D for ; Mon, 24 Jul 2017 16:15:11 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500909311; bh=3LrHWVPikBufGUjLDvuF/PIl6VqcFUMJz055KXQe7Ko=; h=To:From:Subject:Date:From; b=SuhdGKk3H+DyL6iTtuIGbmnapfEFKTbrzSONaBa4RNh8hML9yajHNcAwzlZIy2/zf 5DcANyh258DsOew2HcqaWcxyfehaDQL35UumCsryJYlpIeBNrwSooPgoMfgdtBu+Ua oyYLnHRh6DI4LIvEzM9I9IoiXAbOVHn6CzP3KIjE=
To: "tls@ietf.org" 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
Date: Mon, 24 Jul 2017 16:15:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FpA1u7mt8BE5K9kOIiofD56NISV8maGHk"
Archived-At: 
Subject: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 15:15:20 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--FpA1u7mt8BE5K9kOIiofD56NISV8maGHk
Content-Type: multipart/mixed; boundary="cWSChUvAvxIG6f4gcp3Vx6F4dNuL83xrE";
 protected-headers="v1"
From: Stephen Farrell 
To: "tls@ietf.org" 
Message-ID: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
Subject: 32 byte randoms in TLS1.3 hello's

--cWSChUvAvxIG6f4gcp3Vx6F4dNuL83xrE
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Hiya,

I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
that may be;-).

Anyway, in TLS1.3 we've gotten rid of the gmt time option
in the client and server hello, which is good, (and I do
recall that discussion) but we've also changed from:

   // RFC5246
   struct {
      uint32 gmt_unix_time;
      opaque random_bytes[28];
   } Random;

to:

   // tls1.3 -21
   opaque Random[32];

Now if some TLS1.3 deployment were affected by a dual-ec
attack, it'd seem like the -21 version of Random might be
even better than the TLS1.2 version, for the attacker.

I tried to see where that 28->32 change came from but
didn't find it (apologies if I missed that). I guess it
just ensures that the overall length of the struct is
the same.

So, a question and a possible suggestion:

Q: Why do we need 32 bytes of Random?

Suggestion: if we don't need that much, maybe we could
change the length there, (I can see that might trigger
bugs and middlebox issues) or encourage/require folks
to mask out some of those bits (e.g. with zeros or some
catchy hex encoded message about dual-ec:-).

Cheers,
S.


[1]
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephe=
n-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
[2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf=



--cWSChUvAvxIG6f4gcp3Vx6F4dNuL83xrE--

--FpA1u7mt8BE5K9kOIiofD56NISV8maGHk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZdg7+AAoJEC88hzaAX42izVUIAJcQ3R5TQ2jbzZJY8mtP0NVM
6lPCJMjG1NGFFAuLapNp2xXXjIj8BU8/K3lEQ7PLE8RThL5UwDO7vnRhn92Po/x8
O6kG7RWO89KPfvqbXBjodZRY0YF/1pFIhwcLZanc3eMcdFeMSbMeRmANfrx64ois
8yWE2NN1xFxruPwnjNBb8tPlsme0ZaE6rGKcNNdHO7Dtw1dksU6HXgk0TcqeEPmN
xEy91DRwGSwfvsIlGIqUwtf6ufu6iQt9e+t4VjvOhplDQx5x8xABkNO6OyBrDIgY
pAohgOPCo5Vsvv0Sot/AeUums2sMM4LlM7JbwCXNSsj+YT/he3e6mlyAwBPzhXM=
=5jsD
-----END PGP SIGNATURE-----

--FpA1u7mt8BE5K9kOIiofD56NISV8maGHk--


From nobody Mon Jul 24 08:19:53 2017
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 D5BE5131E10 for ; Mon, 24 Jul 2017 08:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 CF5sVl1BAuJm for ; Mon, 24 Jul 2017 08:19:50 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 701CE131E0F for ; Mon, 24 Jul 2017 08:19:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 6607A22903; Mon, 24 Jul 2017 18:19:49 +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 OKXR6KKlNT4k; Mon, 24 Jul 2017 18:19:40 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 5B5D021C; Mon, 24 Jul 2017 18:19:36 +0300 (EEST)
Date: Mon, 24 Jul 2017 18:19:36 +0300
From: Ilari Liusvaara 
To: Brian Sniffen 
Cc: Ted Lemon , "Blumenthal, Uri - 0553 - MITLL" , "" 
Message-ID: <20170724151936.hq7uepji62nhype6@LK-Perkele-VII>
References: <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII>  <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>  <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>  <388DA0F2-E3FC-47D2-B97C-D244ACE50E61@fugue.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 15:19:53 -0000

On Mon, Jul 24, 2017 at 10:03:28AM -0400, Brian Sniffen wrote:
> Ted Lemon  writes:
> 
> > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL  wrote:
> >> What I am trying to avoid is the ability to *surreptitiously* subvert a protocol that’s assumed to be secure.
> >
> > You don't seem to be hearing what I'm trying to say.   What you are
> > proposing is physically impossible.
> 
> Is it?  I could imagine making the server ECDH share dependent on the
> client ECDH share, plus a local random value.  At the end of the
> session, the server discloses that random value, showing that it
> properly constructed a fresh ECDH share.

I do not think this works. As a blatant example, have server generate
the ServerRandom and then the ECDH seed using Dual-EC-DRBG...

The ECDH share will then change every connection and there is a
seed to demonstrate, but the connections can still be decrypted by who
controls the Dua-EC-DRBG backdoor key.

Yes, Dual-EC-DRBG is quite crappy with sizable biases, but discovering
those would take way too many connections. And there are similar
methods that have much much smaller biases.


Basically, if implementation wants to be secretly evil, it can be
secretly evil, and there is nothing you can do to discover it remotely.

Bad implementations are a separate problem. E.g., repeating the same
DH share for a long time because there is no key rotation. That sort
of behavior is pretty blatant if one monitors the DH shares used.


-Ilari


From nobody Mon Jul 24 08:29:45 2017
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 0946A131E17 for ; Mon, 24 Jul 2017 08:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 GIp0pMfi_afP for ; Mon, 24 Jul 2017 08:29:41 -0700 (PDT)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 C4C8C129A9F for ; Mon, 24 Jul 2017 08:29:41 -0700 (PDT)
Received: by mail-pg0-x232.google.com with SMTP id y129so58529105pgy.4 for ; Mon, 24 Jul 2017 08:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8R63vQQ8AhkHfgifU/eNAqNBEeSNI0pQUblMXycbNUI=; b=mwmosdYWnFfwRDem/4PK83jrDI/ebXT0XYaxXjTnxi71MFAmp05PBDqfJVyJOv4IQS kINgHlXbTvBPVfcVXXe+ZfEIwvbxnZoA24EVLAiadZZIsHwiakAcTmCCfu8m7Z+/ZjVE aqaXISZHPNSZKNtrWrjGrIYjS4N9t1vT7oJpORmkP83aNt3+cHAT1KJzKKQRTZ0U178Q dFAiKBH0HFXOEvAkwD0YQ2CHKlbg2iP55UDARE8rm0twQFi5jZpIefFm7m2/IHoXsJN9 oC5LIYBRdg5SQtG0jBARkxgiAzWKjNHoiIAm/W2BfMhOHAnNaSCyqDGeSDQ97e78nAaS QVGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8R63vQQ8AhkHfgifU/eNAqNBEeSNI0pQUblMXycbNUI=; b=Y2wYn1ZsNLCsAS45ffjGsE2uY0SS5+0UDLME31kEG9ojWZHhdRGvjVjE2FRinc1BRm ZZebjrzMMkuykuceLOOWcM3Z2bUlKLHaglZGnc+vq9Fc20WBfQ1fS6OXr8c6dj/DPk8F tqV/psULF7BShekIdbGpEhVOA71JHF4TEOcf1kTCsUSCThOnPiIF4gxxfQlPvzcshFf3 Jvd75/cf10Z3ug2vJDnW38AQfpsZDcJ3dwAHqG1b7tpvMLTNBvu4sPhqFni/XAH7J6cH QWTaDf4OfGaUWq60rlCaM8NZDaT5oBM9yR/pgmm2E2tCRkQayemw/POiSVTwTI6cQIsz I4rg==
X-Gm-Message-State: AIVw111lPloj9HDO/qoaSBIs+QopX8t99dLis6yA6zEEykpLAsMh1Aa3 sJHmWEftApQ7fisZn7mNM5kJmYOp8g==
X-Received: by 10.99.114.73 with SMTP id c9mr16473470pgn.267.1500910181351; Mon, 24 Jul 2017 08:29:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Mon, 24 Jul 2017 08:29:40 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Mon, 24 Jul 2017 08:29:40 -0700 (PDT)
In-Reply-To: 
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>   
From: Watson Ladd 
Date: Mon, 24 Jul 2017 08:29:40 -0700
Message-ID: 
To: Stephen Farrell 
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="f403045c70363309a1055511e2c6"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 15:29:44 -0000

--f403045c70363309a1055511e2c6
Content-Type: text/plain; charset="UTF-8"

On Jul 24, 2017 8:15 AM, "Stephen Farrell" 
wrote:


Hiya,

I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
that may be;-).

Anyway, in TLS1.3 we've gotten rid of the gmt time option
in the client and server hello, which is good, (and I do
recall that discussion) but we've also changed from:

   // RFC5246
   struct {
      uint32 gmt_unix_time;
      opaque random_bytes[28];
   } Random;

to:

   // tls1.3 -21
   opaque Random[32];

Now if some TLS1.3 deployment were affected by a dual-ec
attack, it'd seem like the -21 version of Random might be
even better than the TLS1.2 version, for the attacker.

I tried to see where that 28->32 change came from but
didn't find it (apologies if I missed that). I guess it
just ensures that the overall length of the struct is
the same.

So, a question and a possible suggestion:

Q: Why do we need 32 bytes of Random?

Suggestion: if we don't need that much, maybe we could
change the length there, (I can see that might trigger
bugs and middlebox issues) or encourage/require folks
to mask out some of those bits (e.g. with zeros or some
catchy hex encoded message about dual-ec:-).


Anti-kleptography is not a matter of avoiding known attacks one at a time.
The fact is that someone could add backdoor login credentials or a buffer
overflow if they can also force dual-
EC to be used.

Don't use bad prngs. And don't buy products from vendors who ship back
doors and refuse to come completely clean when confronted.


Cheers,
S.


[1]
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-
checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
[2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf


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

--f403045c70363309a1055511e2c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Jul 24, 2017 8:15 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wro=
te:

    
Hiya,
    

    
I'm guessing many folks interested in TLS may have been
    
at the QUIC session in Prague and hence missed out on the
    
excellent talk by Stephen Checkoway on the juniper dual-ec
    
incident. (I highly recommend taking a peek at the slides [1]
    
or reading the paper [2] or watching the video wherever
    
that may be;-).
    

    
Anyway, in TLS1.3 we've gotten rid of the gmt time option
    
in the client and server hello, which is good, (and I do
    
recall that discussion) but we've also changed from:
    

    
=C2=A0 =C2=A0// RFC5246
    
=C2=A0 =C2=A0struct {
    
=C2=A0 =C2=A0 =C2=A0 uint32 gmt_unix_time;
    
=C2=A0 =C2=A0 =C2=A0 opaque random_bytes[28];
    
=C2=A0 =C2=A0} Random;
    

    
to:
    

    
=C2=A0 =C2=A0// tls1.3 -21
    
=C2=A0 =C2=A0opaque Random[32];
    

    
Now if some TLS1.3 deployment were affected by a dual-ec
    
attack, it'd seem like the -21 version of Random might be
    
even better than the TLS1.2 version, for the attacker.
    

    
I tried to see where that 28->32 change came from but
    
didn't find it (apologies if I missed that). I guess it
    
just ensures that the overall length of the struct is
    
the same.
    

    
So, a question and a possible suggestion:
    

    
Q: Why do we need 32 bytes of Random?
    

    
Suggestion: if we don't need that much, maybe we could
    
change the length there, (I can see that might trigger
    
bugs and middlebox issues) or encourage/require folks
    
to mask out some of those bits (e.g. with zeros or some
    
catchy hex encoded message about dual-ec:-).
    =


    Anti-kleptography is not a ma=
tter of avoiding known attacks one at a time. The fact is that someone coul=
d add backdoor login credentials or a buffer overflow if they can also forc=
e dual-
    EC to be used.

    Don't use bad prngs. And don't buy products f=
rom vendors who ship back doors and refuse to come completely clean when co=
nfronted.

    

--f403045c70363309a1055511e2c6--


From nobody Mon Jul 24 09:11:20 2017
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 04255131EA0 for ; Mon, 24 Jul 2017 09:11:18 -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 B1-p5aroPIjg for ; Mon, 24 Jul 2017 09:11:16 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB9E131E9C for ; Mon, 24 Jul 2017 09:11:15 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 38D847A3310; Mon, 24 Jul 2017 16:11:15 +0000 (UTC)
Date: Mon, 24 Jul 2017 16:11:15 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20170724161114.GD8146@mournblade.imrryr.org>
Reply-To: tls@ietf.org
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <2a648a63-8299-1a9c-776e-f5d043371055@akamai.com> <3673860.07CCjCncdc@pintsize.usersys.redhat.com> <6f6bf32f-5c73-9213-969a-2fdf1a4c48a2@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6f6bf32f-5c73-9213-969a-2fdf1a4c48a2@akamai.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 16:11:18 -0000

On Fri, Jul 21, 2017 at 02:37:42PM -0500, Benjamin Kaduk wrote:

> I'm afraid I don't understand this remark.  There is the caveat to which
> Ilari alludes, that the server can send whatever chain it has, if the
> server can't send a chain that complies with the client's
> signature_algorithms.

"Send whatever it has" is the expected behaviour in the vast majority
of cases, i.e., for servers with just one certificate chain.  I sure
hope that server implementation that abort instead of sending some
chain will be rare.

It is indeed a nuisance that even with curves for key agreement
split off into the separate "groups" extension, the "signature
algorithms" extension is still overloaded to serve two rather
different purposes:

    1.  Negotiate algorithms suitable for signing TLS handshake
	messages.

    2.  Signal support for X.509 signature algorithms.

Using the same extension for both was perhaps a mistake.  As pointed
out in this thread,  X.509 admits more combinations for "2" than
TLS 1.3 does for "1".  Consequently TLS 1.3 servers with multiple
chains to choose from might employ suboptimal algorithms in order
to match the client's supported signature algorithm extension, even
though a better choice is available, but was not or cannot be
signalled by the client.

-- 
	Viktor.


From nobody Mon Jul 24 09:27:23 2017
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 33F83131E9D for ; Mon, 24 Jul 2017 09:27:22 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 Z7q5mD71V9aR for ; Mon, 24 Jul 2017 09:27:20 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 E7078131E97 for ; Mon, 24 Jul 2017 09:27:19 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id v190so59255885pgv.2 for ; Mon, 24 Jul 2017 09:27:19 -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=ChUkFGCxv5itwfOG1NGC6qxn2AvgCuC85tnZiJTtUb0=; b=H4mQbUZYdBkFVeBpagMtMVLixDzPCU3vYqGKa8IU+0thyGPxmMH0yMcdfIZcT3HCFd XiFe/lZFmQbwmK2q/5/Jjwzm3eKTcSfUFIwTqFz+ljwkZChO0Q8y/Sg9HZePyBDRl5Zw 7AKoCHGxULjx1oznxPhVnCF7cldoAjN+x+x4M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ChUkFGCxv5itwfOG1NGC6qxn2AvgCuC85tnZiJTtUb0=; b=KrfmLwvq71xoi+XK4wr0uew/lBX1uI5pMs6lEifRxtD/qw/IS62KRaFt1I8PRslRyK QFtfYi8feWynkccVb/jdTBwbhXKmKx2ei9DjprcZbST4/urLxAH0JEc9WlMaLCduuGk/ eQQhCei1ARtEqchTOJU6ChbaDPj6ATB/UWyFT9Ea2+D4p9NOHfDMpqjJfoy7f4pSDnlC YbfnMKhrehuMci1qteFqkZrY7mZZgbomgZPC+c3LsxANRPJMKpVfLm4JpJgKviltTXFM EHMfbrrJEohfdn0i2wqHpA8hjyZDAus710Yf0KaCo0x8cUsa4MetLAHJLvTisB2u/1qQ IOLg==
X-Gm-Message-State: AIVw112gu7ae8ScjpJ1m+JB+hgDllzqABMxtgX+rXlDQ92dS+Ug3z7HY r8iMYJUsjsxLR2x+WSQT+3GPbfeP6A/3
X-Received: by 10.101.70.15 with SMTP id v15mr16676127pgq.229.1500913639313; Mon, 24 Jul 2017 09:27:19 -0700 (PDT)
MIME-Version: 1.0
References:  <20170724145815.xuhzjqsbnf5eardr@LK-Perkele-VII>
In-Reply-To: <20170724145815.xuhzjqsbnf5eardr@LK-Perkele-VII>
From: David Benjamin 
Date: Mon, 24 Jul 2017 16:27:08 +0000
Message-ID: 
To: Ilari Liusvaara , Raja ashok 
Cc: "" 
Content-Type: multipart/alternative; boundary="089e082249e04fcd63055512b057"
Archived-At: 
Subject: Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 16:27:22 -0000

--089e082249e04fcd63055512b057
Content-Type: text/plain; charset="UTF-8"

I believe what Raja is pointing out is that a server which accepts an ECDSA
*client* certificate has no way to advertise to the client which curves it
accepts. The signature algorithm list (and before TLS 1.2, the certificate
types) do advertise ECDSA as a whole, but not curves. E.g., a client with
both a P-256 and P-384 certificate may send P-384 when the server only
accepted P-256. This issue existed in RFC 4492 as well.

Though I wouldn't say the implication is all curves must be implemented.
Rather I think you just reject those curves you don't accept and manage
your client certificate deployment so that all servers accept a curve
before starting to use those certificates.

That's not great, so TLS 1.3 fixes this by moving ECDSA curves into
signature algorithms. It's too late to change supported_groups to allow a
TLS 1.2 ServerHello acknowledgement since clients will unexpected server
extensions[*], so I would suggest we just leave this in the awkward state
for TLS 1.2 and say it is fixed in TLS 1.3.

David

[*] Although, glancing through ours, it seems we do accept and ignore a
ServerHello supported_groups in TLS 1.2. We apparently came across a server
implementation which sent it, contrary to the spec.

On Mon, Jul 24, 2017 at 10:58 AM Ilari Liusvaara 
wrote:

> On Mon, Jul 24, 2017 at 01:48:13PM +0000, Raja ashok wrote:
> > Hi Nir, Josefsson & Pegourie,
> >
> > As per section 5.2 server should send only "Supported Point Format"
> > extensions in server hello message. And it doesn't require to send
> > "Supported Elliptic Curve" extensions. Because of this if server is
> > supporting only few Curves and if it receives unsupported Elliptic
> > curve in client certificate message, then server might not be able
> > to continue the handshake.
>
> In TLS 1.2, the client sends the list of curves (and other groups
> and DHFs) it supports. The server picks one if it can.
>
> Thus if there is at least one common curve that both client and
> server support, then the group selection will succeed (if there
> is none, then no matter what one does things won't work).
>
> The actual curve server selected is transmitted in ServerKeyExchange
> message.
>
>
> In TLS 1.3, things get bit more complicated, since client can
> signal it supports a group without sending a share for it (if
> server selects such group, it needs to tell the client to retry
> using HelloRetryRequest message). The server group selection is
> in KeyShare extension in ServerHello message.
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--089e082249e04fcd63055512b057
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    I believe what Raja is pointing out is that a server which=
 accepts an ECDSA *client* certificate has no way to advertise to the clien=
t which curves it accepts. The signature algorithm list (and before TLS 1.2=
, the certificate types) do advertise ECDSA as a whole, but not curves. E.g=
., a client with both a P-256 and P-384 certificate may send P-384 when the=
 server only accepted P-256. This issue existed in RFC 4492 as well.
    Though I wouldn't say the implication is all curves must b=
e implemented. Rather I think you just reject those curves you don't ac=
cept and manage your client certificate deployment so that all servers acce=
pt a curve before starting to use those certificates.

    That's not great, so TLS 1.3 fixes this by moving ECDSA curves into s=
ignature algorithms. It's too late to change supported_groups to allow =
a TLS 1.2 ServerHello acknowledgement since clients will unexpected server =
extensions[*], so I would suggest we just leave this in the awkward state f=
or TLS 1.2 and say it is fixed in TLS 1.3.

    David

    [*] Although, glancing through ours, it seems we do=
 accept and ignore a ServerHello supported_groups in TLS 1.2. We apparently=
 came across a server implementation which sent it, contrary to the spec.
    On Mon, Jul 24, 2017 at 1=
0:58 AM Ilari Liusvaara <ila=
riliusvaara@welho.com> wrote:
    TLS@ietf.org
    
https://www.ietf.org/mailman/listinfo/tls
    

    

--089e082249e04fcd63055512b057--


From nobody Mon Jul 24 09:40:32 2017
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 1D75F129AC4 for ; Mon, 24 Jul 2017 09:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 5puJjAWZR6PX for ; Mon, 24 Jul 2017 09:40:28 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAD8129ADD for ; Mon, 24 Jul 2017 09:40:27 -0700 (PDT)
Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jul 2017 12:40:25 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0319.002; Mon, 24 Jul 2017 12:40:25 -0400
From: Dan Brown 
To: Stephen Farrell , "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+yUHLG+hMivEObnVpzx6wh/KJjLfkf
Date: Mon, 24 Jul 2017 16:40:24 +0000
Message-ID: <20170724164022.8573013.93422.16108@blackberry.com>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
In-Reply-To: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 16:40:30 -0000

Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given=
 that ephemeral DH is mandated, if anybody has the time/patience. (* ok, no=
t that I truly ever knew).

I assume that the risk of misusing the nonces, to exfiltrate keys etc, is s=
mall enough compared to other side channels to justify their added value.


  Original Message
From: Stephen Farrell
Sent: Monday, July 24, 2017 11:15 AM
To: tls@ietf.org
Subject: [TLS] 32 byte randoms in TLS1.3 hello's


Hiya,

I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
that may be;-).

Anyway, in TLS1.3 we've gotten rid of the gmt time option
in the client and server hello, which is good, (and I do
recall that discussion) but we've also changed from:

   // RFC5246
   struct {
      uint32 gmt_unix_time;
      opaque random_bytes[28];
   } Random;

to:

   // tls1.3 -21
   opaque Random[32];

Now if some TLS1.3 deployment were affected by a dual-ec
attack, it'd seem like the -21 version of Random might be
even better than the TLS1.2 version, for the attacker.

I tried to see where that 28->32 change came from but
didn't find it (apologies if I missed that). I guess it
just ensures that the overall length of the struct is
the same.

So, a question and a possible suggestion:

Q: Why do we need 32 bytes of Random?

Suggestion: if we don't need that much, maybe we could
change the length there, (I can see that might trigger
bugs and middlebox issues) or encourage/require folks
to mask out some of those bits (e.g. with zeros or some
catchy hex encoded message about dual-ec:-).

Cheers,
S.


[1]
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-=
checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
[2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf


From nobody Mon Jul 24 09:51:40 2017
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 8522D131EB0 for ; Mon, 24 Jul 2017 09:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 90vplMh1IP7P for ; Mon, 24 Jul 2017 09:51:36 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4D35B131D21 for ; Mon, 24 Jul 2017 09:51:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7104E2271D; Mon, 24 Jul 2017 19:51:34 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id qzuvR-l8-Hyf; Mon, 24 Jul 2017 19:51:34 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 1E562C4; Mon, 24 Jul 2017 19:51:32 +0300 (EEST)
Date: Mon, 24 Jul 2017 19:51:31 +0300
From: Ilari Liusvaara 
To: Dan Brown 
Cc: "tls@ietf.org" 
Message-ID: <20170724165131.f7loq667auckreo4@LK-Perkele-VII>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie> <20170724164022.8573013.93422.16108@blackberry.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20170724164022.8573013.93422.16108@blackberry.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 16:51:38 -0000

On Mon, Jul 24, 2017 at 04:40:24PM +0000, Dan Brown wrote:
> Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all,
> given that ephemeral DH is mandated, if anybody has the time/
> patience. (* ok, not that I truly ever knew).

Two reasons:

- The DH shares can be reused (even if this is bad practice, there is
  no requirement not to).
- There still is pure-PSK mode, which has no entropy injection apart
  from Random values.


-Ilari


From nobody Mon Jul 24 09:58:06 2017
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 347E6129ADD for ; Mon, 24 Jul 2017 09:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 TYOWn3rZJmOm for ; Mon, 24 Jul 2017 09:58:03 -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 452BB126CD8 for ; Mon, 24 Jul 2017 09:58:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A5CCF30042C for ; Mon, 24 Jul 2017 12:58:02 -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 3jJ7kw-XG-zV for ; Mon, 24 Jul 2017 12:58:01 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6CA38300288; Mon, 24 Jul 2017 12:58:01 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley 
In-Reply-To: <20170724164022.8573013.93422.16108@blackberry.com>
Date: Mon, 24 Jul 2017 12:58:00 -0400
Cc: IETF TLS 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie> <20170724164022.8573013.93422.16108@blackberry.com>
To: Dan Brown 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 16:58:05 -0000

there was a discussion of adding a statement that a fresh ephemeral key =
MUST be used for each session.  It was decided not to do that.  Without =
such a requirement, nonces are needed.

Russ


> On Jul 24, 2017, at 12:40 PM, Dan Brown  =
wrote:
>=20
> Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, =
given that ephemeral DH is mandated, if anybody has the time/patience. =
(* ok, not that I truly ever knew).
>=20
> I assume that the risk of misusing the nonces, to exfiltrate keys etc, =
is small enough compared to other side channels to justify their added =
value.
>=20
>=20
>  Original Message
> From: Stephen Farrell
> Sent: Monday, July 24, 2017 11:15 AM
> To: tls@ietf.org
> Subject: [TLS] 32 byte randoms in TLS1.3 hello's
>=20
>=20
> Hiya,
>=20
> I'm guessing many folks interested in TLS may have been
> at the QUIC session in Prague and hence missed out on the
> excellent talk by Stephen Checkoway on the juniper dual-ec
> incident. (I highly recommend taking a peek at the slides [1]
> or reading the paper [2] or watching the video wherever
> that may be;-).
>=20
> Anyway, in TLS1.3 we've gotten rid of the gmt time option
> in the client and server hello, which is good, (and I do
> recall that discussion) but we've also changed from:
>=20
>   // RFC5246
>   struct {
>      uint32 gmt_unix_time;
>      opaque random_bytes[28];
>   } Random;
>=20
> to:
>=20
>   // tls1.3 -21
>   opaque Random[32];
>=20
> Now if some TLS1.3 deployment were affected by a dual-ec
> attack, it'd seem like the -21 version of Random might be
> even better than the TLS1.2 version, for the attacker.
>=20
> I tried to see where that 28->32 change came from but
> didn't find it (apologies if I missed that). I guess it
> just ensures that the overall length of the struct is
> the same.
>=20
> So, a question and a possible suggestion:
>=20
> Q: Why do we need 32 bytes of Random?
>=20
> Suggestion: if we don't need that much, maybe we could
> change the length there, (I can see that might trigger
> bugs and middlebox issues) or encourage/require folks
> to mask out some of those bits (e.g. with zeros or some
> catchy hex encoded message about dual-ec:-).
>=20
> Cheers,
> S.
>=20
>=20
> [1]
> =
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen=
-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
> [2] =
https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Mon Jul 24 10:09:38 2017
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 38438126C0F for ; Mon, 24 Jul 2017 10:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 E7rv65tds2x8 for ; Mon, 24 Jul 2017 10:09:35 -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 8B78F1241FC for ; Mon, 24 Jul 2017 10:09:35 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id x125so53188082ywa.0 for ; Mon, 24 Jul 2017 10:09:35 -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=R1fIQtkjnYAAmII8a6BVM17l2S8RvXWoQBJRZwYtmY4=; b=r1CFPa4pHSP3JmWih2DblSKn+3U5yDJIoaMEyBwIXJzM3eHBrxPw+Tro/uAC2KLfSQ 6u95puy8y/R6Kkc2CCE+AK3LOo/mYkcyo9B0IQWzHMGBn10PVAdqMmxyGinM4JFPcUqJ Z9kh2h0+mtcJNVcvKJlINnXNSNhyuCTPzfZ1vTxEe5lBqghD6JRRXHQS5p1PgM7NpcTB x2ZFTda8mXxhy6/dZ50qtlqxesKxfKMs+ubG+TR8MN/fMHisYQvk9Q7g0IaXoyABoWm3 yQIgNROER4jhEJk5h8FKg73n1rhd04qhEeoWqOR7wBJDprl2SYpOVfacFm/xyl8VvLqy wbAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R1fIQtkjnYAAmII8a6BVM17l2S8RvXWoQBJRZwYtmY4=; b=AdAS+5qEvSnWKI9ZYh+itkRmYx4m/1nCJ9aBQBjjBdmj3ZXQOsk8MAtwudah5jH64t kEbyewwDqa6J5tawpKVgUYCyP2TExUWZ3oIm36sXI0cs3hXE/vr931P4EaVXXnBvdUmZ 5H198FkboKIHIlNT+X6uEsab+5LszZx0dmjJ9mS4XDAn1hn0ycHkVMJUo2h6lt6A5BK3 t/GK91CZ61Xl6Y72ZqSrS/oihjbDt05WqU21gPoRqFAmm089lhVP5j0lm8H5qrdMjw5l PyX2lbUPh1OfonyzWZHxCyCz0jbysYo2yKNCzkEYU8d7DGwArYB1ZXqr7saf5mgqOk7g 1j7g==
X-Gm-Message-State: AIVw110va8OHnxY66faHaSBfMYOpDZSxR606bxMlXONb/Q/ybhHtUHoe wIO1bNnN0djwsbN64jBLhQh8AGDGxdQT
X-Received: by 10.13.214.203 with SMTP id y194mr13665073ywd.409.1500916174557;  Mon, 24 Jul 2017 10:09:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.71 with HTTP; Mon, 24 Jul 2017 10:09:34 -0700 (PDT)
In-Reply-To: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Mon, 24 Jul 2017 10:09:34 -0700
Message-ID: 
To: Stephen Farrell 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c076d526c740d05551347d0"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 17:09:37 -0000

--94eb2c076d526c740d05551347d0
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 24, 2017 at 8:15 AM, Stephen Farrell 
wrote:

> Now if some TLS1.3 deployment were affected by a dual-ec
> attack, it'd seem like the -21 version of Random might be
> even better than the TLS1.2 version, for the attacker.
>

I think the fix for this is really at the application level; if you want
defense-in-depth against PRNG problems, it's probably best to use separate
RNG instances for public data (e.g. client_random, server_random,
explicit_IV) and for secret data (keys) so that a leak in the public data
doesn't compromise the private one. We do this in s2n, and I think
BouncyCastle does it too.

A protocol level fix probably isn't as helpful because the attacker can
make more connections and collect more data to derive more and more
information about the RNG state anyway.

-- 
Colm

--94eb2c076d526c740d05551347d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Mon, Jul 24, 2017 at 8:15 AM, Stephen Farrell <=
stephen.farr=
ell@cs.tcd.ie> wrote:
    Now i=
f some TLS1.3 deployment were affected by a dual-ec
    
attack, it'd seem like the -21 version of Random might be
    
even better than the TLS1.2 version, for the attacker.

    I think the fix for this is really at the application level=
; if you want defense-in-depth against PRNG problems, it's probably bes=
t to use separate RNG instances for public data (e.g. client_random, server=
_random, explicit_IV) and for secret data (keys) so that a leak in the publ=
ic data doesn't compromise the private one. We do this in s2n, and I th=
ink BouncyCastle does it too.=C2=A0

    A protocol lev=
el fix probably isn't as helpful because the attacker can make more con=
nections and collect more data to derive more and more information about th=
e RNG state anyway.

    -- 
    Colm
    

    

--94eb2c076d526c740d05551347d0--


From nobody Mon Jul 24 10:16:01 2017
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 8F254131EBA for ; Mon, 24 Jul 2017 10:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 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=-0.001, 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 gvT22CIdwmbY for ; Mon, 24 Jul 2017 10:15: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 A0BDC131DA5 for ; Mon, 24 Jul 2017 10:15:57 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 08D327DCE9; Mon, 24 Jul 2017 17:15:57 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 08D327DCE9
Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 08D327DCE9
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C8BDB6E72F; Mon, 24 Jul 2017 17:15:56 +0000 (UTC)
From: Hubert Kario 
To: Benjamin Kaduk 
Cc: tls@ietf.org
Date: Mon, 24 Jul 2017 19:15:50 +0200
Message-ID: <4846144.teiDd8FNEU@pintsize.usersys.redhat.com>
In-Reply-To: <19a5f6c2-20fd-3bf9-f40c-4684c5cbf4f2@akamai.com>
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <166770404.4ZRqQnPX1I@pintsize.usersys.redhat.com> <19a5f6c2-20fd-3bf9-f40c-4684c5cbf4f2@akamai.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart9212555.pZTt3EFy63"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 24 Jul 2017 17:15:57 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 17:15:59 -0000

--nextPart9212555.pZTt3EFy63
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> >> I'm afraid I don't understand this remark. There is the caveat to which
> >> Ilari alludes, that the server can send whatever chain it has, if the
> >> server can't send a chain that complies with the client's
> >> signature_algorithms.  Since certificate validation is assumed to be
> >> largely a function of the PKI library and not really in scope for the
> >> TLS spec itself, this is not particularly problematic.
> >=20
> > true; that disjoint between "stuff that TLS library is supposed to do" =
and
> > "stuff that PKI library is supposed to do" could be spelled out more
> > explicitly in the RFC though
>=20
> I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
> don't have high hopes that it won't just get closed with no action.
>=20
> >> The other main
> >> usage of the signature_algorithms limits what can be used in
> >> CertificateVerify, which is directly relevant to TLS and depends on the
> >> key attested to in the certificate.  Are you claiming that there are
> >> servers that only possess certificates with p384 keys (i.e., no RSA or
> >> p256 or other fallback cert)?
> >=20
> > Yes, there are servers that have P-384 keys. Not sure if they have a du=
al
> > stack (but that is unlikely as only about 30% of servers with ECDSA cer=
ts
> > have also RSA cert).
>=20
> To clarify, you are arguing that P-384 should also be listed as MTI?

no, I'm arguing either for dropping the curve from signature algorithms, or=
 to=20
bind RSA key sizes to hashes 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 115, 612 00  Brno, Czech Republic
--nextPart9212555.pZTt3EFy63
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

iQIbBAABCgAGBQJZditGAAoJEJKo0bgB0vX1i9oP+OEjPN0DqP8T/FJYcFxT3R0G
eikxHHp1Mzo9I6pxWazf5Ekp7Ft76tqfe/zXa9uaY9G5XW79+D/F+d+2xakcyt5r
Na7aykP95kddwT4YQ6hm1NiteJ6c50QD+4JFquWi26jNOqHeBRZllG1c63ME+gON
3WUpLgEIJpTpCDrXcxXatMShvgBoyvIbU9fCSb0qZ9FL3ag2akDOkE/8s77mNxzW
sQHVLwuhW7qEmy3I0cng5+i/AnCyhLxzQuiS7RLYsxarmen12biv9eL0aJoNl/5Z
6erEidMpE3sDHeBFeAmMdgJgdDuM0p9VtAG2CV/jNr8cqzjbGDNcC67vvlyKHiDE
V0MC/XYemqNosjG7ZyoTEPdUchw9zpFmrIu5fVl8JC1fEIEuYt6UEcZBB9HhGJ3F
GLQrCdCr4Mb6rB6x0yMwJe+ixiGgfCkzJ+SWC8IeNpmBCOit+SZRCM2a6Lznnz7U
aRmrFlJgllgPSweBhfMKK5oSKCm1KtfKhQJVxw7CD2vi0zQBZZ54CwvwvsEAJBCn
ljBz89i1QU2SEIdzeAM3gtvxrhDaeGLLwXsMW4DBxcf02VjO+zSsA8+LiqMFswgP
oN86lCK1JZ2+2RSNNZk3CWn9OEwyEFf9b0bHWHea0Nfx8CDmUiWN9tDYm6ODM6cz
6ILHHt1ArPqwFtbQpko=
=Fl+a
-----END PGP SIGNATURE-----

--nextPart9212555.pZTt3EFy63--


From nobody Mon Jul 24 10:16:07 2017
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 E5937131DA5 for ; Mon, 24 Jul 2017 10:15:59 -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 JflmExJdenN1 for ; Mon, 24 Jul 2017 10:15:58 -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 566D4131EB9 for ; Mon, 24 Jul 2017 10:15:58 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id a12so52918064ywh.3 for ; Mon, 24 Jul 2017 10:15:58 -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=gvvalUMNTmpdf2WxGeQSWUZYkT+/508gvBHBkdv4XCM=; b=IaMbh1QV0vM66PxdGZmlLlm/l/mt5S6zZ2Ej3j2wcQzvRMZmhPWWCE651GRv9Hn28G N9YrivfI+hbWoCBcFCbN8MEeqN8j6mCJUYjkhe9mU8i1kLaHOA6GpX8nS6lfWCWC7EDc 1d4vSANOTXiEC43krv7RpQ+iBSm973h0AaZG1Cft+A9Sl/EbhipDc3ydG1haoC7vp3sz gMXzAk8X0M/sWflnIM9FFmYBnrlflRR5x7Sr0RGwUwsmsIlViqxw68I5ifcZDEUyqexD Mtkod0Q0ljCv0pz/eS1f9BazuzDl4CjKgqzBorRkPn/DlnaqwFEBPEKjCKff8MYu1+7+ CKrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gvvalUMNTmpdf2WxGeQSWUZYkT+/508gvBHBkdv4XCM=; b=UmW0FhcNJ5WoOKJwsI1u1j+k7rhOSqMcdkMC7SeT74YfHUO4153ny3UKUYPfxBiUVW naLQL6iEG30bxOY2T6ApK3OqS2pOyt2H8vsV7ueHBgrKIqhBnan/K6FuZeA5C/eTbfSP h4lAFSvQd1fDVR+pZyXqIi6da6KG056K4Ik3Tc/17xcrE6uRlIo4RWPva2bM3pEsHUdm FjE6DYlk2IpcvzE8a1pSSllMJBLpLmAXfPxDRurQm/KVpwTcwtGKwaBgSJ6nECL4yhSc h4yp75oHAZ2vY0D+YTsAtq9q2vLJKeQxsXGs2+63r/J3soVco28T0DXcmDOPfVg9DL9u LLvA==
X-Gm-Message-State: AIVw1135Bh2cfX03WHYS/rTQCTkj7+N8O/uEi5OUoBZHSHnYdfEsklXh 1T8BoYEp2U06AvGWSxIB//DBpTpX5Pny
X-Received: by 10.129.68.14 with SMTP id r14mr13541750ywa.83.1500916557131; Mon, 24 Jul 2017 10:15:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.71 with HTTP; Mon, 24 Jul 2017 10:15:56 -0700 (PDT)
In-Reply-To: 
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>    
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Mon, 24 Jul 2017 10:15:56 -0700
Message-ID: 
To: Watson Ladd 
Cc: Stephen Farrell , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045ecc5c39ecaf0555135ebf"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 17:16:00 -0000

--f403045ecc5c39ecaf0555135ebf
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 24, 2017 at 8:29 AM, Watson Ladd  wrote:

> Don't use bad prngs. And don't buy products from vendors who ship back
> doors and refuse to come completely clean when confronted.
>

Just yesterday DJB posted a blog post about AES-CTR-DRBG, one of the most
widely-used PRNGs, and he points out a security optimization that can be
applied to it, one that escaped years of review. The optimization only
applies if you're generating large chunks of random data, so doesn't apply
to TLS, where the chunks are small; but it's still interesting that we're
still finding improvements and problems in this area.

The PRNG sits at the very bottom of the security of TLS, and biases there
have the potential to break everything, including back in time; they could
defeat PFS and uncloak years worth of data. We don't always know what's bad
t the time that we are using it; e.g. arc4random was considered fine for
years.

I think it's wise to take some measures to handle the "Well, if it were
broken, how would we add defense in depth ...".

-- 
Colm

--f403045ecc5c39ecaf0555135ebf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Mon, Jul 24, 2017 at 8:29 AM, Watson Ladd <watsonbladd@gmail.co=
m> wrote:
    Don't =
use bad prngs. And don't buy products from vendors who ship back doors =
and refuse to come completely clean when confronted.

    Just yesterday DJB posted a blog p=
ost about AES-CTR-DRBG, one of the most widely-used PRNGs, and he points ou=
t a security optimization that can be applied to it, one that escaped years=
 of review. The optimization only applies if you're generating large ch=
unks of random data, so doesn't apply to TLS, where the chunks are smal=
l; but it's still interesting that we're still finding improvements=
 and problems in this area.

    The PRNG sits at the v=
ery bottom of the security of TLS, and biases there have the potential to b=
reak everything, including back in time; they could defeat PFS and uncloak =
years worth of data. We don't always know what's bad t the time tha=
t we are using it; e.g. arc4random was considered fine for years.=C2=A0

    I think it's wise to take some measures to handle=
 the "Well, if it were broken, how would we add defense in depth ...&q=
uot;.=C2=A0

    -- 
    Colm
    

    

--f403045ecc5c39ecaf0555135ebf--


From nobody Mon Jul 24 10:27:23 2017
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 2506B131EBB for ; Mon, 24 Jul 2017 10:27:21 -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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pahtak-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 H_F5gna7U7EV for ; Mon, 24 Jul 2017 10:27:19 -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 D3E4F131EC2 for ; Mon, 24 Jul 2017 10:27:17 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id h199so38043249ith.0 for ; Mon, 24 Jul 2017 10:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pahtak-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=luxmPru+TH68U2VLm4kaEww2lIvg2o16d13bKiEIG20=; b=0HMRR4tuEXHeWDxVND3HOXV8ero2rQIFg1bTkDADzrpWfG5OP5e57mLFdkezqRhIxA Q5CpYU0inzFagxt06IT5CS9O9niAFe0/Oa6RNdXoCo2BiuiEmZsI0Cgr0q01pneejs8o XWyz+zgiJBQgJO5JGOlRZiIU9aH6QsV8H/WDuRRkJJivJ0W8yWRC3M3vJ802VtvtkjuD TQiHt2oy5Pw/FR3TcFtM0ret1xYEQYys0mEOIE1BMXQ/45NSaNeg3UorFgBa7qpUR1Yo lZwltK1JE1Ewjxtdc4JrqyNJuwsLI+yqqBwiffxzRPBJ15xe53A6oU8eSKGDhAYokXTn sDXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=luxmPru+TH68U2VLm4kaEww2lIvg2o16d13bKiEIG20=; b=XOO5sUIpJ/+o5c0xXCJnYbo05AMLTOtxQiJMGUOrl7jIUcgC6kFuBJpYdl3XPLVFI1 soU5X1/A3D+8bUxappbC3zfciHmg3hGgVgBRb47jWNMw7hEBh9T1ZNlxj76MnS/FSUxE OdRNar+NGtajx8sJXrckvLw76ymC34RiedU45Oh3o1UBNGmzqysT1jJyLgUTT2bsK5wl txib/EjiP1Ox5O3DxjUbKxEhivDXO4Eny8guAphDmXvocGrUt1jG9DJLNkFM+l0eJzvS 79oPBSD7h4p2NyuObsxGWhkc4+bvtY0AKJ7qv98SDZjPL2wrKj1OMyXBelkjrXJYgX6n mgMA==
X-Gm-Message-State: AIVw1107AKHL515imc+/MPg5hvDQuj9lE1DhOdxPg6Fqpuri64jodPtO TkfQ3NwIe3VBlhdeLThg/Q==
X-Received: by 10.36.71.135 with SMTP id t129mr8070220itb.141.1500917236604; Mon, 24 Jul 2017 10:27:16 -0700 (PDT)
Received: from zbox.pahtak.org ([2601:241:8b00:fe1f:201:2eff:febc:8976]) by smtp.gmail.com with ESMTPSA id z13sm4146875ita.22.2017.07.24.10.27.15 for  (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 24 Jul 2017 10:27:15 -0700 (PDT)
Received: from [10.186.35.22] (unknown [187.45.180.27]) by zbox.pahtak.org (Postfix) with ESMTPSA id 3D528AC2E0F for ; Mon, 24 Jul 2017 12:27:13 -0500 (CDT)
From: Stephen Checkoway 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: 
Date: Mon, 24 Jul 2017 12:27:11 -0500
To: "tls@ietf.org (tls@ietf.org)" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [TLS] TLS 1.3 presentation language
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 17:27:21 -0000

For the most part, the presentation language (somewhat informally) =
described in section 3 and its use throughout the document is clear, but =
the use doesn't always match the description and some things are written =
in different ways. I have a few examples below of the issues I've =
noticed. After the examples, I make concrete suggestions. To keep the =
following text as uncluttered as possible but still provide easy =
reference, I've copied the relevant structures definitions from Appendix =
B at the bottom of this message.

Array lengths have four different formats.

- Literal constants. For example, `opaque Random[32];` or `uint8 =
CipherSuite[2];`.
- Named, implied constants. For example `coordinate_length` in =
`UncompressedPointRepresentation` which doesn't appear anywhere else, =
but is informally described in the following paragraphs. A variant of =
this is `Hash.length` in the `Finished` struct.
- Qualified field names. I.e., `struct.field`. For example =
`TLSPlaintext.length` in the `TLSPlaintext` and `TLSInnerPlaintext` =
structs
- Unqualified field names. I.e., `field` where `field` is in the same =
structure as the array. For example `length` in `TLSCiphertext`.

I think the unqualified field names use should be removed. We should =
write `TLSCiphertext.length` instead. I think this is the only place =
that the unqualified field name appears.

`Hash.length` and `coordinate_length` are both doing the same thing. I =
think they should be written in the same way. `Hash` isn't a defined =
structure that has fields so it makes sense to me to go with =
`hash_length`. (This would also simplify parsing the presentation =
language.)


Next, most uses of `select` don't match the presentation language's =
definition. Here's the general definition.

      struct {
          T1 f1;
          T2 f2;
          ....
          Tn fn;
          select (E) {
              case e1: Te1;
              case e2: Te2;
              ....
              case en: Ten;
          } [[fv]];
      } [[Tv]];

The definition isn't explicit, but it appears that the `Te1`, ..., `Ten` =
should be types but most uses outside of section 3 are _not_ types. The =
only use of `select` that appears to match the example is in the =
`Handshake` struct. `KeyShare` and `PreSharedKeyExtension` have  =
additional fields in their `case` statements and, somewhat confusingly, =
`EarlyDataIndication`'s `case` statements contain both fields and types.

In addition, the only one of those structs to use the optional label on =
the `select` is `Handshake`.

I think we should make the presentation language definition actually =
conform to its use which means we either need to change the definition =
or change the uses. Options include

1. Add anonymous structs around all of the fields in each `case` =
statement.
2. Add auxiliary structure definitions (like we have for `struct {} =
Empty;` already) and use the type names for each `case` statement.
2. Change the definition of the `case` statements from types to a =
sequence of 0 or more fields. Something like
      struct {
          T1 f1;
          T2 f2;
          ....
          Tn fn;
          select (E) {
              case e1:
                  Te1_1 fe1_1;
                  Te1_2 fe1_2;
                  ....
                  Te1_m fe1_m;
              case e2:
                  Te2_1 fe2_1;
                  Te2_2 fe2_2;
                  ....
                  Te2_m fe2_m;
              ....
              case en:
                  Ten_1 fen_1;
                  Ten_2 fen_2;
                  ....
                  Ten_m fen_m;
          } [[fv]];
      } [[Tv]];

Option 1 adds a bunch of otherwise-useless `struct`s inline with the =
case statements making them harder to read. Option 2 is going to be =
slightly easier to read but still adds a bunch of structs. Option 3 =
complicates the definition of `select` but better conforms with what we =
actually do.

Two additional benefits of option 3 are that we could remove the =
optional `select` field label (the `[[fv]]`) and we can get rid of the =
`Empty` structure. The only `select` that actually uses that label is =
`Handshake` and I don't think that label is ever referred to.


Concretely, I think we should make the following changes.
1. Replace `length` with `TLSCiphertext.length` in the definition of =
`TLSCiphertext`.
2. Replace `Hash.length` with `hash_length` throughout (9 instances).
3. Change the definition of `select`'s `case` statements to have 0 or =
more fields (types and names) and remove the optional label.
4. Change the `select` example to match the new definition.
5. Change `Handshake` by adding field names to each `case` statement. =
(These could all be `body` or they could be unique.) Remove the `body` =
label.
6. Delete the `Empty` structure and replace both current uses with the =
comment `/* Empty */`.

Thoughts?

Copied from Appendix B for reference.

      struct {
          uint8                legacy_form =3D 4;
          opaque               X[coordinate_length];
          opaque               Y[coordinate_length];
      } UncompressedPointRepresentation;

      struct {
          opaque verify_data[Hash.length];
      } Finished;

      struct {
          ContentType type;
          ProtocolVersion legacy_record_version;
          uint16 length;
          opaque fragment[TLSPlaintext.length];
      } TLSPlaintext;

      struct {
          opaque content[TLSPlaintext.length];
          ContentType type;
          uint8 zeros[length_of_padding];
      } TLSInnerPlaintext;

      struct {
          ContentType opaque_type =3D 23; /* application_data */
          ProtocolVersion legacy_record_version =3D 0x0301; /* TLS v1.x =
*/
          uint16 length;
          opaque encrypted_record[length];
      } TLSCiphertext;

      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case end_of_early_data:     EndOfEarlyData;
              case hello_retry_request:   HelloRetryRequest;
              case encrypted_extensions:  EncryptedExtensions;
              case certificate_request:   CertificateRequest;
              case certificate:           Certificate;
              case certificate_verify:    CertificateVerify;
              case finished:              Finished;
              case new_session_ticket:    NewSessionTicket;
              case key_update:            KeyUpdate;
          } body;
      } Handshake;

   struct {
       select (Handshake.msg_type) {
           case client_hello:
               KeyShareEntry client_shares<0..2^16-1>;

           case hello_retry_request:
               NamedGroup selected_group;

           case server_hello:
               KeyShareEntry server_share;
       };
   } KeyShare;

   struct {
       select (Handshake.msg_type) {
           case client_hello:
               PskIdentity identities<7..2^16-1>;
               PskBinderEntry binders<33..2^16-1>;

           case server_hello:
               uint16 selected_identity;
       };

   } PreSharedKeyExtension;

   struct {
       select (Handshake.msg_type) {
           case new_session_ticket:   uint32 max_early_data_size;
           case client_hello:         Empty;
           case encrypted_extensions: Empty;
       };
   } EarlyDataIndication;

--=20
Stephen Checkoway




From nobody Mon Jul 24 10:58:59 2017
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 65CB6129B55 for ; Mon, 24 Jul 2017 10:58:57 -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 XDAsnVeTHjd8 for ; Mon, 24 Jul 2017 10:58:55 -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 46E5A129B19 for ; Mon, 24 Jul 2017 10:58:55 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id x125so54055223ywa.0 for ; Mon, 24 Jul 2017 10:58:55 -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=LzuVQdIok55iPXBMgP4TH8HATddx96wadp9AeyWsf3U=; b=PigqwiUtIr7rD4hHjeAAjmm7/qwvyozf5KUw5JPnbHRV5Nc0MDu4S6xyOABoUqFfD5 egxHnvIMrrMvjeUumgJT0UGpEc0KMdLwAcA0BiGHpijuGRIKkXWkRPV+COjMOmQbQBIV b0yLgmrgE6UexWYQB+xtHaXuQRCRVfqLo+FMBkAQdxo5qutevYq6h2Ymk8OgNeUASvuO v8G+N59QgsAG0oI8JDv/WCI23/T7fQIyihbjkILfkE4pNGpYawOqGdCmywVnI7ecQdUU N1mcZTq5a6ogm5JEp3jAUZayEeIvGm7dy1uFhWVyKwqGRTVmpe/cbKzhKyhagaLhHQFe rztw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LzuVQdIok55iPXBMgP4TH8HATddx96wadp9AeyWsf3U=; b=YM2E1q+y506l9TMO+A8oHc+fCNO4tQO251bwM/USOSMzQhMIBUP0i9cYySPdhasb7K 8wDRyDkA7zb8yd6RhTQ5GmOLESNuQiyggyCk2RntykTPy3eC6kqB8/DhIqplwH3qT7rZ CgauL3FLSDJtSDEfx+yBDhJwZtyE1YPwwf65I3wJgD1MaDY7MhWH1LwTJ++Vfh+WQrdH 87Kt806sWswqRYlL3lxCVdUvYAoV4JAI5kT7jYSjO7f/o7dGmLUjAIf15aFdANQnahDe v+MEQOkk3Ksn8/B9rH9k4WRjoLPBn+0zFVQkVlIF41mux7q+9IGVhMVqC7o6wIrFfO+n qs3A==
X-Gm-Message-State: AIVw1100SJ9/kTCLTR20GQ4DyPjbx6+xMuTCyUVtD80j628AtqbU+Wle jDp4HvUs2NGVKUgP3aVyLwIdT/uiVipU
X-Received: by 10.129.75.5 with SMTP id y5mr3947284ywa.222.1500919133135; Mon, 24 Jul 2017 10:58:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.36.12 with HTTP; Mon, 24 Jul 2017 10:58:12 -0700 (PDT)
In-Reply-To: <4846144.teiDd8FNEU@pintsize.usersys.redhat.com>
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <166770404.4ZRqQnPX1I@pintsize.usersys.redhat.com> <19a5f6c2-20fd-3bf9-f40c-4684c5cbf4f2@akamai.com> <4846144.teiDd8FNEU@pintsize.usersys.redhat.com>
From: Eric Rescorla 
Date: Mon, 24 Jul 2017 10:58:12 -0700
Message-ID: 
To: Hubert Kario 
Cc: Benjamin Kaduk , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113f1e9ac46f83055513f70d"
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 17:58:57 -0000

--001a113f1e9ac46f83055513f70d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 24, 2017 at 10:15 AM, Hubert Kario  wrote:

> On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> > On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> > >> I'm afraid I don't understand this remark. There is the caveat to
> which
> > >> Ilari alludes, that the server can send whatever chain it has, if th=
e
> > >> server can't send a chain that complies with the client's
> > >> signature_algorithms.  Since certificate validation is assumed to be
> > >> largely a function of the PKI library and not really in scope for th=
e
> > >> TLS spec itself, this is not particularly problematic.
> > >
> > > true; that disjoint between "stuff that TLS library is supposed to do=
"
> and
> > > "stuff that PKI library is supposed to do" could be spelled out more
> > > explicitly in the RFC though
> >
> > I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but =
I
> > don't have high hopes that it won't just get closed with no action.
> >
> > >> The other main
> > >> usage of the signature_algorithms limits what can be used in
> > >> CertificateVerify, which is directly relevant to TLS and depends on
> the
> > >> key attested to in the certificate.  Are you claiming that there are
> > >> servers that only possess certificates with p384 keys (i.e., no RSA =
or
> > >> p256 or other fallback cert)?
> > >
> > > Yes, there are servers that have P-384 keys. Not sure if they have a
> dual
> > > stack (but that is unlikely as only about 30% of servers with ECDSA
> certs
> > > have also RSA cert).
> >
> > To clarify, you are arguing that P-384 should also be listed as MTI?
>
> no, I'm arguing either for dropping the curve from signature algorithms,
> or to
> bind RSA key sizes to hashes too
>


I don't think that either of these are good ideas. It turns out that curves
and
signature algorithms just aren't orthogonal (and even less orthogonal than
hash algorithms) nbut RSA is qualitatively different.

-Ekr


> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a113f1e9ac46f83055513f70d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Mon, Jul 24, 2017 at 10:15 AM, Hubert Kario <hkario@redhat.com&=
gt; wrote:
    On Mon=
day, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
    
> On 07/24/2017 05:49 AM, Hubert Kario wrote:
    
> > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
    
> >> I'm afraid I don't understand this remark. There is t=
he caveat to which
    
> >> Ilari alludes, that the server can send whatever chain it has=
, if the
    
> >> server can't send a chain that complies with the client&#=
39;s
    
> >> signature_algorithms.=C2=A0 Since certificate validation is a=
ssumed to be
    
> >> largely a function of the PKI library and not really in scope=
 for the
    
> >> TLS spec itself, this is not particularly problematic.
    
> >
    
> > true; that disjoint between "stuff that TLS library is suppo=
sed to do" and
    
> > "stuff that PKI library is supposed to do" could be spe=
lled out more
    
> > explicitly in the RFC though
    
>
    
> I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
    
> don't have high hopes that it won't just get closed with no ac=
tion.
    
>
    
> >> The other main
    
> >> usage of the signature_algorithms limits what can be used in<=
br>
> >> CertificateVerify, which is directly relevant to TLS and depe=
nds on the
    
> >> key attested to in the certificate.=C2=A0 Are you claiming th=
at there are
    
> >> servers that only possess certificates with p384 keys (i.e., =
no RSA or
    
> >> p256 or other fallback cert)?
    
> >
    
> > Yes, there are servers that have P-384 keys. Not sure if they hav=
e a dual
    
> > stack (but that is unlikely as only about 30% of servers with ECD=
SA certs
    
> > have also RSA cert).
    
>
    
> To clarify, you are arguing that P-384 should also be listed as MTI?

    
    no, I'm arguing either for dropping the curve from signature alg=
orithms, or to
    
bind RSA key sizes to hashes too


    I don't think that either of these are good ideas. It turns ou=
t that curves and
    signature algorithms just aren't orthogonal=
 (and even less orthogonal than
    hash algorithms) nbut RSA is qual=
itatively different.

    -Ekr

    


    
--
    
Regards,
    
Hubert Kario
    
Senior Quality Engineer, QE BaseOS Security team
    
Web: www.cz.redhat.com
    
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=


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


    

--001a113f1e9ac46f83055513f70d--


From nobody Mon Jul 24 11:08:04 2017
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 F23A9129B55 for ; Mon, 24 Jul 2017 11:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 4VWSjWsw5Lus for ; Mon, 24 Jul 2017 11:07:57 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id C9895128BC8 for ; Mon, 24 Jul 2017 11:07:52 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6OI7jlr040353 for ; Mon, 24 Jul 2017 14:07:48 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] Consistency for Signature Algorithms?
Thread-Index: AQHTAiSgfZ+adEbBZESaIsq1or5QVqJejA4AgAAPw4CAAFSWAIAEI0cAgAAnVwCAAES+AIAAC9YA//+/hYA=
Date: Mon, 24 Jul 2017 18:07:46 +0000
Message-ID: <27D7C278-C11D-4FA6-B262-84ACA5886BFD@ll.mit.edu>
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <166770404.4ZRqQnPX1I@pintsize.usersys.redhat.com> <19a5f6c2-20fd-3bf9-f40c-4684c5cbf4f2@akamai.com> <4846144.teiDd8FNEU@pintsize.usersys.redhat.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.24.0.170702
x-originating-ip: [172.26.150.37]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583750049_294888031"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707240276
Archived-At: 
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 18:08:03 -0000

--B_3583750049_294888031
Content-type: multipart/alternative;
	boundary="B_3583750047_175292294"


--B_3583750047_175292294
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

> To clarify, you are arguing that P-384 should also be listed as MTI?

no, I'm arguing either for dropping the curve from signature algorithms, or=
 to
bind RSA key sizes to hashes too

=20

=20

=C2=A0=C2=A0 I don't think that either of these are good ideas.

=20

+1

=20

Both of these ideas are pretty bad, especially the first one.

=20

Listing P-384 as MTI would be just fine, IMHO.

=20


--B_3583750047_175292294
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


    > To clarify, you are arguing tha=
t P-384 should also be listed as MTI?

    no, I'm arguing either for drop=
ping the curve from signature algorithms, or to
    bind RSA key sizes to has=
hes too
     
     
    =C2=A0=C2=A0=
 I don't think that either of these are good ideas.
     
    +1
     
    Both of these ideas are pre=
tty bad, especially the first one.
    &nb=
sp;
    Listing P-384 as MTI would be just fine, IMH=
O.
     
    =


--B_3583750047_175292294--

--B_3583750049_294888031
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKSUBIdwAAAAC3lzANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE3MDQwNzE5MzYyNFoXDTIwMDQwNjE5MzYyNFow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8OK5RGbI6mDfMw/2HPG57y1TdKRaQwlj5iSXC4gDg
tv34L93tRDUTjA27kFG5HOrWar2c37RMkVX7nFR9TfGZh66CSe7Lj7ZMZ3wNyodJqptavXaV
DjSuqp6sPJGQFZNr/pIA2g/3uUOq/igeInptaYb3eDsTwt4fv4G3iLp5Z/4bd26LDJltFZnE
qOsLsQ3xfkAAaht55x+jl1QNm7+Vfe4RVeInASY7xZu9dQUJChc46p7sVcV9/exjYIkOeeG9
QB6i4CJK4vHbyF2qG+IqZfeYFjXWy3Eq7a7YrgqAl81Xs4Bpjsn9zPlFlwmHNVUBJTgShUql
kFvqKjcw0FDpAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUWa29JQeRiwuEcAGFzsv/xdyErcAw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBCDAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAIjee93wr/GEbKbqkXc5
krqRGzwcj6/NhW9rmX+MwXqm63OL+/H159UXdIQCqdd1uovIOcK8y/gXjlJOJ6ol54aixafq
sz3ozZ+eIUvphrxRVTxR8vVb17QnPxOQE0Mx9N1uRS+Hps7XgDS628KYfzxMb12+2WriuwyM
VAVl+lCBF1S4ZO/0NBx/wVyEu8Hi73kHC93/4HC1c4bwoExAAjY+twm7VBY8eTpvV/604iDf
1NdKtCb5l1fFZkyZnQ5ZDKONBehGsRGF0eWBUDCopoYTu8nbcRocvRGM+ZLFtPLh5xlpjrO2
E+CE6Bjx948aoJJCXqHf7BeKxlbazvl2RaIwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCklA
SHcAAAAAt5cwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgIDRAVERh4xMPyFNZ
NcKKQ2yNbLh+GQRvaYF8JiLH7DgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzI0MTgwNzI5WjANBgkqhkiG9w0BAQEFAASCAQAS8a8mb/2KNjsCAyUf
2H76UwZfNlf7Zbu6546WaL2QJ07wBfvTVn3D/hnzWSYFb4BRHFZBPi3Anl8qBsAEFjhhBY5j
sF5RVOsmFcxu0PE/BPg1ehVR28zywHrGbkaI+7scRPzKsg4e3TCR41lzMufSxFVHZSRlE58t
XfttGfJydX98C3g1h8/z8ql3IiV+vUXbYPgGVAr6eZbd6QMHbrsLrsTOMa0KG7Yv8GPGVwtA
TG+y3p2tR9IY/aoVWX7iyW+t1EE4htk3CIjg2wiZqZJe5I/djGiRwutvVx9SD1kWbmNWQaMD
5XHVX1noaTrjX1ZQf4p76CShOpRNQ8TWhDcM

--B_3583750049_294888031--


From nobody Mon Jul 24 12:32:57 2017
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 5FE1913178D for ; Mon, 24 Jul 2017 12:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 c_uCpyRc6OrR for ; Mon, 24 Jul 2017 12:32:53 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C5B131667 for ; Mon, 24 Jul 2017 12:32:53 -0700 (PDT)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jul 2017 15:32:49 -0400
Received: from XCT115CNC.rim.net (10.65.161.215) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 24 Jul 2017 15:32:51 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Mon, 24 Jul 2017 15:32:50 -0400
From: Dan Brown 
To: Russ Housley 
CC: IETF TLS 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+yUHLG+hMivEObnVpzx6wh/KJjLfkfgABH+AD//+g0gw==
Date: Mon, 24 Jul 2017 19:32:49 +0000
Message-ID: <20170724193246.8573013.22749.16126@blackberry.com>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie> <20170724164022.8573013.93422.16108@blackberry.com>, 
In-Reply-To: 
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 24 Jul 2017 19:32:56 -0000

Thanks for the quick answers.

Yet more naive quick questions: =FDin the reused DH setting could a counter=
 do the job of random nonce?=FD doesn't the record layer have an IV or nonc=
e too? (or is that passe?).

If these questions are too naive, or too last minute, let me know and I'll =
withdraw them. I did look over 1.3 once, fwiw, but have since forgot the de=
tails, sorry.
  Original Message
From: Russ Housley
Sent: Monday, July 24, 2017 12:58 PM
To: Dan Brown
Cc: IETF TLS
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's


there was a discussion of adding a statement that a fresh ephemeral key MUS=
T be used for each session.  It was decided not to do that.  Without such a=
 requirement, nonces are needed.

Russ


> On Jul 24, 2017, at 12:40 PM, Dan Brown  wrote:
>
> Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, giv=
en that ephemeral DH is mandated, if anybody has the time/patience. (* ok, =
not that I truly ever knew).
>
> I assume that the risk of misusing the nonces, to exfiltrate keys etc, is=
 small enough compared to other side channels to justify their added value.
>
>
>  Original Message
> From: Stephen Farrell
> Sent: Monday, July 24, 2017 11:15 AM
> To: tls@ietf.org
> Subject: [TLS] 32 byte randoms in TLS1.3 hello's
>
>
> Hiya,
>
> I'm guessing many folks interested in TLS may have been
> at the QUIC session in Prague and hence missed out on the
> excellent talk by Stephen Checkoway on the juniper dual-ec
> incident. (I highly recommend taking a peek at the slides [1]
> or reading the paper [2] or watching the video wherever
> that may be;-).
>
> Anyway, in TLS1.3 we've gotten rid of the gmt time option
> in the client and server hello, which is good, (and I do
> recall that discussion) but we've also changed from:
>
>   // RFC5246
>   struct {
>      uint32 gmt_unix_time;
>      opaque random_bytes[28];
>   } Random;
>
> to:
>
>   // tls1.3 -21
>   opaque Random[32];
>
> Now if some TLS1.3 deployment were affected by a dual-ec
> attack, it'd seem like the -21 version of Random might be
> even better than the TLS1.2 version, for the attacker.
>
> I tried to see where that 28->32 change came from but
> didn't find it (apologies if I missed that). I guess it
> just ensures that the overall length of the struct is
> the same.
>
> So, a question and a possible suggestion:
>
> Q: Why do we need 32 bytes of Random?
>
> Suggestion: if we don't need that much, maybe we could
> change the length there, (I can see that might trigger
> bugs and middlebox issues) or encourage/require folks
> to mask out some of those bits (e.g. with zeros or some
> catchy hex encoded message about dual-ec:-).
>
> Cheers,
> S.
>
>
> [1]
> https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephe=
n-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
> [2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Mon Jul 24 20:54:00 2017
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 84BD7126B7F for ; Mon, 24 Jul 2017 20:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 LISX0kHbu5u9 for ; Mon, 24 Jul 2017 20:53:56 -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 137081242F7 for ; Mon, 24 Jul 2017 20:53:55 -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=1500954836; x=1532490836; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4C2UP8zcBBfGiXYwqnp8gMTpFNR1Awr5RaM1IfKh3PA=; b=r6datC/FEAk+yD9eQVHNCYey5a0PM64/n6EQRXA080+j3apC3J7jxzLa F1fK9Y85LG49meNzDra84v20V/EnHNWJIKjtxKXN0d6ffmcA5N29Bl8lc JjgOgjd7fKRGjztPt4UD4XS/pToyKvDogWl0d8sefJwsBGCbTnBbaHgf7 Np1QpCoz+DtiypteRDPgnN9MjrEHeO4zEQcoS9fo/yzQfN9kTdwtGcw9a qvP6UJThMjz5xxAgNfmWxi7k7eVcg42/PrHo3vMOoQeq1y36REPqXF/F8 ETZjmF/iQPulIuTv5kQZG1y71oWylf4z8R58/fXhi0TlnBMqNHWuJT7rM Q==;
X-IronPort-AV: E=Sophos;i="5.40,410,1496059200"; d="scan'208";a="168034697"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing
Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2017 15:53:53 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 25 Jul 2017 15:53:53 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 25 Jul 2017 15:53:53 +1200
From: Peter Gutmann 
To: =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , Stephen Farrell 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+2hSpUAt7/bkebxZ5uN/u91aJibPQAgAF9Cgg=
Date: Tue, 25 Jul 2017 03:53:53 +0000
Message-ID: <1500954833319.1033@cs.auckland.ac.nz>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>, 
In-Reply-To: 
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 03:53:59 -0000

Colm MacC=E1rthaigh  writes:=0A=
=0A=
>I think the fix for this is really at the application level; if you =0A=
>want defense-in-depth against PRNG problems, it's probably best to use =0A=
>separate RNG instances for public data (e.g. client_random, =0A=
>server_random, explicit_IV) and for secret data (keys) so that a leak =0A=
>in the public data doesn't compromise the private one. We do this in =0A=
>s2n, and I think BouncyCastle does it too. =0A=
=0A=
I do that too.=A0 It's also specified in the LTS draft, it's just common =
=0A=
sense really.=0A=
=0A=
Peter.=0A=


From nobody Mon Jul 24 22:26:48 2017
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 39648127B57 for ; Mon, 24 Jul 2017 22:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4eXImsmN9Q4Y for ; Mon, 24 Jul 2017 22:26:43 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48830126DC2 for ; Mon, 24 Jul 2017 22:26:42 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLF98987; Tue, 25 Jul 2017 05:26:40 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 25 Jul 2017 06:26:38 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.23]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0301.000; Tue, 25 Jul 2017 10:56:27 +0530
From: Raja ashok 
To: David Benjamin 
CC: "" 
Thread-Topic: [TLS] Doubts in draft-ietf-tls-rfc4492bis
Thread-Index: AQHTBI1O+/71ZfDgdUGLLrPh7n3g+qJizhUAgAEsEvA=
Date: Tue, 25 Jul 2017 05:26:26 +0000
Message-ID: 
References:  <20170724145815.xuhzjqsbnf5eardr@LK-Perkele-VII> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.213.121]
Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2301389BLREML503MBXchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5976D690.00F5, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.9.23, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f2f69cd4c5132b3e19eb3d4111334657
Archived-At: 
Subject: Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 05:26:46 -0000

--_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2301389BLREML503MBXchi_
Content-Type: multipart/alternative;
	boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2301389BLREML503MBXchi_"

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2301389BLREML503MBXchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRGF2aWQsDQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4NCg0KSWYgaXQgaXMgYWxyZWFk
eSBmaXhlZCBpbiBUTFMxLjMsIHRoZW4gSSBhbHNvIGZlZWwgb2sgdG8gbGVhdmUgdGhpcyBiZWhh
dmlvciBmb3Igb2xkZXIgdmVyc2lvbiAoVExTMS4yIGFuZCBlYXJsaWVyKS4NClJlY2VudGx5IEkg
c3RhcnRlZCByZWFkaW5nIFRMUzEuMyBzcGVjaWZpY2F0aW9uLCBJIHdpbGwgZ28gdGhyb3VnaCBm
dWxseSB0byBnZXQgbW9yZSBpbmZvLg0KDQpSZWdhcmRzLA0KQXNob2sNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCltDb21wYW55X2xvZ29dDQoNClJhamEgQXNob2sgViBLDQpI
dWF3ZWkgVGVjaG5vbG9naWVzDQpCYW5nYWxvcmUsIEluZGlhDQpodHRwOi8vd3d3Lmh1YXdlaS5j
b20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrmnKzpgq7ku7blj4rlhbbpmYTk
u7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nk
uIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoENCuatouS7u+S9leWF
tuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8iOWMheaLrOS9huS4jemZkOS6juWFqOmDqOaI
lumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaIluaVo+WPke+8ieacrOmCruS7tuS4rQ0K55qE
5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d
5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBDQpUaGlzIGUtbWFp
bCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZy
b20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRp
dHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1h
dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1p
dGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRp
c3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVu
dChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwg
cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBh
bmQgZGVsZXRlIGl0IQ0KDQpGcm9tOiBEYXZpZCBCZW5qYW1pbiBbbWFpbHRvOmRhdmlkYmVuQGNo
cm9taXVtLm9yZ10NClNlbnQ6IDI0IEp1bHkgMjAxNyAyMTo1Nw0KVG86IElsYXJpIExpdXN2YWFy
YTsgUmFqYSBhc2hvaw0KQ2M6IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gRG91
YnRzIGluIGRyYWZ0LWlldGYtdGxzLXJmYzQ0OTJiaXMNCg0KSSBiZWxpZXZlIHdoYXQgUmFqYSBp
cyBwb2ludGluZyBvdXQgaXMgdGhhdCBhIHNlcnZlciB3aGljaCBhY2NlcHRzIGFuIEVDRFNBICpj
bGllbnQqIGNlcnRpZmljYXRlIGhhcyBubyB3YXkgdG8gYWR2ZXJ0aXNlIHRvIHRoZSBjbGllbnQg
d2hpY2ggY3VydmVzIGl0IGFjY2VwdHMuIFRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIGxpc3QgKGFu
ZCBiZWZvcmUgVExTIDEuMiwgdGhlIGNlcnRpZmljYXRlIHR5cGVzKSBkbyBhZHZlcnRpc2UgRUNE
U0EgYXMgYSB3aG9sZSwgYnV0IG5vdCBjdXJ2ZXMuIEUuZy4sIGEgY2xpZW50IHdpdGggYm90aCBh
IFAtMjU2IGFuZCBQLTM4NCBjZXJ0aWZpY2F0ZSBtYXkgc2VuZCBQLTM4NCB3aGVuIHRoZSBzZXJ2
ZXIgb25seSBhY2NlcHRlZCBQLTI1Ni4gVGhpcyBpc3N1ZSBleGlzdGVkIGluIFJGQyA0NDkyIGFz
IHdlbGwuDQoNClRob3VnaCBJIHdvdWxkbid0IHNheSB0aGUgaW1wbGljYXRpb24gaXMgYWxsIGN1
cnZlcyBtdXN0IGJlIGltcGxlbWVudGVkLiBSYXRoZXIgSSB0aGluayB5b3UganVzdCByZWplY3Qg
dGhvc2UgY3VydmVzIHlvdSBkb24ndCBhY2NlcHQgYW5kIG1hbmFnZSB5b3VyIGNsaWVudCBjZXJ0
aWZpY2F0ZSBkZXBsb3ltZW50IHNvIHRoYXQgYWxsIHNlcnZlcnMgYWNjZXB0IGEgY3VydmUgYmVm
b3JlIHN0YXJ0aW5nIHRvIHVzZSB0aG9zZSBjZXJ0aWZpY2F0ZXMuDQoNClRoYXQncyBub3QgZ3Jl
YXQsIHNvIFRMUyAxLjMgZml4ZXMgdGhpcyBieSBtb3ZpbmcgRUNEU0EgY3VydmVzIGludG8gc2ln
bmF0dXJlIGFsZ29yaXRobXMuIEl0J3MgdG9vIGxhdGUgdG8gY2hhbmdlIHN1cHBvcnRlZF9ncm91
cHMgdG8gYWxsb3cgYSBUTFMgMS4yIFNlcnZlckhlbGxvIGFja25vd2xlZGdlbWVudCBzaW5jZSBj
bGllbnRzIHdpbGwgdW5leHBlY3RlZCBzZXJ2ZXIgZXh0ZW5zaW9uc1sqXSwgc28gSSB3b3VsZCBz
dWdnZXN0IHdlIGp1c3QgbGVhdmUgdGhpcyBpbiB0aGUgYXdrd2FyZCBzdGF0ZSBmb3IgVExTIDEu
MiBhbmQgc2F5IGl0IGlzIGZpeGVkIGluIFRMUyAxLjMuDQoNCkRhdmlkDQoNClsqXSBBbHRob3Vn
aCwgZ2xhbmNpbmcgdGhyb3VnaCBvdXJzLCBpdCBzZWVtcyB3ZSBkbyBhY2NlcHQgYW5kIGlnbm9y
ZSBhIFNlcnZlckhlbGxvIHN1cHBvcnRlZF9ncm91cHMgaW4gVExTIDEuMi4gV2UgYXBwYXJlbnRs
eSBjYW1lIGFjcm9zcyBhIHNlcnZlciBpbXBsZW1lbnRhdGlvbiB3aGljaCBzZW50IGl0LCBjb250
cmFyeSB0byB0aGUgc3BlYy4NCk9uIE1vbiwgSnVsIDI0LCAyMDE3IGF0IDEwOjU4IEFNIElsYXJp
IExpdXN2YWFyYSA8aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tPG1haWx0bzppbGFyaWxpdXN2YWFy
YUB3ZWxoby5jb20+PiB3cm90ZToNCk9uIE1vbiwgSnVsIDI0LCAyMDE3IGF0IDAxOjQ4OjEzUE0g
KzAwMDAsIFJhamEgYXNob2sgd3JvdGU6DQo+IEhpIE5pciwgSm9zZWZzc29uICYgUGVnb3VyaWUs
DQo+DQo+IEFzIHBlciBzZWN0aW9uIDUuMiBzZXJ2ZXIgc2hvdWxkIHNlbmQgb25seSAiU3VwcG9y
dGVkIFBvaW50IEZvcm1hdCINCj4gZXh0ZW5zaW9ucyBpbiBzZXJ2ZXIgaGVsbG8gbWVzc2FnZS4g
QW5kIGl0IGRvZXNuJ3QgcmVxdWlyZSB0byBzZW5kDQo+ICJTdXBwb3J0ZWQgRWxsaXB0aWMgQ3Vy
dmUiIGV4dGVuc2lvbnMuIEJlY2F1c2Ugb2YgdGhpcyBpZiBzZXJ2ZXIgaXMNCj4gc3VwcG9ydGlu
ZyBvbmx5IGZldyBDdXJ2ZXMgYW5kIGlmIGl0IHJlY2VpdmVzIHVuc3VwcG9ydGVkIEVsbGlwdGlj
DQo+IGN1cnZlIGluIGNsaWVudCBjZXJ0aWZpY2F0ZSBtZXNzYWdlLCB0aGVuIHNlcnZlciBtaWdo
dCBub3QgYmUgYWJsZQ0KPiB0byBjb250aW51ZSB0aGUgaGFuZHNoYWtlLg0KDQpJbiBUTFMgMS4y
LCB0aGUgY2xpZW50IHNlbmRzIHRoZSBsaXN0IG9mIGN1cnZlcyAoYW5kIG90aGVyIGdyb3Vwcw0K
YW5kIERIRnMpIGl0IHN1cHBvcnRzLiBUaGUgc2VydmVyIHBpY2tzIG9uZSBpZiBpdCBjYW4uDQoN
ClRodXMgaWYgdGhlcmUgaXMgYXQgbGVhc3Qgb25lIGNvbW1vbiBjdXJ2ZSB0aGF0IGJvdGggY2xp
ZW50IGFuZA0Kc2VydmVyIHN1cHBvcnQsIHRoZW4gdGhlIGdyb3VwIHNlbGVjdGlvbiB3aWxsIHN1
Y2NlZWQgKGlmIHRoZXJlDQppcyBub25lLCB0aGVuIG5vIG1hdHRlciB3aGF0IG9uZSBkb2VzIHRo
aW5ncyB3b24ndCB3b3JrKS4NCg0KVGhlIGFjdHVhbCBjdXJ2ZSBzZXJ2ZXIgc2VsZWN0ZWQgaXMg
dHJhbnNtaXR0ZWQgaW4gU2VydmVyS2V5RXhjaGFuZ2UNCm1lc3NhZ2UuDQoNCg0KSW4gVExTIDEu
MywgdGhpbmdzIGdldCBiaXQgbW9yZSBjb21wbGljYXRlZCwgc2luY2UgY2xpZW50IGNhbg0Kc2ln
bmFsIGl0IHN1cHBvcnRzIGEgZ3JvdXAgd2l0aG91dCBzZW5kaW5nIGEgc2hhcmUgZm9yIGl0IChp
Zg0Kc2VydmVyIHNlbGVjdHMgc3VjaCBncm91cCwgaXQgbmVlZHMgdG8gdGVsbCB0aGUgY2xpZW50
IHRvIHJldHJ5DQp1c2luZyBIZWxsb1JldHJ5UmVxdWVzdCBtZXNzYWdlKS4gVGhlIHNlcnZlciBn
cm91cCBzZWxlY3Rpb24gaXMNCmluIEtleVNoYXJlIGV4dGVuc2lvbiBpbiBTZXJ2ZXJIZWxsbyBt
ZXNzYWdlLg0KDQoNCi1JbGFyaQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2301389BLREML503MBXchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrljY7mlofnu4bpu5E7fQ0KLyogU3R5bGUgRGVm
aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7
bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN
Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N
c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s
bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ
Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt
b25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy
Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh
Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIyMDUwIiAvPg0KPC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i
ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91
dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
SGkgRGF2aWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J
ZiBpdCBpcyBhbHJlYWR5IGZpeGVkIGluIFRMUzEuMywgdGhlbiBJIGFsc28gZmVlbCBvayB0byBs
ZWF2ZSB0aGlzIGJlaGF2aW9yIGZvciBvbGRlciB2ZXJzaW9uIChUTFMxLjIgYW5kIGVhcmxpZXIp
Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlY2VudGx5IEkgc3RhcnRlZCByZWFk
aW5nIFRMUzEuMyBzcGVjaWZpY2F0aW9uLCBJIHdpbGwgZ28gdGhyb3VnaCBmdWxseSB0byBnZXQg
bW9yZSBpbmZvLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5Bc2hvazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl
PSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bh
bj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFw
ZXR5cGUgaWQ9Il94MDAwMF90NzUiIGNvb3Jkc2l6ZT0iMjE2MDAsMjE2MDAiIG86c3B0PSI3NSIg
bzpwcmVmZXJyZWxhdGl2ZT0idCIgcGF0aD0ibUA0QDVsQDRAMTFAOUAxMUA5QDV4ZSIgZmlsbGVk
PSJmIiBzdHJva2VkPSJmIj4NCjx2OnN0cm9rZSBqb2luc3R5bGU9Im1pdGVyIiAvPg0KPHY6Zm9y
bXVsYXM+DQo8djpmIGVxbj0iaWYgbGluZURyYXduIHBpeGVsTGluZVdpZHRoIDAiIC8+DQo8djpm
IGVxbj0ic3VtIEAwIDEgMCIgLz4NCjx2OmYgZXFuPSJzdW0gMCAwIEAxIiAvPg0KPHY6ZiBlcW49
InByb2QgQDIgMSAyIiAvPg0KPHY6ZiBlcW49InByb2QgQDMgMjE2MDAgcGl4ZWxXaWR0aCIgLz4N
Cjx2OmYgZXFuPSJwcm9kIEAzIDIxNjAwIHBpeGVsSGVpZ2h0IiAvPg0KPHY6ZiBlcW49InN1bSBA
MCAwIDEiIC8+DQo8djpmIGVxbj0icHJvZCBANiAxIDIiIC8+DQo8djpmIGVxbj0icHJvZCBANyAy
MTYwMCBwaXhlbFdpZHRoIiAvPg0KPHY6ZiBlcW49InN1bSBAOCAyMTYwMCAwIiAvPg0KPHY6ZiBl
cW49InByb2QgQDcgMjE2MDAgcGl4ZWxIZWlnaHQiIC8+DQo8djpmIGVxbj0ic3VtIEAxMCAyMTYw
MCAwIiAvPg0KPC92OmZvcm11bGFzPg0KPHY6cGF0aCBvOmV4dHJ1c2lvbm9rPSJmIiBncmFkaWVu
dHNoYXBlb2s9InQiIG86Y29ubmVjdHR5cGU9InJlY3QiIC8+DQo8bzpsb2NrIHY6ZXh0PSJlZGl0
IiBhc3BlY3RyYXRpbz0idCIgLz4NCjwvdjpzaGFwZXR5cGU+PHY6c2hhcGUgaWQ9InJpZEltZyIg
bzpzcGlkPSJfeDAwMDBfczEwMjYiIHR5cGU9IiNfeDAwMDBfdDc1IiBhbHQ9IkNvbXBhbnlfbG9n
byIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjA7bWFyZ2luLXRvcDowO3dp
ZHRoOjc2LjVwdDtoZWlnaHQ6MjRwdDt6LWluZGV4OjE7dmlzaWJpbGl0eTp2aXNpYmxlO21zby13
cmFwLXN0eWxlOnNxdWFyZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjA7bXNvLXdyYXAtZGlzdGFu
Y2UtdG9wOjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6MDttc28td3JhcC1kaXN0YW5jZS1ib3R0
b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDpsZWZ0O21zby1wb3NpdGlvbi1ob3Jpem9udGFs
LXJlbGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRlO21zby1wb3NpdGlv
bi12ZXJ0aWNhbC1yZWxhdGl2ZTpsaW5lJyBvOmFsbG93b3ZlcmxhcD0iZiI+DQo8djppbWFnZWRh
dGEgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDMwNTM0LkE4RUQwNDIwIiBvOmhyZWY9ImZpbGU6
Ly8vQzpcVXNlcnNccjAwOTAyNzM2XEFwcGxpY2F0aW9uJTIwRGF0YVxNaWNyb3NvZnRcU2lnbmF0
dXJlc1xjb21wYW55X2xvZ28uanBnIiAvPg0KPHc6d3JhcCB0eXBlPSJzcXVhcmUiIGFuY2hvcnk9
ImxpbmUiLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtpZiAhdm1sXT48aW1nIHdpZHRoPSIx
MDIiIGhlaWdodD0iMzIiIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUQzMDUzNC5BOEVEMDQyMCIg
YWxpZ249ImxlZnQiIGFsdD0iQ29tcGFueV9sb2dvIiB2OnNoYXBlcz0icmlkSW1nIj48IVtlbmRp
Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NCjxicj4N
Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU5NTk1OSI+UmFqYSBB
c2hvayBWIEs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1OTU5NTki
Pjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU5NTk1OSI+
SHVhd2VpIFRlY2hub2xvZ2llczxicj4NCkJhbmdhbG9yZSwgSW5kaWE8YnI+DQpodHRwOi8vd3d3
Lmh1YXdlaS5jb20gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFs
IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTrlrovkvZM7Y29sb3I6IzFGNDk3RCI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEw
MCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk65a6L
5L2TO2NvbG9yOmdyYXkiPuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWFrOWPuOea
hOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWIl+WHuuea
hOS4quS6uuaIlue+pOe7hOOAguemgTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0
O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij48YnI+DQo8L3NwYW4+PHNwYW4g
bGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk65a6L5L2TO2Nv
bG9yOmdyYXkiPuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8iOWMheaL
rOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaIluaVo+WP
ke+8ieacrOmCruS7tuS4rTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt
ZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0i
WkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmdy
YXkiPueahOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WN
s+eUteivneaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gTwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtj
b2xvcjpncmF5Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmdy
YXkiPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwg
aW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQo8YnI+DQppcyBpbnRlbmRlZCBvbmx5IGZv
ciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55
IHVzZSBvZiB0aGUNCjxicj4NCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdh
eSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCjxicj4N
CmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBv
dGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8YnI+DQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4g
SWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl
bmRlciBieQ0KPGJyPg0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCE8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+IERhdmlkIEJlbmphbWluIFttYWlsdG86ZGF2aWRiZW5AY2hyb21pdW0ub3JnXQ0KPGJyPg0K
PGI+U2VudDo8L2I+IDI0IEp1bHkgMjAxNyAyMTo1Nzxicj4NCjxiPlRvOjwvYj4gSWxhcmkgTGl1
c3ZhYXJhOyBSYWphIGFzaG9rPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7dGxzQGlldGYub3JnJmd0Ozxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gRG91YnRzIGluIGRyYWZ0LWlldGYtdGxzLXJm
YzQ0OTJiaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg
YmVsaWV2ZSB3aGF0IFJhamEgaXMgcG9pbnRpbmcgb3V0IGlzIHRoYXQgYSBzZXJ2ZXIgd2hpY2gg
YWNjZXB0cyBhbiBFQ0RTQSAqY2xpZW50KiBjZXJ0aWZpY2F0ZSBoYXMgbm8gd2F5IHRvIGFkdmVy
dGlzZSB0byB0aGUgY2xpZW50IHdoaWNoIGN1cnZlcyBpdCBhY2NlcHRzLiBUaGUgc2lnbmF0dXJl
IGFsZ29yaXRobSBsaXN0IChhbmQgYmVmb3JlIFRMUyAxLjIsIHRoZSBjZXJ0aWZpY2F0ZSB0eXBl
cykgZG8NCiBhZHZlcnRpc2UgRUNEU0EgYXMgYSB3aG9sZSwgYnV0IG5vdCBjdXJ2ZXMuIEUuZy4s
IGEgY2xpZW50IHdpdGggYm90aCBhIFAtMjU2IGFuZCBQLTM4NCBjZXJ0aWZpY2F0ZSBtYXkgc2Vu
ZCBQLTM4NCB3aGVuIHRoZSBzZXJ2ZXIgb25seSBhY2NlcHRlZCBQLTI1Ni4gVGhpcyBpc3N1ZSBl
eGlzdGVkIGluIFJGQyA0NDkyIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaG91Z2ggSSB3b3VsZG4ndCBzYXkgdGhlIGltcGxpY2F0aW9uIGlz
IGFsbCBjdXJ2ZXMgbXVzdCBiZSBpbXBsZW1lbnRlZC4gUmF0aGVyIEkgdGhpbmsgeW91IGp1c3Qg
cmVqZWN0IHRob3NlIGN1cnZlcyB5b3UgZG9uJ3QgYWNjZXB0IGFuZCBtYW5hZ2UgeW91ciBjbGll
bnQgY2VydGlmaWNhdGUgZGVwbG95bWVudCBzbyB0aGF0IGFsbCBzZXJ2ZXJzIGFjY2VwdCBhIGN1
cnZlIGJlZm9yZSBzdGFydGluZyB0byB1c2UNCiB0aG9zZSBjZXJ0aWZpY2F0ZXMuPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0J3Mgbm90IGdyZWF0LCBz
byBUTFMgMS4zIGZpeGVzIHRoaXMgYnkgbW92aW5nIEVDRFNBIGN1cnZlcyBpbnRvIHNpZ25hdHVy
ZSBhbGdvcml0aG1zLiBJdCdzIHRvbyBsYXRlIHRvIGNoYW5nZSBzdXBwb3J0ZWRfZ3JvdXBzIHRv
IGFsbG93IGEgVExTIDEuMiBTZXJ2ZXJIZWxsbyBhY2tub3dsZWRnZW1lbnQgc2luY2UgY2xpZW50
cyB3aWxsIHVuZXhwZWN0ZWQgc2VydmVyIGV4dGVuc2lvbnNbKl0sIHNvIEkgd291bGQNCiBzdWdn
ZXN0IHdlIGp1c3QgbGVhdmUgdGhpcyBpbiB0aGUgYXdrd2FyZCBzdGF0ZSBmb3IgVExTIDEuMiBh
bmQgc2F5IGl0IGlzIGZpeGVkIGluIFRMUyAxLjMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+WypdIEFsdGhvdWdoLCBnbGFuY2luZyB0aHJvdWdoIG91cnMsIGl0IHNlZW1zIHdlIGRvIGFj
Y2VwdCBhbmQgaWdub3JlIGEgU2VydmVySGVsbG8gc3VwcG9ydGVkX2dyb3VwcyBpbiBUTFMgMS4y
LiBXZSBhcHBhcmVudGx5IGNhbWUgYWNyb3NzIGEgc2VydmVyIGltcGxlbWVudGF0aW9uIHdoaWNo
IHNlbnQgaXQsIGNvbnRyYXJ5IHRvIHRoZSBzcGVjLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCAyNCwgMjAxNyBhdCAxMDo1OCBB
TSBJbGFyaSBMaXVzdmFhcmEgJmx0OzxhIGhyZWY9Im1haWx0bzppbGFyaWxpdXN2YWFyYUB3ZWxo
by5jb20iPmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBK
dWwgMjQsIDIwMTcgYXQgMDE6NDg6MTNQTSAmIzQzOzAwMDAsIFJhamEgYXNob2sgd3JvdGU6PGJy
Pg0KJmd0OyBIaSBOaXIsIEpvc2Vmc3NvbiAmYW1wOyBQZWdvdXJpZSw8YnI+DQomZ3Q7PGJyPg0K
Jmd0OyBBcyBwZXIgc2VjdGlvbiA1LjIgc2VydmVyIHNob3VsZCBzZW5kIG9ubHkgJnF1b3Q7U3Vw
cG9ydGVkIFBvaW50IEZvcm1hdCZxdW90Ozxicj4NCiZndDsgZXh0ZW5zaW9ucyBpbiBzZXJ2ZXIg
aGVsbG8gbWVzc2FnZS4gQW5kIGl0IGRvZXNuJ3QgcmVxdWlyZSB0byBzZW5kPGJyPg0KJmd0OyAm
cXVvdDtTdXBwb3J0ZWQgRWxsaXB0aWMgQ3VydmUmcXVvdDsgZXh0ZW5zaW9ucy4gQmVjYXVzZSBv
ZiB0aGlzIGlmIHNlcnZlciBpczxicj4NCiZndDsgc3VwcG9ydGluZyBvbmx5IGZldyBDdXJ2ZXMg
YW5kIGlmIGl0IHJlY2VpdmVzIHVuc3VwcG9ydGVkIEVsbGlwdGljPGJyPg0KJmd0OyBjdXJ2ZSBp
biBjbGllbnQgY2VydGlmaWNhdGUgbWVzc2FnZSwgdGhlbiBzZXJ2ZXIgbWlnaHQgbm90IGJlIGFi
bGU8YnI+DQomZ3Q7IHRvIGNvbnRpbnVlIHRoZSBoYW5kc2hha2UuPGJyPg0KPGJyPg0KSW4gVExT
IDEuMiwgdGhlIGNsaWVudCBzZW5kcyB0aGUgbGlzdCBvZiBjdXJ2ZXMgKGFuZCBvdGhlciBncm91
cHM8YnI+DQphbmQgREhGcykgaXQgc3VwcG9ydHMuIFRoZSBzZXJ2ZXIgcGlja3Mgb25lIGlmIGl0
IGNhbi48YnI+DQo8YnI+DQpUaHVzIGlmIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBjb21tb24gY3Vy
dmUgdGhhdCBib3RoIGNsaWVudCBhbmQ8YnI+DQpzZXJ2ZXIgc3VwcG9ydCwgdGhlbiB0aGUgZ3Jv
dXAgc2VsZWN0aW9uIHdpbGwgc3VjY2VlZCAoaWYgdGhlcmU8YnI+DQppcyBub25lLCB0aGVuIG5v
IG1hdHRlciB3aGF0IG9uZSBkb2VzIHRoaW5ncyB3b24ndCB3b3JrKS48YnI+DQo8YnI+DQpUaGUg
YWN0dWFsIGN1cnZlIHNlcnZlciBzZWxlY3RlZCBpcyB0cmFuc21pdHRlZCBpbiBTZXJ2ZXJLZXlF
eGNoYW5nZTxicj4NCm1lc3NhZ2UuPGJyPg0KPGJyPg0KPGJyPg0KSW4gVExTIDEuMywgdGhpbmdz
IGdldCBiaXQgbW9yZSBjb21wbGljYXRlZCwgc2luY2UgY2xpZW50IGNhbjxicj4NCnNpZ25hbCBp
dCBzdXBwb3J0cyBhIGdyb3VwIHdpdGhvdXQgc2VuZGluZyBhIHNoYXJlIGZvciBpdCAoaWY8YnI+
DQpzZXJ2ZXIgc2VsZWN0cyBzdWNoIGdyb3VwLCBpdCBuZWVkcyB0byB0ZWxsIHRoZSBjbGllbnQg
dG8gcmV0cnk8YnI+DQp1c2luZyBIZWxsb1JldHJ5UmVxdWVzdCBtZXNzYWdlKS4gVGhlIHNlcnZl
ciBncm91cCBzZWxlY3Rpb24gaXM8YnI+DQppbiBLZXlTaGFyZSBleHRlbnNpb24gaW4gU2VydmVy
SGVsbG8gbWVzc2FnZS48YnI+DQo8YnI+DQo8YnI+DQotSWxhcmk8YnI+DQo8YnI+DQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRMUyBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2301389BLREML503MBXchi_--

--_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2301389BLREML503MBXchi_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=6737;
	creation-date="Tue, 25 Jul 2017 05:26:26 GMT";
	modification-date="Tue, 25 Jul 2017 05:26:26 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA
AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA
AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA
AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB
AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A
AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA////////
/////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD/////////
////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA
AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A
AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA
AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg
AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS
AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF
U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA
AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA
TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA
AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA
AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB
bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA
AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl
QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u
ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN
BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA
AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM
QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT
ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O
Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB
IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB
AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR
obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF
tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR
AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV
NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA
AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6
6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs
VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns
U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9
w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh
fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX
146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh
SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t
bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo
JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb
qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv
/QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F
ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4
HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v
6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m
+u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6
tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ
JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r
WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z
OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB
AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA
AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq
AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8
CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox
ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA
BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB
AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf
Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM
DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM
DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED
EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA
AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV
UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0
pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB
UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz
hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/
APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3
0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl
/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP
UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+
qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW
9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq
FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp
VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku
cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf
Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0
PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C
OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us
XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j
QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6
jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n
0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT
gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf
UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj
Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI
BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04
MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA
AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh
CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp
anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV
1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK
C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy
0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm
5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge
ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn
yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr
aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g
dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf
03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l
6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo
9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai
uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45
RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV
zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc
TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM
v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S
reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8
V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM
qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/
thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le
LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x
ke3tRX0lRQB//9k=

--_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2301389BLREML503MBXchi_--


From nobody Mon Jul 24 23:29:52 2017
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 6800C126DC2 for ; Mon, 24 Jul 2017 23:29:51 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iij.ad.jp
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv6_Wpk8Ym8N for ; Mon, 24 Jul 2017 23:29:49 -0700 (PDT)
Received: from omgo.iij.ad.jp (mo901.iij.ad.jp [202.232.31.77]) (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 B16111200F3 for ; Mon, 24 Jul 2017 23:29:49 -0700 (PDT)
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Cc:Subject:From:In-Reply-To:References:Mime-Version: Content-Type:Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1500964188; x=1502173788; bh=IhT9XHiH9vzl5NKpcS2XZ+lh4pF/VeaycpEgD0WMrAM=; b=Me5cNjnPCkJ1UH JO+A26liGemmwB7Cilg3fA1LiHhj0ygiO4Den9ad0lGM4gPaVo6th5S+lsVa5kUGjgP/Ij8wl64KO 4CzsStCEvCLnTOK2ckWUbFqYiUw9Yk4i8j1q4TaJOXCnC6W8V6O0OMule9qeXsoQ59IubwC9pbNLz d06ZcgdImAfM1q8UMnDCkgqnxaxGHSBsbiwqVO9t3kvQxvSAoc+uxxsqOWCpAICwCnOxPEHuPQ9Z1 jKyogEh4AvxWXYYF13f87Kao7g2yA6TSeuCYV29o4ukQS7IAQ0MCnk8s9o6zkzd8syTse8zjGHeim gzUH6WzytjmNlr7RWB7Q==;
Received: by omgo.iij.ad.jp (mo901) id v6P6Tmma015987; Tue, 25 Jul 2017 15:29:48 +0900
X-Iguazu-Qid: 33Puh5E1VTAT0baabA
Date: Tue, 25 Jul 2017 15:29:47 +0900 (JST)
Message-Id: <20170725.152947.1933219367499132607.kazu@iij.ad.jp>
To: s@pahtak.org
Cc: tls@ietf.org
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] TLS 1.3 presentation language
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 06:29:51 -0000

Hi Stephen,

Thank you for your nice work.

> Concretely, I think we should make the following changes.
> 1. Replace `length` with `TLSCiphertext.length` in the definition of `TLSCiphertext`.

I agree.

> 2. Replace `Hash.length` with `hash_length` throughout (9 instances).

I agree.

> 3. Change the definition of `select`'s `case` statements to have 0 or more fields (types and names) and remove the optional label.
> 4. Change the `select` example to match the new definition.

I agree if this means 1 or more. (See below)

> 5. Change `Handshake` by adding field names to each `case` statement. (These could all be `body` or they could be unique.)

Would you show me a concrete definition?

> Remove the `body` label.

I agree.

> 6. Delete the `Empty` structure and replace both current uses with the comment `/* Empty */`.

Empty has a long story.

I proposed None (namely Empty) first but it was not accepted:

	https://github.com/tlswg/tls13-spec/issues/630

But when we discussed EarlyDataIndication, this idea came back:

	https://github.com/tlswg/tls13-spec/issues/861

So, people would want to avoid removing Empty again.

--Kazu


From nobody Tue Jul 25 05:20:23 2017
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 E0F7B131C89 for ; Tue, 25 Jul 2017 05:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVidMD1s5zJe for ; Tue, 25 Jul 2017 05:20:18 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00BB131C37 for ; Tue, 25 Jul 2017 05:20:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4C415BE2C; Tue, 25 Jul 2017 13:20:15 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWF5PIr4IhpF; Tue, 25 Jul 2017 13:20:15 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 15963BDF9; Tue, 25 Jul 2017 13:20:15 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500985215; bh=O43tG69/3RJ+oohx7sp8ypH6T+9FA6YBEQYuqCWbuo4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EQsjS7lVvhsSaT3/PzIfFArbRRep0l5Z5RVvAxcLfZQi8eUwXrDrOTrx/UiAXJUj7 T8wqiohNugG3rQIudIduXl+xZhocIPQrkvwS8tJ+BB885E9jtLd7gIS/e+1IQfKu9T F1PRzR/yfd47uyAjTIDJpR/G7xXZcc72zMSaDi7c=
To: Peter Gutmann , =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= 
Cc: "tls@ietf.org" 
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>  <1500954833319.1033@cs.auckland.ac.nz>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Tue, 25 Jul 2017 13:20:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <1500954833319.1033@cs.auckland.ac.nz>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iXTGXpNuaHdA5kuTJ0QIFWv1nQTA3rSQQ"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 12:20:21 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--iXTGXpNuaHdA5kuTJ0QIFWv1nQTA3rSQQ
Content-Type: multipart/mixed; boundary="McvVNS01TCpAFBhhXbLHgNOC3TiWdh2Cj";
 protected-headers="v1"
From: Stephen Farrell 
To: Peter Gutmann ,
 =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= 
Cc: "tls@ietf.org" 
Message-ID: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
 
 <1500954833319.1033@cs.auckland.ac.nz>
In-Reply-To: <1500954833319.1033@cs.auckland.ac.nz>

--McvVNS01TCpAFBhhXbLHgNOC3TiWdh2Cj
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 25/07/17 04:53, Peter Gutmann wrote:
> Colm MacC=C3=A1rthaigh  writes:
>=20
>> I think the fix for this is really at the application level; if you=20
>> want defense-in-depth against PRNG problems, it's probably best to use=
=20
>> separate RNG instances for public data (e.g. client_random,=20
>> server_random, explicit_IV) and for secret data (keys) so that a leak =

>> in the public data doesn't compromise the private one. We do this in=20
>> s2n, and I think BouncyCastle does it too.=20
>=20
> I do that too.  It's also specified in the LTS draft, it's just common =

> sense really.

I guess you mean this:

"
   TLS-LTS drops the requirement to generate the Client.random and
   Server.random using "a secure random number generator", typically the
   one used to generate encryption keys.  The use of a secure/
   cryptographic random number generator serves no obvious purpose (all
   that's required is a unique value), but exposes 224 bits of the
   cryptographic RNG output to an attacker, allowing them to analyse and
   potentially attack the RNG, and by extension any crypto keys that it
   generates:

   o  Implementations SHOULD NOT use the raw output from a
      cryptographic/secure RNG that's used to generate keying material
      to generate the Client.random and Server.random values.  Instead,
      they SHOULD employ a mechanism that doesn't directly expose
      cryptographic RNG output to attackers, for example by using the
      crypto RNG to seed a hash-based PRF such as the TLS PRF and using
      the output of that for the values.
"

I think something along these lines would be good advice to add
to appendix C.1 or to 4.1.2 where Random is defined.

That said, I'd still argue for an approach that a peer could
see was in use when "public" random byes aren't really needed but
fair enough if that doesn't resonate with people.

Cheers,
S.


>=20
> Peter.
>=20


--McvVNS01TCpAFBhhXbLHgNOC3TiWdh2Cj--

--iXTGXpNuaHdA5kuTJ0QIFWv1nQTA3rSQQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZdzd+AAoJEC88hzaAX42iOFMIALQTN+SXuzf7CElsbYSVufF7
M1pdg6LZ9e1Rkm4sH4wYJU0H6+hg21k1oJRGJjNx8oQr+MjmFPbEMfLo1lqiu1sn
5y7emT37EH/wuaQzAaX1VzZSDSsdho7imu6cKTSlcDSuzetHbC9yEW5XcnHAJ0m3
N62BNUOnhrgXjQydVlBz7ft58kpwMqb7otKudDqW6vIx7O0xAKNNzalsMSWluXOn
EcQJuvzkRA6lI87Xk8PEFURTjlLXWflGXka789IjxR8adOHl42yhU4BVUZ7/dcGE
vXW9fIsclz+LcNz91ocY+8G1fgB12VTErpZk/u0rkvGaGybIvUqFcHLu+iGnYk8=
=m1Jl
-----END PGP SIGNATURE-----

--iXTGXpNuaHdA5kuTJ0QIFWv1nQTA3rSQQ--


From nobody Tue Jul 25 10:52:50 2017
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 3D723129ADD for ; Tue, 25 Jul 2017 10:52:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 yf-Q-juS6KYJ for ; Tue, 25 Jul 2017 10:52:45 -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 7CB07126C0F for ; Tue, 25 Jul 2017 10:52:45 -0700 (PDT)
Received: by mail-vk0-x235.google.com with SMTP id p193so11376957vkd.0 for ; Tue, 25 Jul 2017 10:52:45 -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=LPH3naMGYEPKLBJTXypttzYreXu/kJzzYzbHVPQJFJk=; b=AsK2CAel3rl7c/6/68P1mkU7ecUujRGWDelCaPMdd8WkJbHVGQUuqZiVjCxGaw0Lxk ZFri/ZB8zSw25uOE5TNaRfeQPbw5NQnzPeyl/4HsdEKv0nZ13wW0bs95aBaB660TDlsp LFae7Rtbs8yIjkRQM+DOHUGKOGsJZ8eKS5V78=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LPH3naMGYEPKLBJTXypttzYreXu/kJzzYzbHVPQJFJk=; b=fkWDxn22J7BtPTS/ViiBXBM+bnV/hB0vc5YHF46mm7bk3KOsBopNySkMoKVoGt4hOl YK9oIGUxKdkPHuILCFEH8y1Kx6Bsl6GTSINGqacf46OarofEjiGGE9EYvRCySOanpttH Mxp57A30yWmPPwbeUu2Z/GfIB7hOsu+TWhDzBCscKXiA7gL/D7fN/fct7ngDS3UjYuyH DNEsR51uZIrl8gERMiRbE97iwAwqvzpzyd6e/oyNx+0XFdP08eFmRYXwtU3AKsNL7EY4 wPtJRpf/o+7gap3nFOdMS+UgAxc75yX6JUx4fkPogoLLdQ9qgzn4qmuKc26XwxsV5Qr2 5KZQ==
X-Gm-Message-State: AIVw1104gfZP1oqoA6/nHysE3KNEpPXEPrd8E/SSUvfjNo6pxC5z25QG Q2opRSPybNK/+npSUyJalD/NEWtPHNvogpmp0w==
X-Received: by 10.31.218.133 with SMTP id r127mr10175627vkg.104.1501005164401;  Tue, 25 Jul 2017 10:52:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.72.137 with HTTP; Tue, 25 Jul 2017 10:52:23 -0700 (PDT)
In-Reply-To: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
From: Joseph Lorenzo Hall 
Date: Tue, 25 Jul 2017 13:52:23 -0400
Message-ID: 
To: Stephen Farrell 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 17:52:48 -0000

On Mon, Jul 24, 2017 at 11:15 AM, Stephen Farrell
 wrote:
>
>
> Hiya,
>
> I'm guessing many folks interested in TLS may have been
> at the QUIC session in Prague and hence missed out on the
> excellent talk by Stephen Checkoway on the juniper dual-ec
> incident. (I highly recommend taking a peek at the slides [1]
> or reading the paper [2] or watching the video wherever
> that may be;-).

Video of Steve's talk in the IRTF Open session is here and Steve
begins around 52:15:

https://www.youtube.com/watch?v=JRneMj7LX8U&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h&t=52m15s


-- 
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 Jul 25 12:03:07 2017
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 B212012EC11 for ; Tue, 25 Jul 2017 12:03:05 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 SSl41HvL8jPo for ; Tue, 25 Jul 2017 12:03:03 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 CB46512EB2B for ; Tue, 25 Jul 2017 12:03:03 -0700 (PDT)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1da56k-000422-6g for tls@ietf.org; Tue, 25 Jul 2017 21:03:03 +0200
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1da56i-00084z-Fj for tls@ietf.org; Tue, 25 Jul 2017 15:03:01 -0400
Received: (qmail 24448 invoked from network); 25 Jul 2017 19:02:59 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jul 2017 19:02:59 -0000
To: tls@ietf.org
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>  <1500954833319.1033@cs.auckland.ac.nz> 
From: Christian Huitema 
Message-ID: <2467f973-392a-f579-8b2f-e7cc5332fc49@huitema.net>
Date: Tue, 25 Jul 2017 12:02:47 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3ul7qOvAwp3OepG3mEPn8KxqKdek9JR6Q"
X-Originating-IP: 168.144.250.223
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.27)
X-Recommended-Action: accept
X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23316N1xbbVOkJnstOLWWvkdLq/ve7b16x7vAJ KZkNps2TXlyBcAGYqxUTVAIuDRMbYOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRP6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyZC6vDVenkTTs5qFqG9cbVzeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17EG/t1oSd/AwwJSBmWk5/HC2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe93qlFit1PvkPF7Ua1AOSWcb0i13zjCiwPgdt77s k1WBMw==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 19:03:06 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--3ul7qOvAwp3OepG3mEPn8KxqKdek9JR6Q
Content-Type: multipart/mixed; boundary="t0bpgW3qFTtxHxUf9WSWi6rALwBFmBc0j";
 protected-headers="v1"
From: Christian Huitema 
To: tls@ietf.org
Message-ID: <2467f973-392a-f579-8b2f-e7cc5332fc49@huitema.net>
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
 
 <1500954833319.1033@cs.auckland.ac.nz>
 
In-Reply-To: 

--t0bpgW3qFTtxHxUf9WSWi6rALwBFmBc0j
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 7/25/2017 5:20 AM, Stephen Farrell wrote:
> I guess you mean this:
>
> "
>    TLS-LTS drops the requirement to generate the Client.random and
>    Server.random using "a secure random number generator", typically th=
e
>    one used to generate encryption keys.  The use of a secure/
>    cryptographic random number generator serves no obvious purpose (all=

>    that's required is a unique value), but exposes 224 bits of the
>    cryptographic RNG output to an attacker, allowing them to analyse an=
d
>    potentially attack the RNG, and by extension any crypto keys that it=

>    generates:
>
>    o  Implementations SHOULD NOT use the raw output from a
>       cryptographic/secure RNG that's used to generate keying material
>       to generate the Client.random and Server.random values.  Instead,=

>       they SHOULD employ a mechanism that doesn't directly expose
>       cryptographic RNG output to attackers, for example by using the
>       crypto RNG to seed a hash-based PRF such as the TLS PRF and using=

>       the output of that for the values.
> "
>
> I think something along these lines would be good advice to add
> to appendix C.1 or to 4.1.2 where Random is defined.

I am not sure that this recommendation is practical. For one thing, it
conflicts with the general advice that developers should not invent
their own PRNG, and should use a good crypto RNG when available. Also,
when we make such a recommendation in the TLS spec, we can hope that it
will be heeded by the TLS developers, but what about the developers of
applications and protocols sitting on top of TLS, such DTLS, QUIC or HTTP=
?

We want defense in depth, but in TLS 1.3 we mostly want to defend the
private [EC]DH keys. So maybe the recommendation should apply there.
Developers could for example mix the output of the crypto RNG with a
locally held secret before generating the private keys.

--=20
Christian Huitema



--t0bpgW3qFTtxHxUf9WSWi6rALwBFmBc0j--

--3ul7qOvAwp3OepG3mEPn8KxqKdek9JR6Q
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

iQEcBAEBCAAGBQJZd5XgAAoJELba05IUOHVQN2MH/1Yo6dBTXFoVQUzR5wYOxk3c
xvtEZ6qoZa7LaEqYKr5TA+egAD8bpZxeTt0HNKNJapAil5UAFDC9cMC8EQDMWhaW
SMXnT8fk8ho943yIfvVd9LR/o9EyUE9Y+RyaF5jOQL8pxan3pAUOK6LG/UOrfbHb
ES5eK5TLjqsWp5J4Bza68CtcS9h+msERX1TvoR7Y7NqOaehf6Fr5miuwA9oWGR26
1IBA2HmigusepSqjTWiuUW3eQz6cU0qZgNyBKkH3DHQMR67NefnUt26lXBRcBHsH
6eZOozMqXaYTn6kx7Ua+SkAC03CkgsFd33PNTsXhdDkEBU/eoNtjT8saZnn+DDQ=
=E/6b
-----END PGP SIGNATURE-----

--3ul7qOvAwp3OepG3mEPn8KxqKdek9JR6Q--


From nobody Tue Jul 25 13:29:02 2017
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 9FF7C1317AD for ; Tue, 25 Jul 2017 13:29:01 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pahtak-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 EGdZA9dXDyh9 for ; Tue, 25 Jul 2017 13:28:59 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0647312420B for ; Tue, 25 Jul 2017 13:28:58 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id l7so60652422iof.1 for ; Tue, 25 Jul 2017 13:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pahtak-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=phpzcKBdekA7pzaAlyVSy10UXLQU/zstK08sbibDH34=; b=PutkGtyk66h8kRkPq+gFpI0rxKnOZaF5TuTt35vhjuvMfXrI8c9atWvinpoISDXlxS l9wzxBEKC5NxYKOf0WQGNm2zDyVtCOiEEUgVQwVk5MP54c8Iq1kuoM3vHPRvKogLBcqw 6y+BxutoeeRSU9id+IreX1lh+1S1fuMBI5lEgeNOCzOKF/Vt0kyeiBblYaBE5jQbRQfP T5Y5650UZhlZlUuZgYJi2qVYSsifcTWLli8DPNlOgmG5E7JdFMqVDB0wAN0E80Xov2dS owvWZ4CSB3IVWepkeA4mwV9CLe0P7U5lpvTT3kt9ClzqqamkygK0X3jM69x0z3Z1nhMN Cqnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=phpzcKBdekA7pzaAlyVSy10UXLQU/zstK08sbibDH34=; b=SnP2v54yBofzjW+kWXjzatoECcZyoY/NUG7G4h9OlNXHSMrytUoeDoe/iBrCTUxAVe PhLexRJQM3qv6poN4CaSOQFuRps+HFUPq0zI2Sy3lq4Sb7itGauBtzBnmP0kXxE9ItIa 16/RfW3/xpz7y8bsuho8juolRgtS1rY5sgIcgHJw8T00qqdf4JOvxthmZG+NIZMFbPiK 6lJvEXEq9nPz/C47dr+DfobS6tH67mgsn7UKkI0ZTslvA0oqav5iI03nUBt739/32+yt MR8TyTm250qyZpFg8NbGuKgBr+hqmudoe5TMvA67dGomQvNCVBSiRnqMM70jp3lxkWtA BEsQ==
X-Gm-Message-State: AIVw113WkAlWVakjkzx2K/H8chop/cIZTpeTFf+4/+nbM6uhadQoUaNy gQTdVpdw6/l3RidXo8vDcQ==
X-Received: by 10.107.185.138 with SMTP id j132mr8859826iof.204.1501014538042;  Tue, 25 Jul 2017 13:28:58 -0700 (PDT)
Received: from zbox.pahtak.org ([2601:241:8b00:fe1f:201:2eff:febc:8976]) by smtp.gmail.com with ESMTPSA id e84sm7094893iof.86.2017.07.25.13.28.57 for  (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 25 Jul 2017 13:28:57 -0700 (PDT)
Received: from mba.hsd1.il.comcast.net (router [192.168.1.1]) by zbox.pahtak.org (Postfix) with ESMTPSA id 95B1FAC2F02 for ; Tue, 25 Jul 2017 15:28:56 -0500 (CDT)
From: Stephen Checkoway 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 25 Jul 2017 15:28:56 -0500
References:  <20170725.152947.1933219367499132607.kazu@iij.ad.jp>
To: "tls@ietf.org (tls@ietf.org)" 
In-Reply-To: <20170725.152947.1933219367499132607.kazu@iij.ad.jp>
Message-Id: <73E4CF3F-6D27-4482-9CBB-AB8AA4E92216@pahtak.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] TLS 1.3 presentation language
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 20:29:02 -0000

On Jul 25, 2017, at 01:29, Kazu Yamamoto (=E5=B1=B1=E6=9C=AC=E5=92=8C=E5=BD=
=A6)  wrote:

>> 3. Change the definition of `select`'s `case` statements to have 0 or =
more fields (types and names) and remove the optional label.
>> 4. Change the `select` example to match the new definition.
>=20
> I agree if this means 1 or more. (See below)

I went with 0 precisely to avoid Empty, but 1 or more seems fine too.

>> 5. Change `Handshake` by adding field names to each `case` statement. =
(These could all be `body` or they could be unique.)
>=20
> Would you show me a concrete definition?

I give three straw men proposals below, proposal I shows this.

>> 6. Delete the `Empty` structure and replace both current uses with =
the comment `/* Empty */`.
>=20
> Empty has a long story.
> [...]
> So, people would want to avoid removing Empty again.

Okay, I wasn't aware of this discussion. There's no real issue here =
except that the two `Empty` structures would need to be given field =
names. See the proposal I below.

Here are three proposals and the impact on the structures containing =
`select`.

Proposal I. Case statements contain 1 or more fields.

      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello         ch;
              case server_hello:          ServerHello         sh;
              case end_of_early_data:     EndOfEarlyData      eed;
              case hello_retry_request:   HelloRetryRequest   hrr;
              case encrypted_extensions:  EncryptedExtensions ee;
              case certificate_request:   CertificateRequest  cr;
              case certificate:           Certificate         c;
              case certificate_verify:    CertificateVerify   cv;
              case finished:              Finished            f;
              case new_session_ticket:    NewSessionTicket    nst;
              case key_update:            KeyUpdate           ku;
          };
      } Handshake;

   struct {
       select (Handshake.msg_type) {
           case client_hello:
               KeyShareEntry client_shares<0..2^16-1>;

           case hello_retry_request:
               NamedGroup selected_group;

           case server_hello:
               KeyShareEntry server_share;
       };
   } KeyShare;


   struct {} Empty;

   struct {
       select (Handshake.msg_type) {
           case new_session_ticket:   uint32 max_early_data_size;
           case client_hello:         Empty  empty;
           case encrypted_extensions: Empty  empty;
       };
   } EarlyDataIndication;

   struct {
       select (Handshake.msg_type) {
           case client_hello:
               PskIdentity identities<7..2^16-1>;
               PskBinderEntry binders<33..2^16-1>;

           case server_hello:
               uint16 selected_identity;
       };
   } PreSharedKeyExtension;

      struct {
          select (certificate_type){
              case RawPublicKey:
                // =46rom RFC 7250 ASN.1_subjectPublicKeyInfo
                opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

              case X509:
                opaque cert_data<1..2^24-1>;
          };
          Extension extensions<0..2^16-1>;
      } CertificateEntry;

In `Handshake`, the field names themselves are unimportant since they're =
never referenced. Similarly, the `empty` names aren't important. I find =
this mildly unpleasant. This involves the fewest changes to the actual =
structure definitions.

Proposal II. Case statements contain a type. Here, fields are replaced =
by anonymous structs.

      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case end_of_early_data:     EndOfEarlyData;
              case hello_retry_request:   HelloRetryRequest;
              case encrypted_extensions:  EncryptedExtensions;
              case certificate_request:   CertificateRequest;
              case certificate:           Certificate;
              case certificate_verify:    CertificateVerify;
              case finished:              Finished;
              case new_session_ticket:    NewSessionTicket;
              case key_update:            KeyUpdate;
          };
      } Handshake;

   struct {
       select (Handshake.msg_type) {
           case client_hello: struct {
               KeyShareEntry client_shares<0..2^16-1>;
           };
           case hello_retry_request: struct {
               NamedGroup selected_group;
           };
           case server_hello: struct {
               KeyShareEntry server_share;
           };
       };
   } KeyShare;


   struct {} Empty;

   struct {
       select (Handshake.msg_type) {
           case new_session_ticket:   struct { uint32 =
max_early_data_size; };
           case client_hello:         Empty;
           case encrypted_extensions: Empty;
       };
   } EarlyDataIndication;

   struct {
       select (Handshake.msg_type) {
           case client_hello: struct {
               PskIdentity identities<7..2^16-1>;
               PskBinderEntry binders<33..2^16-1>;
           };
           case server_hello: struct {
               uint16 selected_identity;
           };
       };
   } PreSharedKeyExtension;

      struct {
          select (certificate_type){
              case RawPublicKey: struct {
                // =46rom RFC 7250 ASN.1_subjectPublicKeyInfo
                opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
              };
              case X509: struct {
                opaque cert_data<1..2^24-1>;
              };
          };
          Extension extensions<0..2^16-1>;
      } CertificateEntry;

This involves no changes to the presentation language but inserts a =
bunch of otherwise useless `structs`s and braces. Those that have just a =
single field could be replaced by the field's type, but this is almost =
certainly more confusing and loses the field's name.

Proposal III. Case statements contain a structure type's name.

      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case end_of_early_data:     EndOfEarlyData;
              case hello_retry_request:   HelloRetryRequest;
              case encrypted_extensions:  EncryptedExtensions;
              case certificate_request:   CertificateRequest;
              case certificate:           Certificate;
              case certificate_verify:    CertificateVerify;
              case finished:              Finished;
              case new_session_ticket:    NewSessionTicket;
              case key_update:            KeyUpdate;
          };
      } Handshake;

   struct {
       KeyShareEntry client_shares<0..2^16-1>;
   } ClientKeyShares;

   struct {
       NamedGroup selected_group;
   } HelloRetryRequestGroup;

   struct {
       KeyShareEntry server_share;
   } ServerKeyShare;

   struct {
       select (Handshake.msg_type) {
           case client_hello:        ClientKeyShares;
           case hello_retry_request: HelloRetryRequestGroup;
           case server_hello:        ServerKeyShare;
       };
   } KeyShare;


   struct {} Empty;

   struct {
       uint32 max_early_data_size;
   } MaxEarlyDataSize;

   struct {
       select (Handshake.msg_type) {
           case new_session_ticket:   MaxEarlyDataSize;
           case client_hello:         Empty;
           case encrypted_extensions: Empty;
       };
   } EarlyDataIndication;

   struct {
       PskIdentity identities<7..2^16-1>;
       PskBinderEntry binders<33..2^16-1>;
   } OfferedIdentities;

   struct {
       uint16 selected_identity;
   } SelectedIdentity;

   struct {
       select (Handshake.msg_type) {
           case client_hello: OfferedIdentities;
           case server_hello: SelectedIdentity;
       };
   } PreSharedKeyExtension;

      struct {
          // =46rom RFC 7250 ASN.1_subjectPublicKeyInfo
          opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
      } SubjectPublicKeyInfo;

      struct {
          opaque cert_data<1..2^24-1>;
      } CertData;

      struct {
          select (certificate_type){
              case RawPublicKey: SubjectPublicKeyInfo;
              case X509:         CertData;
          };
          Extension extensions<0..2^16-1>;
      } CertificateEntry;

This creates a bunch of auxiliary, named structures to hold the =
field(s). The `ServerKeyShare` struct could be replaced with =
`KeyShareEntry`, but this loses the field name.


Having written these all out, I like proposal II the least. Proposals I =
and III have the advantage that anonymous structures can be removed from =
the presentation language whereas proposal II introduces the only use of =
them.

Initially, I thought proposal I would be the best, but now I have a mild =
preference for proposal III. I think it makes the language simpler over =
all. It essentially becomes two primitive types (`opaque` and `uint8`) =
and four type definitions:

1. Fixed-length vectors: `T1 T[v];` (numbers are a special case where =
`T1` is `uint8`);
2. Variable-length vectors: `T1 T;`;
3. Enumerated types: `enum { e1(r1), ..., en(rn) [[, (vm)]] } T;`; and
4. Structures:
       struct {
           F1;
           F2;
           ...
           Fm;
           [[
           select (Ts.fs) {
               case e1: S1;
               case e2: S2;
               ...
               case en: Sn;
           };
           ]]
       } T;
   Each field Fi is one of
   - `Ti fi`         (normal fields);
   - `Ti fi =3D v`     (constants where `Ti` is a number type);
   - `Ti fi[v]`      (fixed-length vectors); or
   - `Ti fi` (variable-length vectors).

where the symbols have the following meanings:
- S: structure type identifier
- T: type identifier
- e: enum element
- f: field identifier
- r: enum value, either a number or a range `v1..v2`
- v: number

Note that currently, the presentation language doesn't describe fixed- =
nor variable-length vectors as _structure fields_, it only describes =
them in the context of defining new types.

Neither the current presentation language nor my proposed one above =
gives meaning to `uint16 ProtocolVersion;`. Absent a compelling reason =
for type aliases, I think this should be written as `uint8 =
ProtocolVersion[2];`

--=20
Stephen Checkoway






From nobody Tue Jul 25 16:49:10 2017
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 1A2FA1320E6 for ; Tue, 25 Jul 2017 16:49: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, 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=vimino.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 MfoQxMWAAGYd for ; Tue, 25 Jul 2017 16:49:07 -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 136F11320CD for ; Tue, 25 Jul 2017 16:49:06 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id k2so39493115qkf.0 for ; Tue, 25 Jul 2017 16:49:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino.com; s=google;  h=mime-version:from:date:message-id:subject:to; bh=llxucNQN6G0RFzH6NpMSSQB8wWYZUyiK4e9+yaplqiI=; b=prUEp0bq+n2ciy4iwfJytSEfxRd9UjG7K2RlfCagzBZdF8IQR7DNHqtQp43ogY+bJR R8JdCOdvoLoY5dYo7fWHSe7Xzf1KeRMs59ETbVY/3yTUeyrnFV5OzL/AGlnkLdZVD+UX V/M0m1OZjgPdO+Nj/xtCFgZdpuQSsISN6GH/s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=llxucNQN6G0RFzH6NpMSSQB8wWYZUyiK4e9+yaplqiI=; b=b120waYuZLv7zE53fQZCS+KG05Xjw8jih9SY9hzNdgTS6sqTTcFh2JNA1WYD5k8xUy uJbOTr2O9t/uaTPMrjG0JU494CMQy2xqRBlHL2FIxdDMMQNbLGXMyuhZsRJlJNeI/hH5 uyTMtihb5yWrL/i7VHQ5srrixih78h3HaZCP3s8xRQ0dPYL99rDc1L25W/EDJ2ua4dVP N1aO42o4AKiiFVRWMzHd1wJIxjbG5fi72HaCm1Qsh8vu9zXmTuNyZhfgueyHlEnzeUo2 R0FcgIfZNOAwyY14C54UVAHkCI/49Y4FrcGQgrATbe/401FzA4N7UG4s4cdF7L4iVN5l LaPQ==
X-Gm-Message-State: AIVw111vAsco2Rh2/CfZXzun0J9JL4vWYHcCJjhpyNR8mmfKY4hCVlfA O5x15uT7wpv99igzTXQ0zkLtertqIVJ7
X-Received: by 10.55.212.137 with SMTP id s9mr8614530qks.120.1501026545909; Tue, 25 Jul 2017 16:49:05 -0700 (PDT)
MIME-Version: 1.0
From: Xuelei Fan 
Date: Tue, 25 Jul 2017 23:48:55 +0000
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11498e2011558805552cfab3"
Archived-At: 
Subject: [TLS] certificate_request_context in TLS 1.3 Certificate handshake message
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 23:49:09 -0000

--001a11498e2011558805552cfab3
Content-Type: text/plain; charset="UTF-8"

Hi,

The TLS 1.3 Certificate handshake message is defined as:

   struct {
       opaque certificate_request_context<0..2^8-1>;
       CertificateEntry certificate_list<0..2^24-1>;
   } Certificate;

   certificate_request_context  If this message is in response to a
      CertificateRequest, the value of certificate_request_context in
      that message.  Otherwise (in the case of server authentication),
      this field SHALL be zero length.


As the certificate_request_context and client delivered Certificate
handshake message are only in response to a CertificateRequest, the one
byte zero length of certificate_request_context field is redundant for
server delivered certificate handshake message. It may be more clear to use
the certificate_request_context field for client delivered Certificate
handshake message only, for example:

   struct {
       select (connection_end) {
            case client:
               opaque certificate_request_context<0..2^8-1>;
            case server:
               struct {};
       }
       CertificateEntry certificate_list<0..2^24-1>;
   } Certificate;

Regards,
Xuelei Fan

--001a11498e2011558805552cfab3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    Hi,

    The TLS 1.3=C2=A0Certificate handsh=
ake message is defined as:
       struct {
       opaque certificate_request_context<0..2^8-1>;
       CertificateEntry certificate_list<0..2^24-1>;
   } Certificate;

   certificate_request_context  If this message is in response to a
      CertificateRequest, the value of certificate_request_context in
      that message.  Otherwise (in the case of server authentication),
      this field SHALL be zero length.

    As th=
e=C2=A0certificate_request_context and client delivered=C2=A0Certificate ha=
ndshake message are only in response to a CertificateRequest, the one byte =
zero length of certificate_request_context field is redundant for server de=
livered certificate handshake message. It may be more clear to use the=C2=
=A0certificate_request_context field for client delivered=C2=A0Certificate =
handshake message only, for example:

    =C2=A0 =
=C2=A0struct {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0select (connection_end)=
 {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case client:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque certificat=
e_request_context<0..2^8-1>;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 case server:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0struct {};
    =C2=A0 =C2=A0 =C2=A0 =C2=A0}
    =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateEntry certificate_list<0..2^24-1=
>;
    =C2=A0 =C2=A0} Certificate;

    =
Regards,
    Xuelei Fan

    

--001a11498e2011558805552cfab3--


From nobody Tue Jul 25 16:57:30 2017
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 1A590132101 for ; Tue, 25 Jul 2017 16:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 Aql36gu5bFAN for ; Tue, 25 Jul 2017 16:57:25 -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 640B51320FE for ; Tue, 25 Jul 2017 16:57:25 -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=1501027045; x=1532563045; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xzQ5FhFHNqgFv58ETe/QzGIzdFHHmkTbldcYJLVbOhE=; b=YKdfNrPbqmmDZOwfKeBE99uqMCiOUglisUWnRfcr3/YAW6xVz0uT8lUO DL/5ZF9MSdMRagpzP0D/XH/cdgBms4arXJfGNBz3sEhoVZKyZsWEbl//7 0e5kt9jqY1Veul+lgm+9C+pqALOUTJihYSYf96Psz656OYZaihGJuQ/pL Hl8us3M9DucyrfPlclHbetIGOPQdrrOhYGQXyJFzyQcXfBX2Iv31+EEGt USsRCGEtt5nE3iTNN8VhUjQRT7Pcs/5rKd4tJ2nAVcCgw5yBxSUO2PHu1 edmR6zNb3BzR7NGG1mBhLPXU3NMIHi8FS4FC7A9YuViAp4FwVW4yBliAC g==;
X-IronPort-AV: E=Sophos;i="5.40,413,1496059200"; d="scan'208";a="168244427"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 26 Jul 2017 11:57:22 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Jul 2017 11:57:16 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 26 Jul 2017 11:57:16 +1200
From: Peter Gutmann 
To: Christian Huitema , "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+2hSpUAt7/bkebxZ5uN/u91aJibPQAgAF9Cgj//8R0AIAAcHmAgAEbOYA=
Date: Tue, 25 Jul 2017 23:57:16 +0000
Message-ID: <1501027031926.45701@cs.auckland.ac.nz>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>  <1500954833319.1033@cs.auckland.ac.nz> , <2467f973-392a-f579-8b2f-e7cc5332fc49@huitema.net>
In-Reply-To: <2467f973-392a-f579-8b2f-e7cc5332fc49@huitema.net>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 23:57:28 -0000

Christian Huitema  writes:=0A=
=0A=
>For one thing, it conflicts with the general advice that developers should=
=0A=
>not invent their own PRNG, =0A=
=0A=
You're not inventing your own PRNG, you're using the TLS PRF, or some=0A=
equivalent (I use PBKDF2, HKDF is also nice).=0A=
=0A=
>and should use a good crypto RNG when available.=0A=
=0A=
You're generating public nonces, you could use SHA-1 in a loop or a CRC32 o=
r=0A=
whatever, the values are public.  All you're doing is isolating the output =
of=0A=
the nonce generator from your crypto-key generator.  In fact the very thing=
=0A=
you absolutely don't want to use here is your good crypto RNG.=0A=
=0A=
>Also, when we make such a recommendation in the TLS spec, we can hope that=
 it=0A=
>will be heeded by the TLS developers, but what about the developers of=0A=
>applications and protocols sitting on top of TLS, such DTLS, QUIC or HTTP?=
=0A=
=0A=
They don't need to know or care about this, it's being used to generate the=
=0A=
TLS nonce which is invisible to anything running over TLS.=0A=
=0A=
Are we talking about the same thing here?=0A=
=0A=
Peter.=0A=


From nobody Tue Jul 25 16:58:17 2017
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 451C5132107 for ; Tue, 25 Jul 2017 16:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=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 3qp4XCkbNmBo for ; Tue, 25 Jul 2017 16:58:13 -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 E4E18120724 for ; Tue, 25 Jul 2017 16:58:12 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id u207so16686684ywc.3 for ; Tue, 25 Jul 2017 16:58:12 -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=a5pDBwIZlfeeEtq4EeIbg/ixvEdHvJtIMoAAw9GdlO0=; b=tXu3WlhuYERdMYf9kmPiUlMry6/ZpkK1ONr1597I4K67v2W+acu53G9Sn3mh1wFeyN fsAwhCH/RLxBPrk2YVwZwEqbStv1QX7G1yKnPb1op47fl+MCvZjH48M8XhiwL7hX7/Um HkCzePRfmvW5kdJeVqqIFkKybBDrW7iZiP3Kp2Rnmte6AAfRa/veVp72WIz0FnAjVK+x GPJ7boiBobRPFulimCkTydJ1XAGT6IivLfrGPz4NVQsvZulZiHtk7rvYKL6Ox8totHxf SfjollH6fj7dOteN02zjcI67l4wb6dbcoJ/u865pU5vqhcQk5sELr8/FDH3/nYWq6kLC dr8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a5pDBwIZlfeeEtq4EeIbg/ixvEdHvJtIMoAAw9GdlO0=; b=jrpYb6YVq0SpLs90AfBbARSkeYWHiRx03GfV4KdBWHc5f6Px16FE0QmjbhQ3gDsekM mtPUJLLYHt6ceV2nEDi9uUko0HLFRQxqZ0XMLBTnETa+GwAk38urnrLo7MmUz7KZxB02 NE3H999tnpa6NddqHSmQUj41FOesxYQhh6TCrqdkelE5V3pXpL8angOwBEUB5uipW7OB ItEHD3hrKz/Kj7cbA1usgohDC10B2W2CR4PBIxjYBfWRiKfte+MWcrnxe6cSSjiQGmBf LrFLdr0l+QN8yuo/Iz/7RmeCSSqHKDxB+DWY0bVyRL6hWStb+iddRf+fpRfJShRgZI3E PtHg==
X-Gm-Message-State: AIVw1110+xIhnZRNyNMleprenp+ziyKZCD59wYOf9KjjAvZmTieZtU+C TT67e9c97MIfZgLFkkfiHbDXMI4pjj9gHfI=
X-Received: by 10.37.212.140 with SMTP id m134mr6579481ybf.256.1501027092178;  Tue, 25 Jul 2017 16:58:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.36.12 with HTTP; Tue, 25 Jul 2017 16:57:31 -0700 (PDT)
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Tue, 25 Jul 2017 16:57:31 -0700
Message-ID: 
To: Xuelei Fan 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c07d966a0dc5b05552d1aca"
Archived-At: 
Subject: Re: [TLS] certificate_request_context in TLS 1.3 Certificate handshake message
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 25 Jul 2017 23:58:15 -0000

--94eb2c07d966a0dc5b05552d1aca
Content-Type: text/plain; charset="UTF-8"

Given that this document has been through 2 WGLCs, and this is basically an
aesthetic change, I don't think it gets over the barrier.

-Ekr


On Tue, Jul 25, 2017 at 4:48 PM, Xuelei Fan  wrote:

> Hi,
>
> The TLS 1.3 Certificate handshake message is defined as:
>
>    struct {
>        opaque certificate_request_context<0..2^8-1>;
>        CertificateEntry certificate_list<0..2^24-1>;
>    } Certificate;
>
>    certificate_request_context  If this message is in response to a
>       CertificateRequest, the value of certificate_request_context in
>       that message.  Otherwise (in the case of server authentication),
>       this field SHALL be zero length.
>
>
> As the certificate_request_context and client delivered Certificate
> handshake message are only in response to a CertificateRequest, the one
> byte zero length of certificate_request_context field is redundant for
> server delivered certificate handshake message. It may be more clear to use
> the certificate_request_context field for client delivered Certificate
> handshake message only, for example:
>
>    struct {
>        select (connection_end) {
>             case client:
>                opaque certificate_request_context<0..2^8-1>;
>             case server:
>                struct {};
>        }
>        CertificateEntry certificate_list<0..2^24-1>;
>    } Certificate;
>
> Regards,
> Xuelei Fan
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c07d966a0dc5b05552d1aca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    Given that this document has been through 2 WGLCs, and thi=
s is basically an aesthetic change, I don't think it gets over the barr=
ier.

    -Ekr


    On Tue, Jul 25, 2017 at 4:48 PM, Xuel=
ei Fan <xuelei.fan@vimino.com> wrote:
    Hi,

    The TLS 1.3=C2=A0Ce=
rtificate handshake message is defined as:
       struct {
       opaque certificate_request_context<0..2^8-1>;
       CertificateEntry certificate_list<0..2^24-1>;
   } Certificate;

   certificate_request_context  If this message is in response to a
      CertificateRequest, the value of certificate_request_context in
      that message.  Otherwise (in the case of server authentication),
      this field SHALL be zero length.

    As th=
e=C2=A0certificate_request_context and client delivered=C2=A0Certifica=
te handshake message are only in response to a CertificateRequest, the one =
byte zero length of certificate_request_context field is redundant for serv=
er delivered certificate handshake message. It may be more clear to use the=
=C2=A0certificate_request_context field for client delivered=C2=A0Cert=
ificate handshake message only, for example:

    =
=C2=A0 =C2=A0struct {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0select (connecti=
on_end) {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case client:<=
/div>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque cer=
tificate_request_context<0..2^8-1>;
    =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 case server:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {};
    =C2=A0 =C2=A0 =C2=A0 =C2=
=A0}
    =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateEntry certificate_list=
<0..2^24-1>;
    =C2=A0 =C2=A0} Certificate;
    Regards,
    Xuelei Fan

    

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


    

--94eb2c07d966a0dc5b05552d1aca--


From nobody Tue Jul 25 18:07:38 2017
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 60AA71296C9 for ; Tue, 25 Jul 2017 18:07:36 -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=vimino.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 RKmC9-QBmk8J for ; Tue, 25 Jul 2017 18:07:34 -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 1232A124B0A for ; Tue, 25 Jul 2017 18:07:34 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id u139so16664239qka.1 for ; Tue, 25 Jul 2017 18:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2eFI8k1Y/W7HJskEMD6zH+Y0KfTlVYCguJtJqJ1roB0=; b=AawXj+rSRjYpODEAO2LTn8dRM1rmTD58oplIpALikPrUrwdjDpSVycli62lCuJ3rX/ YtTF79cEpfHj3oksPc5JhUf7Oyq9zdw/pqq978DN4Req4SX4eZp2Z5sPEkHWrjTwLblW u71ysmOO9fVRvIGwq/4Ht1T9xipE4QoXEsXyc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2eFI8k1Y/W7HJskEMD6zH+Y0KfTlVYCguJtJqJ1roB0=; b=fHfzd3xamAtKvgWPOCuusB1yVvNRtEUwzVYlzipdrAoRh4PYh+DMRKbj8+pu8Da1XF UguvZ44iBDi0F3dPDpHRo27LuoxNIRx0jywrP04PcVpyN1JGspC13U3nHNNTOG2WuWN5 8s61JFB/HGDf1M3vEwxLX+5U6NZzul6YWwiLbWq5Br+6wYFG3Z0NedXmRrGuThVsq3/z ddRqDJStmhAZfrHoDmMisz5e8Ddom7y8A0nIpuawkuAk/JkUGqlKR6/dkeF3Kl8DRiRr OBpC9ucsrj9H1NKqp0UnEyJUv4cddHt/sQbDYMysHb78twD28SbTP/kRZ/fVBbHdfl5G zBJA==
X-Gm-Message-State: AIVw111+WGd1GpZXWGv8CAOP4diQte7+Ly9O5KdH/K4R0NI6V2tbOwFI okatsWBjrs90AQA/f8VskmqDYMFLd0e3
X-Received: by 10.55.103.23 with SMTP id b23mr28988694qkc.55.1501031253172; Tue, 25 Jul 2017 18:07:33 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Xuelei Fan 
Date: Wed, 26 Jul 2017 01:07:22 +0000
Message-ID: 
To: Eric Rescorla 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c059c70a4907a05552e1203"
Archived-At: 
Subject: Re: [TLS] certificate_request_context in TLS 1.3 Certificate handshake message
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 01:07:36 -0000

--94eb2c059c70a4907a05552e1203
Content-Type: text/plain; charset="UTF-8"

Agreed it is basically an aesthetic change.

Thanks,
Xuelei

On Tue, Jul 25, 2017 at 4:58 PM Eric Rescorla  wrote:

> Given that this document has been through 2 WGLCs, and this is basically
> an aesthetic change, I don't think it gets over the barrier.
>
> -Ekr
>
>
> On Tue, Jul 25, 2017 at 4:48 PM, Xuelei Fan  wrote:
>
>> Hi,
>>
>> The TLS 1.3 Certificate handshake message is defined as:
>>
>>    struct {
>>        opaque certificate_request_context<0..2^8-1>;
>>        CertificateEntry certificate_list<0..2^24-1>;
>>    } Certificate;
>>
>>    certificate_request_context  If this message is in response to a
>>       CertificateRequest, the value of certificate_request_context in
>>       that message.  Otherwise (in the case of server authentication),
>>       this field SHALL be zero length.
>>
>>
>> As the certificate_request_context and client delivered Certificate
>> handshake message are only in response to a CertificateRequest, the one
>> byte zero length of certificate_request_context field is redundant for
>> server delivered certificate handshake message. It may be more clear to use
>> the certificate_request_context field for client delivered Certificate
>> handshake message only, for example:
>>
>>    struct {
>>        select (connection_end) {
>>             case client:
>>                opaque certificate_request_context<0..2^8-1>;
>>             case server:
>>                struct {};
>>        }
>>        CertificateEntry certificate_list<0..2^24-1>;
>>    } Certificate;
>>
>> Regards,
>> Xuelei Fan
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>

--94eb2c059c70a4907a05552e1203
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    Agreed it is basically an aesthetic=C2=A0change.

    <=
/div>
    Thanks,
    Xuelei=C2=A0

    =

    On Tue, Jul 25, 2017 at 4:58 PM Eric Rescorla <ekr@rtfm.com> wrote:
    Given that this document has been throug=
h 2 WGLCs, and this is basically an aesthetic change, I don't think it =
gets over the barrier.

    -Ekr


    On Tue, Jul 25, 2017 at 4:48=
 PM, Xuelei Fan <xuelei.fan@vimino.com> wrote:
    =

    Hi,

    The TLS 1.3=C2=A0Ce=
rtificate handshake message is defined as:
       stru=
ct {
       opaque certificate_request_context<0..2^8-1>;
       CertificateEntry certificate_list<0..2^24-1>;
   } Certificate;

   certificate_request_context  If this message is in response to a
      CertificateRequest, the value of certificate_request_context in
      that message.  Otherwise (in the case of server authentication),
      this field SHALL be zero length.

    As th=
e=C2=A0certificate_request_context and client delivered=C2=A0Certificate ha=
ndshake message are only in response to a CertificateRequest, the one byte =
zero length of certificate_request_context field is redundant for server de=
livered certificate handshake message. It may be more clear to use the=C2=
=A0certificate_request_context field for client delivered=C2=A0Certificate =
handshake message only, for example:

    =C2=A0 =
=C2=A0struct {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0select (connection_end)=
 {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case client:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque certificat=
e_request_context<0..2^8-1>;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 case server:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0struct {};
    =C2=A0 =C2=A0 =C2=A0 =C2=A0}
    =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateEntry certificate_list<0..2^24-1=
>;
    =C2=A0 =C2=A0} Certificate;

    =
Regards,
    Xuelei Fan

    

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


    

    

--94eb2c059c70a4907a05552e1203--


From nobody Tue Jul 25 18:21:45 2017
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 86ECA131ECE for ; Tue, 25 Jul 2017 18:21:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LEYX7Eg3oesZ for ; Tue, 25 Jul 2017 18:21:42 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 C6695124B0A for ; Tue, 25 Jul 2017 18:21:42 -0700 (PDT)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1daB1B-000406-9D for tls@ietf.org; Wed, 26 Jul 2017 03:21:42 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1daB19-0007HP-PU for tls@ietf.org; Tue, 25 Jul 2017 21:21:40 -0400
Received: (qmail 11939 invoked from network); 26 Jul 2017 01:21:39 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jul 2017 01:21:38 -0000
To: Peter Gutmann , "tls@ietf.org" 
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>  <1500954833319.1033@cs.auckland.ac.nz>  <2467f973-392a-f579-8b2f-e7cc5332fc49@huitema.net> <1501027031926.45701@cs.auckland.ac.nz>
From: Christian Huitema 
Message-ID: 
Date: Tue, 25 Jul 2017 18:21:37 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1501027031926.45701@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------D18CDEDE89054A2EE85A8166"
X-Originating-IP: 168.144.250.223
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.22)
X-Recommended-Action: accept
X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23qYF5SOz/jkeylAndJeBcYkNu6nlvxXcLqtzf A/BCZeU9UcoRT1aqEQHi9PYSv8V2YOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRP6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyeEeE8v7xjAF2H09SsIttNbeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17qTMtQxOaK6fM/m9QpOzdoC2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe93qlFit1PvkPF7Ua1AOSWcb0i13zjCiwPgdt77s k1WBMw==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 01:21:44 -0000

This is a multi-part message in MIME format.
--------------D18CDEDE89054A2EE85A8166
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit



On 7/25/2017 4:57 PM, Peter Gutmann wrote:
>> Also, when we make such a recommendation in the TLS spec, we can hope that it
>> will be heeded by the TLS developers, but what about the developers of
>> applications and protocols sitting on top of TLS, such DTLS, QUIC or HTTP?
> They don't need to know or care about this, it's being used to generate the
> TLS nonce which is invisible to anything running over TLS.
>
> Are we talking about the same thing here?

Not sure. I am looking at the implementations of QUIC. QUIC needs its
own set of random numbers for things like connection ID or initial
sequence number. The most natural thing to do is do get them from the OS
API, /dev/random or cryptogenrandom(), but that requires platform
specific code. The next natural thing to do is to reuse the random
number generator configured for the TLS context, because it is not OS
dependent. If that is not OK, then developers will need lots of explaining.

-- 
Christian Huitema


--------------D18CDEDE89054A2EE85A8166
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
    
    
    
    
    
    On 7/25/2017 4:57 PM, Peter Gutmann
      wrote:
    
    
    
    
    
      
    
        
    Also, when we make such a recommendation in the TLS spec, we can hope that it
will be heeded by the TLS developers, but what about the developers of
applications and protocols sitting on top of TLS, such DTLS, QUIC or HTTP?

    
      
    
      
    They don't need to know or care about this, it's being used to generate the
TLS nonce which is invisible to anything running over TLS.

Are we talking about the same thing here?
    
    
    
    
    
    Not sure. I am looking at the implementations of QUIC. QUIC needs
    its own set of random numbers for things like connection ID or
    initial sequence number. The most natural thing to do is do get them
    from the OS API, /dev/random or cryptogenrandom(), but that requires
    platform specific code. The next natural thing to do is to reuse the
    random number generator configured for the TLS context, because it
    is not OS dependent. If that is not OK, then developers will need
    lots of explaining.
    
    
    -- 
Christian Huitema
    
  


--------------D18CDEDE89054A2EE85A8166--


From nobody Tue Jul 25 18:32:31 2017
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 3941B1286B2 for ; Tue, 25 Jul 2017 18:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6CzrHmn5vBbn for ; Tue, 25 Jul 2017 18:32:28 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 46F12124B0A for ; Tue, 25 Jul 2017 18:32:28 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id 125so77277105pgi.3 for ; Tue, 25 Jul 2017 18:32:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y4cviCOwC9YdioCRsfaTs0uOkKIc4V7ci3X7AsVHGQI=; b=tGB/4vnW/q9mQhoCNQoVo7QFxX6daq5k2+3xTurOxQo1MBDPTXOoEVS5+DysToW5qr 7gLBS/XT2NL+y4ic94qHgVpWXfBQ7Aj/2mVXjbXAuGQLrVxBfnLaWwmjcpM1Zu5cQnuR JHzm3TbVSnh5j47Celgvjy/e2I7fuNK+RQT/GjR+avt9YdSdQybqtqxN3uJnDA3NMuzL INxZm52d0ZKCMz68HVp6M3bg8l7BVuLz9ifjEi+ofY+VkQTU1dmACPVrbDy/bABrKZtZ mdHSiECSmYScwNHMsQUKAdjCAKf3C+xZiUw6gfZHm7OSiSLLN2fOce9i/Xi19zmlmeuw 9wgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y4cviCOwC9YdioCRsfaTs0uOkKIc4V7ci3X7AsVHGQI=; b=i7Im9BbVxwI4EL6Rf7IDYNoO+zK++lH9mVrFFjg5+pHhueMv3TxfLuHMyrfxlPRY/y EC2aaeqDXCr9LK7DuDVLmlaCg1OQVMt/KAVM9uCViJ+uPmPQMalY/qAenFyBfx+ItYpb aw9DnoN0UhTrJ8m4ktYLSB0tCOl2GVBc77BZikcNCVrU44s1EJq21wsOM0p/FyFpjD2+ XF3vdrnyH8eDbHOEFMKTCiycuHKcMpDbQ/XlVj+jr97V6wTQhJj0eIcf2LAwjYn6rnH1 tEMIpeNu2rN+MIielofGLQbS8BJHoyxug182gAtB/4IRiY60mj7OSqsni9+ScmMyJzxm gugQ==
X-Gm-Message-State: AIVw113GJIu67raVciwJ1yrlVsjRrmlGF4grq9N1BmSjPRXDw0F/J2xw 53+vtT9yc4iDcmjXk4ZK8PFzKW2sCg==
X-Received: by 10.99.98.5 with SMTP id w5mr21232874pgb.354.1501032747917; Tue, 25 Jul 2017 18:32:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Tue, 25 Jul 2017 18:32:27 -0700 (PDT)
In-Reply-To: 
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>  <1500954833319.1033@cs.auckland.ac.nz>  <2467f973-392a-f579-8b2f-e7cc5332fc49@huitema.net> <1501027031926.45701@cs.auckland.ac.nz> 
From: Watson Ladd 
Date: Tue, 25 Jul 2017 18:32:27 -0700
Message-ID: 
To: Christian Huitema 
Cc: Peter Gutmann , "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 01:32:30 -0000

On Tue, Jul 25, 2017 at 6:21 PM, Christian Huitema  wrote:
>
>
> On 7/25/2017 4:57 PM, Peter Gutmann wrote:
>
> Also, when we make such a recommendation in the TLS spec, we can hope that
> it
> will be heeded by the TLS developers, but what about the developers of
> applications and protocols sitting on top of TLS, such DTLS, QUIC or HTTP?
>
> They don't need to know or care about this, it's being used to generate the
> TLS nonce which is invisible to anything running over TLS.
>
> Are we talking about the same thing here?
>
>
> Not sure. I am looking at the implementations of QUIC. QUIC needs its own
> set of random numbers for things like connection ID or initial sequence
> number. The most natural thing to do is do get them from the OS API,
> /dev/random or cryptogenrandom(), but that requires platform specific code.
> The next natural thing to do is to reuse the random number generator
> configured for the TLS context, because it is not OS dependent. If that is
> not OK, then developers will need lots of explaining.

Why not write a cross-platform shim that calls the underlying OS
specific API, instead of implementing another broken RNG?

I feel the solution to broken RNG is don't use them. This entire
discussion is premised on an idea that anything can be done about this
"problem".

>
> --
> Christian Huitema
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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


From nobody Wed Jul 26 01:09:01 2017
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 CBE1513188F for ; Wed, 26 Jul 2017 01:08:59 -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, RP_MATCHES_RCVD=-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=iij.ad.jp
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QnvmxDcBT3m for ; Wed, 26 Jul 2017 01:08:58 -0700 (PDT)
Received: from omgo.iij.ad.jp (mo900.iij.ad.jp [202.232.31.76]) (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 646F4131822 for ; Wed, 26 Jul 2017 01:08:58 -0700 (PDT)
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1501056537; x=1502266137;  bh=1XIDdN9IAY7OWK5Z3qgS9vxrch555iLLwit6UpdUcNQ=; b=gE3Yh0bgamZufMPCbA5jqXRi0ip x+Rp9ngHkjxHhDE/ssluQVeV/sT33QBcBkpb0kPHElwCHcEL+0CQkKB5oG2t0a/7shSutAXfAa41+ 6azahLrbXUwCKwXvNx9UKDcMmHv+D00mxwTEILYRH1Zuz3R+5MRda/IvizIVTY1mE2X+NKuHLGPza Ba54SrzqtnnrnIIsDYShnjeTOF+/Jvqd/9+6k6waUBPJiymyckduwXHejfBi0fHto1259sH1WJKtW Ab2LOTq7csvlgepzCwR9NpUcqcx8Kn2aNNV4KcrZYm5d+nkL/NvHkhB3mYtKPWnuVLA6tDPrC0p5R jyic0/w==;
Received: by omgo.iij.ad.jp (mo900) id v6Q88uNC008725; Wed, 26 Jul 2017 17:08:57 +0900
X-Iguazu-Qid: 33PumyHsDNwO9R4Pg0
Date: Wed, 26 Jul 2017 17:08:56 +0900 (JST)
Message-Id: <20170726.170856.1849883525224784997.kazu@iij.ad.jp>
To: tls@ietf.org
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) 
In-Reply-To: <73E4CF3F-6D27-4482-9CBB-AB8AA4E92216@pahtak.org>
References:  <20170725.152947.1933219367499132607.kazu@iij.ad.jp> <73E4CF3F-6D27-4482-9CBB-AB8AA4E92216@pahtak.org>
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] TLS 1.3 presentation language
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 08:09:00 -0000

Hi Stephen,

> Initially, I thought proposal I would be the best, but now I have a
> mild preference for proposal III. I think it makes the language
> simpler over all. It essentially becomes two primitive types
> (`opaque` and `uint8`) and four type definitions:


I like III, too. But I don't want to keep unused labels such as
'server_share'. So, I like the following definition.

   struct {
       KeyShareEntry client_shares<0..2^16-1>;
   } ClientKeyShares;

   struct {
       select (Handshake.msg_type) {
           case client_hello:        ClientKeyShares;
           case hello_retry_request: NamedGroup;
           case server_hello:        KeyShareEntry;
       };
   } KeyShare;


> Neither the current presentation language nor my proposed one above
> gives meaning to `uint16 ProtocolVersion;`. Absent a compelling
> reason for type aliases, I think this should be written as `uint8
> ProtocolVersion[2];`

If I remember correctly, ProtocolVersion is defined:

      struct {
          uint8 major;
          uint8 minor;
      } ProtocolVersion;

And its value is described as { 3, 1 }.

Now, the notation of 0x0301 is used. So, that's why unit16 is used.

--Kazu


From nobody Wed Jul 26 05:11:59 2017
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 A959A126E3A for ; Wed, 26 Jul 2017 05:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 6Nb7u5aWhcC6 for ; Wed, 26 Jul 2017 05:11:56 -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 5C6F6124E15 for ; Wed, 26 Jul 2017 05:11:56 -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=1501071116; x=1532607116; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QR/ayCchqGDXz2Izx1x8h+w5oukbw0oomtOkzFS4Y/s=; b=zEnmzjVfP4/4KIylI4NNVEuVug8H6n2/n8saHvK5n8IFeY0nsb/AQXaW vSF0hj4/i/EvLqau2rONB1X23saCoStLX0iESnS6/sqZKmrKbAXbaDfA/ Ze9Uyso+L2iFtQh0uJ498L8JwoNrxR6jCcMnl7ZWDT1K2vemBvjJxU3hC Q7+vKDzI/vueHkDTjxb6RL9udEQwfpqtdcdwmVTnF7RzAb8UCmvqm7Iv/ jL1vzLvVu6RsdltyjeOTdPOtu3KAaViVpGFxKCzsron7i5IRK/Yzd9r9T vp/vIR2GA4/vJAByK75NMwlFY6Bgcttnvb6HaKZwF2K8VJsCHFWMGu5oO A==;
X-IronPort-AV: E=Sophos;i="5.40,415,1496059200"; d="scan'208";a="168402772"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Jul 2017 00:11:52 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 00:11:52 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Thu, 27 Jul 2017 00:11:52 +1200
From: Peter Gutmann 
To: Christian Huitema , "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+2hSpUAt7/bkebxZ5uN/u91aJibPQAgAF9Cgj//8R0AIAAcHmAgAEbOYD//06fgIABfhcZ
Date: Wed, 26 Jul 2017 12:11:51 +0000
Message-ID: <1501071106566.29442@cs.auckland.ac.nz>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>  <1500954833319.1033@cs.auckland.ac.nz>  <2467f973-392a-f579-8b2f-e7cc5332fc49@huitema.net> <1501027031926.45701@cs.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-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 12:11:58 -0000

Christian Huitema  writes:=0A=
 =0A=
>On 7/25/2017 4:57 PM, Peter Gutmann wrote:=0A=
>> Are we talking about the same thing here?=0A=
>=0A=
>Not sure. =0A=
=0A=
OK, I'd say we are :-).  This isn't about which PRNG or randomness source t=
o=0A=
use but the need for a separation between PRNG-for-secret-values and PRNG-f=
or-=0A=
public-values.  In particular you don't want to feed large amounts of outpu=
t=0A=
from your PRNG-for-secret-values to an attacker for analysis via nonces,=0A=
client/server randoms, and other things, in case they can use that to attac=
k=0A=
your PRNG state.=0A=
=0A=
The prime example of this is the EC-DRBG fiasco, which relied on the attack=
er=0A=
seeing the client/server random just before the same PRNG was used to gener=
ate=0A=
the master secret.  If the client/server random had come from PRNG instance=
 #1=0A=
and the master secret from PRNG instance #2, it would have been... well, st=
ill=0A=
a bad PRNG, but not as catastrophic a failure.=0A=
=0A=
So the advice was to seed the public-PRNG from the private-PRNG and use the=
=0A=
public-PRNG for nonces, sequence numbers, and so on, and the private-PRNG f=
or=0A=
encryption keys and the like.=0A=
=0A=
Peter.=0A=
    =


From nobody Wed Jul 26 06:22:45 2017
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 C0C19131BF8 for ; Wed, 26 Jul 2017 06:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Level: 
X-Spam-Status: No, score=-6.421 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, RCVD_IN_SORBS_SPAM=0.5, 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 2QbCg4RhgiKw for ; Wed, 26 Jul 2017 06:22: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 C881F129AAD for ; Wed, 26 Jul 2017 06:22:41 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (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 3xHbPq6Q1dz25GY; Wed, 26 Jul 2017 15:22:39 +0200 (CEST)
X-purgate-ID: 152705::1501075359-00000805-A42EB415/0/0
X-purgate-size: 1996
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 mail07.wdf.sap.corp (Postfix) with ESMTP id 3xHbPq2bXjzGnsd; Wed, 26 Jul 2017 15:22:39 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 53A981A6CB; Wed, 26 Jul 2017 15:22:39 +0200 (CEST)
In-Reply-To: <1501071106566.29442@cs.auckland.ac.nz>
To: Peter Gutmann 
Date: Wed, 26 Jul 2017 15:22:39 +0200 (CEST)
CC: Christian Huitema , "tls@ietf.org" 
Reply-To: mrex@sap.com
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: <20170726132239.53A981A6CB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 13:22:44 -0000

Peter Gutmann wrote:
> Christian Huitema  writes:
>  
>>On 7/25/2017 4:57 PM, Peter Gutmann wrote:
>>> Are we talking about the same thing here?
>>
>>Not sure. 
> 
> OK, I'd say we are :-).  This isn't about which PRNG or randomness source to
> use but the need for a separation between PRNG-for-secret-values and PRNG-for-
> public-values.  In particular you don't want to feed large amounts of output
> from your PRNG-for-secret-values to an attacker for analysis via nonces,
> client/server randoms, and other things, in case they can use that to attack
> your PRNG state.
> 
> The prime example of this is the EC-DRBG fiasco, which relied on the attacker
> seeing the client/server random just before the same PRNG was used to generate
> the master secret.  If the client/server random had come from PRNG instance #1
> and the master secret from PRNG instance #2, it would have been... well, still
> a bad PRNG, but not as catastrophic a failure.
> 
> So the advice was to seed the public-PRNG from the private-PRNG and use the
> public-PRNG for nonces, sequence numbers, and so on, and the private-PRNG for
> encryption keys and the like.


Whenever you're using "some" CPRNG as a black box, you should very probably
take 4x to 16x of CPRNG native output size and run it through a cryptgraphic
compression function (such as a secure hash or PRF) to produce 1x output
size (a) as a safety precaution and (b) to obtain reasonable entropy.

Just look at the Intel RDRAND fiasko.  It isn't just a bad design, it
is a clearly documented bad design.  They openly admit that they're
artificially inflating the output by factor of 2x, i.e. that an output
of 256 bits is based on entropy of _at_best_ 128 bits.

Since you also have no idea whether and how the internal hardware design
behind Intel RDRAND is backdoored, you should not be using any of its
output without an at least 10x cryptographic compression in any case.


-Martin


From nobody Wed Jul 26 08:00:09 2017
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 3305413204C for ; Wed, 26 Jul 2017 08:00: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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pahtak-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 I-KAczgpuXeC for ; Wed, 26 Jul 2017 08:00:05 -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 5489813204A for ; Wed, 26 Jul 2017 08:00:05 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id v127so16081394itd.0 for ; Wed, 26 Jul 2017 08:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pahtak-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=PtX77nNk4xkideFvin5S4mmPsQt/p3ZQYd7cxmtPEIg=; b=1B3LvBfDtbj6avOenot9rNX11B1Z22BHOvCvpn9TSM5TO7tbUZQnQk5JdndAHKA8Od 164ndrmNVI72hat+LO++GgKDW/I4QTJaVVQiZnQgPdM738Z4dWewQ+SQxOd1FAXMjx0t 45i/0GpAhksUAA4XrV+5S1pXYwP2PR6imPFZm/WJb55BFrS7xg/k1RGJzGsJ1U+0e22i F/t5h+us60j3sEoEdGyEsR0ZIU7BZgZ/QAQFaO55pCubmyj2ZwH1d7rbOVJndenuz6Sf /MAKRJnMHzML+UvhGDgBzuUDPJgPzZy6i0pKisMQXBqBAfYq9nJsYb54Ae1cT0+ECPA4 jCng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=PtX77nNk4xkideFvin5S4mmPsQt/p3ZQYd7cxmtPEIg=; b=dEEeyJtXQlTLXgen/LFLGX/LxrxMvO8LrKC2tNwmOPcPkzB4oJXnsK0vKNT/40N3Ky YkOzUcBT4iWaUVFfNbik15mb43YaaLQOiBbeaKfLyJSSZKSfXdrT4+JVN582C7aDZ9cF OO5jrzjdXFKeSuQ5FxAG1a3NitQ2RihlQ0zrowu+uTzL6fUbz0jirmg7E+yIJYLzPd1L VLWBx7bevI9+18zAUcUkVOxa3EWBOf5yT7pwjCvsBwCKUry1JfNcCzHvIBGM3jLoTJ2o 4iou2A6i8AzywDxP6FhSG1V7QTFhBCdpUJQ+dlmP9j3cvdYBpl8QuZTIcEcc3b4tua0Y lt9w==
X-Gm-Message-State: AIVw111BJ9hnWHf+thNpWrpyz+Znaqu63q97kVWkXvfrYpccPzw2ZVaM BXS9nosaItItZUwLxCsOIA==
X-Received: by 10.36.165.73 with SMTP id w9mr1193682iti.121.1501081204221; Wed, 26 Jul 2017 08:00:04 -0700 (PDT)
Received: from zbox.pahtak.org (c-73-9-255-112.hsd1.il.comcast.net. [73.9.255.112]) by smtp.gmail.com with ESMTPSA id h196sm8046943ioe.41.2017.07.26.08.00.03 for  (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 26 Jul 2017 08:00:03 -0700 (PDT)
Received: from hackintosh.hsd1.il.comcast.net (router [192.168.1.1]) by zbox.pahtak.org (Postfix) with ESMTPSA id A8003AC2C93 for ; Wed, 26 Jul 2017 10:00:02 -0500 (CDT)
From: Stephen Checkoway 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 26 Jul 2017 10:00:02 -0500
References:  <20170725.152947.1933219367499132607.kazu@iij.ad.jp> <73E4CF3F-6D27-4482-9CBB-AB8AA4E92216@pahtak.org> <20170726.170856.1849883525224784997.kazu@iij.ad.jp>
To: "tls@ietf.org (tls@ietf.org)" 
In-Reply-To: <20170726.170856.1849883525224784997.kazu@iij.ad.jp>
Message-Id: <3F0E5513-48AC-4A44-B3B3-CA21A0B167DE@pahtak.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] TLS 1.3 presentation language
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 15:00:07 -0000

> On Jul 26, 2017, at 03:08, Kazu Yamamoto (=E5=B1=B1=E6=9C=AC=E5=92=8C=E5=
=BD=A6)  wrote:
>=20
> Hi Stephen,
>=20
>> Initially, I thought proposal I would be the best, but now I have a
>> mild preference for proposal III. I think it makes the language
>> simpler over all. It essentially becomes two primitive types
>> (`opaque` and `uint8`) and four type definitions:
>=20
>=20
> I like III, too. But I don't want to keep unused labels such as
> 'server_share'. So, I like the following definition.
>=20
>   struct {
>       KeyShareEntry client_shares<0..2^16-1>;
>   } ClientKeyShares;
>=20
>   struct {
>       select (Handshake.msg_type) {
>           case client_hello:        ClientKeyShares;
>           case hello_retry_request: NamedGroup;
>           case server_hello:        KeyShareEntry;
>       };
>   } KeyShare;

That would be fine too, but `server_share` really is described in the =
text and there's no good way to discuss it without having a field name.

>=20
>> Neither the current presentation language nor my proposed one above
>> gives meaning to `uint16 ProtocolVersion;`. Absent a compelling
>> reason for type aliases, I think this should be written as `uint8
>> ProtocolVersion[2];`
>=20
> If I remember correctly, ProtocolVersion is defined:
>=20
>      struct {
>          uint8 major;
>          uint8 minor;
>      } ProtocolVersion;
>=20
> And its value is described as { 3, 1 }.

I believe that's how it was defined in previous versions. Now it's =
defined (see B.3.1) as

    uint16 ProtocolVersion;

But this notation (a type alias/typedef) isn't defined in the =
presentation language and isn't, to the best of my knowledge, used =
anywhere else.

--=20
Stephen Checkoway




From nobody Wed Jul 26 08:59:11 2017
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 0C70613207C for ; Wed, 26 Jul 2017 08:59:10 -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=pahtak-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 uNIqdLu03lwp for ; Wed, 26 Jul 2017 08:59:08 -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 6D164132073 for ; Wed, 26 Jul 2017 08:59:08 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id v205so21478074itf.1 for ; Wed, 26 Jul 2017 08:59:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pahtak-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=dpMp/ZMD/TpABXpidYHW9lRw9GcfkbnnCsMhfVA5ORM=; b=g25ZFDXu6Si/H//H5A0do8B9E183hWX6Iz1Crfw7VHuOyzagRYZvK7WIJCl53Hw/CW mceDW2QJ7EvjTFAGPiYH8Y946cdYBzBIS5OfRn05kaM47sh9G1PJyGH/pBJm717GWchL lUuQr/NdcQUCvJtGiwzMpwgByFjIkCasj2xyhnZrOtjghj1Bjvhfzj7tw+L1SA7tBB6g f/XttPvZdwJYVDlKr6vn92TRmqTCGwLUOMcfKS94n+sSQfJsVqaQWgjotwemzVa+F5lU dPXyautAbtRdRaLVoTODsskKG0+H1dsZyOPdfgSoy1dbCDbOnQ+2p1tsWveGdEoFwFzX 99Jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=dpMp/ZMD/TpABXpidYHW9lRw9GcfkbnnCsMhfVA5ORM=; b=Ud93SIpNuUGZynFHm9CyxP6zh2/7ZQwxgIYCv0yY8lhqVWjTxG4cD5WGOMtzQY7hHw H/t8+KMc6PaiB19uyrQvgvgrVz5C0+twcQTD6RhL4QxVx9Q9qdKYlnVh+4W/iP4c77Tv 2JQauUI9wHERWLEMCDtxDhTYImPGo1JyLfYGg7NUa+XYW7YVtGK6tw05hoCDdRi08i91 In+y/8pxuTHx8+iRjJiz0mHyea9mkZaK8rh0SlzldVt8OUi823n7JaEwxd+AdReTJCJV bPggoS20S8l/daMr8t6BRcnsbVjOzY3X5GXssKRzcC8KQbsX84a9IZc25RArh7cdiiDs ZYag==
X-Gm-Message-State: AIVw110N0vYKq9m1+YfN3fEDGuQAwwxu2sIMZj5eEFXh9nlIpWllEslR 7ykawUgrcx7rXuw9CrJAtg==
X-Received: by 10.36.78.83 with SMTP id r80mr1385146ita.131.1501084747391; Wed, 26 Jul 2017 08:59:07 -0700 (PDT)
Received: from zbox.pahtak.org ([2601:241:8b00:fe1f:201:2eff:febc:8976]) by smtp.gmail.com with ESMTPSA id g5sm7849787iof.85.2017.07.26.08.59.06 for  (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 26 Jul 2017 08:59:06 -0700 (PDT)
Received: from hackintosh.hsd1.il.comcast.net (router [192.168.1.1]) by zbox.pahtak.org (Postfix) with ESMTPSA id 0BD08AC2C93 for ; Wed, 26 Jul 2017 10:59:06 -0500 (CDT)
From: Stephen Checkoway 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: 
Date: Wed, 26 Jul 2017 10:59:05 -0500
To: "tls@ietf.org (tls@ietf.org)" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [TLS] presentation language description is not great
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 15:59:10 -0000

Stepping back a bit from my previous messages on `select`, I took a =
broader look at how the presentation language (PL) is used to define the =
bits that get sent over the wire. In essence, the presentation language =
defines types and encodings of types.

At a high level, there are 46 types that are defined in Appendix B which =
break down as follows.

- 1 type alias
- 2 fixed-length vector types
- 2 variable-length vector type
- 9 enumerated types
- 32 structure types

The description of the PL, given in Section 3, fails to give meaning to =
27 of these definition. Now the draft has gone through 2 WGLCs and if =
perhaps nobody cares at this point in which case I'll drop it, but I =
find this situation faintly ridiculous.

The 4 fixed- and variable-length vector type definitions
    opaque Random[32];
    uint8 CipherSuite[2];
    opaque PskBinderEntry<32..255>;
    opaque DistinguishedName<1..2^16-1>;
and the 9 enumerated type definitions appear to be correct according to =
the PL.

The type alias
    uint16 ProtocolVersion
has an obvious meaning, but type aliases don't appear in the PL.

Only 5 of the 32 structure types (two of which are empty) are described =
by the PL. In fact, two of the example structures given in Section 3 =
don't fit the description for a structure which appears just before the =
examples. The two main problems with structures are (1) fixed- and =
variable-length vector fields aren't allowed (the PL only defines fixed- =
and variable-length _type definitions_); and (2) most of the uses of =
variants (`select`) don't match the PL as I described in great detail in =
my previous thread.

The PL has a few additional quirks that would be nice to fix as well.

- Anonymous structures are allowed, but unused. They should be removed =
from the PL.
- Variants have an optional field label that is used once (for =
`Handshake`) but that use serves no purpose. The optional label should =
be removed from the PL.
- One of the predefined types, `uint64`, isn't used. It could be =
removed.
- Constants should be restricted to numeric and enumerated types, since =
otherwise the PL would need a syntax for other types and we don't need =
it.


My motivation for all of this is it would be nice to have a clean PL =
that is easily machine parsable. This would enable ensuring that future =
changes to TLS (e.g., extensions) use a consistent syntax. It would also =
enable (at least in theory) parsers generated directly from  the =
standard.

(As an aside, while writing this email, I noticed another issue with =
`TLSCiphertext`, the first field (a constant) should be `ContentType =
opaque_type =3D application_data;` and not `ContentType opaque_type =3D =
23; /* application_data */`. I'll create a PR to fix that after lunch.)

--=20
Stephen Checkoway




From nobody Wed Jul 26 09:06:24 2017
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 93B18132084 for ; Wed, 26 Jul 2017 09:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eibrVN0Vrx3I for ; Wed, 26 Jul 2017 09:06:20 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0651D131CEE for ; Wed, 26 Jul 2017 09:06:20 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id i6so56674667ywb.1 for ; Wed, 26 Jul 2017 09:06:19 -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=f8A14+BXwYI+OhmzdF0BsNjpfjqkWYD7JAMUIjkBFeU=; b=w8C1fkc7qvK3qJwTcIArJjnvwmVAPR948FD1j3MwdZN9UNy+ZAckydX7/dpO4aVHrU o6YlV+6jUz1VGAz+6aWOqT2r72Jmi2O9bCxO0AybST8KaHlaDsEveh/F6t8S38ekTB7I sMICkc1G0pboyLsblXXMleGh70uHF33mLlv1bIgLISwPoC1KUjawGz3Y2fy/W1dU6wGi uxGbKWWHHgpiPlpisCoPQ5Zq5Xfrj19y30aLDcGisStCLhUrEtR2WVwWSUaS3GlpXkLH s3grzsDohXeFUnz8ggLWtL62jaTx4l76vVZy7kz5whdwUr8cPTtJqibPV85SLrt2/PWz DqaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f8A14+BXwYI+OhmzdF0BsNjpfjqkWYD7JAMUIjkBFeU=; b=i3mrf1abKRmUDnYijx+qaMxAoE6X/5lIvxnkh1wE/onp6e3XVW9WWEGlatEUFmB7Gs 1gHMs/PyiQyZGfSl5CX1K4i0GZeiinRcJGB8rwWAqbKdjVXOkqWQTUtUsR2YN1eKujWJ 5BORVbqr+kJVC75q9zl4+9atykxFBmTDbhXlyuquW1c/r8//tvso6tAZqoiAIThT6gmu GcDyRM6LeWb4STw8JG1lJYKHGR7tPzgLrNxO6qmLvLo/f6ivUoXrGLHtgfWxPTCbc+kx xIEZ7JPMklLKWNaLbbgyYhCkrVyJfs4oCRkll7bZm2ZBnegn1XiZhxyWPYhdHcvPThap 6heQ==
X-Gm-Message-State: AIVw113DrdYv3ApKxGWBvR32xMHkY/hClFVYmo10Az98Q1EWP/VBwmpi UfhRyG5v+DowW5wcLHZDQBAnPWm/9TG3
X-Received: by 10.37.171.79 with SMTP id u73mr1225053ybi.329.1501085178956; Wed, 26 Jul 2017 09:06:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.71 with HTTP; Wed, 26 Jul 2017 09:06:18 -0700 (PDT)
In-Reply-To: <20170726132239.53A981A6CB@ld9781.wdf.sap.corp>
References: <1501071106566.29442@cs.auckland.ac.nz> <20170726132239.53A981A6CB@ld9781.wdf.sap.corp>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 26 Jul 2017 09:06:18 -0700
Message-ID: 
To: mrex@sap.com
Cc: Peter Gutmann , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c188c62def25205553aa021"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 16:06:21 -0000

--94eb2c188c62def25205553aa021
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 26, 2017 at 6:22 AM, Martin Rex  wrote:

> Since you also have no idea whether and how the internal hardware design
> behind Intel RDRAND is backdoored, you should not be using any of its
> output without an at least 10x cryptographic compression in any case.
>

Obviously your CPU can fully compromise you locally, so that's not very
interesting to think about. But for remote attacks, like the one you
describe here, where an adversary may use predictable PRNG output, it is
probably better to mix RDRAND output with something else. There are a few
layers of defense here, such as multi-source NRBGs, or personalization
strings. Those significantly distance the output from the RDRAND. The kind
of compression you mention here can be easily precomputed and tables
generated by someone with a large amount of resources, since it's a pure
function.

In BoringSSL, and s2n, we mix RDRAND in as part of the reseeding. But the
initial seed came from urandom (which is not pure RDRAND). In s2n, we also
use personalization strings to provide another degree of defense.


-- 
Colm

--94eb2c188c62def25205553aa021
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Wed, Jul 26, 2017 at 6:22 AM, Martin Rex <mrex@sap.com> wr=
ote:
    Since you also have no idea whether =
and how the internal hardware design
    
behind Intel RDRAND is backdoored, you should not be using any of its
    
output without an at least 10x cryptographic compression in any case.

    Obviously your CPU can fully compromise you =
locally, so that's not very interesting to think about. But for remote =
attacks, like the one you describe here, where an adversary may use predict=
able PRNG output, it is probably better to mix RDRAND output with something=
 else. There are a few layers of defense here, such as multi-source NRBGs, =
or personalization strings. Those significantly distance the output from th=
e RDRAND. The kind of compression you mention here can be easily precompute=
d and tables generated by someone with a large amount of resources, since i=
t's a pure function.=C2=A0

    In BoringSSL, and s=
2n, we mix RDRAND in as part of the reseeding. But the initial seed came fr=
om urandom (which is not pure RDRAND). In s2n, we also use personalization =
strings to provide another degree of defense.=C2=A0


    -- 
    Colm
    

    

--94eb2c188c62def25205553aa021--


From nobody Wed Jul 26 09:51:08 2017
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 8944C1320C3 for ; Wed, 26 Jul 2017 09:51: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, 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=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 sDNQkLE9sjAU for ; Wed, 26 Jul 2017 09:51:05 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 2490A1320C1 for ; Wed, 26 Jul 2017 09:51:05 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6QGl6nF005282; Wed, 26 Jul 2017 17:51:03 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=XRDC432QYccR85hm98rBM7BOUKBU7QZYEEUh8hlfrVQ=; b=E+f2746Q7ioQNUUOpGrmPyFocc7ySHMmIKsHWSLSCGGi0ijKf9TnvMJAL16C+Bvn7VAJ xsJ/MdpOnm/ILrLcDof6epBKYGLGYGPjJDidE+gZheKp7m11s4wwxqJ70XFBhq6STNMr SXrJQ+Bo1m6muZUTmIwX61NhmMw2O8lEORk7Xv4rn0KnWWJcgZE4OEpdZ6MHjumbpEMU 1rZgXaipb5SZcRvqh8m324B5ZwfLtcwEfqotQwb37HpkNmmlkACLlzLamIic9xPYahdJ f0ffGhR7eKAKM/8ELFysg48ITMSOdRll13cdOzO5PemgNmHdkHikbSPiCjjrJ9XvuJnn Kg== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2bxjb4jyhy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Jul 2017 17:51:03 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6QGkJ0e004090; Wed, 26 Jul 2017 12:51:02 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bv21vjfr6-1; Wed, 26 Jul 2017 12:51:02 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id B2CB78005D; Wed, 26 Jul 2017 10:51:01 -0600 (MDT)
To: Stephen Checkoway , "tls@ietf.org (tls@ietf.org)" 
References: 
From: Benjamin Kaduk 
Message-ID: <42e9a14e-05d2-ed59-10bc-777ec568996e@akamai.com>
Date: Wed, 26 Jul 2017 11:51:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C2118EF28A68309B31B6243C"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-26_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707260244
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-26_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707260244
Archived-At: 
Subject: Re: [TLS] presentation language description is not great
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 16:51:06 -0000

This is a multi-part message in MIME format.
--------------C2118EF28A68309B31B6243C
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/26/2017 10:59 AM, Stephen Checkoway wrote:
> My motivation for all of this is it would be nice to have a clean PL that is easily machine parsable. This would enable ensuring that future changes to TLS (e.g., extensions) use a consistent syntax. It would also enable (at least in theory) parsers generated directly from  the standard.

It would.  It would also be nice to actually get the spec out the door,
a spec that has already made it through two WGLCs, no less.

TLS presentation language is (basically) only used to specify TLS, TLS
implementors are largely familiar with its quirks already, and it
doesn't seem like a good use of the WG's time to try to change it for
TLS 1.3.  Which is not to say "don't try", but I don't see how this is
worth delaying the publication of TLS 1.3.

-Ben

--------------C2118EF28A68309B31B6243C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 07/26/2017 10:59 AM, Stephen Checkoway wrote:
    
    
    
      
    My motivation for all of this is it would be nice to have a clean PL that is easily machine parsable. This would enable ensuring that future changes to TLS (e.g., extensions) use a consistent syntax. It would also enable (at least in theory) parsers generated directly from  the standard.
    
    
    
    
    
    It would.  It would also be nice to actually get the spec out the
    door, a spec that has already made it through two WGLCs, no less.
    
    
    
    TLS presentation language is (basically) only used to specify TLS,
    TLS implementors are largely familiar with its quirks already, and
    it doesn't seem like a good use of the WG's time to try to change it
    for TLS 1.3.  Which is not to say "don't try", but I don't see how
    this is worth delaying the publication of TLS 1.3.
    
    
    
    -Ben
    
  


--------------C2118EF28A68309B31B6243C--


From nobody Wed Jul 26 09:56:52 2017
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 0FA6E1320B9 for ; Wed, 26 Jul 2017 09:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 fSUEE_0pgY9z for ; Wed, 26 Jul 2017 09:56:49 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2101320BB for ; Wed, 26 Jul 2017 09:56:48 -0700 (PDT)
Received: from [192.168.91.201] ([80.92.121.224]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MTjMy-1d9ymC0p2O-00QQ8K; Wed, 26 Jul 2017 18:56:36 +0200
To: Benjamin Kaduk , Stephen Checkoway , "tls@ietf.org (tls@ietf.org)" 
References:  <42e9a14e-05d2-ed59-10bc-777ec568996e@akamai.com>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <78109135-cf98-bdc0-4c69-47c27386ce35@gmx.net>
Date: Wed, 26 Jul 2017 18:56:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <42e9a14e-05d2-ed59-10bc-777ec568996e@akamai.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:SgiqWUUTbgrNNW9W1xCimnAP+Mv/H3NMy2ckCuz2nFvrCjzf+VV rac45F3n+QDZH/BGtHXhQEp6tWTIJMxYGIaappo0tBbGtTsQuS0U0xO5QnXWVm2QpqiUHmj tyRSuRCu3G640M/6uvrkEW01o4rSa3xq+VVqT6FvWlinG+D04kbTEOACjLMOETIJHn9eXyz aisAHvkFbgGucm4q2G0bQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:sFmmvA9El4A=:jU15uCAT9elCfNnrB2Hic9 MIk8XsIIEjxOg8wUb/pA2cn3idffT1i2MUKnwE8vd+U7TQ0brgtapH3CAv3JwLq1E2JpUggkC hqhAMzFORkYAEtgyNASSJufHTQ3vKoPrNuMmMj8PQv6DGs40vt9EesXZ5mEf7vyiiuK/XXOvx fcW1An8f51OcXT9KUDddXPrM1wTYX+rtq1PyV5h7q68JrzNbVnpdJYYxDowjkouijK51FEL3y +80dAnXy/saZRJ0rrNQFdoPPqh0XNAdoR2rKJ8qTbDiBrScj67HSnewvNZQzChtuqD+3bCN8K EE+2Pb5+q/6f20vWOjYy+TOpGHNUb3mENNUp05rMGmDYzUycTWk17D9mSDNVSACZsmONuOvZ2 UhOARqGYBLR4DNJInaQGAXPrCTnMmQUg4m4ka9J1fQnpU3ix6e1FYqwmq4UwqLM/edshP81TE 3MgOUfCfUuAt3Nk47kJCeZwiKmw7YUVbo2Al/Zjn1In1UEfBswhrlQAOAtvyGDMg5yImpAIQ7 smDAFX/vwnDvr3jTzKmfGP5XK1cdy3/ACUfKtFv8j2uJujr0xSJX4XoaPrS4ojCOgbkTR+kz+ Nf7FhUayIB6yZ9LN/iUmVMRZIRUhiNWOQS/xvmxfk4YTk1+5sKcjszt8xA82UnPa35Vd30eI0 Vk6SUfZ7ruBCFFFhEUee8PpfS1U8j7eqAzLly5L1bbLyBcFn3RY4ZxhDCso6jPelcF1iSmyPN ynQoP8H1eOI7173OuQebD+yHAQEk7tKxwiH7MXbWesC0NpkvAR/NsQmi0+OHCVOVkyFu6s7K6 cRiCB443mR7dHSbTRITw1auuIzN4slItQd3lr5aa61wMI8AgmU=
Archived-At: 
Subject: Re: [TLS] presentation language description is not great
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 16:56:51 -0000

I agree with Ben. It is too late

On 07/26/2017 06:51 PM, Benjamin Kaduk wrote:
> On 07/26/2017 10:59 AM, Stephen Checkoway wrote:
>> My motivation for all of this is it would be nice to have a clean PL that is easily machine parsable. This would enable ensuring that future changes to TLS (e.g., extensions) use a consistent syntax. It would also enable (at least in theory) parsers generated directly from  the standard.
> 
> It would.  It would also be nice to actually get the spec out the door,
> a spec that has already made it through two WGLCs, no less.
> 
> TLS presentation language is (basically) only used to specify TLS, TLS
> implementors are largely familiar with its quirks already, and it
> doesn't seem like a good use of the WG's time to try to change it for
> TLS 1.3.  Which is not to say "don't try", but I don't see how this is
> worth delaying the publication of TLS 1.3.
> 
> -Ben
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


From nobody Wed Jul 26 10:04:32 2017
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 4BD41126B6E for ; Wed, 26 Jul 2017 10:04:31 -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 rSWhOxtNx-Dw for ; Wed, 26 Jul 2017 10:04:29 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 4E2DE131DFC for ; Wed, 26 Jul 2017 10:04:29 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id i6so57713886ywb.1 for ; Wed, 26 Jul 2017 10:04:29 -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=80yaCYJ0/2Rox6Le8dX5t65C5WwqPyhW7QQyXss32G4=; b=kZjsAaWkuHvgvkn7jSmD8pxfa9bIo99WaUF0qFpgnCu+rGRUttHHlQayLMXIGFu87c UtPEZdsLrdPuB7dZMvBKkwBq1lAJ8PpAQeDLGrOoOEDX1ctub7aj8Bnr2TgdbRDGBJbr yOqgaKMyaE5+fTusBUQjaTC6wDa6K3lTzUR/H1LmviAPk9M2r3Jj2NULJNO7fWA0+5Xt h0u5gZbVzepc1sln/faaDCuUP8DeU0qNskXY+XyrEYyCg4chNpYrXC3wigGK0BlDl5Vu +FZ/OuiWpHQzYYWXZwIng+9mf9agNtiSTVwdHorywl/WsY8cevo/EyYfBPqUGpMMqhCv pCUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=80yaCYJ0/2Rox6Le8dX5t65C5WwqPyhW7QQyXss32G4=; b=FrwUQCkQAGfgRJ7bmWLtG8Yf4waU5SiEKU3wEYf/m9plNO/slS00gh8iTo4FCJfVsw 39lYp7Y7pHsgg9r7NCxf6JpdZe92wMJIs5tKP76unQJiPVD8BK6IaTdcjwOPhw2c57sD KeDB5vwuQgKoybDlN4nE3EOzlgqSmn1qc2MrRbkIFpoTTrZCV7vc2w0Wp21WYBQ2NC8X o3TPAslXFaAs40UkG15IPMoksPzu+pcjQ/HoZftyFXMMsS5DeWUHE41HRum7BJ+1f1vB Oi07VZH2G7NW3wLDW3cSa6XlfgEt6FuJONroi0czifu+qjjgHK5qWg0FrvApSrj+//ry NONA==
X-Gm-Message-State: AIVw110flovx+Z2k7nLIBxPs2Tb9obhSm65I9FG460UqUuKMtb8BRPPK yZXGtMyVejIN/CiNeLbrQL6LAyO8SMcL
X-Received: by 10.37.181.25 with SMTP id p25mr1377355ybj.249.1501088668123; Wed, 26 Jul 2017 10:04:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.36.12 with HTTP; Wed, 26 Jul 2017 10:03:47 -0700 (PDT)
In-Reply-To: <78109135-cf98-bdc0-4c69-47c27386ce35@gmx.net>
References:  <42e9a14e-05d2-ed59-10bc-777ec568996e@akamai.com> <78109135-cf98-bdc0-4c69-47c27386ce35@gmx.net>
From: Eric Rescorla 
Date: Wed, 26 Jul 2017 10:03:47 -0700
Message-ID: 
To: Hannes Tschofenig 
Cc: Benjamin Kaduk , Stephen Checkoway ,  "tls@ietf.org (tls@ietf.org)" 
Content-Type: multipart/alternative; boundary="f403045e6ed0d7c59f05553b703b"
Archived-At: 
Subject: Re: [TLS] presentation language description is not great
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 17:04:31 -0000

--f403045e6ed0d7c59f05553b703b
Content-Type: text/plain; charset="UTF-8"

I don't think it's useful to rework the PDUs significantly. That's a great
way to really mess things up.

If you think that there are changes to the *description* of the language
that would make it easier
to read that description and then read the PDUs, PRs might be useful. Also,
very small tweaks
to the actual PDUs might be useful, but a total rework is out of scope.

-Ekr


On Wed, Jul 26, 2017 at 9:56 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> I agree with Ben. It is too late
>
> On 07/26/2017 06:51 PM, Benjamin Kaduk wrote:
> > On 07/26/2017 10:59 AM, Stephen Checkoway wrote:
> >> My motivation for all of this is it would be nice to have a clean PL
> that is easily machine parsable. This would enable ensuring that future
> changes to TLS (e.g., extensions) use a consistent syntax. It would also
> enable (at least in theory) parsers generated directly from  the standard.
> >
> > It would.  It would also be nice to actually get the spec out the door,
> > a spec that has already made it through two WGLCs, no less.
> >
> > TLS presentation language is (basically) only used to specify TLS, TLS
> > implementors are largely familiar with its quirks already, and it
> > doesn't seem like a good use of the WG's time to try to change it for
> > TLS 1.3.  Which is not to say "don't try", but I don't see how this is
> > worth delaying the publication of TLS 1.3.
> >
> > -Ben
> >
> >
> > _______________________________________________
> > 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
>

--f403045e6ed0d7c59f05553b703b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    I don't think it's useful to rework the PDUs signi=
ficantly. That's a great way to really mess things up.

    If you think that there are changes to the *description* of the language=
 that would make it easier
    to read that description and then read=
 the PDUs, PRs might be useful. Also, very small tweaks
    to the ac=
tual PDUs might be useful, but a total rework is out of scope.
    -Ekr


    =

    On Wed, Jul 26, 2017 at 9:56 AM, Hannes Tschofen=
ig <hannes.tschofenig@gmx.net> wrote:
    I agree with Ben. It is too late
    


    
On 07/26/2017 06:51 PM, Benjamin Kaduk wrote:
    
> On 07/26/2017 10:59 AM, Stephen Checkoway wrote:
    
>> My motivation for all of this is it would be nice to have a clean =
PL that is easily machine parsable. This would enable ensuring that future =
changes to TLS (e.g., extensions) use a consistent syntax. It would also en=
able (at least in theory) parsers generated directly from=C2=A0 the standar=
d.
    
>
    
> It would.=C2=A0 It would also be nice to actually get the spec out the=
 door,
    
> a spec that has already made it through two WGLCs, no less.
    
>
    
> TLS presentation language is (basically) only used to specify TLS, TLS=

    
> implementors are largely familiar with its quirks already, and it
    
> doesn't seem like a good use of the WG's time to try to change=
 it for
    
> TLS 1.3.=C2=A0 Which is not to say "don't try", but I do=
n't see how this is
    
> worth delaying the publication of TLS 1.3.
    
>
    
> -Ben
    
>
    
>
    

    > __________________=
_____________________________
    
> 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
    


    

--f403045e6ed0d7c59f05553b703b--


From nobody Wed Jul 26 10:19:00 2017
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 5DA7E1320D4 for ; Wed, 26 Jul 2017 10:18:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 It5P0Sti76uy for ; Wed, 26 Jul 2017 10:18:56 -0700 (PDT)
Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E4C131E0D for ; Wed, 26 Jul 2017 10:18:56 -0700 (PDT)
Received: by mail-oi0-x244.google.com with SMTP id v11so13948744oif.1 for ; Wed, 26 Jul 2017 10:18:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+akORFMY5mMF9mGAfqMej9zLn8Nhle2X91FNTPNRAL4=; b=hPM8Ae1d84LFabowr2PN2ZWdwJP+1eZ7wAvHLuFKeWE0j9tvV2GgtxstYBmc6VNEiz Z6TCYBJqKZaJ55JkpohtNWFMxC5z/7X5mJhdxzSqNTOhDIT0g0ehqVl0d7OgbPz/s/Aq 6k9WJX/8/Nd4aS1abvoQ+QMrRughtbKX3SXK6HPLftFXuQAQ2dmhax65E0sitCmh6qqR NofN4Wg53HyMSJYYGtvC6+4B5Q0AcyPbKp3FvCezqsvrHBRtsqU/tq3bGJRXt36A9lEr OsGq73HI+bZjzzJ7DLo/NWPgAZorFWDbUgp/iAbpv1z+OPEOTrytSrXp007+bHachk85 FT5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=+akORFMY5mMF9mGAfqMej9zLn8Nhle2X91FNTPNRAL4=; b=ULoorgviJ+vS0heRvHF7QxnpjMnWfqREB/zy0+FRdpsThrTPU5AJwrRVFcAioK3wwN MSL30LgLW8mQfTogwLkrMvW7GX4OHvdQIKzQeT2LzvWvDFFNGfhG12l2aqBWIJuGTtkc 2qdzSVI4COwtEyHQbwAoG6NztItIQcwpFMNi38KNqCp2nxsit/T74cUUM+0mnYXgJudP QkKBdfsaQraxXs4ybO6cfuSoWNdXFkA2xG9FPV6Yg+NGjPAjwxpItjKbaEpc+vyeHutl 8e3uMDaRYEsvxdGZje2jnZduV3VZMotI814f8VTIuxRFuznEsus4pmkd9r6n1GODjtnh jKhA==
X-Gm-Message-State: AIVw113BRDw623uPjaMmOepRlnjZTccYVGD54rHAngyxLO7VUOarWOpp U/LF8JkG4cTatYonEbtK6px6KFgchxv9yNY=
X-Received: by 10.202.74.194 with SMTP id x185mr1593243oia.26.1501089535697; Wed, 26 Jul 2017 10:18:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.98.28 with HTTP; Wed, 26 Jul 2017 10:18:54 -0700 (PDT)
Reply-To: noloader@gmail.com
In-Reply-To: 
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>  <1500954833319.1033@cs.auckland.ac.nz>  <2467f973-392a-f579-8b2f-e7cc5332fc49@huitema.net> <1501027031926.45701@cs.auckland.ac.nz> 
From: Jeffrey Walton 
Date: Wed, 26 Jul 2017 13:18:54 -0400
Message-ID: 
To: Christian Huitema 
Cc: Peter Gutmann , "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 17:18:58 -0000

On Tue, Jul 25, 2017 at 9:21 PM, Christian Huitema  wrote:
> ...
> Not sure. I am looking at the implementations of QUIC. QUIC needs its own
> set of random numbers for things like connection ID or initial sequence
> number. The most natural thing to do is do get them from the OS API,
> /dev/random or cryptogenrandom(), but that requires platform specific code...

Somewhat related (but OT for TLS-WG): According to the Linux Kernel
Crypto folks, you should not use /dev/random because it is a
deprecated interface. You should use /dev/urandom, and it has been
recommend for the last decade or so. Also see "[RFC PATCH v12 3/4]
Linux Random Number Generator" (https://lkml.org/lkml/2017/7/20/993)
on the kernel-crypto mailing list.

The BSDs, OS X, DragonFly, and others may be different. But for Linux
the advice is clear.

Jeff


From nobody Wed Jul 26 11:59:08 2017
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 29DE012EB9B for ; Wed, 26 Jul 2017 11:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Level: 
X-Spam-Status: No, score=-6.421 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, RCVD_IN_SORBS_SPAM=0.5, 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 nFUwkXte3bUP for ; Wed, 26 Jul 2017 11:59:05 -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 E307C12EA7C for ; Wed, 26 Jul 2017 11:58:59 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (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 3xHkst14g1z1HTl; Wed, 26 Jul 2017 20:58:58 +0200 (CEST)
X-purgate-ID: 152705::1501095538-00000805-BF1A869E/0/0
X-purgate-size: 2236
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 mail07.wdf.sap.corp (Postfix) with ESMTP id 3xHkss0F9HzGnxJ; Wed, 26 Jul 2017 20:58:57 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 0311E1A6CB; Wed, 26 Jul 2017 20:58:57 +0200 (CEST)
In-Reply-To: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 26 Jul 2017 20:58:56 +0200 (CEST)
CC: mrex@sap.com, Peter Gutmann ,  "tls@ietf.org" 
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20170726185857.0311E1A6CB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 18:59:07 -0000

Colm MacC=E1rthaigh wrote:
> Martin Rex  wrote:
>>=20
>> Since you also have no idea whether and how the internal hardware design
>> behind Intel RDRAND is backdoored, you should not be using any of its
>> output without an at least 10x cryptographic compression in any case.
>=20
> Obviously your CPU can fully compromise you locally, so that's not very
> interesting to think about. But for remote attacks, like the one you
> describe here, where an adversary may use predictable PRNG output, it is
> probably better to mix RDRAND output with something else. There are a few
> layers of defense here, such as multi-source NRBGs, or personalization
> strings. Those significantly distance the output from the RDRAND. The kind
> of compression you mention here can be easily precomputed and tables
> generated by someone with a large amount of resources, since it's a pure
> function.

We're either talking about different things, or I fail to understand
what you're talking about.

The predictable failure of EC_Dual was based on the fact that the
internal state and the output had (almost) the _same_ size.

With RDRAND, you would use e.g. SHA-256 to compress 10*256 =3D 2560 Bits of
a black-box CPRNG output into a 256-bit _new_ output that you
actually use in communication protocols.

Should the creator of a backdoored black-box-CPRNG be able to recompute
the internal state from a few leaked _new_ (post-compression) outputs,
then you _will_ be able to notice a real problem (non-randomness)
problem with the outputs of black-box-CPRNG.


>=20
> In BoringSSL, and s2n, we mix RDRAND in as part of the reseeding. But the
> initial seed came from urandom (which is not pure RDRAND). In s2n, we also
> use personalization strings to provide another degree of defense.

Any half-way portable crypto library will have code for collecting
entropy on pre-RDRAND Intel CPUs and non-Intel CPUs, probably use
an entropy pool that is >=3D512 bits and outputs of at most half of
the size of the entropy pool, and use compressed RDRAND outputs for
additional entropy gathering, and at most for nonces, but never
use RDRAND alone for generation of secret keying material.


-Martin


From nobody Wed Jul 26 12:46:43 2017
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 4C400131473 for ; Wed, 26 Jul 2017 12:46:42 -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 YZY8qZuSdnxw for ; Wed, 26 Jul 2017 12:46:38 -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 DDFF113146E for ; Wed, 26 Jul 2017 12:46:37 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id u207so32741757ywc.3 for ; Wed, 26 Jul 2017 12:46:37 -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=lZUDF8kS41AGMtvQrfjk98Ns/kPFrBIc6OJMtN0TmPY=; b=RD2O3uzl53p5kB3UY75dzST7xTbiQozYN9H5wwF0w5BtYRn1YeCZ2+T9soaVsbFPjw S+WGpaLf6BeElS13xvkFL+6XLPzCeKGD8OkssHhc3tmsiqyGJBmZbH8Obg0KiWf3ng0Y 67pibZtaNmmDTV+HBTdvONhOa6O9jgX7GNws2Dhyco1Zxju4Y5u5SOIK9FPtZI1KGPna lmHcv6AplrmXOSg10JfvbdVcA60Nb8n3czG+GbcPqJ+B7PT0vCir9KUpv7KakeRUHbTX HmeAIlTPjbNVlH4U2v8GLH3KRmoHS6xncaRd8G2qRYMpcwLPO9HbuzQS83+XRTLV9qp3 jagg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lZUDF8kS41AGMtvQrfjk98Ns/kPFrBIc6OJMtN0TmPY=; b=iXVkaYH2lX9lYKnhl8AJgUx2R2EzjPWahIg55gEYnvP38tj/sDeebda6YiI1MsP1vW 2S4swSR2aJMpSxwsR5qU5zoH9vfz6UXt8SWTeI/3ezaH5fhSJhabwkpWApXch9sWdFDF 15qiPvKplxURJBRVEcaCWyQ+f3oPO34naVs+VlvlO7qwKgYZ0QMUAXat1wSWV6L4BjYV wbdaqKiO7VseIy/7iJK/JO7/8ofjSvL4tomGTLIGL8VFxsKUZ/nWiVVSn0QeSe0vG9VP el1HzQo5XEfo/ORZeUsHlE+SN87xUxw/dWkm8xB5Jdo6EcDx5R9MWHKHdDuO1TsSD1SM YvEw==
X-Gm-Message-State: AIVw111xVth4P8Hr1NhW3Accl7vh0EfVZ5kCxeeZ8koQodch63HvTtID lA6Yk/1uKokGETwffmeJVICJCYzoxQif
X-Received: by 10.37.194.130 with SMTP id s124mr1796508ybf.360.1501098397039;  Wed, 26 Jul 2017 12:46:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.71 with HTTP; Wed, 26 Jul 2017 12:46:36 -0700 (PDT)
In-Reply-To: <20170726185857.0311E1A6CB@ld9781.wdf.sap.corp>
References:  <20170726185857.0311E1A6CB@ld9781.wdf.sap.corp>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 26 Jul 2017 12:46:36 -0700
Message-ID: 
To: mrex@sap.com
Cc: Peter Gutmann , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c054adcbaa89e05553db4ce"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 19:46:42 -0000

--94eb2c054adcbaa89e05553db4ce
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 26, 2017 at 11:58 AM, Martin Rex  wrote:

> With RDRAND, you would use e.g. SHA-256 to compress 10*256 = 2560 Bits of
> a black-box CPRNG output into a 256-bit _new_ output that you
> actually use in communication protocols.
>

If the relation between the RDRAND input and the output of your function is
fixed, then your attacker than just do the same thing. It doesn't help at
all really. You have to mix RDRAND with something else that is unknowable
to the attacker as part of the process.

-- 
Colm

--94eb2c054adcbaa89e05553db4ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Wed, Jul 26, 2017 at 11:58 AM, Martin Rex <mrex@sap.com> w=
rote:
    With RDRAND, you would use e.g. SHA=
-256 to compress 10*256 =3D 2560 Bits of
    
a black-box CPRNG output into a 256-bit _new_ output that you
    
actually use in communication protocols.

    If the relation between the RDRAND input and the output of your function =
is fixed, then your attacker than just do the same thing. It doesn't he=
lp at all really. You have to mix RDRAND with something else that is unknow=
able to the attacker as part of the process. =C2=A0=C2=A0

    -- 
    Colm
    

    

--94eb2c054adcbaa89e05553db4ce--


From nobody Wed Jul 26 13:57:36 2017
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 09182131CE5 for ; Wed, 26 Jul 2017 13:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Level: 
X-Spam-Status: No, score=-6.421 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, RCVD_IN_SORBS_SPAM=0.5, 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 l6z9_80PhIod for ; Wed, 26 Jul 2017 13:57:34 -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 55FEB129A9F for ; Wed, 26 Jul 2017 13:57:34 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (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 3xHnVh4mMzz25Rd; Wed, 26 Jul 2017 22:57:32 +0200 (CEST)
X-purgate-ID: 152705::1501102652-00000805-5C18835A/0/0
X-purgate-size: 1266
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 mail07.wdf.sap.corp (Postfix) with ESMTP id 3xHnVh3qQqzGp3B; Wed, 26 Jul 2017 22:57:32 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 784F41A6CB; Wed, 26 Jul 2017 22:57:32 +0200 (CEST)
In-Reply-To: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 26 Jul 2017 22:57:32 +0200 (CEST)
CC: mrex@sap.com, Peter Gutmann ,  "tls@ietf.org" 
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 20:57:36 -0000

Colm MacC=E1rthaigh wrote:
> Martin Rex  wrote:
>>=20
>> With RDRAND, you would use e.g. SHA-256 to compress 10*256 =3D 2560 Bits=
 of
>> a black-box CPRNG output into a 256-bit _new_ output that you
>> actually use in communication protocols.
>=20
> If the relation between the RDRAND input and the output of your function =
is
> fixed, then your attacker than just do the same thing. It doesn't help at
> all really. You have to mix RDRAND with something else that is unknowable
> to the attacker as part of the process.

Through the 10x compression of the RDRAND output, which will provably
create an incredibly huge amount of collisions, the attacker will be
unable to identify any particular output values of RDRAND.

Your conceived attack could only work under the condition that
10 RDRAND consecutive outputs are always fully deterministic, and
that also the seed used by RDRAND will be fully deterministic to
the attacker -- or can otherwise be learned out-of-band by the attacker
-- while at the same time this property will remain invisible to
all external randomness tests.

Can you shed any light on how you believe and attacker could meet
such preconditions, because I'm not seeing the problem yet.


-Martin


From nobody Wed Jul 26 14:13:34 2017
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 EFA74131C2E for ; Wed, 26 Jul 2017 14:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VKMZEvQfuoH1 for ; Wed, 26 Jul 2017 14:13:31 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25570131471 for ; Wed, 26 Jul 2017 14:13:31 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id y129so89014568pgy.4 for ; Wed, 26 Jul 2017 14:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G5TyBTcErMar/Trv0vLZWiwPShAehRYOBGDLiF87xBk=; b=m8E30ECmjtIDYNl3+ju67bYSYdNSwhhr1w92/7ADueKSW33QiKgWNfCl6faXLNNG2Y UEYP4NnUZcE+PjutQ7mNZepwXGsG7pcG6LgLP8lEnhq2XzXXQR2jWHVRDbLB4lqp1LPs gwBUM0JacZ34KH/tAx7u+nPpSWYrIFT70wA9/unwc2kdQwFIICwwqkk/h8V9PLYtxGf4 VCXjs/0l+P/tm71XTi4GPp3mWIBdI3/3cPOUoQmcuoRHKOp+RRDOoNiBcPt3xFPvp8Gf Y6VGne9sjJ0FeozcEKQpddfD0BmRkzEl3kjvSmAtSH7r8I7gljr95VlAluJpbtWvAxz6 2RKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G5TyBTcErMar/Trv0vLZWiwPShAehRYOBGDLiF87xBk=; b=LuxPGp2t11Clsl1Cy6MzL9hYCpkKhwH5tBfdtSUDqxd8jOizyZ3xJKacbJLb/3MLsV q07z8IAuCc4tWmpj1GyWgClMiKf4n0Y6JDBHknB3Q8NrKSYLAuVgjiL0LyV3v8y+n+ZW 7xaKDiSfAnc7gshj44N/KUyZMmKYNlEcig0Ur2rsUgTUFZW22T49ZbgiYh1M47swq/s+ V44vY9yF+1TWaDra5Q0eWwO561Q/Xv+WywhrEzahNHUGB54EDng3cfSgSE2gAtKXWYoa DX2iNKXCgAaNtiqe4wU/gp950SfD8RwcTx3bzJftvbUAJcNG+Jub3vFifA2h9MaezhlJ zFFw==
X-Gm-Message-State: AIVw110P2EVnDGBV80rVfvHGOJtGtVJfdBfikddNJ4gOcuOB+n3TNI70 A19Myfvrufzbl7k/xWvY/wo+7sQL7k6Y
X-Received: by 10.99.51.200 with SMTP id z191mr2037411pgz.329.1501103610754; Wed, 26 Jul 2017 14:13:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Wed, 26 Jul 2017 14:13:30 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Wed, 26 Jul 2017 14:13:30 -0700 (PDT)
In-Reply-To: <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>
From: Watson Ladd 
Date: Wed, 26 Jul 2017 14:13:30 -0700
Message-ID: 
To: mrex@sap.com
Cc: tls@ietf.org, =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Content-Type: multipart/alternative; boundary="94eb2c0e69867d82ed05553eebbc"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 21:13:33 -0000

--94eb2c0e69867d82ed05553eebbc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Jul 26, 2017 1:57 PM, "Martin Rex"  wrote:

Colm MacC=C3=A1rthaigh wrote:
> Martin Rex  wrote:
>>
>> With RDRAND, you would use e.g. SHA-256 to compress 10*256 =3D 2560 Bits=
 of
>> a black-box CPRNG output into a 256-bit _new_ output that you
>> actually use in communication protocols.
>
> If the relation between the RDRAND input and the output of your function
is
> fixed, then your attacker than just do the same thing. It doesn't help at
> all really. You have to mix RDRAND with something else that is unknowable
> to the attacker as part of the process.

Through the 10x compression of the RDRAND output, which will provably
create an incredibly huge amount of collisions, the attacker will be
unable to identify any particular output values of RDRAND.

Your conceived attack could only work under the condition that
10 RDRAND consecutive outputs are always fully deterministic, and
that also the seed used by RDRAND will be fully deterministic to
the attacker -- or can otherwise be learned out-of-band by the attacker
-- while at the same time this property will remain invisible to
all external randomness tests.

Can you shed any light on how you believe and attacker could meet
such preconditions, because I'm not seeing the problem yet.


Trivially.

Imagine an attack where the attacker restricts the keys used in the final
counter mode step to a 2^40 keyspace and the counter resets to 0 every 2^40
outputs.

Detecting this has happened is extremely difficult: one needs to force 2^40
rekeyings, and so execute 2^80 operations. Extra points for the 2^80 keys
being a function of cpu serial number.

An attacker though can mount a 2^80 search for the internal state across
many CPUs, and can do multitarget as well.

Sincerely,
Watson Ladd



-Martin

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

--94eb2c0e69867d82ed05553eebbc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Jul 26, 2017 1:57 PM, "Martin Rex" <mrex@sap.com> wrote:
    Colm MacC=C3=A1rthaigh wrot=
e:
    
> Martin Rex <mrex@sap.com> wr=
ote:
    
>>
    
>> With RDRAND, you would use e.g. SHA-256 to compress 10*256 =3D 256=
0 Bits of
    
>> a black-box CPRNG output into a 256-bit _new_ output that you
    
>> actually use in communication protocols.
    
>
    
> If the relation between the RDRAND input and the output of your functi=
on is
    
> fixed, then your attacker than just do the same thing. It doesn't =
help at
    
> all really. You have to mix RDRAND with something else that is unknowa=
ble
    
> to the attacker as part of the process.
    

    

    Through the 10x compression of the RDRAND output, which will provably=

    
create an incredibly huge amount of collisions, the attacker will be
    
unable to identify any particular output values of RDRAND.
    

    
Your conceived attack could only work under the condition that
    
10 RDRAND consecutive outputs are always fully deterministic, and
    
that also the seed used by RDRAND will be fully deterministic to
    
the attacker -- or can otherwise be learned out-of-band by the attacker
    
-- while at the same time this property will remain invisible to
    
all external randomness tests.
    

    
Can you shed any light on how you believe and attacker could meet
    
such preconditions, because I'm not seeing the problem yet.

    Trivia=
lly.

    Imagine an attack w=
here the attacker restricts the keys used in the final counter mode step to=
 a 2^40 keyspace and the counter resets to 0 every 2^40 outputs.

    Detecting this has happened is ext=
remely difficult: one needs to force 2^40 rekeyings, and so execute 2^80 op=
erations. Extra points for the 2^80 keys being a function of cpu serial num=
ber.

    An attacker though =
can mount a 2^80 search for the internal state across many CPUs, and can do=
 multitarget as well.

    Si=
ncerely,
    Watson Ladd=C2=A0
    


    

    
-Martin
    

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


    

--94eb2c0e69867d82ed05553eebbc--


From nobody Wed Jul 26 14:15:32 2017
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 BA31C131CFC for ; Wed, 26 Jul 2017 14:15:30 -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 lpxOLPlggXRY for ; Wed, 26 Jul 2017 14:15:29 -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 38F75131C2E for ; Wed, 26 Jul 2017 14:15:29 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id l82so37351820ywc.2 for ; Wed, 26 Jul 2017 14:15:29 -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=+hnNZbAPtDK0pBaWYnyz1gmnKtwsvigBSE2yhmn5Xmo=; b=hqunNmwnNcyF61HgD6Jlwrslf7LEHGEZ+TF8JQ6HyWPQD81LpmbzLFetwtOFth5KeS 7svIEMtV95vO8DT1bltCddUPcwEQNEOxV/+bJ8j/2iMtf9+A849QdWgrH14OC/JxsTJ8 1JbnCDXw4hyM9VnTODw7XKlfuRWnz3FBb4ZeuJlPXfUiexY8PD/BRMle+SdxtbqiEdbn 4Pw0MLoiQqimJqjGMLFNNoTtk+yIeMbx/HsQHASZKiWPzy4GMEdK+w8e2ELel2rROrjc CjXVveVDwx5EBRq3doU0sKeHC7La//561PvRKqjr1FNy4z9ZG+vfX9SlOq4qWOpxU3JN Xc/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+hnNZbAPtDK0pBaWYnyz1gmnKtwsvigBSE2yhmn5Xmo=; b=mtBg2rNql8lqzupwDIG3L4yFnkZ25/3RGLzwNttVtD2RnjK+X/NhVW86wG0KE9wAsy oZOIOWc4/rOHSw8Nzk6uSrG5/TiphP8wDIBppbF5CcevAPTdE1muEqcezk5MOVxDIe5I sRsuef/ugM/jgRNXpqcsUnyavi5+DE9UUSYQSY0eQEXbK9dQH2bYkzLLf0fOaxJ9gqv2 wEwT7LEVt5BFOdIHNzYMA2y6I95eJrxqLZ8s3gfHJ23xlh4Mg8GBLcR4gef1u2SRtf9z D+Gx55FaPdADInj2qkMw+g3nHpTbxQq0DUIZS+ACJAjFUIjpMWEY4Vecq7MbOYJmKtbF BZ2w==
X-Gm-Message-State: AIVw111+6a/GkP4fxw1FcnP4W4KC8RWyP80YlH3/dxsZiS/T68euGjVu rlEf6lKBrMPCl3xx9l0wy7zwV2X957ye
X-Received: by 10.129.94.67 with SMTP id s64mr1934317ywb.83.1501103728339; Wed, 26 Jul 2017 14:15:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.71 with HTTP; Wed, 26 Jul 2017 14:15:27 -0700 (PDT)
In-Reply-To: <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 26 Jul 2017 14:15:27 -0700
Message-ID: 
To: mrex@sap.com
Cc: Peter Gutmann , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114921d27fdb1005553ef2e2"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 21:15:31 -0000

--001a114921d27fdb1005553ef2e2
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 26, 2017 at 1:57 PM, Martin Rex  wrote:
>
> Through the 10x compression of the RDRAND output, which will provably
> create an incredibly huge amount of collisions, the attacker will be
> unable to identify any particular output values of RDRAND.
>
> Your conceived attack could only work under the condition that
> 10 RDRAND consecutive outputs are always fully deterministic, and
> that also the seed used by RDRAND will be fully deterministic to
> the attacker -- or can otherwise be learned out-of-band by the attacker
> -- while at the same time this property will remain invisible to
> all external randomness tests.
>

I think this is pretty easy for some conceivable attacks. Suppose that your
adversary makes RDRAND a DRBG seeded with wall-clock time and device-ID.
That's going to produce deterministic output, but it will pass all of the
tests and appear to be random. If the attacker knows your device-ID, or
even just a range of possible device-IDs, they can confirm via a match.

The 10x compression would just make them do a bit more work.


-- 
Colm

--001a114921d27fdb1005553ef2e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Wed, Jul 26, 2017 at 1:57 PM, Martin Rex <mrex@sap.com> wr=
ote:
    Through the 10x compression of the RDRAN=
D output, which will provably
    
create an incredibly huge amount of collisions, the attacker will be
    
unable to identify any particular output values of RDRAND.
    

    
Your conceived attack could only work under the condition that
    
10 RDRAND consecutive outputs are always fully deterministic, and
    
that also the seed used by RDRAND will be fully deterministic to
    
the attacker -- or can otherwise be learned out-of-band by the attacker
    
-- while at the same time this property will remain invisible to
    
all external randomness tests.

    I think =
this is pretty easy for some conceivable attacks. Suppose that your adversa=
ry makes RDRAND a DRBG seeded with wall-clock time and device-ID. That'=
s going to produce deterministic output, but it will pass all of the tests =
and appear to be random. If the attacker knows your device-ID, or even just=
 a range of possible device-IDs, they can confirm via a match.=C2=A0
    <=
div>
    The 10x compression would just make them do a bit more w=
ork.


    -- 
    Colm
    

    

--001a114921d27fdb1005553ef2e2--


From nobody Wed Jul 26 16:27:16 2017
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 2AF31131ED5 for ; Wed, 26 Jul 2017 16:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg9YOHprOdQz for ; Wed, 26 Jul 2017 16:27:12 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A559131ED2 for ; Wed, 26 Jul 2017 16:27:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BDB52BE2C for ; Thu, 27 Jul 2017 00:27:09 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z90Wyuf_5_D for ; Thu, 27 Jul 2017 00:27:08 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F427BE24 for ; Thu, 27 Jul 2017 00:27:08 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1501111628; bh=uh4MhaX1IJbxYwtBGNXGovbV5wrtB9dh8bjk+OUwndc=; h=Subject:References:To:From:Date:In-Reply-To:From; b=epUY7CrNBkPYFvsYOx3xz3CS5sXhEwBitjRWF0SzMpFVJJnB6njfFv5spb2eWYdV9 a5Jhrk7TuNo5t/LkUueYrOvLlliFdOGB2orWl9RdOK24k+XnYtgWAwdj+0TVGPBQqp DlV0fu4wcawgA07iuuV4I3wxHyxYpBz1DVniiYQ4=
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp> 
To: "tls@ietf.org" 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>
Date: Thu, 27 Jul 2017 00:27:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wDoGcMJxN7KXtEmn5lf2fhHO2iXBMM6Hb"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 26 Jul 2017 23:27:15 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wDoGcMJxN7KXtEmn5lf2fhHO2iXBMM6Hb
Content-Type: multipart/mixed; boundary="j2aFEgMJhdwG2f0tfFAsfSn91UlOLkwcC";
 protected-headers="v1"
From: Stephen Farrell 
To: "tls@ietf.org" 
Message-ID: <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
References: 
 <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>
 
In-Reply-To: 

--j2aFEgMJhdwG2f0tfFAsfSn91UlOLkwcC
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


I've suggested some text for this in a PR [1]
based on what people have said in this thread.

I'm sure that can be further improved.

It might be no harm to add more pointers to that
appendix from elsewhere in the spec, and/or to
add a list of the various public/private random
numbers that are needed to that appendix. (I'd be
happy to do a pass to identify those if folks
basically like this kind of addition.)

I also need to figure out how to handle the
reference properly:-) Can do that tomorrow.

Cheers,
S.

[1] https://github.com/tlswg/tls13-spec/pull/1068


--j2aFEgMJhdwG2f0tfFAsfSn91UlOLkwcC--

--wDoGcMJxN7KXtEmn5lf2fhHO2iXBMM6Hb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZeSVLAAoJEC88hzaAX42iwJEH/21wdWgdcQ/bTIcGz20fF5PM
Ql+GtTLZwYVf0GZWQKW2rYFgyGc4JIdXNwKXdhIHIE9eD/CKN8LG6DF9x1vuEdM7
Zo2LGrZ3Ews6PWdt9nVrm8GouvsYiVOhDbLQ7QBfBnMIHSMMN+Qr7ChiF73EDTUI
3eTcpew6fjC6dlunZLBSyBlgcVqkWqemFUxeqF0+GocW1zivwEJozU3sNXY7ePDN
7Kc5J3bGDKO39shH6KuS1Xk6jb0GLWKm4zvdIJOUK/chife0k/smS7mDnaT3cuyO
p9fhyBlGnyEpo2WPV4k3VA66Rg4cpH0d/fbfM92rr/2gLY+2/Zor1u5WdlsSxBM=
=USlg
-----END PGP SIGNATURE-----

--wDoGcMJxN7KXtEmn5lf2fhHO2iXBMM6Hb--


From nobody Thu Jul 27 15:34:43 2017
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 0B2DC1321DD for ; Thu, 27 Jul 2017 15:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=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 YEtPL8sp-7Me for ; Thu, 27 Jul 2017 15:34:40 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449BF1321E1 for ; Thu, 27 Jul 2017 15:34:36 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id u207so53204524ywc.3 for ; Thu, 27 Jul 2017 15:34:36 -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=Yrc0MgX6OeJczYl/xCN6SjDMkdJSh2zMJGkes40gN8g=; b=ttJmLRC1SoyK/cdjr9G6CU7I97CdGasrJ7ieeDPXNwmdp8yQ9eEtR1Tzp6fnAc4rbH 0s1yZqyYINzllQeho2iChoMOQPz0tVszrRNmU27lZdCE5hDuEK+cNYcNZqAADnmnu1Hl z5fAhStXIuatOJ5YEr9QB7ZdmoiDsPsqAst1QuMs4gTB6uxzUnCCOwuIi92ENewZItQp TkfPayXJ8mVL2h6oRObNIeUBeHJ7WgJ61vc9PIkrKAt61I9KWdtkCyYKuPZ/wQNDJ965 XXGEA/NHdLoN0BXNKvOFKDNt6A8Qx8z7/ttovIVPhHJ4OLcccx+ZK/DIXmhdOhihQAug iK6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yrc0MgX6OeJczYl/xCN6SjDMkdJSh2zMJGkes40gN8g=; b=Loi2n/wFomWAZD6/MrAVRN+aZGCAb8Ji1Hqk760FDgvBr+jS0FdeIN064t+ZBq/hK6 3rkQRkZv/+SnJWlccJvWnWxuvLFP6n4//WGTbidnkeEHYKy6InM1ScNweEHP05Rp4OyV e7DtwIfhoomUmrmE3cCQasrX4RNmHpNyIpUVX90jjoQNJx8ailaJtx1XY25athx5q8yr xW5h7OQRXTNl8nls5cRWjxfPh3zaHREH7b8epJ5vM/v5zKF3ysbb4u+iQKyXVElU2kKN /dkq0Q+b9q/YBDeWQC0niqI4MIx+um8Qzh9jsCtUyYhwBP12h1GddkM4zNpa3CW0JAiN fZRQ==
X-Gm-Message-State: AIVw113njQgH1Ix110o26w7ERLaEfCLAev5CHTXTq+Z383bpg9AYne5N oBCZITJoe5sFWmGDHu8zJDVnHjAMcB1aF7ddLw==
X-Received: by 10.129.75.5 with SMTP id y5mr5230948ywa.222.1501194875541; Thu, 27 Jul 2017 15:34:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.36.12 with HTTP; Thu, 27 Jul 2017 15:33:54 -0700 (PDT)
In-Reply-To: <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>
From: Eric Rescorla 
Date: Thu, 27 Jul 2017 15:33:54 -0700
Message-ID: 
To: Stephen Farrell 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113f1e9a4bdfa20555542b3b"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 27 Jul 2017 22:34:42 -0000

--001a113f1e9a4bdfa20555542b3b
Content-Type: text/plain; charset="UTF-8"

Spec updated here;
https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc42942af9ca77

-Ekr


On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell 
wrote:

>
> I've suggested some text for this in a PR [1]
> based on what people have said in this thread.
>
> I'm sure that can be further improved.
>
> It might be no harm to add more pointers to that
> appendix from elsewhere in the spec, and/or to
> add a list of the various public/private random
> numbers that are needed to that appendix. (I'd be
> happy to do a pass to identify those if folks
> basically like this kind of addition.)
>
> I also need to figure out how to handle the
> reference properly:-) Can do that tomorrow.
>
> Cheers,
> S.
>
> [1] https://github.com/tlswg/tls13-spec/pull/1068
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a113f1e9a4bdfa20555542b3b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



    On Wed, Jul 26, 2017 at 4:27 PM, =
Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

    
I've suggested some text for this in a PR [1]
    
based on what people have said in this thread.
    

    
I'm sure that can be further improved.
    

    
It might be no harm to add more pointers to that
    
appendix from elsewhere in the spec, and/or to
    
add a list of the various public/private random
    
numbers that are needed to that appendix. (I'd be
    
happy to do a pass to identify those if folks
    
basically like this kind of addition.)
    

    
I also need to figure out how to handle the
    
reference properly:-) Can do that tomorrow.
    

    
Cheers,
    
S.
    

    
[1] https://github.com/tlswg/tls13-spec/pull/1068<=
/a>
    

    

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


    

--001a113f1e9a4bdfa20555542b3b--


From nobody Thu Jul 27 16:33:45 2017
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 BCE62131C24 for ; Thu, 27 Jul 2017 16:33:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bvYq8clwiz0r for ; Thu, 27 Jul 2017 16:33:41 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173AF1252BA for ; Thu, 27 Jul 2017 16:33:40 -0700 (PDT)
Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2017 19:33:39 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0319.002; Thu, 27 Jul 2017 19:33:39 -0400
From: Dan Brown 
To: Eric Rescorla , Stephen Farrell 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+yUHLG+hMivEObnVpzx6wh/KJjeS0AgAC0BYCAAI15AIAAcHiAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDwAgAANUQCAABPSAIAABQGAgAAkyoCAAYN2AP//zaLl
Date: Thu, 27 Jul 2017 23:33:38 +0000
Message-ID: <20170727233335.8573013.91860.16216@blackberry.com>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>, 
In-Reply-To: 
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_2017072723333585730139186016216blackberrycom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 27 Jul 2017 23:33:44 -0000

--_000_2017072723333585730139186016216blackberrycom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


I don't think 2 CSPRNGs is a good idea.

Wasn=92t there a few years back some RSA keys with separate p and q, genera=
ted independently leading to an attack...

Here if the seeds to initialize the RNGS are related, or one is weak, or wo=
rst if the seed is a raw source that doesn=92t change in the moments betwee=
n the two CSPRNG inits, that'd be bad, even if the CSPRNGs were good.
From: Eric Rescorla
Sent: Thursday, July 27, 2017 6:34 PM
To: Stephen Farrell
Cc: tls@ietf.org
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's


Spec updated here;
https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc4294=
2af9ca77

-Ekr


On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell > wrote:

I've suggested some text for this in a PR [1]
based on what people have said in this thread.

I'm sure that can be further improved.

It might be no harm to add more pointers to that
appendix from elsewhere in the spec, and/or to
add a list of the various public/private random
numbers that are needed to that appendix. (I'd be
happy to do a pass to identify those if folks
basically like this kind of addition.)

I also need to figure out how to handle the
reference properly:-) Can do that tomorrow.

Cheers,
S.

[1] https://github.com/tlswg/tls13-spec/pull/1068


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



--_000_2017072723333585730139186016216blackberrycom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







    

    

    


    


    

    From: Eric Rescorla
    

    Sent: Thursday, July 27, 2017 6:34 PM
    

    To: Stephen Farrell
    

    Cc: tls@ietf.org
    

    Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
    

    
    		

    
    

    

    

    

    

    



    

    On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell=
 
<stephen.=
farrell@cs.tcd.ie> wrote:
    

    

    
I've suggested some text for this in a PR [1]
    
based on what people have said in this thread.
    

    
I'm sure that can be further improved.
    

    
It might be no harm to add more pointers to that
    
appendix from elsewhere in the spec, and/or to
    
add a list of the various public/private random
    
numbers that are needed to that appendix. (I'd be
    
happy to do a pass to identify those if folks
    
basically like this kind of addition.)
    

    
I also need to figure out how to handle the
    
reference properly:-) Can do that tomorrow.
    

    
Cheers,
    
S.
    

    
[1] 
https://github.com/tlswg/tls13-spec/pull/1068
    

    

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

    

    

    

    

    

    



--_000_2017072723333585730139186016216blackberrycom_--


From nobody Thu Jul 27 16:43:28 2017
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 AD63D131D02 for ; Thu, 27 Jul 2017 16:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 RpoCtro94YqM for ; Thu, 27 Jul 2017 16:43:23 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 631F9131CD1 for ; Thu, 27 Jul 2017 16:43:23 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6RNhJnV026826; Thu, 27 Jul 2017 19:43:19 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Dan Brown 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI/QFdXms6d7jEaZNtjFKD2eRqJjeSwAgAC0BYCAAI15AIAAcHmAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDsAgAANUgCAABPRAIAABQKAgAAkyYCAAYN3AIAAELAAgAACowA=
Date: Thu, 27 Jul 2017 23:43:06 +0000
Message-ID: <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com>
In-Reply-To: <20170727233335.8573013.91860.16216@blackberry.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; boundary="Apple-Mail-2D5E2050-55D1-4311-BAB1-6E7A7EA746B5"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-27_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707270360
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 27 Jul 2017 23:43:26 -0000

--Apple-Mail-2D5E2050-55D1-4311-BAB1-6E7A7EA746B5
Content-Type: multipart/alternative;
	boundary=Apple-Mail-2CE78D37-521C-4F94-9C1A-584DEF991F40
Content-Transfer-Encoding: 7bit


--Apple-Mail-2CE78D37-521C-4F94-9C1A-584DEF991F40
Content-Type: text/plain;
	charset=windows-1251
Content-Transfer-Encoding: base64

UmVzcGVjdGZ1bGx5IGRpc2FncmVlLiBIYXZpbmcgdHdvIGNyeXB0b2dyYXBoaWNhbGx5IGluZGVw
ZW5kZW50IFBSTkdzLCBvbmUgZm9yIHB1YmxpYyBkYXRhIGFuZCBvbmUgZm9yIGtleSBtYXRlcmlh
bCwgSU1ITyBpcyBhIGdvb2QgaWRlYS4gT2YgY291cnNlLCBib3RoIHNob3VsZCBiZSBwcm9wZXJs
eSBzZWVkZWQgLSBidXQgdGhhdCdzIGEgZGlmZmVyZW50IGlzc3VlLg0KDQpSZWdhcmRzLA0KVXJp
DQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiBPbiBKdWwgMjcsIDIwMTcsIGF0IDE5OjMzLCBE
YW4gQnJvd24gPGRhbmlicm93bkBibGFja2JlcnJ5LmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gSSBk
b24ndCB0aGluayAyIENTUFJOR3MgaXMgYSBnb29kIGlkZWEuDQo+IA0KPiBXYXNuknQgdGhlcmUg
YSBmZXcgeWVhcnMgYmFjayBzb21lIFJTQSBrZXlzIHdpdGggc2VwYXJhdGUgcCBhbmQgcSwgZ2Vu
ZXJhdGVkIGluZGVwZW5kZW50bHkgbGVhZGluZyB0byBhbiBhdHRhY2suLi4NCj4gDQo+IEhlcmUg
aWYgdGhlIHNlZWRzIHRvIGluaXRpYWxpemUgdGhlIFJOR1MgYXJlIHJlbGF0ZWQsIG9yIG9uZSBp
cyB3ZWFrLCBvciB3b3JzdCBpZiB0aGUgc2VlZCBpcyBhIHJhdyBzb3VyY2UgdGhhdCBkb2VzbpJ0
IGNoYW5nZSBpbiB0aGUgbW9tZW50cyBiZXR3ZWVuIHRoZSB0d28gQ1NQUk5HIGluaXRzLCB0aGF0
J2QgYmUgYmFkLCBldmVuIGlmIHRoZSBDU1BSTkdzIHdlcmUgZ29vZC4NCj4gRnJvbTogRXJpYyBS
ZXNjb3JsYQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAyNywgMjAxNyA2OjM0IFBNDQo+IFRvOiBT
dGVwaGVuIEZhcnJlbGwNCj4gQ2M6IHRsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1RMU10g
MzIgYnl0ZSByYW5kb21zIGluIFRMUzEuMyBoZWxsbydzDQo+IA0KPiBTcGVjIHVwZGF0ZWQgaGVy
ZTsNCj4gaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvY29tbWl0LzQ2NWRlMGUx
ODliMmI1OTA5MGQwZWFjMGFjYmM0Mjk0MmFmOWNhNzcNCj4gDQo+IC1Fa3INCj4gDQo+IA0KPj4g
T24gV2VkLCBKdWwgMjYsIDIwMTcgYXQgNDoyNyBQTSwgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVu
LmZhcnJlbGxAY3MudGNkLmllPiB3cm90ZToNCj4+IA0KPj4gSSd2ZSBzdWdnZXN0ZWQgc29tZSB0
ZXh0IGZvciB0aGlzIGluIGEgUFIgWzFdDQo+PiBiYXNlZCBvbiB3aGF0IHBlb3BsZSBoYXZlIHNh
aWQgaW4gdGhpcyB0aHJlYWQuDQo+PiANCj4+IEknbSBzdXJlIHRoYXQgY2FuIGJlIGZ1cnRoZXIg
aW1wcm92ZWQuDQo+PiANCj4+IEl0IG1pZ2h0IGJlIG5vIGhhcm0gdG8gYWRkIG1vcmUgcG9pbnRl
cnMgdG8gdGhhdA0KPj4gYXBwZW5kaXggZnJvbSBlbHNld2hlcmUgaW4gdGhlIHNwZWMsIGFuZC9v
ciB0bw0KPj4gYWRkIGEgbGlzdCBvZiB0aGUgdmFyaW91cyBwdWJsaWMvcHJpdmF0ZSByYW5kb20N
Cj4+IG51bWJlcnMgdGhhdCBhcmUgbmVlZGVkIHRvIHRoYXQgYXBwZW5kaXguIChJJ2QgYmUNCj4+
IGhhcHB5IHRvIGRvIGEgcGFzcyB0byBpZGVudGlmeSB0aG9zZSBpZiBmb2xrcw0KPj4gYmFzaWNh
bGx5IGxpa2UgdGhpcyBraW5kIG9mIGFkZGl0aW9uLikNCj4+IA0KPj4gSSBhbHNvIG5lZWQgdG8g
ZmlndXJlIG91dCBob3cgdG8gaGFuZGxlIHRoZQ0KPj4gcmVmZXJlbmNlIHByb3Blcmx5Oi0pIENh
biBkbyB0aGF0IHRvbW9ycm93Lg0KPj4gDQo+PiBDaGVlcnMsDQo+PiBTLg0KPj4gDQo+PiBbMV0g
aHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC8xMDY4DQo+PiANCj4+IA0K
Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFRM
UyBtYWlsaW5nIGxpc3QNCj4+IFRMU0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby90bHMNCj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gVExTIG1haWxpbmcgbGlzdA0KPiBUTFNAaWV0Zi5v
cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg==

--Apple-Mail-2CE78D37-521C-4F94-9C1A-584DEF991F40
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+UmVzcGVj
dGZ1bGx5IGRpc2FncmVlLiBIYXZpbmcgdHdvIGNyeXB0b2dyYXBoaWNhbGx5IGluZGVwZW5kZW50
IFBSTkdzLCBvbmUgZm9yIHB1YmxpYyBkYXRhIGFuZCBvbmUgZm9yIGtleSBtYXRlcmlhbCwgSU1I
TyBpcyBhIGdvb2QgaWRlYS4gT2YgY291cnNlLCBib3RoIHNob3VsZCBiZSBwcm9wZXJseSBzZWVk
ZWQgLSBidXQgdGhhdCdzIGEgZGlmZmVyZW50IGlzc3VlLjxicj48YnI+UmVnYXJkcyw8ZGl2PlVy
aTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U2VudCBmcm9tIG15IGlQaG9uZTwvZGl2PjwvZGl2
PjxkaXY+PGJyPk9uIEp1bCAyNywgMjAxNywgYXQgMTk6MzMsIERhbiBCcm93biAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmRhbmlicm93bkBibGFja2JlcnJ5LmNvbSI+ZGFuaWJyb3duQGJsYWNrYmVycnku
Y29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48
ZGl2Pg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7
IGNoYXJzZXQ9V2luZG93cy0xMjUyIj4NCg0KDQo8ZGl2IHN0eWxlPSJ3aWR0aDoxMDAlOyBmb250
LXNpemU6aW5pdGlhbDsgZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJvJyxzYW5zLXNlcmlm
LHNhbnMtc2VyaWY7IGNvbG9yOnJnYigzMSw3MywxMjUpOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJh
Y2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5
bGU9IndpZHRoOjEwMCU7IGZvbnQtc2l6ZTppbml0aWFsOyBmb250LWZhbWlseTpDYWxpYnJpLCdT
bGF0ZSBQcm8nLHNhbnMtc2VyaWYsc2Fucy1zZXJpZjsgY29sb3I6cmdiKDMxLDczLDEyNSk7IHRl
eHQtYWxpZ246aW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4NCkkg
ZG9uJ3QgdGhpbmsgMiBDU1BSTkdzIGlzIGEgZ29vZCBpZGVhLjwvZGl2Pg0KPGRpdiBzdHlsZT0i
d2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRpYWw7IGZvbnQtZmFtaWx5OkNhbGlicmksJ1NsYXRl
IFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmOyBjb2xvcjpyZ2IoMzEsNzMsMTI1KTsgdGV4dC1h
bGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KPGJyPg0K
PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3aWR0aDoxMDAlOyBmb250LXNpemU6aW5pdGlhbDsgZm9udC1m
YW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJvJyxzYW5zLXNlcmlmLHNhbnMtc2VyaWY7IGNvbG9yOnJn
YigzMSw3MywxMjUpOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1
NSwyNTUsMjU1KSI+DQpXYXNu4oCZdCB0aGVyZSBhIGZldyB5ZWFycyBiYWNrIHNvbWUgUlNBIGtl
eXMgd2l0aCBzZXBhcmF0ZSBwIGFuZCBxLCBnZW5lcmF0ZWQgaW5kZXBlbmRlbnRseSBsZWFkaW5n
IHRvIGFuIGF0dGFjay4uLjwvZGl2Pg0KPGRpdiBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXpl
OmluaXRpYWw7IGZvbnQtZmFtaWx5OkNhbGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5z
LXNlcmlmOyBjb2xvcjpyZ2IoMzEsNzMsMTI1KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3Jv
dW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJ3
aWR0aDoxMDAlOyBmb250LXNpemU6aW5pdGlhbDsgZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUg
UHJvJyxzYW5zLXNlcmlmLHNhbnMtc2VyaWY7IGNvbG9yOnJnYigzMSw3MywxMjUpOyB0ZXh0LWFs
aWduOmluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQpIZXJlIGlm
IHRoZSBzZWVkcyB0byBpbml0aWFsaXplIHRoZSBSTkdTIGFyZSByZWxhdGVkLCBvciBvbmUgaXMg
d2Vhaywgb3Igd29yc3QgaWYgdGhlIHNlZWQgaXMgYSByYXcgc291cmNlIHRoYXQgZG9lc27igJl0
IGNoYW5nZSBpbiB0aGUgbW9tZW50cyBiZXR3ZWVuIHRoZSB0d28gQ1NQUk5HIGluaXRzLCB0aGF0
J2QgYmUgYmFkLCBldmVuIGlmIHRoZSBDU1BSTkdzIHdlcmUgZ29vZC48L2Rpdj4NCjx0YWJsZSB3
aWR0aD0iMTAwJSIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6d2hpdGU7IGJvcmRlci1zcGFjaW5n
OjBweCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgY29sc3Bhbj0iMiIgc3R5bGU9ImZvbnQtc2l6ZTpp
bml0aWFsOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUs
MjU1KSI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6c29saWQgbm9uZSBub25lOyBib3JkZXIt
dG9wLWNvbG9yOnJnYigxODEsMTk2LDIyMyk7IGJvcmRlci10b3Atd2lkdGg6MXB0OyBwYWRkaW5n
OjNwdCAwaW4gMGluOyBmb250LWZhbWlseTpUYWhvbWEsJ0JCIEFscGhhIFNhbnMnLCdTbGF0ZSBQ
cm8nOyBmb250LXNpemU6MTBwdCI+DQo8ZGl2PjxiPkZyb206IDwvYj5FcmljIFJlc2NvcmxhPC9k
aXY+DQo8ZGl2PjxiPlNlbnQ6IDwvYj5UaHVyc2RheSwgSnVseSAyNywgMjAxNyA2OjM0IFBNPC9k
aXY+DQo8ZGl2PjxiPlRvOiA8L2I+U3RlcGhlbiBGYXJyZWxsPC9kaXY+DQo8ZGl2PjxiPkNjOiA8
L2I+PGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxzQGlldGYub3JnPC9hPjwvZGl2Pg0K
PGRpdj48Yj5TdWJqZWN0OiA8L2I+UmU6IFtUTFNdIDMyIGJ5dGUgcmFuZG9tcyBpbiBUTFMxLjMg
aGVsbG8nczwvZGl2Pg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K
PGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOnNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xv
cjpyZ2IoMTg2LDE4OCwyMDkpOyBib3JkZXItdG9wLXdpZHRoOjFwdDsgZm9udC1zaXplOmluaXRp
YWw7IHRleHQtYWxpZ246aW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUp
Ij4NCjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPlNwZWMgdXBkYXRlZCBoZXJl
Ow0KPGRpdj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9jb21t
aXQvNDY1ZGUwZTE4OWIyYjU5MDkwZDBlYWMwYWNiYzQyOTQyYWY5Y2E3NyI+aHR0cHM6Ly9naXRo
dWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvY29tbWl0LzQ2NWRlMGUxODliMmI1OTA5MGQwZWFjMGFj
YmM0Mjk0MmFmOWNhNzc8L2E+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4t
RWtyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l
eHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgSnVsIDI2LCAyMDE3
IGF0IDQ6MjcgUE0sIFN0ZXBoZW4gRmFycmVsbCA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJl
Zj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiIHRhcmdldD0iX2JsYW5rIj5zdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1
b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBib3JkZXIt
bGVmdDoxcHggI2NjYyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQpJJ3ZlIHN1Z2dl
c3RlZCBzb21lIHRleHQgZm9yIHRoaXMgaW4gYSBQUiBbMV08YnI+DQpiYXNlZCBvbiB3aGF0IHBl
b3BsZSBoYXZlIHNhaWQgaW4gdGhpcyB0aHJlYWQuPGJyPg0KPGJyPg0KSSdtIHN1cmUgdGhhdCBj
YW4gYmUgZnVydGhlciBpbXByb3ZlZC48YnI+DQo8YnI+DQpJdCBtaWdodCBiZSBubyBoYXJtIHRv
IGFkZCBtb3JlIHBvaW50ZXJzIHRvIHRoYXQ8YnI+DQphcHBlbmRpeCBmcm9tIGVsc2V3aGVyZSBp
biB0aGUgc3BlYywgYW5kL29yIHRvPGJyPg0KYWRkIGEgbGlzdCBvZiB0aGUgdmFyaW91cyBwdWJs
aWMvcHJpdmF0ZSByYW5kb208YnI+DQpudW1iZXJzIHRoYXQgYXJlIG5lZWRlZCB0byB0aGF0IGFw
cGVuZGl4LiAoSSdkIGJlPGJyPg0KaGFwcHkgdG8gZG8gYSBwYXNzIHRvIGlkZW50aWZ5IHRob3Nl
IGlmIGZvbGtzPGJyPg0KYmFzaWNhbGx5IGxpa2UgdGhpcyBraW5kIG9mIGFkZGl0aW9uLik8YnI+
DQo8YnI+DQpJIGFsc28gbmVlZCB0byBmaWd1cmUgb3V0IGhvdyB0byBoYW5kbGUgdGhlPGJyPg0K
cmVmZXJlbmNlIHByb3Blcmx5Oi0pIENhbiBkbyB0aGF0IHRvbW9ycm93Ljxicj4NCjxicj4NCkNo
ZWVycyw8YnI+DQpTLjxicj4NCjxicj4NClsxXSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v
dGxzd2cvdGxzMTMtc3BlYy9wdWxsLzEwNjgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh
bmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnLzx3YnI+dGxzMTMtc3BlYy9wdWxsLzEwNjg8
L2E+PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5f
X19fX19fX19fX19fX19fXzxicj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby90bHM8
L2E+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2
Pg0KDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pjxz
cGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFu
Pjxicj48c3Bhbj5UTFMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJtYWls
dG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2Nr
cXVvdGU+PC9ib2R5PjwvaHRtbD4=

--Apple-Mail-2CE78D37-521C-4F94-9C1A-584DEF991F40--

--Apple-Mail-2D5E2050-55D1-4311-BAB1-6E7A7EA746B5
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw
ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM
aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe
Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN
SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb
sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy
oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4
MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk
jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U
AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd
8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq
hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg
1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4
HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d
Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK
+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC
ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh
Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s
biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8
F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ
KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g
mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01
Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj
ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK
vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew
JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk
hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI
hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL
KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w
DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB
bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne
qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+
BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s
6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M
yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT
AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV
BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw
KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL
ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN
AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p
6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M
F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC
AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME
GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs
Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov
L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t
aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2
oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG
AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l
ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg
Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D
kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1
RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO
Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G
/HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9
Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD
VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM
IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTcwNzI3MjM0MzA1WjAjBgkqhkiG9w0BCQQxFgQULs8mr9Sn4imw
Os90jgAlaGK+qoEwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAAsnVsag15d6EnWPNO/iMLAh2x/Hi8QsgZnKumvC
Hq3tFCbkXz1U6+1bi5JO4uQlHhsuecgddFuZpc0grij03xT+01PNSQAWOh7LNnK+NXiSxa5gqaId
NL+Cv7bfKyOd1uiJvcOTtiwZf4AfoHZ/0gskABMpTKghrruftgRWSEIjY6ii+8AWRBECowvYXvN+
UWgghfjgzSr4Mb/XsXrww5tHC0vfxdtm+cemN2d4oQtch6JcoAiEeF5agU4nrO0nxqd69LYnD1wL
tjS2RMXN+eJNssVdbaE84iXCVh75dadX96riY1pTB1/6ULE4ChmY2fwexXoDr+f4oR8zkS8u5yQA
AAAAAAA=

--Apple-Mail-2D5E2050-55D1-4311-BAB1-6E7A7EA746B5--


From nobody Thu Jul 27 16:51:19 2017
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 DC60F131E89 for ; Thu, 27 Jul 2017 16:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=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 zvAJ_ByKtN4o for ; Thu, 27 Jul 2017 16:51:14 -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 56B66131723 for ; Thu, 27 Jul 2017 16:51:14 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id u207so53896723ywc.3 for ; Thu, 27 Jul 2017 16:51:14 -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=9Pc5Pj9Jv/mHvIjApDzQsoCjb/dnc79Uhka+smgCMNI=; b=R7oOfTtijeFuLffHymAM00ggCraUlVVilBAqs3ny7yTF3sCoGnG3Kx/zaSf0Xmfid+ ysJt4pVdv5A0VOCROQwPEs4t7FKvgTjQQmLCexIdDfd13WglUF9AprmJqWgBfW3hNZSD wDOMVRVOm2YsjFwLZD6vSJtLSPXXEG5/brtsakRjofAdSSCrYLGzvVup8e7LFtCYitWj 85H/0azWR0fZn5QZU/Y8bZC5FaPxGZois7lpuChucTPxAlZYhzw0Msor3vqU/INzR1IW qcTjd6TefBzBQRWhpN+tbJ/ZF5b4nAgHFSYqkBCii+hvxtSwqQW+v3TDgH3ydez9+92W Ss+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9Pc5Pj9Jv/mHvIjApDzQsoCjb/dnc79Uhka+smgCMNI=; b=ps+prYwTYa/7jSiRemUw2i1f6/RZriTT7ljrEFzS3YAOKxz+ntX2mbTMIX0rcAJaO3 Nz6eQCOvKOvMkKeGw3HxqriWAP/FrgYOvWOSQrNz6nxRsLV/ak9sxGDOOElGQy7Xi7dM y3XeaGfU3ZfSNVo4T4j63m8jmxTPG/naWPXD6FVkDf9mfXGqR5nH7XAKbjzf5u/vwJmN hDcjvewuwWxQMp/Ebmr0R8Ohi0LHWoEmGTQVUGEuSTCH5JHgeLvgenNNzndQ+RBVgOYc MLhke+DSxbBr7I7+zk1zFCyuBP2bEtETAQnmE/hFvjpEh0Y52H70fkMymtQY9vXzeGLM ZUrQ==
X-Gm-Message-State: AIVw113/o4jhBwJT18l5xw6ZjLZoS+xFCvF0/KJShEFt4tOQrkzGfepq 3wP41/fs00GQYJKSX+1kKGJsRG4F8Fpzqdk=
X-Received: by 10.37.56.12 with SMTP id f12mr5325114yba.289.1501199473573; Thu, 27 Jul 2017 16:51:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.36.12 with HTTP; Thu, 27 Jul 2017 16:50:32 -0700 (PDT)
In-Reply-To: <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>
From: Eric Rescorla 
Date: Thu, 27 Jul 2017 16:50:32 -0700
Message-ID: 
To: "Blumenthal, Uri - 0553 - MITLL" 
Cc: Dan Brown , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c03e4c25c15a90555553d1b"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 27 Jul 2017 23:51:17 -0000

--94eb2c03e4c25c15a90555553d1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I used the term "separate" here, which was intended to convey this, but if
people think "independent" or something is better, happy to change.

-Ekr


On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL <
uri@ll.mit.edu> wrote:

> Respectfully disagree. Having two cryptographically independent PRNGs, on=
e
> for public data and one for key material, IMHO is a good idea. Of course,
> both should be properly seeded - but that's a different issue.
>
> Regards,
> Uri
>
> Sent from my iPhone
>
> On Jul 27, 2017, at 19:33, Dan Brown  wrote:
>
>
> I don't think 2 CSPRNGs is a good idea.
>
> Wasn=E2=80=99t there a few years back some RSA keys with separate p and q=
,
> generated independently leading to an attack...
>
> Here if the seeds to initialize the RNGS are related, or one is weak, or
> worst if the seed is a raw source that doesn=E2=80=99t change in the mome=
nts
> between the two CSPRNG inits, that'd be bad, even if the CSPRNGs were goo=
d.
> *From: *Eric Rescorla
> *Sent: *Thursday, July 27, 2017 6:34 PM
> *To: *Stephen Farrell
> *Cc: *tls@ietf.org
> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's
>
> Spec updated here;
> https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc42
> 942af9ca77
>
> -Ekr
>
>
> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell <
> stephen.farrell@cs.tcd.ie> wrote:
>
>>
>> I've suggested some text for this in a PR [1]
>> based on what people have said in this thread.
>>
>> I'm sure that can be further improved.
>>
>> It might be no harm to add more pointers to that
>> appendix from elsewhere in the spec, and/or to
>> add a list of the various public/private random
>> numbers that are needed to that appendix. (I'd be
>> happy to do a pass to identify those if folks
>> basically like this kind of addition.)
>>
>> I also need to figure out how to handle the
>> reference properly:-) Can do that tomorrow.
>>
>> Cheers,
>> S.
>>
>> [1] https://github.com/tlswg/tls13-spec/pull/1068
>>
>>
>> _______________________________________________
>> 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
>
>

--94eb2c03e4c25c15a90555553d1b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    I used the term "separate" here, which was inten=
ded to convey this, but if people think "independent" or somethin=
g is better, happy to change.

    -Ekr

    <=
/div>

    On Thu, Jul =
27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL <<=
a href=3D"mailto:uri@ll.mit.edu" target=3D"_blank">uri@ll.mit.edu> wrote:
    Respe=
ctfully disagree. Having two cryptographically independent PRNGs, one for p=
ublic data and one for key material, IMHO is a good idea. Of course, both s=
hould be properly seeded - but that's a different issue.

    Regards=
,
    Uri

    Sent from my iPhone

    On Jul 27, 2017, at 19:33, Dan Brown <danibrown@blackberry.com=
> wrote:

    




    

    

    

    
I don't think 2 CSPRNGs is a good idea.
    

    

    

    

    
Wasn=E2=80=99t there a few years back some RSA keys with separate p and q, =
generated independently leading to an attack...
    

    

    

    

    
Here if the seeds to initialize the RNGS are related, or one is weak, or wo=
rst if the seed is a raw source that doesn=E2=80=99t change in the moments =
between the two CSPRNG inits, that'd be bad, even if the CSPRNGs were g=
ood.
    

    


    


    

    From: Eric Rescorla
    

    Sent: Thursday, July 27, 2017 6:34 PM
    

    To: Stephen Farrell
    


    Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
    

    
    		

    
    

    

    

    

    

    



    

    On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell=
 
<stephen.=
farrell@cs.tcd.ie> wrote:
    

    

    
I've suggested some text for this in a PR [1]
    
based on what people have said in this thread.
    

    
I'm sure that can be further improved.
    

    
It might be no harm to add more pointers to that
    
appendix from elsewhere in the spec, and/or to
    
add a list of the various public/private random
    
numbers that are needed to that appendix. (I'd be
    
happy to do a pass to identify those if folks
    
basically like this kind of addition.)
    

    
I also need to figure out how to handle the
    
reference properly:-) Can do that tomorrow.
    

    
Cheers,
    
S.
    

    
[1] 
https://github.com/tlswg/tls13-spec/pull/1068
    

    

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

    

    

    

    

    

    



    ___________________=
____________________________
    TLS mailing listTLS@ietf.org<=
/span>
    https://www.ietf.org/mailman/listinfo/tls
    <=
/div>

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


    

--94eb2c03e4c25c15a90555553d1b--


From nobody Fri Jul 28 01:47:11 2017
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 7B0CC1322AD for ; Fri, 28 Jul 2017 01:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q47BXFikVadX for ; Fri, 28 Jul 2017 01:47:06 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51391322AC for ; Fri, 28 Jul 2017 01:47:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AFB4CBE2D; Fri, 28 Jul 2017 09:47:03 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsRtUuz9zApc; Fri, 28 Jul 2017 09:47:01 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A7855BE38; Fri, 28 Jul 2017 09:47:01 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1501231621; bh=L2OHJ1PCJELRPwuNqbH6XCNmaJ+AMu7X+lxMV0l3/So=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=dXJYCUquAQhnHBqQ6vE29KPtEC93hu0wK9S1CdGokRutT8n6c4Y6a2hdMj42o/2/h sm3Y239a0SDMqA4cIf69JyfFKRg8qUh/t6cuvQ3j5DS4U+R/A94AtWcaHs11pWG2mT 1UtepAUhrzBj97+ULWDSXh7od1HZ9ESnl2CcoG0c=
From: Stephen Farrell 
To: Eric Rescorla , "Blumenthal, Uri - 0553 - MITLL" 
Cc: "tls@ietf.org" 
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu> 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie>
Date: Fri, 28 Jul 2017 09:47:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NKJET95FdPP4PuFHqX6hRAX6QkUNAa6K3"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 08:47:09 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--NKJET95FdPP4PuFHqX6hRAX6QkUNAa6K3
Content-Type: multipart/mixed; boundary="kqV8OShfpJcoMnAKUbB58cqovhHH6Rvoe";
 protected-headers="v1"
From: Stephen Farrell 
To: Eric Rescorla ,
 "Blumenthal, Uri - 0553 - MITLL" 
Cc: "tls@ietf.org" 
Message-ID: <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie>
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
References: 
 <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>
 
 <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>
 
 <20170727233335.8573013.91860.16216@blackberry.com>
 <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>
 
In-Reply-To: 

--kqV8OShfpJcoMnAKUbB58cqovhHH6Rvoe
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Hiya,

On 28/07/17 00:50, Eric Rescorla wrote:
> I used the term "separate" here, which was intended to convey this, but=
 if
> people think "independent" or something is better, happy to change.

I think your change is a fine improvement over -21, thanks.
(And my suggested text was as imperfect as I usually manage:-)

I'm not clear if implementers will or will not get the
ramifications of "separate" (or "independent"), so I
think we ought describe (or reference) at least one way
in which that separation can be achieved.

I also think we ought at least RECOMMEND separate CSPRNGs.
I'd prefer a MUST myself but since there's no one good
way we can describe to achieve the effect that'd work in
all cases, I don't think we can say MUST.

Cheers,
S.


>=20
> -Ekr
>=20
>=20
> On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL <
> uri@ll.mit.edu> wrote:
>=20
>> Respectfully disagree. Having two cryptographically independent PRNGs,=
 one
>> for public data and one for key material, IMHO is a good idea. Of cour=
se,
>> both should be properly seeded - but that's a different issue.
>>
>> Regards,
>> Uri
>>
>> Sent from my iPhone
>>
>> On Jul 27, 2017, at 19:33, Dan Brown  wrote:=

>>
>>
>> I don't think 2 CSPRNGs is a good idea.
>>
>> Wasn=E2=80=99t there a few years back some RSA keys with separate p an=
d q,
>> generated independently leading to an attack...
>>
>> Here if the seeds to initialize the RNGS are related, or one is weak, =
or
>> worst if the seed is a raw source that doesn=E2=80=99t change in the m=
oments
>> between the two CSPRNG inits, that'd be bad, even if the CSPRNGs were =
good.
>> *From: *Eric Rescorla
>> *Sent: *Thursday, July 27, 2017 6:34 PM
>> *To: *Stephen Farrell
>> *Cc: *tls@ietf.org
>> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's
>>
>> Spec updated here;
>> https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acb=
c42
>> 942af9ca77
>>
>> -Ekr
>>
>>
>> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell <
>> stephen.farrell@cs.tcd.ie> wrote:
>>
>>>
>>> I've suggested some text for this in a PR [1]
>>> based on what people have said in this thread.
>>>
>>> I'm sure that can be further improved.
>>>
>>> It might be no harm to add more pointers to that
>>> appendix from elsewhere in the spec, and/or to
>>> add a list of the various public/private random
>>> numbers that are needed to that appendix. (I'd be
>>> happy to do a pass to identify those if folks
>>> basically like this kind of addition.)
>>>
>>> I also need to figure out how to handle the
>>> reference properly:-) Can do that tomorrow.
>>>
>>> Cheers,
>>> S.
>>>
>>> [1] https://github.com/tlswg/tls13-spec/pull/1068
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>=20
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>=20



--kqV8OShfpJcoMnAKUbB58cqovhHH6Rvoe--

--NKJET95FdPP4PuFHqX6hRAX6QkUNAa6K3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZevoEAAoJEC88hzaAX42iqrAH/1GhoQgb7PjH9lb4j7LdKZGt
kOYrp2ox1rj++rmBjnKzHrIYunq/UIE67HmLqeUhnqIXAdKvyedRQeGXXOp9D9Xt
ZB1xaAfXnCem6878qG0gtrvYhDvRpSU2oJRro8cT5xJZ3/TVSoGFqRIW0D8TOblx
JPuEtOf07Akrwyzo3ocQwcVPU+QDmssXksIW0FZPXZRd2Ap3SXEJOiyHVLBWxmL5
SM9BtuKilq3G/hIdP163oOZT+vXnbGb5q45UYekSlZPd6RBvuX5CrshbTpj1fOb4
gg9AcvmSqCSY1QMdewGHXYkygEzIwRchBGenARVT1Q9AzMBmCOuY75kOOv7yTMs=
=5/uS
-----END PGP SIGNATURE-----

--NKJET95FdPP4PuFHqX6hRAX6QkUNAa6K3--


From nobody Fri Jul 28 04:59:13 2017
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 18248131C27 for ; Fri, 28 Jul 2017 04:59: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, 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 jM5AL_9lM1Fl for ; Fri, 28 Jul 2017 04:59:09 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59455126DEE for ; Fri, 28 Jul 2017 04:59:09 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id c74so89120079iod.4 for ; Fri, 28 Jul 2017 04:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=HK6hdZ0aEOEl/WDkH2PaB9PSCVU8S8GqCTGUN73jIwA=; b=FzO7cYX3IcOY8LVhuVFQkavzx9Bpk/D796bST3gO4h9waF6A1CfBxID6RkDNmfLewI bVkw9AjZP1dDa9n0MI5+Dteq/l4PHRujBcRVX1EIYj/jfslyPO2leDNg0zGgv0wPZJ2W IbzYvkvBdMVr+zhX+AZfP/Deu7JmnDhatfcvzAHiRf6XP9ePOHceFTXucqJJagFVy/Po hecHUNKzPXHyRkZ/0SNlDwbI+4/OZkw9giQY8ZE+C1GayS8hoJF+/4wP8owkkwP3H39V HHIpOMVXeJA53FFsnocWhI5uS7cj2RJhSk69PqLz7PoiZzNEQky83/iMkQPFMafjkope ZWvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HK6hdZ0aEOEl/WDkH2PaB9PSCVU8S8GqCTGUN73jIwA=; b=XUq/2Bfl3AYlPiiGjeqF0gzxXVTypr5nMk/9+6fDxEOTAvfbc7x4w0/LGgntD0MlUn QVnBnVnA+a/BB49HM4epTAwimXHsh+t+tuYtyP8quvVFpMm8eHtb2+++xILoqoI9XgsA xa761Pf1c6dR0gs1sCCNnGlVvN+HfIFFUSeDI6S0T3w8kgWneU6u0BWMVUbLi4yZm3D+ SORwD793Sc22qoSaKhk31bXVEkcd1f8NyWP159oJw0n+mCKM/B9tyu423PQ3kQA8kv5i h7PJkR+nL9LVe5J1FEVJ3EmSniGSvX1y2giNnFWQelLHdfpKaB3uyOGoNScx8G2m/Hho kvgg==
X-Gm-Message-State: AIVw113znresUawZ2lCXCL5LCht3ceoytiWbWVO3rNCkZoETtmJWBlIr c1l/ZkPkBWLEIJqtsoCoWIyGJga88hZf++E=
X-Received: by 10.107.201.65 with SMTP id z62mr6661486iof.74.1501243148594; Fri, 28 Jul 2017 04:59:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.42 with HTTP; Fri, 28 Jul 2017 04:59:08 -0700 (PDT)
From: Martin Thomson 
Date: Fri, 28 Jul 2017 21:59:08 +1000
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [TLS] NamedGroup 0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 11:59:11 -0000

Just doing some code review and noticed that we don't allocate a value
for a NamedGroup of 0.  Knowing the morass of code out there that does
TLS, this is probably used as a sentinel value of some sort somewhere
(the code I was reviewing did exactly that).

Can we reserve this value?

https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/26
https://github.com/tlswg/tls13-spec/pull/1069


From nobody Fri Jul 28 05:30:18 2017
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 A271D13211C for ; Fri, 28 Jul 2017 05:30:16 -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, HTML_MESSAGE=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=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 j9U90qkxHPzi for ; Fri, 28 Jul 2017 05:30:15 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E8A9613200E for ; Fri, 28 Jul 2017 05:30:14 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6SCQt6I012609; Fri, 28 Jul 2017 13:30:12 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=L6+7h/Wo4mD95+SkI1hRrzNbAASg4v6Q9K8oNdT9k5Q=; b=EEKn4B/w/8Ph7GsKeCWFOrS0lWmnQaF5bOfk1USa/Np+Cf3sQj0UAQD/NcsX4RtRnXbL hi0vq5mDammn37H2ST0Aytf+3Vdax1exdxPtsuASLHwYL5bOAKZWBeOFyNiqnXWXRGvk pNzX5Sw9NOEJSsFo92hKcr9aUr1bet7QUG30QHHyYCI4/mAh0Zbov1SBS07CE7Muxjr1 fX33l9HbrwAljX39Q+q9Rt5VRB8hHNdsPtUnReaoyoJorwwQjB7NJ1Bng4nAL0QtRWnP pqXNRKM2ILQQfGp9k7bLDRJxpGKXu3rOANURQFjiSfKWFrbnFThuDKajfhXiB6Vk579j Gg== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2bytjfjmey-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jul 2017 13:30:12 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6SCRJpJ023332; Fri, 28 Jul 2017 08:30:11 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2byq379s18-1; Fri, 28 Jul 2017 08:30:10 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 7CA3820066; Fri, 28 Jul 2017 06:30:08 -0600 (MDT)
To: Martin Thomson , "" 
References: 
From: Benjamin Kaduk 
Message-ID: <87b89018-31a5-ac0e-cecb-0ce244fe08bf@akamai.com>
Date: Fri, 28 Jul 2017 07:30:07 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D5D976547EC38C075A3CB070"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-28_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707280193
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-28_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707280194
Archived-At: 
Subject: Re: [TLS] NamedGroup 0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 12:30:17 -0000

This is a multi-part message in MIME format.
--------------D5D976547EC38C075A3CB070
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/28/2017 06:59 AM, Martin Thomson wrote:
> Just doing some code review and noticed that we don't allocate a value
> for a NamedGroup of 0.  Knowing the morass of code out there that does
> TLS, this is probably used as a sentinel value of some sort somewhere
> (the code I was reviewing did exactly that).
>
> Can we reserve this value?
>
> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/26
> https://github.com/tlswg/tls13-spec/pull/1069
>

Sounds like a good idea -- let's do it.

-Ben

--------------D5D976547EC38C075A3CB070
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 07/28/2017 06:59 AM, Martin Thomson wrote:
    
    
    
      
    Just doing some code review and noticed that we don't allocate a value
for a NamedGroup of 0.  Knowing the morass of code out there that does
TLS, this is probably used as a sentinel value of some sort somewhere
(the code I was reviewing did exactly that).

Can we reserve this value?

https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/26
https://github.com/tlswg/tls13-spec/pull/1069


    
    
    
    
    
    Sounds like a good idea -- let's do it.
    
    
    
    -Ben
    
  


--------------D5D976547EC38C075A3CB070--


From nobody Fri Jul 28 05:41:17 2017
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 B78D8131FF0 for ; Fri, 28 Jul 2017 05:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 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=-0.001, 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 MXPnRuMEIFHq for ; Fri, 28 Jul 2017 05:41:08 -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 5858E131FCC for ; Fri, 28 Jul 2017 05:41:08 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BDA37C0E8D27 for ; Fri, 28 Jul 2017 12:41:07 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BDA37C0E8D27
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com
Received: from pintsize.usersys.redhat.com (ovpn-200-20.brq.redhat.com [10.40.200.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5FC9077E87 for ; Fri, 28 Jul 2017 12:41:07 +0000 (UTC)
From: Hubert Kario 
To: tls@ietf.org
Date: Fri, 28 Jul 2017 14:41:01 +0200
Message-ID: <1985136.n8kX8SZK3z@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart8088793.mWpvxuiYse"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 28 Jul 2017 12:41:07 +0000 (UTC)
Archived-At: 
Subject: [TLS] ClientHello1[truncated] - definitions?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 12:41:15 -0000

--nextPart8088793.mWpvxuiYse
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

(looking at -21)

Section 4.2.10.2 PSK binder refers to ClientHello1[truncated] as the value=
=20
that needs to be used as parameter to Transcript-Hash.

Neither 'truncated' nor 'ClientHello1' are formally defined.

ClientHello1 can be guessed (given text in 4.4.1) as the first ClientHello=
=20
that the client sends. But the value of 'truncated' is an enigma.
=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 115, 612 00  Brno, Czech Republic
--nextPart8088793.mWpvxuiYse
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

iQIcBAABCgAGBQJZezDdAAoJEJKo0bgB0vX1JPsP/jcdSJVOUkOBP2li7rQbcYma
ZbRKApDQXbCC5k5roXPOiPtzEMKrbc3apIFl5eydloYH9lQzk3cNhPQiyxaxnTZ3
YGLhkktIWk1Xu0E2iPveQ4Gg2xaKLzfv7nQs1Zi39SrF2Nl0y2ZGyN+DzM+7dm0u
gFCWW4lpVrfJzXITGQInGFhn61m7FtEbytg156ttZdRaUYrNWIx1ojFQh79dLIC6
Gmlwvryg94bLL1UfiMhkCLewPYGAU9BebCtZC/ijJuFRUr+xI6dmBnKg+xoQOZwU
cDK0+609wLsa7PD3Z1l4Mm1MW/OjPBZGNegpHTGX7laQcRYQtqNBXlwSBnlOw0nd
VGpLbWEe0lSfOueHhgacpJkMQ8ifdm+swAdnWMrGKdb1S2RrQwP/7RjVfq2g2YHQ
KRsj8EPBiF7SZxK7VfkMkPrGfwr2enByq91sZU7L5OOlB8DXD5kF9xgmDdLkNHC0
YfSNMtlIPOR54SVtFbsPVYKVKctkTCXWSjkomlN6OxQuEcKRhogtT8qZPZieJ4wv
oWTVkqOr4Bd1tu5T189xfpwClIUX8aLjw7PXXLeAtgNuwTlcEpiPyw1pGVJC8yIk
o5WUkWv5VwLmULDp1zKMYtzPwtmf2UX/i0eqqZSz0uYEStNtQ4KZPnNbVDWpujyG
0enMAiwBWqZEm7H6Tm/K
=R6MP
-----END PGP SIGNATURE-----

--nextPart8088793.mWpvxuiYse--


From nobody Fri Jul 28 05:45:48 2017
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 A65BC132126 for ; Fri, 28 Jul 2017 05:45: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, 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=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 0vKI861jyJ_r for ; Fri, 28 Jul 2017 05:45:44 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 B6FE0131FF0 for ; Fri, 28 Jul 2017 05:45:44 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6SCfjPH011317; Fri, 28 Jul 2017 13:45:43 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=bQsv4O1FELsGrrWenKlCylGkxWzNZXgiN71i64ZZIuQ=; b=B8sZ2f2AEQawI4dBWYZNEgu28qaBQBY8BkpCvOig/FiEWDQytOBnqVQHYibH6WnXToOd 3+fP+fIPheT3cju79NGg1V0/mK/ib7lZNflmk+JEGHc5nIo0ql/YZ9Own3pvH6lWijzR UkY+on6NZZ710bU9i+HkwEiN3+cTen15ecF65eHhGjuyd4DGeiBkgQAi3+B6BVxxnSP/ HR2UXN4IjO5njhC+yLWUZQl0F8k4mIgAOyv8LI2U098x6CTUMezz5PtQdbMwtiba7ONK ljw++Zj9CIRZS9CNH6mXfORJzDwyxm3Gm2VG7/NflaKzl3p97vz8pjKohjSLc0BNCaDf rg== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bxjb4vc2q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jul 2017 13:45:42 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6SCgKiB005171; Fri, 28 Jul 2017 08:45:41 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bv21v5m99-1; Fri, 28 Jul 2017 08:45:41 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 06B711FC88; Fri, 28 Jul 2017 12:45:40 +0000 (GMT)
To: Hubert Kario , tls@ietf.org
References: <1985136.n8kX8SZK3z@pintsize.usersys.redhat.com>
From: Benjamin Kaduk 
Message-ID: 
Date: Fri, 28 Jul 2017 07:45:40 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <1985136.n8kX8SZK3z@pintsize.usersys.redhat.com>
Content-Type: multipart/alternative; boundary="------------502BB3BAE821CEFD976D9B81"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-28_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707280197
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-28_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707280197
Archived-At: 
Subject: Re: [TLS] ClientHello1[truncated] - definitions?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 12:45:47 -0000

This is a multi-part message in MIME format.
--------------502BB3BAE821CEFD976D9B81
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 07/28/2017 07:41 AM, Hubert Kario wrote:
> (looking at -21)
>
> Section 4.2.10.2 PSK binder refers to ClientHello1[truncated] as the value 
> that needs to be used as parameter to Transcript-Hash.
>
> Neither 'truncated' nor 'ClientHello1' are formally defined.
>
> ClientHello1 can be guessed (given text in 4.4.1) as the first ClientHello 
> that the client sends. But the value of 'truncated' is an enigma.
>

Just a few paragraphs prior is:

   [...] Each entry in the binders list is computed as an HMAC
   over a transcript hash (see Section 4.4.1
) containing a partial
   ClientHello up to and including the PreSharedKeyExtension.identities
   field.  That is, it includes all of the ClientHello but not the
   binders list itself.  The length fields for the message (including
   the overall length, the length of the extensions block, and the
   length of the "pre_shared_key" extension) are all set as if binders
   of the correct lengths were present.

Please say more about how this could be made into a more-formal definition.

-Ben


--------------502BB3BAE821CEFD976D9B81
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 07/28/2017 07:41 AM, Hubert Kario wrote:
    
    
    
      
    (looking at -21)

Section 4.2.10.2 PSK binder refers to ClientHello1[truncated] as the value 
that needs to be used as parameter to Transcript-Hash.

Neither 'truncated' nor 'ClientHello1' are formally defined.

ClientHello1 can be guessed (given text in 4.4.1) as the first ClientHello 
that the client sends. But the value of 'truncated' is an enigma.

    
      
    
    
    
    
    
    Just a few paragraphs prior is:
    
    
    
    
       [...] Each entry in the binders list is computed as an HMAC
   over a transcript hash (see Section 4.4.1) containing a partial
   ClientHello up to and including the PreSharedKeyExtension.identities
   field.  That is, it includes all of the ClientHello but not the
   binders list itself.  The length fields for the message (including
   the overall length, the length of the extensions block, and the
   length of the "pre_shared_key" extension) are all set as if binders
   of the correct lengths were present.

Please say more about how this could be made into a more-formal definition.

-Ben

    
  


--------------502BB3BAE821CEFD976D9B81--


From nobody Fri Jul 28 06:37:40 2017
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 B78011201F2 for ; Fri, 28 Jul 2017 06:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 8Tz2NUj_Jacx for ; Fri, 28 Jul 2017 06:37:36 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F1A126E3A for ; Fri, 28 Jul 2017 06:37:36 -0700 (PDT)
Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 09:37:34 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0319.002; Fri, 28 Jul 2017 09:37:34 -0400
From: Dan Brown 
To: Stephen Farrell , Eric Rescorla ,  "Blumenthal, Uri - 0553 - MITLL" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+yUHLG+hMivEObnVpzx6wh/KJjeS0AgAC0BYCAAI15AIAAcHiAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDwAgAANUQCAABPSAIAABQGAgAAkyoCAAYN2AP//zaLlgABFtACAAAITAIAAleMAgAADerA=
Date: Fri, 28 Jul 2017 13:37:33 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie>
In-Reply-To: <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.249]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 13:37:40 -0000

SSB0cnkgYmVsb3cgdG8gYmV0dGVyIGV4cGxhaW4gbXkgcG9pbnRzIGFnYWluc3Qgc2VwYXJhdGVk
IHB1YmxpYyBhbmQgcHJpdmF0ZSBDU1BSTkcgaW5zdGFuY2VzLiANCg0KUGVyaGFwcyB0aGUgZWFz
aWVzdCB3YXkgdG8gZ2V0ICJpbmRlcGVuZGVudCIgc2VlZHMgZm9yIHRoZSB0d28gaW5zdGFuY2Vz
IG9mIGEgQ1NQUk5HLCBpcyB0byB1c2UgYSB0aGlyZCBDU1BSTkcgaW5zdGFuY2UgdG8gZ2VuZXJh
dGUgdGhlIHNlZWRzLiAgQnV0IHRoZW4gdGhlIHByb2JsZW0gYXJpc2VzIGFnYWluLCBpZiB0aGUg
MyBDU1BSTkdzIGFyZSBiYWQgZW5vdWdoLCAoMD1zZWVkZXIsIDE9cHVibGljLCAyPXByaXZhdGUp
LCB0aGVyZSBpcyBhIHJpc2sgdGhhdDoNCiANClB1YmxpY19ub25jZT1vdXRwdXQxPT5zZWVkMT1v
dXRwdXQwX2Zvcl8xPT5zZWVkMD0+b3V0cHV0MF9mb3JfMj1zZWVkMj0+b3V0cHV0XzI9cHJpdmF0
ZV9rZXk9VExTX2luc2VjdXJpdHkuDQoNCkluIHNob3J0LCBnZW5lcmFsbHkgc3BlYWtpbmcsIHRo
cmVlIGJhZCBDU1BSTkdzIGRvIG5vdCBjb21iaW5lIGVhc2lseSBpbnRvIDEgZ29vZCBDU1BSTkcu
ICANCg0KKEknbSBub3QgeWV0IHN1cmUgaWYgdGhpcyBhdHRhY2sgb24gdGhyZWUgQ1NQUk5HcyBj
b21iaW5lZCBhcHBsaWVzIHRvIER1YWxfRUMsIHNpbmNlIGl0IG1heSBkbyBzb21ldGhpbmcgaGFz
aC1saWtlIHRvIHRoZSBzZWVkIChJIGZvcmdvdCBkZXRhaWxzKSwgYW5kIGFsc28gb3V0cHV0IGxl
YWtzIHRoZSBuZXh0IHN0YXRlLCBub3QgdGhlIHByZXZpb3VzIHN0YXRlLCBhcyBJIHJlY2FsbCwg
c28gdGhhdCBtaWdodCBicmVhayB0aGUgY2hhaW4gYWJvdmUuKQ0KDQpUaGUgYWx0ZXJuYXRpdmUg
dG8gYSAzcmQgQ1NQUk5HIGlzIHRvIGdldCB0aGUgc2VlZHMgZnJvbSBkaXJlY3RseSBmcm9tIGEg
cmF3IGVudHJvcHkgc291cmNlLiBJbiB0aGF0IGNhc2UsIGtlZXAgaW4gbWluZCB0aGF0IG9uZSBv
ZiB0aGUgcHVycG9zZXMgb2YgQ1NQUk5HcyBpcyB0aGF0IHJhdyBlbnRyb3B5IHNvdXJjZXMgYXJl
IHVucmVsaWFibGUgKHNvbWV0aW1lcyBzdGFsbCwgZXRjLiBbcmVmZXJlbmNlcyB0byBiZSBhZGRl
ZF0pIGFuZCBnZW5lcmFsbHkgd2VhayBvbiB0aGUgaW5kZXBlbmRlbmNlICh0aGV5IGFyZSBub24t
dW5pZm9ybSwgaGVuY2UgaGF2ZSBjb3JyZWxhdGlvbnMpLiAgQ1NQUk5HcyBhcmUgc3VwcG9zZWQg
dG8gY29ycmVjdCB0aGVzZSBkZWZpY2llbmNpZXMsIGFtb25nIG90aGVyIHRoaW5ncy4gIFNvLCBp
ZiB0aGUgMiBzZWVkcyBhcmUgZ2VuZXJhdGVkIGRpcmVjdGx5IGZyb20gYSByYXcgZW50cm9weSBz
b3VyY2VzICh3aXRob3V0IGEgQ1NQUk5HKSwgdHdvIHRoaW5ncyBtYXkgZ28gd3JvbmcuIEZpcnN0
LCBkZXJpdmluZyBvbmUgc2VlZCBmcm9tIHRoZSBvdGhlciBtaWdodCBiZSBmZWFzaWJsZSBiZWNh
dXNlIG9mIG5vbi11bmlmb3JtaXR5LiBBIGJhZCBDU1BSTkcgbWlnaHQgZW5hYmxlIHRoaXMgdGhp
cyB0byBiZSBleHBsb2l0ZWQsIGJ5IGZpbmRpbmcgb25lIHNlZWQgZnJvbSB0aGUgb3RoZXIuICBT
ZWNvbmQsIGlmIHRoZSBlbnRyb3B5IHNvdXJjZSBzdGFsbHMgKGRvd24gYSB0cmlja2xlIG9mIGxv
dyBlbnRyb3B5KSwgYmV0d2VlbiB0b28gY2xvc2Ugc2VlZCByZXF1ZXN0cyAtIGFjY2lkZW50YWxs
eSAtIHRoZW4gZXZlbiBhIGdvb2QgQ1NQUk5HIGNvdWxkbid0IGNvcGUuDQoNCk1heWJlLCBhbGwg
dGhpcyB3b3VsZG4ndCBiZSBhIHByb2JsZW0gb24gbWFueSBoaWdoZXIgZW5kIHN5c3RlbXMsIHdp
dGggaGlnaCBlbnRyb3B5LCBzbyBteSBjb25jZXJuIGlzIGxvd2VyIGVuZCBzeXN0ZW1zLCBhbmQg
YWxzbyB1bm5lY2Vzc2FyeSBjb21wbGljYXRpb25zIG9mIG1haW50YWluaW5nIG11bHRpcGxlIGJh
ZCBDU1BSTkdzLCBwb3RlbnRpYWxseSB0byBubyBhdmFpbC4gIA0KDQpGaW5hbGx5LCBvbiBzeXN0
ZW1zIHdpdGggYSBsaW51eC1zdHlsZSBpbnRlcmZhY2UsIC9kZXYvdXJhbmRvbSBhbmQgL2Rldi9y
YW5kb20gY291bGQgYmUgdXNlZCBhcyB0aGUgdHdvIENTUFJOR3Mgb24gc29tZSBzeXN0ZW1zIChv
ciBzZWVkIHNvdXJjZXMpLCBhbHRob3VnaCBJIHRoaW5rIG9uZSBvZiB0aGVzZSBpcyBub3cgZGVw
cmVjYXRlZD8gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUTFMgW21haWx0
bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXBoZW4gRmFycmVsbA0KU2Vu
dDogRnJpZGF5LCBKdWx5IDI4LCAyMDE3IDQ6NDcgQU0NClRvOiBFcmljIFJlc2NvcmxhIDxla3JA
cnRmbS5jb20+OyBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEwgPHVyaUBsbC5taXQuZWR1
Pg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIDMyIGJ5dGUgcmFuZG9tcyBp
biBUTFMxLjMgaGVsbG8ncw0KDQoNCkhpeWEsDQoNCk9uIDI4LzA3LzE3IDAwOjUwLCBFcmljIFJl
c2NvcmxhIHdyb3RlOg0KPiBJIHVzZWQgdGhlIHRlcm0gInNlcGFyYXRlIiBoZXJlLCB3aGljaCB3
YXMgaW50ZW5kZWQgdG8gY29udmV5IHRoaXMsIA0KPiBidXQgaWYgcGVvcGxlIHRoaW5rICJpbmRl
cGVuZGVudCIgb3Igc29tZXRoaW5nIGlzIGJldHRlciwgaGFwcHkgdG8gY2hhbmdlLg0KDQpJIHRo
aW5rIHlvdXIgY2hhbmdlIGlzIGEgZmluZSBpbXByb3ZlbWVudCBvdmVyIC0yMSwgdGhhbmtzLg0K
KEFuZCBteSBzdWdnZXN0ZWQgdGV4dCB3YXMgYXMgaW1wZXJmZWN0IGFzIEkgdXN1YWxseSBtYW5h
Z2U6LSkNCg0KSSdtIG5vdCBjbGVhciBpZiBpbXBsZW1lbnRlcnMgd2lsbCBvciB3aWxsIG5vdCBn
ZXQgdGhlIHJhbWlmaWNhdGlvbnMgb2YgInNlcGFyYXRlIiAob3IgImluZGVwZW5kZW50IiksIHNv
IEkgdGhpbmsgd2Ugb3VnaHQgZGVzY3JpYmUgKG9yIHJlZmVyZW5jZSkgYXQgbGVhc3Qgb25lIHdh
eSBpbiB3aGljaCB0aGF0IHNlcGFyYXRpb24gY2FuIGJlIGFjaGlldmVkLg0KDQpJIGFsc28gdGhp
bmsgd2Ugb3VnaHQgYXQgbGVhc3QgUkVDT01NRU5EIHNlcGFyYXRlIENTUFJOR3MuDQpJJ2QgcHJl
ZmVyIGEgTVVTVCBteXNlbGYgYnV0IHNpbmNlIHRoZXJlJ3Mgbm8gb25lIGdvb2Qgd2F5IHdlIGNh
biBkZXNjcmliZSB0byBhY2hpZXZlIHRoZSBlZmZlY3QgdGhhdCdkIHdvcmsgaW4gYWxsIGNhc2Vz
LCBJIGRvbid0IHRoaW5rIHdlIGNhbiBzYXkgTVVTVC4NCg0KQ2hlZXJzLA0KUy4NCg0KDQo+IA0K
PiAtRWtyDQo+IA0KPiANCj4gT24gVGh1LCBKdWwgMjcsIDIwMTcgYXQgNDo0MyBQTSwgQmx1bWVu
dGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMIDwgDQo+IHVyaUBsbC5taXQuZWR1PiB3cm90ZToNCj4g
DQo+PiBSZXNwZWN0ZnVsbHkgZGlzYWdyZWUuIEhhdmluZyB0d28gY3J5cHRvZ3JhcGhpY2FsbHkg
aW5kZXBlbmRlbnQgDQo+PiBQUk5Hcywgb25lIGZvciBwdWJsaWMgZGF0YSBhbmQgb25lIGZvciBr
ZXkgbWF0ZXJpYWwsIElNSE8gaXMgYSBnb29kIA0KPj4gaWRlYS4gT2YgY291cnNlLCBib3RoIHNo
b3VsZCBiZSBwcm9wZXJseSBzZWVkZWQgLSBidXQgdGhhdCdzIGEgZGlmZmVyZW50IGlzc3VlLg0K
Pj4NCj4+IFJlZ2FyZHMsDQo+PiBVcmkNCj4+DQo+PiBTZW50IGZyb20gbXkgaVBob25lDQo+Pg0K
Pj4gT24gSnVsIDI3LCAyMDE3LCBhdCAxOTozMywgRGFuIEJyb3duIDxkYW5pYnJvd25AYmxhY2ti
ZXJyeS5jb20+IHdyb3RlOg0KPj4NCj4+DQo+PiBJIGRvbid0IHRoaW5rIDIgQ1NQUk5HcyBpcyBh
IGdvb2QgaWRlYS4NCj4+DQo+PiBXYXNu4oCZdCB0aGVyZSBhIGZldyB5ZWFycyBiYWNrIHNvbWUg
UlNBIGtleXMgd2l0aCBzZXBhcmF0ZSBwIGFuZCBxLCANCj4+IGdlbmVyYXRlZCBpbmRlcGVuZGVu
dGx5IGxlYWRpbmcgdG8gYW4gYXR0YWNrLi4uDQo+Pg0KPj4gSGVyZSBpZiB0aGUgc2VlZHMgdG8g
aW5pdGlhbGl6ZSB0aGUgUk5HUyBhcmUgcmVsYXRlZCwgb3Igb25lIGlzIHdlYWssIA0KPj4gb3Ig
d29yc3QgaWYgdGhlIHNlZWQgaXMgYSByYXcgc291cmNlIHRoYXQgZG9lc27igJl0IGNoYW5nZSBp
biB0aGUgDQo+PiBtb21lbnRzIGJldHdlZW4gdGhlIHR3byBDU1BSTkcgaW5pdHMsIHRoYXQnZCBi
ZSBiYWQsIGV2ZW4gaWYgdGhlIENTUFJOR3Mgd2VyZSBnb29kLg0KPj4gKkZyb206ICpFcmljIFJl
c2NvcmxhDQo+PiAqU2VudDogKlRodXJzZGF5LCBKdWx5IDI3LCAyMDE3IDY6MzQgUE0NCj4+ICpU
bzogKlN0ZXBoZW4gRmFycmVsbA0KPj4gKkNjOiAqdGxzQGlldGYub3JnDQo+PiAqU3ViamVjdDog
KlJlOiBbVExTXSAzMiBieXRlIHJhbmRvbXMgaW4gVExTMS4zIGhlbGxvJ3MNCj4+DQo+PiBTcGVj
IHVwZGF0ZWQgaGVyZTsNCj4+IGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL2Nv
bW1pdC80NjVkZTBlMTg5YjJiNTkwOTBkMGVhYzBhYw0KPj4gYmM0Mg0KPj4gOTQyYWY5Y2E3Nw0K
Pj4NCj4+IC1Fa3INCj4+DQo+Pg0KPj4gT24gV2VkLCBKdWwgMjYsIDIwMTcgYXQgNDoyNyBQTSwg
U3RlcGhlbiBGYXJyZWxsIDwgDQo+PiBzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90ZToN
Cj4+DQo+Pj4NCj4+PiBJJ3ZlIHN1Z2dlc3RlZCBzb21lIHRleHQgZm9yIHRoaXMgaW4gYSBQUiBb
MV0gYmFzZWQgb24gd2hhdCBwZW9wbGUgDQo+Pj4gaGF2ZSBzYWlkIGluIHRoaXMgdGhyZWFkLg0K
Pj4+DQo+Pj4gSSdtIHN1cmUgdGhhdCBjYW4gYmUgZnVydGhlciBpbXByb3ZlZC4NCj4+Pg0KPj4+
IEl0IG1pZ2h0IGJlIG5vIGhhcm0gdG8gYWRkIG1vcmUgcG9pbnRlcnMgdG8gdGhhdCBhcHBlbmRp
eCBmcm9tIA0KPj4+IGVsc2V3aGVyZSBpbiB0aGUgc3BlYywgYW5kL29yIHRvIGFkZCBhIGxpc3Qg
b2YgdGhlIHZhcmlvdXMgDQo+Pj4gcHVibGljL3ByaXZhdGUgcmFuZG9tIG51bWJlcnMgdGhhdCBh
cmUgbmVlZGVkIHRvIHRoYXQgYXBwZW5kaXguIChJJ2QgDQo+Pj4gYmUgaGFwcHkgdG8gZG8gYSBw
YXNzIHRvIGlkZW50aWZ5IHRob3NlIGlmIGZvbGtzIGJhc2ljYWxseSBsaWtlIHRoaXMgDQo+Pj4g
a2luZCBvZiBhZGRpdGlvbi4pDQo+Pj4NCj4+PiBJIGFsc28gbmVlZCB0byBmaWd1cmUgb3V0IGhv
dyB0byBoYW5kbGUgdGhlIHJlZmVyZW5jZSBwcm9wZXJseTotKSANCj4+PiBDYW4gZG8gdGhhdCB0
b21vcnJvdy4NCj4+Pg0KPj4+IENoZWVycywNCj4+PiBTLg0KPj4+DQo+Pj4gWzFdIGh0dHBzOi8v
Z2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL3B1bGwvMTA2OA0KPj4+DQo+Pj4NCj4+PiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IFRMUyBtYWls
aW5nIGxpc3QNCj4+PiBUTFNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3Rscw0KPj4+DQo+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+PiBUTFMgbWFpbGluZyBsaXN0DQo+PiBUTFNAaWV0Zi5v
cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+Pg0KPj4N
Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBU
TFMgbWFpbGluZyBsaXN0DQo+PiBUTFNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdGxzDQo+Pg0KPj4NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVExTIG1haWxpbmcgbGlzdA0K
PiBUTFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90
bHMNCj4gDQoNCg0K


From nobody Fri Jul 28 06:44:20 2017
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 9D3FF132006 for ; Fri, 28 Jul 2017 06:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 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=-0.001, 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 L7e2TfpT1DYT for ; Fri, 28 Jul 2017 06:44: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 8276A131C81 for ; Fri, 28 Jul 2017 06:44:17 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 192978535D; Fri, 28 Jul 2017 13:44:17 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 192978535D
Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com
Received: from pintsize.usersys.redhat.com (ovpn-200-20.brq.redhat.com [10.40.200.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C8BC77091C; Fri, 28 Jul 2017 13:44:16 +0000 (UTC)
From: Hubert Kario 
To: Benjamin Kaduk 
Cc: tls@ietf.org
Date: Fri, 28 Jul 2017 15:44:10 +0200
Message-ID: <1743154.SRp0UpLzoG@pintsize.usersys.redhat.com>
In-Reply-To: 
References: <1985136.n8kX8SZK3z@pintsize.usersys.redhat.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4798629.EJEqO93dW8"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 28 Jul 2017 13:44:17 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] ClientHello1[truncated] - definitions?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 13:44:19 -0000

--nextPart4798629.EJEqO93dW8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Friday, 28 July 2017 14:45:40 CEST Benjamin Kaduk wrote:
> On 07/28/2017 07:41 AM, Hubert Kario wrote:
> > (looking at -21)
> >=20
> > Section 4.2.10.2 PSK binder refers to ClientHello1[truncated] as the va=
lue
> > that needs to be used as parameter to Transcript-Hash.
> >=20
> > Neither 'truncated' nor 'ClientHello1' are formally defined.
> >=20
> > ClientHello1 can be guessed (given text in 4.4.1) as the first ClientHe=
llo
> > that the client sends. But the value of 'truncated' is an enigma.
>=20
> Just a few paragraphs prior is:
>=20
>    [...] Each entry in the binders list is computed as an HMAC
>    over a transcript hash (see Section 4.4.1
> )
> containing a partial ClientHello up to and including the
> PreSharedKeyExtension.identities field.  That is, it includes all of the
> ClientHello but not the binders list itself.  The length fields for the
> message (including the overall length, the length of the extensions block,
> and the length of the "pre_shared_key" extension) are all set as if binde=
rs
> of the correct lengths were present.
>=20
> Please say more about how this could be made into a more-formal definitio=
n.

something like this:

   ClientHello1 is the initial ClientHello and ClientHello2 is the ClientHe=
llo=20
   send by client as a response to HelloRetryRequest. For both of those=20
   messages, the binder value will be computer over:

     truncated =3D Handshake.length - length(Extension.extension_data)
     Transcript-Hash(ClientHello1[truncated])

  Given Handshake message that contains the ClientHello message and the
  Extension that contains the PreSharedKeyExtension.

Though the references to specific message and extension could be made=20
cleaner...
=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 115, 612 00  Brno, Czech Republic
--nextPart4798629.EJEqO93dW8
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

iQIcBAABCgAGBQJZez+qAAoJEJKo0bgB0vX11Q0P/R6DQlsEO1VbnztwIspMS32R
G8Xfhb592Qbasc0H8rCnYQBrrq5zXDpvfOaFXqVCkIwgFnjHivl9z02OAroz52eU
oHm3UNSoK50III1WB008jvyQofS9rGPRBmsJ/PcmMFs2htWiGDcMuVM3LQcyJD21
OwtsJjKK7flWFyHsA0karAskqINnWKSjTMP6RWnQupkRXp5v+Rdm6sb+Qv0VuRmj
lD6Q4itqlB6YbCQ50p0SJRq2jYxo+DnJfwFDXJnYz/mOGsNTxSB63EpLq5KR949m
oC/4mGJ4+AXZa7i+10h+fGGJOptNl5XaiajgbRx5/V/6i8d5lhaT33O0WDSa8uiW
C7QfGwN88vDJCcgG7fCeSppsiqLc2DfqjImfdGLCvkasnVwlsRu/7j0l/Dt9zWj1
W6meEUmnhF8byJmwPAxm5XqmZhbiy35Z6/yFq+MriHi/a+R2DZxP/esf4DlO6xbk
DaGstEyIqHOkgPnw9qHCmpW43wY9OCWtKHPNTMP5daPSv2scQ/99f+2EmazYJVHM
DEwrqEJ/e564HslNVOxiVOhkJI7C823YunTo9MYNg6CYGCxT4EDBNTmC6djSZvpM
wm6RjzwsSgVP4b2OUdkYWotruVIGv9H+zD0MAbD5bsnZHuyv88/HzmsxJ9Lrf12Q
tGRSQ3w4QIC2QihP/CXx
=3lGk
-----END PGP SIGNATURE-----

--nextPart4798629.EJEqO93dW8--


From nobody Fri Jul 28 08:09:02 2017
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 AA7C8131566 for ; Fri, 28 Jul 2017 08:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 s65KkIvKMXwH for ; Fri, 28 Jul 2017 08:08:55 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 716ED131C7A for ; Fri, 28 Jul 2017 08:08:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id D7C94655BB; Fri, 28 Jul 2017 18:08:52 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id SXH-8VReZDAh; Fri, 28 Jul 2017 18:08:52 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 9C9AAC4; Fri, 28 Jul 2017 18:08:50 +0300 (EEST)
Date: Fri, 28 Jul 2017 18:08:50 +0300
From: Ilari Liusvaara 
To: Dan Brown 
Cc: "tls@ietf.org" 
Message-ID: <20170728150850.4kjtlfkbhdivhqnf@LK-Perkele-VII>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 15:08:57 -0000

On Fri, Jul 28, 2017 at 01:37:33PM +0000, Dan Brown wrote:
> 
> Finally, on systems with a linux-style interface, /dev/urandom and
> /dev/random could be used as the two CSPRNGs on some systems (or
> seed sources), although I think one of these is now deprecated? 

You do not want to use /dev/random as seed source. It can block for
potentially long times. And the output quality is not better than
/dev/urandom. The same goes for the GRND_RANDOM flag.

There is one use for /dev/random tho: AFAIK, one can wait for random
initialization on Linux 3.16 or order by blocking until /dev/random
returns one byte (and then reading /dev/urandom). In 3.17 or newer,
better way is to call sys_getrandom as this blocks until random
initialization.



-Ilari


From nobody Fri Jul 28 08:36:02 2017
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 0527D131C76 for ; Fri, 28 Jul 2017 08:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 nv56Ay-lN3Kt for ; Fri, 28 Jul 2017 08:35:59 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9CB131BFE for ; Fri, 28 Jul 2017 08:35:59 -0700 (PDT)
Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 11:35:58 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0319.002; Fri, 28 Jul 2017 11:35:57 -0400
From: Dan Brown 
To: "ilariliusvaara@welho.com" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+yUHLG+hMivEObnVpzx6wh/KJjeS0AgAC0BYCAAI15AIAAcHiAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDwAgAANUQCAABPSAIAABQGAgAAkyoCAAYN2AP//zaLlgABFtACAAAITAIAAleMAgAADerCAAGc1AP//vyIg
Date: Fri, 28 Jul 2017 15:35:56 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501B7486A@XMB116CNC.rim.net>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <20170728150850.4kjtlfkbhdivhqnf@LK-Perkele-VII>
In-Reply-To: <20170728150850.4kjtlfkbhdivhqnf@LK-Perkele-VII>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.249]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 15:36:01 -0000

UmVwbGllcyBpbi1saW5lIChub24tc3RhbmRhcmRseSBlbmNsb3NlZCB3aXRoIDw8ID4+LCBzb3Jy
eSA7KQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWxhcmlsaXVzdmFhcmFA
d2VsaG8uY29tIFttYWlsdG86aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tXSANClNlbnQ6IEZyaWRh
eSwgSnVseSAyOCwgMjAxNyAxMTowOSBBTQ0KVG86IERhbiBCcm93biA8ZGFuaWJyb3duQGJsYWNr
YmVycnkuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIDMyIGJ5dGUg
cmFuZG9tcyBpbiBUTFMxLjMgaGVsbG8ncw0KDQpPbiBGcmksIEp1bCAyOCwgMjAxNyBhdCAwMToz
NzozM1BNICswMDAwLCBEYW4gQnJvd24gd3JvdGU6DQo+IA0KPiBGaW5hbGx5LCBvbiBzeXN0ZW1z
IHdpdGggYSBsaW51eC1zdHlsZSBpbnRlcmZhY2UsIC9kZXYvdXJhbmRvbSBhbmQgDQo+IC9kZXYv
cmFuZG9tIGNvdWxkIGJlIHVzZWQgYXMgdGhlIHR3byBDU1BSTkdzIG9uIHNvbWUgc3lzdGVtcyAo
b3Igc2VlZCANCj4gc291cmNlcyksIGFsdGhvdWdoIEkgdGhpbmsgb25lIG9mIHRoZXNlIGlzIG5v
dyBkZXByZWNhdGVkPw0KDQpZb3UgZG8gbm90IHdhbnQgdG8gdXNlIC9kZXYvcmFuZG9tIGFzIHNl
ZWQgc291cmNlLiBJdCBjYW4gYmxvY2sgZm9yIHBvdGVudGlhbGx5IGxvbmcgdGltZXMuIEFuZCB0
aGUgb3V0cHV0IHF1YWxpdHkgaXMgbm90IGJldHRlciB0aGFuIC9kZXYvdXJhbmRvbS4gDQoNCjw8
IFRoaXMgaXMgYW4gZXhhbXBsZSBvZiB0aGUgZGVwcmVjYXRpb24gb2YgL2Rldi9yYW5kb20sIEkg
dGhpbmsgKHdoaWNoIGNhbiBiZSBmb3VuZCBlbHNld2hlcmUgdG9vKS4NCg0KQW55d2F5LCB0aGlz
IHdob2xlIHRocmVhZCBjb25zaWRlcnMgcmVzaXN0aW5nIHRoZSBoeXBvdGhlc2lzIG9mIGEgQ1NQ
Uk5HLCBzdWNoIGFzIC9kZXYvW3VdcmFuZG9tLCBsZWFraW5nIGl0cyBpbnRlcm5hbCBzdGF0ZS4g
VGhlIGlkZWEgb2YgL2Rldi91cmFuZG9tIGlzIHRvIG5vdCBibG9jaywgYWxsb3dpbmcgdGhlIGlu
dGVybmFsIHN0YXRlIHRvIGV2b2x2ZSBkZXRlcm1pbmlzdGljYWxseSAoaWYgbm8gbmV3IGVudHJv
cHkgaW5wdXQgYXJyaXZlcykuICBTbywgZmluZGluZyBvbmUgL2Rldi91cmFuZG9tIG91dHB1dCB3
b3VsZCBsZWFkIHRvIGZpbmRpbmcgYW5vdGhlciAodW5kZXIgdGhpcyBoeXBvdGhlc2lzKSwgYnkg
d2F5IG9mIHRoZSBpbnRlcm5hbCBzdGF0ZS4gIEJ5IGNvbnRyYXN0LCBhcyBJIHVuZGVyc3RhbmQg
aXQsIC9kZXYvcmFuZG9tIHNob3VsZCBhdCBsZWFzdCBibG9jayB1bnRpbCBpdCBiZWxpZXZlcyBp
dCBoYXMgdXBkYXRlZCBpdHMgaW50ZXJuYWwgc3RhdGUgd2l0aCBhIGdvb2QgZG9zZSBvZiBlbnRy
b3B5LiAgT2YgY291cnNlLCB0aGlzIG11ZGRsZXMgdGhlIGh5cG90aGVzaXMgc29tZXdoYXQsIHNp
bmNlIGZpcnN0IHdlIHBvc2l0IGEgYmFkIFBSTkcsIHRoZW4gd2Ugc3BlYWsgb2YgL2Rldi9yYW5k
b20gYWN0aW5nIGxpa2UgYSBnb29kIFBSTkcsIGV0Yy4gSW4gYSB3YXksIC9kZXYvcmFuZG9tIGlz
IHNvcnQgb2YgZG9pbmcgd2hhdCBwZW9wbGUgYXJlIHByb3Bvc2luZyBoZXJlICh0aGUgMiBDU1BS
TkcpLCBieSB0cnlpbmcgdG8gZW5zdXJlIHRoYXQgc3VjY2Vzc2l2ZSByYW5kb20gb3V0cHV0cyBh
cmUgbm90IGRldGVybWluaXN0aWNhbGx5IGxpbmtlZCBieSBhIHJhbmRvbSBzdGF0ZSwgc28gYXJl
IGluIGEgc2Vuc2UgdHdvICJpbmRlcGVuZGVudCIgdmFsdWVzLi4uLCBldmVuIGlmIHRoZSBkZXRl
cm1pbmlzdGljIHBhcnQgb2YgdGhlIFJORywgdGhlIGhhc2hpbmcgb3Igd2hhdGV2ZXIsIGZhaWxz
Li4uID4+DQoNCg0K


From nobody Fri Jul 28 08:48:57 2017
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 02F75131EDF for ; Fri, 28 Jul 2017 08:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qlk_i8Vl9gL for ; Fri, 28 Jul 2017 08:48:53 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2F112EE45 for ; Fri, 28 Jul 2017 08:48:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7992BBE2F; Fri, 28 Jul 2017 16:48:50 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_jlnIOTyhfY; Fri, 28 Jul 2017 16:48:47 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 40EEEBE2D; Fri, 28 Jul 2017 16:48:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1501256927; bh=Y+xYLZtNBs6VDvb0c4WxBzwpLxCMo9xu1OEW9YvjjDw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=3+C81mXTIO2ZHOUMqgUWohsPQeELGfvsKuIX7HYWrlMk3YHzDlP8v9TiaJbCjo8Z/ unzCpp/enWPIxWCuI6D0gEEHWlDxXD0F6SSUEWhi0j2nq5T8pwsZN0OSzlgnQAJUDT ZI8fxYkeOK/3O2LTrnXmXviT+0DBSvl73il8AToU=
To: Dan Brown , Eric Rescorla , "Blumenthal, Uri - 0553 - MITLL" 
Cc: "tls@ietf.org" 
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie>
Date: Fri, 28 Jul 2017 16:48:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iHAL4pGhRn4OBPd4W0X2BA3etQIVnsnsh"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 15:48:56 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--iHAL4pGhRn4OBPd4W0X2BA3etQIVnsnsh
Content-Type: multipart/mixed; boundary="8VfvslLagKrWLSjOONa1BeGg8uxu1UChH";
 protected-headers="v1"
From: Stephen Farrell 
To: Dan Brown , Eric Rescorla ,
 "Blumenthal, Uri - 0553 - MITLL" 
Cc: "tls@ietf.org" 
Message-ID: <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie>
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
References: 
 <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>
 
 <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>
 
 <20170727233335.8573013.91860.16216@blackberry.com>
 <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>
 
 <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie>
 <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net>

--8VfvslLagKrWLSjOONa1BeGg8uxu1UChH
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


I don't think this is simply a case of multiple CSPRNGs.

My guess is many TLS implementations don't have visibility
into how the CSPRNG operates. That code does however, know
which output values will be public and which not. For me,
that implies that any good separation scheme applied within
the TLS code that differentiates between public and non
public outputs is a good plan. Yes, if an attacker can bork
your CSPRNG, they may be able to get at the TLS code too
sometimes, but I'd argue the defence in depth is worthwhile.

Cheers,
S.

On 28/07/17 14:37, Dan Brown wrote:
> I try below to better explain my points against separated public and pr=
ivate CSPRNG instances.=20
>=20
> Perhaps the easiest way to get "independent" seeds for the two instance=
s of a CSPRNG, is to use a third CSPRNG instance to generate the seeds.  =
But then the problem arises again, if the 3 CSPRNGs are bad enough, (0=3D=
seeder, 1=3Dpublic, 2=3Dprivate), there is a risk that:
> =20
> Public_nonce=3Doutput1=3D>seed1=3Doutput0_for_1=3D>seed0=3D>output0_for=
_2=3Dseed2=3D>output_2=3Dprivate_key=3DTLS_insecurity.
>=20
> In short, generally speaking, three bad CSPRNGs do not combine easily i=
nto 1 good CSPRNG. =20
>=20
> (I'm not yet sure if this attack on three CSPRNGs combined applies to D=
ual_EC, since it may do something hash-like to the seed (I forgot details=
), and also output leaks the next state, not the previous state, as I rec=
all, so that might break the chain above.)
>=20
> The alternative to a 3rd CSPRNG is to get the seeds from directly from =
a raw entropy source. In that case, keep in mind that one of the purposes=
 of CSPRNGs is that raw entropy sources are unreliable (sometimes stall, =
etc. [references to be added]) and generally weak on the independence (th=
ey are non-uniform, hence have correlations).  CSPRNGs are supposed to co=
rrect these deficiencies, among other things.  So, if the 2 seeds are gen=
erated directly from a raw entropy sources (without a CSPRNG), two things=
 may go wrong. First, deriving one seed from the other might be feasible =
because of non-uniformity. A bad CSPRNG might enable this this to be expl=
oited, by finding one seed from the other.  Second, if the entropy source=
 stalls (down a trickle of low entropy), between too close seed requests =
- accidentally - then even a good CSPRNG couldn't cope.
>=20
> Maybe, all this wouldn't be a problem on many higher end systems, with =
high entropy, so my concern is lower end systems, and also unnecessary co=
mplications of maintaining multiple bad CSPRNGs, potentially to no avail.=
 =20
>=20
> Finally, on systems with a linux-style interface, /dev/urandom and /dev=
/random could be used as the two CSPRNGs on some systems (or seed sources=
), although I think one of these is now deprecated?=20
>=20
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: Friday, July 28, 2017 4:47 AM
> To: Eric Rescorla ; Blumenthal, Uri - 0553 - MITLL 
> Cc: tls@ietf.org
> Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
>=20
>=20
> Hiya,
>=20
> On 28/07/17 00:50, Eric Rescorla wrote:
>> I used the term "separate" here, which was intended to convey this,=20
>> but if people think "independent" or something is better, happy to cha=
nge.
>=20
> I think your change is a fine improvement over -21, thanks.
> (And my suggested text was as imperfect as I usually manage:-)
>=20
> I'm not clear if implementers will or will not get the ramifications of=
 "separate" (or "independent"), so I think we ought describe (or referenc=
e) at least one way in which that separation can be achieved.
>=20
> I also think we ought at least RECOMMEND separate CSPRNGs.
> I'd prefer a MUST myself but since there's no one good way we can descr=
ibe to achieve the effect that'd work in all cases, I don't think we can =
say MUST.
>=20
> Cheers,
> S.
>=20
>=20
>>
>> -Ekr
>>
>>
>> On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL <=20
>> uri@ll.mit.edu> wrote:
>>
>>> Respectfully disagree. Having two cryptographically independent=20
>>> PRNGs, one for public data and one for key material, IMHO is a good=20
>>> idea. Of course, both should be properly seeded - but that's a differ=
ent issue.
>>>
>>> Regards,
>>> Uri
>>>
>>> Sent from my iPhone
>>>
>>> On Jul 27, 2017, at 19:33, Dan Brown  wrote=
:
>>>
>>>
>>> I don't think 2 CSPRNGs is a good idea.
>>>
>>> Wasn=E2=80=99t there a few years back some RSA keys with separate p a=
nd q,=20
>>> generated independently leading to an attack...
>>>
>>> Here if the seeds to initialize the RNGS are related, or one is weak,=
=20
>>> or worst if the seed is a raw source that doesn=E2=80=99t change in t=
he=20
>>> moments between the two CSPRNG inits, that'd be bad, even if the CSPR=
NGs were good.
>>> *From: *Eric Rescorla
>>> *Sent: *Thursday, July 27, 2017 6:34 PM
>>> *To: *Stephen Farrell
>>> *Cc: *tls@ietf.org
>>> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's
>>>
>>> Spec updated here;
>>> https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0ac=

>>> bc42
>>> 942af9ca77
>>>
>>> -Ekr
>>>
>>>
>>> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell <=20
>>> stephen.farrell@cs.tcd.ie> wrote:
>>>
>>>>
>>>> I've suggested some text for this in a PR [1] based on what people=20
>>>> have said in this thread.
>>>>
>>>> I'm sure that can be further improved.
>>>>
>>>> It might be no harm to add more pointers to that appendix from=20
>>>> elsewhere in the spec, and/or to add a list of the various=20
>>>> public/private random numbers that are needed to that appendix. (I'd=
=20
>>>> be happy to do a pass to identify those if folks basically like this=
=20
>>>> kind of addition.)
>>>>
>>>> I also need to figure out how to handle the reference properly:-)=20
>>>> Can do that tomorrow.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> [1] https://github.com/tlswg/tls13-spec/pull/1068
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>=20
>=20


--8VfvslLagKrWLSjOONa1BeGg8uxu1UChH--

--iHAL4pGhRn4OBPd4W0X2BA3etQIVnsnsh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZe1zeAAoJEC88hzaAX42iEmwH/1dMk1uKyQCXkpO0uBXflb3/
s2iVzy4A8SsrsJfsd+NNv+PaRJGf9tymeSll94W9lzuq5lW9yXXM9IvswCnjkua2
xJPGl4pUlFUihuCHlKdH1BF1JrDuOfPI/KoQSYWVBf3binhzl3SNrAWKDAy2Y1pK
hVbkjtjIAGiwX2Mqu3VmSwOHy8c/hH2ASNrM60HNT67jjXupUHJHtorwumBmkg14
wM0VUnG6ItHuv2fmsEkj0cPbBuWBUeqVXdaknV5iZeJIo1cGEd9Ou5YGPzAVON3b
4F985/HQt2eYA2uClQHvMMHCfcNY4h4j53fZ0gnrjW7MsUMArYOvD5wwheMHHFU=
=1hdj
-----END PGP SIGNATURE-----

--iHAL4pGhRn4OBPd4W0X2BA3etQIVnsnsh--


From nobody Fri Jul 28 08:54:33 2017
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 382C5132144 for ; Fri, 28 Jul 2017 08:54:32 -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 (2048-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 YDVDb_5EyEFq for ; Fri, 28 Jul 2017 08:54:30 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 D5519132143 for ; Fri, 28 Jul 2017 08:54:29 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6SFpa3L012266; Fri, 28 Jul 2017 16:54:21 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ADurgxL10HQCpkiB0i+5FC9fbBow2Sk/aHPmhpD6yt4=; b=d3DBVJFDcB1SYVANqcZ9d/fe/aHnaaWrk5zdaWkV9kz2TrHUdH0LWc/WIJQiMoZ/UpOz U6Ks/Qbc4cPXez+XdP0yMSaZWk0qM/SliwCydwm6dY1nkQmoKQOqTe/jSROqAQbneL5x ulp3EMC0LomW2FRCPROVyMe0mgYSuuUJay7JQfoTk9Mj4A+Bpbc257ww97MDX0K7RiIr 4BQUGE9IWDo7ruS9+t2LGBE/Immr5ityjXtpDuXVeqM539BOYNVmDZEeFmILV+By0s7a iHLL5qo/5rOxawMFYsf4lxwdOTxAoL07Gae1AkSd4JLsN9hUdDI1ZUXwNlVIRpBpfSK9 aA== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2by2p0h192-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jul 2017 16:54:20 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6SFpU3Q008660; Fri, 28 Jul 2017 11:54:19 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bv21v679j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 28 Jul 2017 11:54:19 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Jul 2017 11:54:18 -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.1263.000; Fri, 28 Jul 2017 11:54:18 -0400
From: "Salz, Rich" 
To: Stephen Farrell , Dan Brown , Eric Rescorla , "Blumenthal, Uri - 0553 - MITLL" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+zRr18Uq8HhkqrA5btU4vzwqJjeS0AgAC0BYCAAI15AIAAcHiAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDwAgAANUQCAABPSAIAABQGAgAAkyoCAAYN2AIAAELEAgAACpQCAAAITAIAAleMAgABRLoCAACSqAP//vjGw
Date: Fri, 28 Jul 2017 15:54:18 +0000
Message-ID: 
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie>
In-Reply-To: <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.61]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-28_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707280252
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-28_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707280253
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 15:54:32 -0000

PiBUaGF0IGNvZGUgZG9lcyBob3dldmVyLCBrbm93IHdoaWNoIG91dHB1dCB2YWx1ZXMgd2lsbA0K
PiBiZSBwdWJsaWMgYW5kIHdoaWNoIG5vdC4gRm9yIG1lLCB0aGF0IGltcGxpZXMgdGhhdCBhbnkg
Z29vZCBzZXBhcmF0aW9uDQo+IHNjaGVtZSBhcHBsaWVkIHdpdGhpbiB0aGUgVExTIGNvZGUgdGhh
dCBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuIHB1YmxpYyBhbmQNCj4gbm9uIHB1YmxpYyBvdXRwdXRz
IGlzIGEgZ29vZCBwbGFuLg0KDQpBZ3JlZWQuDQoNCgkvciQsIHdobyBpcyBtb3ZpbmcgT3BlblNT
TCB0byBEUkJHIEFFUzEyOC1jdHIsIGFuZCBob3BlZnVsbHkgYWRkaW5nIHR3byBpbnN0YW5jZXMg
OikNCg0K


From nobody Fri Jul 28 10:35:15 2017
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 15139131C88 for ; Fri, 28 Jul 2017 10:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 HHDvVjYGNTUx for ; Fri, 28 Jul 2017 10:35:11 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9B38713188D for ; Fri, 28 Jul 2017 10:35:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 90BD622C5C; Fri, 28 Jul 2017 20:35:09 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id xScYSNyzhbyt; Fri, 28 Jul 2017 20:35:09 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3922421C; Fri, 28 Jul 2017 20:35:07 +0300 (EEST)
Date: Fri, 28 Jul 2017 20:35:07 +0300
From: Ilari Liusvaara 
To: Dan Brown 
Cc: "tls@ietf.org" 
Message-ID: <20170728173507.2vk67me56q2edz6g@LK-Perkele-VII>
References:  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <20170728150850.4kjtlfkbhdivhqnf@LK-Perkele-VII> <810C31990B57ED40B2062BA10D43FBF501B7486A@XMB116CNC.rim.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B7486A@XMB116CNC.rim.net>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 28 Jul 2017 17:35:14 -0000

On Fri, Jul 28, 2017 at 03:35:56PM +0000, Dan Brown wrote:
> You do not want to use /dev/random as seed source. It can block for
> potentially long times. And the output quality is not better than
> /dev/urandom. 
> 
> << This is an example of the deprecation of /dev/random, I think
> (which can be found elsewhere too).

No, /dev/random has behaved that way for a long long time.

> Anyway, this whole thread considers resisting the hypothesis of
> a CSPRNG, such as /dev/[u]random, leaking its internal state.
> The idea of /dev/urandom is to not block, allowing the internal
> state to evolve deterministically (if no new entropy input
> arrives).  So, finding one /dev/urandom output would lead to
> finding another (under this hypothesis), by way of the internal
> state. 

The pool underlying /dev/urandom is reseeded periodically (I think
every minute if enough entropy is available).

> By contrast, as I understand it, /dev/random should at least
> block until it believes it has updated its internal state
> with a good dose of entropy.  

The problem is that /dev/random runs out of entropy REALLY fast if
you try to actually use it.

I think the pool size is equivalent to about 16 ECDH keys or TLS
*randoms. And it can easily take ten seconds to recover enough entropy
for one such. Not good.


If you want to use /dev/random (or GRND_RANDOM) for anything, it better
be long-term key generation (and even that is bit questionable).



-Ilari


From nobody Sat Jul 29 08:54:53 2017
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 DF7B2131C3C for ; Sat, 29 Jul 2017 08:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 J5-h475_b5mv for ; Sat, 29 Jul 2017 08:54:49 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDBB12EC13 for ; Sat, 29 Jul 2017 08:54:48 -0700 (PDT)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jul 2017 11:54:47 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0319.002; Sat, 29 Jul 2017 11:54:47 -0400
From: Dan Brown 
To: Stephen Farrell , Eric Rescorla ,  "Blumenthal, Uri - 0553 - MITLL" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+yUHLG+hMivEObnVpzx6wh/KJjeS0AgAC0BYCAAI15AIAAcHiAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDwAgAANUQCAABPSAIAABQGAgAAkyoCAAYN2AP//zaLlgABFtACAAAITAIAAleMAgAADerCAAHJeAIABUPW7
Date: Sat, 29 Jul 2017 15:54:47 +0000
Message-ID: <20170729155445.8573013.35196.16289@blackberry.com>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net>, <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie>
In-Reply-To: <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Jul 2017 15:54:52 -0000

https://eprint.iacr.org/2012/064
mentions the problem of generating multiple secrets instead of a single sec=
ret

  Original Message
From: Stephen Farrell
Sent: Friday, July 28, 2017 11:48 AM
To: Dan Brown; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL
Cc: tls@ietf.org
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's


I don't think this is simply a case of multiple CSPRNGs.

My guess is many TLS implementations don't have visibility
into how the CSPRNG operates. That code does however, know
which output values will be public and which not. For me,
that implies that any good separation scheme applied within
the TLS code that differentiates between public and non
public outputs is a good plan. Yes, if an attacker can bork
your CSPRNG, they may be able to get at the TLS code too
sometimes, but I'd argue the defence in depth is worthwhile.

Cheers,
S.

On 28/07/17 14:37, Dan Brown wrote:
> I try below to better explain my points against separated public and priv=
ate CSPRNG instances.
>
> Perhaps the easiest way to get "independent" seeds for the two instances =
of a CSPRNG, is to use a third CSPRNG instance to generate the seeds.  But =
then the problem arises again, if the 3 CSPRNGs are bad enough, (0=3Dseeder=
, 1=3Dpublic, 2=3Dprivate), there is a risk that:
>
> Public_nonce=3Doutput1=3D>seed1=3Doutput0_for_1=3D>seed0=3D>output0_for_2=
=3Dseed2=3D>output_2=3Dprivate_key=3DTLS_insecurity.
>
> In short, generally speaking, three bad CSPRNGs do not combine easily int=
o 1 good CSPRNG.
>
> (I'm not yet sure if this attack on three CSPRNGs combined applies to Dua=
l_EC, since it may do something hash-like to the seed (I forgot details), a=
nd also output leaks the next state, not the previous state, as I recall, s=
o that might break the chain above.)
>
> The alternative to a 3rd CSPRNG is to get the seeds from directly from a =
raw entropy source. In that case, keep in mind that one of the purposes of =
CSPRNGs is that raw entropy sources are unreliable (sometimes stall, etc. [=
references to be added]) and generally weak on the independence (they are n=
on-uniform, hence have correlations).  CSPRNGs are supposed to correct thes=
e deficiencies, among other things.  So, if the 2 seeds are generated direc=
tly from a raw entropy sources (without a CSPRNG), two things may go wrong.=
 First, deriving one seed from the other might be feasible because of non-u=
niformity. A bad CSPRNG might enable this this to be exploited, by finding =
one seed from the other.  Second, if the entropy source stalls (down a tric=
kle of low entropy), between too close seed requests - accidentally - then =
even a good CSPRNG couldn't cope.
>
> Maybe, all this wouldn't be a problem on many higher end systems, with hi=
gh entropy, so my concern is lower end systems, and also unnecessary compli=
cations of maintaining multiple bad CSPRNGs, potentially to no avail.
>
> Finally, on systems with a linux-style interface, /dev/urandom and /dev/r=
andom could be used as the two CSPRNGs on some systems (or seed sources), a=
lthough I think one of these is now deprecated?
>
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: Friday, July 28, 2017 4:47 AM
> To: Eric Rescorla ; Blumenthal, Uri - 0553 - MITLL 
> Cc: tls@ietf.org
> Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
>
>
> Hiya,
>
> On 28/07/17 00:50, Eric Rescorla wrote:
>> I used the term "separate" here, which was intended to convey this,
>> but if people think "independent" or something is better, happy to chang=
e.
>
> I think your change is a fine improvement over -21, thanks.
> (And my suggested text was as imperfect as I usually manage:-)
>
> I'm not clear if implementers will or will not get the ramifications of "=
separate" (or "independent"), so I think we ought describe (or reference) a=
t least one way in which that separation can be achieved.
>
> I also think we ought at least RECOMMEND separate CSPRNGs.
> I'd prefer a MUST myself but since there's no one good way we can describ=
e to achieve the effect that'd work in all cases, I don't think we can say =
MUST.
>
> Cheers,
> S.
>
>
>>
>> -Ekr
>>
>>
>> On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL <
>> uri@ll.mit.edu> wrote:
>>
>>> Respectfully disagree. Having two cryptographically independent
>>> PRNGs, one for public data and one for key material, IMHO is a good
>>> idea. Of course, both should be properly seeded - but that's a differen=
t issue.
>>>
>>> Regards,
>>> Uri
>>>
>>> Sent from my iPhone
>>>
>>> On Jul 27, 2017, at 19:33, Dan Brown  wrote:
>>>
>>>
>>> I don't think 2 CSPRNGs is a good idea.
>>>
>>> Wasn=92t there a few years back some RSA keys with separate p and q,
>>> generated independently leading to an attack...
>>>
>>> Here if the seeds to initialize the RNGS are related, or one is weak,
>>> or worst if the seed is a raw source that doesn=92t change in the
>>> moments between the two CSPRNG inits, that'd be bad, even if the CSPRNG=
s were good.
>>> *From: *Eric Rescorla
>>> *Sent: *Thursday, July 27, 2017 6:34 PM
>>> *To: *Stephen Farrell
>>> *Cc: *tls@ietf.org
>>> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's
>>>
>>> Spec updated here;
>>> https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0ac
>>> bc42
>>> 942af9ca77
>>>
>>> -Ekr
>>>
>>>
>>> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell <
>>> stephen.farrell@cs.tcd.ie> wrote:
>>>
>>>>
>>>> I've suggested some text for this in a PR [1] based on what people
>>>> have said in this thread.
>>>>
>>>> I'm sure that can be further improved.
>>>>
>>>> It might be no harm to add more pointers to that appendix from
>>>> elsewhere in the spec, and/or to add a list of the various
>>>> public/private random numbers that are needed to that appendix. (I'd
>>>> be happy to do a pass to identify those if folks basically like this
>>>> kind of addition.)
>>>>
>>>> I also need to figure out how to handle the reference properly:-)
>>>> Can do that tomorrow.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> [1] https://github.com/tlswg/tls13-spec/pull/1068
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>


From nobody Sat Jul 29 11:04:49 2017
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 B09B6131CEB for ; Sat, 29 Jul 2017 11:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level: 
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 GfhqR1n3_niE for ; Sat, 29 Jul 2017 11:04:45 -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 419BB131C88 for ; Sat, 29 Jul 2017 11:04:45 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id p68so1554783ywg.0 for ; Sat, 29 Jul 2017 11:04:45 -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=aHvftLMTAom2oE2xcdS8279hpV7yBoqvMAUS2A756R4=; b=eBoE4Y9wgKn4ZcCbndr4a9meCkpNozDS3umaBXzqkmDxNoLGt6POiNjWL0T221hsMM Cnw8QJ3lbDO2nfj18GT1MeSPR0jCNML3i/0dOgHswvVjhSu0kZqhVgjSkBwLbOuz2wuz 0R/ZkDOyuR38FrIjcOOJVHYBdIDGIUEHQieeRv61KMtCmr1ownDvT4AZ/ES+j+e0RqZd 3vgmrw1xJyXhmi/CYm4U5fv9CGLNTVzS2jimMyqF8u/kJS+CT22oly1WGlcFNn8oG9D2 l//Y0GzT7SjO33iPjALiJHCEq3KWFHCRDpTnTobeRUSL54BL+NIgapNIewzpi5dB+MJd BChw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aHvftLMTAom2oE2xcdS8279hpV7yBoqvMAUS2A756R4=; b=ROhQ9X/00wCcsGjNBhoVcjSl8rvUmAVMZBbBG0Lt1ZTJvobaasRF2UidRvyvuf5nUo eiPIlte/mgpSFW2qx6Vdb8P1WHakAzGxQ56ubU+tSWNtIYRfHtxkGzohbYQnSG+cbjXR Je34AHlFVXAbkGOPt8feyDhP0UdrorL5k8PuHyCAcuAKAatN/S5RUoemGJXNl/F0gN+L ygMsc8TyI9eaIA0Dxg6IRzetRb+4G4jNGTufdDfO6OyeW0xvXwqO2jMK8mQjqjVyHV2Z xEk3LhzFRl2NQL/eFqc7SeTb+eS0Fkzr+QqjsF9Er7rUC7aVVbpjgd01ra/2ItXfqYG9 17hA==
X-Gm-Message-State: AIVw112zWGU97pyZgwwTKMKOKGcT8ZcMmd7qjySiyudjGWbH/x4yKEgx l+NRw5Q8FBbwPD0CM1ybB3krf8LggYhP
X-Received: by 10.129.94.67 with SMTP id s64mr9292251ywb.83.1501351484259; Sat, 29 Jul 2017 11:04:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.71 with HTTP; Sat, 29 Jul 2017 11:04:43 -0700 (PDT)
In-Reply-To: <20170729155445.8573013.35196.16289@blackberry.com>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie> <20170729155445.8573013.35196.16289@blackberry.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Sat, 29 Jul 2017 11:04:43 -0700
Message-ID: 
To: Dan Brown 
Cc: Stephen Farrell , Eric Rescorla ,  "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114921d2e71ff1055578a16f"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Jul 2017 18:04:48 -0000

--001a114921d2e71ff1055578a16f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't see anything relevant to the problem at hand in that paper. Did you
reference the right one? There are some mentions about not re-using random
secrets, but that applies no matter how many RNGs you use.

In your previous mail, even if an implementer were to seed two RNGs from
one CSPRNG, and all 3 are bad generator, this is still strictly better than
one broken generator; because the amount of work an attacker must do is far
greater.

On Sat, Jul 29, 2017 at 8:54 AM, Dan Brown  wrote=
:

> https://eprint.iacr.org/2012/064
> mentions the problem of generating multiple secrets instead of a single
> secret
>




>
>   Original Message
> From: Stephen Farrell
> Sent: Friday, July 28, 2017 11:48 AM
> To: Dan Brown; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL
> Cc: tls@ietf.org
> Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
>
>
> I don't think this is simply a case of multiple CSPRNGs.
>
> My guess is many TLS implementations don't have visibility
> into how the CSPRNG operates. That code does however, know
> which output values will be public and which not. For me,
> that implies that any good separation scheme applied within
> the TLS code that differentiates between public and non
> public outputs is a good plan. Yes, if an attacker can bork
> your CSPRNG, they may be able to get at the TLS code too
> sometimes, but I'd argue the defence in depth is worthwhile.
>
> Cheers,
> S.
>
> On 28/07/17 14:37, Dan Brown wrote:
> > I try below to better explain my points against separated public and
> private CSPRNG instances.
> >
> > Perhaps the easiest way to get "independent" seeds for the two instance=
s
> of a CSPRNG, is to use a third CSPRNG instance to generate the seeds.  Bu=
t
> then the problem arises again, if the 3 CSPRNGs are bad enough, (0=3Dseed=
er,
> 1=3Dpublic, 2=3Dprivate), there is a risk that:
> >
> > Public_nonce=3Doutput1=3D>seed1=3Doutput0_for_1=3D>seed0=3D>output0_
> for_2=3Dseed2=3D>output_2=3Dprivate_key=3DTLS_insecurity.
> >
> > In short, generally speaking, three bad CSPRNGs do not combine easily
> into 1 good CSPRNG.
> >
> > (I'm not yet sure if this attack on three CSPRNGs combined applies to
> Dual_EC, since it may do something hash-like to the seed (I forgot
> details), and also output leaks the next state, not the previous state, a=
s
> I recall, so that might break the chain above.)
> >
> > The alternative to a 3rd CSPRNG is to get the seeds from directly from =
a
> raw entropy source. In that case, keep in mind that one of the purposes o=
f
> CSPRNGs is that raw entropy sources are unreliable (sometimes stall, etc.
> [references to be added]) and generally weak on the independence (they ar=
e
> non-uniform, hence have correlations).  CSPRNGs are supposed to correct
> these deficiencies, among other things.  So, if the 2 seeds are generated
> directly from a raw entropy sources (without a CSPRNG), two things may go
> wrong. First, deriving one seed from the other might be feasible because =
of
> non-uniformity. A bad CSPRNG might enable this this to be exploited, by
> finding one seed from the other.  Second, if the entropy source stalls
> (down a trickle of low entropy), between too close seed requests -
> accidentally - then even a good CSPRNG couldn't cope.
> >
> > Maybe, all this wouldn't be a problem on many higher end systems, with
> high entropy, so my concern is lower end systems, and also unnecessary
> complications of maintaining multiple bad CSPRNGs, potentially to no avai=
l.
> >
> > Finally, on systems with a linux-style interface, /dev/urandom and
> /dev/random could be used as the two CSPRNGs on some systems (or seed
> sources), although I think one of these is now deprecated?
> >
> > -----Original Message-----
> > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Stephen Farrell
> > Sent: Friday, July 28, 2017 4:47 AM
> > To: Eric Rescorla ; Blumenthal, Uri - 0553 - MITLL <
> uri@ll.mit.edu>
> > Cc: tls@ietf.org
> > Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
> >
> >
> > Hiya,
> >
> > On 28/07/17 00:50, Eric Rescorla wrote:
> >> I used the term "separate" here, which was intended to convey this,
> >> but if people think "independent" or something is better, happy to
> change.
> >
> > I think your change is a fine improvement over -21, thanks.
> > (And my suggested text was as imperfect as I usually manage:-)
> >
> > I'm not clear if implementers will or will not get the ramifications of
> "separate" (or "independent"), so I think we ought describe (or reference=
)
> at least one way in which that separation can be achieved.
> >
> > I also think we ought at least RECOMMEND separate CSPRNGs.
> > I'd prefer a MUST myself but since there's no one good way we can
> describe to achieve the effect that'd work in all cases, I don't think we
> can say MUST.
> >
> > Cheers,
> > S.
> >
> >
> >>
> >> -Ekr
> >>
> >>
> >> On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL <
> >> uri@ll.mit.edu> wrote:
> >>
> >>> Respectfully disagree. Having two cryptographically independent
> >>> PRNGs, one for public data and one for key material, IMHO is a good
> >>> idea. Of course, both should be properly seeded - but that's a
> different issue.
> >>>
> >>> Regards,
> >>> Uri
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On Jul 27, 2017, at 19:33, Dan Brown  wrote=
:
> >>>
> >>>
> >>> I don't think 2 CSPRNGs is a good idea.
> >>>
> >>> Wasn=E2=80=99t there a few years back some RSA keys with separate p a=
nd q,
> >>> generated independently leading to an attack...
> >>>
> >>> Here if the seeds to initialize the RNGS are related, or one is weak,
> >>> or worst if the seed is a raw source that doesn=E2=80=99t change in t=
he
> >>> moments between the two CSPRNG inits, that'd be bad, even if the
> CSPRNGs were good.
> >>> *From: *Eric Rescorla
> >>> *Sent: *Thursday, July 27, 2017 6:34 PM
> >>> *To: *Stephen Farrell
> >>> *Cc: *tls@ietf.org
> >>> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's
> >>>
> >>> Spec updated here;
> >>> https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0ac
> >>> bc42
> >>> 942af9ca77
> >>>
> >>> -Ekr
> >>>
> >>>
> >>> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell <
> >>> stephen.farrell@cs.tcd.ie> wrote:
> >>>
> >>>>
> >>>> I've suggested some text for this in a PR [1] based on what people
> >>>> have said in this thread.
> >>>>
> >>>> I'm sure that can be further improved.
> >>>>
> >>>> It might be no harm to add more pointers to that appendix from
> >>>> elsewhere in the spec, and/or to add a list of the various
> >>>> public/private random numbers that are needed to that appendix. (I'd
> >>>> be happy to do a pass to identify those if folks basically like this
> >>>> kind of addition.)
> >>>>
> >>>> I also need to figure out how to handle the reference properly:-)
> >>>> Can do that tomorrow.
> >>>>
> >>>> Cheers,
> >>>> S.
> >>>>
> >>>> [1] https://github.com/tlswg/tls13-spec/pull/1068
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
>



--=20
Colm

--001a114921d2e71ff1055578a16f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    I don't see anything relevant to the problem at hand in that =
paper. Did you reference the right one? There are some mentions about not r=
e-using random secrets, but that applies no matter how many RNGs you use.=
=C2=A0

    In your previous mail, even if an implementer were to seed two RNGs from o=
ne CSPRNG, and all 3 are bad generator, this is still strictly better than =
one broken generator; because the amount of work an attacker must do is far=
 greater. =C2=A0

    On Sat, Jul 29, 2017 at 8:54 AM, Dan Brown <danibrown@blackber=
ry.com> wrote:
    https=
://eprint.iacr.org/2012/064
    
mentions the problem of generating multiple secrets instead of a single sec=
ret


    =C2=A0
    

    
=C2=A0 Original Message
    
From: Stephen Farrell
    
Sent: Friday, July 28, 2017 11:48 AM
    
To: Dan Brown; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL
    

    Cc: tls@ietf.org
    
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
    

    

    
I don't think this is simply a case of multiple CSPRNGs.
    

    
My guess is many TLS implementations don't have visibility
    
into how the CSPRNG operates. That code does however, know
    
which output values will be public and which not. For me,
    
that implies that any good separation scheme applied within
    
the TLS code that differentiates between public and non
    
public outputs is a good plan. Yes, if an attacker can bork
    
your CSPRNG, they may be able to get at the TLS code too
    
sometimes, but I'd argue the defence in depth is worthwhile.
    

    
Cheers,
    
S.
    

    
On 28/07/17 14:37, Dan Brown wrote:
    
> I try below to better explain my points against separated public and p=
rivate CSPRNG instances.
    
>
    
> Perhaps the easiest way to get "independent" seeds for the t=
wo instances of a CSPRNG, is to use a third CSPRNG instance to generate the=
 seeds.=C2=A0 But then the problem arises again, if the 3 CSPRNGs are bad e=
nough, (0=3Dseeder, 1=3Dpublic, 2=3Dprivate), there is a risk that:
    
>
    
> Public_nonce=3Doutput1=3D>seed1=3Doutput0_for_1=3D>seed0=3D=
>output0_for_2=3Dseed2=3D>output_2=3Dprivate_key=3DTLS_inse=
curity.
    
>
    
> In short, generally speaking, three bad CSPRNGs do not combine easily =
into 1 good CSPRNG.
    
>
    
> (I'm not yet sure if this attack on three CSPRNGs combined applies=
 to Dual_EC, since it may do something hash-like to the seed (I forgot deta=
ils), and also output leaks the next state, not the previous state, as I re=
call, so that might break the chain above.)
    
>
    
> The alternative to a 3rd CSPRNG is to get the seeds from directly from=
 a raw entropy source. In that case, keep in mind that one of the purposes =
of CSPRNGs is that raw entropy sources are unreliable (sometimes stall, etc=
. [references to be added]) and generally weak on the independence (they ar=
e non-uniform, hence have correlations).=C2=A0 CSPRNGs are supposed to corr=
ect these deficiencies, among other things.=C2=A0 So, if the 2 seeds are ge=
nerated directly from a raw entropy sources (without a CSPRNG), two things =
may go wrong. First, deriving one seed from the other might be feasible bec=
ause of non-uniformity. A bad CSPRNG might enable this this to be exploited=
, by finding one seed from the other.=C2=A0 Second, if the entropy source s=
talls (down a trickle of low entropy), between too close seed requests - ac=
cidentally - then even a good CSPRNG couldn't cope.
    
>
    
> Maybe, all this wouldn't be a problem on many higher end systems, =
with high entropy, so my concern is lower end systems, and also unnecessary=
 complications of maintaining multiple bad CSPRNGs, potentially to no avail=
.
    
>
    
> Finally, on systems with a linux-style interface, /dev/urandom and /de=
v/random could be used as the two CSPRNGs on some systems (or seed sources)=
, although I think one of these is now deprecated?
    
>
    
> -----Original Message-----
    
> From: TLS [mailto:tls-bounces@=
ietf.org] On Behalf Of Stephen Farrell
    
> Sent: Friday, July 28, 2017 4:47 AM
    
> To: Eric Rescorla <ekr@rtfm.com=
>; Blumenthal, Uri - 0553 - MITLL <=
uri@ll.mit.edu>
    
> Cc: tls@ietf.org
    
> Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
    
>
    
>
    
> Hiya,
    
>
    
> On 28/07/17 00:50, Eric Rescorla wrote:
    
>> I used the term "separate" here, which was intended to c=
onvey this,
    
>> but if people think "independent" or something is better=
, happy to change.
    
>
    
> I think your change is a fine improvement over -21, thanks.
    
> (And my suggested text was as imperfect as I usually manage:-)
    
>
    
> I'm not clear if implementers will or will not get the ramificatio=
ns of "separate" (or "independent"), so I think we ough=
t describe (or reference) at least one way in which that separation can be =
achieved.
    
>
    
> I also think we ought at least RECOMMEND separate CSPRNGs.
    
> I'd prefer a MUST myself but since there's no one good way we =
can describe to achieve the effect that'd work in all cases, I don'=
t think we can say MUST.
    
>
    
> Cheers,
    
> S.
    
>
    
>
    
>>
    
>> -Ekr
    
>>
    
>>
    
>> On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL &l=
t;
    
>> uri@ll.mit.edu> wrote:
>>
    
>>> Respectfully disagree. Having two cryptographically independen=
t
    
>>> PRNGs, one for public data and one for key material, IMHO is a=
 good
    
>>> idea. Of course, both should be properly seeded - but that'=
;s a different issue.
    
>>>
    
>>> Regards,
    
>>> Uri
    
>>>
    
>>> Sent from my iPhone
    
>>>
    
>>> On Jul 27, 2017, at 19:33, Dan Brown <danibrown@blackberry.com> wrote:
    
>>>
    
>>>
    
>>> I don't think 2 CSPRNGs is a good idea.
    
>>>
    
>>> Wasn=E2=80=99t there a few years back some RSA keys with separ=
ate p and q,
    
>>> generated independently leading to an attack...
    
>>>
    
>>> Here if the seeds to initialize the RNGS are related, or one i=
s weak,
    
>>> or worst if the seed is a raw source that doesn=E2=80=99t chan=
ge in the
    
>>> moments between the two CSPRNG inits, that'd be bad, even =
if the CSPRNGs were good.
    
>>> *From: *Eric Rescorla
    
>>> *Sent: *Thursday, July 27, 2017 6:34 PM
    
>>> *To: *Stephen Farrell
    
>>> *Cc: *tls@ietf.org
    
>>> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's
    
>>>
    
>>> Spec updated here;
    
>>> https://github.com=
/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0ac
    
>>> bc42
    
>>> 942af9ca77
    
>>>
    
>>> -Ekr
    
>>>
    
>>>
    
>>> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell <
    
>>> stephen.farrell@c=
s.tcd.ie> wrote:
    
>>>
    
>>>>
    
>>>> I've suggested some text for this in a PR [1] based on=
 what people
    
>>>> have said in this thread.
    
>>>>
    
>>>> I'm sure that can be further improved.
    
>>>>
    
>>>> It might be no harm to add more pointers to that appendix =
from
    
>>>> elsewhere in the spec, and/or to add a list of the various=

    
>>>> public/private random numbers that are needed to that appe=
ndix. (I'd
    
>>>> be happy to do a pass to identify those if folks basically=
 like this
    
>>>> kind of addition.)
    
>>>>
    
>>>> I also need to figure out how to handle the reference prop=
erly:-)
    
>>>> Can do that tomorrow.
    
>>>>
    
>>>> Cheers,
    
>>>> S.
    
>>>>
    
>>>> [1] https://github.com/tlswg/tls1=
3-spec/pull/1068
    
>>>>
    
>>>>
    
>>>> _______________________________________________
    
>>>> TLS mailing list
    
>>>> TLS@ietf.org
    
>>>> https://www.ietf.org/mailman/listinf=
o/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=

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




    -- 
    =

    Colm

    

--001a114921d2e71ff1055578a16f--


From nobody Sat Jul 29 13:30:42 2017
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 D9136131D13 for ; Sat, 29 Jul 2017 13:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CGTVfYBiPjg7 for ; Sat, 29 Jul 2017 13:30:38 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BBE131E7A for ; Sat, 29 Jul 2017 13:30:37 -0700 (PDT)
Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jul 2017 16:30:35 -0400
Received: from XCT116CNC.rim.net (10.65.161.216) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 29 Jul 2017 16:30:34 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Sat, 29 Jul 2017 16:30:33 -0400
From: Dan Brown 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: Stephen Farrell , Eric Rescorla ,  "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+yUHLG+hMivEObnVpzx6wh/KJjeS0AgAC0BYCAAI15AIAAcHiAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDwAgAANUQCAABPSAIAABQGAgAAkyoCAAYN2AP//zaLlgABFtACAAAITAIAAleMAgAADerCAAHJeAIABUPW7gABnW4D//+Wy+Q==
Date: Sat, 29 Jul 2017 20:30:33 +0000
Message-ID: <20170729203031.8573013.59357.16296@blackberry.com>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie> <20170729155445.8573013.35196.16289@blackberry.com>, 
In-Reply-To: 
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_2017072920303185730135935716296blackberrycom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Jul 2017 20:30:41 -0000

--_000_2017072920303185730135935716296blackberrycom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

4oCOU2VjdGlvbiAzLCBvZiB0aGUgZXByaW50ICJSb24gaXMgd3JvbmcsIFdoaXQgaXMgcmlnaHQi
LCBzdWJzZWN0aW9uICJNb2R1bGkgd2l0aCBzaGFyZWQgcHJpbWVzIiwgc3VnZ2VzdHMgdG8gbWUg
dGhhdCBpdCdzIG5vdCB1bmxpa2VseSB3aGVuIHNlZWRpbmcgdHdvIHNlY3JldHMgbmVhciBpbiB0
aW1lLCBvbmUgaGFzIGxvdyBlbnRyb3B5IChieSBhY2NpZGVudCkuIFRoYXQncyBub3QgdGhlIG9u
bHkgZXhwbGFuYXRpb24gb2YgdGhlIG9ic2VydmVkIHNoYXJlZCBwcmltZXMsIGJ1dCBpcyBwbGF1
c2libGUgYW5kIHJlbGV2YW50IHRvIHRoZSBxdWVzdGlvbiBhdCBoYW5kLiAoSSB0aG91Z2h0IEkg
bWVudGlvbmVkIHRoaXMgZWFybGllci4pDQpGcm9tOiBDb2xtIE1hY0PDoXJ0aGFpZ2gNClNlbnQ6
IFNhdHVyZGF5LCBKdWx5IDI5LCAyMDE3IDI6MDQgUE0NClRvOiBEYW4gQnJvd24NCkNjOiBTdGVw
aGVuIEZhcnJlbGw7IEVyaWMgUmVzY29ybGE7IEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRM
TDsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gMzIgYnl0ZSByYW5kb21zIGluIFRM
UzEuMyBoZWxsbydzDQoNCg0KDQoNCkkgZG9uJ3Qgc2VlIGFueXRoaW5nIHJlbGV2YW50IHRvIHRo
ZSBwcm9ibGVtIGF0IGhhbmQgaW4gdGhhdCBwYXBlci4gRGlkIHlvdSByZWZlcmVuY2UgdGhlIHJp
Z2h0IG9uZT8gVGhlcmUgYXJlIHNvbWUgbWVudGlvbnMgYWJvdXQgbm90IHJlLXVzaW5nIHJhbmRv
bSBzZWNyZXRzLCBidXQgdGhhdCBhcHBsaWVzIG5vIG1hdHRlciBob3cgbWFueSBSTkdzIHlvdSB1
c2UuDQoNCkluIHlvdXIgcHJldmlvdXMgbWFpbCwgZXZlbiBpZiBhbiBpbXBsZW1lbnRlciB3ZXJl
IHRvIHNlZWQgdHdvIFJOR3MgZnJvbSBvbmUgQ1NQUk5HLCBhbmQgYWxsIDMgYXJlIGJhZCBnZW5l
cmF0b3IsIHRoaXMgaXMgc3RpbGwgc3RyaWN0bHkgYmV0dGVyIHRoYW4gb25lIGJyb2tlbiBnZW5l
cmF0b3I7IGJlY2F1c2UgdGhlIGFtb3VudCBvZiB3b3JrIGFuIGF0dGFja2VyIG11c3QgZG8gaXMg
ZmFyIGdyZWF0ZXIuDQoNCk9uIFNhdCwgSnVsIDI5LCAyMDE3IGF0IDg6NTQgQU0sIERhbiBCcm93
biA8ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tPG1haWx0bzpkYW5pYnJvd25AYmxhY2tiZXJyeS5j
b20+PiB3cm90ZToNCmh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMTIvMDY0DQptZW50aW9ucyB0
aGUgcHJvYmxlbSBvZiBnZW5lcmF0aW5nIG11bHRpcGxlIHNlY3JldHMgaW5zdGVhZCBvZiBhIHNp
bmdsZSBzZWNyZXQNCg0KDQoNCg0KICBPcmlnaW5hbCBNZXNzYWdlDQpGcm9tOiBTdGVwaGVuIEZh
cnJlbGwNClNlbnQ6IEZyaWRheSwgSnVseSAyOCwgMjAxNyAxMTo0OCBBTQ0KVG86IERhbiBCcm93
bjsgRXJpYyBSZXNjb3JsYTsgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMDQpDYzogdGxz
QGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gMzIgYnl0
ZSByYW5kb21zIGluIFRMUzEuMyBoZWxsbydzDQoNCg0KSSBkb24ndCB0aGluayB0aGlzIGlzIHNp
bXBseSBhIGNhc2Ugb2YgbXVsdGlwbGUgQ1NQUk5Hcy4NCg0KTXkgZ3Vlc3MgaXMgbWFueSBUTFMg
aW1wbGVtZW50YXRpb25zIGRvbid0IGhhdmUgdmlzaWJpbGl0eQ0KaW50byBob3cgdGhlIENTUFJO
RyBvcGVyYXRlcy4gVGhhdCBjb2RlIGRvZXMgaG93ZXZlciwga25vdw0Kd2hpY2ggb3V0cHV0IHZh
bHVlcyB3aWxsIGJlIHB1YmxpYyBhbmQgd2hpY2ggbm90LiBGb3IgbWUsDQp0aGF0IGltcGxpZXMg
dGhhdCBhbnkgZ29vZCBzZXBhcmF0aW9uIHNjaGVtZSBhcHBsaWVkIHdpdGhpbg0KdGhlIFRMUyBj
b2RlIHRoYXQgZGlmZmVyZW50aWF0ZXMgYmV0d2VlbiBwdWJsaWMgYW5kIG5vbg0KcHVibGljIG91
dHB1dHMgaXMgYSBnb29kIHBsYW4uIFllcywgaWYgYW4gYXR0YWNrZXIgY2FuIGJvcmsNCnlvdXIg
Q1NQUk5HLCB0aGV5IG1heSBiZSBhYmxlIHRvIGdldCBhdCB0aGUgVExTIGNvZGUgdG9vDQpzb21l
dGltZXMsIGJ1dCBJJ2QgYXJndWUgdGhlIGRlZmVuY2UgaW4gZGVwdGggaXMgd29ydGh3aGlsZS4N
Cg0KQ2hlZXJzLA0KUy4NCg0KT24gMjgvMDcvMTcgMTQ6MzcsIERhbiBCcm93biB3cm90ZToNCj4g
SSB0cnkgYmVsb3cgdG8gYmV0dGVyIGV4cGxhaW4gbXkgcG9pbnRzIGFnYWluc3Qgc2VwYXJhdGVk
IHB1YmxpYyBhbmQgcHJpdmF0ZSBDU1BSTkcgaW5zdGFuY2VzLg0KPg0KPiBQZXJoYXBzIHRoZSBl
YXNpZXN0IHdheSB0byBnZXQgImluZGVwZW5kZW50IiBzZWVkcyBmb3IgdGhlIHR3byBpbnN0YW5j
ZXMgb2YgYSBDU1BSTkcsIGlzIHRvIHVzZSBhIHRoaXJkIENTUFJORyBpbnN0YW5jZSB0byBnZW5l
cmF0ZSB0aGUgc2VlZHMuICBCdXQgdGhlbiB0aGUgcHJvYmxlbSBhcmlzZXMgYWdhaW4sIGlmIHRo
ZSAzIENTUFJOR3MgYXJlIGJhZCBlbm91Z2gsICgwPXNlZWRlciwgMT1wdWJsaWMsIDI9cHJpdmF0
ZSksIHRoZXJlIGlzIGEgcmlzayB0aGF0Og0KPg0KPiBQdWJsaWNfbm9uY2U9b3V0cHV0MT0+c2Vl
ZDE9b3V0cHV0MF9mb3JfMT0+c2VlZDA9Pm91dHB1dDBfZm9yXzI9c2VlZDI9Pm91dHB1dF8yPXBy
aXZhdGVfa2V5PVRMU19pbnNlY3VyaXR5Lg0KPg0KPiBJbiBzaG9ydCwgZ2VuZXJhbGx5IHNwZWFr
aW5nLCB0aHJlZSBiYWQgQ1NQUk5HcyBkbyBub3QgY29tYmluZSBlYXNpbHkgaW50byAxIGdvb2Qg
Q1NQUk5HLg0KPg0KPiAoSSdtIG5vdCB5ZXQgc3VyZSBpZiB0aGlzIGF0dGFjayBvbiB0aHJlZSBD
U1BSTkdzIGNvbWJpbmVkIGFwcGxpZXMgdG8gRHVhbF9FQywgc2luY2UgaXQgbWF5IGRvIHNvbWV0
aGluZyBoYXNoLWxpa2UgdG8gdGhlIHNlZWQgKEkgZm9yZ290IGRldGFpbHMpLCBhbmQgYWxzbyBv
dXRwdXQgbGVha3MgdGhlIG5leHQgc3RhdGUsIG5vdCB0aGUgcHJldmlvdXMgc3RhdGUsIGFzIEkg
cmVjYWxsLCBzbyB0aGF0IG1pZ2h0IGJyZWFrIHRoZSBjaGFpbiBhYm92ZS4pDQo+DQo+IFRoZSBh
bHRlcm5hdGl2ZSB0byBhIDNyZCBDU1BSTkcgaXMgdG8gZ2V0IHRoZSBzZWVkcyBmcm9tIGRpcmVj
dGx5IGZyb20gYSByYXcgZW50cm9weSBzb3VyY2UuIEluIHRoYXQgY2FzZSwga2VlcCBpbiBtaW5k
IHRoYXQgb25lIG9mIHRoZSBwdXJwb3NlcyBvZiBDU1BSTkdzIGlzIHRoYXQgcmF3IGVudHJvcHkg
c291cmNlcyBhcmUgdW5yZWxpYWJsZSAoc29tZXRpbWVzIHN0YWxsLCBldGMuIFtyZWZlcmVuY2Vz
IHRvIGJlIGFkZGVkXSkgYW5kIGdlbmVyYWxseSB3ZWFrIG9uIHRoZSBpbmRlcGVuZGVuY2UgKHRo
ZXkgYXJlIG5vbi11bmlmb3JtLCBoZW5jZSBoYXZlIGNvcnJlbGF0aW9ucykuICBDU1BSTkdzIGFy
ZSBzdXBwb3NlZCB0byBjb3JyZWN0IHRoZXNlIGRlZmljaWVuY2llcywgYW1vbmcgb3RoZXIgdGhp
bmdzLiAgU28sIGlmIHRoZSAyIHNlZWRzIGFyZSBnZW5lcmF0ZWQgZGlyZWN0bHkgZnJvbSBhIHJh
dyBlbnRyb3B5IHNvdXJjZXMgKHdpdGhvdXQgYSBDU1BSTkcpLCB0d28gdGhpbmdzIG1heSBnbyB3
cm9uZy4gRmlyc3QsIGRlcml2aW5nIG9uZSBzZWVkIGZyb20gdGhlIG90aGVyIG1pZ2h0IGJlIGZl
YXNpYmxlIGJlY2F1c2Ugb2Ygbm9uLXVuaWZvcm1pdHkuIEEgYmFkIENTUFJORyBtaWdodCBlbmFi
bGUgdGhpcyB0aGlzIHRvIGJlIGV4cGxvaXRlZCwgYnkgZmluZGluZyBvbmUgc2VlZCBmcm9tIHRo
ZSBvdGhlci4gIFNlY29uZCwgaWYgdGhlIGVudHJvcHkgc291cmNlIHN0YWxscyAoZG93biBhIHRy
aWNrbGUgb2YgbG93IGVudHJvcHkpLCBiZXR3ZWVuIHRvbyBjbG9zZSBzZWVkIHJlcXVlc3RzIC0g
YWNjaWRlbnRhbGx5IC0gdGhlbiBldmVuIGEgZ29vZCBDU1BSTkcgY291bGRuJ3QgY29wZS4NCj4N
Cj4gTWF5YmUsIGFsbCB0aGlzIHdvdWxkbid0IGJlIGEgcHJvYmxlbSBvbiBtYW55IGhpZ2hlciBl
bmQgc3lzdGVtcywgd2l0aCBoaWdoIGVudHJvcHksIHNvIG15IGNvbmNlcm4gaXMgbG93ZXIgZW5k
IHN5c3RlbXMsIGFuZCBhbHNvIHVubmVjZXNzYXJ5IGNvbXBsaWNhdGlvbnMgb2YgbWFpbnRhaW5p
bmcgbXVsdGlwbGUgYmFkIENTUFJOR3MsIHBvdGVudGlhbGx5IHRvIG5vIGF2YWlsLg0KPg0KPiBG
aW5hbGx5LCBvbiBzeXN0ZW1zIHdpdGggYSBsaW51eC1zdHlsZSBpbnRlcmZhY2UsIC9kZXYvdXJh
bmRvbSBhbmQgL2Rldi9yYW5kb20gY291bGQgYmUgdXNlZCBhcyB0aGUgdHdvIENTUFJOR3Mgb24g
c29tZSBzeXN0ZW1zIChvciBzZWVkIHNvdXJjZXMpLCBhbHRob3VnaCBJIHRoaW5rIG9uZSBvZiB0
aGVzZSBpcyBub3cgZGVwcmVjYXRlZD8NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRscy1ib3Vu
Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFN0ZXBoZW4gRmFycmVsbA0KPiBTZW50OiBGcmlk
YXksIEp1bHkgMjgsIDIwMTcgNDo0NyBBTQ0KPiBUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u
Y29tPG1haWx0bzpla3JAcnRmbS5jb20+PjsgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExM
IDx1cmlAbGwubWl0LmVkdTxtYWlsdG86dXJpQGxsLm1pdC5lZHU+Pg0KPiBDYzogdGxzQGlldGYu
b3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbVExTXSAzMiBieXRlIHJh
bmRvbXMgaW4gVExTMS4zIGhlbGxvJ3MNCj4NCj4NCj4gSGl5YSwNCj4NCj4gT24gMjgvMDcvMTcg
MDA6NTAsIEVyaWMgUmVzY29ybGEgd3JvdGU6DQo+PiBJIHVzZWQgdGhlIHRlcm0gInNlcGFyYXRl
IiBoZXJlLCB3aGljaCB3YXMgaW50ZW5kZWQgdG8gY29udmV5IHRoaXMsDQo+PiBidXQgaWYgcGVv
cGxlIHRoaW5rICJpbmRlcGVuZGVudCIgb3Igc29tZXRoaW5nIGlzIGJldHRlciwgaGFwcHkgdG8g
Y2hhbmdlLg0KPg0KPiBJIHRoaW5rIHlvdXIgY2hhbmdlIGlzIGEgZmluZSBpbXByb3ZlbWVudCBv
dmVyIC0yMSwgdGhhbmtzLg0KPiAoQW5kIG15IHN1Z2dlc3RlZCB0ZXh0IHdhcyBhcyBpbXBlcmZl
Y3QgYXMgSSB1c3VhbGx5IG1hbmFnZTotKQ0KPg0KPiBJJ20gbm90IGNsZWFyIGlmIGltcGxlbWVu
dGVycyB3aWxsIG9yIHdpbGwgbm90IGdldCB0aGUgcmFtaWZpY2F0aW9ucyBvZiAic2VwYXJhdGUi
IChvciAiaW5kZXBlbmRlbnQiKSwgc28gSSB0aGluayB3ZSBvdWdodCBkZXNjcmliZSAob3IgcmVm
ZXJlbmNlKSBhdCBsZWFzdCBvbmUgd2F5IGluIHdoaWNoIHRoYXQgc2VwYXJhdGlvbiBjYW4gYmUg
YWNoaWV2ZWQuDQo+DQo+IEkgYWxzbyB0aGluayB3ZSBvdWdodCBhdCBsZWFzdCBSRUNPTU1FTkQg
c2VwYXJhdGUgQ1NQUk5Hcy4NCj4gSSdkIHByZWZlciBhIE1VU1QgbXlzZWxmIGJ1dCBzaW5jZSB0
aGVyZSdzIG5vIG9uZSBnb29kIHdheSB3ZSBjYW4gZGVzY3JpYmUgdG8gYWNoaWV2ZSB0aGUgZWZm
ZWN0IHRoYXQnZCB3b3JrIGluIGFsbCBjYXNlcywgSSBkb24ndCB0aGluayB3ZSBjYW4gc2F5IE1V
U1QuDQo+DQo+IENoZWVycywNCj4gUy4NCj4NCj4NCj4+DQo+PiAtRWtyDQo+Pg0KPj4NCj4+IE9u
IFRodSwgSnVsIDI3LCAyMDE3IGF0IDQ6NDMgUE0sIEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBN
SVRMTCA8DQo+PiB1cmlAbGwubWl0LmVkdTxtYWlsdG86dXJpQGxsLm1pdC5lZHU+PiB3cm90ZToN
Cj4+DQo+Pj4gUmVzcGVjdGZ1bGx5IGRpc2FncmVlLiBIYXZpbmcgdHdvIGNyeXB0b2dyYXBoaWNh
bGx5IGluZGVwZW5kZW50DQo+Pj4gUFJOR3MsIG9uZSBmb3IgcHVibGljIGRhdGEgYW5kIG9uZSBm
b3Iga2V5IG1hdGVyaWFsLCBJTUhPIGlzIGEgZ29vZA0KPj4+IGlkZWEuIE9mIGNvdXJzZSwgYm90
aCBzaG91bGQgYmUgcHJvcGVybHkgc2VlZGVkIC0gYnV0IHRoYXQncyBhIGRpZmZlcmVudCBpc3N1
ZS4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4gVXJpDQo+Pj4NCj4+PiBTZW50IGZyb20gbXkgaVBo
b25lDQo+Pj4NCj4+PiBPbiBKdWwgMjcsIDIwMTcsIGF0IDE5OjMzLCBEYW4gQnJvd24gPGRhbmli
cm93bkBibGFja2JlcnJ5LmNvbTxtYWlsdG86ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tPj4gd3Jv
dGU6DQo+Pj4NCj4+Pg0KPj4+IEkgZG9uJ3QgdGhpbmsgMiBDU1BSTkdzIGlzIGEgZ29vZCBpZGVh
Lg0KPj4+DQo+Pj4gV2FzbuKAmXQgdGhlcmUgYSBmZXcgeWVhcnMgYmFjayBzb21lIFJTQSBrZXlz
IHdpdGggc2VwYXJhdGUgcCBhbmQgcSwNCj4+PiBnZW5lcmF0ZWQgaW5kZXBlbmRlbnRseSBsZWFk
aW5nIHRvIGFuIGF0dGFjay4uLg0KPj4+DQo+Pj4gSGVyZSBpZiB0aGUgc2VlZHMgdG8gaW5pdGlh
bGl6ZSB0aGUgUk5HUyBhcmUgcmVsYXRlZCwgb3Igb25lIGlzIHdlYWssDQo+Pj4gb3Igd29yc3Qg
aWYgdGhlIHNlZWQgaXMgYSByYXcgc291cmNlIHRoYXQgZG9lc27igJl0IGNoYW5nZSBpbiB0aGUN
Cj4+PiBtb21lbnRzIGJldHdlZW4gdGhlIHR3byBDU1BSTkcgaW5pdHMsIHRoYXQnZCBiZSBiYWQs
IGV2ZW4gaWYgdGhlIENTUFJOR3Mgd2VyZSBnb29kLg0KPj4+ICpGcm9tOiAqRXJpYyBSZXNjb3Js
YQ0KPj4+ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMjcsIDIwMTcgNjozNCBQTQ0KPj4+ICpUbzog
KlN0ZXBoZW4gRmFycmVsbA0KPj4+ICpDYzogKnRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYu
b3JnPg0KPj4+ICpTdWJqZWN0OiAqUmU6IFtUTFNdIDMyIGJ5dGUgcmFuZG9tcyBpbiBUTFMxLjMg
aGVsbG8ncw0KPj4+DQo+Pj4gU3BlYyB1cGRhdGVkIGhlcmU7DQo+Pj4gaHR0cHM6Ly9naXRodWIu
Y29tL3Rsc3dnL3RsczEzLXNwZWMvY29tbWl0LzQ2NWRlMGUxODliMmI1OTA5MGQwZWFjMGFjDQo+
Pj4gYmM0Mg0KPj4+IDk0MmFmOWNhNzcNCj4+Pg0KPj4+IC1Fa3INCj4+Pg0KPj4+DQo+Pj4gT24g
V2VkLCBKdWwgMjYsIDIwMTcgYXQgNDoyNyBQTSwgU3RlcGhlbiBGYXJyZWxsIDwNCj4+PiBzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4g
d3JvdGU6DQo+Pj4NCj4+Pj4NCj4+Pj4gSSd2ZSBzdWdnZXN0ZWQgc29tZSB0ZXh0IGZvciB0aGlz
IGluIGEgUFIgWzFdIGJhc2VkIG9uIHdoYXQgcGVvcGxlDQo+Pj4+IGhhdmUgc2FpZCBpbiB0aGlz
IHRocmVhZC4NCj4+Pj4NCj4+Pj4gSSdtIHN1cmUgdGhhdCBjYW4gYmUgZnVydGhlciBpbXByb3Zl
ZC4NCj4+Pj4NCj4+Pj4gSXQgbWlnaHQgYmUgbm8gaGFybSB0byBhZGQgbW9yZSBwb2ludGVycyB0
byB0aGF0IGFwcGVuZGl4IGZyb20NCj4+Pj4gZWxzZXdoZXJlIGluIHRoZSBzcGVjLCBhbmQvb3Ig
dG8gYWRkIGEgbGlzdCBvZiB0aGUgdmFyaW91cw0KPj4+PiBwdWJsaWMvcHJpdmF0ZSByYW5kb20g
bnVtYmVycyB0aGF0IGFyZSBuZWVkZWQgdG8gdGhhdCBhcHBlbmRpeC4gKEknZA0KPj4+PiBiZSBo
YXBweSB0byBkbyBhIHBhc3MgdG8gaWRlbnRpZnkgdGhvc2UgaWYgZm9sa3MgYmFzaWNhbGx5IGxp
a2UgdGhpcw0KPj4+PiBraW5kIG9mIGFkZGl0aW9uLikNCj4+Pj4NCj4+Pj4gSSBhbHNvIG5lZWQg
dG8gZmlndXJlIG91dCBob3cgdG8gaGFuZGxlIHRoZSByZWZlcmVuY2UgcHJvcGVybHk6LSkNCj4+
Pj4gQ2FuIGRvIHRoYXQgdG9tb3Jyb3cuDQo+Pj4+DQo+Pj4+IENoZWVycywNCj4+Pj4gUy4NCj4+
Pj4NCj4+Pj4gWzFdIGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL3B1bGwvMTA2
OA0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPj4+PiBUTFMgbWFpbGluZyBsaXN0DQo+Pj4+IFRMU0BpZXRmLm9yZzxtYWls
dG86VExTQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3Rscw0KPj4+Pg0KPj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+Pj4gVExTIG1haWxpbmcgbGlzdA0KPj4+IFRMU0BpZXRmLm9yZzxt
YWlsdG86VExTQGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vdGxzDQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+Pj4gVExTIG1haWxpbmcgbGlzdA0KPj4+IFRMU0BpZXRmLm9yZzxt
YWlsdG86VExTQGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vdGxzDQo+Pj4NCj4+Pg0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFRMUyBtYWlsaW5nIGxpc3QNCj4+IFRMU0Bp
ZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby90bHMNCj4+DQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFp
bHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
dGxzDQoNCg0KDQotLQ0KQ29sbQ0K

--_000_2017072920303185730135935716296blackberrycom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i
d2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRpYWw7IGZvbnQtZmFtaWx5OkNhbGlicmksJ1NsYXRl
IFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmOyBjb2xvcjpyZ2IoMzEsNzMsMTI1KTsgdGV4dC1h
bGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0K4oCOU2Vj
dGlvbiAzLCBvZiB0aGUgZXByaW50ICZxdW90O1JvbiBpcyB3cm9uZywgV2hpdCBpcyByaWdodCZx
dW90Oywgc3Vic2VjdGlvbiAmcXVvdDtNb2R1bGkgd2l0aCBzaGFyZWQgcHJpbWVzJnF1b3Q7LCBz
dWdnZXN0cyB0byBtZSB0aGF0IGl0J3Mgbm90IHVubGlrZWx5IHdoZW4gc2VlZGluZyB0d28gc2Vj
cmV0cyBuZWFyIGluIHRpbWUsIG9uZSBoYXMgbG93IGVudHJvcHkgKGJ5IGFjY2lkZW50KS4gVGhh
dCdzIG5vdCB0aGUgb25seSBleHBsYW5hdGlvbiBvZiB0aGUgb2JzZXJ2ZWQNCiBzaGFyZWQgcHJp
bWVzLCBidXQgaXMgcGxhdXNpYmxlIGFuZCByZWxldmFudCB0byB0aGUgcXVlc3Rpb24gYXQgaGFu
ZC4gKEkgdGhvdWdodCBJIG1lbnRpb25lZCB0aGlzIGVhcmxpZXIuKTxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpLCdTbGF0ZSBQcm8nLHNhbnMtc2VyaWYsc2Fucy1zZXJpZjsgZm9udC1z
aXplOmluaXRpYWw7IGxpbmUtaGVpZ2h0OmluaXRpYWw7IHRleHQtYWxpZ246aW5pdGlhbCI+PC9z
cGFuPjwvZGl2Pg0KPHRhYmxlIHdpZHRoPSIxMDAlIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjp3
aGl0ZTsgYm9yZGVyLXNwYWNpbmc6MHB4Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBjb2xzcGFuPSIy
IiBzdHlsZT0iZm9udC1zaXplOmluaXRpYWw7IHRleHQtYWxpZ246aW5pdGlhbDsgYmFja2dyb3Vu
ZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTpzb2xp
ZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6cmdiKDE4MSwxOTYsMjIzKTsgYm9yZGVyLXRv
cC13aWR0aDoxcHQ7IHBhZGRpbmc6M3B0IDBpbiAwaW47IGZvbnQtZmFtaWx5OlRhaG9tYSwnQkIg
QWxwaGEgU2FucycsJ1NsYXRlIFBybyc7IGZvbnQtc2l6ZToxMHB0Ij4NCjxkaXY+PGI+RnJvbTog
PC9iPkNvbG0gTWFjQ8OhcnRoYWlnaDwvZGl2Pg0KPGRpdj48Yj5TZW50OiA8L2I+U2F0dXJkYXks
IEp1bHkgMjksIDIwMTcgMjowNCBQTTwvZGl2Pg0KPGRpdj48Yj5UbzogPC9iPkRhbiBCcm93bjwv
ZGl2Pg0KPGRpdj48Yj5DYzogPC9iPlN0ZXBoZW4gRmFycmVsbDsgRXJpYyBSZXNjb3JsYTsgQmx1
bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMOyB0bHNAaWV0Zi5vcmc8L2Rpdj4NCjxkaXY+PGI+
U3ViamVjdDogPC9iPlJlOiBbVExTXSAzMiBieXRlIHJhbmRvbXMgaW4gVExTMS4zIGhlbGxvJ3M8
L2Rpdj4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxkaXYgc3R5
bGU9ImJvcmRlci1zdHlsZTpzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6cmdiKDE4
NiwxODgsMjA5KTsgYm9yZGVyLXRvcC13aWR0aDoxcHQ7IGZvbnQtc2l6ZTppbml0aWFsOyB0ZXh0
LWFsaWduOmluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQo8L2Rp
dj4NCjxicj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l
eHRyYSI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+SSBkb24ndCBzZWUg
YW55dGhpbmcgcmVsZXZhbnQgdG8gdGhlIHByb2JsZW0gYXQgaGFuZCBpbiB0aGF0IHBhcGVyLiBE
aWQgeW91IHJlZmVyZW5jZSB0aGUgcmlnaHQgb25lPyBUaGVyZSBhcmUgc29tZSBtZW50aW9ucyBh
Ym91dCBub3QgcmUtdXNpbmcgcmFuZG9tIHNlY3JldHMsIGJ1dCB0aGF0IGFwcGxpZXMgbm8gbWF0
dGVyIGhvdyBtYW55IFJOR3MgeW91IHVzZS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls
X2V4dHJhIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj5JbiB5b3VyIHBy
ZXZpb3VzIG1haWwsIGV2ZW4gaWYgYW4gaW1wbGVtZW50ZXIgd2VyZSB0byBzZWVkIHR3byBSTkdz
IGZyb20gb25lIENTUFJORywgYW5kIGFsbCAzIGFyZSBiYWQgZ2VuZXJhdG9yLCB0aGlzIGlzIHN0
aWxsIHN0cmljdGx5IGJldHRlciB0aGFuIG9uZSBicm9rZW4gZ2VuZXJhdG9yOyBiZWNhdXNlIHRo
ZSBhbW91bnQgb2Ygd29yayBhbiBhdHRhY2tlciBtdXN0IGRvIGlzIGZhciBncmVhdGVyLg0KICZu
YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9Imdt
YWlsX3F1b3RlIj5PbiBTYXQsIEp1bCAyOSwgMjAxNyBhdCA4OjU0IEFNLCBEYW4gQnJvd24gPHNw
YW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5pYnJvd25AYmxhY2tiZXJyeS5j
b20iIHRhcmdldD0iX2JsYW5rIj5kYW5pYnJvd25AYmxhY2tiZXJyeS5jb208L2E+Jmd0Ozwvc3Bh
bj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy
Z2luOjAgMCAwIC44ZXg7IGJvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkOyBwYWRkaW5nLWxlZnQ6
MWV4Ij4NCjxhIGhyZWY9Imh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMTIvMDY0IiByZWw9Im5v
cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2VwcmludC5pYWNyLm9yZy8yMDEyLzx3
YnI+MDY0PC9hPjxicj4NCm1lbnRpb25zIHRoZSBwcm9ibGVtIG9mIGdlbmVyYXRpbmcgbXVsdGlw
bGUgc2VjcmV0cyBpbnN0ZWFkIG9mIGEgc2luZ2xlIHNlY3JldDxicj4NCjwvYmxvY2txdW90ZT4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N
CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4
OyBib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQom
bmJzcDsgT3JpZ2luYWwgTWVzc2FnZTxicj4NCkZyb206IFN0ZXBoZW4gRmFycmVsbDxicj4NClNl
bnQ6IEZyaWRheSwgSnVseSAyOCwgMjAxNyAxMTo0OCBBTTxicj4NClRvOiBEYW4gQnJvd247IEVy
aWMgUmVzY29ybGE7IEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTDxicj4NCjxkaXYgY2xh
c3M9IkhPRW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+Q2M6IDxhIGhyZWY9Im1haWx0bzp0bHNAaWV0
Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW1RMU10gMzIgYnl0ZSBy
YW5kb21zIGluIFRMUzEuMyBoZWxsbydzPGJyPg0KPGJyPg0KPGJyPg0KSSBkb24ndCB0aGluayB0
aGlzIGlzIHNpbXBseSBhIGNhc2Ugb2YgbXVsdGlwbGUgQ1NQUk5Hcy48YnI+DQo8YnI+DQpNeSBn
dWVzcyBpcyBtYW55IFRMUyBpbXBsZW1lbnRhdGlvbnMgZG9uJ3QgaGF2ZSB2aXNpYmlsaXR5PGJy
Pg0KaW50byBob3cgdGhlIENTUFJORyBvcGVyYXRlcy4gVGhhdCBjb2RlIGRvZXMgaG93ZXZlciwg
a25vdzxicj4NCndoaWNoIG91dHB1dCB2YWx1ZXMgd2lsbCBiZSBwdWJsaWMgYW5kIHdoaWNoIG5v
dC4gRm9yIG1lLDxicj4NCnRoYXQgaW1wbGllcyB0aGF0IGFueSBnb29kIHNlcGFyYXRpb24gc2No
ZW1lIGFwcGxpZWQgd2l0aGluPGJyPg0KdGhlIFRMUyBjb2RlIHRoYXQgZGlmZmVyZW50aWF0ZXMg
YmV0d2VlbiBwdWJsaWMgYW5kIG5vbjxicj4NCnB1YmxpYyBvdXRwdXRzIGlzIGEgZ29vZCBwbGFu
LiBZZXMsIGlmIGFuIGF0dGFja2VyIGNhbiBib3JrPGJyPg0KeW91ciBDU1BSTkcsIHRoZXkgbWF5
IGJlIGFibGUgdG8gZ2V0IGF0IHRoZSBUTFMgY29kZSB0b288YnI+DQpzb21ldGltZXMsIGJ1dCBJ
J2QgYXJndWUgdGhlIGRlZmVuY2UgaW4gZGVwdGggaXMgd29ydGh3aGlsZS48YnI+DQo8YnI+DQpD
aGVlcnMsPGJyPg0KUy48YnI+DQo8YnI+DQpPbiAyOC8wNy8xNyAxNDozNywgRGFuIEJyb3duIHdy
b3RlOjxicj4NCiZndDsgSSB0cnkgYmVsb3cgdG8gYmV0dGVyIGV4cGxhaW4gbXkgcG9pbnRzIGFn
YWluc3Qgc2VwYXJhdGVkIHB1YmxpYyBhbmQgcHJpdmF0ZSBDU1BSTkcgaW5zdGFuY2VzLjxicj4N
CiZndDs8YnI+DQomZ3Q7IFBlcmhhcHMgdGhlIGVhc2llc3Qgd2F5IHRvIGdldCAmcXVvdDtpbmRl
cGVuZGVudCZxdW90OyBzZWVkcyBmb3IgdGhlIHR3byBpbnN0YW5jZXMgb2YgYSBDU1BSTkcsIGlz
IHRvIHVzZSBhIHRoaXJkIENTUFJORyBpbnN0YW5jZSB0byBnZW5lcmF0ZSB0aGUgc2VlZHMuJm5i
c3A7IEJ1dCB0aGVuIHRoZSBwcm9ibGVtIGFyaXNlcyBhZ2FpbiwgaWYgdGhlIDMgQ1NQUk5HcyBh
cmUgYmFkIGVub3VnaCwgKDA9c2VlZGVyLCAxPXB1YmxpYywgMj1wcml2YXRlKSwgdGhlcmUgaXMg
YQ0KIHJpc2sgdGhhdDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQdWJsaWNfbm9uY2U9b3V0cHV0MT0m
Z3Q7c2VlZDE9PHdicj5vdXRwdXQwX2Zvcl8xPSZndDtzZWVkMD0mZ3Q7b3V0cHV0MF88d2JyPmZv
cl8yPXNlZWQyPSZndDtvdXRwdXRfMj1wcml2YXRlXzx3YnI+a2V5PVRMU19pbnNlY3VyaXR5Ljxi
cj4NCiZndDs8YnI+DQomZ3Q7IEluIHNob3J0LCBnZW5lcmFsbHkgc3BlYWtpbmcsIHRocmVlIGJh
ZCBDU1BSTkdzIGRvIG5vdCBjb21iaW5lIGVhc2lseSBpbnRvIDEgZ29vZCBDU1BSTkcuPGJyPg0K
Jmd0Ozxicj4NCiZndDsgKEknbSBub3QgeWV0IHN1cmUgaWYgdGhpcyBhdHRhY2sgb24gdGhyZWUg
Q1NQUk5HcyBjb21iaW5lZCBhcHBsaWVzIHRvIER1YWxfRUMsIHNpbmNlIGl0IG1heSBkbyBzb21l
dGhpbmcgaGFzaC1saWtlIHRvIHRoZSBzZWVkIChJIGZvcmdvdCBkZXRhaWxzKSwgYW5kIGFsc28g
b3V0cHV0IGxlYWtzIHRoZSBuZXh0IHN0YXRlLCBub3QgdGhlIHByZXZpb3VzIHN0YXRlLCBhcyBJ
IHJlY2FsbCwgc28gdGhhdCBtaWdodCBicmVhayB0aGUgY2hhaW4gYWJvdmUuKTxicj4NCiZndDs8
YnI+DQomZ3Q7IFRoZSBhbHRlcm5hdGl2ZSB0byBhIDNyZCBDU1BSTkcgaXMgdG8gZ2V0IHRoZSBz
ZWVkcyBmcm9tIGRpcmVjdGx5IGZyb20gYSByYXcgZW50cm9weSBzb3VyY2UuIEluIHRoYXQgY2Fz
ZSwga2VlcCBpbiBtaW5kIHRoYXQgb25lIG9mIHRoZSBwdXJwb3NlcyBvZiBDU1BSTkdzIGlzIHRo
YXQgcmF3IGVudHJvcHkgc291cmNlcyBhcmUgdW5yZWxpYWJsZSAoc29tZXRpbWVzIHN0YWxsLCBl
dGMuIFtyZWZlcmVuY2VzIHRvIGJlIGFkZGVkXSkgYW5kIGdlbmVyYWxseQ0KIHdlYWsgb24gdGhl
IGluZGVwZW5kZW5jZSAodGhleSBhcmUgbm9uLXVuaWZvcm0sIGhlbmNlIGhhdmUgY29ycmVsYXRp
b25zKS4mbmJzcDsgQ1NQUk5HcyBhcmUgc3VwcG9zZWQgdG8gY29ycmVjdCB0aGVzZSBkZWZpY2ll
bmNpZXMsIGFtb25nIG90aGVyIHRoaW5ncy4mbmJzcDsgU28sIGlmIHRoZSAyIHNlZWRzIGFyZSBn
ZW5lcmF0ZWQgZGlyZWN0bHkgZnJvbSBhIHJhdyBlbnRyb3B5IHNvdXJjZXMgKHdpdGhvdXQgYSBD
U1BSTkcpLCB0d28gdGhpbmdzIG1heSBnbyB3cm9uZy4NCiBGaXJzdCwgZGVyaXZpbmcgb25lIHNl
ZWQgZnJvbSB0aGUgb3RoZXIgbWlnaHQgYmUgZmVhc2libGUgYmVjYXVzZSBvZiBub24tdW5pZm9y
bWl0eS4gQSBiYWQgQ1NQUk5HIG1pZ2h0IGVuYWJsZSB0aGlzIHRoaXMgdG8gYmUgZXhwbG9pdGVk
LCBieSBmaW5kaW5nIG9uZSBzZWVkIGZyb20gdGhlIG90aGVyLiZuYnNwOyBTZWNvbmQsIGlmIHRo
ZSBlbnRyb3B5IHNvdXJjZSBzdGFsbHMgKGRvd24gYSB0cmlja2xlIG9mIGxvdyBlbnRyb3B5KSwg
YmV0d2VlbiB0b28NCiBjbG9zZSBzZWVkIHJlcXVlc3RzIC0gYWNjaWRlbnRhbGx5IC0gdGhlbiBl
dmVuIGEgZ29vZCBDU1BSTkcgY291bGRuJ3QgY29wZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBNYXli
ZSwgYWxsIHRoaXMgd291bGRuJ3QgYmUgYSBwcm9ibGVtIG9uIG1hbnkgaGlnaGVyIGVuZCBzeXN0
ZW1zLCB3aXRoIGhpZ2ggZW50cm9weSwgc28gbXkgY29uY2VybiBpcyBsb3dlciBlbmQgc3lzdGVt
cywgYW5kIGFsc28gdW5uZWNlc3NhcnkgY29tcGxpY2F0aW9ucyBvZiBtYWludGFpbmluZyBtdWx0
aXBsZSBiYWQgQ1NQUk5HcywgcG90ZW50aWFsbHkgdG8gbm8gYXZhaWwuPGJyPg0KJmd0Ozxicj4N
CiZndDsgRmluYWxseSwgb24gc3lzdGVtcyB3aXRoIGEgbGludXgtc3R5bGUgaW50ZXJmYWNlLCAv
ZGV2L3VyYW5kb20gYW5kIC9kZXYvcmFuZG9tIGNvdWxkIGJlIHVzZWQgYXMgdGhlIHR3byBDU1BS
TkdzIG9uIHNvbWUgc3lzdGVtcyAob3Igc2VlZCBzb3VyY2VzKSwgYWx0aG91Z2ggSSB0aGluayBv
bmUgb2YgdGhlc2UgaXMgbm93IGRlcHJlY2F0ZWQ/PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IFRMUyBbbWFpbHRvOjxhIGhyZWY9
Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP
biBCZWhhbGYgT2YgU3RlcGhlbiBGYXJyZWxsPGJyPg0KJmd0OyBTZW50OiBGcmlkYXksIEp1bHkg
MjgsIDIwMTcgNDo0NyBBTTxicj4NCiZndDsgVG86IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9
Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4mZ3Q7OyBCbHVtZW50aGFsLCBV
cmkgLSAwNTUzIC0gTUlUTEwgJmx0OzxhIGhyZWY9Im1haWx0bzp1cmlAbGwubWl0LmVkdSI+dXJp
QGxsLm1pdC5lZHU8L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzp0bHNAaWV0
Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbVExTXSAzMiBi
eXRlIHJhbmRvbXMgaW4gVExTMS4zIGhlbGxvJ3M8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn
dDsgSGl5YSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAyOC8wNy8xNyAwMDo1MCwgRXJpYyBSZXNj
b3JsYSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBJIHVzZWQgdGhlIHRlcm0gJnF1b3Q7c2VwYXJhdGUm
cXVvdDsgaGVyZSwgd2hpY2ggd2FzIGludGVuZGVkIHRvIGNvbnZleSB0aGlzLDxicj4NCiZndDsm
Z3Q7IGJ1dCBpZiBwZW9wbGUgdGhpbmsgJnF1b3Q7aW5kZXBlbmRlbnQmcXVvdDsgb3Igc29tZXRo
aW5nIGlzIGJldHRlciwgaGFwcHkgdG8gY2hhbmdlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgdGhp
bmsgeW91ciBjaGFuZ2UgaXMgYSBmaW5lIGltcHJvdmVtZW50IG92ZXIgLTIxLCB0aGFua3MuPGJy
Pg0KJmd0OyAoQW5kIG15IHN1Z2dlc3RlZCB0ZXh0IHdhcyBhcyBpbXBlcmZlY3QgYXMgSSB1c3Vh
bGx5IG1hbmFnZTotKTxicj4NCiZndDs8YnI+DQomZ3Q7IEknbSBub3QgY2xlYXIgaWYgaW1wbGVt
ZW50ZXJzIHdpbGwgb3Igd2lsbCBub3QgZ2V0IHRoZSByYW1pZmljYXRpb25zIG9mICZxdW90O3Nl
cGFyYXRlJnF1b3Q7IChvciAmcXVvdDtpbmRlcGVuZGVudCZxdW90OyksIHNvIEkgdGhpbmsgd2Ug
b3VnaHQgZGVzY3JpYmUgKG9yIHJlZmVyZW5jZSkgYXQgbGVhc3Qgb25lIHdheSBpbiB3aGljaCB0
aGF0IHNlcGFyYXRpb24gY2FuIGJlIGFjaGlldmVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYWxz
byB0aGluayB3ZSBvdWdodCBhdCBsZWFzdCBSRUNPTU1FTkQgc2VwYXJhdGUgQ1NQUk5Hcy48YnI+
DQomZ3Q7IEknZCBwcmVmZXIgYSBNVVNUIG15c2VsZiBidXQgc2luY2UgdGhlcmUncyBubyBvbmUg
Z29vZCB3YXkgd2UgY2FuIGRlc2NyaWJlIHRvIGFjaGlldmUgdGhlIGVmZmVjdCB0aGF0J2Qgd29y
ayBpbiBhbGwgY2FzZXMsIEkgZG9uJ3QgdGhpbmsgd2UgY2FuIHNheSBNVVNULjxicj4NCiZndDs8
YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7IFMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC1Fa3I8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgT24gVGh1LCBKdWwgMjcsIDIwMTcgYXQgNDo0MyBQTSwgQmx1bWVudGhhbCwg
VXJpIC0gMDU1MyAtIE1JVExMICZsdDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86dXJp
QGxsLm1pdC5lZHUiPnVyaUBsbC5taXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyZndDsgUmVzcGVjdGZ1bGx5IGRpc2FncmVlLiBIYXZpbmcgdHdvIGNyeXB0
b2dyYXBoaWNhbGx5IGluZGVwZW5kZW50PGJyPg0KJmd0OyZndDsmZ3Q7IFBSTkdzLCBvbmUgZm9y
IHB1YmxpYyBkYXRhIGFuZCBvbmUgZm9yIGtleSBtYXRlcmlhbCwgSU1ITyBpcyBhIGdvb2Q8YnI+
DQomZ3Q7Jmd0OyZndDsgaWRlYS4gT2YgY291cnNlLCBib3RoIHNob3VsZCBiZSBwcm9wZXJseSBz
ZWVkZWQgLSBidXQgdGhhdCdzIGEgZGlmZmVyZW50IGlzc3VlLjxicj4NCiZndDsmZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsmZ3Q7Jmd0OyBVcmk8YnI+DQomZ3Q7
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgU2VudCBmcm9tIG15IGlQaG9uZTxicj4NCiZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBKdWwgMjcsIDIwMTcsIGF0IDE5OjMzLCBEYW4g
QnJvd24gJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5pYnJvd25AYmxhY2tiZXJyeS5jb20iPmRhbmli
cm93bkBibGFja2JlcnJ5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJIGRvbid0IHRoaW5rIDIgQ1NQUk5HcyBp
cyBhIGdvb2QgaWRlYS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgV2FzbuKA
mXQgdGhlcmUgYSBmZXcgeWVhcnMgYmFjayBzb21lIFJTQSBrZXlzIHdpdGggc2VwYXJhdGUgcCBh
bmQgcSw8YnI+DQomZ3Q7Jmd0OyZndDsgZ2VuZXJhdGVkIGluZGVwZW5kZW50bHkgbGVhZGluZyB0
byBhbiBhdHRhY2suLi48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSGVyZSBp
ZiB0aGUgc2VlZHMgdG8gaW5pdGlhbGl6ZSB0aGUgUk5HUyBhcmUgcmVsYXRlZCwgb3Igb25lIGlz
IHdlYWssPGJyPg0KJmd0OyZndDsmZ3Q7IG9yIHdvcnN0IGlmIHRoZSBzZWVkIGlzIGEgcmF3IHNv
dXJjZSB0aGF0IGRvZXNu4oCZdCBjaGFuZ2UgaW4gdGhlPGJyPg0KJmd0OyZndDsmZ3Q7IG1vbWVu
dHMgYmV0d2VlbiB0aGUgdHdvIENTUFJORyBpbml0cywgdGhhdCdkIGJlIGJhZCwgZXZlbiBpZiB0
aGUgQ1NQUk5HcyB3ZXJlIGdvb2QuPGJyPg0KJmd0OyZndDsmZ3Q7ICpGcm9tOiAqRXJpYyBSZXNj
b3JsYTxicj4NCiZndDsmZ3Q7Jmd0OyAqU2VudDogKlRodXJzZGF5LCBKdWx5IDI3LCAyMDE3IDY6
MzQgUE08YnI+DQomZ3Q7Jmd0OyZndDsgKlRvOiAqU3RlcGhlbiBGYXJyZWxsPGJyPg0KJmd0OyZn
dDsmZ3Q7ICpDYzogKjxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9yZzwv
YT48YnI+DQomZ3Q7Jmd0OyZndDsgKlN1YmplY3Q6ICpSZTogW1RMU10gMzIgYnl0ZSByYW5kb21z
IGluIFRMUzEuMyBoZWxsbydzPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFNw
ZWMgdXBkYXRlZCBoZXJlOzxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1
Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9jb21taXQvNDY1ZGUwZTE4OWIyYjU5MDkwZDBlYWMwYWMi
IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL3Rs
c3dnLzx3YnI+dGxzMTMtc3BlYy9jb21taXQvPHdicj40NjVkZTBlMTg5YjJiNTkwOTBkMGVhYzBh
YzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgYmM0Mjxicj4NCiZndDsmZ3Q7Jmd0OyA5NDJhZjljYTc3
PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC1Fa3I8YnI+DQomZ3Q7Jmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gV2VkLCBKdWwgMjYsIDIw
MTcgYXQgNDoyNyBQTSwgU3RlcGhlbiBGYXJyZWxsICZsdDs8YnI+DQomZ3Q7Jmd0OyZndDsgPGEg
aHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiPnN0ZXBoZW4uZmFycmVsbEBj
cy50Y2QuaWU8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJJ3ZlIHN1Z2dlc3RlZCBzb21lIHRleHQgZm9y
IHRoaXMgaW4gYSBQUiBbMV0gYmFzZWQgb24gd2hhdCBwZW9wbGU8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7IGhhdmUgc2FpZCBpbiB0aGlzIHRocmVhZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyBJJ20gc3VyZSB0aGF0IGNhbiBiZSBmdXJ0aGVyIGltcHJvdmVkLjxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEl0IG1pZ2h0IGJlIG5v
IGhhcm0gdG8gYWRkIG1vcmUgcG9pbnRlcnMgdG8gdGhhdCBhcHBlbmRpeCBmcm9tPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyBlbHNld2hlcmUgaW4gdGhlIHNwZWMsIGFuZC9vciB0byBhZGQgYSBsaXN0
IG9mIHRoZSB2YXJpb3VzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBwdWJsaWMvcHJpdmF0ZSByYW5k
b20gbnVtYmVycyB0aGF0IGFyZSBuZWVkZWQgdG8gdGhhdCBhcHBlbmRpeC4gKEknZDxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsgYmUgaGFwcHkgdG8gZG8gYSBwYXNzIHRvIGlkZW50aWZ5IHRob3NlIGlm
IGZvbGtzIGJhc2ljYWxseSBsaWtlIHRoaXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGtpbmQgb2Yg
YWRkaXRpb24uKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEkg
YWxzbyBuZWVkIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGhhbmRsZSB0aGUgcmVmZXJlbmNlIHByb3Bl
cmx5Oi0pPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDYW4gZG8gdGhhdCB0b21vcnJvdy48YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyBTLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
IFsxXSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzEw
NjgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29t
L3Rsc3dnLzx3YnI+dGxzMTMtc3BlYy9wdWxsLzEwNjg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7IFRMUyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1h
aWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiByZWw9
Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vPHdicj5saXN0aW5mby90bHM8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBUTFMgbWFpbGluZyBs
aXN0PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0Bp
ZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL3RsczwvYT48YnI+
DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NCiZndDsm
Z3Q7Jmd0OyBUTFMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0
bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHJlbD0ibm9yZWZl
cnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2Jy
Pmxpc3RpbmZvL3RsczwvYT48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fPGJyPg0KJmd0
OyZndDsgVExTIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpUTFNA
aWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJn
ZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8v
dGxzPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQo8YnI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fPGJyPg0KVExT
IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL3RsczwvYT48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KLS0gPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfc2lnbmF0dXJlIj5Db2xtPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_2017072920303185730135935716296blackberrycom_--


From nobody Sat Jul 29 14:19:48 2017
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 4539A131EAA for ; Sat, 29 Jul 2017 14:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level: 
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 Fh5j-xanZ7tc for ; Sat, 29 Jul 2017 14:19:45 -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 41DDB131D0F for ; Sat, 29 Jul 2017 14:19:45 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id l82so81374335ywc.2 for ; Sat, 29 Jul 2017 14:19:45 -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=kjVEpEiuVfpRGzcm/rvfX83uNqazk2Pt2YvGMc1laSw=; b=zKHa0gMhapr2J/OJtPOPHTdx1Y73/Mrmj/uOv/PaTC2KiXzwREx2hX2jk0PmBKofcr qHauFVISOPBK7YLcBuzo7zQCBg2qnP4VO+n/px+lJmeCVQsigcgIDc6sYpIR+gmN10+F CaM4B/Of6U7XeolXJlQhrdvpuzw1pfT+rd7BHvOuyl1u3x06oMej3LQsAGVLwFDlqjvf VzsISTJq6/mxy91QGkmxbOK7G4DChS2MYu0iN6JDNuNWZcPj8jkY1DGJgwKCHnFvoy+A SbnoH2wOQtZwx0AxhhEXlW0yiWedelZE89lbh3lxGuTZr7McagghuRztfDzqRRPfEDDu o9YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kjVEpEiuVfpRGzcm/rvfX83uNqazk2Pt2YvGMc1laSw=; b=eOkBRgMrpZzKDfAN3CKvLTbzNMzgtoDlyHKQURwwZKy5srJXs41ygyTHSpEzlXYUn5 LfPbpECJJxwTkFxlFU/yiH7S/GLC9cPj+oKDcgUtysOQYXvZnWmN5AlBmGlz767k1/If iTUZizcJmlx91/nh1sjIoWQaGuAshhzLWqthXZpAG3CwiVsJEH/Ur12vNSTT1NPNlF8x qCaBGBUS7e57cwhDfFYxJqI9llwlmfWRo2tqYZO51mv5W1FdgDxs/rHBZj2WEY0wObvM 1K8SoXU6kBX1EBLx7KjoFYOYIyUN5q6SRo75hDV5gVHS6aqAcrOWTsCWe/YEkqMPEdHd 10fA==
X-Gm-Message-State: AIVw111xPDM1sejGwVmhhIzoM6m9sOxx9cF/L+terSOrMUrT/Ey/jN9y 1CeDDwfRZtQBv1Ad5PInFh48RQ5k0MqP
X-Received: by 10.129.94.67 with SMTP id s64mr9594342ywb.83.1501363184463; Sat, 29 Jul 2017 14:19:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.71 with HTTP; Sat, 29 Jul 2017 14:19:43 -0700 (PDT)
In-Reply-To: <20170729203031.8573013.59357.16296@blackberry.com>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie> <20170729155445.8573013.35196.16289@blackberry.com>  <20170729203031.8573013.59357.16296@blackberry.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Sat, 29 Jul 2017 14:19:43 -0700
Message-ID: 
To: Dan Brown 
Cc: Stephen Farrell , Eric Rescorla ,  "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114921d24a22fd05557b5b50"
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 29 Jul 2017 21:19:46 -0000

--001a114921d24a22fd05557b5b50
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 29, 2017 at 1:30 PM, Dan Brown  wrote=
:

> =E2=80=8ESection 3, of the eprint "Ron is wrong, Whit is right", subsecti=
on
> "Moduli with shared primes", suggests to me that it's not unlikely when
> seeding two secrets near in time, one has low entropy (by accident). That=
's
> not the only explanation of the observed shared primes, but is plausible
> and relevant to the question at hand. (I thought I mentioned this earlier=
.)
>

If the PRNGs produce identical output, that is bad, but that seems easy to
protect against: check that the seeds are actually different.  This is also
what personalization strings are designed to protect against.

--=20
Colm

--001a114921d24a22fd05557b5b50
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



    On Sat, Jul 29, 2017 at 1:3=
0 PM, Dan Brown <danibrown@blackberry.com> wrote:
    =

    




    

    
=E2=80=8ESection 3, of the eprint "Ron is wrong, Whit is right", =
subsection "Moduli with shared primes", suggests to me that it=
9;s not unlikely when seeding two secrets near in time, one has low entropy=
 (by accident). That's not the only explanation of the observed
 shared primes, but is plausible and relevant to the question at hand. (I t=
hought I mentioned this earlier.)

    If the PRNGs produce identical output, that is bad, but that seems easy =
to protect against: check that the seeds are actually different.=C2=A0 This=
 is also what personalization strings are designed to protect against.=C2=
=A0

    -- 
    Colm
    

    

--001a114921d24a22fd05557b5b50--


From nobody Sat Jul 29 19:39:25 2017
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 B6771131E7F for ; Sat, 29 Jul 2017 19:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 vWNIK-Clq2Lr for ; Sat, 29 Jul 2017 19:39: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 374161317AD for ; Sat, 29 Jul 2017 19:39:19 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6U2dEoJ034233; Sat, 29 Jul 2017 22:39:14 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Dan Brown 
CC: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Stephen Farrell , Eric Rescorla , "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI/QFdXms6d7jEaZNtjFKD2eRqJjeSwAgAC0BYCAAI15AIAAcHmAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDsAgAANUgCAABPRAIAABQKAgAAkyYCAAYN3AIAAELAAgAACowCAAAIWAIAAleMAgABRLoCAACSpAIABlAOAgAAkToCAACi/gIAAZwGA
Date: Sun, 30 Jul 2017 02:39:13 +0000
Message-ID: <2542C946-9777-4404-8CDA-C33C4CE2FFDE@ll.mit.edu>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie> <20170729155445.8573013.35196.16289@blackberry.com>  <20170729203031.8573013.59357.16296@blackberry.com>
In-Reply-To: <20170729203031.8573013.59357.16296@blackberry.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; boundary="Apple-Mail-5A4C1CBC-408B-4A27-8EC6-5AEA1222CCC0"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-30_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707300044
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 30 Jul 2017 02:39:23 -0000

--Apple-Mail-5A4C1CBC-408B-4A27-8EC6-5AEA1222CCC0
Content-Type: multipart/alternative;
	boundary=Apple-Mail-56D3470A-E27B-4B6E-8269-E5852CC2CD10
Content-Transfer-Encoding: 7bit


--Apple-Mail-56D3470A-E27B-4B6E-8269-E5852CC2CD10
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: base64

RGFuLCANCg0KSSBjb25mZXNzIEkgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIGxvZ2ljLiANCg0KQSBQ
Uk5HIGNhbiBiZSBnb29kLCBvciBpdCBjYW4gYmUgYmFkLiBJZiB5b3Ugc2VlZCBtb3JlIHRoYW4g
b25lIFBSTkcsIHlvdXIgc2VlZHMgY291bGQgYmUgY3J5cHRvZ3JhcGhpY2FsbHkgY29ycmVsYXRl
ZCAod29yc3QgY2FzZSksIG9yIHRoZXkgbWF5IGJlIGNyeXB0b2dyYXBoaWNhbGx5IGluZGVwZW5k
ZW50ICh3aGF0IHdlIHdhbnQgYW5kIGV4cGVjdCkuDQoNCkF0IGxlYXN0IG9uZSBvZiB0aGUgUFJO
R3MgaGFzIHRvIGhhdmUgaXMgb3V0cHV0IGV4cG9zZWQgKGFrYSBwdWJsaWMpLiBJZiB0aGlzIFBS
TkcgaXMgKGF0IGxlYXN0IHBhcnRpYWxseSkgYnJva2VuLCBhbiBhZHZlcnNhcnkgbWF5IGJlIGFi
bGUgdG8gcmVjb3ZlciBpdCdzIHN0YXRlL3NlZWQuDQoNCkkgZmFpbCB0byBzZWUgaG93IHRoZSBh
Ym92ZSBjYW4ganVzdGlmeSBpbnNpc3Rpbmcgb24gaGF2aW5nIG9ubHkgb25lIFBSTkcuIElmIHlv
dSBoYXZlIHNlZWRlZCBtb3JlIHRoYW4gb25lIFBSTkcsIGFuZCBvdXRwdXRzIG9mIG90aGVycyBh
cmUgbm90IGV4cG9zZWQgLSB0aGVuIGZvciB0aGUgYXR0YWNrIHRvIHN1Y2NlZWQgdGhlIGFkdmVy
c2FyeSBtdXN0IGtub3cgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBzZWVkcywgdGh1cyBl
eHBsb2l0aW5nIG1vcmUgdnVsbmVyYWJpbGl0aWVzIHRoYW4gYSBicm9rZW4gUFJORy4gTWF5YmUg
eW91IGRvbid0IGNvbnNpZGVyIHRoaXMgZGlzdGluY3Rpb24gc2lnbmlmaWNhbnQgZW5vdWdoLCBi
dXQgSSBkby4gDQoNCklmIHlvdSBhcmUgcmlnaHQgKGh5cG90aGV0aWNhbGx5IG9mIGNvdXJzZSks
IHRoZSBwcm9wb3NlZCBzZXR1cCBpcyBubyB3b3JzZSB0aGFuIGhhdmluZyBvbmUgZXhwb3NlZCBQ
Uk5HLiBJZiB5b3UgYXJlIHdyb25nIChhcyBJJ20gc3VyZSB5b3UgYXJlKSwgdGhlIHByb3Bvc2Vk
IHNldHVwIG1ha2VzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgZmFpbGVkIHN5c3RlbSwgYW5kIG9u
ZSB0aGF0IHdvcmtzLiANCg0KQXBwZWFycyBhIG5vLWJyYWluZXIuIA0KDQpSZWdhcmRzLA0KVXJp
DQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiBPbiBKdWwgMjksIDIwMTcsIGF0IDE2OjMwLCBE
YW4gQnJvd24gPGRhbmlicm93bkBibGFja2JlcnJ5LmNvbT4gd3JvdGU6DQo+IA0KPiDigI5TZWN0
aW9uIDMsIG9mIHRoZSBlcHJpbnQgIlJvbiBpcyB3cm9uZywgV2hpdCBpcyByaWdodCIsIHN1YnNl
Y3Rpb24gIk1vZHVsaSB3aXRoIHNoYXJlZCBwcmltZXMiLCBzdWdnZXN0cyB0byBtZSB0aGF0IGl0
J3Mgbm90IHVubGlrZWx5IHdoZW4gc2VlZGluZyB0d28gc2VjcmV0cyBuZWFyIGluIHRpbWUsIG9u
ZSBoYXMgbG93IGVudHJvcHkgKGJ5IGFjY2lkZW50KS4gVGhhdCdzIG5vdCB0aGUgb25seSBleHBs
YW5hdGlvbiBvZiB0aGUgb2JzZXJ2ZWQgc2hhcmVkIHByaW1lcywgYnV0IGlzIHBsYXVzaWJsZSBh
bmQgcmVsZXZhbnQgdG8gdGhlIHF1ZXN0aW9uIGF0IGhhbmQuIChJIHRob3VnaHQgSSBtZW50aW9u
ZWQgdGhpcyBlYXJsaWVyLikNCj4gRnJvbTogQ29sbSBNYWNDw6FydGhhaWdoDQo+IFNlbnQ6IFNh
dHVyZGF5LCBKdWx5IDI5LCAyMDE3IDI6MDQgUE0NCj4gVG86IERhbiBCcm93bg0KPiBDYzogU3Rl
cGhlbiBGYXJyZWxsOyBFcmljIFJlc2NvcmxhOyBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlU
TEw7IHRsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1RMU10gMzIgYnl0ZSByYW5kb21zIGlu
IFRMUzEuMyBoZWxsbydzDQo+IA0KPiANCj4gDQo+IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIHJlbGV2
YW50IHRvIHRoZSBwcm9ibGVtIGF0IGhhbmQgaW4gdGhhdCBwYXBlci4gRGlkIHlvdSByZWZlcmVu
Y2UgdGhlIHJpZ2h0IG9uZT8gVGhlcmUgYXJlIHNvbWUgbWVudGlvbnMgYWJvdXQgbm90IHJlLXVz
aW5nIHJhbmRvbSBzZWNyZXRzLCBidXQgdGhhdCBhcHBsaWVzIG5vIG1hdHRlciBob3cgbWFueSBS
TkdzIHlvdSB1c2UuIA0KPiANCj4gSW4geW91ciBwcmV2aW91cyBtYWlsLCBldmVuIGlmIGFuIGlt
cGxlbWVudGVyIHdlcmUgdG8gc2VlZCB0d28gUk5HcyBmcm9tIG9uZSBDU1BSTkcsIGFuZCBhbGwg
MyBhcmUgYmFkIGdlbmVyYXRvciwgdGhpcyBpcyBzdGlsbCBzdHJpY3RseSBiZXR0ZXIgdGhhbiBv
bmUgYnJva2VuIGdlbmVyYXRvcjsgYmVjYXVzZSB0aGUgYW1vdW50IG9mIHdvcmsgYW4gYXR0YWNr
ZXIgbXVzdCBkbyBpcyBmYXIgZ3JlYXRlci4gIA0KPiANCj4+IE9uIFNhdCwgSnVsIDI5LCAyMDE3
IGF0IDg6NTQgQU0sIERhbiBCcm93biA8ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tPiB3cm90ZToN
Cj4+IGh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMTIvMDY0DQo+PiBtZW50aW9ucyB0aGUgcHJv
YmxlbSBvZiBnZW5lcmF0aW5nIG11bHRpcGxlIHNlY3JldHMgaW5zdGVhZCBvZiBhIHNpbmdsZSBz
ZWNyZXQNCj4gDQo+IA0KPiAgDQo+PiANCj4+ICAgT3JpZ2luYWwgTWVzc2FnZQ0KPj4gRnJvbTog
U3RlcGhlbiBGYXJyZWxsDQo+PiBTZW50OiBGcmlkYXksIEp1bHkgMjgsIDIwMTcgMTE6NDggQU0N
Cj4+IFRvOiBEYW4gQnJvd247IEVyaWMgUmVzY29ybGE7IEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMg
LSBNSVRMTA0KPj4gQ2M6IHRsc0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtUTFNdIDMyIGJ5
dGUgcmFuZG9tcyBpbiBUTFMxLjMgaGVsbG8ncw0KPj4gDQo+PiANCj4+IEkgZG9uJ3QgdGhpbmsg
dGhpcyBpcyBzaW1wbHkgYSBjYXNlIG9mIG11bHRpcGxlIENTUFJOR3MuDQo+PiANCj4+IE15IGd1
ZXNzIGlzIG1hbnkgVExTIGltcGxlbWVudGF0aW9ucyBkb24ndCBoYXZlIHZpc2liaWxpdHkNCj4+
IGludG8gaG93IHRoZSBDU1BSTkcgb3BlcmF0ZXMuIFRoYXQgY29kZSBkb2VzIGhvd2V2ZXIsIGtu
b3cNCj4+IHdoaWNoIG91dHB1dCB2YWx1ZXMgd2lsbCBiZSBwdWJsaWMgYW5kIHdoaWNoIG5vdC4g
Rm9yIG1lLA0KPj4gdGhhdCBpbXBsaWVzIHRoYXQgYW55IGdvb2Qgc2VwYXJhdGlvbiBzY2hlbWUg
YXBwbGllZCB3aXRoaW4NCj4+IHRoZSBUTFMgY29kZSB0aGF0IGRpZmZlcmVudGlhdGVzIGJldHdl
ZW4gcHVibGljIGFuZCBub24NCj4+IHB1YmxpYyBvdXRwdXRzIGlzIGEgZ29vZCBwbGFuLiBZZXMs
IGlmIGFuIGF0dGFja2VyIGNhbiBib3JrDQo+PiB5b3VyIENTUFJORywgdGhleSBtYXkgYmUgYWJs
ZSB0byBnZXQgYXQgdGhlIFRMUyBjb2RlIHRvbw0KPj4gc29tZXRpbWVzLCBidXQgSSdkIGFyZ3Vl
IHRoZSBkZWZlbmNlIGluIGRlcHRoIGlzIHdvcnRod2hpbGUuDQo+PiANCj4+IENoZWVycywNCj4+
IFMuDQo+PiANCj4+IE9uIDI4LzA3LzE3IDE0OjM3LCBEYW4gQnJvd24gd3JvdGU6DQo+PiA+IEkg
dHJ5IGJlbG93IHRvIGJldHRlciBleHBsYWluIG15IHBvaW50cyBhZ2FpbnN0IHNlcGFyYXRlZCBw
dWJsaWMgYW5kIHByaXZhdGUgQ1NQUk5HIGluc3RhbmNlcy4NCj4+ID4NCj4+ID4gUGVyaGFwcyB0
aGUgZWFzaWVzdCB3YXkgdG8gZ2V0ICJpbmRlcGVuZGVudCIgc2VlZHMgZm9yIHRoZSB0d28gaW5z
dGFuY2VzIG9mIGEgQ1NQUk5HLCBpcyB0byB1c2UgYSB0aGlyZCBDU1BSTkcgaW5zdGFuY2UgdG8g
Z2VuZXJhdGUgdGhlIHNlZWRzLiAgQnV0IHRoZW4gdGhlIHByb2JsZW0gYXJpc2VzIGFnYWluLCBp
ZiB0aGUgMyBDU1BSTkdzIGFyZSBiYWQgZW5vdWdoLCAoMD1zZWVkZXIsIDE9cHVibGljLCAyPXBy
aXZhdGUpLCB0aGVyZSBpcyBhIHJpc2sgdGhhdDoNCj4+ID4NCj4+ID4gUHVibGljX25vbmNlPW91
dHB1dDE9PnNlZWQxPW91dHB1dDBfZm9yXzE9PnNlZWQwPT5vdXRwdXQwX2Zvcl8yPXNlZWQyPT5v
dXRwdXRfMj1wcml2YXRlX2tleT1UTFNfaW5zZWN1cml0eS4NCj4+ID4NCj4+ID4gSW4gc2hvcnQs
IGdlbmVyYWxseSBzcGVha2luZywgdGhyZWUgYmFkIENTUFJOR3MgZG8gbm90IGNvbWJpbmUgZWFz
aWx5IGludG8gMSBnb29kIENTUFJORy4NCj4+ID4NCj4+ID4gKEknbSBub3QgeWV0IHN1cmUgaWYg
dGhpcyBhdHRhY2sgb24gdGhyZWUgQ1NQUk5HcyBjb21iaW5lZCBhcHBsaWVzIHRvIER1YWxfRUMs
IHNpbmNlIGl0IG1heSBkbyBzb21ldGhpbmcgaGFzaC1saWtlIHRvIHRoZSBzZWVkIChJIGZvcmdv
dCBkZXRhaWxzKSwgYW5kIGFsc28gb3V0cHV0IGxlYWtzIHRoZSBuZXh0IHN0YXRlLCBub3QgdGhl
IHByZXZpb3VzIHN0YXRlLCBhcyBJIHJlY2FsbCwgc28gdGhhdCBtaWdodCBicmVhayB0aGUgY2hh
aW4gYWJvdmUuKQ0KPj4gPg0KPj4gPiBUaGUgYWx0ZXJuYXRpdmUgdG8gYSAzcmQgQ1NQUk5HIGlz
IHRvIGdldCB0aGUgc2VlZHMgZnJvbSBkaXJlY3RseSBmcm9tIGEgcmF3IGVudHJvcHkgc291cmNl
LiBJbiB0aGF0IGNhc2UsIGtlZXAgaW4gbWluZCB0aGF0IG9uZSBvZiB0aGUgcHVycG9zZXMgb2Yg
Q1NQUk5HcyBpcyB0aGF0IHJhdyBlbnRyb3B5IHNvdXJjZXMgYXJlIHVucmVsaWFibGUgKHNvbWV0
aW1lcyBzdGFsbCwgZXRjLiBbcmVmZXJlbmNlcyB0byBiZSBhZGRlZF0pIGFuZCBnZW5lcmFsbHkg
d2VhayBvbiB0aGUgaW5kZXBlbmRlbmNlICh0aGV5IGFyZSBub24tdW5pZm9ybSwgaGVuY2UgaGF2
ZSBjb3JyZWxhdGlvbnMpLiAgQ1NQUk5HcyBhcmUgc3VwcG9zZWQgdG8gY29ycmVjdCB0aGVzZSBk
ZWZpY2llbmNpZXMsIGFtb25nIG90aGVyIHRoaW5ncy4gIFNvLCBpZiB0aGUgMiBzZWVkcyBhcmUg
Z2VuZXJhdGVkIGRpcmVjdGx5IGZyb20gYSByYXcgZW50cm9weSBzb3VyY2VzICh3aXRob3V0IGEg
Q1NQUk5HKSwgdHdvIHRoaW5ncyBtYXkgZ28gd3JvbmcuIEZpcnN0LCBkZXJpdmluZyBvbmUgc2Vl
ZCBmcm9tIHRoZSBvdGhlciBtaWdodCBiZSBmZWFzaWJsZSBiZWNhdXNlIG9mIG5vbi11bmlmb3Jt
aXR5LiBBIGJhZCBDU1BSTkcgbWlnaHQgZW5hYmxlIHRoaXMgdGhpcyB0byBiZSBleHBsb2l0ZWQs
IGJ5IGZpbmRpbmcgb25lIHNlZWQgZnJvbSB0aGUgb3RoZXIuICBTZWNvbmQsIGlmIHRoZSBlbnRy
b3B5IHNvdXJjZSBzdGFsbHMgKGRvd24gYSB0cmlja2xlIG9mIGxvdyBlbnRyb3B5KSwgYmV0d2Vl
biB0b28gY2xvc2Ugc2VlZCByZXF1ZXN0cyAtIGFjY2lkZW50YWxseSAtIHRoZW4gZXZlbiBhIGdv
b2QgQ1NQUk5HIGNvdWxkbid0IGNvcGUuDQo+PiA+DQo+PiA+IE1heWJlLCBhbGwgdGhpcyB3b3Vs
ZG4ndCBiZSBhIHByb2JsZW0gb24gbWFueSBoaWdoZXIgZW5kIHN5c3RlbXMsIHdpdGggaGlnaCBl
bnRyb3B5LCBzbyBteSBjb25jZXJuIGlzIGxvd2VyIGVuZCBzeXN0ZW1zLCBhbmQgYWxzbyB1bm5l
Y2Vzc2FyeSBjb21wbGljYXRpb25zIG9mIG1haW50YWluaW5nIG11bHRpcGxlIGJhZCBDU1BSTkdz
LCBwb3RlbnRpYWxseSB0byBubyBhdmFpbC4NCj4+ID4NCj4+ID4gRmluYWxseSwgb24gc3lzdGVt
cyB3aXRoIGEgbGludXgtc3R5bGUgaW50ZXJmYWNlLCAvZGV2L3VyYW5kb20gYW5kIC9kZXYvcmFu
ZG9tIGNvdWxkIGJlIHVzZWQgYXMgdGhlIHR3byBDU1BSTkdzIG9uIHNvbWUgc3lzdGVtcyAob3Ig
c2VlZCBzb3VyY2VzKSwgYWx0aG91Z2ggSSB0aGluayBvbmUgb2YgdGhlc2UgaXMgbm93IGRlcHJl
Y2F0ZWQ/DQo+PiA+DQo+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+IEZyb206
IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RlcGhlbiBG
YXJyZWxsDQo+PiA+IFNlbnQ6IEZyaWRheSwgSnVseSAyOCwgMjAxNyA0OjQ3IEFNDQo+PiA+IFRv
OiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0g
TUlUTEwgPHVyaUBsbC5taXQuZWR1Pg0KPj4gPiBDYzogdGxzQGlldGYub3JnDQo+PiA+IFN1Ympl
Y3Q6IFJlOiBbVExTXSAzMiBieXRlIHJhbmRvbXMgaW4gVExTMS4zIGhlbGxvJ3MNCj4+ID4NCj4+
ID4NCj4+ID4gSGl5YSwNCj4+ID4NCj4+ID4gT24gMjgvMDcvMTcgMDA6NTAsIEVyaWMgUmVzY29y
bGEgd3JvdGU6DQo+PiA+PiBJIHVzZWQgdGhlIHRlcm0gInNlcGFyYXRlIiBoZXJlLCB3aGljaCB3
YXMgaW50ZW5kZWQgdG8gY29udmV5IHRoaXMsDQo+PiA+PiBidXQgaWYgcGVvcGxlIHRoaW5rICJp
bmRlcGVuZGVudCIgb3Igc29tZXRoaW5nIGlzIGJldHRlciwgaGFwcHkgdG8gY2hhbmdlLg0KPj4g
Pg0KPj4gPiBJIHRoaW5rIHlvdXIgY2hhbmdlIGlzIGEgZmluZSBpbXByb3ZlbWVudCBvdmVyIC0y
MSwgdGhhbmtzLg0KPj4gPiAoQW5kIG15IHN1Z2dlc3RlZCB0ZXh0IHdhcyBhcyBpbXBlcmZlY3Qg
YXMgSSB1c3VhbGx5IG1hbmFnZTotKQ0KPj4gPg0KPj4gPiBJJ20gbm90IGNsZWFyIGlmIGltcGxl
bWVudGVycyB3aWxsIG9yIHdpbGwgbm90IGdldCB0aGUgcmFtaWZpY2F0aW9ucyBvZiAic2VwYXJh
dGUiIChvciAiaW5kZXBlbmRlbnQiKSwgc28gSSB0aGluayB3ZSBvdWdodCBkZXNjcmliZSAob3Ig
cmVmZXJlbmNlKSBhdCBsZWFzdCBvbmUgd2F5IGluIHdoaWNoIHRoYXQgc2VwYXJhdGlvbiBjYW4g
YmUgYWNoaWV2ZWQuDQo+PiA+DQo+PiA+IEkgYWxzbyB0aGluayB3ZSBvdWdodCBhdCBsZWFzdCBS
RUNPTU1FTkQgc2VwYXJhdGUgQ1NQUk5Hcy4NCj4+ID4gSSdkIHByZWZlciBhIE1VU1QgbXlzZWxm
IGJ1dCBzaW5jZSB0aGVyZSdzIG5vIG9uZSBnb29kIHdheSB3ZSBjYW4gZGVzY3JpYmUgdG8gYWNo
aWV2ZSB0aGUgZWZmZWN0IHRoYXQnZCB3b3JrIGluIGFsbCBjYXNlcywgSSBkb24ndCB0aGluayB3
ZSBjYW4gc2F5IE1VU1QuDQo+PiA+DQo+PiA+IENoZWVycywNCj4+ID4gUy4NCj4+ID4NCj4+ID4N
Cj4+ID4+DQo+PiA+PiAtRWtyDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IE9uIFRodSwgSnVsIDI3LCAy
MDE3IGF0IDQ6NDMgUE0sIEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTCA8DQo+PiA+PiB1
cmlAbGwubWl0LmVkdT4gd3JvdGU6DQo+PiA+Pg0KPj4gPj4+IFJlc3BlY3RmdWxseSBkaXNhZ3Jl
ZS4gSGF2aW5nIHR3byBjcnlwdG9ncmFwaGljYWxseSBpbmRlcGVuZGVudA0KPj4gPj4+IFBSTkdz
LCBvbmUgZm9yIHB1YmxpYyBkYXRhIGFuZCBvbmUgZm9yIGtleSBtYXRlcmlhbCwgSU1ITyBpcyBh
IGdvb2QNCj4+ID4+PiBpZGVhLiBPZiBjb3Vyc2UsIGJvdGggc2hvdWxkIGJlIHByb3Blcmx5IHNl
ZWRlZCAtIGJ1dCB0aGF0J3MgYSBkaWZmZXJlbnQgaXNzdWUuDQo+PiA+Pj4NCj4+ID4+PiBSZWdh
cmRzLA0KPj4gPj4+IFVyaQ0KPj4gPj4+DQo+PiA+Pj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPj4g
Pj4+DQo+PiA+Pj4gT24gSnVsIDI3LCAyMDE3LCBhdCAxOTozMywgRGFuIEJyb3duIDxkYW5pYnJv
d25AYmxhY2tiZXJyeS5jb20+IHdyb3RlOg0KPj4gPj4+DQo+PiA+Pj4NCj4+ID4+PiBJIGRvbid0
IHRoaW5rIDIgQ1NQUk5HcyBpcyBhIGdvb2QgaWRlYS4NCj4+ID4+Pg0KPj4gPj4+IFdhc27igJl0
IHRoZXJlIGEgZmV3IHllYXJzIGJhY2sgc29tZSBSU0Ega2V5cyB3aXRoIHNlcGFyYXRlIHAgYW5k
IHEsDQo+PiA+Pj4gZ2VuZXJhdGVkIGluZGVwZW5kZW50bHkgbGVhZGluZyB0byBhbiBhdHRhY2su
Li4NCj4+ID4+Pg0KPj4gPj4+IEhlcmUgaWYgdGhlIHNlZWRzIHRvIGluaXRpYWxpemUgdGhlIFJO
R1MgYXJlIHJlbGF0ZWQsIG9yIG9uZSBpcyB3ZWFrLA0KPj4gPj4+IG9yIHdvcnN0IGlmIHRoZSBz
ZWVkIGlzIGEgcmF3IHNvdXJjZSB0aGF0IGRvZXNu4oCZdCBjaGFuZ2UgaW4gdGhlDQo+PiA+Pj4g
bW9tZW50cyBiZXR3ZWVuIHRoZSB0d28gQ1NQUk5HIGluaXRzLCB0aGF0J2QgYmUgYmFkLCBldmVu
IGlmIHRoZSBDU1BSTkdzIHdlcmUgZ29vZC4NCj4+ID4+PiAqRnJvbTogKkVyaWMgUmVzY29ybGEN
Cj4+ID4+PiAqU2VudDogKlRodXJzZGF5LCBKdWx5IDI3LCAyMDE3IDY6MzQgUE0NCj4+ID4+PiAq
VG86ICpTdGVwaGVuIEZhcnJlbGwNCj4+ID4+PiAqQ2M6ICp0bHNAaWV0Zi5vcmcNCj4+ID4+PiAq
U3ViamVjdDogKlJlOiBbVExTXSAzMiBieXRlIHJhbmRvbXMgaW4gVExTMS4zIGhlbGxvJ3MNCj4+
ID4+Pg0KPj4gPj4+IFNwZWMgdXBkYXRlZCBoZXJlOw0KPj4gPj4+IGh0dHBzOi8vZ2l0aHViLmNv
bS90bHN3Zy90bHMxMy1zcGVjL2NvbW1pdC80NjVkZTBlMTg5YjJiNTkwOTBkMGVhYzBhYw0KPj4g
Pj4+IGJjNDINCj4+ID4+PiA5NDJhZjljYTc3DQo+PiA+Pj4NCj4+ID4+PiAtRWtyDQo+PiA+Pj4N
Cj4+ID4+Pg0KPj4gPj4+IE9uIFdlZCwgSnVsIDI2LCAyMDE3IGF0IDQ6MjcgUE0sIFN0ZXBoZW4g
RmFycmVsbCA8DQo+PiA+Pj4gc3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6DQo+PiA+
Pj4NCj4+ID4+Pj4NCj4+ID4+Pj4gSSd2ZSBzdWdnZXN0ZWQgc29tZSB0ZXh0IGZvciB0aGlzIGlu
IGEgUFIgWzFdIGJhc2VkIG9uIHdoYXQgcGVvcGxlDQo+PiA+Pj4+IGhhdmUgc2FpZCBpbiB0aGlz
IHRocmVhZC4NCj4+ID4+Pj4NCj4+ID4+Pj4gSSdtIHN1cmUgdGhhdCBjYW4gYmUgZnVydGhlciBp
bXByb3ZlZC4NCj4+ID4+Pj4NCj4+ID4+Pj4gSXQgbWlnaHQgYmUgbm8gaGFybSB0byBhZGQgbW9y
ZSBwb2ludGVycyB0byB0aGF0IGFwcGVuZGl4IGZyb20NCj4+ID4+Pj4gZWxzZXdoZXJlIGluIHRo
ZSBzcGVjLCBhbmQvb3IgdG8gYWRkIGEgbGlzdCBvZiB0aGUgdmFyaW91cw0KPj4gPj4+PiBwdWJs
aWMvcHJpdmF0ZSByYW5kb20gbnVtYmVycyB0aGF0IGFyZSBuZWVkZWQgdG8gdGhhdCBhcHBlbmRp
eC4gKEknZA0KPj4gPj4+PiBiZSBoYXBweSB0byBkbyBhIHBhc3MgdG8gaWRlbnRpZnkgdGhvc2Ug
aWYgZm9sa3MgYmFzaWNhbGx5IGxpa2UgdGhpcw0KPj4gPj4+PiBraW5kIG9mIGFkZGl0aW9uLikN
Cj4+ID4+Pj4NCj4+ID4+Pj4gSSBhbHNvIG5lZWQgdG8gZmlndXJlIG91dCBob3cgdG8gaGFuZGxl
IHRoZSByZWZlcmVuY2UgcHJvcGVybHk6LSkNCj4+ID4+Pj4gQ2FuIGRvIHRoYXQgdG9tb3Jyb3cu
DQo+PiA+Pj4+DQo+PiA+Pj4+IENoZWVycywNCj4+ID4+Pj4gUy4NCj4+ID4+Pj4NCj4+ID4+Pj4g
WzFdIGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL3B1bGwvMTA2OA0KPj4gPj4+
Pg0KPj4gPj4+Pg0KPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPj4gPj4+PiBUTFMgbWFpbGluZyBsaXN0DQo+PiA+Pj4+IFRMU0BpZXRmLm9y
Zw0KPj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KPj4g
Pj4+Pg0KPj4gPj4+Pg0KPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+PiA+Pj4gVExTIG1haWxpbmcgbGlzdA0KPj4gPj4+IFRMU0BpZXRmLm9y
Zw0KPj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+PiA+
Pj4NCj4+ID4+Pg0KPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+PiA+Pj4gVExTIG1haWxpbmcgbGlzdA0KPj4gPj4+IFRMU0BpZXRmLm9yZw0K
Pj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+PiA+Pj4N
Cj4+ID4+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IFRMUyBtYWlsaW5nIGxpc3QNCj4+ID4+
IFRMU0BpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by90bHMNCj4+ID4+DQo+PiA+DQo+PiA+DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBUTFMgbWFpbGluZyBsaXN0DQo+PiBUTFNAaWV0
Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+IA0K
PiANCj4gDQo+IC0tIA0KPiBDb2xtDQo=

--Apple-Mail-56D3470A-E27B-4B6E-8269-E5852CC2CD10
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+RGFuLCZu
YnNwOzwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2PjxkaXYgaWQ9
IkFwcGxlTWFpbFNpZ25hdHVyZSI+SSBjb25mZXNzIEkgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIGxv
Z2ljLiZuYnNwOzwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2Pjxk
aXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+QSBQUk5HIGNhbiBiZSBnb29kLCBvciBpdCBjYW4g
YmUgYmFkLiBJZiB5b3Ugc2VlZCBtb3JlIHRoYW4gb25lIFBSTkcsIHlvdXIgc2VlZHMgY291bGQg
YmUgY3J5cHRvZ3JhcGhpY2FsbHkgY29ycmVsYXRlZCAod29yc3QgY2FzZSksIG9yIHRoZXkgbWF5
IGJlIGNyeXB0b2dyYXBoaWNhbGx5IGluZGVwZW5kZW50ICh3aGF0IHdlIHdhbnQgYW5kIGV4cGVj
dCkuPC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+PC9kaXY+PGRpdiBpZD0i
QXBwbGVNYWlsU2lnbmF0dXJlIj5BdCBsZWFzdCBvbmUgb2YgdGhlIFBSTkdzIGhhcyB0byBoYXZl
IGlzIG91dHB1dCBleHBvc2VkIChha2EgcHVibGljKS4gSWYgdGhpcyBQUk5HIGlzIChhdCBsZWFz
dCBwYXJ0aWFsbHkpIGJyb2tlbiwgYW4gYWR2ZXJzYXJ5IG1heSBiZSBhYmxlIHRvIHJlY292ZXIg
aXQncyBzdGF0ZS9zZWVkLjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwv
ZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+SSBmYWlsIHRvIHNlZSBob3cgdGhlIGFi
b3ZlIGNhbiBqdXN0aWZ5IGluc2lzdGluZyBvbiBoYXZpbmcgb25seSBvbmUgUFJORy4gSWYgeW91
IGhhdmUgc2VlZGVkIG1vcmUgdGhhbiBvbmUgUFJORywgYW5kIG91dHB1dHMgb2Ygb3RoZXJzIGFy
ZSBub3QgZXhwb3NlZCAtIHRoZW4gZm9yIHRoZSBhdHRhY2sgdG8gc3VjY2VlZCB0aGUgYWR2ZXJz
YXJ5IG11c3Qga25vdyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHNlZWRzLCB0aHVzIGV4
cGxvaXRpbmcgbW9yZSB2dWxuZXJhYmlsaXRpZXMgdGhhbiBhIGJyb2tlbiBQUk5HLiBNYXliZSB5
b3UgZG9uJ3QgY29uc2lkZXIgdGhpcyBkaXN0aW5jdGlvbiBzaWduaWZpY2FudCBlbm91Z2gsIGJ1
dCBJIGRvLiZuYnNwOzwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2
PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+SWYgeW91IGFyZSByaWdodCAoaHlwb3RoZXRp
Y2FsbHkgb2YgY291cnNlKSwgdGhlIHByb3Bvc2VkIHNldHVwIGlzIG5vIHdvcnNlIHRoYW4gaGF2
aW5nIG9uZSBleHBvc2VkIFBSTkcuIElmIHlvdSBhcmUgd3JvbmcgKGFzIEknbSBzdXJlIHlvdSBh
cmUpLCB0aGUgcHJvcG9zZWQgc2V0dXAgbWFrZXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gYSBmYWls
ZWQgc3lzdGVtLCBhbmQgb25lIHRoYXQgd29ya3MuJm5ic3A7PC9kaXY+PGRpdiBpZD0iQXBwbGVN
YWlsU2lnbmF0dXJlIj48YnI+PC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5BcHBl
YXJzIGEgbm8tYnJhaW5lci4mbmJzcDs8YnI+PGJyPlJlZ2FyZHMsPGRpdj5Vcmk8L2Rpdj48ZGl2
Pjxicj48L2Rpdj48ZGl2PlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj5P
biBKdWwgMjksIDIwMTcsIGF0IDE2OjMwLCBEYW4gQnJvd24gJmx0OzxhIGhyZWY9Im1haWx0bzpk
YW5pYnJvd25AYmxhY2tiZXJyeS5jb20iPmRhbmlicm93bkBibGFja2JlcnJ5LmNvbTwvYT4mZ3Q7
IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCjxtZXRh
IGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0
Zi04Ij4NCg0KDQo8ZGl2IHN0eWxlPSJ3aWR0aDoxMDAlOyBmb250LXNpemU6aW5pdGlhbDsgZm9u
dC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJvJyxzYW5zLXNlcmlmLHNhbnMtc2VyaWY7IGNvbG9y
OnJnYigzMSw3MywxMjUpOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdi
KDI1NSwyNTUsMjU1KSI+DQrigI5TZWN0aW9uIDMsIG9mIHRoZSBlcHJpbnQgIlJvbiBpcyB3cm9u
ZywgV2hpdCBpcyByaWdodCIsIHN1YnNlY3Rpb24gIk1vZHVsaSB3aXRoIHNoYXJlZCBwcmltZXMi
LCBzdWdnZXN0cyB0byBtZSB0aGF0IGl0J3Mgbm90IHVubGlrZWx5IHdoZW4gc2VlZGluZyB0d28g
c2VjcmV0cyBuZWFyIGluIHRpbWUsIG9uZSBoYXMgbG93IGVudHJvcHkgKGJ5IGFjY2lkZW50KS4g
VGhhdCdzIG5vdCB0aGUgb25seSBleHBsYW5hdGlvbiBvZiB0aGUgb2JzZXJ2ZWQNCiBzaGFyZWQg
cHJpbWVzLCBidXQgaXMgcGxhdXNpYmxlIGFuZCByZWxldmFudCB0byB0aGUgcXVlc3Rpb24gYXQg
aGFuZC4gKEkgdGhvdWdodCBJIG1lbnRpb25lZCB0aGlzIGVhcmxpZXIuKTxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTpDYWxpYnJpLCdTbGF0ZSBQcm8nLHNhbnMtc2VyaWYsc2Fucy1zZXJpZjsgZm9u
dC1zaXplOmluaXRpYWw7IGxpbmUtaGVpZ2h0OmluaXRpYWw7IHRleHQtYWxpZ246aW5pdGlhbCI+
PC9zcGFuPjwvZGl2Pg0KPHRhYmxlIHdpZHRoPSIxMDAlIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv
cjp3aGl0ZTsgYm9yZGVyLXNwYWNpbmc6MHB4Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBjb2xzcGFu
PSIyIiBzdHlsZT0iZm9udC1zaXplOmluaXRpYWw7IHRleHQtYWxpZ246aW5pdGlhbDsgYmFja2dy
b3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTpz
b2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6cmdiKDE4MSwxOTYsMjIzKTsgYm9yZGVy
LXRvcC13aWR0aDoxcHQ7IHBhZGRpbmc6M3B0IDBpbiAwaW47IGZvbnQtZmFtaWx5OlRhaG9tYSwn
QkIgQWxwaGEgU2FucycsJ1NsYXRlIFBybyc7IGZvbnQtc2l6ZToxMHB0Ij4NCjxkaXY+PGI+RnJv
bTogPC9iPkNvbG0gTWFjQ8OhcnRoYWlnaDwvZGl2Pg0KPGRpdj48Yj5TZW50OiA8L2I+U2F0dXJk
YXksIEp1bHkgMjksIDIwMTcgMjowNCBQTTwvZGl2Pg0KPGRpdj48Yj5UbzogPC9iPkRhbiBCcm93
bjwvZGl2Pg0KPGRpdj48Yj5DYzogPC9iPlN0ZXBoZW4gRmFycmVsbDsgRXJpYyBSZXNjb3JsYTsg
Qmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMOyA8YSBocmVmPSJtYWlsdG86dGxzQGlldGYu
b3JnIj50bHNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PjxiPlN1YmplY3Q6IDwvYj5SZTogW1RM
U10gMzIgYnl0ZSByYW5kb21zIGluIFRMUzEuMyBoZWxsbydzPC9kaXY+DQo8L2Rpdj4NCjwvdGQ+
DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6c29s
aWQgbm9uZSBub25lOyBib3JkZXItdG9wLWNvbG9yOnJnYigxODYsMTg4LDIwOSk7IGJvcmRlci10
b3Atd2lkdGg6MXB0OyBmb250LXNpemU6aW5pdGlhbDsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNr
Z3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KPC9kaXY+DQo8YnI+DQo8ZGl2Pg0KPGRp
diBkaXI9Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPkkgZG9uJ3Qgc2VlIGFueXRoaW5nIHJlbGV2YW50IHRv
IHRoZSBwcm9ibGVtIGF0IGhhbmQgaW4gdGhhdCBwYXBlci4gRGlkIHlvdSByZWZlcmVuY2UgdGhl
IHJpZ2h0IG9uZT8gVGhlcmUgYXJlIHNvbWUgbWVudGlvbnMgYWJvdXQgbm90IHJlLXVzaW5nIHJh
bmRvbSBzZWNyZXRzLCBidXQgdGhhdCBhcHBsaWVzIG5vIG1hdHRlciBob3cgbWFueSBSTkdzIHlv
dSB1c2UuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+SW4geW91ciBwcmV2aW91cyBtYWlsLCBldmVuIGlm
IGFuIGltcGxlbWVudGVyIHdlcmUgdG8gc2VlZCB0d28gUk5HcyBmcm9tIG9uZSBDU1BSTkcsIGFu
ZCBhbGwgMyBhcmUgYmFkIGdlbmVyYXRvciwgdGhpcyBpcyBzdGlsbCBzdHJpY3RseSBiZXR0ZXIg
dGhhbiBvbmUgYnJva2VuIGdlbmVyYXRvcjsgYmVjYXVzZSB0aGUgYW1vdW50IG9mIHdvcmsgYW4g
YXR0YWNrZXIgbXVzdCBkbyBpcyBmYXIgZ3JlYXRlci4NCiAmbmJzcDs8L2Rpdj4NCjxkaXYgY2xh
c3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU2F0LCBK
dWwgMjksIDIwMTcgYXQgODo1NCBBTSwgRGFuIEJyb3duIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8
YSBocmVmPSJtYWlsdG86ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tIiB0YXJnZXQ9Il9ibGFuayI+
ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9j
a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBib3Jk
ZXItbGVmdDoxcHggI2NjYyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8YSBocmVmPSJodHRw
czovL2VwcmludC5pYWNyLm9yZy8yMDEyLzA2NCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxMi88d2JyPjA2NDwvYT48YnI+DQptZW50
aW9ucyB0aGUgcHJvYmxlbSBvZiBnZW5lcmF0aW5nIG11bHRpcGxlIHNlY3JldHMgaW5zdGVhZCBv
ZiBhIHNpbmdsZSBzZWNyZXQ8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0i
Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6MXB4ICNj
Y2Mgc29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KJm5ic3A7IE9yaWdpbmFsIE1lc3Nh
Z2U8YnI+DQpGcm9tOiBTdGVwaGVuIEZhcnJlbGw8YnI+DQpTZW50OiBGcmlkYXksIEp1bHkgMjgs
IDIwMTcgMTE6NDggQU08YnI+DQpUbzogRGFuIEJyb3duOyBFcmljIFJlc2NvcmxhOyBCbHVtZW50
aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEw8YnI+DQo8ZGl2IGNsYXNzPSJIT0VuWmIiPg0KPGRpdiBj
bGFzcz0iaDUiPkNjOiA8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8
L2E+PGJyPg0KU3ViamVjdDogUmU6IFtUTFNdIDMyIGJ5dGUgcmFuZG9tcyBpbiBUTFMxLjMgaGVs
bG8nczxicj4NCjxicj4NCjxicj4NCkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBzaW1wbHkgYSBjYXNl
IG9mIG11bHRpcGxlIENTUFJOR3MuPGJyPg0KPGJyPg0KTXkgZ3Vlc3MgaXMgbWFueSBUTFMgaW1w
bGVtZW50YXRpb25zIGRvbid0IGhhdmUgdmlzaWJpbGl0eTxicj4NCmludG8gaG93IHRoZSBDU1BS
Tkcgb3BlcmF0ZXMuIFRoYXQgY29kZSBkb2VzIGhvd2V2ZXIsIGtub3c8YnI+DQp3aGljaCBvdXRw
dXQgdmFsdWVzIHdpbGwgYmUgcHVibGljIGFuZCB3aGljaCBub3QuIEZvciBtZSw8YnI+DQp0aGF0
IGltcGxpZXMgdGhhdCBhbnkgZ29vZCBzZXBhcmF0aW9uIHNjaGVtZSBhcHBsaWVkIHdpdGhpbjxi
cj4NCnRoZSBUTFMgY29kZSB0aGF0IGRpZmZlcmVudGlhdGVzIGJldHdlZW4gcHVibGljIGFuZCBu
b248YnI+DQpwdWJsaWMgb3V0cHV0cyBpcyBhIGdvb2QgcGxhbi4gWWVzLCBpZiBhbiBhdHRhY2tl
ciBjYW4gYm9yazxicj4NCnlvdXIgQ1NQUk5HLCB0aGV5IG1heSBiZSBhYmxlIHRvIGdldCBhdCB0
aGUgVExTIGNvZGUgdG9vPGJyPg0Kc29tZXRpbWVzLCBidXQgSSdkIGFyZ3VlIHRoZSBkZWZlbmNl
IGluIGRlcHRoIGlzIHdvcnRod2hpbGUuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NClMuPGJyPg0K
PGJyPg0KT24gMjgvMDcvMTcgMTQ6MzcsIERhbiBCcm93biB3cm90ZTo8YnI+DQomZ3Q7IEkgdHJ5
IGJlbG93IHRvIGJldHRlciBleHBsYWluIG15IHBvaW50cyBhZ2FpbnN0IHNlcGFyYXRlZCBwdWJs
aWMgYW5kIHByaXZhdGUgQ1NQUk5HIGluc3RhbmNlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBQZXJo
YXBzIHRoZSBlYXNpZXN0IHdheSB0byBnZXQgImluZGVwZW5kZW50IiBzZWVkcyBmb3IgdGhlIHR3
byBpbnN0YW5jZXMgb2YgYSBDU1BSTkcsIGlzIHRvIHVzZSBhIHRoaXJkIENTUFJORyBpbnN0YW5j
ZSB0byBnZW5lcmF0ZSB0aGUgc2VlZHMuJm5ic3A7IEJ1dCB0aGVuIHRoZSBwcm9ibGVtIGFyaXNl
cyBhZ2FpbiwgaWYgdGhlIDMgQ1NQUk5HcyBhcmUgYmFkIGVub3VnaCwgKDA9c2VlZGVyLCAxPXB1
YmxpYywgMj1wcml2YXRlKSwgdGhlcmUgaXMgYQ0KIHJpc2sgdGhhdDo8YnI+DQomZ3Q7PGJyPg0K
Jmd0OyBQdWJsaWNfbm9uY2U9b3V0cHV0MT0mZ3Q7c2VlZDE9PHdicj5vdXRwdXQwX2Zvcl8xPSZn
dDtzZWVkMD0mZ3Q7b3V0cHV0MF88d2JyPmZvcl8yPXNlZWQyPSZndDtvdXRwdXRfMj1wcml2YXRl
Xzx3YnI+a2V5PVRMU19pbnNlY3VyaXR5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEluIHNob3J0LCBn
ZW5lcmFsbHkgc3BlYWtpbmcsIHRocmVlIGJhZCBDU1BSTkdzIGRvIG5vdCBjb21iaW5lIGVhc2ls
eSBpbnRvIDEgZ29vZCBDU1BSTkcuPGJyPg0KJmd0Ozxicj4NCiZndDsgKEknbSBub3QgeWV0IHN1
cmUgaWYgdGhpcyBhdHRhY2sgb24gdGhyZWUgQ1NQUk5HcyBjb21iaW5lZCBhcHBsaWVzIHRvIER1
YWxfRUMsIHNpbmNlIGl0IG1heSBkbyBzb21ldGhpbmcgaGFzaC1saWtlIHRvIHRoZSBzZWVkIChJ
IGZvcmdvdCBkZXRhaWxzKSwgYW5kIGFsc28gb3V0cHV0IGxlYWtzIHRoZSBuZXh0IHN0YXRlLCBu
b3QgdGhlIHByZXZpb3VzIHN0YXRlLCBhcyBJIHJlY2FsbCwgc28gdGhhdCBtaWdodCBicmVhayB0
aGUgY2hhaW4gYWJvdmUuKTxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBhbHRlcm5hdGl2ZSB0byBh
IDNyZCBDU1BSTkcgaXMgdG8gZ2V0IHRoZSBzZWVkcyBmcm9tIGRpcmVjdGx5IGZyb20gYSByYXcg
ZW50cm9weSBzb3VyY2UuIEluIHRoYXQgY2FzZSwga2VlcCBpbiBtaW5kIHRoYXQgb25lIG9mIHRo
ZSBwdXJwb3NlcyBvZiBDU1BSTkdzIGlzIHRoYXQgcmF3IGVudHJvcHkgc291cmNlcyBhcmUgdW5y
ZWxpYWJsZSAoc29tZXRpbWVzIHN0YWxsLCBldGMuIFtyZWZlcmVuY2VzIHRvIGJlIGFkZGVkXSkg
YW5kIGdlbmVyYWxseQ0KIHdlYWsgb24gdGhlIGluZGVwZW5kZW5jZSAodGhleSBhcmUgbm9uLXVu
aWZvcm0sIGhlbmNlIGhhdmUgY29ycmVsYXRpb25zKS4mbmJzcDsgQ1NQUk5HcyBhcmUgc3VwcG9z
ZWQgdG8gY29ycmVjdCB0aGVzZSBkZWZpY2llbmNpZXMsIGFtb25nIG90aGVyIHRoaW5ncy4mbmJz
cDsgU28sIGlmIHRoZSAyIHNlZWRzIGFyZSBnZW5lcmF0ZWQgZGlyZWN0bHkgZnJvbSBhIHJhdyBl
bnRyb3B5IHNvdXJjZXMgKHdpdGhvdXQgYSBDU1BSTkcpLCB0d28gdGhpbmdzIG1heSBnbyB3cm9u
Zy4NCiBGaXJzdCwgZGVyaXZpbmcgb25lIHNlZWQgZnJvbSB0aGUgb3RoZXIgbWlnaHQgYmUgZmVh
c2libGUgYmVjYXVzZSBvZiBub24tdW5pZm9ybWl0eS4gQSBiYWQgQ1NQUk5HIG1pZ2h0IGVuYWJs
ZSB0aGlzIHRoaXMgdG8gYmUgZXhwbG9pdGVkLCBieSBmaW5kaW5nIG9uZSBzZWVkIGZyb20gdGhl
IG90aGVyLiZuYnNwOyBTZWNvbmQsIGlmIHRoZSBlbnRyb3B5IHNvdXJjZSBzdGFsbHMgKGRvd24g
YSB0cmlja2xlIG9mIGxvdyBlbnRyb3B5KSwgYmV0d2VlbiB0b28NCiBjbG9zZSBzZWVkIHJlcXVl
c3RzIC0gYWNjaWRlbnRhbGx5IC0gdGhlbiBldmVuIGEgZ29vZCBDU1BSTkcgY291bGRuJ3QgY29w
ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBNYXliZSwgYWxsIHRoaXMgd291bGRuJ3QgYmUgYSBwcm9i
bGVtIG9uIG1hbnkgaGlnaGVyIGVuZCBzeXN0ZW1zLCB3aXRoIGhpZ2ggZW50cm9weSwgc28gbXkg
Y29uY2VybiBpcyBsb3dlciBlbmQgc3lzdGVtcywgYW5kIGFsc28gdW5uZWNlc3NhcnkgY29tcGxp
Y2F0aW9ucyBvZiBtYWludGFpbmluZyBtdWx0aXBsZSBiYWQgQ1NQUk5HcywgcG90ZW50aWFsbHkg
dG8gbm8gYXZhaWwuPGJyPg0KJmd0Ozxicj4NCiZndDsgRmluYWxseSwgb24gc3lzdGVtcyB3aXRo
IGEgbGludXgtc3R5bGUgaW50ZXJmYWNlLCAvZGV2L3VyYW5kb20gYW5kIC9kZXYvcmFuZG9tIGNv
dWxkIGJlIHVzZWQgYXMgdGhlIHR3byBDU1BSTkdzIG9uIHNvbWUgc3lzdGVtcyAob3Igc2VlZCBz
b3VyY2VzKSwgYWx0aG91Z2ggSSB0aGluayBvbmUgb2YgdGhlc2UgaXMgbm93IGRlcHJlY2F0ZWQ/
PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7
IEZyb206IFRMUyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyI+
dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3RlcGhlbiBGYXJyZWxsPGJy
Pg0KJmd0OyBTZW50OiBGcmlkYXksIEp1bHkgMjgsIDIwMTcgNDo0NyBBTTxicj4NCiZndDsgVG86
IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZt
LmNvbTwvYT4mZ3Q7OyBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEwgJmx0OzxhIGhyZWY9
Im1haWx0bzp1cmlAbGwubWl0LmVkdSI+dXJpQGxsLm1pdC5lZHU8L2E+Jmd0Ozxicj4NCiZndDsg
Q2M6IDxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT48YnI+DQom
Z3Q7IFN1YmplY3Q6IFJlOiBbVExTXSAzMiBieXRlIHJhbmRvbXMgaW4gVExTMS4zIGhlbGxvJ3M8
YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGl5YSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBP
biAyOC8wNy8xNyAwMDo1MCwgRXJpYyBSZXNjb3JsYSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBJIHVz
ZWQgdGhlIHRlcm0gInNlcGFyYXRlIiBoZXJlLCB3aGljaCB3YXMgaW50ZW5kZWQgdG8gY29udmV5
IHRoaXMsPGJyPg0KJmd0OyZndDsgYnV0IGlmIHBlb3BsZSB0aGluayAiaW5kZXBlbmRlbnQiIG9y
IHNvbWV0aGluZyBpcyBiZXR0ZXIsIGhhcHB5IHRvIGNoYW5nZS48YnI+DQomZ3Q7PGJyPg0KJmd0
OyBJIHRoaW5rIHlvdXIgY2hhbmdlIGlzIGEgZmluZSBpbXByb3ZlbWVudCBvdmVyIC0yMSwgdGhh
bmtzLjxicj4NCiZndDsgKEFuZCBteSBzdWdnZXN0ZWQgdGV4dCB3YXMgYXMgaW1wZXJmZWN0IGFz
IEkgdXN1YWxseSBtYW5hZ2U6LSk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ20gbm90IGNsZWFyIGlm
IGltcGxlbWVudGVycyB3aWxsIG9yIHdpbGwgbm90IGdldCB0aGUgcmFtaWZpY2F0aW9ucyBvZiAi
c2VwYXJhdGUiIChvciAiaW5kZXBlbmRlbnQiKSwgc28gSSB0aGluayB3ZSBvdWdodCBkZXNjcmli
ZSAob3IgcmVmZXJlbmNlKSBhdCBsZWFzdCBvbmUgd2F5IGluIHdoaWNoIHRoYXQgc2VwYXJhdGlv
biBjYW4gYmUgYWNoaWV2ZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBhbHNvIHRoaW5rIHdlIG91
Z2h0IGF0IGxlYXN0IFJFQ09NTUVORCBzZXBhcmF0ZSBDU1BSTkdzLjxicj4NCiZndDsgSSdkIHBy
ZWZlciBhIE1VU1QgbXlzZWxmIGJ1dCBzaW5jZSB0aGVyZSdzIG5vIG9uZSBnb29kIHdheSB3ZSBj
YW4gZGVzY3JpYmUgdG8gYWNoaWV2ZSB0aGUgZWZmZWN0IHRoYXQnZCB3b3JrIGluIGFsbCBjYXNl
cywgSSBkb24ndCB0aGluayB3ZSBjYW4gc2F5IE1VU1QuPGJyPg0KJmd0Ozxicj4NCiZndDsgQ2hl
ZXJzLDxicj4NCiZndDsgUy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsgLUVrcjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBP
biBUaHUsIEp1bCAyNywgMjAxNyBhdCA0OjQzIFBNLCBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0g
TUlUTEwgJmx0Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzp1cmlAbGwubWl0LmVkdSI+
dXJpQGxsLm1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
Jmd0OyBSZXNwZWN0ZnVsbHkgZGlzYWdyZWUuIEhhdmluZyB0d28gY3J5cHRvZ3JhcGhpY2FsbHkg
aW5kZXBlbmRlbnQ8YnI+DQomZ3Q7Jmd0OyZndDsgUFJOR3MsIG9uZSBmb3IgcHVibGljIGRhdGEg
YW5kIG9uZSBmb3Iga2V5IG1hdGVyaWFsLCBJTUhPIGlzIGEgZ29vZDxicj4NCiZndDsmZ3Q7Jmd0
OyBpZGVhLiBPZiBjb3Vyc2UsIGJvdGggc2hvdWxkIGJlIHByb3Blcmx5IHNlZWRlZCAtIGJ1dCB0
aGF0J3MgYSBkaWZmZXJlbnQgaXNzdWUuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm
Z3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsmZ3Q7IFVyaTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7Jmd0OyBTZW50IGZyb20gbXkgaVBob25lPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7IE9uIEp1bCAyNywgMjAxNywgYXQgMTk6MzMsIERhbiBCcm93biAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmRhbmlicm93bkBibGFja2JlcnJ5LmNvbSI+ZGFuaWJyb3duQGJsYWNrYmVy
cnkuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsmZ3Q7IEkgZG9uJ3QgdGhpbmsgMiBDU1BSTkdzIGlzIGEgZ29vZCBpZGVh
Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBXYXNu4oCZdCB0aGVyZSBhIGZl
dyB5ZWFycyBiYWNrIHNvbWUgUlNBIGtleXMgd2l0aCBzZXBhcmF0ZSBwIGFuZCBxLDxicj4NCiZn
dDsmZ3Q7Jmd0OyBnZW5lcmF0ZWQgaW5kZXBlbmRlbnRseSBsZWFkaW5nIHRvIGFuIGF0dGFjay4u
Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBIZXJlIGlmIHRoZSBzZWVkcyB0
byBpbml0aWFsaXplIHRoZSBSTkdTIGFyZSByZWxhdGVkLCBvciBvbmUgaXMgd2Vhayw8YnI+DQom
Z3Q7Jmd0OyZndDsgb3Igd29yc3QgaWYgdGhlIHNlZWQgaXMgYSByYXcgc291cmNlIHRoYXQgZG9l
c27igJl0IGNoYW5nZSBpbiB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsgbW9tZW50cyBiZXR3ZWVuIHRo
ZSB0d28gQ1NQUk5HIGluaXRzLCB0aGF0J2QgYmUgYmFkLCBldmVuIGlmIHRoZSBDU1BSTkdzIHdl
cmUgZ29vZC48YnI+DQomZ3Q7Jmd0OyZndDsgKkZyb206ICpFcmljIFJlc2NvcmxhPGJyPg0KJmd0
OyZndDsmZ3Q7ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMjcsIDIwMTcgNjozNCBQTTxicj4NCiZn
dDsmZ3Q7Jmd0OyAqVG86ICpTdGVwaGVuIEZhcnJlbGw8YnI+DQomZ3Q7Jmd0OyZndDsgKkNjOiAq
PGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxzQGlldGYub3JnPC9hPjxicj4NCiZndDsm
Z3Q7Jmd0OyAqU3ViamVjdDogKlJlOiBbVExTXSAzMiBieXRlIHJhbmRvbXMgaW4gVExTMS4zIGhl
bGxvJ3M8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgU3BlYyB1cGRhdGVkIGhl
cmU7PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90
bHMxMy1zcGVjL2NvbW1pdC80NjVkZTBlMTg5YjJiNTkwOTBkMGVhYzBhYyIgcmVsPSJub3JlZmVy
cmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvPHdicj50bHMx
My1zcGVjL2NvbW1pdC88d2JyPjQ2NWRlMGUxODliMmI1OTA5MGQwZWFjMGFjPC9hPjxicj4NCiZn
dDsmZ3Q7Jmd0OyBiYzQyPGJyPg0KJmd0OyZndDsmZ3Q7IDk0MmFmOWNhNzc8YnI+DQomZ3Q7Jmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLUVrcjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBXZWQsIEp1bCAyNiwgMjAxNyBhdCA0OjI3IFBN
LCBTdGVwaGVuIEZhcnJlbGwgJmx0Ozxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86
c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4m
Z3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7IEkndmUgc3VnZ2VzdGVkIHNvbWUgdGV4dCBmb3IgdGhpcyBpbiBhIFBS
IFsxXSBiYXNlZCBvbiB3aGF0IHBlb3BsZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgaGF2ZSBzYWlk
IGluIHRoaXMgdGhyZWFkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7IEknbSBzdXJlIHRoYXQgY2FuIGJlIGZ1cnRoZXIgaW1wcm92ZWQuPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSXQgbWlnaHQgYmUgbm8gaGFybSB0byBhZGQg
bW9yZSBwb2ludGVycyB0byB0aGF0IGFwcGVuZGl4IGZyb208YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
IGVsc2V3aGVyZSBpbiB0aGUgc3BlYywgYW5kL29yIHRvIGFkZCBhIGxpc3Qgb2YgdGhlIHZhcmlv
dXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHB1YmxpYy9wcml2YXRlIHJhbmRvbSBudW1iZXJzIHRo
YXQgYXJlIG5lZWRlZCB0byB0aGF0IGFwcGVuZGl4LiAoSSdkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyBiZSBoYXBweSB0byBkbyBhIHBhc3MgdG8gaWRlbnRpZnkgdGhvc2UgaWYgZm9sa3MgYmFzaWNh
bGx5IGxpa2UgdGhpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsga2luZCBvZiBhZGRpdGlvbi4pPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSSBhbHNvIG5lZWQgdG8g
ZmlndXJlIG91dCBob3cgdG8gaGFuZGxlIHRoZSByZWZlcmVuY2UgcHJvcGVybHk6LSk8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7IENhbiBkbyB0aGF0IHRvbW9ycm93Ljxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFMu
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgWzFdIDxhIGhyZWY9
Imh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL3B1bGwvMTA2OCIgcmVsPSJub3Jl
ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvPHdicj50
bHMxMy1zcGVjL3B1bGwvMTA2ODwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVExTIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRm
Lm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHJlbD0ibm9yZWZlcnJlciIg
dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3Rp
bmZvL3RsczwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19f
X19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IFRMUyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7
Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxi
cj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vdGxzPC9hPjxicj4NCiZndDsmZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IFRMUyBt
YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9y
ZyI+VExTQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9
Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vdGxz
PC9hPjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBUTFMgbWFp
bGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExT
QGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdGxzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby90bHM8L2E+PGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0
PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4N
CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiByZWw9
Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
Lzx3YnI+bGlzdGluZm8vdGxzPC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQotLSA8
YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPkNvbG08L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCg0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4=

--Apple-Mail-56D3470A-E27B-4B6E-8269-E5852CC2CD10--

--Apple-Mail-5A4C1CBC-408B-4A27-8EC6-5AEA1222CCC0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw
ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM
aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe
Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN
SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb
sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy
oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4
MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk
jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U
AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd
8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq
hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg
1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4
HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d
Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK
+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC
ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh
Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s
biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8
F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ
KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g
mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01
Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj
ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK
vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew
JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk
hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI
hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL
KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w
DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB
bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne
qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+
BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s
6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M
yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT
AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV
BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw
KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL
ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN
AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p
6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M
F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC
AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME
GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs
Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov
L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t
aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2
oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG
AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l
ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg
Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D
kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1
RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO
Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G
/HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9
Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD
VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM
IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTcwNzMwMDIzOTEzWjAjBgkqhkiG9w0BCQQxFgQUe65qvwN5R0La
/nAGVytMh0f4WM8wbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAHwdKcwkt5HkFHwVlY0LAkLTc0eX2IpE1gGaBwuU
qTINO6IWVghKrjBvd508m/usY1pU8VB3wN00jxTO/jBG/nzG7/7LUPufjz0CC+c+a+xH3kAjOcj7
6ZP6aJyeFOGQIAUG8IwMrGSVujhgdqQMEF4MECQiH1PMAaWTJy7MBrubLhZRxeaSfQeO5htB/g1m
U3yoNGslTk5bQyEJOGl0/xkW+X8D40xDpH6pAAWM6TuMz6tfPFl2Rro2aAdkRRmQxHDo4qRFs2Nd
Me88L9Tp3Mgza10sMYD/BlMMc8q4kpEbZkjKf0TEtPFBHTVpx5SnjUYa4QUzc/okvndCl2JCsPEA
AAAAAAA=

--Apple-Mail-5A4C1CBC-408B-4A27-8EC6-5AEA1222CCC0--


From nobody Sun Jul 30 17:28:47 2017
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 32B34131D08 for ; Sun, 30 Jul 2017 17:28: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 p2VizUc6JPkg for ; Sun, 30 Jul 2017 17:28:45 -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 1CAD9131D05 for ; Sun, 30 Jul 2017 17:28:45 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id l7so105973753iof.1 for ; Sun, 30 Jul 2017 17:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8VBLnYelukqLpp69ptFK8qayD+nBj/BfWyW7efXZmYs=; b=bogVf4MxE8W1wMH8paGLEJQLaHZeYte1iQtbcwLcgOwSYU1InczgyZXxYZ07lQCaSf xrtLqcLRVhLk2UFI6vLxYIt5VuS8sAKGOPMTlESM31NJ4CPB6nInrGmjjy9rFxEv43UU lNClTXq3jeJf5R+UrTKWIo9oVYp63lJuk9iW05tfd0M05eq0jtqZkYZOmPekpuHAk+gp 7SRL4cdTjsEVEGw6jyiz+nq3U00nA+OgGe8ik847aEmZ97llkjFEh0kyDzs3BFLMPXij 13LNwtyKNB7DpaCIWPgZM2uPqHWF7eZFTfmTg0m/QsJCzEwGmYDjdsgxe+aJH2JgVy0X c1Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8VBLnYelukqLpp69ptFK8qayD+nBj/BfWyW7efXZmYs=; b=gLIsi0ZrHO5jzcuoDEVMutdn3qHl1rP6s9iD3zuTWOhANAuAo23nCM+bCYTMI4/LaB T2TpD7zwMHZmDXw7njRXMHMC5rGsYpOPm16VYNEGFKKdA/QovgzFe0JxIOgYMzU6rM+I ES9uK/Ki1GrkcJbOi3mi8Z19hgauNlrsZLu3n6Lbr/Aw5pscYpc7RujI54KzDJYLC5LC SN64vkFYC0WCAUvc1cMhS4my3J8fuVl24AL5eVVahgs6pNhrWwHE8oToYLY6Mh2UZKPD fOOU2AL93YoMJWmC3rKC6Z2wryqyhgr4WASjy+BOGvmhDK6KNmTE3ufE25bCpsv4+9LF hdNg==
X-Gm-Message-State: AIVw112Z4m3B1jsT4Hfa/cG0lVvK1OnosShe9MdPOxU22lp66jM2jDSd /jEiPfdiBGbxcf2Tj0a9VVCst8XxJw==
X-Received: by 10.107.16.196 with SMTP id 65mr18848149ioq.297.1501460924536; Sun, 30 Jul 2017 17:28:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.42 with HTTP; Sun, 30 Jul 2017 17:28:44 -0700 (PDT)
In-Reply-To: <1743154.SRp0UpLzoG@pintsize.usersys.redhat.com>
References: <1985136.n8kX8SZK3z@pintsize.usersys.redhat.com>  <1743154.SRp0UpLzoG@pintsize.usersys.redhat.com>
From: Martin Thomson 
Date: Mon, 31 Jul 2017 10:28:44 +1000
Message-ID: 
To: Hubert Kario 
Cc: Benjamin Kaduk , "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] ClientHello1[truncated] - definitions?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 31 Jul 2017 00:28:46 -0000

On 28 July 2017 at 23:44, Hubert Kario  wrote:
> something like this:
>
>    ClientHello1 is the initial ClientHello and ClientHello2 is the ClientHello
>    send by client as a response to HelloRetryRequest. For both of those
>    messages, the binder value will be computer over:
>
>      truncated = Handshake.length - length(Extension.extension_data)
>      Transcript-Hash(ClientHello1[truncated])
>
>   Given Handshake message that contains the ClientHello message and the
>   Extension that contains the PreSharedKeyExtension.

I think that what you want is

ClientHello1_truncated - ClientHello1.length -
PreSharedKeyExtension.binders.length

And you need to point out that the length of the binders is included, i.e.,

PreSharedKeyExtension.binders.length = 2 +
sum(PreSharedKeyExtension.binders[i].length)


From nobody Mon Jul 31 01:13:54 2017
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 AEDDA131EBA for ; Mon, 31 Jul 2017 01:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Rkf9vZn389rk for ; Mon, 31 Jul 2017 01:13:51 -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 4F70B128961 for ; Mon, 31 Jul 2017 01:13:51 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 860FCC12CA00; Mon, 31 Jul 2017 08:13:50 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 860FCC12CA00
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3C47D931ED; Mon, 31 Jul 2017 08:13:50 +0000 (UTC)
From: Hubert Kario 
To: Martin Thomson 
Cc: Benjamin Kaduk , "tls@ietf.org" 
Date: Mon, 31 Jul 2017 10:13:44 +0200
Message-ID: <42904141.7nftgiudgT@pintsize.usersys.redhat.com>
In-Reply-To: 
References: <1985136.n8kX8SZK3z@pintsize.usersys.redhat.com> <1743154.SRp0UpLzoG@pintsize.usersys.redhat.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart14724939.zHBpRBxgMs"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 31 Jul 2017 08:13:50 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] ClientHello1[truncated] - definitions?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 31 Jul 2017 08:13:52 -0000

--nextPart14724939.zHBpRBxgMs
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Monday, 31 July 2017 02:28:44 CEST Martin Thomson wrote:
> On 28 July 2017 at 23:44, Hubert Kario  wrote:
> > something like this:
> >    ClientHello1 is the initial ClientHello and ClientHello2 is the
> >    ClientHello
> >    send by client as a response to HelloRetryRequest. For both of those
> >   =20
> >    messages, the binder value will be computer over:
> >      truncated =3D Handshake.length - length(Extension.extension_data)
> >      Transcript-Hash(ClientHello1[truncated])
> >  =20
> >   Given Handshake message that contains the ClientHello message and the
> >   Extension that contains the PreSharedKeyExtension.
>=20
> I think that what you want is
>=20
> ClientHello1_truncated - ClientHello1.length -
> PreSharedKeyExtension.binders.length
>=20
> And you need to point out that the length of the binders is included, i.e=
=2E,
>=20
> PreSharedKeyExtension.binders.length =3D 2 +
> sum(PreSharedKeyExtension.binders[i].length)

aah, yes, on second reading I noticed that identities are not supposed to b=
e=20
removed, so yes it's without binders.length, not extension.length.

I went for the generic ClientHello instead of ClientHello1 as it applies bo=
th=20
to initial and the one that is a response to Hello Retry Request, but the P=
SK=20
extension is the same in both cases so explicit name of it would probably b=
e=20
better.

There's a slight problem with the syntax of=20
  PreSharedKeyExtension.binders[i]
as [] are used to define a length of a vector, and in that is contrary to t=
he=20
meaning of
   ClientHello1[truncated]

I think it would be cleaner to include that "2" in original and explain whe=
re=20
it comes from rather than defining `length` different ways for the `binders=
`=20
vector and for the  PSKIdentity struct.

=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 115, 612 00  Brno, Czech Republic
--nextPart14724939.zHBpRBxgMs
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

iQIcBAABCgAGBQJZfua4AAoJEJKo0bgB0vX1iKkP/2N8cxj3MsV/C8II1alAIsDU
yp7UzPzm/0INLroDhf54Zq4rh0NWBmeQHhfVwRmpUQP999AXvk/JW5YhAyW0R1yr
KvyifjfFJnmg/pIMHu3AJkd3PlboRlcpVvNJ/FyXECwT+hhSwhzzMpL4WZsCAaHm
3Dvs6y3UZGZ1xZ5Tg0XkZTnGhsOIucdHHwAJt2otLxPKD+aBC6o2Yl6RNZR8ikVK
I6xMmV2LxlIlXT35mLp/VmSKfCinGtvSdGSeazUxGr++Asvg/d9RI6BzHYl/qtbU
mxCJcVrxNXb7bL89LGudQQccDqlCsf+Wg0dkZE9uj8tpl8kFnY9yM120Ep8Cln7b
u01i5hrbzTSSlguMj09jnod5KEIkFUfB+Q5YSlnilHjZd8dlIp2rsmxC9of+Yokm
GY1V3RT8eINLRVtZT6I/QCYeKd7jay6TQv8JYkaKXPGCy+xHhtxCNk+ph7Lq7QYn
L5uYkA6WL79QETtMElqjfxc8jVDMTWlSAyFMSYE9//g4X8YXrSF33+UdQkTo2nR2
IisnJf2i2vwOcICYLhvs5l3JlSatZW2djg+D6NBcAuVB/l3shvOJJDefOoVt8JuB
QQp0/9nffmysQUserUrMjYWuBz7vIQb28J9lzTyLWeNFXpgtjS9v6Zmx/gmysOCC
YN7uYAEp+FhiTsBxsBfu
=dQV3
-----END PGP SIGNATURE-----

--nextPart14724939.zHBpRBxgMs--


From nobody Mon Jul 31 06:54:35 2017
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 55FB01322F3 for ; Mon, 31 Jul 2017 06:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 lCsb4_APKfrO for ; Mon, 31 Jul 2017 06:54:32 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765FE1322EF for ; Mon, 31 Jul 2017 06:54:31 -0700 (PDT)
Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jul 2017 09:54:31 -0400
Received: from XCT199YKF.rim.net (10.2.25.7) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 31 Jul 2017 09:54:30 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT199YKF.rim.net ([fe80::3026:d39d:47da:9fa3%12]) with mapi id 14.03.0319.002; Mon, 31 Jul 2017 09:54:30 -0400
From: Dan Brown 
To: Stephen Farrell , Eric Rescorla ,  "Blumenthal, Uri - 0553 - MITLL" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+yUHLG+hMivEObnVpzx6wh/KJjeS0AgAC0BYCAAI15AIAAcHiAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDwAgAANUQCAABPSAIAABQGAgAAkyoCAAYN2AP//zaLlgABFtACAAAITAIAAleMAgAADerCAAHJeAIAETPYg
Date: Mon, 31 Jul 2017 13:54:29 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501B78355@XMB116CNC.rim.net>
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie>
In-Reply-To: <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.252]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 31 Jul 2017 13:54:34 -0000

LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRv
OnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIA0KDQpJIGRvbid0IHRoaW5rIHRoaXMgaXMgc2lt
cGx5IGEgY2FzZSBvZiBtdWx0aXBsZSBDU1BSTkdzLg0KDQpEQj4gTm90IHF1aXRlIHN1cmUgd2hh
dCB5b3UgbWVhbiBieSAic2ltcGx5IGEgY2FzZSBvZiBtdWx0aXBsZSBDU1BSTkdzIiwgYnV0IEkg
YW0gc3RhcnRpbmcgdG8gZ2V0IGFuIGlkZWEgYmVsb3cuDQoNCk15IGd1ZXNzIGlzIG1hbnkgVExT
IGltcGxlbWVudGF0aW9ucyBkb24ndCBoYXZlIHZpc2liaWxpdHkgaW50byBob3cgdGhlIENTUFJO
RyBvcGVyYXRlcy4gVGhhdCBjb2RlIGRvZXMgaG93ZXZlciwga25vdyB3aGljaCBvdXRwdXQgdmFs
dWVzIHdpbGwgYmUgcHVibGljIGFuZCB3aGljaCBub3QuIEZvciBtZSwgdGhhdCBpbXBsaWVzIHRo
YXQgYW55IGdvb2Qgc2VwYXJhdGlvbiBzY2hlbWUgYXBwbGllZCB3aXRoaW4gdGhlIFRMUyBjb2Rl
IHRoYXQgZGlmZmVyZW50aWF0ZXMgYmV0d2VlbiBwdWJsaWMgYW5kIG5vbiBwdWJsaWMgb3V0cHV0
cyBpcyBhIGdvb2QgcGxhbi4gDQoNCkRCPiBPaywgc3VwcG9zZSB0aGUgVExTIGltcGxlbWVudGF0
aW9uIHdpc2hlcyB0byBqdXN0IHJlYWQgL2Rldi91cmFuZG9tLCB3aGljaCBpcyBwcmVzdW1hYmx5
IGEgZ29vZCBDU1BSTkcuICBVbmxpa2UgdGhlIE5JU1QgUkJHcywgdGhlcmUncyBubyBpbnRlcmZh
Y2UgdG8gY3JlYXRlIGluZGVwZW5kZW50IGFuZCBzZXBhcmF0ZSBpbnN0YW50aWF0aW9ucyBvZiAv
ZGV2L3VyYW5kb20gKGFzIGZhciBhcyBJIGtub3csIGFsdGhvdWdoIG5ld2VyIHZlcnNpb25zIG1h
eSBwcm92aWRlIHRoaXMgZmVhdHVyZSkuICBTbywgd2hhdCB3b3VsZCBjb3VudCBhcyB5b3VyICJz
ZXBhcmF0aW9uIHNjaGVtZSI/ICBBcmUgeW91IHNheWluZyB0aGUgVExTIGNvZGUgc2hvdWxkIHBv
c3QtcHJvY2VzcyB0aGUgb3V0cHV0IG9mIGEgc2luZ2xlIENTUFJORz8gIElmIHNvLCB0aGVuIHRo
YXQncyBwcm9iYWJseSBhIGdvb2QgaWRlYSwgaWYgZG9uZSByaWdodC4gIEF0IGxlYXN0IGl0IGRv
ZXNuJ3QgaGF2ZSB0aGUgZG93bnNpZGUgcmlzayBvZiB0aGUgVExTIGNvZGVyIGdlbmVyYXRpbmcg
aXRzIG93biBzZWVkcywgd3JpdGluZyBpdHMgb3duIENTUFJORyAoaW5zdGVhZCBvZiB1c2luZyAv
ZGV2L3VyYW5kb20pLCBldGMuICAoSSB0aG91Z2h0IHRoYXQgSSB3YXMgYmVpbmcgdmVyeSBzcGVj
aWZpYyB0aGF0IGxhdW5jaGluZyAyIENTUFJOR3Mgd2FzIG5vdCBhIGdvb2QgaWRlYSwgeWV0IGl0
IHNlZW1zIEkgd2FzIHJlYWQgYXMgcHJlZmVycmluZyBhcyBkb2luZyBub3RoaW5nIGFuZCBrZWVw
aW5nIHRoZSBzdGF0dXMgcXVvLCB3aGljaCBpcyBub3Qgd2hhdCBJIGludGVuZGVkLikgIFNvLCBJ
IHRoaW5rIHNvbWUga2luZCBvZiBjbGFyaWZpY2F0aW9uIG9mIHRoZSBjdXJyZW50bHkgcHJvcG9z
ZWQgdGV4dCAoZm9yIC0yMSA/KSAgbWF5IGJlIHdvcnRod2hpbGUsIGJlY2F1c2UgSSByZWFkIGl0
IGNyZWF0aW5nIHR3byBzZXBhcmF0ZSBDU1BSTkdzLiAgKE9mIGNvdXJzZSwgZGVmZW5jZSBpbiBk
ZXB0aCBpcyBnb29kLCBhbmQgb2Z0ZW4gd29ydGggdGhlIGltcGxlbWVudGF0aW9uIGNvc3QsIGJ1
dCBpZiBpdCBpbnRyb2R1Y2VzIG5ldyBzZWN1cml0eSBwcm9ibGVtcywgdGhlbiBpdCBpcyBub3Qg
dG9vIGdvb2QuICBNb3JlIHBoaWxvc29waGljYWxseSwgaW4gYW4gaWRlYWwgd29ybGQsIGFueSBh
ZGRpdGlvbnMgdG8gdGhlIFRMUyBzcGVjIHNob3VsZCBiZSB2ZXR0ZWQgd2l0aCBwZWRpZ3JlZS4g
IFRyeWluZyB0byBjcmVhdGUgaW5kZXBlbmRlbnRseSBzZWVkZWQgQ1NQUk5HcyBnb2VzIGFnYWlu
c3QgdGhlIGN1cnJlbnQgYmVzdCBwcmFjdGljZXMgYXMgSSB1bmRlcnN0YW5kIHRoZW0uICBCeSBj
b250cmFzdCwgVExTIGFscmVhZHkgaGFzIGFsbCBraW5kcyBvZiBrZXkgZGVyaXZhdGlvbiwgc2Vw
YXJhdGlvbiBmb3IgZGlmZmVyZW50IHB1cnBvc2VzICh1bmxlc3MgdGhhdCB3YXMgZHJvcHBlZCBp
biAxLjM/Pz8pLCB3aGljaCBUTFMgbWlnaHQgYXMgd2VsbCBjb250aW51ZSB0byB1c2UuICANCg0K


From nobody Mon Jul 31 08:24:20 2017
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 5534413252B for ; Mon, 31 Jul 2017 08:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 TTeqnBmPvmqc for ; Mon, 31 Jul 2017 08:24:14 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 92E54132515 for ; Mon, 31 Jul 2017 08:24:13 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6VFO6K8008431; Mon, 31 Jul 2017 11:24:06 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Dan Brown , Stephen Farrell , Eric Rescorla 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI/QFdXms6d7jEaZNtjFKD2eRqJjeSwAgAC0BYCAAI15AIAAcHmAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDsAgAANUgCAABPRAIAABQKAgAAkyYCAAYN3AIAAELAAgAACowCAAAIWAIAAleMAgABRLoCAACSpAIAElxGA///V+oA=
Date: Mon, 31 Jul 2017 15:24:05 +0000
Message-ID: 
References:  <20170726205732.784F41A6CB@ld9781.wdf.sap.corp>  <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie>  <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu>  <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B78355@XMB116CNC.rim.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B78355@XMB116CNC.rim.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.24.1.170721
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3584345045_1457748084"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1706020000 definitions=main-1707310261
Archived-At: 
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list 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, 31 Jul 2017 15:24:18 -0000

--B_3584345045_1457748084
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

       My guess is many TLS implementations don't have visibility into how =
the CSPRNG operates.
       That code does however, know which output values will be public and =
which not. For me, that
       implies that any good separation scheme applied within the TLS code =
that differentiates
       between public and non public outputs is a good plan.=20

Hasn=E2=80=99t this been the whole point of the discussion?! The proposal to sepa=
rate PRNGs into those that supply publicly-visible randomness (nonces, etc),=
 and those that supply =E2=80=9Csecret=E2=80=9D randomness (keying material and such)? T=
hus, having *two* PRNGs, each (hopefully) properly seeded?

I=E2=80=99m glad you=E2=80=99re now agreeing that the above is a good plan.
=20

--B_3584345045_1457748084
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU
WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO
DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A
97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN
YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR
COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x
dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01
c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ
KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G
/F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL
e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK
MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z
MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C
8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg
+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH
YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC
64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB
sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud
h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF
BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB
DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT
AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV
ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg
Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL
d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp
+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL
MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c
A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgLdHOG3yzjKsfybdT
cQ9XB7GuvXW+FBmP58a31tYGLf8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTcwNzMxMTUyNDA1WjANBgkqhkiG9w0BAQEFAASCAQAOdLtC0GvPTw3aP8u+
RvjHH0Okt4XaKJmUJRLgyPDF58CkksCPifGuvSO6E+BqdGPIVPE97Np+Yg8GxtLsmX7wApHX
3Pu4jKJXm9cGmApB9pMD3CG+Q7G2jvy3iH86Z1PKZ1n+15mI0nt1iQu+NsN/L+V1R/2ECrUL
3uxtEyvk3XVhkGp/D1G9nhnl+HrIYX1swK+XQswXfc1x9uAEJHY+c5JSsLJvqNrhCbzvqThL
H8b5q13iRMhaipb1ixGqv9WpeRAw4bTVZ5eL8Q8LUY+V1BaA5l5gIkHQt+3vZlqDTdc5AUQl
sfTUibmZGRNSJnV3NUQU/fHa/a/AypoxRuBg

--B_3584345045_1457748084--