From nobody Sat Feb 1 07:54:08 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2FA12013C for ; Sat, 1 Feb 2020 07:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNIGjqd1vpQq for ; Sat, 1 Feb 2020 07:54:02 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 8A15B120804 for ; Sat, 1 Feb 2020 07:54:02 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 011FkoU0018692; Sat, 1 Feb 2020 07:53:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : content-transfer-encoding : mime-version : subject : from : in-reply-to : cc : date : message-id : references : to; s=20180706; bh=fJflOe4ygqzU1MsTgImeQAXfRRzbnOEkYUMQIfkTgbE=; b=tIPx0AdQNmt/72j2QnYhmlCpDydPE1qsVI/Qb5NZEH8oRporTIt1blkFlkcRhiJiokaJ 7oq80KqbgvXoewwx2mfw0JcwNHkBUdTiaRXWvsJyc86csJO8bvi553QbtjHigoJdBkjr eD4m+jX9YWNL6oGVQYK8M8jpXQGxKNaeOGom4TG1EO36t/x/Wd88zGaX4Lo3BY7qA34X MmqaVFu0cYwYs88rIQXb9M22NKfJjs350FCoeIXyFFLdUJiuoZJMDKMujSlb8gSj1Qx/ YW0s0E1iBIJG/ksCu4dFN+F/nKZQLZQXGUFtwEbQMGFvwMosEaN7nfgle+A4Rnf0a/CT xw== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2xw8v6cwmg-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 01 Feb 2020 07:53:59 -0800 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q5100W9V5HYQ740@rn-mailsvcp-mta-lapp01.rno.apple.com>; Sat, 01 Feb 2020 07:53:58 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5100M004VMBN00@nwk-mmpp-sz11.apple.com>; Sat, 01 Feb 2020 07:53:58 -0800 (PST) X-Va-A: X-Va-T-CD: b885964abc53914bb4dc9f6410fd4b52 X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-Va-CD: 0 X-Va-ID: 2d842721-cd26-49b0-8f9b-be06441e0a93 X-V-A: X-V-T-CD: b885964abc53914bb4dc9f6410fd4b52 X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-V-CD: 0 X-V-ID: 81144eaf-ac28-4419-89ab-b75959aebb71 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-01_03:,, signatures=0 Received: from [17.234.53.54] (unknown [17.234.53.54]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q5100AVD5HYVT50@nwk-mmpp-sz11.apple.com>; Sat, 01 Feb 2020 07:53:58 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable MIME-version: 1.0 (1.0) From: Tommy Pauly In-reply-to: <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie> Cc: IETF TLS WG Date: Sat, 01 Feb 2020 07:53:57 -0800 Message-id: <9A5EE7C8-360D-49C0-92F8-274FE1A94249@apple.com> References: <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie> To: Stephen Farrell X-Mailer: iPhone Mail (18A214) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-01_03:, , signatures=0 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 15:54:06 -0000 > On Jan 31, 2020, at 6:14 PM, Stephen Farrell w= rote: >=20 > =EF=BB=BF > Hiya, >=20 > I have no particular position about this draft but > am curious about 2 things: >=20 > #1 I don't get why it's not possible for postfix to > determine the best way to manage tickets based on the > destination port to which the ClientHello is sent. I > totally get why that won't solve 100% of cases, but it > would surely solve a huge percentage? Apologies if an > answer was already posted as part of this v. long > thread. >=20 > #2 I don't get why Viktor's request for special handling > for value 255 is a real problem for anyone. We have > another thread today envisaging 2040 extensions flags, > so I really have a hard time seeing what here justifies > rejecting Viktor's argument. FWIW, this thread has not > provided me with an obvious answer to #2 other than "not- > invented-here." I'm not sure that declaring things in the > rough where the only identifiable issue is NIH is the > overall best outcome, longer term. That=E2=80=99s a fair point, and worth clarifying. Totally agree that NIH is= n=E2=80=99t a good reason. Instead, it seems unclear what value the special u= se of 0 and 255 adds that wouldn=E2=80=99t be better served by a separate ex= tension. Today, without any sentinel values, 0 means the client hints that it doesn=E2= =80=99t need any tickets, and N means that the client hints that it would li= ke N tickets. Whether or not a ticket is intended to be reused is not part o= f this, and ticket reuse is elsewhere discouraged. As far as I understand the proposal, the meaning currently expressed by send= ing 0 would be expressed by sending 255 instead; and sending 0 would take on= a new meaning that is =E2=80=9Csend a ticket if you want, and I may try to r= euse a ticket if you don=E2=80=99t send one=E2=80=9D, which seems like the b= ehavior already expressed by not sending the ticket request message at all (= since not passing the message is equivalent to no hint). To that end, the proposed change doesn=E2=80=99t seem to add any new signali= ng capabilities, but makes the meanings of numbers less intuitive. If the hint is intended to be =E2=80=9CI=E2=80=99m planning on reusing ticke= ts, let me know ahead of time if I shouldn=E2=80=99t=E2=80=9D, that seems li= ke it could be an explicit signal sent that doesn=E2=80=99t need to reuse a f= ield that is a numeric count of tickets being requested. It seems like there= is a small number of clients that would use this, so adding another message= to signal this and potentially more info about reuse policy would make more= sense and could be fleshed out in more detail separately. For example, if w= e add the proposed hint that presumably means =E2=80=9Cif you give me a new t= icket, I=E2=80=99ll use it; but if you don=E2=80=99t, I=E2=80=99ll reuse an o= ld one=E2=80=9D, the client is essentially forcing a server that doesn=E2=80= =99t want ticket reuse to issue a new ticket; whereas a more explicit signal= could indicate that the server won=E2=80=99t allow ticket reuse, so the cli= ent shouldn=E2=80=99t even try, etc, without necessarily giving out new tick= ets.=20 Best, Tommy >=20 > Cheers, > S. >=20 > <0x5AB2FAF17B172BEA.asc> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Feb 1 17:30:24 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CF81201AA for ; Sat, 1 Feb 2020 17:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 HUHaVklYX6NY for ; Sat, 1 Feb 2020 17:30:19 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC6B120013 for ; Sat, 1 Feb 2020 17:30:17 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id D82D238551; Sat, 1 Feb 2020 20:30:16 -0500 (EST) Date: Sat, 1 Feb 2020 20:30:16 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20200202013016.GH49778@straasha.imrryr.org> Reply-To: tls@ietf.org References: <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie> <9A5EE7C8-360D-49C0-92F8-274FE1A94249@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9A5EE7C8-360D-49C0-92F8-274FE1A94249@apple.com> User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 01:30:22 -0000 On Sat, Feb 01, 2020 at 07:53:57AM -0800, Tommy Pauly wrote: > Instead, it seems unclear what value the special use of 0 and 255 adds > that wouldn’t be better served by a separate extension. The benefit of the new value of "0" is *unambiguous* signalling that the client would like to reuse the ticket if possible, and the new "255" then carries the "We don't need no stinking tickets" signal. > Today, without any sentinel values, 0 means the client hints that it > doesn’t need any tickets, and N means that the client hints that it > would like N tickets. Whether or not a ticket is intended to be reused > is not part of this, and ticket reuse is elsewhere discouraged. And the same remains true with my proposal, with the only difference being that 0 replaced by 255, and the new 0 as discouraged as it was before. Nothing we do or can do prevents a *consenting* client and server from reusing tickets, no matter what form this extension ultimately takes. All I'm proposing is a minor change to allow the consent to be negotiated, rather than guessed unilaterally by the server, likely incorrectly in various cases. With negotiated consent, clients that don't want to reuse talking to a server that supports reuse will get fresh tickets. Otherwise, they don't, and end up doing a full handshake 50% of the time. > As far as I understand the proposal, the meaning currently expressed > by sending 0 would be expressed by sending 255 instead; Correct. > and sending 0 would take on a new meaning that is “send a ticket if > you want, and I may try to reuse a ticket if you don’t send one”, Correct. > which seems like the behavior already expressed by not sending the > ticket request message at all (since not passing the message is > equivalent to no hint). No, it is not, because not sending the extension is status quo, and will be for quite some time as the extension will not be available to most clients for quite some time. Is it your position that once the extension is defined, servers should assume a desire or willingness to reuse if the extension is not sent? If the document makes it clear, that *absent* the extension servers that are *willing* to support reuse SHOULD impute that the client is willing to reuse (and thus clients that don't reuse need to send the extension to ensure any fresh tickets on resumption): Then indeed the desired signal becomes not sending the extension. But, that would mean that legacy clients that don't implement the extension get presumptive reuse (from reuse-supporting servers) for quite some time as the extension gradually gets adopted. If that's OK, then let's specify that. > To that end, the proposed change doesn’t seem to add any new signaling > capabilities, but makes the meanings of numbers less intuitive. Well, it makes the signalling unambiguous, given that without this extension we presently have no indication of client preference. If however, the extension redefines absence of signal to mean willingness to reuse if the server so chooses, then the ambiguity goes away, and implementations that support conditional reuse default to reuse on not receiving the extension. This makes reuse be "opt-out", rather than "opt-in". Which may not be the best way to discourage it, but once the extension is broadly supported (and enabled by default) the difference starts to fade. > If the hint is intended to be “I’m planning on reusing tickets, let me > know ahead of time if I shouldn’t”, No, the hint is simply "send me a new ticket if I can't (already expired) or shouln't (will soon expire) reuse what I just sent". > It seems like there is a small number of clients that would use this, Just a few million MTAs, on-prem industrial controllers, ... > For example, if we add the proposed hint that presumably means “if you > give me a new ticket, I’ll use it; but if you don’t, I’ll reuse an old > one”, the client is essentially forcing a server that doesn’t want > ticket reuse to issue a new ticket No. Clients can attempt reuse no matter what the server does, but they SHOULD use any fresh ticket from the server because the server may no longer accept the old one. With or without this extension a server that does not want reuse should vend a fresh ticket unless it knows that the client does not to resumption at all (255 or 0, wherever the chips fall). > whereas a more explicit signal could indicate that the server won’t > allow ticket reuse, so the client shouldn’t even try, etc, without > necessarily giving out new tickets. Well, that's a completely different server->client signal, saying "don't reuse", and does not replace the proposed "client->server" signal. But it makes no sense for servers to refuse reuse and also not vend fresh tickets, unless they simply don't support resumption and never vend tickets in the first place (in which case no such signal is needed). Therefore the way to indicate that a ticket is no longer valid is to issue a replacement ticket (possibly after performing a full handshake to revalidate the client cert, if the session is too old). This largely obviates any need for a server->client signal. A server can also always refuse old tickets (but that requires keeping track of sufficiently recently used tickets). Above I said "largely obviates", because a client making parallel connections might race to reuse a ticket in parallel before any of the parallel connections return a fresh ticket. Therefore, a signal from server to client meaning "my tickets are single-use" is potentially useful. If so, it should be in the server variant (response) of this extension. -- Viktor. From nobody Sat Feb 1 19:05:10 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93663120024 for ; Sat, 1 Feb 2020 19:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 y2C1M8J4XJFn for ; Sat, 1 Feb 2020 19:05:06 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 6EA23120020 for ; Sat, 1 Feb 2020 19:05:06 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id q8so11123469ljb.2 for ; Sat, 01 Feb 2020 19:05:06 -0800 (PST) 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=5nTxdFgJ/8w0L+4vFvrcsLabebjGqYvwIHt1D457pSc=; b=mFQeH3/Mf1wG6LgYOd3bTvhtv+hDe9wAhMiWDwHZu8XH1i9D9O+sMmhjIQc4HG2PCq R1kEeBY8UcJnCF6WIky3vayDJybS6BmWz/adez5+EXuRVhc5c1rT+9In5K7pueyy5iYv CGjQrx2kYaARIoV/wtjOq1hmJrbndWaBXwe3Jni+BpmJNMxdBGOv+Rw34+06eWh5HyIn 16whdKIxCQzgGsguaI9RlbYTTpJDhwJBTBL/UTEAAzfVH7wLyYSeuWGa3yvz/EUpgBw5 2ZvCl+ZSF/D3ilIWkbTtYkURdXbwf7e5O/8qmje5VtmLNzeA4amhVGwJOO8lGWORXLD1 oZuA== 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=5nTxdFgJ/8w0L+4vFvrcsLabebjGqYvwIHt1D457pSc=; b=IQbb/D5YGOVilpTTfmOlVC6//wfDssEDn8v7cYjmIVn/27MWz36OSTPLz5dWhZ/KX1 jYqZgIER6/VNx35vF34Q+cF/N2FvLT6zRUVWF8iq8Hdn/0iroCvDjw1TWI0rEU1k0jJq bwuPAxksQIhYFfoZp6RXnx/aNawOzlCh9gcQeeN8NIAk/nn+VMxbzYmEdzw+mhoSOIHB erup1HpUZLYvk/t8W5cnY6Sh3OmeHiD2dmUiPOuazAIqHjYnBvecuibxXEZa2EFwS/Bj dmpRVdtThBNaJP7Ctr3pWj3rPREeqCj8hokXIDzmOlm88QyUmwmIs8Bplu3QUVXdrh00 59rQ== X-Gm-Message-State: APjAAAXFYRPSQz65q+zG580R6RU8UDfpecQfoAodCjCIPQ3BhudRf4ZQ zzMDVwdopHZOo4no66iuhR6t8OPtSxBHrjRzDLjAuc8JfJo= X-Google-Smtp-Source: APXvYqwSWpvSN9rxUkzuxhb2kxsHkdwrW/prjFN87VV7aCgJXiUYpddwU3W8jo0PfBvwPzpz6AXrsZrlU4vELXXTWdE= X-Received: by 2002:a2e:9b90:: with SMTP id z16mr9236841lji.254.1580612704460; Sat, 01 Feb 2020 19:05:04 -0800 (PST) MIME-Version: 1.0 References: <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie> <9A5EE7C8-360D-49C0-92F8-274FE1A94249@apple.com> <20200202013016.GH49778@straasha.imrryr.org> In-Reply-To: <20200202013016.GH49778@straasha.imrryr.org> From: Watson Ladd Date: Sat, 1 Feb 2020 19:04:53 -0800 Message-ID: To: TLS List Content-Type: multipart/alternative; boundary="000000000000c6e11f059d8f1237" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 03:05:08 -0000 --000000000000c6e11f059d8f1237 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 1, 2020 at 5:30 PM Viktor Dukhovni wrote: > On Sat, Feb 01, 2020 at 07:53:57AM -0800, Tommy Pauly wrote: > > > Instead, it seems unclear what value the special use of 0 and 255 adds > > that wouldn=E2=80=99t be better served by a separate extension. > > The benefit of the new value of "0" is *unambiguous* signalling that the > client would like to reuse the ticket if possible, and the new "255" > then carries the "We don't need no stinking tickets" signal. > Brown sticker conventions belong in the Bermuda Bowl, not TLS. I'd be happier with a magic 0, or a N =3D valid tickets at the end including the o= ne used, then swapping 2 values and making one magic. (For those of you who aren't bridge fiends: https://en.wikipedia.org/wiki/Brown_sticker) Sincerely, Watson --000000000000c6e11f059d8f1237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Feb 1, 2020 at 5:30 PM Viktor= Dukhovni <ietf-dane@dukhovni.= org> wrote:
On Sat, Feb 01, 2020 at 07:53:57AM -0800, Tommy Pauly wrote:

> Instead, it seems unclear what value the special use of 0 and 255 adds=
> that wouldn=E2=80=99t be better served by a separate extension.

The benefit of the new value of "0" is *unambiguous* signalling t= hat the
client would like to reuse the ticket if possible, and the new "255&qu= ot;
then carries the "We don't need no stinking tickets" signal.<= br>

Brown sticker conventions belong in the= Bermuda Bowl, not TLS. I'd be happier with a magic 0, or a N =3D valid= tickets at the end including the one used, then swapping 2 values and maki= ng one magic.
(For those of you who aren't bridge fiends: https://en.wikipedia.or= g/wiki/Brown_sticker)

Sincerely,
Watson
--000000000000c6e11f059d8f1237-- From nobody Sat Feb 1 19:58:55 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074931200FD for ; Sat, 1 Feb 2020 19:58:53 -0800 (PST) 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, SPF_HELO_NONE=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 Nvw3CPatBKkE for ; Sat, 1 Feb 2020 19:58:50 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30924120020 for ; Sat, 1 Feb 2020 19:58:50 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 94746386FD; Sat, 1 Feb 2020 22:58:48 -0500 (EST) Date: Sat, 1 Feb 2020 22:58:48 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20200202035848.GJ49778@straasha.imrryr.org> Reply-To: tls@ietf.org References: <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie> <9A5EE7C8-360D-49C0-92F8-274FE1A94249@apple.com> <20200202013016.GH49778@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 03:58:53 -0000 On Sat, Feb 01, 2020 at 07:04:53PM -0800, Watson Ladd wrote: > > The benefit of the new value of "0" is *unambiguous* signalling that the > > client would like to reuse the ticket if possible, and the new "255" > > then carries the "We don't need no stinking tickets" signal. > > > > I'd be happier with a magic 0, or a N = valid tickets at the end > including the one used, then swapping 2 values and making one magic. > (For those of you who aren't bridge fiends: > https://en.wikipedia.org/wiki/Brown_sticker) Sorry, no idea what that above means. And is it simpler than the proposal under discussion (which got some fine-tuning in early feedback)? -- Viktor. From nobody Sat Feb 1 20:05:44 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3181200FD for ; Sat, 1 Feb 2020 20:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 00dQXQgqcV8N for ; Sat, 1 Feb 2020 20:05:41 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 4C909120045 for ; Sat, 1 Feb 2020 20:05:41 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id v17so11175117ljg.4 for ; Sat, 01 Feb 2020 20:05:41 -0800 (PST) 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=qysEfgaopk5vTELO0sbseyaVqsxrbtbz/OWVXO+DLbg=; b=HTwk4GWZsGiHJv4ekeGBXLAUXJZLogr3JTVKnidFf7eBThiQkNoUO9dTz8TBuuUn8q YWA6M/ugmNstOs9cwQF9/fB5cXLCia91oXZNyG0xSQUbKK2eVJEXpVLxyG2RkQCpmffx omEkqlZQShdUj5mTCH2RrlWwqP4WQf2tTq8jAlEOZbYmCuPGWCzWq1Y9wncKxGTmn03Y 9hrsw0PCDcW7mqmP7k3XvZJGhDh4xE/AC34iIrphK7mUZcjt1Y7/OnQ5YjYHR5nMuYQj 7o09FhbTmqjPA5GD86/oB+vF2xUpNqsVCQ3xmEwy3ACwp1EbafknYUhjFyTOYdNjs4jb /e3g== 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=qysEfgaopk5vTELO0sbseyaVqsxrbtbz/OWVXO+DLbg=; b=T6bJroCKq/vAd2Uyk5O0CKEPmQ2FQSBMn0BESkHYw56DIOjT41wzaQF+wLHLwyhCmo IosJs3LazYrKpQVC8uF2VX3VH1+OKfanOsecv7r6DeTlhecUnPuIeb4dO1KIRGMbT1pE hfvqVim4oAw0O/gjpIDBljR7QVmH5ojddWKi23xuPwSmJ23IzaCImxriAb3nD0Zh8PT6 2rYHvTasDBFIX/DNZ58Vjg1j/RxtqBXYvec9Pola60FgidSKWPgnadv2pC7hP+PzJ6F0 rJv6CanLH6zegabELXuAD6p0aFz4IDZxjW9OBRVlVCeHMljG9/D1qYSiCP0CcAXvkGBh KHKw== X-Gm-Message-State: APjAAAXtZUE6yfjBzZSbJcKVrFdTdHzz9TQXRK0+LdjEvA5t+k7Ty4Ub ues8jZbxwt72PDPS+EzW++c358Hbe4oo782VFpxG9kOU X-Google-Smtp-Source: APXvYqxHJ2zbkZYZ/hULXs1K/kqkmworbqasm5jD9qDjwXl08N8YOQBPv/YFb9jliTzmVU7sW3/j4wekIHJbk39JaNk= X-Received: by 2002:a2e:9256:: with SMTP id v22mr10693994ljg.45.1580616339096; Sat, 01 Feb 2020 20:05:39 -0800 (PST) MIME-Version: 1.0 References: <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie> <9A5EE7C8-360D-49C0-92F8-274FE1A94249@apple.com> <20200202013016.GH49778@straasha.imrryr.org> <20200202035848.GJ49778@straasha.imrryr.org> In-Reply-To: <20200202035848.GJ49778@straasha.imrryr.org> From: Watson Ladd Date: Sat, 1 Feb 2020 20:05:28 -0800 Message-ID: To: TLS List Content-Type: multipart/alternative; boundary="0000000000006b0a01059d8febf7" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 04:05:43 -0000 --0000000000006b0a01059d8febf7 Content-Type: text/plain; charset="UTF-8" On Sat, Feb 1, 2020 at 7:59 PM Viktor Dukhovni wrote: > On Sat, Feb 01, 2020 at 07:04:53PM -0800, Watson Ladd wrote: > > > > The benefit of the new value of "0" is *unambiguous* signalling that > the > > > client would like to reuse the ticket if possible, and the new "255" > > > then carries the "We don't need no stinking tickets" signal. > > > > > > > I'd be happier with a magic 0, or a N = valid tickets at the end > > including the one used, then swapping 2 values and making one magic. > > (For those of you who aren't bridge fiends: > > https://en.wikipedia.org/wiki/Brown_sticker) > > Sorry, no idea what that above means. And is it simpler than the > proposal under discussion (which got some fine-tuning in early > feedback)? > So one proposal in above is we treat 0 tickets as "ensure I have a valid ticket, either this one or a new one" and all other numbers are straight asks for that many tickets. The other proposal is N means "ensure I have N valid tickets, including the one I used on this connection". I find both cleaner then the 0 and 255 swap. > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. --0000000000006b0a01059d8febf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Feb 1, 2020 at 7:59 PM Viktor= Dukhovni <ietf-dane@dukhovni.= org> wrote:
On Sat, Feb 01, 2020 at 07:04:53PM -0800, Watson Ladd wrote:

> > The benefit of the new value of "0" is *unambiguous* si= gnalling that the
> > client would like to reuse the ticket if possible, and the new &q= uot;255"
> > then carries the "We don't need no stinking tickets"= ; signal.
> >
>
> I'd be happier with a magic 0, or a N =3D valid tickets at the end=
> including the one used, then swapping 2 values and making one magic. > (For those of you who aren't bridge fiends:
> https://en.wikipedia.org/wiki/Brown_sticker)

Sorry, no idea what that above means.=C2=A0 And is it simpler than the
proposal under discussion (which got some fine-tuning in early
feedback)?

So one proposal in above is = we treat 0 tickets as "ensure I have a valid ticket, either this one o= r a new one" and all other numbers are straight asks for that many tic= kets.

The other proposal is N means "ensure I= have N valid tickets, including the one I used on this connection". I= find both cleaner then the 0 and 255 swap.



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

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


--
"Man is born free, but everywhere he is in chains"= ;.
--Rousseau.
--0000000000006b0a01059d8febf7-- From nobody Sat Feb 1 23:32:39 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3120E120827 for ; Sat, 1 Feb 2020 23:32:35 -0800 (PST) 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=mnot.net header.b=wjG5cUus; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Kybpi/xY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac-Uh8nE1yDu for ; Sat, 1 Feb 2020 23:32:33 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CA2120045 for ; Sat, 1 Feb 2020 23:32:33 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2E5963E9 for ; Sun, 2 Feb 2020 02:32:33 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 02 Feb 2020 02:32:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=MMxV2EnQ/7W7DMGPyedCvWbsIk7ANJPTjpvIYwSDvJQ=; b=wjG5cUus gblwKrI8ov0tSAnHLuJ2smJjwn+p9LcUHwcawiSSRlLiO2nhrRdPjEOkU87KpeDY W+EaM9SvqFTST8ta2SJgiMINIL0jNL0bgKfnskzm8zOCicBOfT90x+4vO3COUARl 0W453ojL3WdxeJTQDtXJXB0lbsz8GQ4NBOtrGSUt8MfjbNyENnPXq3hInatwv2N2 MkdfiwDcjHN4RMe375/PRXvlLDnWxE/jaC9s9qXyp6ICZSv5bXLepleunfVzTQ7m xLvfUm7m+C0lN/MlOunjAMCly9yZZrkRxF1EWnh5PiED02aG1o3swZVrBZJs9cBI 5edOt+WKrg44+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=MMxV2EnQ/7W7DMGPyedCvWbsIk7AN JPTjpvIYwSDvJQ=; b=Kybpi/xYP8+JE0ZV/vZO5c43E/L8JQBmWKw8DpyPPNUBq j2AslYU0q0iVl/mhV91LBhl50pM0c8gFEaDI9RAvIzxgsBlWnAaOOf6x1NOtyc7K OC2Ai0BKDdJ9ttaYyYX5nc3nSgah6TI8vrgZvPLv1JDugGHs7souiP6U3VUSXJfA ZO5XvqrFiz8nbMh1DrT3+AUCC/sSnN4wkoqv5SaGwGOHxwszhiSgs0Vzo2/qLdgG Qyy0wSpKta8wzmbrBSPvXy+0w3r/Vl2Rf5AQBQ9lF8GmyZT2WYGbR+l+TQFnCNn7 GB94gH+DPrcMj1S1NiBXYmfmU7eW71dfsmygTk3YQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgeeggdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeegtddruddujedrvdefjedrvdegudenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.117.237.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 98EC4328005E for ; Sun, 2 Feb 2020 02:32:32 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6929906838206003398==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200202073232.98EC4328005E@mailuser.nyi.internal> Date: Sun, 2 Feb 2020 02:32:32 -0500 (EST) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 07:32:37 -0000 --===============6929906838206003398== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-ticketrequest (+0/-3/=F0=9F=92=AC3) 3 issues received 3 new comments: - #14 Allow server to echo the number of tickets that it expects to send = (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/14=20 - #13 ticket_request in HRR (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/13=20 - #9 Add advisory text on prioritization of tickets vs. application data = (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/9=20 3 issues closed: - ticket_request in HRR https://github.com/tlswg/draft-ietf-tls-ticketreq= uest/issues/13=20 - Allow server to echo the number of tickets that it expects to send http= s://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/14=20 - Add advisory text on prioritization of tickets vs. application data htt= ps://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/9=20 * tlswg/tls-flags (+0/-0/=F0=9F=92=AC6) 1 issues received 6 new comments: - #1 63 or 247? (6 by martinthomson, nmav, yoavnir) https://github.com/tlswg/tls-flags/issues/1=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #196 Tunnel version (1 by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/pull/196=20 * tlswg/draft-ietf-tls-ticketrequest (+1/-2/=F0=9F=92=AC6) 1 pull requests submitted: - Add performance considerations (by tfpauly) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/16=20 3 pull requests received 6 new comments: - #16 Add performance considerations (1 by DavidSchinazi) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/16=20 - #15 Prohibit SH and HRR extensions, allow EE server hints (2 by DavidSc= hinazi, chris-wood) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/15=20 - #12 adding security consideration on reflection attack (3 by chris-wood= , mglt) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/12=20 2 pull requests merged: - Add performance considerations https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/16=20 - Prohibit SH and HRR extensions, allow EE server hints https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/15=20 * tlswg/tls-flags (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Make section 2 and IANA cons agree on flag count (by yoavnir) https://github.com/tlswg/tls-flags/pull/2=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============6929906838206003398== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday February 02, 2020

Issues

tlswg/draft-ietf-tls-ticketrequest (+0/-3/=F0=9F=92=AC3)

3 issues received 3 new comments:

3 issues closed:

tlswg/tls-flags (+0/-0/=F0=9F=92=AC6)

1 issues received 6 new comments:

Pull requests

tlswg/draft-ietf-tls-esni (+0/-0/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

tlswg/draft-ietf-tls-ticketrequest (+1/-2/=F0=9F=92=AC6)

1 pull requests submitted:

3 pull requests received 6 new comments:

2 pull requests merged:

tlswg/tls-flags (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

Repositories tracked by this digest:

--===============6929906838206003398==-- From nobody Sun Feb 2 03:52:08 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EDB1200C1 for ; Sun, 2 Feb 2020 03:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 mBUm-n1tVDnb for ; Sun, 2 Feb 2020 03:52:05 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2928120045 for ; Sun, 2 Feb 2020 03:52:03 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 2FD973883E; Sun, 2 Feb 2020 06:52:03 -0500 (EST) Date: Sun, 2 Feb 2020 06:52:03 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20200202115203.GK49778@straasha.imrryr.org> Reply-To: tls@ietf.org References: <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie> <9A5EE7C8-360D-49C0-92F8-274FE1A94249@apple.com> <20200202013016.GH49778@straasha.imrryr.org> <20200202035848.GJ49778@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 11:52:06 -0000 On Sat, Feb 01, 2020 at 08:05:28PM -0800, Watson Ladd wrote: > > Sorry, no idea what that above means. And is it simpler than the > > proposal under discussion (which got some fine-tuning in early > > feedback)? > > So one proposal in above is we treat 0 tickets as "ensure I have a valid > ticket, either this one or a new one" and all other numbers are straight > asks for that many tickets. This is indeed simpler, but it removes the ability to ask for zero tickets, which I think was one of the intended use-cases (that's what the 255 is for). > The other proposal is N means "ensure I have N valid tickets, including the > one I used on this connection". I find both cleaner then the 0 and 255 swap. The problem here is now reuse is implicit, and the only way for a client to ensure that it gets a fresh ticket, is by asking for 2. So I now see where you're coming from, and it was worth a try at simplification, but I don't think it works out. The reasons for two sentinels is that in fact are three separate cases. 1. Client wants no tickets 2. Client wants to try to reuse an existing ticket 3. Client wants n > 0 fresh tickets. I don't see how to handle 1 and 2 cleanly without two sentinels. -- Viktor. From nobody Sun Feb 2 06:43:12 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1987120100 for ; Sun, 2 Feb 2020 06:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=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=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHeAhnoara79 for ; Sun, 2 Feb 2020 06:43:07 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC0312006E for ; Sun, 2 Feb 2020 06:43:07 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 012EflOZ063451 for ; Sun, 2 Feb 2020 06:43:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : in-reply-to : to; s=20180706; bh=aOUVjgfF5huFOaqOpwsy3zQqGa82An6KXfcGKJ6LMVk=; b=RmjpCiEbv9OUMGADxRuPcL7V0fQPxRUc5JkeAu6WxfrXnEXywAeVbz0aA5z/8qk3Xvn/ BRAWIwN8HW5THeGSmM2D3ADDJd3HMXpS73724Wmqo2F80jIoe4L6D3UabL8n0FdgOW0u WsZunKyX2iUFi5iq8VOdYbwZcbEq9PJ9xJtz3kONbGaYTNljDvUisZqXDiZIMoUtEI7d hJdb/1jaQUD3CHrDeu2rKuaTxMl7UG7WxtXm/aEoRUompfmndcQVyyPgMY0p+4E3mWgR jCfA/BTNzaMAS2cIDv5LJdcAiVaoqHvqxyWUx0C/X6NYmWrwM1WrlqbNxJcsQWN4kJm+ AQ== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2xw970112f-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 02 Feb 2020 06:43:06 -0800 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q52002N7WVLYE70@rn-mailsvcp-mta-lapp03.rno.apple.com> for tls@ietf.org; Sun, 02 Feb 2020 06:42:57 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5200900U3AN900@nwk-mmpp-sz12.apple.com> for tls@ietf.org; Sun, 02 Feb 2020 06:42:57 -0800 (PST) X-Va-A: X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-Va-CD: 0 X-Va-ID: 78f997bc-b601-4b77-b07b-3b3da0e2445a X-V-A: X-V-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-V-CD: 0 X-V-ID: 0311abb0-e01a-4dd7-90d3-7d9bb157c4af X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-02_04:,, signatures=0 Received: from [17.234.105.142] (unknown [17.234.105.142]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q5200MB5WVLJ160@nwk-mmpp-sz12.apple.com> for tls@ietf.org; Sun, 02 Feb 2020 06:42:57 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable From: Tommy Pauly MIME-version: 1.0 (1.0) Date: Sun, 02 Feb 2020 06:42:56 -0800 Message-id: <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> References: <20200202115203.GK49778@straasha.imrryr.org> In-reply-to: <20200202115203.GK49778@straasha.imrryr.org> To: tls@ietf.org X-Mailer: iPhone Mail (18A214) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-02_04:, , signatures=0 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 14:43:09 -0000 > On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni wrote= : >=20 > =EF=BB=BFOn Sat, Feb 01, 2020 at 08:05:28PM -0800, Watson Ladd wrote: >=20 >>> Sorry, no idea what that above means. And is it simpler than the >>> proposal under discussion (which got some fine-tuning in early >>> feedback)? >>=20 >> So one proposal in above is we treat 0 tickets as "ensure I have a valid >> ticket, either this one or a new one" and all other numbers are straight >> asks for that many tickets. >=20 > This is indeed simpler, but it removes the ability to ask for zero > tickets, which I think was one of the intended use-cases (that's what > the 255 is for). >=20 >> The other proposal is N means "ensure I have N valid tickets, including t= he >> one I used on this connection". I find both cleaner then the 0 and 255 sw= ap. >=20 > The problem here is now reuse is implicit, and the only way for a client > to ensure that it gets a fresh ticket, is by asking for 2. >=20 > So I now see where you're coming from, and it was worth a try at > simplification, but I don't think it works out. The reasons for > two sentinels is that in fact are three separate cases. >=20 > 1. Client wants no tickets > 2. Client wants to try to reuse an existing ticket > 3. Client wants n > 0 fresh tickets. >=20 > I don't see how to handle 1 and 2 cleanly without two sentinels. I think Watson=E2=80=99s point (which I fully agree with) is that sending th= e value =E2=80=9C0=E2=80=9D already means =E2=80=9Cthe client wants no ticke= ts=E2=80=9D. The document already explains this usage. Thus, you don=E2=80=99= t need a sentinel value to express that case=E2=80=94is what the value of N a= lready intuitively means.=20 If you did need a sentinel to indicate that you wanted to try to reuse a tic= ket (which you can always try if you want), it would make more sense to just= make that sentinel be 255, etc, rather than creating two sentinels. The ticket reuse signaling that is proposed really is orthogonal to the *cou= nt* of tickets. When requesting a number of tickets, there is a signal in one direction from= the client about how many tickets it wants; and the server signals back by i= ssuing some number of tickets. There isn=E2=80=99t much ambiguity. On the other hand, the proposed sentinel value indicates =E2=80=9CI=E2=80=99= d like to reuse tickets if I can=E2=80=9D, but without any additional signal= ing from the server about the support of ticket reuse, a server response con= taining no tickets is ambiguous=E2=80=94maybe it means ticket reuse is fine;= maybe it means the server isn=E2=80=99t giving out any more tickets and won= =E2=80=99t allow resumption. It is much clearer if there is a bidirectional s= ignal about negotiating ticket reuse. Beyond that, it seems odd to mark a Boolean sent by the client to ask for ti= cket reuse in an integer that counts numbers of tickets. It=E2=80=99s not th= at one value (255) is precious, but it means that these orthogonal concepts c= an no longer be communicated separately. Let=E2=80=99s imagine a client that= had received 4 tickets the first time around, on request, and then wanted t= o either reuse some of them or ask for 2 more. Keeping the ticket request ju= st a number and having a separate message for the reuse Boolean allows that.= Allocating a sentinel means that a request for reuse to a server that doesn= =E2=80=99t support reuse now loses the ability to request a particular numbe= r of tickets. Thanks, Tommy >=20 > --=20 > Viktor. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Feb 2 09:09:02 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D92120241 for ; Sun, 2 Feb 2020 09:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=0.001, SPF_NONE=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=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 JCWHguVfMlSu for ; Sun, 2 Feb 2020 09:08:56 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 B614912004D for ; Sun, 2 Feb 2020 09:08:55 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id h23so12138755ljc.8 for ; Sun, 02 Feb 2020 09:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=F2qT7FeWZYf/b5iUR0Nr40cK7p1/rkgD7IWYMpAJZ3c=; b=TaNFk2XNMNRuMbkt+be++IsZc3+C5h3v+UwRfpRzH0O4Iuqplv4lQDPp6C00oZ+W7x oaHq4PmNUHpSn5MSds57TgkRLW1WIOFQhaO6TYayamge7lSrswOuoQck2zvItLzIEwpc 7fUFJg5cY4A4T/7V8IV1ko1+GEj9UA4dAW7waXOcwTzuyN6z1Tj070T21rGuxFQH0w0c cxP0+Iqo17VJg+6diX+lnJcDoYUyOaILd+KerQQTpsk18UhbeJcBLx4Q/BBOZLrSsNpA /uy8jk3CqClx/msNtb3sDIdFpcDC8/13C8Wiz5tt47x8WiQXbx694kaZ7dLgH6bwAYuG +t2A== 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=F2qT7FeWZYf/b5iUR0Nr40cK7p1/rkgD7IWYMpAJZ3c=; b=HtD4Z1g/qjCJCrRd3CHq3VgRKUlzzBE1kK+GRDK7vPSneIEUz8QLsZ1bryG1bFFhj9 UP0M525LhKYn7y0np3pQtTmYy8S6emGS6NP/4VT3219mrugSlgBfKi87Qn4esBSn0Dc6 iY+XQVKreh0ZwkBlJ+/IiiagZ1copdd+DMSLqc/rtAXdWpsLqM63cSMh+QLIUO1dBmmb tTK7+kyhD17hnS42Mz3evR63vHtBnAHxDzVS48HQuJtw6MwE5nqLFmh5KnmhwD3qCTmf v5KFdcoTfNJLYN2BdToP+4gop/1QkMfm1HBJwU6MaD9Y7zRAuA0dlyfopuz6sq/GAfZJ Lpcg== X-Gm-Message-State: APjAAAU2TdEXTtCrphgk/CLLql3SsI7WDciPisQfbpTINcpsAXoYQBN4 wd00AN3FZWJJzLiT6IZXsg5rqSUCy7DyVdQ82ZP34tOMCm8= X-Google-Smtp-Source: APXvYqyL3uhiA3P+ak4O9B7N0TYU4Fkx9UNv48MxRR9YOAT2Br6NS+/5IKk4tk1Z+qhH3gj70fcnIJ0z1N80kXyeC/Y= X-Received: by 2002:a2e:b5a5:: with SMTP id f5mr11252852ljn.162.1580663333618; Sun, 02 Feb 2020 09:08:53 -0800 (PST) MIME-Version: 1.0 References: <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> In-Reply-To: <20200121224610.GR73491@straasha.imrryr.org> From: Eric Rescorla Date: Sun, 2 Feb 2020 09:08:17 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="00000000000082ac97059d9adc50" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 17:09:00 -0000 --00000000000082ac97059d9adc50 Content-Type: text/plain; charset="UTF-8" > On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote: > > > I would make several points here: > > > > 1. RFC 8446 explicitly discourages ticket reuse > > (https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we > > should not be designing an extension to enable reuse. While it's > > potentially true that some applications do not benefit from > > non-reuse, creating a set of mechanisms around reuse risks those > > mechanisms being used in settings where reuse would be > > bad. Moreover. just because at present sending MTAs have weak > > privacy properties does not mean that we should bake in this > > situation permanently. > > Indeed I agree that ticket reuse is often undesirable, and expect that > it will be avoided in many cases. So I am somewhat sympathetic to the > above as a starting point for the analysis. > > That said, I don't see that making reuse easier to negotiate is likely > to create significant opportunities for misuse. I'm actually making several points here: 1. TLS 1.3 takes the position that reuse is bad and that position is for good reasons, so we shouldn't undercut it in a new extension. 2. Creating a mechanism which encourages reuse increases the risk of reuse. You are responding to number (2), and I'll respond to that below, but I think the controlling point is actually (1). We shouldn't encourage reuse, period. > - Both the client *and* the server would need to opt-in to reuse. > > * Even if the client asks for reuse, the server can invalidate > the old ticket (something it would need to be able to do > already to ensure non-reuse) and send a fresh one anyway. > > The client would have to replace the old with the new, since > it has to assume that the old is now likely invalid. > > * Even if the server is willing to reuse, if the client asks > for a new ticket, the server has to assume the client has > a single-use cache, and should vend a new ticket. > > so it takes bilateral coordination to arrive at reuse, and > so accidental reuse in applications where it is inappropriate > requires errors on both ends. The issue is less accidental reuse than joint misconfiguration (e.g., bad defaults or bad advice in some Stack Overflow document). > > 2. The additional cost of multiple tickets seems extraordinarily > > small, so I am not at all persuaded that there is enough value in > > this use case to justify adding new protocol machinery, even > > ignoring point (1) above. > > Postfix has a shared cache (indexed by destination domain+mx host) for > multiple independent processes racing to use the cache to make remote > SMTP connections. > > Frequent writes to that cache create measurable overhead and still don't > prevent reuse. I'm sorry to say that I'm not that sympathetic to this position. I appreciate that it's inconvenient for Postfix to have frequent writes to the ticket cache, but what you propose to do is hoist this implementation idiosyncracy into the specification, and I don't think that that's a good tradeoff, both for complexity and because the > Transmission of unnecessary tickets is also wasteful of > network and other server resources. Well, my position here is that these tickets aren't unnecessary, because you should be using them, rather than violating the SHOULD in the 8446. > Erasing tickets on first use would be unwise, most existing servers will > not presently return a fresh ticket on resumption. This seems like a defect in those servers. However it can be handled by not erasing tickets until a new ticket is provided. > > > 3. If there *is* such value, then you can register your own extension > > which allows you to say the orthogonal thing, namely "don't send me > > any tickets at all if you are resuming". This would be more > > flexible in that you could then say "I would like 10 tickets, but > > only if you don't resume". Note that > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ would > > allow you to do this efficiently. > > This is an interesting idea, but how would the two extensions interact? I would imagine the logic would be: If !reuse || !present(reuse extension) { send min(max-local-tickets, tickets-requested-extension-present ? tickets-requested-extension-value : 1) } > And wouldn't that interaction add more complexity? Perhaps. At least in NSS, I imagine it would be pretty comparable, assuming we opted to implement the non-reuse one at all. > By hypothesis > clients that are willing to reuse tickets don't really need more than > one at a time. Is there a clear use case for multiple concurrent > reusable tickets. Yes, I see your point here. I don't have a clear case for this, but I'm also not sure that there isn't one: concurrent usage and serial usage are not necessarily the same. > > Thus, I would prefer to advance this document as-is. > > Thanks for the substantive response. Much appreciated. I hope you're > willing to address the above reaction, I am trying to find common > ground that addresses your concerns and mine. And thank you for your substantive response. I am not sure if we will be able to find common ground however. -Ekr --00000000000082ac97059d9adc50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescor= la wrote:
>
> > I would make several points here:
> &= gt;
> > 1. RFC 8446 explicitly discourages ticket reuse
> &= gt; =C2=A0 =C2=A0(https://tools.ietf.org/rfcmarkup?doc=3D8446#appendix-C.4). = so we
> > =C2=A0 =C2=A0should not be designing an extension to ena= ble reuse. While it's
> > =C2=A0 =C2=A0potentially true that s= ome applications do not benefit from
> > =C2=A0 =C2=A0non-reuse, c= reating a set of mechanisms around reuse risks those
> > =C2=A0 = =C2=A0mechanisms being used in settings where reuse would be
> > = =C2=A0 =C2=A0bad. Moreover. just because at present sending MTAs have weak<= br>> > =C2=A0 =C2=A0privacy properties does not mean that we should b= ake in this
> > =C2=A0 =C2=A0situation permanently.
>
&g= t; Indeed I agree that ticket reuse is often undesirable, and expect that> it will be avoided in many cases.=C2=A0 So I am somewhat sympathetic= to the
> above as a starting point for the analysis.
>
>= ; That said, I don't see that making reuse easier to negotiate is likel= y
> to create significant opportunities for misuse.

I'm ac= tually making several points here:

1. TLS 1.3 takes the position tha= t reuse is bad and that position
=C2=A0 =C2=A0is for good reasons, so we= shouldn't undercut it in a new
=C2=A0 =C2=A0extension.

2. Cr= eating a mechanism which encourages reuse increases the risk
=C2=A0 =C2= =A0of reuse.

You are responding to number (2), and I'll respond = to that below,
but I think the controlling point is actually (1). We sho= uldn't
encourage reuse, period.


> =C2=A0 =C2=A0 - Both= the client *and* the server would need to opt-in to reuse.
>
>= ; =C2=A0 =C2=A0 =C2=A0 * Even if the client asks for reuse, the server can = invalidate
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the old ticket (something it= would need to be able to do
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 already to= ensure non-reuse) and send a fresh one anyway.
>
> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 The client would have to replace the old with the new, si= nce
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 it has to assume that the old is no= w likely invalid.
>
> =C2=A0 =C2=A0 =C2=A0 * Even if the serve= r is willing to reuse, if the client asks
> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 for a new ticket, the server has to assume the client has
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 a single-use cache, and should vend a new ticket.<= br>>
> =C2=A0 =C2=A0 =C2=A0 so it takes bilateral coordination to= arrive at reuse, and
> =C2=A0 =C2=A0 =C2=A0 so accidental reuse in a= pplications where it is inappropriate
> =C2=A0 =C2=A0 =C2=A0 requires= errors on both ends.

The issue is less accidental reuse than joint = misconfiguration (e.g.,
bad defaults or bad advice in some Stack Overflo= w document).



> > 2. The additional cost of multiple ti= ckets seems extraordinarily
> > =C2=A0 =C2=A0small, so I am not at= all persuaded that there is enough value in
> > =C2=A0 =C2=A0this= use case to justify adding new protocol machinery, even
> > =C2= =A0 =C2=A0ignoring point (1) above.
>
> Postfix has a shared c= ache (indexed by destination domain+mx host) for
> multiple independe= nt processes racing to use the cache to make remote
> SMTP connection= s.
>
> Frequent writes to that cache create measurable overhead= and still don't
> prevent reuse.

I'm sorry to say tha= t I'm not that sympathetic to this position. I
appreciate that it= 9;s inconvenient for Postfix to have frequent writes
to the ticket cache= , but what you propose to do is hoist this
implementation idiosyncracy i= nto the specification, and I don't think
that that's a good trad= eoff, both for complexity and because the


> Transmission of u= nnecessary tickets is also wasteful of
> network and other server res= ources.

Well, my position here is that these tickets aren't unne= cessary,
because you should be using them, rather than violating the
= SHOULD in the 8446.


> Erasing tickets on first use would be u= nwise, most existing servers will
> not presently return a fresh tick= et on resumption.

This seems like a defect in those servers. However= it can be handled
by not erasing tickets until a new ticket is provided= .


>
> > 3. If there *is* such value, then you can r= egister your own extension
> > =C2=A0 =C2=A0which allows you to sa= y the orthogonal thing, namely "don't send me
> > =C2=A0 = =C2=A0any tickets at all if you are resuming". This would be more
&= gt; > =C2=A0 =C2=A0flexible in that you could then say "I would lik= e 10 tickets, but
> > =C2=A0 =C2=A0only if you don't resume&qu= ot;. Note that
> > =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-= ietf-tls-tlsflags/ would
> > =C2=A0 =C2=A0allow you to do this= efficiently.
>
> This is an interesting idea, but how would t= he two extensions interact?

I would imagine the logic would be:
<= br>If !reuse || !present(reuse extension) {
=C2=A0 send min(max-local-ti= ckets,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tickets-requested-extens= ion-present ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tickets-requested= -extension-value :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01)
}
<= br>> And wouldn't that interaction add more complexity?

Perha= ps. At least in NSS, I imagine it would be pretty comparable, assuming
w= e opted to implement the non-reuse one at all.


> By hypothesi= s
> clients that are willing to reuse tickets don't really need m= ore than
> one at a time. Is there a clear use case for multiple conc= urrent
> reusable tickets.

Yes, I see your point here. I don&#= 39;t have a clear case for this, but
I'm also not sure that there is= n't one: concurrent usage and serial
usage are not necessarily the s= ame.


> > Thus, I would prefer to advance this document as-= is.
>
> Thanks for the substantive response.=C2=A0 Much apprec= iated.=C2=A0 I hope you're
> willing to address the above reactio= n, I am trying to find common
> ground that addresses your concerns a= nd mine.

And thank you for your substantive response. I am not sure = if we will be able to
find common ground however.


-Ekr
--00000000000082ac97059d9adc50-- From nobody Sun Feb 2 09:10:32 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595A41201EF for ; Sun, 2 Feb 2020 09:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=0.001, SPF_NONE=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=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 BGImlR2H192c for ; Sun, 2 Feb 2020 09:10:26 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AD212004D for ; Sun, 2 Feb 2020 09:10:25 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id z18so8085743lfe.2 for ; Sun, 02 Feb 2020 09:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ei1NKjl9g4bJ4uZAGdcmeL7SQAXepKbUEGE2RUvvLLY=; b=q++hFHjYaG4C9uFm9hobvhe6II7cOuJISgtljIXRiUTeevDXDE9nuwSOx/I1C8qOFe jLMAWph6CjXpEBsl09eNCIMVa6AaAmJMoRHJn9WS7Aj6mSoiOSr+8ZPegez6tTh7NTuO jEXhWa8kUvTRJbPR7zNQiftNfDq+n2atm67LsUJDPbjWKAHuz/GNgseH5G8DE9TL6cPv IlDjMoVQExDY1b9H1EB05qXiFObqR34ehWMcrw1qTusB9lwX3TXj4AJqfiEp+q8RhGIP T9kPTi2ms240uaiBrAIo50zk+bLfNhjUmXqkBZiT5m15jM2mXZm8l+nCQXhn06Hnbrby ED/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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ei1NKjl9g4bJ4uZAGdcmeL7SQAXepKbUEGE2RUvvLLY=; b=d0lMxcI9ey16nLRBIadF+ZFeldqYy7j4WR0weeIofqNv06XIuhg+q6hTprJgpB6QTu PnqrVhD9mz3ujz3IEejFjCi/NrolCz4lVBfyRvBjusZaMJtCLucpihz1FcqltJohVOrF VAhRE2fFCziD9LikdcwYnMGnUMgi5ukRT0SHZwqYtbBCfJu6ipTzdUwAtSH+Wm1GEIsg 11OCu4vGjs3FCBp8dnHn2D0fWKY1TfNH7whmX3ODoQ7Ww8XzBidfQ5EKkLiRGNz1MaLa 1cEV/WFvsasobRs+FQxJrP8yu8m3iOwsnJyMOt5MwyqvJu9/X5vh0a0MO3EuH3dnqnXm ttHg== X-Gm-Message-State: APjAAAUmESDu3iWxoGfNhOUDQncDz5wELay3ylUB/MWjjTPnwR2h5M/+ oUhn6ugcVZNFBODGZ0XRm3dlcF6LBkg5Gi4IiusI0ovN X-Google-Smtp-Source: APXvYqxWvwlPN0AhjXYvTHf5EKieUy1RWHqUgrUTAh21VsxgFKJtJIX+OVVjdbaz/2LtgKeyBbnm+TdQOq0RA+MV8ao= X-Received: by 2002:a19:8b89:: with SMTP id n131mr10015570lfd.14.1580663423728; Sun, 02 Feb 2020 09:10:23 -0800 (PST) MIME-Version: 1.0 References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> In-Reply-To: <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> From: Eric Rescorla Date: Sun, 2 Feb 2020 09:09:47 -0800 Message-ID: To: Tommy Pauly Cc: "" Content-Type: multipart/alternative; boundary="000000000000e18f6a059d9ae151" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 17:10:30 -0000 --000000000000e18f6a059d9ae151 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Feb 2, 2020 at 6:43 AM Tommy Pauly wrote: > > On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni > wrote: > > On the other hand, the proposed sentinel value indicates =E2=80=9CI=E2=80= =99d like to > reuse tickets if I can=E2=80=9D, but without any additional signaling fro= m the > server about the support of ticket reuse, a server response containing no > tickets is ambiguous=E2=80=94maybe it means ticket reuse is fine; maybe i= t means > the server isn=E2=80=99t giving out any more tickets and won=E2=80=99t al= low resumption. It > is much clearer if there is a bidirectional signal about negotiating tick= et > reuse. > > It's worth noting that because tickets are delivered serially and without a leading count it's actually somewhat ambiguous no matter what. The server might just decide to interleave data with tickets. I do agree it's somewhat more ambiguous in the reuse case. -Ekr --000000000000e18f6a059d9ae151 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 2, 2020 at 6:43 AM Tommy = Pauly <tpauly=3D40apple.co= m@dmarc.ietf.org> wrote:
> On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:=

On the other hand, the proposed sentinel value indicates =E2=80=9CI=E2=80= =99d like to reuse tickets if I can=E2=80=9D, but without any additional si= gnaling from the server about the support of ticket reuse, a server respons= e containing no tickets is ambiguous=E2=80=94maybe it means ticket reuse is= fine; maybe it means the server isn=E2=80=99t giving out any more tickets = and won=E2=80=99t allow resumption. It is much clearer if there is a bidire= ctional signal about negotiating ticket reuse.

It's worth noting that because tickets are delivered serial= ly and without a leading count it's actually somewhat ambiguous no matt= er what. The server might just decide to interleave data with tickets. I do= agree it's somewhat more ambiguous in the reuse case.

-Ekr

--000000000000e18f6a059d9ae151-- From nobody Sun Feb 2 09:53:15 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A09120127 for ; Sun, 2 Feb 2020 09:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 9y7h4GbHV1zW for ; Sun, 2 Feb 2020 09:53:11 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB4A120033 for ; Sun, 2 Feb 2020 09:53:10 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 5407338BFD; Sun, 2 Feb 2020 12:53:09 -0500 (EST) Date: Sun, 2 Feb 2020 12:53:09 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20200202175309.GL49778@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 17:53:13 -0000 On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote: > If you did need a sentinel to indicate that you wanted to try to reuse > a ticket (which you can always try if you want), it would make more > sense to just make that sentinel be 255, etc, rather than creating two > sentinels. Sure, if you want to swap my 0 <-> 255, that'd be fine by me, then 0--254 are "natural", and 255 means "only as needed". If that's what it takes to reach a compromise, I'm on board. > The ticket reuse signaling that is proposed really is orthogonal to the *count* of tickets. Except that it really isn't. Reuse means: 0 tickets or 1 ticket when the one presented is or soon will become unusable. There's no way to decouple that from the ticket count. The idea is not to allow the client to gratuitously inform the server that it is engaged in reuse while not attempting to reuse by requesting fresh tickets anyway. The idea is to attempt a reuse of the presented ticket, by havving the server not return anything back if it is still good. > On the other hand, the proposed sentinel value indicates “I’d like to > reuse tickets if I can”, but without any additional signaling from the > server about the support of ticket reuse, a server response containing > no tickets is ambiguous—maybe it means ticket reuse is fine; maybe it > means the server isn’t giving out any more tickets and won’t allow > resumption. The ambiguity is harmless. If the server no longer accepts tickets the next reuse will elicit a full handshake, resulting a new ticketless session. The client's existing ticket will get flushed. > It is much clearer if there is a bidirectional signal about > negotiating ticket reuse. There an opportunity for a signal in the reverse direction, but not the one above. Rather, a useful reverse signal could be: I never accept a previously used ticket, do not attempt reuse. I would support that signal. > Beyond that, it seems odd to mark a Boolean sent by the client to ask > for ticket reuse in an integer that counts numbers of tickets. It’s > not that one value (255) is precious, but it means that these > orthogonal concepts can no longer be communicated separately. My point (made above) is that the client signals are NOT orthogonal. Reuse implies 0 or 1 at the server's discretion. > Let’s imagine a client that had received 4 tickets the first time > around, on request, and then wanted to either reuse some of them or > ask for 2 more. This scenario doesn't quite work. It can't reuse "some", it can only request to reuse (again after the current resumption) the one it is presenting. If that one is not reusable, the server issues a replacement, either way the client still has 4 usable tickets. > Keeping the ticket request just a number and having a separate message > for the reuse Boolean allows that. Allocating a sentinel means that a > request for reuse to a server that doesn’t support reuse now loses the > ability to request a particular number of tickets. Yes, that's because reuse does not need multiple tickets. Indeed long ago upthread we discussed the fact that multiple tickets should generally only happen on full handshakes (or at least infrequently, rather than on each resumption). Successful resumption should typically yield at most 1 ticket, otherwise the number of tickets indefinitely outpaces the number of connections. The text added to describe that issue is fairly minimal, it should ideally be expanded, but I am not going to make this a point of contention. But if indeed it makes sense to have the client signal how fresh tickets it wants to get should a full handshake rather resumption takes place, because: - While it prefers reuse, the server may not support it - The client not only supports reuse, but also supports a multi-slot ticket cache, and reuses tickets round-robin. then indeed one may envision a signal that indicates the number of tickets to send on full handshake (what this extension really should mean to servers), but otherwise perhaps reuse on resumption, or else a single unconditional ticket. For that to happen, the reuse signal would be a separate bit, but splitting the signal across two extensions makes for rather complicated server and client code to get this right. Therefore, if that's the way forward, then I'll take the high bit as a resumption indication, with the ticket count in the low seven bits. If you tweak the shape of the signal to work for you, I'll not be fussy. Let's just get something that solves the whole problem. -- Viktor. From nobody Sun Feb 2 10:58:39 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F250A1200B1 for ; Sun, 2 Feb 2020 10:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=0.001, SPF_NONE=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=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 iY47BLjzR_7u for ; Sun, 2 Feb 2020 10:58:35 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 EB7B1120115 for ; Sun, 2 Feb 2020 10:58:34 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id o15so6748784ljg.6 for ; Sun, 02 Feb 2020 10:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0dI1eFKFLUl5Q2uRZ/691/A+NwVSZZpUNDJSqd36hvg=; b=jjE6TZ4F6xG19wNcHbChOmj5/ZfQj7ZSAeNASCuWJoJEDKMEGxvMZ5T5032be6OnP2 34zDEX8rpX9WHal31QJLIf8TkiO2AVuFMdhLR/vJCKbcUHzIaenGXte+jQrsEL/CkIap uAV9CFuewkEtLvDFedoypqYl2gyQfeaER4JR+qo01PHR76+rJRJ8dh0l10ekdLwzGtMc pEIo+RJu+A8CAYrSCZkZihmDHIJcAK7wSq7frxpqsjA+hHIpcxt7Dljht66i8Kmffesi rWp3uA5ibedUNU+26/XUrhBsxhXRFjIySgHndgx079wwDw9O0IZ+2sGrPFCZSWNxT6ct GtbA== 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=0dI1eFKFLUl5Q2uRZ/691/A+NwVSZZpUNDJSqd36hvg=; b=PkfkE2NtkpsC1pbGtcjETfQ6poK5ppukHb0bHe5Q7qfGPc2yqV/AdIFjbo/GFv2Qm1 W7EQPUGCywZmQ/RBljM+IsoQ7THgonftJm3cEUrbhDPL1usjGuH5vRA6b0Ko2/Q++/YF MvKzLVscWaHmjJZwjYuw4IHyUDbMjUWdzQIJXiue2fBKThWcHj2QvjGyWAbRWydDLm4g HjkZIkQqYZrsRGGqZMTd1pW759V/zJJ+mYYIWn4MflSyUVeF/HEOe7BfcgLae3eZPZUC l7TM6S382XMPT0CypuCNOMnnqLNK9jIg5R9+JvSuoVB3fRabQIILVBDkRXcK9YZd6e6Y WdjA== X-Gm-Message-State: APjAAAXvAmI0n+3sp1thvAxKkwXJHkqey52aQP79s5S3Rrg6F7gaKG/o rJPBJhahbx+HqAmND10gyJbVoO/aUdtxXBltTOXiSOzs X-Google-Smtp-Source: APXvYqwT69iqCoVob7ywuec5N72gNuLh7zqffxh0UQzyYOV4HsV5vtdwTexRIIJNLuik/0Ln8b4BhWqxi+hv+7yDSDg= X-Received: by 2002:a2e:8797:: with SMTP id n23mr11043410lji.176.1580669912712; Sun, 02 Feb 2020 10:58:32 -0800 (PST) MIME-Version: 1.0 References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> <20200202175309.GL49778@straasha.imrryr.org> In-Reply-To: <20200202175309.GL49778@straasha.imrryr.org> From: Eric Rescorla Date: Sun, 2 Feb 2020 10:57:56 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000a79b57059d9c64e2" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 18:58:37 -0000 --000000000000a79b57059d9c64e2 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 2, 2020 at 9:53 AM Viktor Dukhovni wrote: > Yes, that's because reuse does not need multiple tickets. Indeed long > ago upthread we discussed the fact that multiple tickets should > generally only happen on full handshakes (or at least infrequently, > rather than on each resumption). Successful resumption should typically > yield at most 1 ticket, otherwise the number of tickets indefinitely > outpaces the number of connections. > "Generally" seems to be doing a fair bit of work here, as if you are doing happy eyeballs or some other parallel connection mechanism, then you in fact need N new tickets. -Ekr -Ekr --000000000000a79b57059d9c64e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 2, 2020 at 9:53 AM Viktor= Dukhovni <ietf-dane@dukhovni.= org> wrote:
Yes, that's because reuse does not need multiple tickets.=C2=A0 Inde= ed long
ago upthread we discussed the fact that multiple tickets should
generally only happen on full handshakes (or at least infrequently,
rather than on each resumption).=C2=A0 Successful resumption should typical= ly
yield at most 1 ticket, otherwise the number of tickets indefinitely
outpaces the number of connections.

&qu= ot;Generally" seems to be doing a fair bit of work here, as if you are= doing happy eyeballs or some other parallel connection mechanism, then you= in fact need N new tickets.

-Ekr

-Ekr

--000000000000a79b57059d9c64e2-- From nobody Sun Feb 2 11:05:02 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ADF120125 for ; Sun, 2 Feb 2020 11:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 SrCZysC6GBJ1 for ; Sun, 2 Feb 2020 11:04:58 -0800 (PST) Received: from crocodile.birch.relay.mailchannels.net (crocodile.birch.relay.mailchannels.net [23.83.209.45]) (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 6C8521200B1 for ; Sun, 2 Feb 2020 11:04:58 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B307121B0B; Sun, 2 Feb 2020 19:04:57 +0000 (UTC) Received: from pdx1-sub0-mail-a94.g.dreamhost.com (100-96-217-4.trex.outbound.svc.cluster.local [100.96.217.4]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 38C1321019; Sun, 2 Feb 2020 19:04:57 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a94.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sun, 02 Feb 2020 19:04:57 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Tangy-Squirrel: 6d66dae10c5545b6_1580670297468_1797400246 X-MC-Loop-Signature: 1580670297468:3827458789 X-MC-Ingress-Time: 1580670297468 Received: from pdx1-sub0-mail-a94.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTP id 0C9DFB0D5A; Sun, 2 Feb 2020 11:04:52 -0800 (PST) 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=A5Ef1C+DO9i/XN UR+V1kdb7L2iE=; b=BIC6IGp4kl1I6/hYlLDEbNGv57rfykGqRL9IHoWWvcwT5e /HtUAgQXkNF64FOxUcuYjr+NPsCJyhaAMMEu97UnKcZjJz1Ov5jKM16ukzljH9AN jgu/ypHsKE1FKK9pyKoTcArMZ8YPcxFdYfFAbHz2fxss890yHJa9TW6K0TCig= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTPSA id 3D5CBB0D61; Sun, 2 Feb 2020 11:04:51 -0800 (PST) Date: Sun, 2 Feb 2020 13:04:48 -0600 X-DH-BACKEND: pdx1-sub0-mail-a94 From: Nico Williams To: Eric Rescorla Cc: "" Message-ID: <20200202190447.GG18021@localhost> References: <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrgeehgdduudelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 19:05:00 -0000 On Sun, Feb 02, 2020 at 09:08:17AM -0800, Eric Rescorla wrote: > I'm sorry to say that I'm not that sympathetic to this position. I > appreciate that it's inconvenient for Postfix to have frequent writes > to the ticket cache, but what you propose to do is hoist this > implementation idiosyncracy into the specification, and I don't think > that that's a good tradeoff, both for complexity and because the We've done this a lot though, haven't we. For example, we've striven to avoid reconnects because SChannel can't really handle them. So I'm not that sympathetic to not being that sympathetic to specific implementation issues. Nico -- From nobody Sun Feb 2 11:05:33 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE56E120133 for ; Sun, 2 Feb 2020 11:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xcutuZjQnhg for ; Sun, 2 Feb 2020 11:05:30 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 553A212012D for ; Sun, 2 Feb 2020 11:05:30 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 012Iv9DG034763 for ; Sun, 2 Feb 2020 11:05:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=eyyqOyFQazGluhMYLZ6BDYmbsXaq3AJvnYFpaR89AQ8=; b=SG+GhdSYy9pw2d3MhkGcdco64lIpG+hn5E/VZvKb04IMSJfvR+G99L9AINK3S1eu0bPM JZCGcUW40xvx05hMeTRndJyJFjqZxWwHUe2A3D78ppqCdJqjRliJ0plpoHwc7D8AX0Ec FCnTXK2MxDT6O0dtrpWuxYdvWdMUlGPFzTdmZ1eU2S6fwQihOVffZgY6L7hUz1VMUGqr RmqAHwt3AGGD1aQg2qLpUaLJmJxI1Qab3NR6/WQFSIrIN86MqIrTV02l90yg3dVI1bfz OzXcM3TftIZqP0ynTtfWAY2OSMxQ3Nx972PcR5gtK5MzyMp/xkzCMR1J/uAXBtEIWKrY 2g== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2xw6vwqukk-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 02 Feb 2020 11:05:28 -0800 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q5300B7O914IO30@rn-mailsvcp-mta-lapp01.rno.apple.com> for tls@ietf.org; Sun, 02 Feb 2020 11:05:28 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q53001008OIV700@nwk-mmpp-sz13.apple.com> for tls@ietf.org; Sun, 02 Feb 2020 11:05:28 -0800 (PST) X-Va-A: X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-Va-CD: 0 X-Va-ID: 80c672c9-fa21-4572-83e1-1bc83f035c8c X-V-A: X-V-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-V-CD: 0 X-V-ID: d5892240-5735-40f4-a5d6-dbd4fd8a6d3e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-02_06:,, signatures=0 Received: from [17.234.29.189] (unknown [17.234.29.189]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q53006GV911GI00@nwk-mmpp-sz13.apple.com> for tls@ietf.org; Sun, 02 Feb 2020 11:05:25 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Sun, 02 Feb 2020 11:05:24 -0800 References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> <20200202175309.GL49778@straasha.imrryr.org> To: tls@ietf.org In-reply-to: <20200202175309.GL49778@straasha.imrryr.org> Message-id: <53913E7D-765D-473B-980D-088F3D9D0C4D@apple.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-02_06:, , signatures=0 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 19:05:32 -0000 > On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni = wrote: >=20 > On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote: >=20 >> If you did need a sentinel to indicate that you wanted to try to = reuse >> a ticket (which you can always try if you want), it would make more >> sense to just make that sentinel be 255, etc, rather than creating = two >> sentinels. >=20 > Sure, if you want to swap my 0 <-> 255, that'd be fine by me, then > 0--254 are "natural", and 255 means "only as needed". If that's what = it > takes to reach a compromise, I'm on board. >=20 >> The ticket reuse signaling that is proposed really is orthogonal to = the *count* of tickets. >=20 > Except that it really isn't. Reuse means: 0 tickets or 1 ticket when > the one presented is or soon will become unusable. There's no way to > decouple that from the ticket count. I don=E2=80=99t see why one should limit the number of tickets that can = be requested to only 1 in a case in which a client wants ticket reuse, = since the entire point of this extension message is to allow requesting = multiple. I understand that there may be some scenarios in which a = client requests multiple on the initial handshake, and then wants only = one more after that, but that=E2=80=99s not necessarily the case. For example, I connect once, and request 4 tickets so I can do happy = eyeballs attempts (one for v4 and v6 on each Wi-Fi and Cell, say). When = I try to connect later, I end up using all four of those tickets on = attempts, but only one succeeds. Now I want 4 more, but only have one = connection. If you wanted to have your ticket reuse signaling in this = case, you=E2=80=99d want to express =E2=80=9Ceither give me 4 new = tickets, or let me know I can reuse the previous four=E2=80=9D, in which = case overloading values in the number of tickets is indeed reducing the = expressivity of the mechanism. Tommy >=20 >=20 > --=20 > Viktor. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Feb 2 11:52:09 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B59120122 for ; Sun, 2 Feb 2020 11:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nEb1K5pCRUSD for ; Sun, 2 Feb 2020 11:52:03 -0800 (PST) Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4A5120033 for ; Sun, 2 Feb 2020 11:52:03 -0800 (PST) Received: by mail-vk1-f174.google.com with SMTP id g7so3532265vkl.12 for ; Sun, 02 Feb 2020 11:52:03 -0800 (PST) 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=hLrcmKTa9WxuF5JenGvhrKKA06L+edRe/m2q8k/wuGQ=; b=WPywesMUHYEz5bS0uwyPptKY3SFaAblw1Nsnd+kyAFsC7UjEu6NrrloSk4ctvjWtUE HvX6BIivMvYAiKLkMn54dOyJuerpo2vgD+6weB2rVLm8QvaoXvo/QpiXcgR74ORPahZG B7KNglT3MJFv82wsEUc9P6Fks1NYEUt7/ff4y8xZfXKJjLN7am7KllS+a/rEJPjotYyH +VKqhj+4GB/kiwZFOIqPLjgy2GVrlxoi0Lx82GqIiuMUMnZTW7PR14RuevhWkRljZiyU kUPpymrcqKxS31q4SZjXuC9uM5iXqiScGlW3Ofw/ZI10uNh44pOp8SuCPOyX6mjAQqcH ATTA== X-Gm-Message-State: APjAAAUFT3DscP5ORcEczDXrV8e6y7HgM0z3NqmaROLzByD23Ts83nas 63aGQfPS4UuoFzjukBo4kpl4kTJgrdF70qy0vDhhhnNz90yJVA== X-Google-Smtp-Source: APXvYqwMAZn6gL6LsstbWmKt+8sFRxyIN8J2AUENx0TBWq6H95LTmuBwIvqjeu1w/vqKDlAVdokJRvKwBHr6R1WTUAM= X-Received: by 2002:a1f:6012:: with SMTP id u18mr12009188vkb.77.1580673122515; Sun, 02 Feb 2020 11:52:02 -0800 (PST) MIME-Version: 1.0 References: <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> In-Reply-To: From: Daniel Migault Date: Sun, 2 Feb 2020 14:51:51 -0500 Message-ID: To: Eric Rescorla Cc: "" Content-Type: multipart/alternative; boundary="000000000000f93fae059d9d2309" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 19:52:07 -0000 --000000000000f93fae059d9d2309 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote: > > On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote: > > > > > I would make several points here: > > > > > > 1. RFC 8446 explicitly discourages ticket reuse > > > (https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we > > > should not be designing an extension to enable reuse. While it's > > > potentially true that some applications do not benefit from > > > non-reuse, creating a set of mechanisms around reuse risks those > > > mechanisms being used in settings where reuse would be > > > bad. Moreover. just because at present sending MTAs have weak > > > privacy properties does not mean that we should bake in this > > > situation permanently. > > > > Indeed I agree that ticket reuse is often undesirable, and expect that > > it will be avoided in many cases. So I am somewhat sympathetic to the > > above as a starting point for the analysis. > > > > That said, I don't see that making reuse easier to negotiate is likely > > to create significant opportunities for misuse. > > I'm actually making several points here: > > 1. TLS 1.3 takes the position that reuse is bad and that position > is for good reasons, so we shouldn't undercut it in a new > extension. > > This statement seems wrong to me as TLS 1.3 does not provide such position. Appendix C.4 discourages tickets re-use when Client tracking is a concern. The section uses SHOULD and not MUST. So, in fact, TLS 1.3 takes position this is not mandatory to renew tickets. As you mention, this position is for good reasons, that is the consideration of other use cases than the web browsing use case, and I also tend to agree with you we should not go beyond what TLS 1.3 says - that is: not necessarily preventing ticket re-use. 2. Creating a mechanism which encourages reuse increases the risk > of reuse. > > You are responding to number (2), and I'll respond to that below, > but I think the controlling point is actually (1). We shouldn't > encourage reuse, period. > > > > - Both the client *and* the server would need to opt-in to reuse. > > > > * Even if the client asks for reuse, the server can invalidate > > the old ticket (something it would need to be able to do > > already to ensure non-reuse) and send a fresh one anyway. > > > > The client would have to replace the old with the new, since > > it has to assume that the old is now likely invalid. > > > > * Even if the server is willing to reuse, if the client asks > > for a new ticket, the server has to assume the client has > > a single-use cache, and should vend a new ticket. > > > > so it takes bilateral coordination to arrive at reuse, and > > so accidental reuse in applications where it is inappropriate > > requires errors on both ends. > > The issue is less accidental reuse than joint misconfiguration (e.g., > bad defaults or bad advice in some Stack Overflow document). > > > > > > 2. The additional cost of multiple tickets seems extraordinarily > > > small, so I am not at all persuaded that there is enough value in > > > this use case to justify adding new protocol machinery, even > > > ignoring point (1) above. > > > > Postfix has a shared cache (indexed by destination domain+mx host) for > > multiple independent processes racing to use the cache to make remote > > SMTP connections. > > > > Frequent writes to that cache create measurable overhead and still don't > > prevent reuse. > > I'm sorry to say that I'm not that sympathetic to this position. I > appreciate that it's inconvenient for Postfix to have frequent writes > to the ticket cache, but what you propose to do is hoist this > implementation idiosyncracy into the specification, and I don't think > that that's a good tradeoff, both for complexity and because the > > > > Transmission of unnecessary tickets is also wasteful of > > network and other server resources. > > Well, my position here is that these tickets aren't unnecessary, > because you should be using them, rather than violating the > SHOULD in the 8446. > > > > Erasing tickets on first use would be unwise, most existing servers will > > not presently return a fresh ticket on resumption. > > This seems like a defect in those servers. However it can be handled > by not erasing tickets until a new ticket is provided.. > > > > > > > 3. If there *is* such value, then you can register your own extension > > > which allows you to say the orthogonal thing, namely "don't send me > > > any tickets at all if you are resuming". This would be more > > > flexible in that you could then say "I would like 10 tickets, but > > > only if you don't resume". Note that > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ would > > > allow you to do this efficiently. > > > > This is an interesting idea, but how would the two extensions interact? > > I would imagine the logic would be: > > If !reuse || !present(reuse extension) { > send min(max-local-tickets, > tickets-requested-extension-present ? > tickets-requested-extension-value : > 1) > } > > > And wouldn't that interaction add more complexity? > > Perhaps. At least in NSS, I imagine it would be pretty comparable, assuming > we opted to implement the non-reuse one at all. > > > > By hypothesis > > clients that are willing to reuse tickets don't really need more than > > one at a time. Is there a clear use case for multiple concurrent > > reusable tickets. > > Yes, I see your point here. I don't have a clear case for this, but > I'm also not sure that there isn't one: concurrent usage and serial > usage are not necessarily the same. > > > > > Thus, I would prefer to advance this document as-is. > > > > Thanks for the substantive response. Much appreciated. I hope you're > > willing to address the above reaction, I am trying to find common > > ground that addresses your concerns and mine. > > And thank you for your substantive response. I am not sure if we will be > able to > find common ground however. > > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000f93fae059d9d2309 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 2, 2020 at 12:09 PM Eric = Rescorla <ekr@rtfm.com> wrote:
&= gt; On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote:
> =
> > I would make several points here:
> >
> > = 1. RFC 8446 explicitly discourages ticket reuse
> > =C2=A0 =C2=A0(= https://tools.ietf.org/rfcmarkup?doc=3D8446#appendix-C.4). = so we
> > =C2=A0 =C2=A0should not be designing an extension to ena= ble reuse. While it's
> > =C2=A0 =C2=A0potentially true that s= ome applications do not benefit from
> > =C2=A0 =C2=A0non-reuse, c= reating a set of mechanisms around reuse risks those
> > =C2=A0 = =C2=A0mechanisms being used in settings where reuse would be
> > = =C2=A0 =C2=A0bad. Moreover. just because at present sending MTAs have weak<= br>> > =C2=A0 =C2=A0privacy properties does not mean that we should b= ake in this
> > =C2=A0 =C2=A0situation permanently.
>
&g= t; Indeed I agree that ticket reuse is often undesirable, and expect that> it will be avoided in many cases.=C2=A0 So I am somewhat sympathetic= to the
> above as a starting point for the analysis.
>
>= ; That said, I don't see that making reuse easier to negotiate is likel= y
> to create significant opportunities for misuse.

I'm ac= tually making several points here:

1. TLS 1.3 takes the position tha= t reuse is bad and that position
=C2=A0 =C2=A0is for good reasons, so we= shouldn't undercut it in a new
=C2=A0 =C2=A0extension.


This statement seems wrong to me as TLS 1= .3 does not provide such position. Appendix C.4 discourages tickets re-use = when Client tracking is a concern. The section uses SHOULD and not MUST. So= , in fact, TLS 1.3 takes position this is not mandatory to renew tickets. A= s you mention, this position is for good reasons, that is the consideration= of other use cases than the web browsing use case, and I also tend to agre= e with you we should not go beyond what TLS 1.3 says - that is: not necessa= rily preventing ticket re-use.=C2=A0

2. Creating a mechanism w= hich encourages reuse increases the risk
=C2=A0 =C2=A0of reuse.

Y= ou are responding to number (2), and I'll respond to that below,
but= I think the controlling point is actually (1). We shouldn't
encoura= ge reuse, period.


> =C2=A0 =C2=A0 - Both the client *and* the= server would need to opt-in to reuse.
>
> =C2=A0 =C2=A0 =C2= =A0 * Even if the client asks for reuse, the server can invalidate
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 the old ticket (something it would need to be a= ble to do
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 already to ensure non-reuse) = and send a fresh one anyway.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 T= he client would have to replace the old with the new, since
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 it has to assume that the old is now likely invalid.>
> =C2=A0 =C2=A0 =C2=A0 * Even if the server is willing to reu= se, if the client asks
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 for a new ticket= , the server has to assume the client has
> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 a single-use cache, and should vend a new ticket.
>
> =C2= =A0 =C2=A0 =C2=A0 so it takes bilateral coordination to arrive at reuse, an= d
> =C2=A0 =C2=A0 =C2=A0 so accidental reuse in applications where it= is inappropriate
> =C2=A0 =C2=A0 =C2=A0 requires errors on both ends= .

The issue is less accidental reuse than joint misconfiguration (e.= g.,
bad defaults or bad advice in some Stack Overflow document).

=

> > 2. The additional cost of multiple tickets seems extraord= inarily
> > =C2=A0 =C2=A0small, so I am not at all persuaded that = there is enough value in
> > =C2=A0 =C2=A0this use case to justify= adding new protocol machinery, even
> > =C2=A0 =C2=A0ignoring poi= nt (1) above.
>
> Postfix has a shared cache (indexed by desti= nation domain+mx host) for
> multiple independent processes racing to= use the cache to make remote
> SMTP connections.
>
> Fre= quent writes to that cache create measurable overhead and still don't> prevent reuse.

I'm sorry to say that I'm not that sym= pathetic to this position. I
appreciate that it's inconvenient for P= ostfix to have frequent writes
to the ticket cache, but what you propose= to do is hoist this
implementation idiosyncracy into the specification,= and I don't think
that that's a good tradeoff, both for complex= ity and because the


> Transmission of unnecessary tickets is = also wasteful of
> network and other server resources.

Well, m= y position here is that these tickets aren't unnecessary,
because yo= u should be using them, rather than violating the
SHOULD in the 8446.

> Erasing tickets on first use would be unwise, most existing s= ervers will
> not presently return a fresh ticket on resumption.
<= br>This seems like a defect in those servers. However it can be handled
= by not erasing tickets until a new ticket is provided..


> > > 3. If there *is* such value, then you can register your own exte= nsion
> > =C2=A0 =C2=A0which allows you to say the orthogonal thin= g, namely "don't send me
> > =C2=A0 =C2=A0any tickets at = all if you are resuming". This would be more
> > =C2=A0 =C2= =A0flexible in that you could then say "I would like 10 tickets, but> > =C2=A0 =C2=A0only if you don't resume". Note that
&= gt; > =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-i= etf-tls-tlsflags/ would
> > =C2=A0 =C2=A0allow you to do this = efficiently.
>
> This is an interesting idea, but how would th= e two extensions interact?

I would imagine the logic would be:
If !reuse || !present(reuse extension) {
=C2=A0 send min(max-local-tic= kets,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tickets-requested-extensi= on-present ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tickets-requested-= extension-value :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01)
}
> And wouldn't that interaction add more complexity?

Perhap= s. At least in NSS, I imagine it would be pretty comparable, assuming
we= opted to implement the non-reuse one at all.


> By hypothesis=
> clients that are willing to reuse tickets don't really need mo= re than
> one at a time. Is there a clear use case for multiple concu= rrent
> reusable tickets.

Yes, I see your point here. I don= 9;t have a clear case for this, but
I'm also not sure that there isn= 't one: concurrent usage and serial
usage are not necessarily the sa= me.


> > Thus, I would prefer to advance this document as-i= s.
>
> Thanks for the substantive response.=C2=A0 Much appreci= ated.=C2=A0 I hope you're
> willing to address the above reaction= , I am trying to find common
> ground that addresses your concerns an= d mine.

And thank you for your substantive response. I am not sure i= f we will be able to
find common ground however.


-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000f93fae059d9d2309-- From nobody Sun Feb 2 15:00:05 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104FB1200E7 for ; Sun, 2 Feb 2020 15:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 DN513PpJjXFj for ; Sun, 2 Feb 2020 15:00:00 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (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 081E912012A for ; Sun, 2 Feb 2020 14:59:59 -0800 (PST) Received: from [66.31.15.242] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1iyODe-0004kD-At for tls@ietf.org; Sun, 02 Feb 2020 17:59:58 -0500 Date: Sun, 2 Feb 2020 17:59:58 -0500 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <1F297776-6A94-45FC-8EB6-93E45299498F@akamai.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79895baa06181226dbab1e5d0543a8563e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.31.15.242 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 23:00:03 -0000 On 2/1/20 at 7:43 PM, rsalz@akamai.com (Salz, Rich) wrote: > +1 to what Nico says. Ditto. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Security is like Government | Periwinkle (408)348-7900 | services. The market doesn't | 150 Rivermead Rd #235 www.pwpconsult.com | want to pay for them. | Peterborough, NH 03458 From nobody Sun Feb 2 19:40:07 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D320612086B for ; Sun, 2 Feb 2020 19:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 t3as3yNeOcE4 for ; Sun, 2 Feb 2020 19:40:03 -0800 (PST) Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F407120074 for ; Sun, 2 Feb 2020 19:40:03 -0800 (PST) Received: by mail-il1-x141.google.com with SMTP id g12so11412217ild.2 for ; Sun, 02 Feb 2020 19:40:03 -0800 (PST) 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=v/oicl3yccIWmKaq6WNs06jmmnKpJex/GMzBQ2o4vL8=; b=rsXlV4kvB26rPak40ZkBEWi06sLBIlSULygUsZ9inurk4vH6kwOiT8b9Rc0YtaKUfF 1yBJWBUfaTH25g18aRHNF7WdSHldz0MH07GJU5PQo2WnKF5PGlq5bvCGTwjlUennxmUg d3ziAwf68bV7j5SvgUJ4iggWToOHVrpf9lELKTZzohrorM8usy9kJY5cDH4tdG57DE4T nUyeDHmUVYDQiRd+93CtR8CDlLZIACzyogEaeEEHSph85ipncJZHXX34UgqCzyUoQ/UR V4vQMEjd5UlmvKQNQgFy2QJE65SMRRz8O2noYeXS1RR+SmJkD+EuV6682GUy4IcMnOP0 wC4A== 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=v/oicl3yccIWmKaq6WNs06jmmnKpJex/GMzBQ2o4vL8=; b=V+kJTVi9nb/kua1bEqBwfQNVMk3NuRy2jwdOuD5YIAJTGH0RmxClG3s5inQ0eVRvKj BLR2cQSI3L62c/H/VjZe37XymwFxOuJDPvKLq5KOp5V/R8gC4Os2M3abkVkWVOfWA7s0 4mUgcrqiiZrslokaHxpFg/pjmFb6EuWBJygZ/yOBmpCjEOdlu7XzieB/glx0R88e/BM5 sf/yqV2uy4h34K3VfGOabJl0JzUpYCDmkoW+rywr+WBAdluvcALP0naZLMQ/2SeJbRa5 8/5BX10WXhMOy/EitU1XP7Zj+FN41Fox+ttOcAMcmfndEFGsqGWRkmknDjweV0YSXEqx u40g== X-Gm-Message-State: APjAAAWfSoWliQVzLB3XDeEi0vor9ao2ANHHiOeWuvFRFriK3bdmdqMu ulSejER87ywLGRwIEUTB0yCnrSVOFiyT39HMWTel1PWu X-Google-Smtp-Source: APXvYqyPzSrTKZvpRPBBljjlVpMxf04R7EEhfyRc8NnoKpGB8cCd8/0wKYAPBQfJloK0UZXqPSlM7CZFGVP1ZDniBhQ= X-Received: by 2002:a92:1553:: with SMTP id v80mr20818119ilk.49.1580701202249; Sun, 02 Feb 2020 19:40:02 -0800 (PST) MIME-Version: 1.0 References: <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> In-Reply-To: From: Rob Sayre Date: Sun, 2 Feb 2020 19:39:51 -0800 Message-ID: To: Daniel Migault Cc: Eric Rescorla , "" Content-Type: multipart/alternative; boundary="000000000000a7feaa059da3ad52" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 03:40:05 -0000 --000000000000a7feaa059da3ad52 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault wrote: > > On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote: > >> >> >> 1. TLS 1.3 takes the position that reuse is bad and that position >> is for good reasons, so we shouldn't undercut it in a new >> extension. >> >> > . Appendix C.4 discourages tickets re-use when Client tracking is a > concern. The section uses SHOULD and not MUST. So, in fact, TLS 1.3 takes > position this is not mandatory to renew tickets. > RFC 2119 is a bit stronger than that: implementations are not required to interoperate with parties that violate the "SHOULD" (that is reserved for requirements designated with "MAY"). thanks, Rob --000000000000a7feaa059da3ad52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Feb 2, 2020 at 11:52 AM Daniel Mi= gault <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wrote:
<= br>
On Sun,= Feb 2, 2020 at 12:09 PM Eric Rescorla <ekr@rtfm.com> wrote:


1. TLS 1.3 takes the= position that reuse is bad and that position
=C2=A0 =C2=A0is for good r= easons, so we shouldn't undercut it in a new
=C2=A0 =C2=A0extension.=

=C2=A0<= /div>
. Appendix C.4 discourages tickets re-use when= Client tracking is a concern. The section uses SHOULD and not MUST. So, in= fact, TLS 1.3 takes position this is not mandatory to renew tickets.=C2=A0=

RFC 2119 is a bit st= ronger than that: implementations are not required to interoperate with par= ties that violate the "SHOULD" (that is reserved for requirements= designated with "MAY").

thanks,
Rob=C2=A0
--000000000000a7feaa059da3ad52-- From nobody Sun Feb 2 20:43:36 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E3F1208A9 for ; Sun, 2 Feb 2020 20:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_NONE=0.001, SPF_NONE=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 lT_hfUwh6e1Z for ; Sun, 2 Feb 2020 20:43:33 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 2EC5112089F for ; Sun, 2 Feb 2020 20:43:33 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id o15so7562446ljg.6 for ; Sun, 02 Feb 2020 20:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2paXsWPBYpllhOrm4PcV8gcgAhY5Ckod63Tj2MCO/kU=; b=ApE/9KcdYPXhHGwJcT9rkLHAXmteFex8XqehtYyU7Lq6UH3THlkBffDTPeDl02KHWX X6PnUhoRsTMzZ56g3IJfOA+zDZ10PFqKgC5+/Y8sXneNjFCyW08irENmRAZegBfle5Qg X+KN/jvOJmCrkzezyeYYoCiXfaGNG5lV9L52FkIUyLRjkS1x3NyuIf4yYt4l6ea2hOnP EULNmuic34zk5TMihMP5KkH0wQWwmt9JbkK5qp+xwe/4rLZzdTtWERr4dKc9bepdZSgn If1Gm8zga/I41slsBiiKyV5ZVWrvsZfyI0SPMVivXtJZCcMhr1cJqprJNuIl7snO6qRQ 4ohQ== 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=2paXsWPBYpllhOrm4PcV8gcgAhY5Ckod63Tj2MCO/kU=; b=Me+doJWr0WnU8AN3obGzzf1ju6J6hhxIg8JmLm7yLc52jczDwT7SFNAwTIx2QIB5/L ZlC8/9LDwzhV7VkTPgXFpOXIpQ5tKZMyQT+XmaS/e7wu1mzRvj+4USvIwB4kCWbNaVLc ufOu8KGg1eQuHRNgh5BP7b1L2eBh/cpSDaY7vHr8F5CS45z/6oS5vHHCVv2zydOW9t/e cmrP0uRaTMZ+dGIb0sCS6v2kTfDLNd92xIzRlt8MO8s1fR2qAIRLD1KatzdVgHbS2UK7 6Bd4fnm6u5eFS6Ao7jzTThn233pEIngPWnwKTVTSKL46FHh1P0a99yy/T6kax4+GIQnh 3PoQ== X-Gm-Message-State: APjAAAWZSPuu/VczT2KJX8SHPfFFFh5FleRZLfKneHQeGlwwOaXNRTqg Fi9glEkiFtTn/AqnOtqu+PcM4PsT9aTGXe/w2DqCCfVw X-Google-Smtp-Source: APXvYqxqOLGG2EaZkI3bDI0/HqYjk6MspJzkVbMd8heYrgl1Kshny/ad8gyQ78TBoo/X38uPOlIObzH90n7/4xVV36w= X-Received: by 2002:a05:651c:448:: with SMTP id g8mr12924903ljg.35.1580705011326; Sun, 02 Feb 2020 20:43:31 -0800 (PST) MIME-Version: 1.0 References: <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> <20200202190447.GG18021@localhost> In-Reply-To: <20200202190447.GG18021@localhost> From: Eric Rescorla Date: Sun, 2 Feb 2020 20:42:55 -0800 Message-ID: To: Nico Williams Cc: "" Content-Type: multipart/alternative; boundary="000000000000b1efc6059da490cb" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 04:43:35 -0000 --000000000000b1efc6059da490cb Content-Type: text/plain; charset="UTF-8" On Sun, Feb 2, 2020 at 11:04 AM Nico Williams wrote: > On Sun, Feb 02, 2020 at 09:08:17AM -0800, Eric Rescorla wrote: > > I'm sorry to say that I'm not that sympathetic to this position. I > > appreciate that it's inconvenient for Postfix to have frequent writes > > to the ticket cache, but what you propose to do is hoist this > > implementation idiosyncracy into the specification, and I don't think > > that that's a good tradeoff, both for complexity and because the > > We've done this a lot though, haven't we. For example, we've striven to > avoid reconnects because SChannel can't really handle them. > When we designed TLS 1.3, we paid a lot of attention to it being a drop-in replacement for TLS 1.2. This required some tradeoffs. Given that this issue already existed in TLS 1.2, I don't really see that that rationale applies here. -Ekr --000000000000b1efc6059da490cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 2, 2020 at 11:04 AM Nico = Williams <nico@cryptonector.com= > wrote:
= On Sun, Feb 02, 2020 at 09:08:17AM -0800, Eric Rescorla wrote:
> I'm sorry to say that I'm not that sympathetic to this positio= n. I
> appreciate that it's inconvenient for Postfix to have frequent wri= tes
> to the ticket cache, but what you propose to do is hoist this
> implementation idiosyncracy into the specification, and I don't th= ink
> that that's a good tradeoff, both for complexity and because the
We've done this a lot though, haven't we.=C2=A0 For example, we'= ;ve striven to
avoid reconnects because SChannel can't really handle them.

When we designed TLS 1.3, we paid a lot of attenti= on to it being a drop-in replacement for TLS 1.2. This required some tradeo= ffs. Given that this issue already existed in TLS 1.2, I don't really s= ee that that rationale applies here.

-Ekr


--000000000000b1efc6059da490cb-- From nobody Sun Feb 2 21:01:07 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870281208C6 for ; Sun, 2 Feb 2020 21:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QqVK8LiQjTh for ; Sun, 2 Feb 2020 21:01:01 -0800 (PST) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 BD2D51208BA for ; Sun, 2 Feb 2020 21:01:01 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 0134prew028291; Sun, 2 Feb 2020 21:00:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=rvnyuRVKrsXAXLz+aqQFFQguW47zfqn6EscbMFm3S98=; b=rGIVNo5WrRWsBPX3201SQqOorC1wzyd/oYr71O08K43m3z2RNzb3fYEATPC/6145YEVk kRBJOPZAblQHXV639ahTUaGyCBEfC5ozfytlrI3/jxVRPg8Si3B/26yK7bV8WETqXnVL Otpd5KXf+3L2SBYfCVFTlmFi035kio2QvvDBoUlYkVAcHvWNnhoig8eSB5olBWKyUEBb qOr01GZ7LYK33yUwcIQTTPUW9jJ7b7PSM5oAu7yC0fVCndigpLmRqoT9KBOT2hU/XpXG F7Uj74vpA3uLq1cdKRMjy5+6/AVc3YHPOKBgfcvgRJ4tRXoGjx94ypphPzbY0guqa6o0 nA== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2xw6snfvw8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 02 Feb 2020 21:00:59 -0800 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q5400RGX0LNNP00@rn-mailsvcp-mta-lapp01.rno.apple.com>; Sun, 02 Feb 2020 21:00:59 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q54001000I0Y500@nwk-mmpp-sz11.apple.com>; Sun, 02 Feb 2020 21:00:59 -0800 (PST) X-Va-A: X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-Va-CD: 0 X-Va-ID: 61d3819c-0559-43c1-b887-79fb9445e93a X-V-A: X-V-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-V-CD: 0 X-V-ID: 0ba4722e-7fa2-4ca4-9063-bbea2da39bcb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-02_09:,, signatures=0 Received: from [17.234.32.41] (unknown [17.234.32.41]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q5400HNN0LMTN50@nwk-mmpp-sz11.apple.com>; Sun, 02 Feb 2020 21:00:59 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <7CAD8A81-2B5B-4730-ADCD-73F81A6D5DCF@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_A282E02D-F24D-4722-B397-BAF590D82E22" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Sun, 02 Feb 2020 21:00:58 -0800 In-reply-to: <53913E7D-765D-473B-980D-088F3D9D0C4D@apple.com> Cc: Viktor Dukhovni To: tls@ietf.org References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> <20200202175309.GL49778@straasha.imrryr.org> <53913E7D-765D-473B-980D-088F3D9D0C4D@apple.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-02_09:, , signatures=0 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 05:01:06 -0000 --Apple-Mail=_A282E02D-F24D-4722-B397-BAF590D82E22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I spoke with Viktor this afternoon about various scenarios being = discussed on this thread. Going through the different use cases was very = helpful in elucidating what functionality is appropriate. The use cases we discussed are as follows. A and B are about multiple = ticket requests. C and D are about ticket reuse. E is about both. A. Multiple Tickets: Client with concurrent connections In this scenario, a client may want to, from one initial TLS session, = retrieve tickets for a pool of future connections. For this example, say = this is four connections in a pool. On the initial connection, the = client requests four tickets. It then can create four more connections, = each with a unique ticket. =46rom then on, each of those connections = only requests a single ticket more, so as to get a ticket to replace the = one they consumed. This allows a constant-sized pool of connections, = where each connection gets to use tickets to resume. If the server rejects a ticket due to deleting the session, the client = can either continue to ask for one new ticket for each connection in the = pool, or recognize that the tickets are no longer valid, and thus ask = for a new batch (say, four new tickets) on the next handshake. B. Multiple Tickets: Client with connection racing For a client that wants a single connection, but may race connection = establishment across address families (classic Happy Eyeballs) and = interfaces (as in a mobile device case), the client may request a = handful of tickets up front to allow connection racing. When racing, the = client may consume, via connection attempts, more than one ticket to get = one successful connection. For example, a client make use a ticket on a = connection attempt over Wi-Fi, but then try LTE if Wi-Fi is stalling, = and thus consume two tickets but only completes one connection. So, = whenever a client knows it has consumed more tickets, it should try to = repopulate the tickets. Note that it only knows how many it consumed = *after* one is established, so it shouldn=E2=80=99t run its ticket = collection dry on every connection attempt. Rather, it would probably = make most sense to have enough tickets for two connection establishment = attempts, such that any time many are consumed, the following handshake = has the opportunity to ask for more. If the server rejects a ticket due to deleting the session, all raced = attempts for establishment will likely fail to resume together. Just = like the case in which a client consumes many tickets due to racing, the = client can only change the number of tickets it asks for on the = *subsequent* handshake. C. Single Ticket Reuse: Clients with trusted connection to the server, = all/most clients reuse If, in a controlled environment, a deployment wants to reuse tickets for = resumption, the server can choose to allow that, and clients can choose = to support that. If each client only needs a single ticket (since it can = reuse its tickets), it doesn=E2=80=99t need to signal about multiple = tickets. The one case in which it does need a new ticket is if the = server deletes the session. If the server knows that the majority of its clients reuse tickets, it = can choose to simply give out a ticket only on the first handshake for a = given client, or when a session has been deleted. For this case, no = signaling should be needed. D. Single Ticket Reuse: Clients wants to reuse (and server supports), = most other clients do not reuse As a variation, a server that supports ticket reuse in a situation when = most of its clients do not support ticket reuse cannot simply only hand = out tickets upon initial handshake, since most clients would then stop = resuming. Instead, it would prefer to, by default, hand out a new = ticket. For clients that *did* support reuse, it would be useful to have = a signal. This signal is effectively a boolean to indicate that the = client is happy with the tickets it currently has, and will reuse them = unless the server gives out new tickets. E. Multiple Ticket Reuse: Client want separate tickets for concurrent = connections, that are later reused Viktor described a case in which a client is split across multiple = processes, so could be convenient to have independent tickets that are = all retrieved from an initial connection that requested multiple = handshakes, but the individual processes would want to treat those = tickets as reusable until the server deleted the session. This case = would want to both be able to request multiple tickets, and signal that = reuse is possible. =3D=3D=3D=3D=3D=3D=3D=3D=3D The questions I think that are most relevant are, based on our = discussion: How many distinct pieces of information are there that could be = communicated from client to server? Are any of these pieces fundamentally entangled, or should they be = communicated separately? Is any capability lost by allowing them to be = communicated separately? To answer question 1, there are a few possible pieces of information = that the client can send: First is the item in the current draft, the Integer number of tickets = that a client would like to receive from the server, based on the = client=E2=80=99s current knowledge (how many tickets it already has, and = if it is a new handshake or a resumption). This shows up in cases (A), = (B), and (E). Next is the Boolean value that indicates that a client intends to reuse = the ticket(s) it already has, as a request to the server to only send = tickets if the old one won=E2=80=99t work. This is what Viktor = originally proposed to use as a sentinel value in the Integer space. = This shows up in cases (C), (D), and (E). A third possible item is a case that was brought up in our discussion: = the Integer number of tickets that a client would like to receive if the = current resumption attempt fails. The idea here is that a client in case = (A) would be happy to only receive one ticket if the session is still = valid, but would possibly want an entirely new batch (such as 4) if the = resumption fails, so it can restock its ticket pool. This is certainly = an interesting case, and one that I do consider to be in scope for the = document, but I do have concerns that it does not apply well to all = cases. For example, in scenario (B), the client is racing multiple = connection attempts. If two or more raced attempts do hit the server at = the same time, and the session state has been deleted, having all of = them start to request more tickets than they would otherwise may end up = requesting too many. Since the cases like (B) do often need to adjust = their requests on subsequent handshakes, it seems to me that it is = simpler to have only one value, and err on the side of requesting too = few tickets on occasion instead of requesting some exponential amount. = However, if people have particular opinions on this, I=E2=80=99d like to = hear them! So, to sum up, there are two possible Integer values to send, and one = possible Boolean value to send. To answer question 2, I=E2=80=99d point to the example use cases to = conclude that, at the very least, the Integer number of tickets, and = Boolean client intent to reuse tickets, are indeed separate pieces of = information. Cases (A) and (B) only are concerned with the number of = tickets. Cases (C) and (D) are only concerned with signaling ticket = reuse. Case (E) could take advantage of both. If we consider that these two pieces of information are independent, and = can be used either separately or together, we can evaluate the possible = approaches: The initial proposal to carve out a sentinel value from the Integer = request count space to signal the reuse Boolean. This approach has the = downsides of not allowing the values to be communicated together, as = well as requires that any implementation that supports one value must = also write logic to support the other. As we see above, many of the use = cases only need one. The ticket_request struct could contain two separate values, an Integer = and a Boolean. In this case, the values can be communicated alongside on = another, which is good. It does still require handling both values in an = implementation that only uses one. Use the ticket_request extension for the Integer, and create a new = prefer_ticket_reuse extension for the Boolean. This allows flexibility = of communication, and also allows the semantics of this new extension to = be defined, and to potentially have server response (which the = ticket_request extension doesn=E2=80=99t have). Viktor expressed two concerns with the separation proposed in approach = 3: First, the concern that the working group wouldn=E2=80=99t work on any = more extensions around tickets. I hope that this would not be the case! = Any valid use case that the working group sees fit to work on should be = open to be worked on, and it is not the intent of the ticket request = draft to preclude any future extensions that interact with tickets in = other ways, such as specifying reuse policies. Second, the concern that server processing logic would be too complex if = these values weren=E2=80=99t combined. This I do want to dig into a bit. =46rom the server=E2=80=99s perspective, there should be three = possibilities: the client uses only the ticket_request extension, the = client uses only the prefer_ticket_reuse extension, or the client uses = both the ticket_request and prefer_ticket_reuse extensions. If the server supports both extensions, it should wait to process all = client extensions before deciding how many tickets to send back. If the = prefer_ticket_reuse extension is present, it would choose to not = generate any new tickets unless session state was explicitly deleted; in = that case, it would send tickets with a count hinted by ticket_request. = My impression is that this does not actually constitute any more = complexity in server implementation than if the values were present in a = single extension, since the generation of tickets should wait until the = server has finished the handshake anyway. The difference in = implementation is only in the parsing, not in the processing. =3D=3D=3D=3D=3D=3D=3D=3D=3D Based on this analysis, I=E2=80=99d recommend the following: The proposal for hinting ticket reuse should be written up as a new = draft proposing an extension, with discussion on use cases around ticket = reuse. The reuse discussion can continue around that document. Consider adding text to draft-ietf-tls-ticketrequests to explain the = fact that when racing connections, the client won=E2=80=99t necessarily = know the number of tickets it will =E2=80=9Cconsume=E2=80=9D, so it = should either have enough tickets for two subsequent handshake = resumptions; or else use fewer tickets but potentially run out. Thanks, Tommy > On Feb 2, 2020, at 11:05 AM, Tommy Pauly = wrote: >=20 >=20 >=20 >> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni = wrote: >>=20 >> On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote: >>=20 >>> If you did need a sentinel to indicate that you wanted to try to = reuse >>> a ticket (which you can always try if you want), it would make more >>> sense to just make that sentinel be 255, etc, rather than creating = two >>> sentinels. >>=20 >> Sure, if you want to swap my 0 <-> 255, that'd be fine by me, then >> 0--254 are "natural", and 255 means "only as needed". If that's what = it >> takes to reach a compromise, I'm on board. >>=20 >>> The ticket reuse signaling that is proposed really is orthogonal to = the *count* of tickets. >>=20 >> Except that it really isn't. Reuse means: 0 tickets or 1 ticket when >> the one presented is or soon will become unusable. There's no way to >> decouple that from the ticket count. >=20 > I don=E2=80=99t see why one should limit the number of tickets that = can be requested to only 1 in a case in which a client wants ticket = reuse, since the entire point of this extension message is to allow = requesting multiple. I understand that there may be some scenarios in = which a client requests multiple on the initial handshake, and then = wants only one more after that, but that=E2=80=99s not necessarily the = case. >=20 > For example, I connect once, and request 4 tickets so I can do happy = eyeballs attempts (one for v4 and v6 on each Wi-Fi and Cell, say). When = I try to connect later, I end up using all four of those tickets on = attempts, but only one succeeds. Now I want 4 more, but only have one = connection. If you wanted to have your ticket reuse signaling in this = case, you=E2=80=99d want to express =E2=80=9Ceither give me 4 new = tickets, or let me know I can reuse the previous four=E2=80=9D, in which = case overloading values in the number of tickets is indeed reducing the = expressivity of the mechanism. >=20 > Tommy >=20 >>=20 >>=20 >> --=20 >> Viktor. >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls = >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_A282E02D-F24D-4722-B397-BAF590D82E22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I spoke with Viktor = this afternoon about various scenarios being discussed on this thread. = Going through the different use cases was very helpful in elucidating = what functionality is appropriate.

The use cases we = discussed are as follows. A and B are about multiple ticket requests. C = and D are about ticket reuse. E is about both.

A. Multiple Tickets: Client with concurrent = connections
In this scenario, a client may want to, from one initial TLS = session, retrieve tickets for a pool of future connections. For this = example, say this is four connections in a pool. On the initial = connection, the client requests four tickets. It then can create four = more connections, each with a unique ticket. =46rom then on, each of = those connections only requests a single ticket more, so as to get a = ticket to replace the one they consumed. This allows a constant-sized = pool of connections, where each connection gets to use tickets to = resume.

If the server rejects a ticket = due to deleting the session, the client can either continue to ask for = one new ticket for each connection in the pool, or recognize that the = tickets are no longer valid, and thus ask for a new batch (say, four new = tickets) on the next handshake.

B. = Multiple Tickets: Client with connection racing
For a client that = wants a single connection, but may race connection establishment across = address families (classic Happy Eyeballs) and interfaces (as in a mobile = device case), the client may request a handful of tickets up front to = allow connection racing. When racing, the client may consume, via = connection attempts, more than one ticket to get one successful = connection. For example, a client make use a ticket on a connection = attempt over Wi-Fi, but then try LTE if Wi-Fi is stalling, and thus = consume two tickets but only completes one connection. So, whenever a = client knows it has consumed more tickets, it should try to repopulate = the tickets. Note that it only knows how many it consumed *after* one is = established, so it shouldn=E2=80=99t run its ticket collection dry on = every connection attempt. Rather, it would probably make most sense to = have enough tickets for two connection establishment attempts, such that = any time many are consumed, the following handshake has the opportunity = to ask for more.

If the server rejects a ticket = due to deleting the session, all raced attempts for establishment will = likely fail to resume together. Just like the case in which a client = consumes many tickets due to racing, the client can only change the = number of tickets it asks for on the *subsequent* handshake.
C. Single Ticket Reuse: Clients with trusted = connection to the server, all/most clients reuse
If, in a controlled = environment, a deployment wants to reuse tickets for resumption, the = server can choose to allow that, and clients can choose to support that. = If each client only needs a single ticket (since it can reuse its = tickets), it doesn=E2=80=99t need to signal about multiple tickets. The = one case in which it does need a new ticket is if the server deletes the = session.

If the server knows that the = majority of its clients reuse tickets, it can choose to simply give out = a ticket only on the first handshake for a given client, or when a = session has been deleted. For this case, no signaling should be = needed.

D. Single Ticket = Reuse: Clients wants to reuse (and server supports), most other clients = do not reuse
As a variation, a server that supports ticket reuse in a = situation when most of its clients do not support ticket reuse cannot = simply only hand out tickets upon initial handshake, since most clients = would then stop resuming. Instead, it would prefer to, by default, hand = out a new ticket. For clients that *did* support reuse, it would be = useful to have a signal. This signal is effectively a boolean to = indicate that the client is happy with the tickets it currently has, and = will reuse them unless the server gives out new tickets.
E. Multiple Ticket Reuse: Client want separate = tickets for concurrent connections, that are later reused
Viktor described a = case in which a client is split across multiple processes, so could be = convenient to have independent tickets that are all retrieved from an = initial connection that requested multiple handshakes, but the = individual processes would want to treat those tickets as reusable until = the server deleted the session. This case would want to both be able to = request multiple tickets, and signal that reuse is possible.
=3D=3D=3D=3D=3D=3D=3D=3D=3D

The questions I = think that are most relevant are, based on our discussion:
  1. How many distinct = pieces of information are there that could be communicated from client = to server?
  2. Are any of these = pieces fundamentally entangled, or should they be communicated = separately? Is any capability lost by allowing them to be communicated = separately?

To answer question 1, there are a few possible pieces of = information that the client can send:
  • First is the item = in the current draft, the Integer number of tickets that a client would = like to receive from the server, based on the client=E2=80=99s current = knowledge (how many tickets it already has, and if it is a new handshake = or a resumption). This shows up in cases (A), (B), and (E).
  • Next is the Boolean = value that indicates that a client intends to reuse the ticket(s) it = already has, as a request to the server to only send tickets if the old = one won=E2=80=99t work. This is what Viktor originally proposed to use = as a sentinel value in the Integer space. This shows up in cases (C), = (D), and (E).
  • A third possible = item is a case that was brought up in our discussion: the Integer number = of tickets that a client would like to receive if the current resumption = attempt fails. The idea here is that a client in case (A) would be happy = to only receive one ticket if the session is still valid, but would = possibly want an entirely new batch (such as 4) if the resumption fails, = so it can restock its ticket pool. This is certainly an interesting = case, and one that I do consider to be in scope for the document, but I = do have concerns that it does not apply well to all cases. For example, = in scenario (B), the client is racing multiple connection attempts. If = two or more raced attempts do hit the server at the same time, and the = session state has been deleted, having all of them start to request more = tickets than they would otherwise may end up requesting too many. Since = the cases like (B) do often need to adjust their requests on subsequent = handshakes, it seems to me that it is simpler to have only one value, = and err on the side of requesting too few tickets on occasion instead of = requesting some exponential amount. However, if people have particular = opinions on this, I=E2=80=99d like to hear them!

So, to sum up, there are two possible Integer values to send, = and one possible Boolean value to send.

To answer question = 2, I=E2=80=99d point to the example use cases to conclude that, at the = very least, the Integer number of tickets, and Boolean client intent to = reuse tickets, are indeed separate pieces of information. Cases (A) and = (B) only are concerned with the number of tickets. Cases (C) and (D) are = only concerned with signaling ticket reuse. Case (E) could take = advantage of both.

If we consider that these two = pieces of information are independent, and can be used either separately = or together, we can evaluate the possible approaches:
  1. The initial = proposal to carve out a sentinel value from the Integer request count = space to signal the reuse Boolean. This approach has the downsides of = not allowing the values to be communicated together, as well as requires = that any implementation that supports one value must also write logic to = support the other. As we see above, many of the use cases only need = one.
  2. The ticket_request = struct could contain two separate values, an Integer and a Boolean. In = this case, the values can be communicated alongside on another, which is = good. It does still require handling both values in an implementation = that only uses one.
  3. Use the = ticket_request extension for the Integer, and create a new = prefer_ticket_reuse extension for the Boolean. This allows flexibility = of communication, and also allows the semantics of this new extension to = be defined, and to potentially have server response (which the = ticket_request extension doesn=E2=80=99t have).

Viktor expressed two concerns with the separation proposed in = approach 3:

First, the concern that the = working group wouldn=E2=80=99t work on any more extensions around = tickets. I hope that this would not be the case! Any valid use case that = the working group sees fit to work on should be open to be worked on, = and it is not the intent of the ticket request draft to preclude any = future extensions that interact with tickets in other ways, such as = specifying reuse policies.

Second, the concern that server = processing logic would be too complex if these values weren=E2=80=99t = combined. This I do want to dig into a bit.
=46rom the server=E2=80=99s = perspective, there should be three possibilities: the client uses only = the ticket_request extension, the client uses only the = prefer_ticket_reuse extension, or the client uses both the = ticket_request and prefer_ticket_reuse extensions.
If the server = supports both extensions, it should wait to process all client = extensions before deciding how many tickets to send back. If the = prefer_ticket_reuse extension is present, it would choose to not = generate any new tickets unless session state was explicitly deleted; in = that case, it would send tickets with a count hinted by ticket_request. = My impression is that this does not actually constitute any more = complexity in server implementation than if the values were present in a = single extension, since the generation of tickets should wait until the = server has finished the handshake anyway. The difference in = implementation is only in the parsing, not in the processing.
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Based on this = analysis, I=E2=80=99d recommend the following:
  • The proposal for = hinting ticket reuse should be written up as a new draft proposing an = extension, with discussion on use cases around ticket reuse. The reuse = discussion can continue around that document.
  • Consider adding = text to draft-ietf-tls-ticketrequests to explain the fact that when = racing connections, the client won=E2=80=99t necessarily know the number = of tickets it will =E2=80=9Cconsume=E2=80=9D, so it should either have = enough tickets for two subsequent handshake resumptions; or else use = fewer tickets but potentially run out.
Thanks,
Tommy

On Feb 2, 2020, at 11:05 AM, = Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:



On = Feb 2, 2020, at 9:53 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly = wrote:

If you did need a sentinel to indicate that you wanted to try = to reuse
a ticket (which you can always try if you want), = it would make more
sense to just make that sentinel be = 255, etc, rather than creating two
sentinels.

Sure, if you want to swap my 0 = <-> 255, that'd be fine by me, then
0--254 are = "natural", and 255 means "only as needed".  If that's what it
takes to reach a compromise, I'm on board.

The ticket reuse = signaling that is proposed really is orthogonal to the *count* of = tickets.

Except that it really = isn't.  Reuse means: 0 tickets or 1 ticket when
the = one presented is or soon will become unusable.  There's no way = to
decouple that from the ticket count.

I don=E2=80=99t see why one should limit the number of = tickets that can be requested to only 1 in a case in which a client = wants ticket reuse, since the entire point of this extension message is = to allow requesting multiple. I understand that there may be some = scenarios in which a client requests multiple on the initial handshake, = and then wants only one more after that, but that=E2=80=99s not = necessarily the case.

For example, I connect once, and request 4 tickets so I can = do happy eyeballs attempts (one for v4 and v6 on each Wi-Fi and Cell, = say). When I try to connect later, I end up using all four of those = tickets on attempts, but only one succeeds. Now I want 4 more, but only = have one connection. If you wanted to have your ticket reuse signaling = in this case, you=E2=80=99d want to express =E2=80=9Ceither give me 4 = new tickets, or let me know I can reuse the previous four=E2=80=9D, in = which case overloading values in the number of tickets is indeed = reducing the expressivity of the mechanism.

Tommy



-- 
  Viktor.

_______________________________________________
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=_A282E02D-F24D-4722-B397-BAF590D82E22-- From nobody Sun Feb 2 21:02:26 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BD81208C6 for ; Sun, 2 Feb 2020 21:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_NONE=0.001, SPF_NONE=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 mRd8IAJK_YQr for ; Sun, 2 Feb 2020 21:02:23 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D4D1208C5 for ; Sun, 2 Feb 2020 21:02:23 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id z18so8737774lfe.2 for ; Sun, 02 Feb 2020 21:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=38SPibAwmap8efbOlDSlfBJtl3XelhczcbEqv0MPpCU=; b=FScpUx26bTeERaxk94+sC93XbpSouiHbYrcd37P1Ouia2RMm/PAEku+DaGIMVpZS9E 4CGpZfKTiRhXcE+gj0yT+XpKHV7G83Vnvxfa4JCTmzqZvnyWMRbmKuYMV6gUsmabWVRw r5HmYS7NQ1oy2HVIqUp3gNz1/eHzyI3Hx+bt2S8sI0oZ2Dn02ikx97jw+ZMs6WlqzghZ 8sFwVeICghDRhi618BsUX2akDWaD2JrR/CBltWyb3eCU0/SgSWSrcihRYiwu64FcGjk0 SwLDIOOSfWk37YR7gbY+QDnkU9nW8kOniAVNF2aBdw3FPAIi6YUHMwRO1OsDEEEg+ClQ GQ7w== 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=38SPibAwmap8efbOlDSlfBJtl3XelhczcbEqv0MPpCU=; b=eKlLkEgEwG3+ckIOk/72CcYPJZddQiXUBQ9MpjQ5OCxspOIEZ7dYYu3pAtbkbiHJzP YWCQl43QzC8dPvMcXjHMrgp/0y/IdpcifUucrE9eQsu4aW4Kb1NfSNPkwrm/nDDwWZ0d 3EZPIrIjvdNNkAnULgfXFv2djewscX4O/6ZFrK+KX5hcXOe9BiLiHN3uDzOfoGIj4lHf AM14u/4uewQtzepUe2ZdT2TpKjh1IEL8XUllv8n1zXJvTre/ZraNv4JrKFra2Nvl6lfn uq2iJHt4MgAcWVQlQgzXr9lGkB5oTmYG0mYnaRYzkX8WBJv9sfGxN+CyDUQiaENYCI3e qWsw== X-Gm-Message-State: APjAAAVp4qmfzmV89o+RzrG89kVkcUaxLrYQlH+KvCsCbldac4jXVwSR ObcBPYJohhs+5DgZ5cMq0pvvRRcSeIEQoWEXjmadoA== X-Google-Smtp-Source: APXvYqzeZWutO25os0OWuSSD6aLEXiYLBaDZq/dqNnOFD2oe4z4og5/dI20O6hM3Rl+LZumrwL5M97zF5GnvPjQ7zV0= X-Received: by 2002:a05:6512:64:: with SMTP id i4mr10936314lfo.55.1580706141560; Sun, 02 Feb 2020 21:02:21 -0800 (PST) MIME-Version: 1.0 References: <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> In-Reply-To: From: Eric Rescorla Date: Sun, 2 Feb 2020 21:01:45 -0800 Message-ID: To: Rob Sayre Cc: Daniel Migault , "" Content-Type: multipart/alternative; boundary="0000000000000ff396059da4d453" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 05:02:25 -0000 --0000000000000ff396059da4d453 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 2, 2020 at 7:40 PM Rob Sayre wrote: > On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault 40ericsson.com@dmarc.ietf.org> wrote: > >> >> On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote: >> >>> >>> >>> 1. TLS 1.3 takes the position that reuse is bad and that position >>> is for good reasons, so we shouldn't undercut it in a new >>> extension. >>> >>> > >> . Appendix C.4 discourages tickets re-use when Client tracking is a >> concern. The section uses SHOULD and not MUST. So, in fact, TLS 1.3 takes >> position this is not mandatory to renew tickets. >> > Somehow I didn't get Daniel's email, so responding to it here. C.4 is not conditional. It simply says "Clients SHOULD NOT reuse a ticket for multiple connections." My point is not that servers which do not renew are not compliant but rather that TLS 1.3 has taken the position that reuse is bad and therefore we should not add an extension to facilitate it. -Ekr > thanks, > Rob > --0000000000000ff396059da4d453 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 2, 2020 at 7:40 PM Rob Sa= yre <sayrer@gmail.com> wrote:=
On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault <danie= l.migault=3D40ericsson.com@dmarc.ietf.org> wrote:

On S= un, Feb 2, 2020 at 12:09 PM Eric Rescorla <ekr@rtfm.com> wrote:


1. TLS 1.3 takes = the position that reuse is bad and that position
=C2=A0 =C2=A0is for goo= d reasons, so we shouldn't undercut it in a new
=C2=A0 =C2=A0extensi= on.

=C2= =A0
. Appendix C.4 discourages tickets re-use = when Client tracking is a concern. The section uses SHOULD and not MUST. So= , in fact, TLS 1.3 takes position this is not mandatory to renew tickets.= =C2=A0

=
Somehow I didn't get Daniel's email, so responding to it= here.

C.4 is not conditional. It simply says &quo= t;Clients SHOULD NOT reuse a ticket for multiple connections." My poin= t is not that servers which do not renew are not compliant but rather that = TLS 1.3 has taken the position that reuse is bad and therefore we should no= t add an extension to facilitate it.

-Ekr

<= /div>

thanks,
Rob=C2=A0
--0000000000000ff396059da4d453-- From nobody Sun Feb 2 21:49:20 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85121208E9 for ; Sun, 2 Feb 2020 21:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 My1GYMyUDKOC for ; Sun, 2 Feb 2020 21:49:17 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020181208E6 for ; Sun, 2 Feb 2020 21:49:15 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 2111E38E68; Mon, 3 Feb 2020 00:49:15 -0500 (EST) Date: Mon, 3 Feb 2020 00:49:15 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20200203054915.GO49778@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 05:49:19 -0000 On Sun, Feb 02, 2020 at 09:01:45PM -0800, Eric Rescorla wrote: > My point is not that servers which do not renew are not compliant but > rather that TLS 1.3 has taken the position that reuse is bad and > therefore we should not add an extension to facilitate it. Re: C.4 Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of a ticket allows passive observers to correlate different connections. But ticket reuse is patently a win when connection correlation is an unavoidable and even desirable feature of the network relationship between the parties. Receiving MTAs strongly discriminate against direct-to-mx traffic from dynamic IPs. Sending MTAs on the public Internet strive to build up a positive IP reputation, and operators only reluctantly shift traffic to new addresses when the old must unavoidably be retired. There is simply ZERO benefit from ticket churn. Similar considerations apply in many other "fixed endpoint" deployments. What I hear TLS 1.3 telling me, is to eat the porridge, after all there are starving children in Africa, and I must set a good example lest they too refuse to eat. If so, it seems I must stuff my application full of unnecessary tickets, because someone somewhere might actually be a few tickets short... If so, this is regrettable. -- Viktor. From nobody Sun Feb 2 21:55:19 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D20A1208EB for ; Sun, 2 Feb 2020 21:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 ztZ-SALSwt6M for ; Sun, 2 Feb 2020 21:55:15 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9174F1208E7 for ; Sun, 2 Feb 2020 21:55:15 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id p8so11538965iln.12 for ; Sun, 02 Feb 2020 21:55:15 -0800 (PST) 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=2ahYh8x+3Q0Dmyl20R1ftHKTmW03pOvpsFVNtE6ChRA=; b=s5d2FNf/KLA93WE07cuJWvllBpgLXOhj7mUz2198wUu1+lDBaOcos9mxn+oeq0/Y9L ER/zaZRMRSefZZ9vOgLA8Ci5fcF6PCh8N743jUepgBPLBMb88IRxQQhYvOJ2nxhcSdp2 ga7EYg5JBizP6qq8FeV74aYsK9F3O+hbrgAfrHwpQy9oNNv1fcfx2xjqrZjtymVfTbTS 1wkJG33gmXVqOFX8Tvv1ZjZQUurbzkoG9cr+/BlAm+gDsXyHpCa9O8bGqhjlzxgkT95A U+QPtuZrNdHPeHXtK7CDFBjk6YlvNE6r5k9Ip9tctkwr+arYZ7oxWh88K4buiEOcW/Ab NwRQ== 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=2ahYh8x+3Q0Dmyl20R1ftHKTmW03pOvpsFVNtE6ChRA=; b=qjWr070XUO4DoExHce8V1ZdPdlxEAIx6TH78oEKnfgCbOf8EwMfAeft6uP7LonmLQI Yt14CZ3KOudatn6bWE99zjCpJ2e6891YEzLRsDzdw7DQZo1HPAd2eoPy7j8Xkj7nZ0d0 kj++caw6pwaCid3dKkbUopstSDMCAf91pE44i3WO73GHjEWPyr52twWB8egUgiJ5T18D 0JWd2WvdUG3F/XLQ+JhVzmdNoICJEGUaLlMwXnvA6ixjUML0VmqRV7zNzslo6SNx4lGc MWa7K4sM4VEpANaOXe7mcnhlagXkAw5ZGnQFeffMb3grlRPveRHTy6Kk6Z2385WNPC0o lssQ== X-Gm-Message-State: APjAAAXiYs856DhXYpJedx6fo4DnDTd/Vf3cugKnuuwmmiYoRyES7lY1 WzGcl5YxtG7VjksrY+4XB39jKs7usJRsK37x/KR8WRPV X-Google-Smtp-Source: APXvYqxyU7Xm6OomEVshnZzO77s8FhGgx4G0tYvnrRw3HeEpdaRgr8jM0rqZAMDn+qAtc9gWS4D3d5MvZsCD8U5jRVU= X-Received: by 2002:a92:5845:: with SMTP id m66mr13925428ilb.257.1580709314438; Sun, 02 Feb 2020 21:55:14 -0800 (PST) MIME-Version: 1.0 References: <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> <20200203054915.GO49778@straasha.imrryr.org> In-Reply-To: <20200203054915.GO49778@straasha.imrryr.org> From: Rob Sayre Date: Sun, 2 Feb 2020 21:55:03 -0800 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002e2bd4059da59183" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 05:55:17 -0000 --0000000000002e2bd4059da59183 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 2, 2020 at 9:49 PM Viktor Dukhovni wrote: > > What I hear TLS 1.3 telling me, is to eat the porridge, after all there > are starving children in Africa, and I must set a good example lest they > too refuse to eat. > > I do not understand this point. > If so, it seems I must stuff my application full of unnecessary tickets, > I don't this is the case. thanks, Rob --0000000000002e2bd4059da59183 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Feb 2, 2020 at 9:49 PM Viktor Duk= hovni <ietf-dane@dukhovni.org<= /a>> wrote:

What I hear TLS 1.3 telling me, is to eat the porridge, after all there
are starving children in Africa, and I must set a good example lest they too refuse to eat.


--0000000000002e2bd4059da59183-- From nobody Mon Feb 3 09:04:37 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4075120B72 for ; Mon, 3 Feb 2020 09:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 whQjn9fKBKwD for ; Mon, 3 Feb 2020 09:04:32 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9353D1209EA for ; Mon, 3 Feb 2020 09:04:31 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id c84so76292wme.4 for ; Mon, 03 Feb 2020 09:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jeUBVvE9cYZJO87BEuGT9LDMBk9jHg+lNnymiRgKOeE=; b=T5+8FC4wSLkOAfSse7N4ZHm1kwvHPyLx5zDsPPijII9cmycr5BnpMvK8yJ/JG5YyvZ wOGJ5wYuV95IfgfDV1T8seUYypIEbNlmhPH7JFhI8ZEiidLY+5MT4COWDhiE5zybuffP UWe7XK8zw29wrfRFUiDkQ0QgMGf+nNApbzhor0NsOcnNta0Esg2u6RnSOg2axGZOlOxi fRNqYWw5ZL1q2UBGzXXsGyGWoI7iEQ89QwSjtByRFjcKh9G22cDohothiZynFYKYASRz nzpHVdhNR+PGB9xNMulBLeWsNySaNvxZcBjv5CwmUjr76e6t7/1tFB3390fyYXvDvJNd 2etg== 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=jeUBVvE9cYZJO87BEuGT9LDMBk9jHg+lNnymiRgKOeE=; b=r+2Hw5E7zjiz757fAP0LFE195HYeD2eSrkCWFQMB1dBdsA1NDSFoHxdDwdNTLhiW2w jSVd5HM4dSN3qVLLS7U43tODakZ/BiQmzLmYnOaGmEBgOwwKhpqf3qdIEiKVF00Av3r7 ggEi7b8EBlnyh4OZ+itjI4/W6/qzGtk4g04xadWPb5CztIsiH7+BzDkn0+sXiYqXW6eS xtcco2xpm0F5gV5H6T495QM8fQZgdlHqkEHwg5MeeXE7yPtqBoQjBDv9X+RNjXECOCW4 VdShQ5fTdRZPk2+ZnsugF/ogQbvDqwcCSXrKjRn4u/yxivN4pkvpjIx01H29PvmWmq2n enOg== X-Gm-Message-State: APjAAAX+WbWAPSWgjmGGkA0NVlmQ8jrt0zhdBA+Th41vZwxmfbTiOkeQ bjKXYGo8QxK2Kbgj/GREMI/Yj+i/kC6dX4lZXoYZoQ== X-Google-Smtp-Source: APXvYqx3Wrb/Uyv8F7aENbfApfYhdiUk2WwMqgTSQBS2+e/vHm5Pzs34dmm+07yl/xJLY/4f02HzMoXdM2GfCiOoAnw= X-Received: by 2002:a1c:9897:: with SMTP id a145mr32935wme.132.1580749469604; Mon, 03 Feb 2020 09:04:29 -0800 (PST) MIME-Version: 1.0 References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> <20200202175309.GL49778@straasha.imrryr.org> <53913E7D-765D-473B-980D-088F3D9D0C4D@apple.com> <7CAD8A81-2B5B-4730-ADCD-73F81A6D5DCF@apple.com> In-Reply-To: <7CAD8A81-2B5B-4730-ADCD-73F81A6D5DCF@apple.com> From: Ben Schwartz Date: Mon, 3 Feb 2020 12:04:18 -0500 Message-ID: To: Tommy Pauly Cc: "" , Viktor Dukhovni Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000a77f83059daeea83" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 17:04:35 -0000 --000000000000a77f83059daeea83 Content-Type: multipart/alternative; boundary="0000000000009db3b0059daeea64" --0000000000009db3b0059daeea64 Content-Type: text/plain; charset="UTF-8" > E. Multiple Ticket Reuse: Client want separate tickets for concurrent connections, that are later reused > Viktor described a case in which a client is split across multiple processes, so could be convenient to have independent tickets that are all retrieved from an initial connection that requested multiple handshakes, but the individual processes would want to treat those tickets as reusable until the server deleted the session. This case would want to both be able to request multiple tickets, and signal that reuse is possible. What is reuse allowing us to optimize in this case? If each process has its own ticket cache, then reuse doesn't reduce inter-process overhead, so what is the resource we are trying to economize? --0000000000009db3b0059daeea64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> E. Multiple Ticket Reuse: Client want separate ticket= s for concurrent connections, that are later reused
> Viktor describe= d a case in which a client is split across multiple processes, so could be = convenient to have independent tickets that are all retrieved from an initi= al connection that requested multiple handshakes, but the individual proces= ses would want to treat those tickets as reusable until the server deleted = the session. This case would want to both be able to request multiple ticke= ts, and signal that reuse is possible.

What is reuse all= owing us to=C2=A0optimize in this case?=C2=A0 If each process has its own t= icket cache, then reuse doesn't reduce inter-process overhead, so what = is the resource we are trying to economize?
--0000000000009db3b0059daeea64-- --000000000000a77f83059daeea83 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCBLgvA/35yL10c6QXA0AQd6GbogEOomJDGuA6dXnKakDAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMDMxNzA0MzBaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEATaGl8p+RYAwFEuPOqJrQ1WNBrywnyl2Bo+P/KIw1B1acRVPPyQJIsit15jKIxJJq1l8e9Viu XV6RQrK45Zh2MuGwrnkZOT3imyKNLtpNwcjmzwkDg2pTs16KkJEpWLwdFnmotMl4wTCAsFYgw7Zz HAUVvP6IhebujR4HkG66YKEGk6e+edhbU51N0Sv6cXHV6lE/DIPJy3FgUWXLAatnYg/DzLuaceM3 gUzI5Hj78olGkkqrP6wn+Aij63+8qxK7JI56mE3Xgfq4Tk1CHlQfOU56AWP3Vwk2dzBDTSXANsfw BikzQmHU4CNfmFdiYr0mKyywfsJNi2BZzCq4tP4U2w== --000000000000a77f83059daeea83-- From nobody Mon Feb 3 10:35:03 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F641209EA for ; Mon, 3 Feb 2020 10:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 66CAdkBg5HU5 for ; Mon, 3 Feb 2020 10:34:58 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5511E120A90 for ; Mon, 3 Feb 2020 10:34:58 -0800 (PST) Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id A58B039AB2 for ; Mon, 3 Feb 2020 13:34:57 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 3 Feb 2020 13:34:57 -0500 Content-Transfer-Encoding: 7bit Reply-To: IETF TLS WG Message-Id: <83175EE9-EFBF-4182-90EF-84FCAC127260@dukhovni.org> References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> <20200202175309.GL49778@straasha.imrryr.org> <53913E7D-765D-473B-980D-088F3D9D0C4D@apple.com> <7CAD8A81-2B5B-4730-ADCD-73F81A6D5DCF@apple.com> To: IETF TLS WG X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 18:35:02 -0000 > On Feb 3, 2020, at 12:04 PM, Ben Schwartz wrote: > > What is reuse allowing us to optimize in this case? If each process has > its own ticket cache, then reuse doesn't reduce inter-process overhead, > so what is the resource we are trying to economize? The processes do not have their own ticket caches. They are SMTP delivery agents, that deliver messages to whatever destination is next to receive email, and don't keep any state between messages. The session cache is shared across processes. -- Viktor. From nobody Mon Feb 3 10:40:04 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DDA1200B7 for ; Mon, 3 Feb 2020 10:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 kgPsdqD04y3U for ; Mon, 3 Feb 2020 10:40:01 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB0F12003F for ; Mon, 3 Feb 2020 10:40:00 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id j104so19614994wrj.7 for ; Mon, 03 Feb 2020 10:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=C4BLpEl/3WE2i3D3Qen568BylZdPx1IcTSd/V9NkIYU=; b=mnyGLcI1/TTO0QE6fGO6ZSxuBt5S/YFAWHy/mumqzryMwRI50OkhDXYQfbPr6VqZJm w8udOmzA6bTPDs2TLB0iXH6s4prUImZI+jilbnpIIUTwB77ozdpdocfsz6tdTM65bReD 9UOPekD1FRFTXzGZlUDOXqO3iXuCNdIR1y0D96UWo+y9dDm5lBHQnRv3Sbw5qR0fdi34 CO6OPXl+P8148dy4ReN8CoU698OliJzwa2PYcvC6XwvmcGCWs50lJMYY6kLzrc95Zsmm o+0zUBzLrTJU6WmdPB4Gw2MAYfr8qsa8b7UxMnFK7CuPoDKXr32spw6HSGEsOGnLgrE/ ViQg== 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=C4BLpEl/3WE2i3D3Qen568BylZdPx1IcTSd/V9NkIYU=; b=Yv6KwvaYdzcQj4htbYq7oftPJUditJxbJ8E/VNAyClbkHRKpIZyg4GuF8ka0kRV4rF Q+TR9/9tInWsvj5PKnXbv8QjK3d6mZqosezx2GYpaMpp6es/aehri8iQQGUzWKpZ3i2v TimvzMLL/wcJOcSCBtbS3IehMY8sVc3qIEgXZ/F1nf8mixjh+PivK7sMByBpRe1at+ot +wVh6OFBhTFy/U6Mcav+z+kc8/kJxn0Q1+SrHKK18Gy+JTj5M479ijIPcbXhtRbIdhnk 78kteF7c+jSTkrikMfNicWlp9ZErLhODsw2GeN6o0Kae+apdGOxIlttSr4E+Nm3IbQoH Z0cA== X-Gm-Message-State: APjAAAW2DbS9i9mAC+nuHSO/35ixyP0/MKBSbfpkVjXOCmEET929DzGk liI3N1hN/2Wd5c2R7CRsUR/Ce3yR91BjdY7iaJOk5t7c X-Google-Smtp-Source: APXvYqxkSyrikzUlyvdb6WNInhOD3NJ3pXGqc4SAd9WB46s0K5mP6BEb6IXFfat3W/vgAt0z8Ga35AmM8g2dbT3OOv4= X-Received: by 2002:adf:ffc7:: with SMTP id x7mr16660720wrs.159.1580755198971; Mon, 03 Feb 2020 10:39:58 -0800 (PST) MIME-Version: 1.0 References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> <20200202175309.GL49778@straasha.imrryr.org> <53913E7D-765D-473B-980D-088F3D9D0C4D@apple.com> <7CAD8A81-2B5B-4730-ADCD-73F81A6D5DCF@apple.com> <83175EE9-EFBF-4182-90EF-84FCAC127260@dukhovni.org> In-Reply-To: <83175EE9-EFBF-4182-90EF-84FCAC127260@dukhovni.org> From: Ben Schwartz Date: Mon, 3 Feb 2020 13:39:47 -0500 Message-ID: To: IETF TLS WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000249c7b059db0407c" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 18:40:03 -0000 --000000000000249c7b059db0407c Content-Type: multipart/alternative; boundary="0000000000001ccd3d059db0404d" --0000000000001ccd3d059db0404d Content-Type: text/plain; charset="UTF-8" On Mon, Feb 3, 2020 at 1:35 PM Viktor Dukhovni wrote: > > On Feb 3, 2020, at 12:04 PM, Ben Schwartz wrote: > > > > What is reuse allowing us to optimize in this case? If each process has > > its own ticket cache, then reuse doesn't reduce inter-process overhead, > > so what is the resource we are trying to economize? > > The processes do not have their own ticket caches. They are SMTP > delivery agents, that deliver messages to whatever destination > is next to receive email, and don't keep any state between > messages. I thought in Case E the goal was that each delivery agent keeps its ticket as persistent per-process state, to avoid re-querying the global cache. > The session cache is shared across processes. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001ccd3d059db0404d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> On Feb 3, 2020, at 12:04 PM, Ben Schwartz &l= t;bemasc@google.com<= /a>> wrote:
>
> What is reuse allowing us to optimize in this case?=C2=A0 If each proc= ess has
> its own ticket cache, then reuse doesn't reduce inter-process over= head,
> so what is the resource we are trying to economize?

The processes do not have their own ticket caches.=C2=A0 They are SMTP
delivery agents, that deliver messages to whatever destination
is next to receive email, and don't keep any state between
messages.

=C2=A0 The session cache is shared acro= ss processes.

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000001ccd3d059db0404d-- --000000000000249c7b059db0407c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCnTc6/t3xm357NnRJh5cNICh6QYca1RBxYftZKxjZYmzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMDMxODM5NTlaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAZOZrtGd43BATff91fsbnryIzCp9zIbwy+pOW/QZpnU5sL0OlGQvROIKLQU1EwTpEAy3ZSSDE EDP7xBZprkUoUYh0SjgK2Epcd3nVke8/50/+ztdH8nFjHwkojxgfWWFLk2NDkO4JvJsFr8x35WmO uJxHlOeuybDZxJVDak9SwIRPw6HhqGV8Z0WjeiE2lzYWl4OGat3p1OCmp1RJ/ux35iHs5kqHe2L5 ks0delN9Ql6LlmYS0Z4fqz6xkeCpKrKUm3RRLF4MqJTNiDPPzpYtu2NFi3NVFAg0rgvjZFLhDRWH 0ZUzaLxyy4tReECioQuFFuTh7OLwvR24AHgmyRt8ow== --000000000000249c7b059db0407c-- From nobody Mon Feb 3 10:50:29 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A10212003F for ; Mon, 3 Feb 2020 10:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 Sek8cBriJkel for ; Mon, 3 Feb 2020 10:50:26 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199491200B4 for ; Mon, 3 Feb 2020 10:50:19 -0800 (PST) Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 7F05439AF5 for ; Mon, 3 Feb 2020 13:50:18 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 3 Feb 2020 13:50:18 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: IETF TLS WG Message-Id: <7EE22630-F800-4C85-B3B6-DC6A2509CE62@dukhovni.org> References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> <20200202175309.GL49778@straasha.imrryr.org> <53913E7D-765D-473B-980D-088F3D9D0C4D@apple.com> <7CAD8A81-2B5B-4730-ADCD-73F81A6D5DCF@apple.com> <83175EE9-EFBF-4182-90EF-84FCAC127260@dukhovni.org> To: IETF TLS WG X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 18:50:28 -0000 > On Feb 3, 2020, at 1:39 PM, Ben Schwartz = wrote: >=20 > I thought in Case E the goal was that each delivery agent keeps its = ticket as > persistent per-process state, to avoid re-querying the global cache. I don't recall discussing such a scenario. In Postfix the cache is = shared. There is not sufficient process affinity to particular destinations to make such a cache design be viable, and the processes have limited lifetimes, with new ones spawned as needed. So whatever E might be, a per-process cache is not the use-case I'm working with. I'll read the post more closely over the next few days and attempt to summarize where I think we are, and propose a pull request to at least clarify the issues that motivate potential tweaks to the design. We're starting to lose focus, and I think something more concrete in writing will help. --=20 Viktor. From nobody Mon Feb 3 14:07:28 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E420712082F for ; Mon, 3 Feb 2020 14:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.398 X-Spam-Level: X-Spam-Status: No, score=-14.398 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=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=StMTlRia; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Cx0W7GwX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYSgHUyHieB6 for ; Mon, 3 Feb 2020 14:07:23 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A4212001E for ; Mon, 3 Feb 2020 14:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25596; q=dns/txt; s=iport; t=1580767642; x=1581977242; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Is1eEygIaAgReDSbiqqFACSOJhJd0ju/ZYWxNB+F7Nk=; b=StMTlRiaPwcau1DOFj0F3i1nD8TaYsuJC5h3rH/63liZx+Msx7KsqK5f 1aHUr8OH0ZtJmWYc8b3ZTqzb4Wc2nVWcZxKfnG4Ly0dNThbUYDGG5AyGc Or7Nxk88IAoFVmYM09k+4NI1j5XftU9uVLaUESU5FSt7JHfQ82gkBABB1 Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AwmJH1xHtC5Fzt2+0L7xJ9J1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efnkdS03GOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQDemDhe/5pdJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gSUvUAVsWCAECyoKhAqDRgOKeYJfiWGJTIR?= =?us-ascii?q?iglIDVAkBAQEMAQEYAQkLAgEBgWOCXQIXgh0kOBMCAw0BAQQBAQECAQUEbYU?= =?us-ascii?q?3DIVmAQEBAQMBARARChMBAQccBgMLAQ0CAgEGAg4DBAEBAScDAgICGQYGCxQ?= =?us-ascii?q?JCAIEAQ0FCBqCfwQCgX1NAy4BAgyRMpBmAoE5iGJ1gTKCfwEBBYEvAYNvAwo?= =?us-ascii?q?LggwJBYEzhR6FZIEeGoFBPyZrR4JMPoIbSQEBAhqBSwoLFgkIglIygiyNRiI?= =?us-ascii?q?IH4JIhWCJeY5yRAqCO4dGhUeFCYRFgkiIDpAyjmGIZ4IokAsCBAIEBQIOAQE?= =?us-ascii?q?FgWkiDYFLcBU7gmwJCj0YDY4dg3ODEoIChT90AgEBAYEkjFABgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,398,1574121600"; d="scan'208,217";a="701395598" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Feb 2020 22:07:20 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 013M7KJ5020512 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Feb 2020 22:07:20 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Feb 2020 16:07:20 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Feb 2020 16:07:19 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 3 Feb 2020 16:07:19 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JEH8ocYCUgVAOYgNbZG7e5SVouXB37OqVZIS+qhPywYvVp989bQCC1ykwzCm67mAE3ZNGtKB533l7cDVUTevJtnCKUTu5FixJB0Ura2tpSjYdrtrFdZE8QEuAA2F1MjULFiOza3sH9s9wqMwvP314JjzSD1QqOuRGwrrb4HcUq02ZKJKi0HzitzonYeleOsZs7ZULJ24rHrHtzVWGNF6wxktYJU60wSWTg8r0EhgBUmIZvOx6sSr6liHCKpuot/RO0k8RbvEq6vrJq/BPpLuCa6ElZxf9k30FIhvHKlnQcAGIj7F7ISwzM7406D6w+ZwNrblD6sqvkuxsF+69yZ/0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Is1eEygIaAgReDSbiqqFACSOJhJd0ju/ZYWxNB+F7Nk=; b=V2tLXmqc6MvFG95cAQbUNtHcJJoZ3D8K2kYLN4qVD/mbTPyXNXLuAZfPplbTGUsjgIfbNfjOx84HE4ia1JpHDLmgUCyUUBUn7gM6vWCnsTzOhyrVKr5JjJMOq5D81ZXhrgX7/XnbzHehIh4oIt/NwpujEQY76mizfOH3uMRE34Z18Gltcp3wWwYJiuP0MkkRZgJuE9xWm9HVt0/wsQNNV+lSlIInzDhoWUyxrYWMoBYdXtWqzUesYVfT2SzXiauNm6wkHhxICKE7EKHxqwqLoR8JOKrH3+lCL0Rrc7poKdyE0Qe2WC70hpvTALerKQqSSe1MBeH7OwA1JyhGCW6bnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Is1eEygIaAgReDSbiqqFACSOJhJd0ju/ZYWxNB+F7Nk=; b=Cx0W7GwXXQz9olXAT3Qz2DoGEkf+7fyehEwuRgqtcyz5yA4WXMPthNPgCRjbLmzylc/Gy8XVuHAVnlJ+U2X2OmUhTIyh1BNIYUHM9ZZ91uhWhZGrI+7x+kE1ibAY3OopOjSio1qI2I25hqrCB3WpPJRBi7lTUdRNNlQDrDPUCYc= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3629.namprd11.prod.outlook.com (20.178.252.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Mon, 3 Feb 2020 22:07:18 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::d1b8:3e63:ead8:10c9]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::d1b8:3e63:ead8:10c9%7]) with mapi id 15.20.2686.031; Mon, 3 Feb 2020 22:07:18 +0000 From: "Owen Friel (ofriel)" To: Eric Rescorla , Jonathan Hoyland CC: =?utf-8?B?QmrDtnJuIEhhYXNl?= , TLS List , Mohit Sethi M Thread-Topic: [TLS] External PSK design team Thread-Index: AQHV0A95AGHaXgezM0iEtJyKwXOzXaf0mHUAgABGWACAAAIEgIAAA08AgAAMuQCAAEPNAIAU550w Date: Mon, 3 Feb 2020 22:07:18 +0000 Message-ID: References: <6b080bb0-bdb5-c424-c6c8-596fbeadb588@ericsson.com> <815ea7c9-b0ce-b0e3-3763-1cda6fe1b5b0@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [173.38.220.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 03492361-52d6-4ded-612a-08d7a8f56f73 x-ms-traffictypediagnostic: MN2PR11MB3629: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(39860400002)(366004)(396003)(346002)(189003)(199004)(86362001)(45080400002)(66574012)(8936002)(966005)(2906002)(9686003)(66946007)(26005)(4326008)(478600001)(316002)(76116006)(7696005)(66446008)(6506007)(66556008)(33656002)(64756008)(8676002)(81166006)(81156014)(5660300002)(186003)(66476007)(54906003)(71200400001)(55016002)(53546011)(52536014)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3629; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jVYbsqrKLIOivDmxrODTa0LSSan1mD2GDyq10jPu8Vtd6eiL1bH44y4xt1nZktUuQib9ovcnz2OO2D0kqclFQmMUpAKHTQFMtuh4NpueNuJTO9XrnMN/a0LM6/9qzny6QLKHUR1/0Lug+5uAEV7Ah6ljosn3mMKszFQzT9vkDPzwEO6E45XUrxEfYEJqGfjQjyVyiWTV/N0KKoYJQchR7MlNOYdOd5uMPPks0BIRcVDHvACpzgifu8glThFrGI2PAaxuH8K1aKO6E7/LQU3fDTHDPUFsnMMD4GWnaWaahoCazPhGuYugYyf5h0u/a+eQmp2qJDHVmKLwlJnGAh/wDmqgQz554xowx9cDrompXfQ31EE0C4pQeSw0BgIYJoWBobQeyXh4df7OWZSeak9tILDKKP2B9O+ns+mtbuaemQ3BO6qZEpgRVUAOA51ooIBtGtgA7L4KlDuk7HJsyct7NQz+aOxOl+L/DoYsD1wnCOQ1qG356yCF1zAtyz7USiR3qu/hD9Xwf7V45fq3ULsVvw== x-ms-exchange-antispam-messagedata: BTzJ+sO1RVL8LSTGT5Lpb0BcJ2KWIvsr69G6ErmnIkLFdzKzNOzMnekhrBoMiwvBNzOsqn+M0QJoq+rf5mwvdCP4hSjA2kpG7xvlJ9ytzpzLcNPX1cHVEoqnKeDx063Z3y09d6WIMh1hw+8Bj4q3lQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3901FCD4796FA9C921BC32D0DB000MN2PR11MB3901namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 03492361-52d6-4ded-612a-08d7a8f56f73 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 22:07:18.4961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hWmZprVcW0sNR+MLAelPJdlK/Q0axFuP3QzMFHmJAOw20pI/xuCwjfKHk6g9RLHDdidXAyJ4ymSs2UV/SqPZ8g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3629 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [TLS] External PSK design team X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:07:27 -0000 --_000_MN2PR11MB3901FCD4796FA9C921BC32D0DB000MN2PR11MB3901namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gYWxzbyBpbnRlcmVzdGVkIGluIGhlbHBpbmcgaGVyZSBmb3IgcG90ZW50aWFsIGFwcGxp Y2FiaWxpdHkgZm9yIElvVCBkZXZpY2Ugb25ib2FyZGluZy4NCg0KRnJvbTogVExTIDx0bHMtYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IDIxIEphbnVh cnkgMjAyMCAxNDo1Mg0KVG86IEpvbmF0aGFuIEhveWxhbmQgPGpvbmF0aGFuLmhveWxhbmRAZ21h aWwuY29tPg0KQ2M6IEJqw7ZybiBIYWFzZSA8YmpvZXJuLmhhYXNlQGVuZHJlc3MuY29tPjsgVExT IExpc3QgPHRsc0BpZXRmLm9yZz47IE1vaGl0IFNldGhpIE0gPG1vaGl0Lm0uc2V0aGk9NDBlcmlj c3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gRXh0ZXJuYWwgUFNL IGRlc2lnbiB0ZWFtDQoNCkkgYW0gd2lsbGluZyB0byBjb250cmlidXRlLg0KDQotRWtyDQoNCg0K T24gVHVlLCBKYW4gMjEsIDIwMjAgYXQgMjo1MCBBTSBKb25hdGhhbiBIb3lsYW5kIDxqb25hdGhh bi5ob3lsYW5kQGdtYWlsLmNvbTxtYWlsdG86am9uYXRoYW4uaG95bGFuZEBnbWFpbC5jb20+PiB3 cm90ZToNCkhpIEFsbCwNCg0KVGhpcyBpcyBzb21ldGhpbmcgSSdtIHZlcnkgaW50ZXJlc3RlZCBp bi4NCg0KRGVmaW5pdGVseSB3YW50IHRvIHBhcnRpY2lwYXRlLg0KDQpSZWdhcmRzLA0KDQpKb25h dGhhbg0KDQpPbiBUdWUsIDIxIEphbiAyMDIwIGF0IDEwOjA0LCBNb2hpdCBTZXRoaSBNIDxtb2hp dC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGVyaWNzc29u LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSSB3b3VsZCBsZXQgQ0ZSRyBkZWFsIHdpdGgg dGhlIFBBS0Ugc2VsZWN0aW9uIHByb2Nlc3M6DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL2NmcmcvLWExc1czaktfNWF2bWI5OHptRmJDTkxtcEFzDQphbmQgbm90IGhhdmUg dGhpcyBkZXNpZ24gdGVhbSBzcGVuZCB0aW1lIGFuZCBlbmVyZ3kgb24gZGVzaWduaW5nIFBBS0Vz Lg0KDQotLU1vaGl0DQoNCk9uIDEvMjEvMjAgMTE6NTIgQU0sIEJqw7ZybiBIYWFzZSB3cm90ZToN Cj4gSGVsbG8gdG8gYWxsLA0KPg0KPiBJIGFtIGFsc28gd2lsbGluZyB0byBjb250cmlidXRlLiBN eSBjb25jZXJuIGlzIHRoYXQgSSBvYnNlcnZlIHRoYXQgaW4gc29tZSBpbmR1c3RyaWFsIGNvbnRy b2wgYXBwbGljYXRpb25zLCBQU0sgbWVjaGFuaXNtcyAodGhhdCBhY3R1YWxseSByZXF1aXJlIGhp Z2gtZW50cm9weSBrZXlzKSBhcmUgKG1pcyktdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIFRMUywg d2hlcmUgdGhlIFBTSyBpcyBhY3R1YWxseSBvZiBpbnN1ZmZpY2llbnQgZW50cm9weSAobWF5YmUg ZGVyaXZlZCBvbmx5IGZyb20gYSA0IGRpZ2l0IFBJTikuDQo+DQo+IEluIG9yZGVyIHRvIGZpeCB0 aGlzIGlzc3VlLCBJJ2QgcmVhbGx5IGFwcHJlY2lhdGUgdG8gaGF2ZSBhbiBQU0stc3R5bGUgVExT IG9wZXJhdGlvbiB1c2luZyBhIGJhbGFuY2VkIFBBS0UgKG5vdGUgdGhhdCB0aGlzIGNvdWxkIGJl IGltcGxlbWVudGVkIHdpdGggdmlydHVhbGx5IG5vIGNvbXB1dGF0aW9uYWwgb3ZlcmhlYWQgaW4g Y29tcGFyaXNvbiB0byBjb252ZW50aW9uYWwgRUNESCBzZXNzaW9uIGtleSBnZW5lcmF0aW9uKS4N Cj4NCj4gWW91cnMsDQo+DQo+IEJqw7Zybi4NCj4NCj4NCj4NCj4gTWl0IGZyZXVuZGxpY2hlbiBH csO8w59lbiBJIEJlc3QgUmVnYXJkcw0KPg0KPiBEci4gQmrDtnJuIEhhYXNlDQo+DQo+DQo+IFNl bmlvciBFeHBlcnQgRWxlY3Ryb25pY3MgfCBUR1JFSCBFbGVjdHJvbmljcyBIYXJkd2FyZQ0KPiBF bmRyZXNzK0hhdXNlciBDb25kdWN0YSBHbWJIK0NvLktHIHwgRGllc2Vsc3RyYXNzZSAyNCB8IDcw ODM5IEdlcmxpbmdlbiB8IEdlcm1hbnkNCj4gUGhvbmU6ICs0OSA3MTU2IDIwOSAzNzcgfCBGYXg6 ICs0OSA3MTU2IDIwOSAyMjENCj4gYmpvZXJuLmhhYXNlQGVuZHJlc3MuY29tPG1haWx0bzpiam9l cm4uaGFhc2VAZW5kcmVzcy5jb20+IHwgIHd3dy5jb25kdWN0YS5lbmRyZXNzLmNvbTxodHRwOi8v d3d3LmNvbmR1Y3RhLmVuZHJlc3MuY29tPg0KPg0KPg0KPg0KPg0KPg0KPiBFbmRyZXNzK0hhdXNl ciBDb25kdWN0YSBHbWJIK0NvLktHDQo+IEFtdHNnZXJpY2h0IFN0dXR0Z2FydCBIUkEgMjAxOTA4 DQo+IFNpdHogZGVyIEdlc2VsbHNjaGFmdDogR2VybGluZ2VuDQo+IFBlcnPDtm5saWNoIGhhZnRl bmRlIEdlc2VsbHNjaGFmdGVyaW46DQo+IEVuZHJlc3MrSGF1c2VyIENvbmR1Y3RhIFZlcndhbHR1 bmdzZ2VzZWxsc2NoYWZ0IG1iSA0KPiBTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IEdlcmxpbmdlbg0K PiBBbXRzZ2VyaWNodCBTdHV0dGdhcnQgSFJBIDIwMTkyOQ0KPiBHZXNjaMOkZnRzZsO8aHJlcjog RHIuIE1hbmZyZWQgSmFnaWVsbGENCj4NCj4NCj4gR2Vtw6RzcyBEYXRlbnNjaHV0emdydW5kdmVy b3JkbnVuZyBzaW5kIHdpciB2ZXJwZmxpY2h0ZXQsIFNpZSB6dSBpbmZvcm1pZXJlbiwgd2VubiB3 aXIgcGVyc29uZW5iZXpvZ2VuZSBEYXRlbiB2b24gSWhuZW4gZXJoZWJlbi4NCj4gRGllc2VyIElu Zm9ybWF0aW9uc3BmbGljaHQga29tbWVuIHdpciBtaXQgZm9sZ2VuZGVtIERhdGVuc2NodXR6aGlu d2VpcyAoaHR0cHM6Ly93d3cuZW5kcmVzcy5jb20vZGUvY29va2llcy1lbmRyZXNzK2hhdXNlci13 ZWJzaXRlKSBuYWNoLg0KPg0KPg0KPg0KPg0KPg0KPiBEaXNjbGFpbWVyOg0KPg0KPiBUaGUgaW5m b3JtYXRpb24gdHJhbnNtaXR0ZWQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBl bnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwsIHByb3ByaWV0YXJ5LCBhbmQvb3IgcHJpdmlsZWdlZCBtYXRlcmlhbC4gQW55IHJldmlldywg cmV0cmFuc21pc3Npb24sIGRpc3NlbWluYXRpb24gb3Igb3RoZXIgdXNlIG9mLCBvciB0YWtpbmcg b2YgYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9uLCB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNv bnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hp Yml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgaW4gZXJyb3IsIHBsZWFzZSBjb250YWN0IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWF0ZXJpYWwgZnJvbSBhbnkgY29tcHV0ZXIuIFRoaXMgZS1t YWlsIGRvZXMgbm90IGNvbnN0aXR1dGUgYSBjb250cmFjdCBvZmZlciwgYSBjb250cmFjdCBhbWVu ZG1lbnQsIG9yIGFuIGFjY2VwdGFuY2Ugb2YgYSBjb250cmFjdCBvZmZlciB1bmxlc3MgZXhwbGlj aXRseSBhbmQgY29uc3BpY3VvdXNseSBkZXNpZ25hdGVkIG9yIHN0YXRlZCBhcyBzdWNoLg0KPg0K Pg0KPg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogVExTIDx0 bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc+PiBJbSBBdWZ0 cmFnIHZvbiBNb2hpdCBTZXRoaSBNDQo+IEdlc2VuZGV0OiBEaWVuc3RhZywgMjEuIEphbnVhciAy MDIwIDEwOjQ1DQo+IEFuOiBDb2xtIE1hY0PDoXJ0aGFpZ2ggPGNvbG1AYWxsY29zdHMubmV0PG1h aWx0bzpjb2xtQGFsbGNvc3RzLm5ldD4+OyBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb208bWFp bHRvOnNlYW5Ac24zcmQuY29tPj4NCj4gQ2M6IFRMUyBMaXN0IDx0bHNAaWV0Zi5vcmc8bWFpbHRv OnRsc0BpZXRmLm9yZz4+DQo+IEJldHJlZmY6IFJlOiBbVExTXSBFeHRlcm5hbCBQU0sgZGVzaWdu IHRlYW0NCj4NCj4gSSBhbSBjZXJ0YWlubHkgaW50ZXJlc3RlZCBhbmQgd2lsbGluZyB0byBjb250 cmlidXRlLiBXZSBuZWVkIHNvbWUNCj4gY29uc2Vuc3VzIG9uIHdoZXRoZXIgUFNLcyBjYW4gYmUg c2hhcmVkIHdpdGggbW9yZSB0aGFuIDIgcGFydGllcywNCj4gd2hldGhlciB0aGUgcGFydGllcyBj YW4gc3dpdGNoIHJvbGVzLCBldGMuDQo+DQo+IEVNVSBpcyBnb2luZyB0byB3b3JrIG9uIEVBUC1U TFMtUFNLIGFuZCB0aGUgcXVlc3Rpb24gb2YNCj4gcHJpdmFjeS9pZGVudGl0aWVzIHdpbGwgcG9w LXVwIHRoZXJlIHRvby4NCj4NCj4gLS1Nb2hpdA0KPg0KPiBPbiAxLzIxLzIwIDc6MzMgQU0sIENv bG0gTWFjQ8OhcnRoYWlnaCB3cm90ZToNCj4+IEludGVyZXN0ZWQsIGFzIGl0IGhhcHBlbnMgLSB0 aGlzIGlzIHNvbWV0aGluZyBJJ3ZlIGJlZW4gd29ya2luZyBvbiBhdCBBbWF6b24uDQo+Pg0KPj4g T24gTW9uLCBKYW4gMjAsIDIwMjAgYXQgODowMSBQTSBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5j b208bWFpbHRvOnNlYW5Ac24zcmQuY29tPj4gd3JvdGU6DQo+Pj4gQXQgSUVURiAxMDYsIHdlIGRp c2N1c3NlZCBmb3JtaW5nIGEgZGVzaWduIHRlYW0gdG8gZm9jdXMgb24gZXh0ZXJuYWwgUFNLIG1h bmFnZW1lbnQgYW5kIHVzYWdlIGZvciBUTFMuIFRoZSBnb2FsIG9mIHRoaXMgdGVhbSB3b3VsZCBi ZSB0byBwcm9kdWNlIGEgZG9jdW1lbnQgdGhhdCBkaXNjdXNzZXMgY29uc2lkZXJhdGlvbnMgZm9y IHVzaW5nIGV4dGVybmFsIFBTS3MsIHByaXZhY3kgY29uY2VybnMgKGFuZCBwb3NzaWJsZSBtaXRp Z2F0aW9ucykgZm9yIHN0YWJsZSBpZGVudGl0aWVzLCBhbmQgbW9yZSBkZXZlbG9wZWQgbWl0aWdh dGlvbnMgZm9yIGRlcGxveW1lbnQgcHJvYmxlbXMgc3VjaCBhcyBTZWxmaWUuIElmIHlvdSBoYXZl IGFuIGludGVyZXN0IGluIHBhcnRpY2lwYXRpbmcgb24gdGhpcyBkZXNpZ24gdGVhbSwgcGxlYXNl IHJlcGx5IHRvIHRoaXMgbWVzc2FnZSBhbmQgc3RhdGUgc28gYnkgMjM1OSBVVEMgMzEgSmFudWFy eSAyMDIwLg0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+DQo+Pj4gSm9lIGFuZCBTZWFuDQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBUTFMgbWFp bGluZyBsaXN0DQo+Pj4gVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQo+Pj4gaHR0 cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGxzJmFtcDtkYXRhPTAy JTdDMDElN0Niam9lcm4uaGFhc2UlNDBlbmRyZXNzLmNvbSU3QzVhZjdmOWRjZDJmNzQ2YjY2Mzhh MDhkNzllNTZhN2RjJTdDNTJkYWYyYTkzYjczNGRhNGFjNmEzZjgxYWRjOTJiN2UlN0MxJTdDMCU3 QzYzNzE1MTk2NzMzMDI0NjU0NCZhbXA7c2RhdGE9eHR0JTJGMW14UzBYYnJUUThtRXhkelVQJTJG JTJCSFNKS3JYQU5zVnFzWCUyRjRzVVpBJTNEJmFtcDtyZXNlcnZlZD0wDQo+Pg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGluZyBs aXN0DQo+IFRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KPiBodHRwczovL2V1cjAz LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cu aWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0bHMmYW1wO2RhdGE9MDIlN0MwMSU3Q2Jq b2Vybi5oYWFzZSU0MGVuZHJlc3MuY29tJTdDNWFmN2Y5ZGNkMmY3NDZiNjYzOGEwOGQ3OWU1NmE3 ZGMlN0M1MmRhZjJhOTNiNzM0ZGE0YWM2YTNmODFhZGM5MmI3ZSU3QzElN0MwJTdDNjM3MTUxOTY3 MzMwMjQ2NTQ0JmFtcDtzZGF0YT14dHQlMkYxbXhTMFhiclRROG1FeGR6VVAlMkYlMkJIU0pLclhB TnNWcXNYJTJGNHNVWkElM0QmYW1wO3Jlc2VydmVkPTANCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8 bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K --_000_MN2PR11MB3901FCD4796FA9C921BC32D0DB000MN2PR11MB3901namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQt c3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SeKAmW0gYWxzbyBpbnRlcmVzdGVkIGluIGhlbHBpbmcgaGVyZSBmb3IgcG90ZW50aWFs IGFwcGxpY2FiaWxpdHkgZm9yIElvVCBkZXZpY2Ugb25ib2FyZGluZy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBUTFMgJmx0O3Rscy1ib3VuY2VzQGll dGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2Vu dDo8L2I+IDIxIEphbnVhcnkgMjAyMCAxNDo1Mjxicj4NCjxiPlRvOjwvYj4gSm9uYXRoYW4gSG95 bGFuZCAmbHQ7am9uYXRoYW4uaG95bGFuZEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBC asO2cm4gSGFhc2UgJmx0O2Jqb2Vybi5oYWFzZUBlbmRyZXNzLmNvbSZndDs7IFRMUyBMaXN0ICZs dDt0bHNAaWV0Zi5vcmcmZ3Q7OyBNb2hpdCBTZXRoaSBNICZsdDttb2hpdC5tLnNldGhpPTQwZXJp Y3Nzb24uY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RM U10gRXh0ZXJuYWwgUFNLIGRlc2lnbiB0ZWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPkkgYW0gd2lsbGluZyB0byBjb250cmlidXRlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tRWtyPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+T24gVHVlLCBKYW4gMjEsIDIwMjAgYXQgMjo1MCBBTSBKb25hdGhhbiBIb3lsYW5kICZs dDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW4uaG95bGFuZEBnbWFpbC5jb20iPmpvbmF0aGFuLmhv eWxhbmRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+SGkgQWxsLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+VGhpcyBpcyBzb21ldGhpbmcgSSdtIHZlcnkmbmJzcDtpbnRlcmVzdGVkIGluLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5E ZWZpbml0ZWx5IHdhbnQgdG8gcGFydGljaXBhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 YnI+DQpKb25hdGhhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5PbiBUdWUsIDIxIEphbiAyMDIwIGF0IDEwOjA0LCBNb2hpdCBTZXRoaSBNICZsdDtt b2hpdC5tLnNldGhpPTxhIGhyZWY9Im1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JIHdvdWxkIGxldCBDRlJHIGRlYWwg d2l0aCB0aGUgUEFLRSBzZWxlY3Rpb24gcHJvY2VzczoNCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY2ZyZy8tYTFzVzNqS181YXZtYjk4em1GYkNO TG1wQXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL2NmcmcvLWExc1czaktfNWF2bWI5OHptRmJDTkxtcEFzPC9hPg0KPGJyPg0KYW5kIG5vdCBo YXZlIHRoaXMgZGVzaWduIHRlYW0gc3BlbmQgdGltZSBhbmQgZW5lcmd5IG9uIGRlc2lnbmluZyBQ QUtFcy48YnI+DQo8YnI+DQotLU1vaGl0PGJyPg0KPGJyPg0KT24gMS8yMS8yMCAxMTo1MiBBTSwg QmrDtnJuIEhhYXNlIHdyb3RlOjxicj4NCiZndDsgSGVsbG8gdG8gYWxsLDxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgYW0gYWxzbyB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUuIE15IGNvbmNlcm4gaXMgdGhh dCBJIG9ic2VydmUgdGhhdCBpbiBzb21lIGluZHVzdHJpYWwgY29udHJvbCBhcHBsaWNhdGlvbnMs IFBTSyBtZWNoYW5pc21zICh0aGF0IGFjdHVhbGx5IHJlcXVpcmUgaGlnaC1lbnRyb3B5IGtleXMp IGFyZSAobWlzKS11c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggVExTLCB3aGVyZSB0aGUgUFNLIGlz IGFjdHVhbGx5IG9mIGluc3VmZmljaWVudCBlbnRyb3B5DQogKG1heWJlIGRlcml2ZWQgb25seSBm cm9tIGEgNCBkaWdpdCBQSU4pLjxicj4NCiZndDs8YnI+DQomZ3Q7IEluIG9yZGVyIHRvIGZpeCB0 aGlzIGlzc3VlLCBJJ2QgcmVhbGx5IGFwcHJlY2lhdGUgdG8gaGF2ZSBhbiBQU0stc3R5bGUgVExT IG9wZXJhdGlvbiB1c2luZyBhIGJhbGFuY2VkIFBBS0UgKG5vdGUgdGhhdCB0aGlzIGNvdWxkIGJl IGltcGxlbWVudGVkIHdpdGggdmlydHVhbGx5IG5vIGNvbXB1dGF0aW9uYWwgb3ZlcmhlYWQgaW4g Y29tcGFyaXNvbiB0byBjb252ZW50aW9uYWwgRUNESCBzZXNzaW9uIGtleSBnZW5lcmF0aW9uKS48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBZb3Vycyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBCasO2cm4uPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBNaXQgZnJldW5kbGljaGVuIEdy w7zDn2VuIEkgQmVzdCBSZWdhcmRzPGJyPg0KJmd0Ozxicj4NCiZndDsgRHIuIEJqw7ZybiBIYWFz ZTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZW5pb3IgRXhwZXJ0IEVsZWN0cm9uaWNz IHwgVEdSRUggRWxlY3Ryb25pY3MgSGFyZHdhcmU8YnI+DQomZ3Q7IEVuZHJlc3MmIzQzO0hhdXNl ciBDb25kdWN0YSBHbWJIJiM0MztDby5LRyB8IERpZXNlbHN0cmFzc2UgMjQgfCA3MDgzOSBHZXJs aW5nZW4gfCBHZXJtYW55PGJyPg0KJmd0OyBQaG9uZTogJiM0Mzs0OSA3MTU2IDIwOSAzNzcgfCBG YXg6ICYjNDM7NDkgNzE1NiAyMDkgMjIxPGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86YmpvZXJu LmhhYXNlQGVuZHJlc3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmpvZXJuLmhhYXNlQGVuZHJlc3Mu Y29tPC9hPiB8Jm5ic3A7DQo8YSBocmVmPSJodHRwOi8vd3d3LmNvbmR1Y3RhLmVuZHJlc3MuY29t IiB0YXJnZXQ9Il9ibGFuayI+d3d3LmNvbmR1Y3RhLmVuZHJlc3MuY29tPC9hPjxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBFbmRyZXNz JiM0MztIYXVzZXIgQ29uZHVjdGEgR21iSCYjNDM7Q28uS0c8YnI+DQomZ3Q7IEFtdHNnZXJpY2h0 IFN0dXR0Z2FydCBIUkEgMjAxOTA4PGJyPg0KJmd0OyBTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IEdl cmxpbmdlbjxicj4NCiZndDsgUGVyc8O2bmxpY2ggaGFmdGVuZGUgR2VzZWxsc2NoYWZ0ZXJpbjo8 YnI+DQomZ3Q7IEVuZHJlc3MmIzQzO0hhdXNlciBDb25kdWN0YSBWZXJ3YWx0dW5nc2dlc2VsbHNj aGFmdCBtYkg8YnI+DQomZ3Q7IFNpdHogZGVyIEdlc2VsbHNjaGFmdDogR2VybGluZ2VuPGJyPg0K Jmd0OyBBbXRzZ2VyaWNodCBTdHV0dGdhcnQgSFJBIDIwMTkyOTxicj4NCiZndDsgR2VzY2jDpGZ0 c2bDvGhyZXI6IERyLiBNYW5mcmVkIEphZ2llbGxhPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7PGJyPg0KJmd0OyBHZW3DpHNzIERhdGVuc2NodXR6Z3J1bmR2ZXJvcmRudW5nIHNpbmQg d2lyIHZlcnBmbGljaHRldCwgU2llIHp1IGluZm9ybWllcmVuLCB3ZW5uIHdpciBwZXJzb25lbmJl em9nZW5lIERhdGVuIHZvbiBJaG5lbiBlcmhlYmVuLjxicj4NCiZndDsgRGllc2VyIEluZm9ybWF0 aW9uc3BmbGljaHQga29tbWVuIHdpciBtaXQgZm9sZ2VuZGVtIERhdGVuc2NodXR6aGlud2VpcyAo PGEgaHJlZj0iaHR0cHM6Ly93d3cuZW5kcmVzcy5jb20vZGUvY29va2llcy1lbmRyZXNzJiM0Mzto YXVzZXItd2Vic2l0ZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmVuZHJlc3MuY29tL2Rl L2Nvb2tpZXMtZW5kcmVzcyYjNDM7aGF1c2VyLXdlYnNpdGU8L2E+KSBuYWNoLjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgRGlzY2xhaW1lcjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgaW5mb3JtYXRpb24gdHJh bnNtaXR0ZWQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgdG8gd2hp Y2ggaXQgaXMgYWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwsIHByb3ByaWV0 YXJ5LCBhbmQvb3IgcHJpdmlsZWdlZCBtYXRlcmlhbC4gQW55IHJldmlldywgcmV0cmFuc21pc3Np b24sIGRpc3NlbWluYXRpb24gb3Igb3RoZXIgdXNlIG9mLCBvciB0YWtpbmcgb2YgYW55IGFjdGlv biBpbiByZWxpYW5jZQ0KIHVwb24sIHRoaXMgaW5mb3JtYXRpb24gYnkgcGVyc29ucyBvciBlbnRp dGllcyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYg eW91IHJlY2VpdmUgdGhpcyBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoZSBtYXRlcmlhbCBmcm9tIGFueSBjb21wdXRlci4gVGhpcyBlLW1haWwgZG9lcyBu b3QgY29uc3RpdHV0ZSBhIGNvbnRyYWN0IG9mZmVyLCBhIGNvbnRyYWN0IGFtZW5kbWVudCwNCiBv ciBhbiBhY2NlcHRhbmNlIG9mIGEgY29udHJhY3Qgb2ZmZXIgdW5sZXNzIGV4cGxpY2l0bHkgYW5k IGNvbnNwaWN1b3VzbHkgZGVzaWduYXRlZCBvciBzdGF0ZWQgYXMgc3VjaC48YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLVVyc3Byw7xuZ2xp Y2hlIE5hY2hyaWNodC0tLS0tPGJyPg0KJmd0OyBWb246IFRMUyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnRscy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0OyBJbSBBdWZ0cmFnIHZvbiBNb2hpdCBTZXRoaSBNPGJyPg0KJmd0OyBHZXNlbmRl dDogRGllbnN0YWcsIDIxLiBKYW51YXIgMjAyMCAxMDo0NTxicj4NCiZndDsgQW46IENvbG0gTWFj Q8OhcnRoYWlnaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvbG1AYWxsY29zdHMubmV0IiB0YXJnZXQ9 Il9ibGFuayI+Y29sbUBhbGxjb3N0cy5uZXQ8L2E+Jmd0OzsgU2VhbiBUdXJuZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZWFuQHNuM3JkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNlYW5Ac24zcmQuY29t PC9hPiZndDs8YnI+DQomZ3Q7IENjOiBUTFMgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRsc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRsc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyBC ZXRyZWZmOiBSZTogW1RMU10gRXh0ZXJuYWwgUFNLIGRlc2lnbiB0ZWFtPGJyPg0KJmd0Ozxicj4N CiZndDsgSSBhbSBjZXJ0YWlubHkgaW50ZXJlc3RlZCBhbmQgd2lsbGluZyB0byBjb250cmlidXRl LiBXZSBuZWVkIHNvbWU8YnI+DQomZ3Q7IGNvbnNlbnN1cyBvbiB3aGV0aGVyIFBTS3MgY2FuIGJl IHNoYXJlZCB3aXRoIG1vcmUgdGhhbiAyIHBhcnRpZXMsPGJyPg0KJmd0OyB3aGV0aGVyIHRoZSBw YXJ0aWVzIGNhbiBzd2l0Y2ggcm9sZXMsIGV0Yy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBFTVUgaXMg Z29pbmcgdG8gd29yayBvbiBFQVAtVExTLVBTSyBhbmQgdGhlIHF1ZXN0aW9uIG9mPGJyPg0KJmd0 OyBwcml2YWN5L2lkZW50aXRpZXMgd2lsbCBwb3AtdXAgdGhlcmUgdG9vLjxicj4NCiZndDs8YnI+ DQomZ3Q7IC0tTW9oaXQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAxLzIxLzIwIDc6MzMgQU0sIENv bG0gTWFjQ8OhcnRoYWlnaCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBJbnRlcmVzdGVkLCBhcyBpdCBo YXBwZW5zIC0gdGhpcyBpcyBzb21ldGhpbmcgSSd2ZSBiZWVuIHdvcmtpbmcgb24gYXQgQW1hem9u Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gTW9uLCBKYW4gMjAsIDIwMjAgYXQgODow MSBQTSBTZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlYW5Ac24zcmQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+c2VhbkBzbjNyZC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZn dDsgQXQgSUVURiAxMDYsIHdlIGRpc2N1c3NlZCBmb3JtaW5nIGEgZGVzaWduIHRlYW0gdG8gZm9j dXMgb24gZXh0ZXJuYWwgUFNLIG1hbmFnZW1lbnQgYW5kIHVzYWdlIGZvciBUTFMuIFRoZSBnb2Fs IG9mIHRoaXMgdGVhbSB3b3VsZCBiZSB0byBwcm9kdWNlIGEgZG9jdW1lbnQgdGhhdCBkaXNjdXNz ZXMgY29uc2lkZXJhdGlvbnMgZm9yIHVzaW5nIGV4dGVybmFsIFBTS3MsIHByaXZhY3kgY29uY2Vy bnMgKGFuZCBwb3NzaWJsZSBtaXRpZ2F0aW9ucykNCiBmb3Igc3RhYmxlIGlkZW50aXRpZXMsIGFu ZCBtb3JlIGRldmVsb3BlZCBtaXRpZ2F0aW9ucyBmb3IgZGVwbG95bWVudCBwcm9ibGVtcyBzdWNo IGFzIFNlbGZpZS4gSWYgeW91IGhhdmUgYW4gaW50ZXJlc3QgaW4gcGFydGljaXBhdGluZyBvbiB0 aGlzIGRlc2lnbiB0ZWFtLCBwbGVhc2UgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGFuZCBzdGF0ZSBz byBieSAyMzU5IFVUQyAzMSBKYW51YXJ5IDIwMjAuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSm9l IGFuZCBTZWFuPGJyPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IFRMUyBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9l dXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGxzJmFtcDthbXA7ZGF0YT0wMiU3 QzAxJTdDYmpvZXJuLmhhYXNlJTQwZW5kcmVzcy5jb20lN0M1YWY3ZjlkY2QyZjc0NmI2NjM4YTA4 ZDc5ZTU2YTdkYyU3QzUyZGFmMmE5M2I3MzRkYTRhYzZhM2Y4MWFkYzkyYjdlJTdDMSU3QzAlN0M2 MzcxNTE5NjczMzAyNDY1NDQmYW1wO2FtcDtzZGF0YT14dHQlMkYxbXhTMFhiclRROG1FeGR6VVAl MkYlMkJIU0pLclhBTnNWcXNYJTJGNHNVWkElM0QmYW1wO2FtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0 bHMmYW1wO2FtcDtkYXRhPTAyJTdDMDElN0Niam9lcm4uaGFhc2UlNDBlbmRyZXNzLmNvbSU3QzVh ZjdmOWRjZDJmNzQ2YjY2MzhhMDhkNzllNTZhN2RjJTdDNTJkYWYyYTkzYjczNGRhNGFjNmEzZjgx YWRjOTJiN2UlN0MxJTdDMCU3QzYzNzE1MTk2NzMzMDI0NjU0NCZhbXA7YW1wO3NkYXRhPXh0dCUy RjFteFMwWGJyVFE4bUV4ZHpVUCUyRiUyQkhTSktyWEFOc1Zxc1glMkY0c1VaQSUzRCZhbXA7YW1w O3Jlc2VydmVkPTA8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBUTFMgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ VExTQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9ldXIwMy5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGxzJmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdDYmpvZXJu LmhhYXNlJTQwZW5kcmVzcy5jb20lN0M1YWY3ZjlkY2QyZjc0NmI2NjM4YTA4ZDc5ZTU2YTdkYyU3 QzUyZGFmMmE5M2I3MzRkYTRhYzZhM2Y4MWFkYzkyYjdlJTdDMSU3QzAlN0M2MzcxNTE5NjczMzAy NDY1NDQmYW1wO2FtcDtzZGF0YT14dHQlMkYxbXhTMFhiclRROG1FeGR6VVAlMkYlMkJIU0pLclhB TnNWcXNYJTJGNHNVWkElM0QmYW1wO2FtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0bHMmYW1wO2FtcDtk YXRhPTAyJTdDMDElN0Niam9lcm4uaGFhc2UlNDBlbmRyZXNzLmNvbSU3QzVhZjdmOWRjZDJmNzQ2 YjY2MzhhMDhkNzllNTZhN2RjJTdDNTJkYWYyYTkzYjczNGRhNGFjNmEzZjgxYWRjOTJiN2UlN0Mx JTdDMCU3QzYzNzE1MTk2NzMzMDI0NjU0NCZhbXA7YW1wO3NkYXRhPXh0dCUyRjFteFMwWGJyVFE4 bUV4ZHpVUCUyRiUyQkhTSktyWEFOc1Zxc1glMkY0c1VaQSUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8 L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB3901FCD4796FA9C921BC32D0DB000MN2PR11MB3901namp_-- From nobody Mon Feb 3 15:54:53 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B132120045 for ; Mon, 3 Feb 2020 15:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 lJgHMfo-HJ07 for ; Mon, 3 Feb 2020 15:54:49 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1111912001A for ; Mon, 3 Feb 2020 15:54:49 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id n27so10225282vsa.0 for ; Mon, 03 Feb 2020 15:54:49 -0800 (PST) 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=z2Q0RXCTq4eeRZSt0IutTcjZ3OV0IGUfTyudINY0Ls8=; b=oaFzEBvfvPTULcaymHW1M8f4xQvEhXtc9oSThRx80r9yVIwmwL38GRvbx2HprioS72 evXRwm06Fon7LLzY04fiXQ5ghwlVX2td43GPc5gFek7mc/gba/GbskZWPIgeb3OJy+eb ovRDzEqTZQXaQ0m7NkVeaRVuInvGEkaze3OfylMCYnNE9DoE1wpp8qmdd2SYK0ZH/riF GgMe3C//WTdxrMdkW/A7sz41AKV9ieb2s7Tu/uqM9bgjpig9sWCYcv4YvGNne+8K9IXP l0u/yaASfFnl1kkiBN6gZ8qHS5OWq6bbFiGDTq5eddd5kC8vK1J/0ry8j2uJaOK0Tymh t5fg== 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=z2Q0RXCTq4eeRZSt0IutTcjZ3OV0IGUfTyudINY0Ls8=; b=TQ930q/qjxgxDoNz54TgCRc+rVcJ5HcP1GR5EIBuOvkmxLSrZkAOsTDNAU4JauqNd7 5+rOmYrFcBnUqn21VMKNdD7Ql19tuZQ7ZUEswmDGkvmTVpH85HDZJCPWA9+5rioW1//K rPu5zcZ3KNUJzlw/mxWs2Iyk5f2yZ5mA3R4HySMY9IqotJvNtVrvHXeAS19x4c7I+oBN MC/xvm4Omzrf3XMNh6K5hf7upJA95Vm2tFGR75L9FMDrMWqMzT/PZpx428EQ8AX7WFs8 h/YdKGGPYKviaEaFiMQFlFGs8OaFfwWLZx31NFwl/Sc4GsCsfyILkyAnYu+WFBUVZpsw 2eZg== X-Gm-Message-State: APjAAAV3eQEm8/gAQ8N6LK+wcIse6jjD4e3v06RBd7fL25+lFv/Xj3MY A4FsbgmlvxJfMNKV41Eld+SiTipwMULOFUgknnc= X-Google-Smtp-Source: APXvYqyCKHH3BwJmuQFPMbmwawXG8/u7d4S78I4Yk/2VLYW3vK5o1kWTK1HeXHWzU3EiAhdl4zCUMqyhDAsydUrX7ek= X-Received: by 2002:a67:b309:: with SMTP id a9mr15843569vsm.97.1580774088209; Mon, 03 Feb 2020 15:54:48 -0800 (PST) MIME-Version: 1.0 References: <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> In-Reply-To: From: Daniel Migault Date: Mon, 3 Feb 2020 18:54:37 -0500 Message-ID: To: Eric Rescorla Cc: Rob Sayre , "" , Daniel Migault Content-Type: multipart/alternative; boundary="000000000000ff7965059db4a58c" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 23:54:52 -0000 --000000000000ff7965059db4a58c Content-Type: text/plain; charset="UTF-8" C.4 is clearly in a context where privacy is needed and by writing "SHOULD NOT" TLS 1.3 takes instead the position there are some cases this is not required. """ C.4 . Client Tracking Prevention Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of a ticket allows passive observers to correlate different connections. Servers that issue tickets SHOULD offer at least as many tickets as the number of connections that a client might use; for example, a web browser using HTTP/1.1 [RFC7230 ] might open six connections to a server. Servers SHOULD issue new tickets with every connection. This ensures that clients are always able to use a new ticket when creating a new connection. """ On Mon, Feb 3, 2020 at 12:02 AM Eric Rescorla wrote: > > > On Sun, Feb 2, 2020 at 7:40 PM Rob Sayre wrote: > >> On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault > 40ericsson.com@dmarc.ietf.org> wrote: >> >>> >>> On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote: >>> >>>> >>>> >>>> 1. TLS 1.3 takes the position that reuse is bad and that position >>>> is for good reasons, so we shouldn't undercut it in a new >>>> extension. >>>> >>>> >> >>> . Appendix C.4 discourages tickets re-use when Client tracking is a >>> concern. The section uses SHOULD and not MUST. So, in fact, TLS 1.3 takes >>> position this is not mandatory to renew tickets. >>> >> > Somehow I didn't get Daniel's email, so responding to it here. > > C.4 is not conditional. It simply says "Clients SHOULD NOT reuse a ticket > for multiple connections." My point is not that servers which do not renew > are not compliant but rather that TLS 1.3 has taken the position that reuse > is bad and therefore we should not add an extension to facilitate it. > > -Ekr > > >> thanks, >> Rob >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson --000000000000ff7965059db4a58c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
C.4 is clearly in a context where privacy is needed and by= writing "SHOULD NOT" TLS 1.3 takes instead the position there ar= e some cases this is not required.=C2=A0

""&qu= ot;
C.4.  Client Tracking Preven=
tion


   Clients SHOULD NOT reuse a ticket for multiple connections.  Reuse of
   a ticket allows passive observers to correlate different connections.
   Servers that issue tickets SHOULD offer at least as many tickets as
   the number of connections that a client might use; for example, a web
   browser using HTTP/1.1 [RFC7230] might open six connections to a
   server.  Servers SHOULD issue new tickets with every connection.
   This ensures that clients are always able to use a new ticket when=C2=A0=
=C2=A0 =C2= =A0creating a new connection.=C2=A0
"""

On Mon, Feb 3, 2020 at 12:02 AM Eric Rescorla <ekr@rtfm.com> wrote:



-Ekr


=
thanks,
Rob=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--
Daniel Migault
Ericsson
--000000000000ff7965059db4a58c-- From nobody Mon Feb 3 18:34:22 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DCF12004D for ; Mon, 3 Feb 2020 18:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 v5_67-Hun2To for ; Mon, 3 Feb 2020 18:34:20 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E0212001A for ; Mon, 3 Feb 2020 18:34:00 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id s6so8775562iol.9 for ; Mon, 03 Feb 2020 18:34:00 -0800 (PST) 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=g0P7kFjmhmXlJ+TucHdsQxuuNKyatrG+JOk646p7fXw=; b=Ze0IWsLcAmOjR7wsEC3+Tx+Cx/eDHpfsLjQkInJIbb1IqhruLZEaF+qPcHvDLM4Khv N3zzRs9mXL2SRB0XABNWtYQduazXApJzheuqLKDZGkHcd87JH4DX93amK4Ec+JUfmdJt Luxy/F3cRktaFcyVZRvtJDZm3cFPMShRQU8LgnEcKEf97FcMBCIaymTyRVKE9S6yu1Jo wSSpAVauL6fZeVfjdJPw00HIeGyVO27QXxo2jm1zeNPEvn0SZ/hNRBfCvF9tn0vBjysS WcknutzvL3zI7XbtJBHymYpUgaNwAf29VlNgCbJEp+xpugyQdLalrDkT93FRI6sEPOts 5/Wg== 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=g0P7kFjmhmXlJ+TucHdsQxuuNKyatrG+JOk646p7fXw=; b=Xn5QZ0FVFOHYIGXGXiujLmYhzZ+JLyx8wvN9NVg0CiIL98q5Sh4eFxD6YZPrYlgOCZ 6+UVFDyUJ/0I0L4LKtYd62fcbKpoo60ywAx08UO3cwSHYkIMSWSDCh2N8jF+9PfEamjX F+RsajCEz9nGYk6cptBztIGtuCNxKySZIeNkyLNw8AHmoCvhT3nuws0BtQ8B4Bo3VZAd dPMgCxfknx/nAbtEHpvJUigAyacjNqpkN5M5Fq9eO8tL7c53sWYB8af3goHm3NmFjSao YTIsdllGoduLyjmuMyJSktMacnKW/+bjA2MlWhqhFC99p/0KxFSVemlu/H0OSWA/UbID +o0w== X-Gm-Message-State: APjAAAW+uIdF2NaefOPAoiNRPfxTaj3caHcuFAFIz5RKG6OP5MbTWsAy bLQAgbp2dCdcpVB1R+nTiMLhli1jr+gAcvyFeo224prWkg0= X-Google-Smtp-Source: APXvYqw3YHXjdro+KAspmQJei7xI64kUCJFVoxhQKO2IBRy656DNRYt85e1UlSbjE7U6yLxIya8h/7Wczk/3kV6d6dY= X-Received: by 2002:a6b:731a:: with SMTP id e26mr21072391ioh.254.1580783639587; Mon, 03 Feb 2020 18:33:59 -0800 (PST) MIME-Version: 1.0 References: <20200202115203.GK49778@straasha.imrryr.org> <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com> <20200202175309.GL49778@straasha.imrryr.org> <53913E7D-765D-473B-980D-088F3D9D0C4D@apple.com> <7CAD8A81-2B5B-4730-ADCD-73F81A6D5DCF@apple.com> <83175EE9-EFBF-4182-90EF-84FCAC127260@dukhovni.org> <7EE22630-F800-4C85-B3B6-DC6A2509CE62@dukhovni.org> In-Reply-To: <7EE22630-F800-4C85-B3B6-DC6A2509CE62@dukhovni.org> From: Rob Sayre Date: Mon, 3 Feb 2020 18:33:47 -0800 Message-ID: To: IETF TLS WG Content-Type: multipart/alternative; boundary="0000000000004df13e059db6dfc7" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 02:34:22 -0000 --0000000000004df13e059db6dfc7 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 3, 2020 at 10:50 AM Viktor Dukhovni wrote: > > I'll read the post more closely over the next few days and attempt to > summarize where I think we are, and propose a pull request to at least > clarify the issues that motivate potential tweaks to the design. > I find the sentinel idea a little odd, and it seems to create habitat for overflow bugs. As others have written, it might be better for you to change your program, rather than change the protocol in the draft. It would be nice to describe that tradeoff, if you write a summary. thanks, Rob --0000000000004df13e059db6dfc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 3, 2020 at 10:50 AM Viktor Du= khovni <ietf-dane@dukhovni.org= > wrote:

I'll read the post more closely over the next few days and attempt to summarize where I think we are, and propose a pull request to at least
clarify the issues that motivate potential tweaks to the design.

I find the sentinel idea a little odd, and it see= ms to create habitat for overflow bugs.

As oth= ers have written, it might be better for you to change your program, rather= than change the protocol in the draft.

It would = be nice=C2=A0to describe that tradeoff, if you write a summary.
<= br>
thanks,
Rob

--0000000000004df13e059db6dfc7-- From nobody Tue Feb 4 05:56:38 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E315C120020 for ; Tue, 4 Feb 2020 05:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eke0wN8x8TM for ; Tue, 4 Feb 2020 05:56:34 -0800 (PST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AF71200C4 for ; Tue, 4 Feb 2020 05:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580824592; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HbigvV/f7zMCgX8LGbPc3qsYAXJXCrbhNxtRWVFBOhA=; b=GNLqwDKWGKp+K6F+HPbW75uMhfCKvIG8gYjf/6Rn4rR24jYEnNtysqqqO5a7cUoyecyyhp uWdyCmcLF3m78R9qym5wN8GL2FoO96nSWko5/+chbWfQ1E6DaQpF2IifXRt/T15bIciPWd kV6To6zDJzhV0pc3kaaP89nb2wUCUb8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-170-eYjcm8M5Pour8YuiPpDzqQ-1; Tue, 04 Feb 2020 08:56:30 -0500 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id E296D184AEAA for ; Tue, 4 Feb 2020 13:56:29 +0000 (UTC) Received: from localhost (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8EB995C1B5 for ; Tue, 4 Feb 2020 13:56:29 +0000 (UTC) From: Hubert Kario To: Date: Tue, 04 Feb 2020 14:56:27 +0100 MIME-Version: 1.0 Message-ID: <6edaf470-ecc7-4f17-8727-dc166cc6d8d5@redhat.com> In-Reply-To: <20200203054915.GO49778@straasha.imrryr.org> References: <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> <20200203054915.GO49778@straasha.imrryr.org> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-MC-Unique: eYjcm8M5Pour8YuiPpDzqQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 13:56:37 -0000 On Monday, 3 February 2020 06:49:15 CET, Viktor Dukhovni wrote: > On Sun, Feb 02, 2020 at 09:01:45PM -0800, Eric Rescorla wrote: > >> My point is not that servers which do not renew are not compliant but >> rather that TLS 1.3 has taken the position that reuse is bad and >> therefore we should not add an extension to facilitate it. > > Re: C.4 Clients SHOULD NOT reuse a ticket for multiple connections. > Reuse of a ticket allows passive observers to correlate > different connections. > > But ticket reuse is patently a win when connection correlation is an > unavoidable and even desirable feature of the network relationship > between the parties. the thing is that getting extra ticket from the server is at most an inconvenience for postfix for other usages, reusing aticket may be a security breach just by virtue of being defined, it will be implemented by some libraries, which means in turn that it will be used incorrectly by somebody --=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 From nobody Tue Feb 4 07:08:40 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FC01200CD for ; Tue, 4 Feb 2020 07:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.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 M3mZnBNYZ7zJ for ; Tue, 4 Feb 2020 07:08:36 -0800 (PST) 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 53456120020 for ; Tue, 4 Feb 2020 07:08:36 -0800 (PST) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1580828916; b=jUMIV1Iu1PzQql4FQL97XCuc1T35Bfq5kCKVDzmBcNxZoca/ziGRG+tHGU8dvxKT7f9HdcNcLt PpImY0fuC2YMWzw5H0uWyWezmIwz5SYw0JcUqqJmhK3p916azDTzdjPNen/yna2JRg1pvtmHP2 yaUyjNgt8jfoHGTpyjhvf6M=; ARC-Authentication-Results: i=1; wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1580828916; bh=KeMSBxgVGoY+E5nA+SMkby8j2Z+SsqDCIBkU5kQQOhA=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=g7qSa/OAaf3mLc52U5kDg2ivJvOSnaw6IMyVxKzYiDcPsuLMJ7Zduct+2gHZVDu1pv51wsMkk9 tascFXDc0AOEF9a8PqFvV3i56hdMW99DW3JRURzETfuovumv65//QrexmDFwgyBxIu4c0SgfQP i00MI8tbACCqxYkvL8J7GJ8=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=BE+byRdYeZBG/Ytgwx0I7UyELQKc0K+bv6bJWuWU9wc=; b=m XZt/U4C9tPYrLLs5JiDLyl9kIltf9ijDNTxrJxMpS9QojXyv8hlc6KwXcQ4G5GCLBHfEZa8F6kSkJ YBtBs2+K63Dpqsp7TmXJZi2PwlEvO5By14srh+ymhI6Jka2fqV2AdPuvO147QmlhE3JsymyxUmhgc Cv15zgtnCscY2ZIw=; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) by wizmail.org (Exim 4.93.107) (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with esmtpsa id 1iyzoY-0002pZ-6D for tls@ietf.org (return-path ); Tue, 04 Feb 2020 15:08:34 +0000 To: tls@ietf.org References: <20191120064819.GR34850@straasha.imrryr.org> <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> <20200203054915.GO49778@straasha.imrryr.org> <6edaf470-ecc7-4f17-8727-dc166cc6d8d5@redhat.com> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQFOBBMBCAA4FiEE qYbzpr1jd9hzCVjevOWMjOQfMt8FAl4WMuMCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQvOWMjOQfMt946ggAvqDr2jvVnGIN2Njnjl2iiKyw4dYdFzNhZgjTaryiV90BftUDxRsB uTVFUC6XU+B13MEgSK0zRDyI5NpEH+JTW539gWlmz2k2WTTmoBsm/js1ELoAjGr/i32SByqm 0fo3JPctn/lc7oTo0muGYvB5xWhTHRlcT9zGTRUb/6ucabVLiJUrcGhS1OqDGq7nvYQpFZdf Dj7hyyrCKrq6YUPRvoq3aWw/o6aPUN8gmJj+h4pB5dMbbNKm7umz4O3RHWceO9JCGYxfC4uh 0k85bgIVb4wtaljBW90YZRU/5zIjD6r2b6rluY55rLulsyT7xAqe14eE1AlRB1og/s4rUtRf 8LkBDQRVgAbEAQgA6YSx2ik6EbkfxO0x3qwYgow2rcAmhEzijk2Ns0QUKWkN9qfxdlyBi0vA nNu/oK2UikOmV9GTeOzvgBchRxfAx/dCF2RaSUd0W/M4F0/I5y19PAzN9XhAmR50cxYRpTpq ulgFJagdxigj1AmNnOHk0V8qFy7Xk8a1wmKI+Ocv2Jr5Wa5aJwTYzwQMh4jvyzc/le32bTbD ezf1xq5y23HTXzXfkg9RDZmyyfEb8spsYLk8gf5GvSXYxxyKEBCei9eugd4YXwh6bfIgtBj2 ZLYvSDJdDaCdNvYyZtyatahHHhAZ+R+UDBp+hauuIl8E7DtUzDVMKVsfKY71e8FSMYyPGQAR AQABiQEfBBgBAgAJBQJVgAbEAhsMAAoJELzljIzkHzLfTegH/Aktgk6zEBXYZBhLQV5i+Inw /FBxZAUQRpjPGS9n1lAU2V0/Jq3UTDiurXD5ylmgr1ryq9JJ7fe9I/w8gIBZh/IYDot8nLYo BXnFQ444pQHgiTKt/LNbWCmIiw2wXR1rXZAPbh2cKt5X3d0MXBBDt0GpkBfnTu4fIADl5Rvq aPOx5vhNMM+LMCAfPkt+yc68fbrtC0hQ3yQkyvkyChmuVJ/C8T8cqvVp5zQ4e9syuwYkYnZP 7ONCnDaHfNzTOB5/7Gxn8i2vLEtBdzBNEvqHEjDorv2RxzosKS2DW8Eye7LWcRrK4Llnk/T/ mpsWwP2JSveS3nbLcLzflnB2e3fvgK65AQ0EXiRPygEIAMP9Z2LRciWF8OoKUbcnA50W0U60 zTBvb7IMm0Rfaeb+s5vk0bX6Hel8i7dxmQvy0yUBrQq/9NYa90MOcm54b9oETtKHcoe63U3i iZc62ERe5dRIr9EG1DAN3SW5fRc5H234mskCdl06ftOJCsXLL1enbunWF8WYQpn8hzsoQqzs klloqd24z8c/+3C5cPjI26hyGFR0W5Q1T8xBMqxgc5W0smyyqDdDs/H1VXrxfQdculDXkM3B EUkeZMsyT7Q8jr8qHv13T1dPCyObP4wXkaOSEtOcBAeF2B1TUVUEhqPzXbG6+oZWgVUKWB8o oHReboJUCkQC8jAIZrr9xpgCMPMAEQEAAYkBPAQYAQgAJhYhBKmG86a9Y3fYcwlY3rzljIzk HzLfBQJeJE/KAhsMBQkB4TOAAAoJELzljIzkHzLfjg4IAM2GxIUaXLfO22z2JWS3byFvfRNS eXLZx2cDokn8AGpzTY+k5mcCkOQVUUz9MuxM50VnrRuBaeH++LfzSghKRWLx2PdJlKzThyFi y23NagSwx4i/R2J8xiPtajZm5SS3slEg1pt3NhgDkkrTQUTHYcf4F0O3YgdoqGKR7m10jqXz gzwQE65Pb0QUX5clxy55oV1pXoq1qjELIYVH9aS8bpI0RE86axHwpOvG4cQrMWZ0tg1txwZ/ DSstczlx7/Ptxfdd+A0x27UhS7ijUuqXx/z8Vh7U/oj/lsVERXyxuUgojD5kkagRLURuYBef CxJ/k6RTKs8juRsbVGfJMmNdfyK4OAReJFQPEgorBgEEAZdVAQUBAQdAPr/8EgFM8AkB/CZz +BGJIezPAdpTYFLvRhsem2GoBicDAQgHiQE8BBgBCAAmFiEEqYbzpr1jd9hzCVjevOWMjOQf Mt8FAl4kVA8CGwwFCQPCZwAACgkQvOWMjOQfMt99PAgApNBPoJog4UKuiP4YP4vvntA4etz8 z7WzVU4uI2ep7++qEaZOafHlSaUILaGag4CSh7KmxrTUjtoJNeX2qx5AQ4pdlNIjMy/V/Z+z 8gJ5vQ3tXglN4P7S6ud6mYKzpGHCvNF2CdzSRa2DRizCy6+sHOrDiH5V7veKE+9LjF+aB9lw PYLeF6Dh4idnxIa3aVwQjAAn3NBYAuhymnqgLgWcrPNaiSP6VIrsu4aCCoeIuc7bCFks6hrR x805g1J6uxixrMu2bW+AbPpRObi5B0pTJhDaLBW1xQgOiwYIAdyu0H2YNMrCBsA0w40UWEIz xrAkJFP/CS+qkjMI47FKq1EzbQ== Message-ID: <2d587501-b323-9a75-99cd-5686219dba0d@wizmail.org> Date: Tue, 4 Feb 2020 15:08:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <6edaf470-ecc7-4f17-8727-dc166cc6d8d5@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 15:08:38 -0000 On 04/02/2020 13:56, Hubert Kario wrote: > the thing is that getting extra ticket from the server is at most an > inconvenience for postfix Isn't the giving out of needless tickets a performance cost for the server, as well as a bandwidth cost for the network? Or are tickets zero-cost to produce? -- Cheers, Jeremy From nobody Tue Feb 4 07:13:53 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD1A120105 for ; Tue, 4 Feb 2020 07:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 W8idlxWI3fR8 for ; Tue, 4 Feb 2020 07:13:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E076C120020 for ; Tue, 4 Feb 2020 07:13:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A37DFF406CD; Tue, 4 Feb 2020 07:13:36 -0800 (PST) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: rsalz@akamai.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200204151336.A37DFF406CD@rfc-editor.org> Date: Tue, 4 Feb 2020 07:13:36 -0800 (PST) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (5976) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 15:13:52 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5976 -------------------------------------- Type: Editorial Reported by: Rich Salz Section: GLOBAL Original Text ------------- Section 4.4.2 has the following: enum { X509(0), RawPublicKey(2), (255) } CertificateType; Corrected Text -------------- Notes ----- The registry has "X.509" as the certificate type. The IANA registry for TLS Certificate types at https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3 has "X.509" as the name for value 0. The name should be changed to "X509" and the reference should be changed to RFC 8446. A comment "Was X.509 before TLS 1.3" should be added. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Feb 4 07:19:12 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF144120020 for ; Tue, 4 Feb 2020 07:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 r7_UVjOW5o34 for ; Tue, 4 Feb 2020 07:19:08 -0800 (PST) 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 1A9CF12009E for ; Tue, 4 Feb 2020 07:19:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AC5B2300AEF for ; Tue, 4 Feb 2020 09:52:26 -0500 (EST) 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 wEylxs1ZvD25 for ; Tue, 4 Feb 2020 09:52:23 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 386D7300AAF; Tue, 4 Feb 2020 09:52:22 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20200204151336.A37DFF406CD@rfc-editor.org> Date: Tue, 4 Feb 2020 10:19:02 -0500 Cc: Eric Rescorla , "Roman D. Danyliw" , Ben Kaduk , Chris Wood , Joe Salowey , sean+ietf@sn3rd.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200204151336.A37DFF406CD@rfc-editor.org> To: IETF TLS X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (5976) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 15:19:10 -0000 I think the document is correct and the IANA registry should remove the = dot. Russ > On Feb 4, 2020, at 10:13 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5976 >=20 > -------------------------------------- > Type: Editorial > Reported by: Rich Salz >=20 > Section: GLOBAL >=20 > Original Text > ------------- > Section 4.4.2 has the following: > enum { > X509(0), > RawPublicKey(2), > (255) > } CertificateType; >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- > The registry has "X.509" as the certificate type. The IANA registry = for TLS Certificate types at = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml#tls-extensiontype-values-3 has "X.509" as the name for = value 0. The name should be changed to "X509" and the reference should = be changed to RFC 8446. A comment "Was X.509 before TLS 1.3" should be = added. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8446 (draft-ietf-tls-tls13-28) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol = Version 1.3 > Publication Date : August 2018 > Author(s) : E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Feb 4 07:52:38 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAA2120119 for ; Tue, 4 Feb 2020 07:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=0.001, SPF_NONE=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=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 lVDVgxGiZPwZ for ; Tue, 4 Feb 2020 07:52:34 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 682021200B9 for ; Tue, 4 Feb 2020 07:52:34 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id h23so19145275ljc.8 for ; Tue, 04 Feb 2020 07:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RqH4poIdKedvsT2FhysoYLuOvBwI2nZEkOMnVyIGzWI=; b=jUgTvOSlIVA0XTAqvEjFasLlqmPc9XeUX491L3pnrRYVzYvh/Vs0pDdFZhnxnBXi7l mqtZOylRRxpOqOxOezwwoLEzZj7Bo40tC2AzZ3wkkkk8iBwAJwJQuyUtx8Xtatdpow0R ngs8aFYTG4QgD0BmbfyAue2w3PWWEO4j/Ek6iQLtmwvXnMPX+aOGBnKNCLYsqqnQe3x7 OMoeDpnzbaMa5x0JvRz5+jUxDWZgzjiP6o8orXRdCudzwb5uWxU73IsobU9mB3CedRIm P6SzRjfShcHdqxMn24U2bzplk+gRvbUBNhgnQlcz2GsIdX4yO15HhLQmk1wnF3Fg3jQG y6mA== 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=RqH4poIdKedvsT2FhysoYLuOvBwI2nZEkOMnVyIGzWI=; b=FYv3lvJ6p31KRAMigSu57QXfcDFu6CLNNYsBU4j8bupn9k4OjEeMWjgr/7TchYLKt6 AOQK/hcHOCqJUGrb7bvrivYVt/4a4L7XxEMPKWqjuWydZsMiwyTLu+k0vyofutsm3ow6 /MRPeG4tQi3ShJjvGCdCY4+5Kbxq/DTEBHB6g2eXCcvdcU0+RUYqOh7VUD8TeTKQTQDD SBW4mFlMtT99Jv25ugTvQpwSnWSFPWFbWa2aaByucfdB20DolRgnlf6fZpRyp7+V+OV4 V5RF8GemYhuswQcVUKNoe8dNklI6UiNrvOSsyj2ETo71HAEEYLkgdionRHE3o9ymzHgp I7ng== X-Gm-Message-State: APjAAAVFiLRbcmlxZTCfaX8QFqnC/5FRNc+edY4lW06wS75MZaegesyW xX9cGu+NnVlOouJfPGSETsVQ3JwGPPJicOEn946iig== X-Google-Smtp-Source: APXvYqxX3NEB1aPwbqmrPlMRqVvPkmnGcvPdVPOBZ3/T60a7x5PZ2PpaMBv8D/+/90L/pJP8E1HILg4l8KKI2+EDq/A= X-Received: by 2002:a2e:90f:: with SMTP id 15mr17178258ljj.120.1580831552712; Tue, 04 Feb 2020 07:52:32 -0800 (PST) MIME-Version: 1.0 References: <20200204151336.A37DFF406CD@rfc-editor.org> In-Reply-To: From: Eric Rescorla Date: Tue, 4 Feb 2020 07:51:56 -0800 Message-ID: To: Russ Housley Cc: IETF TLS , "Roman D. Danyliw" , Ben Kaduk , Chris Wood , Joe Salowey , sean+ietf@sn3rd.com Content-Type: multipart/alternative; boundary="000000000000263bd4059dc207ff" Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (5976) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 15:52:37 -0000 --000000000000263bd4059dc207ff Content-Type: text/plain; charset="UTF-8" I agree. This was an intentional change. -Ekr On Tue, Feb 4, 2020 at 7:19 AM Russ Housley wrote: > I think the document is correct and the IANA registry should remove the > dot. > > Russ > > > > On Feb 4, 2020, at 10:13 AM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC8446, > > "The Transport Layer Security (TLS) Protocol Version 1.3". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid5976 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Rich Salz > > > > Section: GLOBAL > > > > Original Text > > ------------- > > Section 4.4.2 has the following: > > enum { > > X509(0), > > RawPublicKey(2), > > (255) > > } CertificateType; > > > > > > Corrected Text > > -------------- > > > > > > Notes > > ----- > > The registry has "X.509" as the certificate type. The IANA registry for > TLS Certificate types at > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3 > has "X.509" as the name for value 0. The name should be changed to "X509" > and the reference should be changed to RFC 8446. A comment "Was X.509 > before TLS 1.3" should be added. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8446 (draft-ietf-tls-tls13-28) > > -------------------------------------- > > Title : The Transport Layer Security (TLS) Protocol > Version 1.3 > > Publication Date : August 2018 > > Author(s) : E. Rescorla > > Category : PROPOSED STANDARD > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > --000000000000263bd4059dc207ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree. This was an intentional change.
-Ekr


=
On Tue, Feb 4, 2020 at 7:19 AM Russ H= ousley <housley@vigilsec.com= > wrote:
I th= ink the document is correct and the IANA registry should remove the dot.
Russ


> On Feb 4, 2020, at 10:13 AM, RFC Errata System <rfc-editor@rfc-editor.org&g= t; wrote:
>
> The following errata report has been submitted for RFC8446,
> "The Transport Layer Security (TLS) Protocol Version 1.3". >
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5976
>
> --------------------------------------
> Type: Editorial
> Reported by: Rich Salz <rsalz@akamai.com>
>
> Section: GLOBAL
>
> Original Text
> -------------
> Section 4.4.2 has the following:
>=C2=A0 =C2=A0 =C2=A0 enum {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 X509(0),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RawPublicKey(2),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (255)
>=C2=A0 =C2=A0 =C2=A0 } CertificateType;
>
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> The registry has "X.509" as the certificate type.=C2=A0 The = IANA registry for TLS Certificate types at https://www.iana.= org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls= -extensiontype-values-3 has "X.509" as the name for value 0.= =C2=A0 The name should be changed to "X509" and the reference sho= uld be changed to RFC 8446.=C2=A0 A comment "Was X.509 before TLS 1.3&= quot; should be added.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC8446 (draft-ietf-tls-tls13-28)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Tran= sport Layer Security (TLS) Protocol Version 1.3
> Publication Date=C2=A0 =C2=A0 : August 2018
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: E. Rescorla
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Lay= er Security
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--000000000000263bd4059dc207ff-- From nobody Tue Feb 4 07:59:04 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091DA12012E for ; Tue, 4 Feb 2020 07:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 DrrfYb0RHOjb for ; Tue, 4 Feb 2020 07:59:01 -0800 (PST) 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 0E34C120119 for ; Tue, 4 Feb 2020 07:59:00 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 014FkRJe011698; Tue, 4 Feb 2020 15:58:58 GMT 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=qnl44hsi7oebYidkp2gpKVt7g/nh1ixYI2CCh0wX1B8=; b=URyEGpDr6jNZG/94+RJeZP656d3lsWNxq4bzc1V6kWWJ0uxq7TVAFxxGxtKcuCyKgoyE /Ah8TQ+TV6IDm17bAuLpu9BUodJT0x4HGfdI4sJsVgfDrFTO3BXcIjiNCRE4W7FLxcs/ lp6pUZHXPdHjrDq0fGywO3mW4HV9DRnXQaMpH5mxdoMSU8sVGKJPn6UypHbH/Kl1gviW wo/PH56gT2UE/32W5FtqZZw1wM9MeMK9ZMj+v0O/PGGumKRPEmfGiPbgak0rUXQGMuUb vY9CfPYE73oFE9vIaWrMBHN4CjfyOtQTSV+YMH9z22XHGwFfDq9dfnUwTtK/BQRpnmTD mw== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2xx7mnpym1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Feb 2020 15:58:58 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 014Fmq9U019635; Tue, 4 Feb 2020 07:58:57 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint5.akamai.com with ESMTP id 2xw86b2hky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 04 Feb 2020 07:58:57 -0800 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb2.msg.corp.akamai.com (172.27.123.59) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 10:58:56 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 10:58:56 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 4 Feb 2020 10:58:56 -0500 From: "Salz, Rich" To: Eric Rescorla , Russ Housley CC: "Roman D. Danyliw" , Ben Kaduk , "sean+ietf@sn3rd.com" , IETF TLS Thread-Topic: [TLS] [Editorial Errata Reported] RFC8446 (5976) Thread-Index: AQHV2222wiSRNBXkCUycL9NarMoWY6gLedIAgAAJMQD//64igA== Date: Tue, 4 Feb 2020 15:58:55 +0000 Message-ID: <2F4BA11D-FB72-444C-818F-7B3DEDF45DA7@akamai.com> References: <20200204151336.A37DFF406CD@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.117.88] Content-Type: multipart/alternative; boundary="_000_2F4BA11DFB72444C818F7B3DEDF45DA7akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-04_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=817 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002040107 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-04_05:2020-02-04, 2020-02-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 priorityscore=1501 bulkscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 suspectscore=0 mlxlogscore=786 clxscore=1011 spamscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2002040107 Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (5976) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 15:59:03 -0000 --_000_2F4BA11DFB72444C818F7B3DEDF45DA7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGludGVudCBpcyB0byBtYWtlIHRoZSBjaGFuZ2UsIGJ1dCBJQU5BIHdhbnRlZCBhbiBhcHBy b3ZlZCBlcnJhdGEgZmlyc3QuDQoNCg== --_000_2F4BA11DFB72444C818F7B3DEDF45DA7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <6B74885D3985314CA622D0432467977D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50ZW50IGlzIHRvIG1ha2UgdGhl IGNoYW5nZSwgYnV0IElBTkEgd2FudGVkIGFuIGFwcHJvdmVkIGVycmF0YSBmaXJzdC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2F4BA11DFB72444C818F7B3DEDF45DA7akamaicom_-- From nobody Tue Feb 4 08:50:07 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A471120123 for ; Tue, 4 Feb 2020 08:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 V7m37g_tPWsc for ; Tue, 4 Feb 2020 08:50:02 -0800 (PST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AEA11200F5 for ; Tue, 4 Feb 2020 08:50:02 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id s7so8860949qvn.8 for ; Tue, 04 Feb 2020 08:50:02 -0800 (PST) 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=0uk3Y+0VqCk+6Jz4NlCj29LyUaRCMrKkOicdygFndhw=; b=BzjIMtQAUXDO7Bg04lUrxy7FXpm7PPj1eOPh7wKFh4F2kq/YfOg2+VR+my0RSfUpIT mV6k5MbDl3YvLmRZAj8zv0sx6kZSPSNAqAhfppsVJHBQuOm9ej4QOyhd2+YdwJ/YzHg7 qs08kwn3BhbT6UdMM0OE/VVsmuPX1hZHg9T44= 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=0uk3Y+0VqCk+6Jz4NlCj29LyUaRCMrKkOicdygFndhw=; b=QLiCby0p03JsCohpu1dAk4USlt+H9CAzcAOhTuGEMc6NG0VoEZrhccUt3Z24ewdoUp nstdGZuW3nmmQ3SrHVYEwUkvXUVKRYx9DuU5dXpuVkTNRlS9KCOZ4ySASPi3cQsSV92m rBSmxkIS1WUa8Loi9LaiJ3JqROoF0TcskoqTCUzlaDDks8KeX6rZFKJdtDo3FR9uZtSv +cr6K2X/GDDtNte7JambYCAOFjGfJG2Yzq4VCCc4CbKv3KbhkxEaykIk9IOrSngFg1fI grWDsJgsTl3rVId2NSQ59b7qFbu4mmTt1Pv6Q8xTTu+4WHpqSIBz2H/qBShDP0cYOjCD ISLQ== X-Gm-Message-State: APjAAAUceokqIQWRI8i05wRPByaXTScvQMnK9B+XculxRhyvnboKC4Wj j8j7fiosdLvJ9ab+oy2HZzEPqc0eTIZSfA== X-Google-Smtp-Source: APXvYqwan+CrYUCNKJCovPGKzyr+2jj+K8YIHjjqtwJAkJwlWuOyV21HwV6pN4rYwIOhk8PqrPwIxQ== X-Received: by 2002:a05:6214:1267:: with SMTP id r7mr28845500qvv.160.1580835001429; Tue, 04 Feb 2020 08:50:01 -0800 (PST) Received: from [5.5.33.119] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id r1sm11941971qtu.83.2020.02.04.08.49.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Feb 2020 08:50:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <2F4BA11D-FB72-444C-818F-7B3DEDF45DA7@akamai.com> Date: Tue, 4 Feb 2020 17:49:56 +0100 Cc: Eric Rescorla , Russ Housley , Roman Danyliw , Benjamin Kaduk , "sean+ietf@sn3rd.com" , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200204151336.A37DFF406CD@rfc-editor.org> <2F4BA11D-FB72-444C-818F-7B3DEDF45DA7@akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (5976) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 16:50:04 -0000 Ah. I will admit it=E2=80=99s a little weird to do an errata to change = the IANA registry. Maybe we tweak the errata to include the following = text so there is a trail of bits: Corrected Text -------------- Section 11. IANA Considerations=20 Certificate Types paragraph IANA haas to updated the TLS Certificate Types registry extension to = change value 0 to have the name X509, to have a comment "Was X.509 = before TLS 1.3=E2=80=9D, and to refer to this RFC. Cheers, spt > On Feb 4, 2020, at 16:58, Salz, Rich wrote: >=20 > The intent is to make the change, but IANA wanted an approved errata = first. From nobody Tue Feb 4 08:52:01 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953101200F5 for ; Tue, 4 Feb 2020 08:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 Q8LjuU1C3_LI for ; Tue, 4 Feb 2020 08:51:58 -0800 (PST) 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 56C3012011A for ; Tue, 4 Feb 2020 08:51:58 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 014GoYM2016914; Tue, 4 Feb 2020 16:51:54 GMT 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-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=T7dqhMZqn4t2yh0Q77Q5rYdnhLArPbpJeELknEAGiW0=; b=Munlw6yayS5te9ti+MpAPIuRcPz5Qxo3tqHl5AKfmypDRTm9+p9niDOMBq4JUcSWnrG0 55jf6Zf7NykcmXHLa8Yj0V1/RMDPYULhyVmV8qwHm1ait0gkO3EYUz+xXt9gZCvh9GlL T+vX/D09YdAcP5cIKyVsXHNKZrYkqk4gKfMzENg/3WwkWrXq++m9Yooq9qAFjcFEL709 gHeit3UxVXk23/t79rjfinM1xwgZ0WwRRJLxIOy2+/vKi+NTew65/ZC4DslPaoX0NnZV DGR0JPNHND+m3m0NPXrVoOCFshjW/W71kJHFmgVfku7p2qlZ+3/bjvB7er1H1BX9dvgt gQ== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2xwvkdsdy1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Feb 2020 16:51:54 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 014GoY1l012844; Tue, 4 Feb 2020 11:51:52 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint6.akamai.com with ESMTP id 2xw5hy2p2g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 04 Feb 2020 11:51:52 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 11:51:51 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 4 Feb 2020 11:51:51 -0500 From: "Salz, Rich" To: Sean Turner CC: Eric Rescorla , Russ Housley , "Roman Danyliw" , Benjamin Kaduk , "sean+ietf@sn3rd.com" , IETF TLS Thread-Topic: [TLS] [Editorial Errata Reported] RFC8446 (5976) Thread-Index: AQHV2222wiSRNBXkCUycL9NarMoWY6gLedIAgAAJMQD//64igIAAYhMA//+st4A= Date: Tue, 4 Feb 2020 16:51:50 +0000 Message-ID: <87FD04CB-2B87-45B7-8836-36DD4CC78C94@akamai.com> References: <20200204151336.A37DFF406CD@rfc-editor.org> <2F4BA11D-FB72-444C-818F-7B3DEDF45DA7@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/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.117.88] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=975 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002040110 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-04_06:2020-02-04, 2020-02-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=942 spamscore=0 clxscore=1011 malwarescore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2002040110 Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (5976) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 16:51:59 -0000 R29vZCBpZGVhIQ0KDQrvu79PbiAyLzQvMjAsIDExOjUwIEFNLCAiU2VhbiBUdXJuZXIiIDxzZWFu QHNuM3JkLmNvbT4gd3JvdGU6DQoNCiAgICBBaC4gSSB3aWxsIGFkbWl0IGl04oCZcyBhIGxpdHRs ZSB3ZWlyZCB0byBkbyBhbiBlcnJhdGEgdG8gY2hhbmdlIHRoZSBJQU5BIHJlZ2lzdHJ5LiBNYXli ZSB3ZSB0d2VhayB0aGUgZXJyYXRhIHRvIGluY2x1ZGUgdGhlIGZvbGxvd2luZyB0ZXh0IHNvIHRo ZXJlIGlzIGEgdHJhaWwgb2YgYml0czoNCiAgICANCiAgICBDb3JyZWN0ZWQgVGV4dA0KICAgIC0t LS0tLS0tLS0tLS0tDQogICAgU2VjdGlvbiAxMS4gSUFOQSBDb25zaWRlcmF0aW9ucyANCiAgICBD ZXJ0aWZpY2F0ZSBUeXBlcyBwYXJhZ3JhcGgNCiAgICANCiAgICBJQU5BIGhhYXMgdG8gdXBkYXRl ZCB0aGUgVExTIENlcnRpZmljYXRlIFR5cGVzIHJlZ2lzdHJ5IGV4dGVuc2lvbiB0byBjaGFuZ2Ug dmFsdWUgMCB0byBoYXZlIHRoZSBuYW1lIFg1MDksIHRvIGhhdmUgYSBjb21tZW50ICJXYXMgWC41 MDkgYmVmb3JlIFRMUyAxLjPigJ0sIGFuZCB0byByZWZlciB0byB0aGlzIFJGQy4NCiAgICANCiAg ICBDaGVlcnMsDQogICAgDQogICAgc3B0DQogICAgDQogICAgPiBPbiBGZWIgNCwgMjAyMCwgYXQg MTY6NTgsIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb20+IHdyb3RlOg0KICAgID4gDQogICAg PiBUaGUgaW50ZW50IGlzIHRvIG1ha2UgdGhlIGNoYW5nZSwgYnV0IElBTkEgd2FudGVkIGFuIGFw cHJvdmVkIGVycmF0YSBmaXJzdC4NCiAgICANCiAgICANCg0K From nobody Tue Feb 4 13:47:08 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF89B120164 for ; Tue, 4 Feb 2020 13:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 TW0pL0wE2OCb for ; Tue, 4 Feb 2020 13:47:05 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36E3120152 for ; Tue, 4 Feb 2020 13:47:03 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 1B7533AA9E; Tue, 4 Feb 2020 16:47:02 -0500 (EST) Date: Tue, 4 Feb 2020 16:47:02 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20200204214702.GT49778@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20200121055411.GJ73491@straasha.imrryr.org> <20200121224610.GR73491@straasha.imrryr.org> <20200203054915.GO49778@straasha.imrryr.org> <6edaf470-ecc7-4f17-8727-dc166cc6d8d5@redhat.com> <2d587501-b323-9a75-99cd-5686219dba0d@wizmail.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d587501-b323-9a75-99cd-5686219dba0d@wizmail.org> User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 21:47:07 -0000 On Tue, Feb 04, 2020 at 03:08:31PM +0000, Jeremy Harris wrote: > On 04/02/2020 13:56, Hubert Kario wrote: > > the thing is that getting extra ticket from the server is at most an > > inconvenience for postfix > > Isn't the giving out of needless tickets a performance cost > for the server, as well as a bandwidth cost for the network? > > Or are tickets zero-cost to produce? They are not free. They can be modestly large, especially when client cert authencation was used on the initial connection, in which case at least the EE cert is typically bundled into the ticket (some implementations may save the whole chain). This means that abbreviated resumption handshakes are now followed with potentially an additional O(1 KB) of ticket traffic. The CPU cost of encrypting the ticket is generally modest, but in an RPC protocol over TLS, which relies on resumption to ammortise handshake overhead, the extra payload may dwarf the application traffic. Squirreling away a fresh tickets after each RPC request may also increase garbage collection pressure in some languages. Not all the world is C, C++ or Rust. -- Viktor. From nobody Wed Feb 5 12:36:54 2020 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 B75DD12081B; Wed, 5 Feb 2020 12:36:52 -0800 (PST) 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.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <158093501262.12877.10966121264461280401@ietfa.amsl.com> Date: Wed, 05 Feb 2020 12:36:52 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for 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 Feb 2020 20:36:53 -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 WG of the IETF. Title : Delegated Credentials for TLS Authors : Richard Barnes Subodh Iyengar Nick Sullivan Eric Rescorla Filename : draft-ietf-tls-subcerts-06.txt Pages : 15 Date : 2020-02-05 Abstract: The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-subcerts-06 https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 5 23:36:52 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CAE12018D for ; Wed, 5 Feb 2020 23:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 YxBJOlPvPWBL for ; Wed, 5 Feb 2020 23:36:49 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EB412016E for ; Wed, 5 Feb 2020 23:36:49 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id b7so4607929qkl.7 for ; Wed, 05 Feb 2020 23:36:49 -0800 (PST) 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=YU3O+TI5JN5sRSNdp7rnO1Vo3JgdMXt+TI8MU3lwYwI=; b=b5KbGgnlzkSNVLXtjglqbFzmKrXEsZM/YkBFh01/TfVz4aC9njaC8QpArUUGN3zeZ6 RqKaRc5A8hThSqP7ppwRG02GunO2+cCfaDTYEBG2ZFFSEWxX0DaQqt8LjBCv5AiAz0He ZuW9VfZ9F1IM5inRZTPzSmPM4aQgrT/MH8bFQ= 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=YU3O+TI5JN5sRSNdp7rnO1Vo3JgdMXt+TI8MU3lwYwI=; b=OH+QRTSxxZ1qOIV0XY8nbncuYa9maITuEDMIn0AupqlRngRGci9ten2MGXOMUueHKV lK1LzjtdFtg00eTXdguPHigYYBOKuheGxcM12tdgmfOwawE/AdxrAFqWzbSarc9guMoS cyVXNoru4Sw4TpFOXN1e1jY+rMUKhP+TZH+/q4r0LfskWv5c8ChsQ3xIO/1efENrNgut wonqDOa9Mt0yzv/63DMQHbkRyncphYAEljY1ZI85l6KYX5/MElZJuxbUjOOTEQP2nbcp 01DGolyaokYU5w7Ktl5Q84gxkt3uC5N/ZY6wkMM17HuhdXT4cPr6kvJEY+0VjjcfO42B lwow== X-Gm-Message-State: APjAAAWiRf2jTmMMn9zgjuAS8jMKHdazj1PRgjGGvb5n4d/8JPZh0b18 oT8HUVfr7KdKSWV0R7bzKs36xs9T75wn2GeX X-Google-Smtp-Source: APXvYqzhXgGiQfD8GdEKM3TfLkShKyER6q2Y4GYrqA/sSXc34SLt3sPtoEbD8MKXRsOodCl15WBLOg== X-Received: by 2002:ae9:e710:: with SMTP id m16mr1215076qka.242.1580974607391; Wed, 05 Feb 2020 23:36:47 -0800 (PST) Received: from [5.5.33.70] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id f28sm996069qkk.130.2020.02.05.23.36.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Feb 2020 23:36:46 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 6 Feb 2020 08:36:45 +0100 References: <19B416A1-2605-4EA1-9E89-744C17B35F2E@sn3rd.com> To: TLS List In-Reply-To: Message-Id: <979E6C54-C8BC-4DF9-A4CF-6D5F4EAC86DC@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] code point assignments for draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 07:36:51 -0000 Just an FYI, I sent the message to the DEs just now. spt > On Jan 27, 2020, at 05:44, Sean Turner wrote: >=20 > FYI - Ben has, rightly, pointed out that we cannot request that TLS = DEs set the Recommended column to =E2=80=9CY=E2=80=9D until the draft is = published as a standards track RFC. So, when the request is sent to the = DEs the value will be =E2=80=9CN=E2=80=9D, but we will request that IANA = change it during AUTH48. I do not believe this will impact the = extension=E2=80=99s deployment, but I wanted to make sure the WG (and = DEs) are aware that when we first request the assignment that the = request of the TLS DE=E2=80=99s will not exactly match the text in the = IANA considerations section. >=20 > Apologies for any confusion, >=20 > spt >=20 >> On Jan 22, 2020, at 12:17, Sean Turner wrote: >>=20 >> Hi! >>=20 >> The chairs want to determine whether we should ask for the = assignments requested in draft-ietf-tls-subcerts [0][1]. We believe the = draft is stable enough and that there is interest from multiple = implementers. Please let the WG know by 2359 UTC 05 February 2020 = whether you disagree with these code point allocations and why. >>=20 >> What follows are the two request of IANA; one for the TLS DEs and one = for the PKIX DE: >>=20 >> 1. TLS ExtensionType Registry Request >>=20 >> This document registers the "delegated_credentials" extension in the >> "TLS ExtensionType Values" registry. The "delegated_credentials" >> extension has been assigned a code point of TBD. The IANA registry >> lists this extension as "Recommended" (i.e., "Y") and indicates that >> it may appear in the ClientHello (CH), CertificateRequest (CR), or >> Certificate (CT) messages in TLS 1.3 [RFC8446]. >>=20 >> 2. SMI Security for PKIX Registry Request >>=20 >> This document also defines an ASN.1 module for the DelegationUsage >> certificate extension in Appendix A. IANA is requested to register >> an Object Identifier (OID) for the ASN.1 in "SMI Security for PKIX >> Module Identifier" arc. An OID for the DelegationUsage certificate >> extension is not needed as it is already assigned to the extension >> from Cloudflare's IANA Private Enterprise Number (PEN) arc. >>=20 >> Cheers, >>=20 >> Joe, Chris, and Sean >>=20 >> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ >> [1] https://github.com/tlswg/tls-subcerts >=20 From nobody Wed Feb 5 23:39:31 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB312012C for ; Wed, 5 Feb 2020 23:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 VEk79XEny2id for ; Wed, 5 Feb 2020 23:39:28 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9780120045 for ; Wed, 5 Feb 2020 23:39:28 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id h12so3797615qtu.1 for ; Wed, 05 Feb 2020 23:39:28 -0800 (PST) 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=1dktg6t+0zODqgZ2nyolx7s/RYYJAO9ttlsE5V7U6c4=; b=AGyXo90qQYKDaF7eEKjssMoAus0WniYydkkrZAYqmk6EDmA8pqJpDZtNmTVkrKWLYu d6qhkIRYH++IEaVqaH+dM9dw3so1WsnFLbmGkPIaB9KCjXdvo9sbsQDLNlBjxz7atIzf anHFoOj1Dp7x0XSXDRmoLb490sjOCxw1xRr8Q= 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=1dktg6t+0zODqgZ2nyolx7s/RYYJAO9ttlsE5V7U6c4=; b=kszRPICBnF/sw/1INk57ASDteI/76sRaEpg8aMYDuh5S0vvzFP67Dn3u2w55WtszFC ceGybj+WPv0F1lipLFbKYblhAae/hFrBwZnJsiQCIXmeLC25H4lZxALKxAP+cKNly5Ys qseRqi4Tp6ODkHPqOwZ1SRtrQaJPv8z0/8T8EoznZYF5Pkpcv0gkZzYwftx0oVDcsUzi hWw+AM/4Y/uIOCFTCrdk03KCxWBw7g8V1DCotbAYq+ws7bp5UaBnECU1uOn1w2q4BQ6R R051m7EJy4/pp/JPP++nObfdfhPYZwDBXsL64KUI0bTt7tRRGuUuSpHpHOud7ZTDrGeG sxSg== X-Gm-Message-State: APjAAAWmstzJDOoz6zA2JUtclGpPVQktTu89mY1KaW47AeNjEurIG/Wx GOwb7JVgN55iuAVT16eREHiCbAztehWJ25z9 X-Google-Smtp-Source: APXvYqxBA22TmRjGqA8djSX4G+MAcq+/7UfJcOyqS61PLobnJq8+UrJJYMtQKBcW6WHfLaz87q4rrg== X-Received: by 2002:aed:3fce:: with SMTP id w14mr1564703qth.0.1580974767805; Wed, 05 Feb 2020 23:39:27 -0800 (PST) Received: from [5.5.33.70] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id p19sm1245543qte.81.2020.02.05.23.39.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Feb 2020 23:39:27 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <83DFDA4B-CAD3-4BA2-8AFB-67775F2F3AE5@sn3rd.com> Date: Thu, 6 Feb 2020 08:39:25 +0100 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] Kickoff message for PSK DT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 07:39:31 -0000 Hi! As alluded to in my message on Friday, a DT (Design Team) [0] has been formed to document considerations for how to use the PSKs to avoid various attacks. There are lots of PSK-related issues, but the chairs would like to maintain focus on the topic at hand. Those that volunteered for the DT are as follows (in no particular order): Eric Resocorla Martin Thomson Colm MacCarthaigh Mohit Sethi Bjorn Hasse Jonathan Hoyland Russ Housley Mohamad Badra Chris Wood Benjamin Berdouche Oleg Pekar Owen Fiell Chris Wood has graciously offered to lead the DT. He=E2=80=99ll arrange the group emails, WebEx, etc. If the DT is still around at IETF107, which we both assume it will be, we would ask for a short status report on what has been discussed/agreed. Remember that "the output of a design team is input to a working group, not a final document. Thanks, Joe and Sean [0] https://ietf.org/about/groups/iesg/statements/design-teams/= From nobody Thu Feb 6 00:07:22 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA36120241 for ; Thu, 6 Feb 2020 00:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 W-7V-uz6zbX9 for ; Thu, 6 Feb 2020 00:07:19 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45ACA1200CE for ; Thu, 6 Feb 2020 00:07:19 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id z193so5331626iof.1 for ; Thu, 06 Feb 2020 00:07:19 -0800 (PST) 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=zueZDFPlFEthjZ055xgkh41G5AIqynygU/bFafvbAuk=; b=agPqdUjLWDeh2qDnh1ZpUS0O/0BQrAiLuwoKMMQxtyXjDOHWLMCbtpi+kqSb8cQPEc 4imms2e8mFNFV3dmMf6Hz8yc7+3ciLf44anlkhWfV0foNeTCy96bVD6e5LyI1wuPgOe5 FN+w5nYJUcG8kTKdiMRdz+YjdP83NDwcklnKYFs5r+rA3NVAdjOm9DQmnW8gNH8y9aFF WjVqYMxwb96RNS9rteXcm2E1pMU+s13VsKDwOwxhA09xa6Ek8rvjMq3BfcZOLj/Lddq7 SjuzwPbNjNuHCkADOkViEVbmpSHPhsp0kHkrt5FQft2l5MOVREnm+80T1WfcID+W6rZc 7k9w== 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=zueZDFPlFEthjZ055xgkh41G5AIqynygU/bFafvbAuk=; b=oVLQ9KK8H9Fmq2iwZDJn3fxpt9Y+GXmrezUKR7F+3FOM8uFWqMvUfN2rNKsvLMrKJp 0P+eOD3XlquC+cFD/yuYxlcBhS1qLLPhGx4eu5nCbLBPfd0jypKvqrDjmOJyAvnbq9aQ uAvWq4y9yT3KJJDmCpY0TLASkolPatVDkXPePJRc1/HWAUXGwKj0SSU2cgSXtovWFioy 6LSBDQoRcE1PC1yW90oadkay/YsSVjbl7say3nZVMC5mdTejorPBly8BXMh/cCEu+Pf5 4kiFSgvctQtB2Idbu5DuzIUM/L2uX0oWtsuuZNraDaqKVl8yvSXjDC+y5P+QhHwTBXsV OIkg== X-Gm-Message-State: APjAAAWltUYY3m48+jy1Cc1tIU64ZR4McX6Y9W/JE1OEtu7aHptJ+VFu Z0hbEHWlZy264/PdEcFCkKBRFoWYHeeORR6pmOcKshotQGQ= X-Google-Smtp-Source: APXvYqxxckR5dbqmX1oshNIjDyBQfyG4D4jC+TgNQHB74bV9eDE+j0LpCv/dL02bGD96tOQfPr0bXZdLcsp9o1Olncw= X-Received: by 2002:a6b:ec08:: with SMTP id c8mr31991701ioh.257.1580976438427; Thu, 06 Feb 2020 00:07:18 -0800 (PST) MIME-Version: 1.0 References: <83DFDA4B-CAD3-4BA2-8AFB-67775F2F3AE5@sn3rd.com> In-Reply-To: <83DFDA4B-CAD3-4BA2-8AFB-67775F2F3AE5@sn3rd.com> From: Rob Sayre Date: Thu, 6 Feb 2020 00:07:04 -0800 Message-ID: To: Sean Turner Cc: TLS List Content-Type: multipart/alternative; boundary="00000000000002c270059de3c3e4" Archived-At: Subject: Re: [TLS] Kickoff message for PSK DT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 08:07:21 -0000 --00000000000002c270059de3c3e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks for doing this. Could the TLS WG also form such a group for ESNI/ECHO? thanks, Rob On Wed, Feb 5, 2020 at 11:39 PM Sean Turner wrote: > Hi! > > As alluded to in my message on Friday, a DT (Design > Team) [0] has been formed to document considerations > for how to use the PSKs to avoid various attacks. > There are lots of PSK-related issues, but the chairs > would like to maintain focus on the topic at hand. > Those that volunteered for the DT are as follows > (in no particular order): > > Eric Resocorla > Martin Thomson > Colm MacCarthaigh > Mohit Sethi > Bjorn Hasse > Jonathan Hoyland > Russ Housley > Mohamad Badra > Chris Wood > Benjamin Berdouche > Oleg Pekar > Owen Fiell > > Chris Wood has graciously offered to lead the DT. > He=E2=80=99ll arrange the group emails, WebEx, etc. > > If the DT is still around at IETF107, which we both > assume it will be, we would ask for a short status > report on what has been discussed/agreed. Remember > that "the output of a design team is input to a > working group, not a final document. > > Thanks, > Joe and Sean > > [0] https://ietf.org/about/groups/iesg/statements/design-teams/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000002c270059de3c3e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for doing=C2=A0this.

Could the TLS WG also form such a group for ESNI/ECHO?

thanks,
Rob

<= /div>

On Wed, Feb 5, 2020 at 11:39 PM Sean Turner <sean@sn3rd.com> wrote:
Hi!

As alluded to in my message on Friday, a DT (Design
Team) [0] has been formed to document considerations
for how to use the PSKs to avoid=C2=A0 various attacks.
There are lots of PSK-related issues, but the chairs
would like to maintain focus on the topic at hand.
Those that=C2=A0 volunteered for the DT are as follows
(in no particular order):

Eric Resocorla
Martin Thomson
Colm MacCarthaigh
Mohit Sethi
Bjorn Hasse
Jonathan Hoyland
Russ Housley
Mohamad Badra
Chris Wood
Benjamin Berdouche
Oleg Pekar
Owen Fiell

Chris Wood has graciously offered to lead the DT.
He=E2=80=99ll arrange the group emails, WebEx, etc.

If the DT is still around at IETF107, which we both
assume it will be,=C2=A0 we would ask for a short status
report on what has been=C2=A0 discussed/agreed. Remember
that "the output of a design team is input to a
working group, not a final document.

Thanks,
Joe and Sean

[0] https://ietf.org/about/groups/iesg/st= atements/design-teams/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000002c270059de3c3e4-- From nobody Fri Feb 7 14:48:26 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1A91200FA for ; Fri, 7 Feb 2020 14:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 hm9My1wE6rCA for ; Fri, 7 Feb 2020 14:48:23 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71351200E6 for ; Fri, 7 Feb 2020 14:48:22 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id g12so961318ild.2 for ; Fri, 07 Feb 2020 14:48:22 -0800 (PST) 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=40/8+KuUdqqTidK8qmug6Bjld2bReJWdnkPZQ/5FPnI=; b=jkd71FTQWwfIHXV8YAdnobJ2w9kJJrLcDE+ogLQORoo5i440zyv/r2ak0j6ER4LtJZ yNWhbuZgEGQhd5+v8EkdB9cG5Oh8DUIevAIFmFaFcgTgb0sTJnJOslDgRYoNJh3/b6Wo odf+YqT0ECAhpE/7HAxHaIbmpToOpXNBpPvpHmrvLgbUpBvalLosAopPEhPFHihqbbMX 8POHNQmJoCpPHCbXjeeF63ST/GpSOKjYgQQad/R56AY/sdraMCMfBg6FYheOaSbYXewf ZWcM1n75g3TeNf+b7cD/MbDw0UDJWToBmsFoHxZRLusZRdJDzNtOecbVpe+iQD8biMbB /y1w== 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=40/8+KuUdqqTidK8qmug6Bjld2bReJWdnkPZQ/5FPnI=; b=cmRJmODP0kwIrv6ohy9pAZJHOpgGCGE3m9H76O+++rxEpwza6bVucmoFBhVp7dHerd fS0Iten/KO8OhTpqUkX8wuZvVHhhKJupSpLYpxa0obPgKHq7mBNpaKT829PmKXgr/1aM 5l7wdgmMr4CYOU3dUEViQQ8rg75XFbC8OJ8/RoWR2oLhSJtwJadOfoyqlg3Jdr8DMt0X cgG+AQ9wAOtMAovox+lmFuPmwO3FdIlUd1f5T4QgCJOf1EFuIcF3cRCiHo81CjlEhHYN HTrUcSDEmDvCodxPdxEAZ3s/DHhLlw/c4juYVI0FBQdru/IZhAo7dmYHaQqULVzXoqIm G7VQ== X-Gm-Message-State: APjAAAXSpTA+aV9SfqyiwUAfApk185omFsqQYpI6BkhLgGlexkLCVsHN 8Y4mZ9qMA4VxQe1Oh7XHbtwRrqQQbB8bCh70nXk= X-Google-Smtp-Source: APXvYqzySeNnM0ZeLPBPvma4TI+A0iaYLpfCNDGyoinQe6ABpGbJq7TVuWHkbSayu+AMh3mAObLz+f7f5if5hjj7qJ8= X-Received: by 2002:a92:9c1c:: with SMTP id h28mr1676150ili.189.1581115702237; Fri, 07 Feb 2020 14:48:22 -0800 (PST) MIME-Version: 1.0 References: <83DFDA4B-CAD3-4BA2-8AFB-67775F2F3AE5@sn3rd.com> In-Reply-To: <83DFDA4B-CAD3-4BA2-8AFB-67775F2F3AE5@sn3rd.com> From: Rob Sayre Date: Fri, 7 Feb 2020 14:48:11 -0800 Message-ID: To: Sean Turner Cc: TLS List Content-Type: multipart/alternative; boundary="000000000000c7df71059e042fe5" Archived-At: Subject: Re: [TLS] Kickoff message for PSK DT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:48:24 -0000 --000000000000c7df71059e042fe5 Content-Type: text/plain; charset="UTF-8" Just to correct some typos: On Wed, Feb 5, 2020 at 11:39 PM Sean Turner wrote: > Hi! > > As alluded to in my message on Friday, a DT (Design > Team) [0] has been formed to document considerations > for how to use the PSKs to avoid various attacks. > There are lots of PSK-related issues, but the chairs > would like to maintain focus on the topic at hand. > Those that volunteered for the DT are as follows > (in no particular order): > > Eric Resocorla > Eric Rescorla. > Martin Thomson > Colm MacCarthaigh > Mohit Sethi > Bjorn Hasse > Jonathan Hoyland > Russ Housley > Mohamad Badra > Chris Wood > Benjamin Berdouche > Oleg Pekar > Owen Fiell > Owen Friel. thanks, Rob --000000000000c7df71059e042fe5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to correct some typos:

On Wed, Feb 5, 2020 at 11:= 39 PM Sean Turner <sean@sn3rd.com&= gt; wrote:
Hi!
As alluded to in my message on Friday, a DT (Design
Team) [0] has been formed to document considerations
for how to use the PSKs to avoid=C2=A0 various attacks.
There are lots of PSK-related issues, but the chairs
would like to maintain focus on the topic at hand.
Those that=C2=A0 volunteered for the DT are as follows
(in no particular order):

Eric Resocorla

Eric Rescorla.
=C2=A0
Martin Thomson
Colm MacCarthaigh
Mohit Sethi
Bjorn Hasse
Jonathan Hoyland
Russ Housley
Mohamad Badra
Chris Wood
Benjamin Berdouche
Oleg Pekar
Owen Fiell

Owen Friel.=C2=A0
=
thanks,
Rob

--000000000000c7df71059e042fe5-- From nobody Fri Feb 7 15:16:27 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277C71200F7 for ; Fri, 7 Feb 2020 15:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 JY9HcJAlOIBc for ; Fri, 7 Feb 2020 15:16:24 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5E21200B3 for ; Fri, 7 Feb 2020 15:16:24 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id t26so1306221ioi.13 for ; Fri, 07 Feb 2020 15:16:24 -0800 (PST) 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=SmAWY16q4JneJM0TjTlTBR4e3Z8XeDVespdbKKv1aE4=; b=vElkg8VOGG6ifDWqaiMGevO6UFNU69f2es/qLoJRAKfsLO9Je1LH7wiaEO38dInCLw zQSyAHdUtl+ERWJbNW4DVSaylnk8jVyBpAQ37jAwQwpZMPTLvUyEvnSZeVSPwSWiuTtZ NteloDw9lYb4Pwi63zm3bMlFFpK24r6Y74uYk1+Xlu5M4Mq3CWvSUrvtpIYaOV9fKkSL C02RNXcjXUfiNtKp5bjpJL82IAhtYmaU8RKugIkZhkTxUJZPGwlz+UsyhEB0PnLuPEbj 6hSG2dBC94nDY4C6fPk8PC+N8ZUJatgRngCtZ8mXNMIgvE0j8lg0e2C92TjzOvzWFFtN BACw== 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=SmAWY16q4JneJM0TjTlTBR4e3Z8XeDVespdbKKv1aE4=; b=PwsHxcQ5vI0ucEqeqUxuJtGbPOOUqv6wUVImYRhtzQ63K+hzplDuZfR/XC0KEbdcot GDl4WJs6G32ae/slUZIw1ffv9y3TSSFJzQ1/zXRQ80QjVtXfv2S2iZxU0q4CIUVpyjv/ GB6r/1kpN2w7MYO66D4we7AIR0iUDh6muW+cZeiZtHs5A0EpamF+SBMsPQxnzs11jzwL P5xaLfKx8riyBl9tdhPgNsugKcejY48aZ0c5zuN7mRIiwkq2V0AL5uc3q+J/MnU1mN58 nBzj4AzryLuCTbCG2aDI8Z+iidf4mo88CTcSzs7JVY9NJ8VkbnRqQUOUcF/PBtKpKAYp Yb0w== X-Gm-Message-State: APjAAAWMPUMXY26lCLZLYSJ/bUTEHB4oFdaEfCmVRdzpN1R1grbhNhlf yAiR9nLOAqMdajQ5di42XEf8uRYgDQkHI19bHPc= X-Google-Smtp-Source: APXvYqwGHUoV4Q8PSFBUdalKu0meintl+uPcX5uPxKzOiWoP4DmXqxKdNOGmZUiGMPoWTtwyowKkUFumrp/ZYtvwE7I= X-Received: by 2002:a02:cbd9:: with SMTP id u25mr816292jaq.106.1581117383443; Fri, 07 Feb 2020 15:16:23 -0800 (PST) MIME-Version: 1.0 References: <83DFDA4B-CAD3-4BA2-8AFB-67775F2F3AE5@sn3rd.com> In-Reply-To: From: Rob Sayre Date: Fri, 7 Feb 2020 15:16:12 -0800 Message-ID: To: Sean Turner Cc: TLS List Content-Type: multipart/alternative; boundary="000000000000fd0b6e059e04932e" Archived-At: Subject: Re: [TLS] Kickoff message for PSK DT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 23:16:26 -0000 --000000000000fd0b6e059e04932e Content-Type: text/plain; charset="UTF-8" Additionally (sorry for the extra message): On Fri, Feb 7, 2020 at 2:48 PM Rob Sayre wrote: > Just to correct some typos: > > On Wed, Feb 5, 2020 at 11:39 PM Sean Turner wrote: > >> Hi! >> >> As alluded to in my message on Friday, a DT (Design >> Team) [0] has been formed to document considerations >> for how to use the PSKs to avoid various attacks. >> There are lots of PSK-related issues, but the chairs >> would like to maintain focus on the topic at hand. >> Those that volunteered for the DT are as follows >> (in no particular order): >> >> Eric Resocorla >> > > Eric Rescorla. > > >> Martin Thomson >> Colm MacCarthaigh >> Mohit Sethi >> Bjorn Hasse >> Jonathan Hoyland >> Russ Housley >> Mohamad Badra >> Chris Wood >> Benjamin Berdouche >> > Benjamin Beurdouche > Oleg Pekar >> Owen Fiell >> > > Owen Friel. > > thanks, > Rob > > --000000000000fd0b6e059e04932e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Additionally (sorry for the extra message= ):

On Fri, Feb 7, 2020 at 2:48 PM Rob Sayre <sayrer@gmail.com> wrote:
Just to correct some typos:
On= Wed, Feb 5, 2020 at 11:39 PM Sean Turner <sean@sn3rd.com> wrote:
Hi!

As alluded to in my message on Friday, a DT (Design
Team) [0] has been formed to document considerations
for how to use the PSKs to avoid=C2=A0 various attacks.
There are lots of PSK-related issues, but the chairs
would like to maintain focus on the topic at hand.
Those that=C2=A0 volunteered for the DT are as follows
(in no particular order):

Eric Resocorla

Eric Rescorla.
=C2=A0
Martin Thomson
Colm MacCarthaigh
Mohit Sethi
Bjorn Hasse
Jonathan Hoyland
Russ Housley
Mohamad Badra
Chris Wood
Benjamin Berdouche

=
Benjamin Beurdouche
=C2=A0
Oleg Pekar
Owen Fiell

Owen Friel.=C2=A0
=
thanks,
Rob

--000000000000fd0b6e059e04932e-- From nobody Sat Feb 8 23:32:44 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D111200B3 for ; Sat, 8 Feb 2020 23:32:40 -0800 (PST) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=R+wVA4Zh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=v88JI87m Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DZRbK50pvou for ; Sat, 8 Feb 2020 23:32:38 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57111200CD for ; Sat, 8 Feb 2020 23:32:37 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 47D7721D73 for ; Sun, 9 Feb 2020 02:32:37 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 09 Feb 2020 02:32:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=fD7Q0IzMkCu6JuxDh/ENYCozXL07Kw3yv25Jb/0SuQk=; b=R+wVA4Zh DbRomcZajuev6jVAGJtmkFf+mtw53TgR2lFe9evpLnS/EGbEfVbC6jysVMDYOF/m +RCY7CcYyttGL3UVoebH2xGm7xwrblKEr4ffOWjlp0c3m+YZldRzw42+GIEzEjQ0 lThbmyavyEjzEVdqKM45JNvz50HMKSuWcz/pjJz9Mknce3hPY5tRzWgMJ3Ipvctz QjBMc9iJ7lNOYCU1SGdpi1OFll3v1TaN1sAm2fwBXPO2nYCZcnye10LiRlL1Yapn MprUwLSPHoDvOyzHArPagLckOQJBIIQ/A3VtlzZSKp7Il7J8RIH97I7GPliZSojQ lMVl3/YBqOIx2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=fD7Q0IzMkCu6JuxDh/ENYCozXL07K w3yv25Jb/0SuQk=; b=v88JI87mYL+v2BlXpd0v5KbsoI5TZBps5eeG41qZTHc4n bXE4wiqBd6pVSm60WNHIiBztlUcldv2H0poi/FfAF/zUiVOQhwpuQzT/y08iVbmD WgKpczOgjDOYzxwlQvnzdrdwgMpE6F8IJSOxNg29aRNao+EKwDuiQJjyDEiiHOrP TTzxwE4UKCLbH+pqxomqLS0Igzq7lyF5jxGBvmSwcTCPY0zBx1dKGee4x53E6GPR z9xonNqP/sl1RMVxswFX32hItuEgpdYXpDGtCKnasOMF22aoFcpWdcuscwmDKUKX nzUdw2bcQTjHssEbYABMMRM+SNAxruA7ay/bSSB8Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheekgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepgedtrdduvddurdduieeirdeifeenucevlhhushht vghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.121.166.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 11BFF30606E9 for ; Sun, 9 Feb 2020 02:32:37 -0500 (EST) Content-Type: multipart/alternative; boundary="===============7426344894382341973==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200209073237.11BFF30606E9@mailuser.nyi.internal> Date: Sun, 9 Feb 2020 02:32:37 -0500 (EST) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 07:32:41 -0000 --===============7426344894382341973== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC0) 1 issues created: - Suggestion to support user@domain.name (by vanrein) https://github.com/tlswg/draft-ietf-tls-esni/issues/206=20 * tlswg/tls-flags (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #1 63 or 247? (2 by chris-wood, yoavnir) https://github.com/tlswg/tls-flags/issues/1=20 * tlswg/tls-subcerts (+1/-2/=F0=9F=92=AC2) 1 issues created: - Change the ASN.1 module request to IANA (by grittygrease) https://github.com/tlswg/tls-subcerts/issues/48=20 2 issues received 2 new comments: - #48 Change the ASN.1 module request to IANA (1 by chris-wood) https://github.com/tlswg/tls-subcerts/issues/48=20 - #41 Assign codepoint for delegated_credentials extension (1 by chris-wo= od) https://github.com/tlswg/tls-subcerts/issues/41=20 2 issues closed: - Assign codepoint for delegated_credentials extension https://github.com= /tlswg/tls-subcerts/issues/41=20 - Change the ASN.1 module request to IANA https://github.com/tlswg/tls-su= bcerts/issues/48=20 Pull requests ------------- * tlswg/tls-flags (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Make section 2 and IANA cons agree on flag count https://github.com/tlswg/tls-flags/pull/2=20 * tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Added Clarification regarding the message_seqnr use (by hannestschofeni= g) https://github.com/tlswg/dtls13-spec/pull/117=20 * tlswg/dtls-conn-id (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Corrected reference to the RRC draft (by hannestschofenig) https://github.com/tlswg/dtls-conn-id/pull/71=20 * tlswg/tls-subcerts (+3/-3/=F0=9F=92=AC0) 3 pull requests submitted: - Fix nits. (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/50=20 - Switch module definition to PKIX arc. (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/49=20 - Add IANA extension point, change module namespace. (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/47=20 3 pull requests merged: - Fix nits. https://github.com/tlswg/tls-subcerts/pull/50=20 - Switch module definition to PKIX arc. https://github.com/tlswg/tls-subcerts/pull/49=20 - Add IANA extension point, change module namespace. https://github.com/tlswg/tls-subcerts/pull/47=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============7426344894382341973== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday February 09, 2020

Issues

tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC0)

1 issues created:

tlswg/tls-flags (+0/-0/=F0=9F=92=AC2)

1 issues received 2 new comments:

tlswg/tls-subcerts (+1/-2/=F0=9F=92=AC2)

1 issues created:

2 issues received 2 new comments:

2 issues closed:

Pull requests

tlswg/tls-flags (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

tlswg/dtls-conn-id (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

tlswg/tls-subcerts (+3/-3/=F0=9F=92=AC0)

3 pull requests submitted:

3 pull requests merged:

Repositories tracked by this digest:

--===============7426344894382341973==-- From nobody Mon Feb 10 07:59:01 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AE1120103 for ; Sun, 9 Feb 2020 06:02:51 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 Xt6UUcUyv2c2 for ; Sun, 9 Feb 2020 06:02:49 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C670012001B for ; Sun, 9 Feb 2020 06:02:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id A8C534552F for ; Sun, 9 Feb 2020 16:02:45 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id k2VM9EIUh03O for ; Sun, 9 Feb 2020 16:02:44 +0200 (EET) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 28C2A2315 for ; Sun, 9 Feb 2020 16:02:42 +0200 (EET) Date: Sun, 9 Feb 2020 16:02:42 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20200209140242.GA1489626@LK-Perkele-VII> References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <158093501262.12877.10966121264461280401@ietfa.amsl.com> Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 14:02:52 -0000 On Wed, Feb 05, 2020 at 12:36:52PM -0800, internet-drafts@ietf.org 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 WG of the IETF. > > Title : Delegated Credentials for TLS > Authors : Richard Barnes > Subodh Iyengar > Nick Sullivan > Eric Rescorla > Filename : draft-ietf-tls-subcerts-06.txt > Pages : 15 > Date : 2020-02-05 I noticed the following: > The algorithm and expected_cert_verify_algorithm fields MUST be of a > type advertised by the client in the SignatureSchemeList and are > considered invalid otherwise. Clients that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. This can be interpretted that the delegated_credentials extension constrains the end-entity certificate algorithm if DC is sent. This has seemingly undesirable consequences if the list diverges from what the signature_algorithms contains: 1) If delegated_credentials contains algorithm that signature_algorithms does not, the server may use that as DC signing algorithm, which will cause PKIX code to blow up. 2) If delgated_credentials is missing some algorithm that signature_algorithms contains, the client needs to constrain the PKIX validation further. These issues are made worse by the fact that delegated credential validation code is seemingly intended to be separate from PKIX validation code, meaning the two can diverge from one another (which is a reason for having separate lists). Looking at the steps to validate the delegated credential, there is no explicit step to validate signing algorithm, which would imply that the signing algorithm is constrained by the PKIX code, which would contradict the above. Then because *_rsae is not allowed in expected algorithm, clients would need to include algorithm that can not be used, if they support *_rsae for PKIX signatures (however, there could be reasons not to support *_rsae for signing DCs, see below). And: > The algorithm and expected_cert_verify_algorithm fields MUST be of a > type advertised by the server in the "signature_algorithms" extension > and are considered invalid otherwise. Servers that receive invalid > delegated credentials MUST terminate the connection with an > "illegal_parameter" alert. Is there a reason why client can specify another set of algorithms for verification of delegated credentials, but the server can not? Then in security considerations, I do not see the following issue discussed: - Server has RSA key that has delegation_usage and is usable for RSA encryption. - Server is vulernable to BB98/ROBOT. - Attacker uses BB98/ROBOT to sign a delegated credential. - Attacker impersonates the server using the forged delegated credential. It is much easier to perform this kind of attack than to use BB98/ROBOT to impersonate without delgated credentials: - Much longer time window to perform the attack (limited by certificate lifetime, not how long client waits). - One can impersonate server multiple times per successful attack, not just once. This could be generalized to any signing oracle, but the ones associated with RSA encryption (BB98/ROBOT/DROWN) are the most common ones. -Ilari From nobody Mon Feb 10 08:33:22 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EA3120816 for ; Mon, 10 Feb 2020 08:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 B4P67mRxkgtz for ; Mon, 10 Feb 2020 08:33:12 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F509120860 for ; Mon, 10 Feb 2020 08:33:12 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id c24so5575930qtp.5 for ; Mon, 10 Feb 2020 08:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ABLjEY8njoQUlcGPRSlzACz6PNneKRxy3iDmyDDhHP0=; b=mscr2qBrDHA5xq493CpLQQ0B5LZUw50bFCUo3yqlTf+W7+cxdXQr2MwGdRnlC+t5Wn I8FIdvMj+jEMOFPen7jfYS22fbSYd5Yqp/romL9ieuTfm+keBSGkqUNXDqOncwAzFgYa mDX/J0xN+slJqgNzLbBLL0nPEs7Mm1l4LUjo8= 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=ABLjEY8njoQUlcGPRSlzACz6PNneKRxy3iDmyDDhHP0=; b=sgps6Qji9/+H1jHLQlxI1vEoRZydP4uNVMwIe/6Gx4epVrOkm7nwZnYs1fYPIXdTxr KVx5vkaRsdY2W0b2QxHBgSJXaSPCGwEQHhWT30Pv0Wn/ZzzEKpVUm2Q7b4Y8Ud5NndCg ngJFDxmMUos2m/O8KRCXOEmW7+PIXJiQ6hcsp2GYoFGB8bdJvYaW30q8QtVCk57LXUyi Umctlq4si2zLRRa1MBHMOiDaPN44Gq2myysEimpZ9dEOoDTpBjbobEaYfip2Z60WfoYV uLnh0eNhs79MnDw0eY+DULR+PTocyl8E40VRW1yU9eybKlSrSQI41gotot0Dubk2fC2j UgaA== X-Gm-Message-State: APjAAAV+9ZXy4ZYgbvXd207zHnf7ntFH64MSqiwEEv5IgZGjIEC3fTtu QdooowPZvgdEUN2XbyRDYpzanZDiIOCIQzSU4K34IsHzKFeWFA== X-Google-Smtp-Source: APXvYqwA9bI45T87S+N6jC4lxZxPGXH9bF6wgl15kG+yQbqOcv3kJ76F/Vl4UGSscjmjgu95HF24OjiLbVGVYnNX6/Q= X-Received: by 2002:ac8:4b6f:: with SMTP id g15mr10746288qts.196.1581352390995; Mon, 10 Feb 2020 08:33:10 -0800 (PST) MIME-Version: 1.0 References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> <20200209140242.GA1489626@LK-Perkele-VII> In-Reply-To: <20200209140242.GA1489626@LK-Perkele-VII> From: Watson Ladd Date: Mon, 10 Feb 2020 08:33:00 -0800 Message-ID: To: Ilari Liusvaara Cc: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 16:33:20 -0000 On Mon, Feb 10, 2020 at 7:59 AM Ilari Liusvaara wrote: > > On Wed, Feb 05, 2020 at 12:36:52PM -0800, internet-drafts@ietf.org 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 WG of the IETF. > > > > Title : Delegated Credentials for TLS > > Authors : Richard Barnes > > Subodh Iyengar > > Nick Sullivan > > Eric Rescorla > > Filename : draft-ietf-tls-subcerts-06.txt > > Pages : 15 > > Date : 2020-02-05 > > I noticed the following: > > > The algorithm and expected_cert_verify_algorithm fields MUST be of a > > type advertised by the client in the SignatureSchemeList and are > > considered invalid otherwise. Clients that receive invalid delegated > > credentials MUST terminate the connection with an "illegal_parameter" > > alert. > > This can be interpretted that the delegated_credentials extension > constrains the end-entity certificate algorithm if DC is sent. This has > seemingly undesirable consequences if the list diverges from what the > signature_algorithms contains: > > 1) If delegated_credentials contains algorithm that signature_algorithms > does not, the server may use that as DC signing algorithm, which will > cause PKIX code to blow up. > > 2) If delgated_credentials is missing some algorithm that > signature_algorithms contains, the client needs to constrain the PKIX > validation further. > > These issues are made worse by the fact that delegated credential > validation code is seemingly intended to be separate from PKIX validation > code, meaning the two can diverge from one another (which is a reason > for having separate lists). I think the intent of the change was to make two separate lists so the TLS implementation could implement new signature schemes and DCs with those keys could be issued, while being signed by existing certs that would be selected based on what the PKIX library allows. The PKIX library is only checking the validity of the EE certificate and the chain to the root, the signature by the EE certificate on the DC is only being checked by the TLS library. The PKIX library never sees the DC, and what is in delegated_credentials doesn't matter for the EE to root verification. > > Looking at the steps to validate the delegated credential, there is > no explicit step to validate signing algorithm, which would imply that > the signing algorithm is constrained by the PKIX code, which would > contradict the above. > > Then because *_rsae is not allowed in expected algorithm, clients would > need to include algorithm that can not be used, if they support *_rsae > for PKIX signatures (however, there could be reasons not to support > *_rsae for signing DCs, see below). > > > And: > > > The algorithm and expected_cert_verify_algorithm fields MUST be of a > > type advertised by the server in the "signature_algorithms" extension > > and are considered invalid otherwise. Servers that receive invalid > > delegated credentials MUST terminate the connection with an > > "illegal_parameter" alert. > > Is there a reason why client can specify another set of algorithms for > verification of delegated credentials, but the server can not? > > > Then in security considerations, I do not see the following issue > discussed: > > - Server has RSA key that has delegation_usage and is usable for > RSA encryption. > - Server is vulernable to BB98/ROBOT. > - Attacker uses BB98/ROBOT to sign a delegated credential. > - Attacker impersonates the server using the forged delegated > credential. > > It is much easier to perform this kind of attack than to use BB98/ROBOT > to impersonate without delgated credentials: > > - Much longer time window to perform the attack (limited by certificate > lifetime, not how long client waits). > - One can impersonate server multiple times per successful attack, not > just once. > > This could be generalized to any signing oracle, but the ones > associated with RSA encryption (BB98/ROBOT/DROWN) are the most common > ones. Should we explicitly prohibit including the credential and supporting RSA decryption? Unfortunately I seem to recall PKIX doesn't have a way to do this because of widespread compatibility issues. Sincerely, Watson Ladd > > > > > > -Ilari > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Feb 11 22:27:07 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01755120879 for ; Tue, 11 Feb 2020 22:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 3xBUZWPhD1Qw for ; Tue, 11 Feb 2020 22:27:01 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0298F120052 for ; Tue, 11 Feb 2020 22:27:01 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id k188so448804vsc.8 for ; Tue, 11 Feb 2020 22:27:00 -0800 (PST) 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=ChTr0xe2Jtyq3aPxkk4SEVkQd+3cPTHvByFDZ+aSntk=; b=cv29QoO51rCSt9GgRakk+zyJJQjxmYvHo5Rur0wxM/0TAJ/By09xCnwHypRE8jbd6b lg6x1kFfdbsSiMgTwq8lgmnea3WmN27kn8Zeldkx3dI+8b5aRepZgkwICPFODGoapHqY wg3gzrliqDGLpPXZpwTM38DmTUNQjDFWPsRyamX8Yzd2LDbsyjIImtNGeaIs+WZKxGwD /URUTRuowm318kBkZHOEHsKWq1NvVJBJMu0RMKJzlhSMnyCAcyNLe7uVw8u/tHZgnqNY wS2WqQo/3Z1Le4TuQpVatsk6IJsNLKmRrk2QAoDYvv4iDgv3hSm1ReXxAthorBFNCpo+ XvEA== 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=ChTr0xe2Jtyq3aPxkk4SEVkQd+3cPTHvByFDZ+aSntk=; b=YdsXyKO4P29u6ciP7R28CRyQRcB+0WdR2a0OEbnbt7R7LUQcg+OoJJBIhR6L1ik96g w1p0dfIMxirkdOVvPTdJuOQhneGj8LDsb4qcubs2Y4njKiAkyAIHEgP1NZYpTuIT8z6q mEkZG/fJSrjKgMBBmtk7T9qh4119+zBhHdRiUzs9aFiISRnFPQDAfldh9lpbtztPZPcy oPfSagA89K/d+MI1XFu6XvQgD443KCUw9D1qUi4n0jQFcCdw18za8vmBXO4PEI6pLQ/W pOAkS6DVfZNdCIohpD2vVM1FnyoiqeZM8UDV2IvIFUDco3oHYV17FQn2K+BZGZYs48We 80Gw== X-Gm-Message-State: APjAAAULk5rakokN5y010VEV3qN6XX2bQtYQCQ1THei222k0CG0rz74m 6+UetogluqPyRPZVWY/zgADbljgVRm42Zr1RLf6qVdM4jgQ= X-Google-Smtp-Source: APXvYqwM3PK31BxASRGU/95MLQ70Pk+YxIx6up2juRwBAe5I/7bIXmT7OaSop4jzN3AGeLIklLRSMeP10dxViRSDGM4= X-Received: by 2002:a67:ecd5:: with SMTP id i21mr11328172vsp.166.1581488818835; Tue, 11 Feb 2020 22:26:58 -0800 (PST) MIME-Version: 1.0 From: M K Saravanan Date: Wed, 12 Feb 2020 14:26:47 +0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="00000000000043572e059e5b0f8f" Archived-At: Subject: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 06:27:05 -0000 --00000000000043572e059e5b0f8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I recently encountered the below issue: TLS1.2 ECDHE_RSA server certificate: 2048-bit RSA (=3D 256 bytes) ServerKeyExchange hash/sign algorithm: rsa_pkcs1_sha1 The server was sending the ServerKeyExchange with 255 byte as length for the RSA signature (i.e. the leading zero was stripped) instead of 256 like this: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Handshake Protocol: Server Key Exchange Handshake Type: Server Key Exchange (12) Length: 328 EC Diffie-Hellman Server Params Curve Type: named_curve (0x03) Named Curve: secp256r1 (0x0017) Pubkey Length: 65 Pubkey: 042206562efea8bd47bf014a9e650c42f27078643c553671=E2=80=A6 Signature Algorithm: rsa_pkcs1_sha1 (0x0201) Signature Length: 255 Signature: d1bf915eca2ec0bcdda6f90a398fe5378d2028a22574d213=E2=80= =A6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Is this allowed? i.e. stripping the leading zero of the RSA signature and marking the length as 255? It is not clear to me from the RFC5246 whether it is allowed or not. (client was failing to verify the signature due to this). with regards, Saravanan --00000000000043572e059e5b0f8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I recently encountered the below is= sue:

TLS1.2
ECDHE_RSA
server c= ertificate: 2048-bit RSA (=3D 256 bytes)
ServerKeyExchange hash/s= ign algorithm:=C2=A0rsa_pkcs1_sha1

The server was = sending the ServerKeyExchange with 255 byte as length for the RSA signature= (i.e. the leading zero was stripped) instead of 256 like this:
<= br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /div>
Handshake Protocol: Server Key Exchange
=C2=A0 =C2=A0 Handshak= e Type: Server Key Exchange (12)
=C2=A0 =C2=A0 Length: 328
=C2=A0 =C2= =A0 EC Diffie-Hellman Server Params
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Curve Ty= pe: named_curve (0x03)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Named Curve: secp256r= 1 (0x0017)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pubkey Length: 65
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Pubkey: 042206562efea8bd47bf014a9e650c42f27078643c553671= =E2=80=A6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Signature Algorithm: rsa_pkcs1_sha= 1 (0x0201)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Signature Length: 255
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Signature: d1bf915eca2ec0bcdda6f90a398fe5378d2028a2257= 4d213=E2=80=A6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Is this allowed?=C2=A0 i.e. stripp= ing the leading zero of the RSA signature and marking the length as 255?=C2= =A0 =C2=A0It is not clear to me from the RFC5246 whether it is allowed or n= ot.

(client was failing to verify the signature du= e to this).

with regards,
Saravanan

--00000000000043572e059e5b0f8f-- From nobody Tue Feb 11 22:53:50 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BF812006B for ; Tue, 11 Feb 2020 22:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 UXu6aZihqtNq for ; Tue, 11 Feb 2020 22:53:46 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9C9120052 for ; Tue, 11 Feb 2020 22:53:46 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id d5so456103pjz.5 for ; Tue, 11 Feb 2020 22:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AYKB5yo59nWTNao5HreJF309H0IcjQWmgSjPNGf4Y9s=; b=d48+yfDRygKAgP5o/v7RPCIhP8ItaxbQovfWQrtgDmDR+KDXdAeC2sWNZ+zWYbEMs6 eAjexjKqFB9TCtv3pRAJq73L7nBX+XCR6moAIRVb7ERTieO8tuibjd2zNJ4rYUb3FU0m 9kGcNnJZ1Ubc1Yec4jBWVylIyC592A1A9yit0= 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=AYKB5yo59nWTNao5HreJF309H0IcjQWmgSjPNGf4Y9s=; b=ez4jwwIq5eTS1S0CqdlheeAbtvgLPcKdbQqRlhwMWFtqfxULLaUQdgW4F0kWnu61gl EMS46qnjhAiejCHjLF3vmXutYfgu54mKOqo1L53jnR2QdGlPIwdHAshUANciG1hK+qhi 5NswgB8Vfnyx1h8y5WCmRBbdXi07intCcx8xqSkuLdggf1LxA2d1ai+fkUncF0SPXMoD T/YDhWGAEgiw9QRioAkB4Fm1X6e1671JGhmOUUYqsm8vqH0qKG/ruIschoxSVheFiwGM ULZZCJI/2YFoSSrv/XkupSN19WEveoOEt3JKRfXLlO+/7j34bQIPb6QBIttxUIOPD+ov dfvA== X-Gm-Message-State: APjAAAXE+KzHdqoIwfR5yckjn0XU1cHgH9FWos/wFbsvK35gBLwi+BOs yoa+NivQFsQRf2BkNv6XSkpzPsYKJKFg+67j1t1Z X-Google-Smtp-Source: APXvYqx0bl7mqXbYNXdkVRcd93/HhFIvka0PJaqyIT/MpgoMQOGnX3tJqgvqVr+JWAtKgQ+QkH62tWTLyQPPMQahJKk= X-Received: by 2002:a17:902:694b:: with SMTP id k11mr6926202plt.334.1581490425884; Tue, 11 Feb 2020 22:53:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 12 Feb 2020 01:53:29 -0500 Message-ID: To: M K Saravanan Cc: "" Content-Type: multipart/alternative; boundary="0000000000000d569c059e5b6f49" Archived-At: Subject: Re: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 06:53:48 -0000 --0000000000000d569c059e5b6f49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The signature is invalid. The client is correct to reject it, and the server is incorrect to produce it. RFC5246 cites PKCS1 (then RFC3447, now RFC8017). Both versions spell out the signing and verifying operations explicitly. The signing operation must produce a fixed-width output and the verification operation must reject incorrectly-sized inputs: https://tools.ietf.org/html/rfc3447#section-8.2.1 https://tools.ietf.org/html/rfc3447#section-8.2.2 https://tools.ietf.org/html/rfc8017#section-8.2.1 https://tools.ietf.org/html/rfc8017#section-8.2.2 On Wed, Feb 12, 2020 at 1:27 AM M K Saravanan wrote: > Hi, > > I recently encountered the below issue: > > TLS1.2 > ECDHE_RSA > server certificate: 2048-bit RSA (=3D 256 bytes) > ServerKeyExchange hash/sign algorithm: rsa_pkcs1_sha1 > > The server was sending the ServerKeyExchange with 255 byte as length for > the RSA signature (i.e. the leading zero was stripped) instead of 256 lik= e > this: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Handshake Protocol: Server Key Exchange > Handshake Type: Server Key Exchange (12) > Length: 328 > EC Diffie-Hellman Server Params > Curve Type: named_curve (0x03) > Named Curve: secp256r1 (0x0017) > Pubkey Length: 65 > Pubkey: 042206562efea8bd47bf014a9e650c42f27078643c553671=E2=80=A6 > Signature Algorithm: rsa_pkcs1_sha1 (0x0201) > Signature Length: 255 > Signature: d1bf915eca2ec0bcdda6f90a398fe5378d2028a22574d213=E2=80= =A6 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Is this allowed? i.e. stripping the leading zero of the RSA signature an= d > marking the length as 255? It is not clear to me from the RFC5246 wheth= er > it is allowed or not. > > (client was failing to verify the signature due to this). > > with regards, > Saravanan > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000000d569c059e5b6f49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The signature is invalid. The client is correct to reject = it, and the server is incorrect to produce it.

RFC5246 c= ites PKCS1 (then RFC3447, now RFC8017). Both versions spell out the signing= and verifying operations explicitly. The signing operation must produce a = fixed-width output and the verification operation must reject incorrectly-s= ized inputs:

On Wed, Feb 12, 2020 at 1:27 AM M K Saravanan <= ;mksarav@gmail.com> wrote:
<= /div>
Hi,=

I recently encountered the below issue:

<= /div>
TLS1.2
ECDHE_RSA
server certificate: 2048-bit= RSA (=3D 256 bytes)
ServerKeyExchange hash/sign algorithm:=C2=A0= rsa_pkcs1_sha1

The server was sending the ServerKe= yExchange with 255 byte as length for the RSA signature (i.e. the leading z= ero was stripped) instead of 256 like this:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Handshake = Protocol: Server Key Exchange
=C2=A0 =C2=A0 Handshake Type: Server Key E= xchange (12)
=C2=A0 =C2=A0 Length: 328
=C2=A0 =C2=A0 EC Diffie-Hellma= n Server Params
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Curve Type: named_curve (0x0= 3)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Named Curve: secp256r1 (0x0017)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 Pubkey Length: 65
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pubk= ey: 042206562efea8bd47bf014a9e650c42f27078643c553671=E2=80=A6
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Signature Length: 255
=C2=A0 =C2=A0 =C2=A0 =C2=A0 S= ignature: d1bf915eca2ec0bcdda6f90a398fe5378d2028a22574d213=E2=80=A6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Is this allowed?=C2=A0 i.e. stripping the leading zero of= the RSA signature and marking the length as 255?=C2=A0 =C2=A0It is not cle= ar to me from the RFC5246 whether it is allowed or not.

(client was failing to verify the signature due to this).
<= br>
with regards,
Saravanan

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000000d569c059e5b6f49-- From nobody Tue Feb 11 23:14:11 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B5012088A for ; Tue, 11 Feb 2020 23:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 IGgxa7jv6Xfx for ; Tue, 11 Feb 2020 23:14:06 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF6E120889 for ; Tue, 11 Feb 2020 23:14:06 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id h32so490004uah.4 for ; Tue, 11 Feb 2020 23:14:06 -0800 (PST) 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=pKbx5302u8+4HoV9O5E3l4X+IaudPToy2K2RFI6pATk=; b=imMiKTv2YWtMJsl9L3qIw/0E6U1eOznXHBMif1oTnGRmnZeXk4f04OAV7ekNlBT7Uf RKkX4G4mZnr+XTkg3fdXAGu3NhGk4BPd7i3JBOvY3Ey9W1q83r1M2myhkBKBETZ5psq9 qsWlU3g8mjjjVMy5AYr58+JIHUT6bQ/kl0tPf4duHZY9CkyW27AxuZf5bDGWZAdnUZTO jg+IrC+w4uInegEewE4pbtgD/UQ2BUkgJqo2aPAoyQrnxaxbeWGKZbq62pJsxxG+DUO7 NSWX64lcuWP/wKqOrgNHXaDwFg0XGgoZrfkzWb2VVLqosU+CauzyavjfXTZ2pO9uh6oB XB4Q== 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=pKbx5302u8+4HoV9O5E3l4X+IaudPToy2K2RFI6pATk=; b=Bxm4oU7Kzds6n71MjP6emX5AKRYxOS4W95Dkk2+LhGBrN/PlsUPPs9BlSVoobXRPHx cV9M/4MrkKHRcZ9ikN7AAcERt4TVA0T88pUnPXtkgCSO1BndW9LOqeJxNPWwb499+Pvc bGNdUIQ0ffkSorueenIACf2Vc6Do5FNec6XtmiwBvJ/8p/IdycctBTmytRu5iKsqZACz P7L9B8lN9nG/QtWOyB+gHKcTfrwOayKi3ZuCv1+PMfUhv4dWsPeCpwZVDCMFTfrEiEUb z9bpyP8+qfkk7e+H2hP5NJnY5DC9XGIVQLzuCdQrJs5nK2GxEIeWjcxs7ahSQ+hIzsM9 DYhQ== X-Gm-Message-State: APjAAAVKF5Pb37PVK870JOFWn9gzw+XX7bEkwMtDuxbaJwYGEewyNRjC gxL6qILfg/hnaqsGKGK8Ax/sQ5IG40T6m2i9KloIPAu9 X-Google-Smtp-Source: APXvYqyP8iYgn8WwLffff3QkAFYmIVfixsd8vNlgB3mguRxHucx6L/SGuR+50UcDs94Pa3InpLd3NYxWR1Y1myLHU7c= X-Received: by 2002:ab0:18a1:: with SMTP id t33mr3919094uag.123.1581491645303; Tue, 11 Feb 2020 23:14:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: M K Saravanan Date: Wed, 12 Feb 2020 15:13:54 +0800 Message-ID: To: David Benjamin Cc: "" Content-Type: multipart/alternative; boundary="000000000000bbce46059e5bb7d8" Archived-At: Subject: Re: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 07:14:09 -0000 --000000000000bbce46059e5bb7d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks David for the clarification. with regards, Saravanan On Wed, 12 Feb 2020 at 14:53, David Benjamin wrote: > The signature is invalid. The client is correct to reject it, and the > server is incorrect to produce it. > > RFC5246 cites PKCS1 (then RFC3447, now RFC8017). Both versions spell out > the signing and verifying operations explicitly. The signing operation mu= st > produce a fixed-width output and the verification operation must reject > incorrectly-sized inputs: > https://tools.ietf.org/html/rfc3447#section-8.2.1 > https://tools.ietf.org/html/rfc3447#section-8.2.2 > https://tools.ietf.org/html/rfc8017#section-8.2.1 > https://tools.ietf.org/html/rfc8017#section-8.2.2 > > > On Wed, Feb 12, 2020 at 1:27 AM M K Saravanan wrote: > >> Hi, >> >> I recently encountered the below issue: >> >> TLS1.2 >> ECDHE_RSA >> server certificate: 2048-bit RSA (=3D 256 bytes) >> ServerKeyExchange hash/sign algorithm: rsa_pkcs1_sha1 >> >> The server was sending the ServerKeyExchange with 255 byte as length for >> the RSA signature (i.e. the leading zero was stripped) instead of 256 li= ke >> this: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Handshake Protocol: Server Key Exchange >> Handshake Type: Server Key Exchange (12) >> Length: 328 >> EC Diffie-Hellman Server Params >> Curve Type: named_curve (0x03) >> Named Curve: secp256r1 (0x0017) >> Pubkey Length: 65 >> Pubkey: 042206562efea8bd47bf014a9e650c42f27078643c553671=E2=80= =A6 >> Signature Algorithm: rsa_pkcs1_sha1 (0x0201) >> Signature Length: 255 >> Signature: d1bf915eca2ec0bcdda6f90a398fe5378d2028a22574d213=E2= =80=A6 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Is this allowed? i.e. stripping the leading zero of the RSA signature >> and marking the length as 255? It is not clear to me from the RFC5246 >> whether it is allowed or not. >> >> (client was failing to verify the signature due to this). >> >> with regards, >> Saravanan >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000bbce46059e5bb7d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks David for the clarification.

wit= h regards,
Saravanan

On Wed, 12 Feb 2020 at 14:53, David Ben= jamin <davidben@chromium.org> wrote:
The signature is invalid. The client is correct to reject it,= and the server is incorrect to produce it.


On Wed, Feb 12, 2020 at 1:27 AM M K Saravanan <mksarav@gmail.com&= gt; wrote:
Hi,

I recently encountered the below issue:<= /div>

TLS1.2
ECDHE_RSA
server certif= icate: 2048-bit RSA (=3D 256 bytes)
ServerKeyExchange hash/sign a= lgorithm:=C2=A0rsa_pkcs1_sha1

The server was sendi= ng the ServerKeyExchange with 255 byte as length for the RSA signature (i.e= . the leading zero was stripped) instead of 256 like this:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
Handshake Protocol: Server Key Exchange
=C2=A0 =C2=A0 Handshake Typ= e: Server Key Exchange (12)
=C2=A0 =C2=A0 Length: 328
=C2=A0 =C2=A0 E= C Diffie-Hellman Server Params
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Curve Type: n= amed_curve (0x03)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Named Curve: secp256r1 (0x= 0017)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pubkey Length: 65
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Pubkey: 042206562efea8bd47bf014a9e650c42f27078643c553671=E2=80= =A6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Signature Algorithm: rsa_pkcs1_sha1 (0x0= 201)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Signature Length: 255
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Signature: d1bf915eca2ec0bcdda6f90a398fe5378d2028a22574d213= =E2=80=A6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Is this allowed?=C2=A0 i.e. stripping th= e leading zero of the RSA signature and marking the length as 255?=C2=A0 = =C2=A0It is not clear to me from the RFC5246 whether it is allowed or not.<= /div>

(client was failing to verify the signature due to= this).

with regards,
Saravanan

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000bbce46059e5bb7d8-- From nobody Wed Feb 12 08:10:07 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20071120104 for ; Wed, 12 Feb 2020 08:10:05 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 wyrn2jX7ShzG for ; Wed, 12 Feb 2020 08:10:04 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 7470F1200FB for ; Wed, 12 Feb 2020 08:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1581523804; x=1613059804; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=f0oN8aBPWVw+lITKd7JqlXI63IC0I7CUjAtmzcL35sc=; b=LgaLf0G/WWp3OyhIK1neA7tIw20HyqAZwMDtgQsjzBJHUsDn1gKUGPXr /DV/m83FHfKJSjeqdgMT916MQ9fIPL0ZuyLYXUSa79rcVEYn8WNIaR9bK k6fzqoeO53b6ZFHpoNvUSAOYQkK5e4RdzByDht/bxG2jcMTC8do7um67k Z/+trepnsgcXrqC0oZAAe6ZIrSlhyP+JAIwO559NtgZhzHwN9/rcD+Huq JHznn+ae15I9CQFDkaYquGoqzvlkzJg8v64S+TS1Vbe1yk7USJoQTYNOT yCKDxImq7GZR7aNHmXuNuVPtiwZuFItOYoCifx/yd0VbOVFl3Da6IJrtK A==; X-IronPort-AV: E=Sophos;i="5.70,433,1574074800"; d="scan'208";a="114813472" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Feb 2020 05:10:02 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Feb 2020 05:10:01 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 13 Feb 2020 05:10:01 +1300 From: Peter Gutmann To: M K Saravanan , "" Thread-Topic: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange? Thread-Index: AQHV4W2CYeXLZ0I+bUablesS8zu9G6gXusN0 Date: Wed, 12 Feb 2020 16:10:00 +0000 Message-ID: <1581523805582.16466@cs.auckland.ac.nz> References: 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] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 16:10:05 -0000 M K Saravanan writes:=0A= =0A= >Is this allowed?=A0 i.e. stripping the leading zero of the RSA signature a= nd=0A= >marking the length as 255?=A0=A0 It is not clear to me from the RFC5246 wh= ether=0A= >it is allowed or not.=0A= =0A= It's not allowed according to the spec but a number of implementations do i= t=0A= because their underlying bignum libraries perform leading-zero truncation, = so=0A= you're better off allowing it to avoid breakage.=0A= =0A= Peter.= From nobody Wed Feb 12 09:12:25 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BD7120824 for ; Wed, 12 Feb 2020 09:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 F-ySedpIRdey for ; Wed, 12 Feb 2020 09:12:22 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBADE120823 for ; Wed, 12 Feb 2020 09:12:22 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id y5so1532568pfb.11 for ; Wed, 12 Feb 2020 09:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YA9/ObPb8OxW8vHd31o8GdkzpeTi+ayM8Tn7oiK8QVw=; b=NIX6mA2ogeMxi/yW+NAF6WARXBb1sYzSLMDEX1QuxAk5Yk3cgem/osVWIMStywlgU3 R19DZ+jusOWzF6sFCau4bLSVh+UH5asBv/mV3cz0mr5LZAaTWynGM4SQabQu5i/IoQVG MuGbplfNmW1hMqGR8jTAhiROcAV+6MS4GW+ro= 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=YA9/ObPb8OxW8vHd31o8GdkzpeTi+ayM8Tn7oiK8QVw=; b=OMdA9v/Sj44TSVhu/v+8T9fVQn5elxPucKS01aEmaP7Noy9P+iConGQbBByFvv2vz4 PwjCUC852v6s6ZB0LM3+E3+qouxmnn5WugsK/904V8QF0LQAne1QSczA4kyelXA+mpLT MyhT/w0w2SavY9vnnjpAQGLNWA8LoLcnOsXEpCGufjZgi+IxFNX4GhSxMmN1EtjPRV2r K2OjdNKki13Rz+Jf4xL9dgNzKDrIA4aYH+CLiMDIzUCtWQze/3fgwwK0fdasvrnWdVoe dCf0MQTV9K6C8rPYehFw2yZBAEGRyZOh1Z5FhOlE9pvJEGoUUoym4ONKUZHPaLjeSf5u lK9g== X-Gm-Message-State: APjAAAVvfnXFuMmRbCdF3ZS9AkLC4lJeGGXeYyoudq7UW6arKUkx5xTp jFssYS9qN24D9DZhmyl10LjSYn9cMVzqhzazQ2XT X-Google-Smtp-Source: APXvYqxaa9okevL7cL5BLZVstDeimbBpQxuQ7Mw8vREfKTzlsFzGz8qgBGiAnULDOTa4o7l55yfW++WLV1JP3UA/qRs= X-Received: by 2002:aa7:9a0b:: with SMTP id w11mr12697662pfj.4.1581527541951; Wed, 12 Feb 2020 09:12:21 -0800 (PST) MIME-Version: 1.0 References: <1581523805582.16466@cs.auckland.ac.nz> In-Reply-To: <1581523805582.16466@cs.auckland.ac.nz> From: David Benjamin Date: Wed, 12 Feb 2020 12:12:05 -0500 Message-ID: To: Peter Gutmann Cc: M K Saravanan , "" Content-Type: multipart/alternative; boundary="00000000000057a4f8059e64130b" Archived-At: Subject: Re: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 17:12:24 -0000 --00000000000057a4f8059e64130b Content-Type: text/plain; charset="UTF-8" On Wed, Feb 12, 2020 at 11:10 AM Peter Gutmann wrote: > M K Saravanan writes: > > >Is this allowed? i.e. stripping the leading zero of the RSA signature and > >marking the length as 255? It is not clear to me from the RFC5246 > whether > >it is allowed or not. > > It's not allowed according to the spec but a number of implementations do > it > because their underlying bignum libraries perform leading-zero truncation, > so > you're better off allowing it to avoid breakage. > For web use cases, this does not appear to be necessary. BoringSSL and Chrome do not accept such signatures and have not for around five years now. (Possibly longer. I do not know off-hand what Chrome's behavior was when it used NSS.) I don't think I've ever seen a report of problems with a website, and the specification quite clearly says to reject those signatures. The robustness principle sounds plausible at face value, but I think we now have the experience to know otherwise. https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 Note that bignum libraries that perform leading-zero truncation are unlikely to be suitable for cryptography anyway. Signatures are public values, but if you're implementing RSA decryption and care about side channel attacks, fixed-width in-memory representations and serialization functions are mandatory. http://archiv.infsec.ethz.ch/education/fs08/secsem/Manger01.pdf --00000000000057a4f8059e64130b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 12, 2020 at 11:10 AM Peter Gu= tmann <pgut001@cs.auckland.= ac.nz> wrote:
M K Saravanan <mksarav@gmail.com> writes:

>Is this allowed?=C2=A0 i.e. stripping the leading zero of the RSA signa= ture and
>marking the length as 255?=C2=A0=C2=A0 It is not clear to me from the R= FC5246 whether
>it is allowed or not.

It's not allowed according to the spec but a number of implementations = do it
because their underlying bignum libraries perform leading-zero truncation, = so
you're better off allowing it to avoid breakage.
<= br>For web use cases, this does not appear to be necessary. BoringSSL and C= hrome do not accept such signatures and have not for around five years now.= (Possibly longer. I do not know off-hand what Chrome's behavior was wh= en it used NSS.) I don't think I've ever seen a report of problems = with a website, and the specification quite clearly says to reject those si= gnatures. The robustness principle sounds plausible at face value, but I th= ink we now have the experience to know otherwise.

= Note that bignum libraries that perform leading-zero truncation are unlikel= y to be=C2=A0suitable for cryptography anyway. Signatures are public values= , but if you're implementing RSA decryption and care about side channel= attacks, fixed-width in-memory representations and serialization functions= are mandatory.
--00000000000057a4f8059e64130b-- From nobody Wed Feb 12 10:45:30 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4A120A46 for ; Wed, 12 Feb 2020 10:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 s1sRBhDUajPw for ; Wed, 12 Feb 2020 10:45:25 -0800 (PST) Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) (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 A59F5120A53 for ; Wed, 12 Feb 2020 10:45:25 -0800 (PST) IronPort-SDR: RYU+yyhBsUOqk/OWpfb1tMGK9Q1CiS6h7hEtsYMhE6UFa4nCgUYygzIYDNciPFfkv7lqZrKqAn DM5fh7YOytXtOXpA4hOBrfsCzvAked+lgs/9nSMXAE7LsqgBacFCEDGb6vHOD1zJuwf+SnIYuL OGh97q4hXA8pR2sG6SjafEA9ZJiMrpFZ48lWA9iVYSM6fU21qfniN2CAzmb9DVKy8S0ow265sc xGWsRwC7J6iQg4q52HpJNSypGN36U+s17RMQ5f31JD/ooRRgokkPa2zLN/AFA+Wr5FkLz994pp Pls= Received: from unknown (HELO V0501WEXGPR02.isaracorp.com) ([10.5.9.20]) by ip1.isaracorp.com with ESMTP; 12 Feb 2020 18:45:26 +0000 Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR01.isaracorp.com (10.5.8.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1847.3; Wed, 12 Feb 2020 13:46:01 -0500 Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1847.005; Wed, 12 Feb 2020 13:46:01 -0500 From: Daniel Van Geest To: "tls@ietf.org" Thread-Topic: TLS 1.3 unsupported_extension vs illegal_parameter clarification Thread-Index: AQHV4dSsu7Pal1sprkOKD5ZOC/nomw== Date: Wed, 12 Feb 2020 18:46:01 +0000 Message-ID: <4E5499C8-7461-4366-9F20-EF36EA407BD8@isara.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.5.52] Content-Type: multipart/alternative; boundary="_000_4E5499C8746143669F20EF36EA407BD8isaracom_" MIME-Version: 1.0 Archived-At: Subject: [TLS] TLS 1.3 unsupported_extension vs illegal_parameter clarification X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 18:45:28 -0000 --_000_4E5499C8746143669F20EF36EA407BD8isaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCknigJltIGxvb2tpbmcgZm9yIHNvbWUgY2xhcmlmaWNhdGlvbiBvbiB1bnN1cHBvcnRl ZF9leHRlbnNpb24gdnMgaWxsZWdhbF9wYXJhbWV0ZXIgYWxlcnRzIGluIFRMUyAxLjMuDQoNClJG QyA4NDQ2IHNheXM6DQoNCklmIGFuIGltcGxlbWVudGF0aW9uIHJlY2VpdmVzIGFuIGV4dGVuc2lv bg0KICAgd2hpY2ggaXQgcmVjb2duaXplcyBhbmQgd2hpY2ggaXMgbm90IHNwZWNpZmllZCBmb3Ig dGhlIG1lc3NhZ2UgaW4NCiAgIHdoaWNoIGl0IGFwcGVhcnMsIGl0IE1VU1QgYWJvcnQgdGhlIGhh bmRzaGFrZSB3aXRoIGFuDQogICAiaWxsZWdhbF9wYXJhbWV0ZXIiIGFsZXJ0Lg0KDQphbmQNCg0K DQpUaGUgY2xpZW50IE1VU1QgY2hlY2sgRW5jcnlwdGVkRXh0ZW5zaW9ucyBmb3IgdGhlDQoNCiAg IHByZXNlbmNlIG9mIGFueSBmb3JiaWRkZW4gZXh0ZW5zaW9ucyBhbmQgaWYgYW55IGFyZSBmb3Vu ZCBNVVNUIGFib3J0DQoNCiAgIHRoZSBoYW5kc2hha2Ugd2l0aCBhbiAiaWxsZWdhbF9wYXJhbWV0 ZXIiIGFsZXJ0Lg0KDQpCdXQgYWxzbw0KDQoNCiAgIHVuc3VwcG9ydGVkX2V4dGVuc2lvbjogIFNl bnQgYnkgZW5kcG9pbnRzIHJlY2VpdmluZyBhbnkgaGFuZHNoYWtlDQoNCiAgICAgIG1lc3NhZ2Ug Y29udGFpbmluZyBhbiBleHRlbnNpb24ga25vd24gdG8gYmUgcHJvaGliaXRlZCBmb3INCg0KICAg ICAgaW5jbHVzaW9uIGluIHRoZSBnaXZlbiBoYW5kc2hha2UgbWVzc2FnZSwgb3IgaW5jbHVkaW5n IGFueQ0KDQogICAgICBleHRlbnNpb25zIGluIGEgU2VydmVySGVsbG8gb3IgQ2VydGlmaWNhdGUg bm90IGZpcnN0IG9mZmVyZWQgaW4NCg0KICAgICAgdGhlIGNvcnJlc3BvbmRpbmcgQ2xpZW50SGVs bG8gb3IgQ2VydGlmaWNhdGVSZXF1ZXN0Lg0KDQpUaGVzZSBzZWVtIGNvbnRyYWRpY3RvcnkuICBB biDigJx1bnN1cHBvcnRlZF9leHRlbnNpb27igJ0gaXMgZm9yIOKAnGFuIGV4dGVuc2lvbiBrbm93 biB0byBiZSBwcm9oaWJpdGVkIGZvciBpbmNsdXNpb24gaW4gdGhlIGdpdmVuIGhhbmRzaGFrZSBt ZXNzYWdl4oCdLg0KDQpCdXQgaXQgc2VlbXMgdGhhdCB0aGUgZmlyc3QgdHdvIHN0YXRlbWVudHMg cXVvdGVkIGluZGljYXRlIHRoYXQg4oCcaWxsZWdhbF9wYXJhbWV0ZXLigJ0gc2hvdWxkIGJlIHNl bnQgaW4gdGhpcyBjYXNlLg0KDQpJ4oCZZCBleHBlY3Qg4oCcdW5zdXBwb3J0ZWRfZXh0ZW5zaW9u 4oCdIHdvdWxkIGJlIG1vcmUgZml0dGluZy4gIElzIGFuIGVycmF0YSBuZWVkZWQ/DQoNClRoYW5r cywNCkRhbmllbCBWYW4gR2Vlc3QNCg0K --_000_4E5499C8746143669F20EF36EA407BD8isaracom_ Content-Type: text/html; charset="utf-8" Content-ID: <5F850213D8896540842D2DD43E1CE422@isara.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPknigJltIGxvb2tpbmcgZm9yIHNvbWUgY2xhcmlmaWNhdGlvbiBvbiB1bnN1 cHBvcnRlZF9leHRlbnNpb24gdnMgaWxsZWdhbF9wYXJhbWV0ZXIgYWxlcnRzIGluIFRMUyAxLjMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPlJGQyA4NDQ2IHNheXM6IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+SWYgYW4gaW1wbGVtZW50YXRpb24gcmVjZWl2ZXMgYW4gZXh0 ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB3aGljaCBpdCByZWNvZ25pemVzIGFuZCB3aGlj aCBpcyBub3Qgc3BlY2lmaWVkIGZvciB0aGUgbWVzc2FnZSBpbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgd2hpY2ggaXQgYXBwZWFycywgaXQgTVVTVCBhYm9ydCB0aGUgaGFuZHNoYWtlIHdpdGggYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7ICZxdW90O2lsbGVnYWxfcGFyYW1ldGVyJnF1b3Q7IGFsZXJ0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5hbmQgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhl IGNsaWVudCBNVVNUIGNoZWNrIEVuY3J5cHRlZEV4dGVuc2lvbnMgZm9yIHRoZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBwcmVzZW5jZSBvZiBhbnkgZm9yYmlkZGVuIGV4dGVuc2lvbnMgYW5kIGlmIGFueSBhcmUgZm91 bmQgTVVTVCBhYm9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgaGFuZHNoYWtlIHdpdGggYW4gJnF1b3Q7aWxs ZWdhbF9wYXJhbWV0ZXImcXVvdDsgYWxlcnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QnV0IGFsc288bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdW5zdXBwb3J0ZWRfZXh0 ZW5zaW9uOiZuYnNwOyBTZW50IGJ5IGVuZHBvaW50cyByZWNlaXZpbmcgYW55IGhhbmRzaGFrZTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZXNzYWdlIGNvbnRhaW5pbmcgYW4gZXh0ZW5z aW9uIGtub3duIHRvIGJlIHByb2hpYml0ZWQgZm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGluY2x1c2lvbiBpbiB0aGUgZ2l2ZW4gaGFuZHNoYWtlIG1lc3NhZ2UsIG9yIGluY2x1ZGlu ZyBhbnk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXh0ZW5zaW9ucyBpbiBhIFNlcnZl ckhlbGxvIG9yIENlcnRpZmljYXRlIG5vdCBmaXJzdCBvZmZlcmVkIGluPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZSBjb3JyZXNwb25kaW5nIENsaWVudEhlbGxvIG9yIENlcnRpZmlj YXRlUmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGVzZSBzZWVtIGNvbnRyYWRpY3RvcnkuJm5ic3A7 IEFuIOKAnHVuc3VwcG9ydGVkX2V4dGVuc2lvbuKAnSBpcyBmb3Ig4oCcYW4gZXh0ZW5zaW9uIGtu b3duIHRvIGJlIHByb2hpYml0ZWQgZm9yIGluY2x1c2lvbiBpbiB0aGUgZ2l2ZW4gaGFuZHNoYWtl IG1lc3NhZ2XigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJ1dCBpdCBzZWVtcyB0aGF0IHRoZSBmaXJzdCB0d28g c3RhdGVtZW50cyBxdW90ZWQgaW5kaWNhdGUgdGhhdCDigJxpbGxlZ2FsX3BhcmFtZXRlcuKAnSBz aG91bGQgYmUgc2VudCBpbiB0aGlzIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPknigJlkIGV4cGVjdCDigJx1 bnN1cHBvcnRlZF9leHRlbnNpb27igJ0gd291bGQgYmUgbW9yZSBmaXR0aW5nLiZuYnNwOyBJcyBh biBlcnJhdGEgbmVlZGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5EYW5pZWwgVmFuIEdlZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_4E5499C8746143669F20EF36EA407BD8isaracom_-- From nobody Wed Feb 12 11:26:39 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06912120819 for ; Wed, 12 Feb 2020 11:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AqzI8gVxFYud for ; Wed, 12 Feb 2020 11:26:34 -0800 (PST) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A5412002F for ; Wed, 12 Feb 2020 11:26:34 -0800 (PST) Received: by mail-lj1-f182.google.com with SMTP id v17so3688777ljg.4 for ; Wed, 12 Feb 2020 11:26:34 -0800 (PST) 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=zIq9cmV+mYHffoOAZAnoKTnswGFJyV+6zwMD1mjZoT8=; b=kp7Gl4fJQj8EeJECshkzQOqQOAsWU6Mgw15O/0gYNuvYl0nekrqjnT25kJIn6hY1tX bSJuUU118dicUgrU/Ayn+Qe8S+JpjDXXHKiUsIlCUrVUlBD0T/HRIQoCvdWWxMDhXC88 9dBAkIdL8xAp69XgbE04eRoTfm0czMzCk6nTSMvThxHnJRhS8r1j5Td88s4cubh4wafk 5Hl5YKzv0Xvl6rohuNZtBfJEWAhf8z4nam6kJA6xqw/lymGht5AH3sesvHm37/+Aw2/V +jFC6F23Ee7WhAPCiw/a9BZfZca0y2yHPgN86UlcEe/LHCMDYTWDQ/WzO1DSDR9Gd3KU y9Og== X-Gm-Message-State: APjAAAWy0vUEvBCVuSpUi3v0cSepwmjlAQGb4a/JZOddl7TMPuyHQUSR ce1ZTyKDYI3TfKLJgHQwhS3cmlkOTw2wW/zdMgiZHyFN734= X-Google-Smtp-Source: APXvYqyRj4iUOR5WVd5oIPSE6+viMTERsG/iF0DXAsooZzMz3xqLeRkP9v+JlFtA7NXhKSLt+i6LQO7S0VXf3hREz7c= X-Received: by 2002:a2e:8651:: with SMTP id i17mr8949208ljj.121.1581535592508; Wed, 12 Feb 2020 11:26:32 -0800 (PST) MIME-Version: 1.0 From: Douglas Stebila Date: Wed, 12 Feb 2020 14:26:21 -0500 Message-ID: To: "" Cc: Shay Gueron , Scott Fluhrer Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 19:26:37 -0000 Dear TLS working group, We would like to request the working group adopt draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as a working group item. We have updated the draft based on feedback we've received over the past few months, including from our presentations at IETF 104 and 105, and think the current version represents the view of the WG to date. https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ Cheers, Douglas From nobody Wed Feb 12 12:47:16 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52E6120817 for ; Wed, 12 Feb 2020 12:47:14 -0800 (PST) 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=lowentropy.net header.b=PLmO/Ah0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y9bWuDM7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUMVJUpClTrC for ; Wed, 12 Feb 2020 12:47:13 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D90120019 for ; Wed, 12 Feb 2020 12:47:12 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 22BE7FE5 for ; Wed, 12 Feb 2020 15:47:12 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 12 Feb 2020 15:47:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=iFK9TpHsl/sx1NMwyiYShufS+mDDSf6 xeMsOLZbJmoc=; b=PLmO/Ah0+lLtXq8tGeRiM7PAVHgpEb34w21UgUxN/Y0LG7+ nbGnR9kj54FEmgj6Ce7AI7xA4OArqbYGakT7lrqkPcDgFsiyij+XoAHGSK1CHA0Z NaVKbyELtHAI2P5nnu+bP1Pp/0/y+XSvMSqjUH9joo9SLlS67PwZztxmY97dz1hg VFrZKd2aIoOz/zwik7tJ/iWTkk3cGFewrWLOrp2EQnc+/XYPgfC2H0qIq9TRkCfh KG6loBzVH71RPyzry5uwUNfQxqyZIx9RRsoexHJAYinGV/cuYM+1hij9N4jV5Emy JlpFgnd9cTF1aSIIm9gnZRS7vJJk64B5cMuxZRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=iFK9Tp Hsl/sx1NMwyiYShufS+mDDSf6xeMsOLZbJmoc=; b=Y9bWuDM758ASMG41elMk3W zNNQxBjlGTkMcmqKTgABW9iG0zotv+ThUsLKnK++eH4tBMz/gQbvvbqQ5F3ltmm2 ZDVxk1wK8hzP2SIFo0+EujPMl7tnRnyaAyfK2svr5AhYoITNud/DbZp/yw107PFr MzSfDBneEDe1X6n7oNbkf5RFCSMNF1VbKClPUnJC0ks+lFt3RhqgBz5VtpEpz4Mc e1y5bopQCoL9D2ZWmcJtFTnAJqk9XXO9QBq/mumZP7uuvpeK7SB0PRfrz6bwPFf6 P5Nnr/TuCukc9E+E9JCpXExI6bIZk3wJxxSEt4LVx3F3wfYZxODWCPOcVwfQpnyg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrieeigddtiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 42511E00A2; Wed, 12 Feb 2020 15:47:11 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> In-Reply-To: References: Date: Thu, 13 Feb 2020 07:46:51 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Requesting_working_group_adoption_of_draft-stebi?= =?utf-8?q?la-tls-hybrid-design?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 20:47:15 -0000 On Thu, Feb 13, 2020, at 06:26, Douglas Stebila wrote: > We would like to request the working group adopt > draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as > a working group item. We have updated the draft based on feedback > we've received over the past few months, including from our > presentations at IETF 104 and 105, and think the current version > represents the view of the WG to date. I agree that we should adopt this. I think that the draft is broadly in the right shape. Skimming through I noticed a few things that I would prefer to see eventually changed, but we can do that in the working group. At a high level, I think that this would be easier if it were more clearly framed as *recommendations*, especially when it comes to the format of key shares and the input secret. One advantage of the macro-level design is that the format is can be specified on a case-by-case basis. For instance, variable-length values might be length-prefixed; fixed size values don't need to be. That might avoid having to directly specify a single format. S 3.1 (Negotiation) suggests that a portion of the named group space be reserved for this use. I think that is a bad idea because it implies semantics where none are necessary. Picking codepoints as usual should suffice; indeed, random allocation might be ideal. The concatenation approach is definitely my preferred approach, but the inconsistency between the design for key shares and secrets is curious. This design assumes that shares are length-delimited; secrets are not. The latter implies that the `ss` needs to be fixed length for a given algorithm (both the PQ and classical parts), but `ct`/`pk` does not. I can guess at why, but when you can avoid the question, then I think you should. That is, in favour of more generic recommendations on structure. To answer some of the open questions: Larger public keys and/or ciphertexts - if we need these, we're in serious trouble. To give you an idea, even at 1k, these will start being much harder to deploy. Getting close to 64k adds all sorts of complication. Better to defer support for big messages. Acknowledging the limitation should suffice. Duplication of key shares - not so much an open question as something the draft could acknowledge as a cost. As previously discussed X25519 is small enough that duplication doesn't hurt enough to care. Variable-length shared secrets - see above. Resumption - I would be supportive of policy recommendations about the strength of key exchange on resumption, but as we allow straight resumption without PSKs, this cannot be standardized. Failures - If this were low enough, I'd be happy to try again. From our perspective, this isn't technically challenging, it's merely annoying. If this were very low probability (as I would expect), then we might just accept the loss of the occasional connection attempt. From nobody Wed Feb 12 13:44:19 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D97120821 for ; Wed, 12 Feb 2020 13:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 K0jW7VdEH1HL for ; Wed, 12 Feb 2020 13:44:15 -0800 (PST) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (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 75A00120805 for ; Wed, 12 Feb 2020 13:44:15 -0800 (PST) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 01CLiDFL031611; Wed, 12 Feb 2020 16:44:13 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design Thread-Index: AQHV4eXAU17JGvDklkis8ExS7ZUyEqgYF1QA Date: Wed, 12 Feb 2020 21:44:12 +0000 Message-ID: References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> In-Reply-To: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3664370652_1458927535" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002120149 Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 21:44:17 -0000 --B_3664370652_1458927535 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I'm jumping in late - so apologies in advance for potential ignorant comments: On 2/12/20, 3:48 PM, "TLS on behalf of Martin Thomson" wrote: > Larger public keys and/or ciphertexts - if we need these, we're in serious trouble. > To give you an idea, even at 1k, these will start being much harder to deploy. > Getting close to 64k adds all sorts of complication. You saw the key sizes that the NIST PQC candidates require? How would you suggest dealing with them unless there's support for larger public keys? --B_3664370652_1458927535 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADyHaxtc8GrYDIrgAAAAPIdjANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMyNjE4NDEwMVoXDTIyMDMy NTE4NDEwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzD7FJptOjLaaidxt9QIIH/dAblMrT ESMm4ggEBR0KqbmSkRY+x45ed8E2u9fJuFWKAgwU+vJo//kzavEpAAuyhe61Z+4noWIvV0sY WkUs+ffLh+29MxDs8Mt1++mDAC1+NyLCPN8QNPRJVu7ECRtmKu3DiAtuEKva3J7lZyVVNE+3 e9HQJlr/3alifN4sg/NxOFMTKMMEq15RgOhDyAudnNSs2IesRnoKTZq/Jykwbm0fg06ePSBR /k2JuYNW8/UZnU7d/Ez2n1NEtZkQw5QzWrC27ijf7FFQxM9yLToJneFVK+krQsfvtMbHGpnz Yo9keqc3Uxb13P4mpDbZiIBTAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUMzH1HGnW9jHVrCuy FAmJhhljwLcwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACztsHHc HX+FTwlhjHUUU+AcLyX3hgIdnTovNmPWVhVgzpN25AotcwODhCwuaLNoLsC0OHRISFUvkqHg 7aeZ9CiDOL4KwlNZgzGpDlqZ/AgMJ+JodWz0XqoNm4wYNs2rl7sEzLe70yPVyzTYlhECYnex UxE4hL334w/cx+Mb8vKn+/EQ9NFKVfCJ8X1dDkCA19EkZu2DbFF2oAM0kr6JX2dNx1rChTMZ iOSkGkKKpnVNFBMl/uw8qH8XrD+slPhLpTQg5t9l0pCtkJSMnrMovPvgwhlOP7yCLdPYYTwY IjwvUeqj1VAvid80L9vevRY1D6NDz/eWfoqCxXxPvtue//owggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADyHaxtc8GrYDIrgAAAAPIdjANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCWGxZWn8lrmx9/TquE4woVE7c76OLxzejdcabu FQVOpjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMTIy MTQ0MTJaMA0GCSqGSIb3DQEBAQUABIIBAJ5u+qwlpV/CLRgAwTRK0rvLsRqmtg+qEUUK+OU+ Qyj8xX4/nndf1H7qcO+6qAU6wHRwDDNgU3xJiNUcwX9yahzekBPHqhnFUX6mIfW/bYvt/XwB NoJhTjHxQw3u2uuM2vyGGHtYMmIzrttKThdEXLVmEr4LrVwRaZAzckisK4pKtucD1lmJQCML 0Txd1jZa3sIHaxDDJ7wFWuf9gCbwT4K0/mG9h5Bm3H5FYbngcTA7cmimA+oCh9OnkyvyEMm/ 3vMddmomwMhv7k7wxgvO/u5lYoZ/Z7cYT7XOL1MFJgtj+YArGy3y1hw8z5dK2OmzN91f9uxY baiEzi+cuXD967Q= --B_3664370652_1458927535-- From nobody Wed Feb 12 13:57:59 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3385A12009C for ; Wed, 12 Feb 2020 13:57:58 -0800 (PST) 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=lowentropy.net header.b=aG4dJEBD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lJpag0pb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXOu1Ep0a1DN for ; Wed, 12 Feb 2020 13:57:56 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5597D120988 for ; Wed, 12 Feb 2020 13:57:56 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 887712AF; Wed, 12 Feb 2020 16:57:55 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 12 Feb 2020 16:57:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=64vS6rkEatmq7Q1kaXnvbX9Dvepm2ii CVEGEBmqfu8Q=; b=aG4dJEBD/VrvMNyGgNifK0/4wo9auUUh3CfYbMUAn6I0sKy t0Tych/S0xGBjqsh9X/DznA3b8kYU0ous+2vlVcZrOTHzDFagYwYHcxS94taX85I 3L1GHVKedqWo8t+kD8qC5wq1zM7+73ckNbuxuvA8qG05yYZfCnaQ1FClT2KtDNJw NxHBawSmaa81yeMzjRd9YRbWX2H26y1hmLZ4vyubo2ZYX8by7FoqCSJpE/qOQSvN +BDxz+Aj7qlFS/+JWFwpyZ8L46Kbsswltl9b1CQVB59jqkMfIC2ogNHM8+TZkKom KivVrmk8jFSCsqmFxjEdFUY6RNFFkzA4SHpyEiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=64vS6r kEatmq7Q1kaXnvbX9Dvepm2iiCVEGEBmqfu8Q=; b=lJpag0pbqsQCqkSTbB1f+5 QE4gi7euAWycFbe/KG7ZpWrXB51I3tpviCQ1x65MDdhsnPee3iv/TExJ8khPncAN H3lRTJ9YPnl5uRjqQEbuVubk3lvXTcpGzflL5GIkipOsPCxcE+eO5CmqO+x0AA52 ikU8llD0uykXeBRQGBNDCjtbYxZ/YjKOE8yKpzWw5qV7rRB7wkP9ysmugRgXnhN+ t8djwqY8QRLTzeJtxEn09tFEXDhGsyAWlIlnySufNvT/yqZF78vTgd5igTHeBLs/ NnNsVFkJYMjIYqaGb6QjNr+tumAcPfGqX1gvYRgTQRZwQLQabnsiGAwz7W9PqyiA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrieeigddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 78811E00A5; Wed, 12 Feb 2020 16:57:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> In-Reply-To: References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> Date: Thu, 13 Feb 2020 08:57:34 +1100 From: "Martin Thomson" To: "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Requesting_working_group_adoption_of_draft-stebi?= =?utf-8?q?la-tls-hybrid-design?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 21:57:58 -0000 On Thu, Feb 13, 2020, at 08:44, Blumenthal, Uri - 0553 - MITLL wrote: > You saw the key sizes that the NIST PQC candidates require? How would > you suggest dealing with them unless there's support for larger public > keys? Only a few of them. Some are OK, but the number is few, I agree. I haven't found a good summary of the second round candidates and I don't have time to dig into all of the candidates. From nobody Wed Feb 12 14:49:45 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B0C12001E for ; Wed, 12 Feb 2020 14:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 58brTrHvEsNA for ; Wed, 12 Feb 2020 14:49:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F64120013 for ; Wed, 12 Feb 2020 14:49:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DD2A2BE2E; Wed, 12 Feb 2020 22:49:38 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ_D0wKECLmI; Wed, 12 Feb 2020 22:49:37 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3287BBE47; Wed, 12 Feb 2020 22:49:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1581547777; bh=neFh6lwaJlvBVljjNUhywfUZANgEQ20c5bTog99uLn0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YxlJag3hpgHjfJNKeZ4j0FC3URuaOO6HZe3FPYpI7VQux9eWjabygBcjs0zJMN3BN H9wbeirnKzzdKJ8FxIy9CU2dTWtOeLrT8lux5sRc8M60ekgF9zE3Zh/P2GmSHcwRxo NhALKN8czhpy13pqwN0TSniMmpOlIq0pRuJdFEeM= To: Martin Thomson , "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie> Date: Wed, 12 Feb 2020 22:49:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TSk5IyTfmgyoKbD3Uwx8GV0P8ZaIM18J9" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 22:49:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TSk5IyTfmgyoKbD3Uwx8GV0P8ZaIM18J9 Content-Type: multipart/mixed; boundary="yeD9OZOFaDkebIsPEQe66H2RIBc05hAOZ"; protected-headers="v1" From: Stephen Farrell To: Martin Thomson , "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Message-ID: <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie> Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> In-Reply-To: <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> --yeD9OZOFaDkebIsPEQe66H2RIBc05hAOZ Content-Type: multipart/mixed; boundary="------------088F56DD2D5BF4479B794944" Content-Language: en-US This is a multi-part message in MIME format. --------------088F56DD2D5BF4479B794944 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 12/02/2020 21:57, Martin Thomson wrote: > Only a few of them. Some are OK, but the number is few, I agree. I > haven't found a good summary of the second round candidates and I > don't have time to dig into all of the candidates. Fine reason to wait and see IMO. I'd be much happier adopting this if we did that with the explicit understanding that we won't produce an RFC until the "winners" in the NIST process are known and their properties understood. (I don't mean waiting for a FIPS or formal NIST document but at least for the final announcement from their process.) If the plan were to adopt this and produce an RFC now (e.g. to mix different curves or something) then I am against that. There's no need for such combinations so the real rationale here is PQC and we (at least I, but I suspect also many IETF participants) don't know enough about the relevant algorithms yet. (And expecting us to be knowledgeable about 25+ algorithms isn't realistic.) Cheers, S. --------------088F56DD2D5BF4479B794944 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------088F56DD2D5BF4479B794944-- --yeD9OZOFaDkebIsPEQe66H2RIBc05hAOZ-- --TSk5IyTfmgyoKbD3Uwx8GV0P8ZaIM18J9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5EgQAACgkQWrL68XsX K+rtRQ/+IF80YYXTzoyfE0SFTmiToFMU/Kx3IZUTjCk/EZsV60cF8Xu5Q8WFbOhW Z8TvENatbfPMN89W+dYEJisu14kHUVIkTGdF+ox0GJ6BlXJvGPZnBqc4sU0RuF4f WMut4Bu4nmby/RvqNYW/oIJ6wn/umIvOju/YOmdEBKaeFSX6Dfq81eOPjrHZVD2Q F/+0GA4BNctO699edoHKuNy7cH7aHLhz+QRD0l4XV9Mbw5e5yb54hbhhTytwZNds BYhy4ZMpjIkzVO6OSGpx8dgGOkJYbTOydXUEjB+5XNnycaXkcc38kHJUXyDrZOwO ZNkO8rG60bgajmWIYjtcvorEpo9BtpDBYF/Eem4x/0cfasgsExO0RXSi4q5tej19 b5kHOIeqkFcJMGg12bbYK5bP8uiDfv29Nys1hg/lh6OlF0SyLURdgnIJNLb2oAzZ Nkm2SQu1AdmCfcalrqB1iMdmzPGms8LF53/1gsOn5QXJGupdAKetzYQA6IRCslAa Z+lzWji+yy9ptM9lh1/OE6eD2Vngtgdu7tOjlO4mw7yxQj5YyqH8yHls1lIp3gs0 j3NtOjnaVL+caZXJm9pVCt5cR9gJ9XbYid6/gO4Y8w+n05W4h69Bopl4vP8sO3+W 5hDDt8dUi3N5wuFCerHPnOq+oJUf4xugySGJuaDTjXh7mFGJdaI= =jVd7 -----END PGP SIGNATURE----- --TSk5IyTfmgyoKbD3Uwx8GV0P8ZaIM18J9-- From nobody Wed Feb 12 14:57:18 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A35120026 for ; Wed, 12 Feb 2020 14:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 gSmhiA7YLW_c for ; Wed, 12 Feb 2020 14:57:14 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 D75B7120013 for ; Wed, 12 Feb 2020 14:57:13 -0800 (PST) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 01CMv8dT031131; Wed, 12 Feb 2020 17:57:08 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Stephen Farrell , Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design Thread-Index: AQHV4fbKdYkW0pRwtUOF1RalA0aXZ6gYK5KA Date: Wed, 12 Feb 2020 22:57:07 +0000 Message-ID: References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie> In-Reply-To: <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3664375027_1635549460" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002120158 Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 22:57:16 -0000 --B_3664375027_1635549460 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I don't expect you to be knowledgeable about 25+ proposed algorithms. I expect you to be knowledgeable about the ballpark of the new key sizes th= at practically all of the candidates use. The shortest keys are in the ballp= ark of a few KB, and I won't go into the size of the largest ones. You may not want to *adopt* them now - but you better be ready to support K= ey Exchange for sizes far larger than what's currently implemented. And keep= in mind that while Signatures aren't a priority yet, that will come eventua= lly. =EF=BB=BFOn 2/12/20, 5:50 PM, "Stephen Farrell" wrote= : =20 Hiya, =20 On 12/02/2020 21:57, Martin Thomson wrote: > Only a few of them. Some are OK, but the number is few, I agree. I > haven't found a good summary of the second round candidates and I > don't have time to dig into all of the candidates. Fine reason to wait and see IMO. =20 I'd be much happier adopting this if we did that with the explicit understanding that we won't produce an RFC until the "winners" in the NIST process are known and their properties understood. (I don't mean waiting for a FIPS or formal NIST document but at least for the final announcement from their process.) =20 If the plan were to adopt this and produce an RFC now (e.g. to mix different curves or something) then I am against that. There's no need for such combinations so the real rationale here is PQC and we (at least I, but I suspect also many IETF participants) don't know enough about the relevant algorithms yet. (And expecting us to be knowledgeable about 25+ algorithms isn't realistic.) =20 Cheers, S. =20 =20 --B_3664375027_1635549460 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADyHaxtc8GrYDIrgAAAAPIdjANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMyNjE4NDEwMVoXDTIyMDMy NTE4NDEwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzD7FJptOjLaaidxt9QIIH/dAblMrT ESMm4ggEBR0KqbmSkRY+x45ed8E2u9fJuFWKAgwU+vJo//kzavEpAAuyhe61Z+4noWIvV0sY WkUs+ffLh+29MxDs8Mt1++mDAC1+NyLCPN8QNPRJVu7ECRtmKu3DiAtuEKva3J7lZyVVNE+3 e9HQJlr/3alifN4sg/NxOFMTKMMEq15RgOhDyAudnNSs2IesRnoKTZq/Jykwbm0fg06ePSBR /k2JuYNW8/UZnU7d/Ez2n1NEtZkQw5QzWrC27ijf7FFQxM9yLToJneFVK+krQsfvtMbHGpnz Yo9keqc3Uxb13P4mpDbZiIBTAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUMzH1HGnW9jHVrCuy FAmJhhljwLcwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACztsHHc HX+FTwlhjHUUU+AcLyX3hgIdnTovNmPWVhVgzpN25AotcwODhCwuaLNoLsC0OHRISFUvkqHg 7aeZ9CiDOL4KwlNZgzGpDlqZ/AgMJ+JodWz0XqoNm4wYNs2rl7sEzLe70yPVyzTYlhECYnex UxE4hL334w/cx+Mb8vKn+/EQ9NFKVfCJ8X1dDkCA19EkZu2DbFF2oAM0kr6JX2dNx1rChTMZ iOSkGkKKpnVNFBMl/uw8qH8XrD+slPhLpTQg5t9l0pCtkJSMnrMovPvgwhlOP7yCLdPYYTwY IjwvUeqj1VAvid80L9vevRY1D6NDz/eWfoqCxXxPvtue//owggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADyHaxtc8GrYDIrgAAAAPIdjANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDS5ruvpZ2ykYraYNYJm3EN/DirsXMTkfQa34Qa pgCYbDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMTIy MjU3MDdaMA0GCSqGSIb3DQEBAQUABIIBAKJ3t1Mdoug9MeOKKu7Vl2IWootMLTJJsw1Exiho 2aVj7BDs+ET8hyKjRBJvhutxdmMR5eJyJD9W/CzHQck6wzZ7aA+7EDSmxV1qlZNF8YQC9so9 uWUSp+j4KT+5tVVgH8I5pKi0zdjtupzXpGV7ac5VskD/hn5UbO5lgta4ieA1cI0w7Me9E04s GBgAlpIZhAH1LJvHCFG2Q1f67W+9c6moeVGcY7tJAU13LExUBs0H+W4Jwq+u314Z2Im9dbvD /lPy3nWz7ZsY2055TWsriiZENg8KR4fb7UiydKpwPciV67WaqZ9BF6tMBJ03V8YVhgoMuMO1 C0xcETmR1kFM3do= --B_3664375027_1635549460-- From nobody Wed Feb 12 14:58:42 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0558E120026 for ; Wed, 12 Feb 2020 14:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.501 X-Spam-Level: X-Spam-Status: No, score=-22.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=usbank.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK4Tu-x337o2 for ; Wed, 12 Feb 2020 14:58:39 -0800 (PST) Received: from mail9.usbank.com (mail9.usbank.com [170.135.218.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C766A120013 for ; Wed, 12 Feb 2020 14:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=usbank.com; i=@usbank.com; q=dns/txt; s=TrustUS; t=1581548319; x=1613084319; h=subject:from:to:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=F0nOXrcYEkTYYJG9ZKL8RYJheeNNvUpQyTl66yY7lpE=; b=sbgtnbbWA1mjt1GBPOiKPsZerOnmdSsxTQY0vL1YdeAFQM58YxmN9chZ R6rPFRalkv3FnKClI/wgCi0Ft6+N3DeU+uRo/k80mk1TVX9lapp3lO8Hn OfUkpeaNkE2Jz92SAsNwkylLRPvDhOTouFN4MtfeUGYLFQsSufuQwR9Jz w=; IronPort-SDR: DbPdYwOg4igh+UcXKwWSlZeXIOdmI5Zkld5I6BYO4R673Q4KE6P4RYkqNDLqFTuXBFPyd6OFgr chnBCrK3Oso1+Hbj4Tf7cIij04z8NP2rp1HN9CHxtdhMFpkvajf5Pq38LXhbbCDNpo+ZMn/VrR wesWVIPeHW67tczDUAWDfUZLSkY6Aqwc8B7WNk17jHsaE9c4LRfXGoAjLk8ohM0A3WchHPpqP+ 3vijQVYpAaQyIeWaR4dZR0wG/yVMPrF7VhmoRn7UpCB3TPMvxM64q0oyBn7ZvknM3m6qax+zWN NTs= Received: from unknown (HELO VMMKSA69901M04.us.bank-dns.com) ([127.0.0.1]) by mail9.usbank.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Feb 2020 16:58:35 -0600 IronPort-SDR: cNUURwcIWeZBGZ7wG3sJiYSmrdKMeSu2qHpleO6JdytpWsbUZEzPUdrW5KW2CtnZiCQ8xShgwQ eFgc8S8ANk9LY8QO0StnmVpW0jd79ONjp5238YlcyaycZvkqoZ3b3peDFjs9aJIjU940mThMF+ 0guTHdbvtEI1546VHmE1QkemV0/p1Wse4hMAFDyGjQrXB8cfQxrqhPzahiO1WUHmNG11Z6ruUD VT3EUlurSuXHGrlF2g/kQzq73SwC5C2P2Q+RRe/S+p9bBNaQRORH7bItd1PR55MdvXpZeRebAa 6Nw= X-LoopCount2: from 192.168.218.98 X_fileSizes: None IronPort-SDR: sFpfpJuPUTmFJGUXhJIfSvGbzgNIThsnzhxc7o566tGhE7Z8dlGkCtUB8nZYHap3SRT3NKj45n jlRD95lr2K6Avl5UXkac/K3kWSshwkHSsre18FLQsLsf5RbTrR5WpAYPfm2GVJgpT/0lT0NYCX PBE23rnqBMR0vdQYMgqNNIAJpe37ROl+qNPHBxvGiAKJzByFZ/pAr0tGojT0Qof18uTewnYM6G z1rzMAbdogPcwUoEbMyIpgoapJd6oUUkNs3+pvJRliWe1sXNBtloQ4sODLmOP3oWpTrPcqdUVS BwA= X-Loop1: 1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=au9PdMk0Y5D7jzE9u81lvGySXkWFejiWAeVU0dtLnOMj1YBppfQU8iNlg4ar0mTg5ZYCRAlcaEKIoSr6llQVPJM4HzRcjcDT7C7Z8EKsKjsYkgM4SLZ3at2FqamEAsMJcs4JEB2Rm+mVdj43oWTyz+HSTRDhMVVDHPeBCQfApf7C0FSRiNGH6D6lIz7i0OlmwFuM5RCG3OfyvQOBgEqWfXLm0OY4/J+OzBlz/Eh17JS5ZL4o8bL7jvRar/Wt3ZZfq/2RkRZy7ijKa8guPyLCUk5hI3BoTfm+Pjo7jnsPG/oevQEABCJIvLRjoZUlK7jx78w1XZdx4P76Cii+Xh7fZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mCaqWaT8tMjsp8rFCdSFBLl45BMRgSFPpn+agcexrzQ=; b=AMshLJfi4eLKGZtm14oeRNaUh+aYFme61obq3QcX2hN1TVERtbIPjuDSMXrCLbZcPWYerRH5tOzy57DgnFQG0OgNco2m8PJXDcR9vPGDV3SVUN+7yondl32M5kLiHtADuu+am3xi/He/mAlL+E5mgJ0cxuBGIMmuE1VzeKpYGR3hi4WZd2b7nsgLtyQqnqmv2RjzrcL5c+w534mwJkq7ITyScm21zo/6fXs1wO6aPR2KTko0H5MbJl7mXAecNiYzFtlk547FnnRu6jrbg3xpOx5XI0jiS+YMVbOpA36o9wIhvSjgnnx2IINSFhuiJ3pMQ0jXIpWCSUArX8Ue58dWfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=usbank.com; dmarc=pass action=none header.from=usbank.com; dkim=pass header.d=usbank.com; arc=none From: "Pettis, Darin P" To: Stephen Farrell , Martin Thomson , "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Thread-Topic: [EXTERNAL] Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design Thread-Index: AQHV4e2u6vSqmRmUYkqQDOypU5j1DagYGwEAgAAOiQCAAAFQIA== Date: Wed, 12 Feb 2020 22:58:30 +0000 Message-ID: References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie> In-Reply-To: <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [170.135.245.64] x-ms-oob-tlc-oobclassifiers: OLM:9508; received-spf: None (protection.outlook.com: usbank.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-messagedata: 9zSls3VmJfYtksmNVE/5EdumNRnUsWPazynnLvXBPnjTr81PEVpnW0Nx1x0R1NvavKQimX9ACNrQuZlQldOSdXzU37bqffuI8izycibyebKnfMmTLWgglnpDmXnp+gP8Bi9SH2BSn/fYrUbZmJvwxQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: usbank.com X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uROXEnghDyuRYlqzOo+UiMjnaFu7jzVwZX+7fGnf6HRcqupGNL+e6ID5bJOFdT6NPnqKN6YH9Li7qqonkrTbEA== Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 22:58:41 -0000 KzEgICBBZ3JlZWluZyB3aXRoIFN0ZXBoZW4gaXMgbmV3IHRvIG1lIGJ1dCB0aGVyZSBpcyBhIGZp cnN0IHRpbWUgZm9yIGV2ZXJ5dGhpbmcuICA7LSkNCg0KRGFyaW4NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IFRMUyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBP ZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMjAgNDo1 MCBQTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD47IEJsdW1lbnRoYWws IFVyaSAtIDA1NTMgLSBNSVRMTCA8dXJpQGxsLm1pdC5lZHU+OyB0bHNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFtFWFRFUk5BTF0gUmU6IFtUTFNdIFJlcXVlc3Rpbmcgd29ya2luZyBncm91cCBhZG9wdGlv biBvZiBkcmFmdC1zdGViaWxhLXRscy1oeWJyaWQtZGVzaWduDQoNCg0KSGl5YSwNCg0KT24gMTIv MDIvMjAyMCAyMTo1NywgTWFydGluIFRob21zb24gd3JvdGU6DQo+IE9ubHkgYSBmZXcgb2YgdGhl bS4gIFNvbWUgYXJlIE9LLCBidXQgdGhlIG51bWJlciBpcyBmZXcsIEkgYWdyZWUuICBJIA0KPiBo YXZlbid0IGZvdW5kIGEgZ29vZCBzdW1tYXJ5IG9mIHRoZSBzZWNvbmQgcm91bmQgY2FuZGlkYXRl cyBhbmQgSSANCj4gZG9uJ3QgaGF2ZSB0aW1lIHRvIGRpZyBpbnRvIGFsbCBvZiB0aGUgY2FuZGlk YXRlcy4NCkZpbmUgcmVhc29uIHRvIHdhaXQgYW5kIHNlZSBJTU8uDQoNCkknZCBiZSBtdWNoIGhh cHBpZXIgYWRvcHRpbmcgdGhpcyBpZiB3ZSBkaWQgdGhhdCB3aXRoIHRoZSBleHBsaWNpdCB1bmRl cnN0YW5kaW5nIHRoYXQgd2Ugd29uJ3QgcHJvZHVjZSBhbiBSRkMgdW50aWwgdGhlICJ3aW5uZXJz IiBpbiB0aGUgTklTVCBwcm9jZXNzIGFyZSBrbm93biBhbmQgdGhlaXIgcHJvcGVydGllcyB1bmRl cnN0b29kLiAoSSBkb24ndCBtZWFuIHdhaXRpbmcgZm9yIGEgRklQUyBvciBmb3JtYWwgTklTVCBk b2N1bWVudCBidXQgYXQgbGVhc3QgZm9yIHRoZSBmaW5hbCBhbm5vdW5jZW1lbnQgZnJvbSB0aGVp ciBwcm9jZXNzLikNCg0KSWYgdGhlIHBsYW4gd2VyZSB0byBhZG9wdCB0aGlzIGFuZCBwcm9kdWNl IGFuIFJGQyBub3cgKGUuZy4gdG8gbWl4IGRpZmZlcmVudCBjdXJ2ZXMgb3Igc29tZXRoaW5nKSB0 aGVuIEkgYW0gYWdhaW5zdCB0aGF0LiBUaGVyZSdzIG5vIG5lZWQgZm9yIHN1Y2ggY29tYmluYXRp b25zIHNvIHRoZSByZWFsIHJhdGlvbmFsZSBoZXJlIGlzIFBRQyBhbmQgd2UgKGF0IGxlYXN0IEks IGJ1dCBJIHN1c3BlY3QgYWxzbyBtYW55IElFVEYgcGFydGljaXBhbnRzKSBkb24ndCBrbm93IGVu b3VnaCBhYm91dCB0aGUgcmVsZXZhbnQgYWxnb3JpdGhtcyB5ZXQuIChBbmQgZXhwZWN0aW5nIHVz IHRvIGJlIGtub3dsZWRnZWFibGUgYWJvdXQgMjUrIGFsZ29yaXRobXMgaXNuJ3QgcmVhbGlzdGlj LikNCg0KQ2hlZXJzLA0KUy4NCg0KCgpVLlMuIEJBTkNPUlAgbWFkZSB0aGUgZm9sbG93aW5nIGFu bm90YXRpb25zCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpFbGVjdHJvbmljIFByaXZhY3kgTm90aWNlLiBUaGlzIGUt bWFpbCwgYW5kIGFueSBhdHRhY2htZW50cywgY29udGFpbnMgaW5mb3JtYXRpb24gdGhhdCBpcywg b3IgbWF5IGJlLCBjb3ZlcmVkIGJ5IGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbnMgcHJpdmFjeSBs YXdzLCBhbmQgaXMgYWxzbyBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5IGluIG5hdHVyZS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGJlIGFkdmlzZWQg dGhhdCB5b3UgYXJlIGxlZ2FsbHkgcHJvaGliaXRlZCBmcm9tIHJldGFpbmluZywgdXNpbmcsIGNv cHlpbmcsIGRpc3RyaWJ1dGluZywgb3Igb3RoZXJ3aXNlIGRpc2Nsb3NpbmcgdGhpcyBpbmZvcm1h dGlvbiBpbiBhbnkgbWFubmVyLiBJbnN0ZWFkLCBwbGVhc2UgcmVwbHkgdG8gdGhlIHNlbmRlciB0 aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgYW5kIHRo ZW4gaW1tZWRpYXRlbHkgZGVsZXRlIGl0LiBUaGFuayB5b3UgaW4gYWR2YW5jZSBmb3IgeW91ciBj b29wZXJhdGlvbi4KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo= From nobody Wed Feb 12 15:01:32 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778AD12002E for ; Wed, 12 Feb 2020 15:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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_LOW=-0.7, SPF_HELO_NONE=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=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxC_4uSm0-G0 for ; Wed, 12 Feb 2020 15:01:28 -0800 (PST) Received: from mr85p00im-hyfv06011301.me.com (mr85p00im-hyfv06011301.me.com [17.58.23.184]) (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 5BB82120026 for ; Wed, 12 Feb 2020 15:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1581548487; bh=pkH58alwUOjaSITDs06vzYrPacn41n6/f4RFLcXo0ZE=; h=Content-Type:Subject:From:Date:Message-Id:To; b=EEyGlIxG4jSy4gBtqI4942JExVpqXKtgujhmvIdUPh7D/Ed9WlIwdb6csUE3l/jUx 5Ch+LIAWTexhOPro6Cchsy0bJ10SkYpVculKLPhH+iSVABMruYBg3yf3uB2T0OaMvA gqqe1EDfVmynhR3ZMgs27IlJ5UWyU9gxAUtSSvFyr1dBQxrBtALSkHqbILruAMZVUn fYFTqV152Lu7HthHYWeLJdd1XFgB9U5SPNcakwVjbzY4YVzkOvBqbaOt9BSdQk+lup G/Qc1Qfsj1ixx85wWExPI0VSHRvEabceSBGEoeKCTYXR1rpEqBJPzGU0AG3mz9i+bo rPz3DaKlvMisQ== Received: from [17.230.167.54] (unknown [17.230.167.54]) by mr85p00im-hyfv06011301.me.com (Postfix) with ESMTPSA id 6F4025802D1; Wed, 12 Feb 2020 23:01:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.3\)) From: Carrick Bartle In-Reply-To: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> Date: Wed, 12 Feb 2020 15:01:26 -0800 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3608.80.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2002120159 Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 23:01:31 -0000 > At a high level, I think that this would be easier if it were more = clearly framed as *recommendations* I'm brand new to the IETF, so please forgive me if I'm totally off base = here, but my understanding is that Informational RFCs are explicitly not = recommendations (let alone mandates)? Per https://ietf.org/standards/process/informational-vs-experimental/: 'An "Informational" specification is published for the general = information of the Internet community, and does not represent an = Internet community consensus or recommendation.' > On Feb 12, 2020, at 12:46 PM, Martin Thomson = wrote: >=20 > On Thu, Feb 13, 2020, at 06:26, Douglas Stebila wrote: >> We would like to request the working group adopt >> draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as >> a working group item. We have updated the draft based on feedback >> we've received over the past few months, including from our >> presentations at IETF 104 and 105, and think the current version >> represents the view of the WG to date. >=20 > I agree that we should adopt this. I think that the draft is broadly = in the right shape. >=20 > Skimming through I noticed a few things that I would prefer to see = eventually changed, but we can do that in the working group. >=20 > At a high level, I think that this would be easier if it were more = clearly framed as *recommendations*, especially when it comes to the = format of key shares and the input secret. One advantage of the = macro-level design is that the format is can be specified on a = case-by-case basis. For instance, variable-length values might be = length-prefixed; fixed size values don't need to be. That might avoid = having to directly specify a single format.=20 >=20 > S 3.1 (Negotiation) suggests that a portion of the named group space = be reserved for this use. I think that is a bad idea because it implies = semantics where none are necessary. Picking codepoints as usual should = suffice; indeed, random allocation might be ideal. >=20 > The concatenation approach is definitely my preferred approach, but = the inconsistency between the design for key shares and secrets is = curious. This design assumes that shares are length-delimited; secrets = are not. The latter implies that the `ss` needs to be fixed length for = a given algorithm (both the PQ and classical parts), but `ct`/`pk` does = not. I can guess at why, but when you can avoid the question, then I = think you should. That is, in favour of more generic recommendations on = structure. >=20 > To answer some of the open questions: >=20 > Larger public keys and/or ciphertexts - if we need these, we're in = serious trouble. To give you an idea, even at 1k, these will start = being much harder to deploy. Getting close to 64k adds all sorts of = complication. Better to defer support for big messages. Acknowledging = the limitation should suffice. >=20 > Duplication of key shares - not so much an open question as something = the draft could acknowledge as a cost. As previously discussed X25519 = is small enough that duplication doesn't hurt enough to care. >=20 > Variable-length shared secrets - see above. >=20 > Resumption - I would be supportive of policy recommendations about the = strength of key exchange on resumption, but as we allow straight = resumption without PSKs, this cannot be standardized. >=20 > Failures - If this were low enough, I'd be happy to try again. =46rom = our perspective, this isn't technically challenging, it's merely = annoying. If this were very low probability (as I would expect), then we = might just accept the loss of the occasional connection attempt. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Feb 12 15:23:22 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AC412002F for ; Wed, 12 Feb 2020 15:23:20 -0800 (PST) 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=lowentropy.net header.b=hBxoH5BG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nMBvUAIJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8T6nhDD8b9k for ; Wed, 12 Feb 2020 15:23:19 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254DA12001E for ; Wed, 12 Feb 2020 15:23:19 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 72B4990A; Wed, 12 Feb 2020 18:23:18 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 12 Feb 2020 18:23:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=g+3SjF22dA5DYAq8wHto4syy1Yi4 W1znrFH4sXgeMKM=; b=hBxoH5BGaj8wIthxB+LCpMjMFkXcBI11NbgswHJTkxFW MoiYFRTT8VQP8ietaDEnVP7VPLzJ17lkdtESRNRdirVvVEAAGd8ROZ1uF3/PI3TJ ytYNA9SzyoeVAXhsYpo4lDpvkkeiUGv8AYg6iTs5IvxXcQXT5MSJd7M71/dUux9I ttFTq5kpmRmqEt08L0vSjRfHCAhtGtBHA1jQJJZ/u3agNoDy+GZ/kyZIypRtbOJ3 S9OqnbbzdoP4mcOHtNCBxy85IgzgdlwjJ+gteTu7zQNGfRypBewDnhSwQsOcRMng tsJv+XjsMqblAj5mKdluQMwNbk+ahFY5TwvUEQAfGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=g+3SjF 22dA5DYAq8wHto4syy1Yi4W1znrFH4sXgeMKM=; b=nMBvUAIJX43Xmu9WYJ6p// poWzokn5EHjw/Psi+YNoBY4g+ShkzLtnU+ReZvNk5GjKXbJIukCU5C2BgsgGhyJm urK7p1iVn5KBiR0UHlBUm5d6kqNrutwbTSsl0lnmADsPeZahhV3+EHekOpQOdQO4 mscb6VZn0cHP+A4niARe8Aa8Fndc6YNmhyjL1WYLl+4nmIwuMuJZ70vF5DWJqQQT Af9tfywR/9q61gMXwh1H16oHfVgH4/DxHcrF148bl3PVMvV3RyIA5I/q8mNaRsGa yrNRsdmWjJ1sDQm74VACB4iXnu2dLo+bt8bwwE7lXlBA6uujzLcDZ9vj3SnYFgng == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrieejgddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigv nhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 872AEE00A2; Wed, 12 Feb 2020 18:23:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> Date: Thu, 13 Feb 2020 10:22:58 +1100 From: "Martin Thomson" To: "Carrick Bartle" Cc: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Requesting_working_group_adoption_of_draft-stebi?= =?utf-8?q?la-tls-hybrid-design?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 23:23:21 -0000 On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote: > I'm brand new to the IETF, so please forgive me if I'm totally off base > here, but my understanding is that Informational RFCs are explicitly > not recommendations (let alone mandates)? This would of course be information, but my comment was about phrasing. This document comes off as being quite prescriptive, where it doesn't really need to be. Absent actual algorithms, it's just a set of guidelines. That's reflected in its Informational status, but it would be better if the verbiage also reflected that more clearly. To address Stephen's comment at the same time: I think that we can publish an RFC on this before the competition completes if it is just a framework. That might in fact make standardizing the one true composite scheme easier. From nobody Wed Feb 12 15:41:28 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7613F12002F for ; Wed, 12 Feb 2020 15:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 YMCTBd2172Fh for ; Wed, 12 Feb 2020 15:41:25 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A607A120019 for ; Wed, 12 Feb 2020 15:41:25 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id b7so3927580qkl.7 for ; Wed, 12 Feb 2020 15:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7jxFLbxyfNh20A3NBblVm9g04k9CtHsbGyl8h8pWl9I=; b=wvJyeDcXxq9naRGzsk2pqGmWkGqMYICHAy1YJ70IgBU0wcrn+w1Kmxq7aL2iKY6o3C qMOF0mSxPS7VU5XA1ncuwPmrxvdl6fOlejv5JM/NToGxHWxsZN1PFz0Xh4BWiRYP9Mc3 wQeBnEtUOmX5enbfhOvfDJzskC4iBySigk1iY= 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:content-transfer-encoding; bh=7jxFLbxyfNh20A3NBblVm9g04k9CtHsbGyl8h8pWl9I=; b=AkR+yR+tvajohiWXYGKjiMYWAQPRzBhYI9uqLwRz9sXbmJMLHMkrc9LjKHT2cdAdeC HtLspWeQpWPVlmW3S34vX8zBdjNrzTZjvNf100saPrmutxbn1V09bk+xLhXohwh9LFLK vIKaIIxEOOlpKRYm0wV3QogWqfa6ARFFweIhEJro1vWCTSKtjxD0IUNivsu+FU7GKGr+ UNA/e+/bGrGxoYwHh/jTz8C3WFoZNGMmRTwBeEIbyADLcu3spBPYRVfWlGyrkf0O5nOQ y9xUjXyps2h+L+skTdAE1b+DKlrGicuWoPfAYRbxOqVrztIiHgCcuH4ZV414pwOTd0Xl l0hg== X-Gm-Message-State: APjAAAWlSK5EpVT9xXU7vDspPErWc9+L2z+JMuJpvKs4DD4TQvlt/Zhj wzKIVf4tibloNaTV5wOEMFNLY24r3Olb8DLfI6eELw== X-Google-Smtp-Source: APXvYqz9PmeOzGEcFWS04hNrPJllYh9eLfESIa+9SeV7RSCtppmQ9moAbqUWEs6XKn48nFIolaH37DT0YWc9qKrUBnU= X-Received: by 2002:a37:9407:: with SMTP id w7mr7962064qkd.55.1581550884399; Wed, 12 Feb 2020 15:41:24 -0800 (PST) MIME-Version: 1.0 References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> In-Reply-To: From: Watson Ladd Date: Wed, 12 Feb 2020 15:41:13 -0800 Message-ID: To: Martin Thomson Cc: Carrick Bartle , tls@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 23:41:27 -0000 On Wed, Feb 12, 2020 at 3:23 PM Martin Thomson wrote: > > On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote: > > I'm brand new to the IETF, so please forgive me if I'm totally off base > > here, but my understanding is that Informational RFCs are explicitly > > not recommendations (let alone mandates)? > > This would of course be information, but my comment was about phrasing. = This document comes off as being quite prescriptive, where it doesn't reall= y need to be. Absent actual algorithms, it's just a set of guidelines. Th= at's reflected in its Informational status, but it would be better if the v= erbiage also reflected that more clearly. > > To address Stephen's comment at the same time: I think that we can publis= h an RFC on this before the competition completes if it is just a framework= . That might in fact make standardizing the one true composite scheme easi= er. What's the point of composite schemes after the NIST competition finishes? The reason imho to have composite schemes now is to be able to do deployment experiments where the security of the postquantum scheme doesn't negatively impact the confidentiality of the transmitted data. Obviously after a scheme has significant cryptanalysis thrown at it, the value of a composite decreases because the scheme is considered much more secure, and so the composite adds much less security and still has costs. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Feb 12 15:52:38 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F65C12002F for ; Wed, 12 Feb 2020 15:52:36 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 9da_DqMPwnv2 for ; Wed, 12 Feb 2020 15:52:33 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCDC120019 for ; Wed, 12 Feb 2020 15:52:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76C86BE39; Wed, 12 Feb 2020 23:52:31 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bzJda0Dxm0E; Wed, 12 Feb 2020 23:52:29 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 81EB1BE2E; Wed, 12 Feb 2020 23:52:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1581551549; bh=rGc/rk9cMWo33GdiJxJX1n+kIsnB7wEswlgRSCHrg8U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=E0KjaSBepnFfUSosrAdhuHbyCsfyabLQblGOU4Nm2MrsLWE4SwSdYLV+LTQnFKesP MBZt4XP/y1lbCh+pONvNiAdoRegylYCZsQjIqRgAQmzH5JbWtlORfQur5C5AtLcLE+ wuvn6JmnytpfRjm3k45jYlSaJj+5lrscylqNzcXE= To: "Blumenthal, Uri - 0553 - MITLL" , Martin Thomson , "tls@ietf.org" References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 12 Feb 2020 23:52:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e3vYkTDBJpaCvrc72adIz7GLuLfkHGxrP" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 23:52:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e3vYkTDBJpaCvrc72adIz7GLuLfkHGxrP Content-Type: multipart/mixed; boundary="lsHwxKMtpO1PJw55TKMEIU2VELayHX1PE"; protected-headers="v1" From: Stephen Farrell To: "Blumenthal, Uri - 0553 - MITLL" , Martin Thomson , "tls@ietf.org" Message-ID: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie> In-Reply-To: --lsHwxKMtpO1PJw55TKMEIU2VELayHX1PE Content-Type: multipart/mixed; boundary="------------2F9DC788B3AFB26A7E1FD1FF" Content-Language: en-US This is a multi-part message in MIME format. --------------2F9DC788B3AFB26A7E1FD1FF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 12/02/2020 22:57, Blumenthal, Uri - 0553 - MITLL wrote: > I don't expect you to be knowledgeable about 25+ proposed=20 > algorithms. I didn't mean it was you forcing that on me, but if you want to give it a shot... :-) >=20 > I expect you to be knowledgeable about the ballpark of the new key=20 > sizes that practically all of the candidates use. The shortest keys=20 > are in the ballpark of a few KB, and I won't go into the size of the=20 > largest ones. Sorry but my understanding is that there are relatively complicated combinations involving both performance and sizes of the various PDUs and stored keys involved. I don't think it'd be a good plan to specify how to handle that on the Internet until the details are better known and understood and the set of possible options is small enough to be sensibly evaluated in detail. IMO, we're not there yet. (And I'll bet a beer that even after we have 'em, each of the "winners" arrives with 5 or so variants;-() >=20 > You may not want to *adopt* them now - but you better be ready to=20 > support Key Exchange for sizes far larger than what's currently=20 > implemented. And keep in mind that while Signatures aren't a > priority yet, that will come eventually. We knew that years ago. The sky hasn't fallen yet. I doubt it'll fall in the next 12-18 months. In contrast I would not be at all surprised to find we'd made a well-meaning mistake in trying to standardise this stuff in the absence of a broad understanding of the detail. Maybe putting it another way might help: my experience is that the worst work I've done involved such ignorance and what I think of as the less bad work I've done did not. Maybe others are better than me at dealing with "known unknowns" though, though IIRC the circumstances that lead to that phrase didn't pan out as well as had been hoped. And one minor addendum: On 12/02/2020 23:41, Watson Ladd wrote: > What's the point of composite schemes after the NIST competition=20 > finishes? SHA-0:-) Cheers, S. >=20 >=20 >=20 > =EF=BB=BFOn 2/12/20, 5:50 PM, "Stephen Farrell" =20 > wrote: >=20 > Hiya, >=20 > On 12/02/2020 21:57, Martin Thomson wrote: >> Only a few of them. Some are OK, but the number is few, I agree. I >> haven't found a good summary of the second round candidates and I >> don't have time to dig into all of the candidates. >=20 > Fine reason to wait and see IMO. >=20 > I'd be much happier adopting this if we did that with the explicit=20 > understanding that we won't produce an RFC until the "winners" in > the NIST process are known and their properties understood. (I don't > mean waiting for a FIPS or formal NIST document but at least for the > final announcement from their process.) >=20 > If the plan were to adopt this and produce an RFC now (e.g. to mix=20 > different curves or something) then I am against that. There's no=20 > need for such combinations so the real rationale here is PQC and we=20 > (at least I, but I suspect also many IETF participants) don't know=20 > enough about the relevant algorithms yet. (And expecting us to be=20 > knowledgeable about 25+ algorithms isn't realistic.) >=20 > Cheers, S. >=20 >=20 >=20 --------------2F9DC788B3AFB26A7E1FD1FF Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------2F9DC788B3AFB26A7E1FD1FF-- --lsHwxKMtpO1PJw55TKMEIU2VELayHX1PE-- --e3vYkTDBJpaCvrc72adIz7GLuLfkHGxrP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5Ej7wACgkQWrL68XsX K+qHjRAAyg+QlGA47TiG5wHfYM1fyG8SWlEJNtv/2NpjfLNDJo3WhzqKItFm8ufi xyxgAtRNEO2tu7kzSbsmhOcAucjs8NQJxuNwCqnLVzaZEi6rkN2cnVmLXNt0/+eV qEt0vMFDFos61extBq4QEIXIwxjLqEkWnZBApNUsL4k52P8qYQmUiruMzBf+W1zb MiFwA/wHUrD3z3Q/Gn/e65vk8TTjhrfvtumZBxvpul/texM+TFd3F1rtzSwXMh4q gvNNOIFaptBP/PMr5EDk1q0DpdbfIFYsdE5pXcMjRQ4ol+7qJDD3T8/OAOEXLHav 36YzFMgx4o/SALkwse8UrCNruXwmnCDz+HCYPvB+49nKUi+H8tmNL4ZjjsTO11vY oIvz4whrI4x4ov7NZ+Iul4OOTI5tAG3p/pLWsMcMIueFHPQNwirCv3t9B5Tx+YRc JVkvAdvl3wvReaG8BgkUinJZ7R3pWbEUeCZ4bR0XFrGRQT/ykpP1A9ENOIMA3RBa S3EGiw6QlIs6tAznBts9V+jM+sR0koRuVvCeegckmyopwrw/evSedgaLP/lwKcqh hqcWOQyZ3q8cA0T2iq77vhQffX962xDZQaOOZwF7TARvhkvaU2u+2omyrUfhx2g8 I45sR7DLL+ZjHH6NX8iHKcbFvgnqfA8hNcTaksik1sQm6PUh6Rk= =6BJb -----END PGP SIGNATURE----- --e3vYkTDBJpaCvrc72adIz7GLuLfkHGxrP-- From nobody Wed Feb 12 20:24:25 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE0412008C for ; Wed, 12 Feb 2020 20:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 PMJjBATsA2QD for ; Wed, 12 Feb 2020 20:24:19 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7315812008A for ; Wed, 12 Feb 2020 20:24:19 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id z8so4981272ioh.0 for ; Wed, 12 Feb 2020 20:24:19 -0800 (PST) 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=gOydzurpRzmyot1vkY692z2HabX0nM1Mudt3yeflcxM=; b=rk1Ku6exoWVBsKcEXGFgXEXziWvULyRrMuvOY7MFGC47EyY+rBDRtSPBZVQAuCjPI4 +Z3k72ANSZvZluxBfCJBZ5fQVUFnEm5O75duwtxJaCwJqsUbnMZbygsYl+qikEx4hD8f /7d3m7ae2AXuMeAW7WVX1XE+ThLT/So7hrVhEaLDMtgfA/r37EhR/Q/T1LLfJXL7Tm7G jyzYzPteggd6ocuPywYPXog/S3IKmgM4uFOeDKQp4Rq0ql8Gd3RNmWuu0410YPXCIhd1 PKI+Wm4jWE6T8nhhx7ux3WBZpslMfJOBF+uIkzHN+e6r214b7/Z2lXrB5noWdwn4M0Fs 5Nqw== 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=gOydzurpRzmyot1vkY692z2HabX0nM1Mudt3yeflcxM=; b=W6p3qj2kAb2Z2NogaTv1Ul1V6oK3d51zUg51zpRYmwmKVszHF+2lXx/PfM1kmdsZwB rit5WmEfL2S/jMFf1SdvLuI6PdphC77UPt7nFVuUebI4zBLVA1gi7OmfynR6J6qctlUS r1wjV5VbsobvU5GXLrZ8XeEwfR+wQ3pB39iXtP4Eoex5PPl8O9pdbISRxLAcCmVIgNt3 E9iHICFQstnY/Cb3eXgonyExdH2SeJb9/Ra2Cl7z7g4qm5V0Mh67/d1R4a05JfZnUOpB GARv1R6iMYOkZKomjqbwLlha1IB1EmAURlSoU2kINgtphsT02TeiROHAuhPhL/O1ZNNH dHcA== X-Gm-Message-State: APjAAAWM0M68Gg54fTIoWQx3Mu2EF6jflniizJVNQnCLSruQUVPEpNXq sIX5/FY5W2QjlIgLgFmrYsqcUY4Pa4kLAi9PlBM= X-Google-Smtp-Source: APXvYqwitDovxc9M04ONF6wamjMg3d4v3vhZZy+M52DIbKFLFdcXwmit7EObKjkcPr51d4W0G5BucmJeRaQK5+ZPiuk= X-Received: by 2002:a05:6638:723:: with SMTP id j3mr22197281jad.131.1581567858312; Wed, 12 Feb 2020 20:24:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Wed, 12 Feb 2020 20:24:03 -0800 Message-ID: To: Douglas Stebila Cc: "" , Shay Gueron Content-Type: multipart/alternative; boundary="000000000000620a17059e6d76f0" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 04:24:23 -0000 --000000000000620a17059e6d76f0 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 12, 2020 at 11:26 AM Douglas Stebila wrote: > Dear TLS working group, > > We would like to request the working group adopt > draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as > a working group item. We have updated the draft based on feedback > we've received over the past few months, including from our > presentations at IETF 104 and 105, and think the current version > represents the view of the WG to date. > > https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ Hi, Thanks for submitting this draft. Would it be ok to add a rationale to the "Goals" section around backward compatibility? I'm not sure how the compatibility points will interact with downgrade attacks. thanks, Rob --000000000000620a17059e6d76f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 12, 2020 at 11:26 AM Douglas = Stebila <douglas= @stebila.ca> wrote:
Dear TLS working group,

We would like to request the working group adopt
draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3"= , as
a working group item.=C2=A0 We have updated the draft based on feedback
we've received over the past few months, including from our
presentations at IETF 104 and 105, and think the current version
represents the view of the WG to date.

https://datatracker.ietf.org/doc/dr= aft-stebila-tls-hybrid-design/

Hi,

Thanks for submitting this draft.=C2=A0
=
Would it be ok to add a rationale=C2=A0to the "Goals&qu= ot; section around backward compatibility? I'm not sure how the compati= bility points will interact with downgrade attacks.

thanks,
Rob
--000000000000620a17059e6d76f0-- From nobody Thu Feb 13 03:39:54 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC9F1200C3 for ; Thu, 13 Feb 2020 03:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 IEoA0tbfDlhN for ; Thu, 13 Feb 2020 03:39:51 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EB6120043 for ; Thu, 13 Feb 2020 03:39:50 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id c188so5316901qkg.4 for ; Thu, 13 Feb 2020 03:39:50 -0800 (PST) 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=Z2dkq6FgfDFvqYBZvPkhP5tjGl8MKQtxlODb6krYQsA=; b=NW3SVdwkRMAbYlBUdLXePouJhyJvs/KdopjLyOc4IOG1gD6DxN/Ph7asbh86UExyEZ 3K+qLMamFYB0l3OtU9m7+70fG40tCbbEnerg7aSPe3iONocq4Myo9wMRWZwfrltscJBy CGv2aT/6hD7pfXVTAjiU6rjRkOEguR4SkG8CWVtWsp6v6EWEoFWGXmotUdmwpRm3UhCj wcrX+DAhQ6NN3mYsegbSZPMnn7qlMOdfYSlkIFGLD+oKWL7r6LYHE94bippcTz8z9+hZ uN14go+0amxR6D+L6pJR9ZCLybn9lLBVHyYoIsvE9jtmnmD5M12OY2daTdDxz4r6ybCs 3vew== 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=Z2dkq6FgfDFvqYBZvPkhP5tjGl8MKQtxlODb6krYQsA=; b=hzSdptSyagbwerWECH1HG3cAq5ou/uQ5SY+G2pBaHbp27RbMctDzIXEKKchHkucTe8 AuOW7UgLiGTz8gnPVjPZeYmsqITO19TssHECOhL/kNOZ6/2g61waJLZCimmauqrio50B dmuTcgn4f/QfaxKD3OAwzu6PB0Fj0g6EQp7b3EmWh02MVOfywJOEareuenfzaluAkZsP zdsBVWt2FbhUvb4cWGySkZatMFd/myYO1m1B3RKZc0sC65kpe4qdyLoY4ixWIO1ha3dv G3EG6/aTXmpmMRXJfYrQUkG760mFq3/zFM55bFQORTlwY8/cmaDCo9QSBeq5bw57KmG+ cEFw== X-Gm-Message-State: APjAAAWtevh1/3cjMbotMq+sL43ZI0qeKdgcJ2v1iq3yZnsHMYs6o9Xb vUe0eYs/XFT3q+lo65F449HvUS5i X-Google-Smtp-Source: APXvYqziYnK52rgIi8ApCvSXlTiIYZ6RarLvY7MfRif7v4ah1a/98O+5I6X6jQEkn9U5b7jfwqHwDA== X-Received: by 2002:ae9:e8d2:: with SMTP id a201mr4890552qkg.47.1581593989941; Thu, 13 Feb 2020 03:39:49 -0800 (PST) Received: from laptop-picard.coleridge (CPE881fa12cf37b-CMa84e3fc93e50.cpe.net.cable.rogers.com. [99.250.203.26]) by smtp.gmail.com with ESMTPSA id l19sm1149447qkl.3.2020.02.13.03.39.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Feb 2020 03:39:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Douglas Stebila In-Reply-To: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> Date: Thu, 13 Feb 2020 06:39:46 -0500 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 11:39:52 -0000 Hi Martin, Thanks for the suggestions. Indeed, happy to incorporate changes in = framing, tone, etc. to better reflect the purpose of the document. > At a high level, I think that this would be easier if it were more = clearly framed as *recommendations*, especially when it comes to the = format of key shares and the input secret. One advantage of the = macro-level design is that the format is can be specified on a = case-by-case basis. For instance, variable-length values might be = length-prefixed; fixed size values don't need to be. That might avoid = having to directly specify a single format.=20 >=20 > [...] >=20 > The concatenation approach is definitely my preferred approach, but = the inconsistency between the design for key shares and secrets is = curious. This design assumes that shares are length-delimited; secrets = are not. The latter implies that the `ss` needs to be fixed length for = a given algorithm (both the PQ and classical parts), but `ct`/`pk` does = not. I can guess at why, but when you can avoid the question, then I = think you should. That is, in favour of more generic recommendations on = structure. There are examples of current PQ candidates that have variable sized ct = / pk: SIKE has compressed and uncompressed variants, which are = mathematically interoperable and would result in the same shared secret, = but trade smaller communication for more computation. To the best of my knowledge, none of the current PQ candidates have = variable sized shared secrets. We did have some debate internally when preparing the draft about = whether shared secrets should have length encoding or not, and in the = end decided not, despite the apparent inconsistency in design. Douglas From nobody Thu Feb 13 03:48:30 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CC71200F1 for ; Thu, 13 Feb 2020 03:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 mZ8oKxc-YVmx for ; Thu, 13 Feb 2020 03:48:27 -0800 (PST) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C16A120013 for ; Thu, 13 Feb 2020 03:48:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id D1A52C0755; Thu, 13 Feb 2020 11:48:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at emo04-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo04-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcEI6h9iQJqb; Thu, 13 Feb 2020 11:48:26 +0000 (UTC) Received: from laptop-picard.coleridge (CPE881fa12cf37b-CMa84e3fc93e50.cpe.net.cable.rogers.com [99.250.203.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 860A9C06E2; Thu, 13 Feb 2020 11:48:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Douglas Stebila In-Reply-To: Date: Thu, 13 Feb 2020 06:48:21 -0500 Cc: Shay Gueron , "" Content-Transfer-Encoding: quoted-printable Message-Id: <64255C99-9C23-4F8E-A2F0-DA7B43572E2C@stebila.ca> References: To: Rob Sayre X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 11:48:29 -0000 On Feb 12, 2020, at 11:24 PM, Rob Sayre wrote: >=20 > Would it be ok to add a rationale to the "Goals" section around = backward compatibility? I'm not sure how the compatibility points will = interact with downgrade attacks. For now I don't think we're envisioning anything different on downgrade = compared to current DH group negotiation. For example, a client that = prefers curve25519 but also is willing to use nistp256 should be able to = talk to a server that only supports nistp256. If the server also = supports curve25519, an adversary who removes curve25519 from a hello = message to try to trick them into 'downgrading' to nistp256 would = eventually be caught by the handshake transcript authentication. The = same holds in this setting. Douglas From nobody Thu Feb 13 07:36:13 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49FA120121 for ; Thu, 13 Feb 2020 07:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ3E-aPP_3AY for ; Thu, 13 Feb 2020 07:36:08 -0800 (PST) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2134.outbound.protection.outlook.com [40.107.91.134]) (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 E39B41200C7 for ; Thu, 13 Feb 2020 07:36:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mT2xVUaWIYizcD6MyE261MpFzXiWdzsqv/Hk3DhrXfurPFTbfkUewYyQMzU/EBTI+79OMNnFbbGWmmerhIpmdQhwUDFlJDcnNmCHW2dxLlxfbDrreA3zwVi72+20SNCy6pABCadbGWU0mTp4uI9kjiUFuaDtGcJEXo8zRhU4U6mR+VS4BgP65zI5yfBB1SBIN9nSUl12o4eZRGEHSPAQNwktkSsnI6wUEnFlwh9k2faKhotqPX9m5ww+RbS8R5r4rBZFCMGRKsZvx8cmYOVnDLAxE3mSaOh86LiJ8dyQZk5HadjfBWBUnOrPYSkPCPwJEGw1qcYse7ZhPqBUeX9Nmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RqW0YU5vLzDGZ5KfewQBgBdWiC48DzA+Avo84Tq7Caw=; b=lJj/Hq/E0IyqgGC3tMWvPPrkk7HJkN9Y3dH/HcKKsaFoC2xZWHEklDa++KkeVCNP5lKzYh7C8qCIdadPBSTNsYcIFW1+tS3PbycFmorrnSTY0mh6efAkh0Nx3GP3N5Dhdwjw7V3+3bVXDfGipvpPQEnAtfVd+DgO8lRP4s6vVosUMTyGoEOWWAt5TJT+WfKb6NhXnezx0q5wzM5rX75ZNdCW41eUW30KvlVsdyx8tFye2HlkHfYh6gsN2jBPJRg5zwVVqap/mRhXhfjAnleGB60acXR73FuRSIsv3llbvaL/osA6hsjiopzw/vBNPKdvFL28SsFhbRtDez+X2D0xFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RqW0YU5vLzDGZ5KfewQBgBdWiC48DzA+Avo84Tq7Caw=; b=bz3dv9Vc8ddxGwijH8KsHiVAaqmJ/3DHNeKkqOYyiwxnGuJorhajLhhzrsiIIwTPBydSQDyldpuMnnaxATR2n6DFmszzuKvllldQgdagnlZ6oKmdFh4JOfT0LZZ70CT8/iiFH0tlstFSuib5EzLmw8mqV+uzG6Dc/jYYIhnxSc4= Received: from CH2PR09MB4220.namprd09.prod.outlook.com (10.186.136.73) by CH2PR09MB4124.namprd09.prod.outlook.com (10.186.139.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.22; Thu, 13 Feb 2020 15:36:05 +0000 Received: from CH2PR09MB4220.namprd09.prod.outlook.com ([fe80::cdd1:f65b:961e:8161]) by CH2PR09MB4220.namprd09.prod.outlook.com ([fe80::cdd1:f65b:961e:8161%7]) with mapi id 15.20.2729.025; Thu, 13 Feb 2020 15:36:05 +0000 From: "Dang, Quynh H. (Fed)" To: Martin Thomson , "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Thread-Topic: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design Thread-Index: AQHV4e+NOu/1zXhTCUOLdsw/9xTXAKgZQntL Date: Thu, 13 Feb 2020 15:36:05 +0000 Message-ID: References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> , <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> In-Reply-To: <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.219.225] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a24fbd15-a6ad-49d0-a106-08d7b09a70a7 x-ms-traffictypediagnostic: CH2PR09MB4124: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 031257FE13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(136003)(39860400002)(376002)(396003)(189003)(199004)(45080400002)(966005)(55016002)(110136005)(478600001)(316002)(9686003)(5660300002)(7696005)(19627405001)(66446008)(86362001)(64756008)(26005)(76116006)(71200400001)(186003)(66476007)(66556008)(33656002)(53546011)(66946007)(2906002)(81156014)(6506007)(81166006)(52536014)(8676002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR09MB4124; H:CH2PR09MB4220.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EOmc7wZbmWZO9UMaNy8nmb98tf4TMDUYO8mNZio1cKwwmfgFgqFVSZODmZ3NsX+IMYWYih4QtnYokKh3/VarixhLhp2+vqxIciJ+k7WALoWjnglf7KmTMnevjqTnU15K32SJX0kxm3Kgwb44GF9TGEcJ8u+8d14kFUNH3JshXN5HWl9VHn0HXLJLUevgIYvF/nqS8jtMfF617bjZV03AX+vLT5xST+qbP2ixRR640+WDaDPVzH6IwjtOnWHs9GMIT1H0dmbNKZoTpZdDinkx2s5vAek/43ysRhjKFYnOX5oyGOIVuwGqBvuGr9Vn1VGZe3ZYjQiBejGn85jXzhtw2x6R/C+0sJJhLvUAoHD3UZD0VEXI6943XuiqvsOibWsCZQKqoU5ahI15vX2OhK+g7CAVJPt00wn7t1XaRn0M/dJvklDNA2ryiPIT37zYplRiTlVRpNYGfyrRv/QUvpHEd5noPo2n/nFzEd8IGSD4V5HZ1tkojqskqtYOF+Whr0wSGJtQIM4qtRE8beKxvU9u5w== x-ms-exchange-antispam-messagedata: XZ4PlBS8ra1o5jje3fg0SWqH636S3lOngfLqHHpCZBDApRt82t639AMSKo6so13RCXQDt00kwQYLXFMudGcrZnEN/8l7EuMQ+srgM95IEjTHEVBkZ/NagV5mEvw3MzP5fYo4zElg+LmCnnY8UW3I6g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR09MB4220CED5DAE986CB4475F9CDF31A0CH2PR09MB4220namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: a24fbd15-a6ad-49d0-a106-08d7b09a70a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2020 15:36:05.6147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nUeUkvZ0+/rl5uyCnNT4MDJrXyKbCRUUfjEZ0U1wcawwHY5ylv2U9ROwWcXNq7R5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR09MB4124 Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 15:36:11 -0000 --_000_CH2PR09MB4220CED5DAE986CB4475F9CDF31A0CH2PR09MB4220namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This website has a good summary of the candidates: https://pqc-wiki.fau.edu= /w/Special:DatabaseHome . Quynh. ________________________________ From: TLS on behalf of Martin Thomson Sent: Wednesday, February 12, 2020 4:57 PM To: Blumenthal, Uri - 0553 - MITLL ; tls@ietf.org Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-h= ybrid-design On Thu, Feb 13, 2020, at 08:44, Blumenthal, Uri - 0553 - MITLL wrote: > You saw the key sizes that the NIST PQC candidates require? How would > you suggest dealing with them unless there's support for larger public > keys? Only a few of them. Some are OK, but the number is few, I agree. I haven'= t found a good summary of the second round candidates and I don't have time= to dig into all of the candidates. _______________________________________________ TLS mailing list TLS@ietf.org https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Ftls&data=3D02%7C01%7Cquynh.dang%40nist.gov= %7C66ec528552554b52d03f08d7b006af16%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%= 7C1%7C637171415063382880&sdata=3DDdG71mohtkyXCdRplxvT1z5JWRvg53RqO98BKq= swIw4%3D&reserved=3D0 --_000_CH2PR09MB4220CED5DAE986CB4475F9CDF31A0CH2PR09MB4220namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This website has a good summary of the candidates: https://pqc-wiki.fau.edu/w/Special= :DatabaseHome  .

Quynh. 
From: TLS <tls-bounces@i= etf.org> on behalf of Martin Thomson <mt@lowentropy.net>
Sent: Wednesday, February 12, 2020 4:57 PM
To: Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>; tls@ietf.= org <tls@ietf.org>
Subject: Re: [TLS] Requesting working group adoption of draft-stebil= a-tls-hybrid-design
 
On Thu, Feb 13, 2020, at 08:44, Blumenthal, Uri - = 0553 - MITLL wrote:
> You saw the key sizes that the NIST PQC candidates require? How would =
> you suggest dealing with them unless there's support for larger public=
> keys?

Only a few of them.  Some are OK, but the number is few, I agree. = ; I haven't found a good summary of the second round candidates and I don't= have time to dig into all of the candidates.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://gcc01.safelinks.p= rotection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinf= o%2Ftls&amp;data=3D02%7C01%7Cquynh.dang%40nist.gov%7C66ec528552554b52d0= 3f08d7b006af16%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637171415063382= 880&amp;sdata=3DDdG71mohtkyXCdRplxvT1z5JWRvg53RqO98BKqswIw4%3D&amp;= reserved=3D0
--_000_CH2PR09MB4220CED5DAE986CB4475F9CDF31A0CH2PR09MB4220namp_-- From nobody Thu Feb 13 07:42:57 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEBC120124 for ; Thu, 13 Feb 2020 07:42:55 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 K2NIAY25_-zn for ; Thu, 13 Feb 2020 07:42:53 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 431DE1200C7 for ; Thu, 13 Feb 2020 07:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1581608573; x=1613144573; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6hHT77Tk+/erZqlWF6wG6CcM2fNLtTAN1XpGSGS2ekA=; b=adZerZEoxGhJLU7ZyEgYGu/ADUfztoJPkE4gaSC2als4rqN1KBgpPGto WjZzV5aJtqxzRav1axtFITFfemQ7b87qqe+8o9jhovRT57VW2mdiw5ByG gv3NVbtTy2nW2LqQK/XCAVl70WfuYM60m95UUOEQ1E/ZIRwYjpK2lnekT sfXRpGzYwnY6eQ4PDaNLrGF4+kVBn9s4/UMoP8oLX293hABBUez/opqER fN6QZhhxymmbYz5pn58+TnijEwmViZKTKj26JLxgmwT8iSuZVZ38+ByCW TSIUjBJtqeAyewo3Kk7Xk5TlHI/6gNImj9xKl5bmajK4apnVPDCm5jHd9 g==; X-IronPort-AV: E=Sophos;i="5.70,437,1574074800"; d="scan'208";a="115018461" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Feb 2020 04:42:51 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 14 Feb 2020 04:42:51 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 14 Feb 2020 04:42:50 +1300 From: Peter Gutmann To: David Benjamin CC: M K Saravanan , "" Thread-Topic: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange? Thread-Index: AQHV4W2CYeXLZ0I+bUablesS8zu9G6gXusN0//83jYCAAlMrzw== Date: Thu, 13 Feb 2020 15:42:50 +0000 Message-ID: <1581608577078.16607@cs.auckland.ac.nz> References: <1581523805582.16466@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] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 15:42:56 -0000 David Benjamin writes:=0A= =0A= >Note that bignum libraries that perform leading-zero truncation=0A= =0A= like OpenSSL, and some PKCS #11 libraries=0A= =0A= >are unlikely to be suitable for cryptography anyway.=0A= =0A= OK, I'll keep that in mind: OpenSSL and PKCS #11 are unlikely to be suitabl= e=0A= for cryptography :-).=0A= =0A= Peter.=0A= =0A= =0A= From nobody Thu Feb 13 09:13:16 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85E120058 for ; Thu, 13 Feb 2020 09:13:14 -0800 (PST) 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_HELO_NONE=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=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 anDAZXYiO5Ri for ; Thu, 13 Feb 2020 09:13:13 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CF01200C4 for ; Thu, 13 Feb 2020 09:13:13 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id r5so4906399qtt.9 for ; Thu, 13 Feb 2020 09:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=w3MEtutQJEOvsdM3IVkP/VEqsBSJXjIY1x3K0zm+HPs=; b=bFq8P31yU1R6n4OlO3GlZ4ugEpdI0a+zKfDgZfVNIzt9gG5qgU30Ec1ad+873JeKpk Yg4vH2SBUkLP97IUf9wlrPEvC36UYZU2MCYLxIl/g45CIa+d4uwd2TmxJDneuuzvExcQ hfTd64SoY+Lck5iyEw37Lpdnc8MEl5OxjqyUmSAe06Ku6yd3bpdD73MoyI7H4u4Xh87K AOBsnDQKB7RDtNqPPXhVOUxoTST77i2UwwZNVoJsBT7saHUfkcEe2WZq858I2eiBj6/B uG+ljk4m5APd9NkUkfnIubrgullWnQ0p9Ymvv3ftLInNmyADh8ZP2n3DuJiekzZIzIAB vxUA== 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=w3MEtutQJEOvsdM3IVkP/VEqsBSJXjIY1x3K0zm+HPs=; b=ZYBvUES+7Qd7H/wmttvmUquP+Xy0p1YLmGut+LJot/znzNtUJEyFDupyGAm5WKZKdD NwWzadDG5VMLtp4ZZ7ez+FEIj6jo+dQoqpLEfmAChJRPDLOUoPjpTNmLwAw76PZH5WaL xvIRoJKTu6ViqO6YUnfayBOiKElHbh9L0PqYoGxwzreUVbiPVCHbtLMruPzTrAy9d4Sc GI5jAP88w3gPq0sw5qvov5RmbXqLBL1sfFhufSUnl+jmcyu7Dgxt8C+edR/RUPE0Jb2t /u/ogVzGnKRe0A7UCMi19pvK6KpBn0BFk80rdaOOERqRY03tgzD/pcyex8tUvwka62sJ D1/w== X-Gm-Message-State: APjAAAWg3yhBfVGklJK1/kE472L+/mv9sjBxS+23tkUARhuPjwitlJem keOwEv6aZNInNa04uZD3ie4nQA2GZokC1FO0KaBOb+9FyO8= X-Google-Smtp-Source: APXvYqzw07N6KJ8vTsxdGd0UH2godbM8Ux1rpuGRKvNsEfAEV1oiCqFjcI84UGhQQ/psp0tuYQzQYqpCL0r1OY5hu3g= X-Received: by 2002:ac8:3aa6:: with SMTP id x35mr25284568qte.38.1581613990764; Thu, 13 Feb 2020 09:13:10 -0800 (PST) MIME-Version: 1.0 From: Joseph Salowey Date: Thu, 13 Feb 2020 09:12:59 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="00000000000017941f059e7834be" Archived-At: Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 17:13:15 -0000 --00000000000017941f059e7834be Content-Type: text/plain; charset="UTF-8" The authors of "Hybrid Key Exchange" have asked for adoption of their draft as a WG item. Please state whether you support adoption of this draft as a WG item by posting a message to the TLS list by 2359 UTC 28 February 2020. Please include any additional information that is helpful in understanding your position. NOTE: If the draft is adopted, the working group has change control over the draft and the timing of its progression. This means the document does not have to be perfect as the working group can and will make changes. Adopting the draft means the working group thinks the topic is a good idea and the draft is a good place to start the work. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ --00000000000017941f059e7834be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The authors o= f "Hybrid Key Exchange" have asked for adoption of their draft as= a WG item.=C2=A0 Please state whether you support adoption of this draft a= s a WG item by posting a message to the TLS list by 2359 UTC 28 February 20= 20.=C2=A0 Please include any additional information that is helpful in unde= rstanding your position.

NOTE:
If the draft is adopted, the worki= ng group has change control over the draft and the timing of its progressio= n.=C2=A0 This means the document does not have to be perfect as the working= group can and will make changes.=C2=A0 Adopting the draft means the workin= g group thinks the topic is a good idea and the draft is a good place to st= art the work. =C2=A0

Thanks,
Chris, Joe, and Sean

[0]=C2= =A0https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-des= ign/


--00000000000017941f059e7834be-- From nobody Thu Feb 13 10:47:12 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A851201CE for ; Thu, 13 Feb 2020 10:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 NsQTi4fZBj16 for ; Thu, 13 Feb 2020 10:47:08 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99D51201AA for ; Thu, 13 Feb 2020 10:47:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 07E33BE2E; Thu, 13 Feb 2020 18:47:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIWtWfYOmPsH; Thu, 13 Feb 2020 18:47:04 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4C79FBE24; Thu, 13 Feb 2020 18:47:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1581619624; bh=DKIqQMB8domIFfHpD2B1cV3xIJHvKdOQ1wTxDJ7NZ+M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SvEPnNgaqKstR/2Bftin68bSubCLQAjeYKGs0UdoVacNbOfaQ77v+QuDifGxhhzqX h0VK3RVXFwr+Q3TSuSZkLVP9RIaLj7m2hOUZLZSUKIObtmntjsSZ4sUAtf5bbTfTaR jLu9BSXPDo8gjnoFHmSsYHHqfL7gJKHXXZdjfNos= To: Joseph Salowey , "" References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Thu, 13 Feb 2020 18:47:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hRKcRhbcjE5c3gnTuWxHCSYpL1D4eQffK" Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 18:47:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hRKcRhbcjE5c3gnTuWxHCSYpL1D4eQffK Content-Type: multipart/mixed; boundary="bXnvUy3LcO8l4ZEGLlYhEjwDMHmhS4sFI"; protected-headers="v1" From: Stephen Farrell To: Joseph Salowey , "" Message-ID: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design References: In-Reply-To: --bXnvUy3LcO8l4ZEGLlYhEjwDMHmhS4sFI Content-Type: multipart/mixed; boundary="------------276798AB4AFBADA3EB2B8276" Content-Language: en-US This is a multi-part message in MIME format. --------------276798AB4AFBADA3EB2B8276 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I said this in the other thread but I'll repeat a call for a bit of clarity that's not normally needed: On 13/02/2020 17:12, Joseph Salowey wrote: > Adopting the draft means the working group thinks the topic is a good i= dea > and the draft is a good place to start the work. I think the draft would be ok to adopt if we don't finish it until the outcome from the NIST competition is known. Otherwise I would be against adoption. That needn't be an insurmountable problem though, e.g. if the chairs/AD created a milestone dependency on NIST having finished before publishing this, then that'd make it clear enough (for me at least). My request is an unusual one, in that we normally want to be finished asap, but in this case, doing a good job has that external dependency and I think we ought not finish before that's been resolved. Cheers, S. --------------276798AB4AFBADA3EB2B8276 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------276798AB4AFBADA3EB2B8276-- --bXnvUy3LcO8l4ZEGLlYhEjwDMHmhS4sFI-- --hRKcRhbcjE5c3gnTuWxHCSYpL1D4eQffK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5FmacACgkQWrL68XsX K+quRw/7Bk9kqKXyDPP24nEQnLYJPSpFaabzFk1Vi3i+e+236udgZHVd2PbpHijg tndnlqFb8ZOAYpl+sRanSan00M+qBiCVp2CGO9r5IpKkOF41DB0ZnIg8cH6bIYfD KaXVGUHD7hQEPFc01/DON7YsGzRcKo6sKsK+NXZzp7IZy291OhjSZxENZHdKmpIX ilBTJ3FWYaO/4gUDaxVmhp4Ed0ba5nwxyr/v/hY1ojyhEKreQNk+Ro09SWf3rOwq 1/a8QXKcwM3oHcZex7cWQKqk26Yzpqo6nSTf5I8gUDVkP97DyqRrQBTLEuLljIM/ FMev6ffypfS6InxPsAfSCGrTInZ9JW0UjPqN7PlwoCqy8P5sFEMk8RY64OqETlFY Gzz4Wqhxm8HgogyI6GzPAmkHkikE0JidigQSyW9EK3OiqBz3222+SXn+Q4SpxWQq lmPjjLGoryKSsZg/PlZ7qOfcSkwqoSE7ywDbaQAeKv1dGHKGVTAJvR1X618IR4DP lWnqpa6uHC9UwdaddOKuZBIrZC8/FnO7XeO5RgvFSXyyKuJPcx/css8m0bPWR26n EyqWbZRj0hD5c2TcrM3YSLz1ECQn0ZwKe5IFSjA0oIMWsWCnCqaxkichf1YoG44n rlmrj0VGSLI+TvcOmr45eHkgbAiwoKs6Q2ZCj/oGu9dGzBN01bs= =+Lic -----END PGP SIGNATURE----- --hRKcRhbcjE5c3gnTuWxHCSYpL1D4eQffK-- From nobody Thu Feb 13 10:48:22 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816D31201B7 for ; Thu, 13 Feb 2020 10:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 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, SPF_HELO_NONE=0.001, SPF_NONE=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 nJepx7sq6Upm for ; Thu, 13 Feb 2020 10:48:18 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 64BCF1201AA for ; Thu, 13 Feb 2020 10:48:18 -0800 (PST) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 01DImHHh033504 for ; Thu, 13 Feb 2020 13:48:17 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: "" Thread-Topic: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design Thread-Index: AQHV4pD4ln+ORR+S+0aBJaQuPhFLnqgZdyqA Date: Thu, 13 Feb 2020 18:48:16 +0000 Message-ID: <90CB5036-4BCB-4C7D-A691-D300C24111C7@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/10.21.0.200113 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3664446496_1865451379" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002130131 Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 18:48:20 -0000 --B_3664446496_1865451379 Content-type: multipart/alternative; boundary="B_3664446495_252976769" --B_3664446495_252976769 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I support its adoption. From: TLS on behalf of Joseph Salowey Date: Thursday, February 13, 2020 at 12:13 PM To: "" Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design The authors of "Hybrid Key Exchange" have asked for adoption of their draft as a WG item. Please state whether you support adoption of this draft as a WG item by posting a message to the TLS list by 2359 UTC 28 February 2020. Please include any additional information that is helpful in understanding your position. NOTE: If the draft is adopted, the working group has change control over the draft and the timing of its progression. This means the document does not have to be perfect as the working group can and will make changes. Adopting the draft means the working group thinks the topic is a good idea and the draft is a good place to start the work. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ --B_3664446495_252976769 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I support its adopt= ion.

=  

From: TLS <tls-bounces@ietf.org> on behalf o= f Joseph Salowey <joe@salowey.net>
Date: Thursday, February = 13, 2020 at 12:13 PM
To: "<tls@ietf.org>" <tls@= ietf.org>
Subject: [TLS] Call for Adoption: draft-stebila-tls-h= ybrid-design

 

The authors of "Hybrid Key Exchange" have asked f= or adoption of their draft as a WG item.  Please state whether you supp= ort adoption of this draft as a WG item by posting a message to the TLS list= by 2359 UTC 28 February 2020.  Please include any additional informati= on that is helpful in understanding your position.

NOTE:
If the dr= aft is adopted, the working group has change control over the draft and the = timing of its progression.  This means the document does not have to be= perfect as the working group can and will make changes.  Adopting the = draft means the working group thinks the topic is a good idea and the draft = is a good place to start the work.  

Thanks,
Chris, Joe, and = Sean

[0] https://datatracker.ietf.org/doc/draft-stebila-tls-hy= brid-design/

 

 

--B_3664446495_252976769-- --B_3664446496_1865451379 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADyHaxtc8GrYDIrgAAAAPIdjANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMyNjE4NDEwMVoXDTIyMDMy NTE4NDEwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzD7FJptOjLaaidxt9QIIH/dAblMrT ESMm4ggEBR0KqbmSkRY+x45ed8E2u9fJuFWKAgwU+vJo//kzavEpAAuyhe61Z+4noWIvV0sY WkUs+ffLh+29MxDs8Mt1++mDAC1+NyLCPN8QNPRJVu7ECRtmKu3DiAtuEKva3J7lZyVVNE+3 e9HQJlr/3alifN4sg/NxOFMTKMMEq15RgOhDyAudnNSs2IesRnoKTZq/Jykwbm0fg06ePSBR /k2JuYNW8/UZnU7d/Ez2n1NEtZkQw5QzWrC27ijf7FFQxM9yLToJneFVK+krQsfvtMbHGpnz Yo9keqc3Uxb13P4mpDbZiIBTAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUMzH1HGnW9jHVrCuy FAmJhhljwLcwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACztsHHc HX+FTwlhjHUUU+AcLyX3hgIdnTovNmPWVhVgzpN25AotcwODhCwuaLNoLsC0OHRISFUvkqHg 7aeZ9CiDOL4KwlNZgzGpDlqZ/AgMJ+JodWz0XqoNm4wYNs2rl7sEzLe70yPVyzTYlhECYnex UxE4hL334w/cx+Mb8vKn+/EQ9NFKVfCJ8X1dDkCA19EkZu2DbFF2oAM0kr6JX2dNx1rChTMZ iOSkGkKKpnVNFBMl/uw8qH8XrD+slPhLpTQg5t9l0pCtkJSMnrMovPvgwhlOP7yCLdPYYTwY IjwvUeqj1VAvid80L9vevRY1D6NDz/eWfoqCxXxPvtue//owggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADyHaxtc8GrYDIrgAAAAPIdjANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCUfXkSRle8wAPS8uIb+JhjZ/usBLwkCvjQ4e42 kNEmujAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMTMx ODQ4MTZaMA0GCSqGSIb3DQEBAQUABIIBAJTHx5OFyse1o4LW1N3BoFfcVWOuFjeOCmrl+nsK PML33iMAjMqLvPXnw+8WSYJwOMaO0mKaZhJrkfgU9cKDz0W8p9ptHFwNlWNvhPWL9PZrxfBS 6ptPIfAi5Zk1uy4SDUkntclFbR1z31O8jrxUrLQMj5djbW9Kiuf8NycrurS9szPOmDzJ18P5 +5sWZQLrRte5kgTncyCon1hrRROKB8jMA6clRehn7w23mBHeIGBJwM3FGxQ67Bfcbc0sOqDM LxPcfbymDiJ/vwMKJXHhUcu2fN06X4/cnGs9Tqz7hevmkGl38ebTq9DxVzrwekLOjC5kO9TZ ZKfoeMcO4aXZitM= --B_3664446496_1865451379-- From nobody Thu Feb 13 11:01:07 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B79D1201DE for ; Thu, 13 Feb 2020 11:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 tj3eWBAiEbvM for ; Thu, 13 Feb 2020 11:01:04 -0800 (PST) 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 9EE7A1201AA for ; Thu, 13 Feb 2020 11:01:04 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01DIvsGk009967; Thu, 13 Feb 2020 19:01:00 GMT 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-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=hUxdN+J0LzFp4sxbN/BAScUXUT/Ug83nAVdt6Npk2gw=; b=M3qsloH8h8Xo9/qwhztKolJALM3Gu8UWBFk0lIaukp2itO/GZoaoHjuBwEoOCdmNZVe7 iXSeDEaDd5sA6YAytFDNBYAtXIGh7bvSyAZYXqX1U4CITs0YngLMgPKoDiXcR8T8riNe m8/kuZfdE9pK2JWBCUqksBWZMSwWyPMRUiiXXp+OlHxA02VEhq68j7ZVoGKcqngJ+EX/ gJrCf6rLKfHdhqC8oUPsFzWusWokdHUJPsSbWiMx5uSOKZuiG+VJaPKDMMhiKLmwbECP KXBYG3nXx9VAdcu4BNzbQuAYqhnqsLPhJQBg5EEDZuxbpJAf5DFc3O8fKEvnbt7/pPXX Yw== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2y4587raah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Feb 2020 19:01:00 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01DIlQhM004323; Thu, 13 Feb 2020 14:00:59 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint6.akamai.com with ESMTP id 2y5bd6810x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 13 Feb 2020 14:00:59 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Feb 2020 14:00:58 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 13 Feb 2020 14:00:58 -0500 From: "Salz, Rich" To: Stephen Farrell , Joseph Salowey , "" Thread-Topic: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design Thread-Index: AQHV4pEOAdSjKLl4YUSBq52E21NJ+KgZyqaA//+wEQA= Date: Thu, 13 Feb 2020 19:00:57 +0000 Message-ID: <182336C5-9F86-4C80-99D8-155A8565ED9F@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.35] Content-Type: text/plain; charset="utf-8" Content-ID: <33B0D271DA946D42B88CA02145E763E9@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=782 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002130132 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-13_07:2020-02-12, 2020-02-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 phishscore=0 adultscore=0 impostorscore=0 mlxlogscore=750 clxscore=1011 priorityscore=1501 spamscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002130132 Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 19:01:06 -0000 PiAgICBJIHRoaW5rIHRoZSBkcmFmdCB3b3VsZCBiZSBvayB0byBhZG9wdCBpZiB3ZSBkb24ndCBm aW5pc2gNCiAgICBpdCB1bnRpbCB0aGUgb3V0Y29tZSBmcm9tIHRoZSBOSVNUIGNvbXBldGl0aW9u IGlzIGtub3duLg0KICAgIE90aGVyd2lzZSBJIHdvdWxkIGJlIGFnYWluc3QgYWRvcHRpb24uDQog IA0KSSB0aGluayBJIGFncmVlIHdpdGggdGhpcywgYnV0IGFtIG5vdCBzdXJlLiBDYW4gd2UgaGF2 ZSB0aGlzIG9uIHRoZSBhZ2VuZGEgZm9yIFZhbmNvdXZlcj8NCg0K From nobody Thu Feb 13 11:44:25 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26B81201CE for ; Thu, 13 Feb 2020 11:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QDvLtBneUHY for ; Thu, 13 Feb 2020 11:44:20 -0800 (PST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.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 63B941201AA for ; Thu, 13 Feb 2020 11:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581623058; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wuYROfYGbCKNUZUGBw6q2x4o0N4neklqJ/bwDS4RH5E=; b=Oi5nhgfl3DKFdHT4GxE5Y+DhEVWho1LWYn6IXu3PPoe7TTI5hfZL4d28wrkGO9GroYHD0I lcR3N3bFEexaWzq5S+p0Xg1g/h6zRnEMc4yZqI29boZkv+pmQD7ubbPZX6YZkdNQR1/jwz UHlbA0QyOQAu7kYLWdCwxQ9ss064I00= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-346-6VxHY-nEMwaOgtl97Qpi7A-1; Thu, 13 Feb 2020 14:44:16 -0500 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id D6A291800D6B for ; Thu, 13 Feb 2020 19:44:15 +0000 (UTC) Received: from localhost (unknown [10.43.21.98]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7AD2A62660 for ; Thu, 13 Feb 2020 19:44:15 +0000 (UTC) From: Hubert Kario To: Date: Thu, 13 Feb 2020 20:44:13 +0100 MIME-Version: 1.0 Message-ID: <131bef25-b25e-4719-9aff-f171959640ce@redhat.com> In-Reply-To: <4E5499C8-7461-4366-9F20-EF36EA407BD8@isara.com> References: <4E5499C8-7461-4366-9F20-EF36EA407BD8@isara.com> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: 6VxHY-nEMwaOgtl97Qpi7A-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] =?iso-8859-1?q?TLS_1=2E3_unsupported=5Fextension_vs_illega?= =?iso-8859-1?q?l=5Fparameter_clarification?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 19:44:23 -0000 On Wednesday, 12 February 2020 19:46:01 CET, Daniel Van Geest wrote: > Hi, > > I=E2=80=99m looking for some clarification on unsupported_extension vs=20 > illegal_parameter alerts in TLS 1.3. > > RFC 8446 says: > > If an implementation receives an extension > which it recognizes and which is not specified for the message in > which it appears, it MUST abort the handshake with an > "illegal_parameter" alert. > > and > > The client MUST check EncryptedExtensions for the > presence of any forbidden extensions and if any are found MUST abort > the handshake with an "illegal_parameter" alert. > > But also > > unsupported_extension: Sent by endpoints receiving any handshake > message containing an extension known to be prohibited for > inclusion in the given handshake message, or including any > extensions in a ServerHello or Certificate not first offered in > the corresponding ClientHello or CertificateRequest. > > These seem contradictory. An =E2=80=9Cunsupported_extension=E2=80=9D is = for=20 > =E2=80=9Can extension known to be prohibited for inclusion in the given= =20 > handshake message=E2=80=9D. > > But it seems that the first two statements quoted indicate that=20 > =E2=80=9Cillegal_parameter=E2=80=9D should be sent in this case. > > I=E2=80=99d expect =E2=80=9Cunsupported_extension=E2=80=9D would be more = fitting. Is=20 > an errata needed? it looks like the first part of unsupported_extension is completely=20 overriden in main text of the RFC, it's just the "allowed, but not an echo" that=20 should cause unsupported_extension but then section 6.2 is quite explicit that it's the main text that is of higher importance: Whenever an implementation encounters a fatal error condition, it SHOULD send an appropriate fatal alert and MUST close the connection without sending or receiving any additional data. In the rest of this specification, when the phrases "terminate the connection" and "abort the handshake" are used without a specific alert it means that the implementation SHOULD send the alert indicated by the descriptions below. The phrases "terminate the connection with an X alert" and "abort the handshake with an X alert" mean that the implementation MUST send alert X if it sends any alert. so while unfortunate, not really internally inconsistent --=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 From nobody Thu Feb 13 13:28:48 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB76120273 for ; Thu, 13 Feb 2020 13:28:47 -0800 (PST) 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=lowentropy.net header.b=WoKYSPvV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=suttnVmQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PylBjlZCHkws for ; Thu, 13 Feb 2020 13:28:46 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F32120236 for ; Thu, 13 Feb 2020 13:28:46 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 57C5B22089 for ; Thu, 13 Feb 2020 16:28:45 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 13 Feb 2020 16:28:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=C0JHcZe7JGbmCifDJCG8xdstw/60S0N xjVBUg89VLJA=; b=WoKYSPvVu9k8E/YdyO+K9XdxDH1xZv/DdAXz4YxC7x1WrBn vJyPKV8TJIv5NJ0S/eBZBJPoXSIgfj8+t3swTxBYePXCgbxPdoWJdL11c8KPUx+L lIPIs8mVXIpYDTlcTXve3nj8wOjWm+0/WN3V6OiLy9CDgw3vo3EkRcAO/e6LsbO0 SGA7PSS25ZD5e+Q7s0tcnOhvi+KGDA23sF4R2U8aYgvy2U27ycT/mq3s64qXSQ/8 T1dIIMIevl50HO1PIXO4znZo+pNdZeHD3suFdYSf6vVT043iw1NWMVCZ2+rQve3z TNYqnLdyPMvbibUhLiHbRUpMA445MRqw+defnPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=C0JHcZ e7JGbmCifDJCG8xdstw/60S0NxjVBUg89VLJA=; b=suttnVmQdr/b5IAcyWmcs4 GIApjGo6Oib+HndiVmsECBb520NUlksogZOH3A/ePLYudRUFgvywsfI6AlAMCcNm vPZg786ytxsv5UdqFTWDGVveFzgMwZcnUK2De5b5XVike4hFywdMs13yY0DJn6g5 2SnWp+hhAn8E5er2dMtYBjW9oDvbFAzb+B67V3gTF7etQ15fYsWqpH57GiRNTNvL yLeDuuT3KwZ+HW91M8lwdW7y3XwYvNJER4bHXBuuGrvs4WUfD+ulG4ZtInwblT6u kcus/vHGfRKvrNTGQyGSL7wQdqUlZkshxwDdMhDsdLwTA+LFakZtiUFesL7mfvlQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrieekgdduheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E356EE00A2; Thu, 13 Feb 2020 16:28:44 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <182336C5-9F86-4C80-99D8-155A8565ED9F@akamai.com> References: <182336C5-9F86-4C80-99D8-155A8565ED9F@akamai.com> Date: Fri, 14 Feb 2020 08:28:27 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 21:28:47 -0000 On Fri, Feb 14, 2020, at 06:00, Salz, Rich wrote: > > I think the draft would be ok to adopt if we don't finish > it until the outcome from the NIST competition is known. > Otherwise I would be against adoption. > > I think I agree with this, but am not sure. Can we have this on the > agenda for Vancouver? That's a good idea. Because I'm fairly sure that I disagree. This work might form the basis of experiments. If the competition result is known, we might instead want to start the process of defining key exchange with a single algorithm rather than concern ourselves with compositions. Having the document in place so that we can define experiments with a degree of surety with respect to their risks is best. In any case, we should adopt this work. From nobody Thu Feb 13 13:35:37 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A212112026E for ; Thu, 13 Feb 2020 13:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 LpgHhWSxJsan for ; Thu, 13 Feb 2020 13:35:34 -0800 (PST) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC22120236 for ; Thu, 13 Feb 2020 13:35:34 -0800 (PST) Received: by mail-vk1-xa33.google.com with SMTP id b2so2020655vkk.4 for ; Thu, 13 Feb 2020 13:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+Wl8T/5Ht6Uw2smTOjwD0LADeZJjpT+iOPjmZcpQhXM=; b=aAMmn2fPNFo/piesID+pffVyi4hXaw50x3MYnXUMDgkAyODSsXK+bpmGyAxVeiNiW2 DLLUzIeGVV9wLdbmkLpXh6fsGD0gkjUBNROC5IeGKW9CFJ7K9eJTLvRWs7t+IC7wqQug CIZCaN1rz5SuyweN3Eh6XXrNX4YQm+bJgdOXI= 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=+Wl8T/5Ht6Uw2smTOjwD0LADeZJjpT+iOPjmZcpQhXM=; b=bmmzrjpsYCxps1KB7tPEzCxfSYtoMG87Oymddw+cO8RwrtTyCF/JiiKp83eHWudB0V ZUF6A2cG8Ixbrqsem698AZWkvyBSsMVj+q0+cSR+s/JCwWa4W7iuMEXJhPH3mdaWXvGW IQ6/LWEbQgX9ZR9zKq5c/v9+SjaE57EeRgVKQo9JpBkk/InLgTulY+DogIyN8kT4U1kI i/3HwCewN4mp1DrvgZWolAsZd/BIBRXc4qJvrGR7NOHpjfAFKag+enKbncyeci16Tiui bTIwwoneOC+ia5vR1zyi+a5VOVWRyIP+5CsQTg05v7An4rSt/lzHgAZbvnGqhJcL0os7 sLLw== X-Gm-Message-State: APjAAAWVYB9FHNXdewlNij91b66KYPs632rUat6Q1nSoJ9JcEcexKNvh MmVu91EfEt8r3p1jBy4VHNkErG05asHrukczuqyprw== X-Google-Smtp-Source: APXvYqwkvlbKVXVZWIxdrAjSFgSa0H4Exz9lWYmGguYEXbShrlexCqxzfXuJNcmqtGJlcekqmQm6mxq2C2nsWRL5tns= X-Received: by 2002:a1f:a9d0:: with SMTP id s199mr61889vke.40.1581629733446; Thu, 13 Feb 2020 13:35:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Thu, 13 Feb 2020 13:34:15 -0800 Message-ID: To: Justice Parham Cc: "" Content-Type: multipart/alternative; boundary="0000000000006dd4e4059e7bde63" Archived-At: Subject: Re: [TLS] ESNI Android Implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 21:35:37 -0000 --0000000000006dd4e4059e7bde63 Content-Type: text/plain; charset="UTF-8" Hi Justice, Thanks for reaching out and welcome. At this point, another implementation of draft-02 wouldn't hurt, but it also likely won't contribute much to the development process for this document. We've learned what we can from -02 and the upcoming draft version will likely be radically different from the existing published version, so you likely won't be able to re-use much code. If it's possible for your schedule I recommend waiting or exploring questions like how applications with different TLS stacks can get access to ESNI records if they're fetched system-wide. Nick On Tue, Jan 21, 2020 at 12:30 AM Justice Parham wrote: > Hello tlsWG, > > First I would like to introduce myself to you. My name is Justice Parham > (github mrsylerpowers) a current Senior Undergraduate Student at North > Carolina A&T State University. As my senior project I decided to create a > android system wide implementation of the ESNI Draft. I am planning on > implementing draft-ietf-tls-esni-02 because this is the version that > cloudflare currently has published on their servers. I am planning on > upgrading to newer versions of ESNI as more implementations come out on the > server side > > My question to everyone is if creating this implementation will hurt or > help this document? I would really like for this to be a standard that is > used everywhere in every browser and in every computer. But I understand draft-ietf-tls-sni-encryption > 3.4 > 's > importance about not sticking out. Is there a time where vendors all plan > to implement or do you think this is a perfect time to create this? > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000006dd4e4059e7bde63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justice,

Thanks for=C2=A0reaching ou= t and welcome. At this point, another implementation of draft-02 wouldn'= ;t hurt, but it also likely won't contribute much to the development pr= ocess for this document. We've learned what we can from -02 and the upc= oming draft version will likely be radically different from the existing pu= blished=C2=A0version, so you likely won't be able to re-use much code. = If it's possible for your schedule I recommend waiting or exploring que= stions like how applications with different TLS stacks can get access to ES= NI records if they're fetched system-wide.

Nic= k

On Tue, Jan 21, 2020 at 12:30 AM Justice Parham <justking100@gmail.com> wrote:
Hello tlsWG,

First I w= ould like to introduce myself to you. My name is Justice Parham (github mrs= ylerpowers) a current Senior Undergraduate Student at North Carolina A&= T State University. As my senior=C2=A0project I decided to create a android= system wide implementation of the ESNI Draft. I am planning on implementin= g=C2=A0draft-ietf-tls-esni-02 because=C2=A0this is the version that cloudfl= are currently has published on their servers. I am planning on upgrading to ne= wer versions of ESNI as more implementations=C2=A0come out on the server si= de

My question to everyone is if creating thi= s implementation=C2=A0will hurt or help this document? I would really like = for this to be a standard that is used everywhere in every browser and in e= very computer. But I understand=C2=A0draft-ietf= -tls-sni-encryption 3.4's importance about not sticking out. Is the= re a time where vendors all plan to implement or do you think this is a per= fect time to create this?
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000006dd4e4059e7bde63-- From nobody Thu Feb 13 13:40:24 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7386512080E for ; Thu, 13 Feb 2020 13:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 d15XFfA-NRtd for ; Thu, 13 Feb 2020 13:40:15 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569C9120821 for ; Thu, 13 Feb 2020 13:40:15 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id k188so4609060vsc.8 for ; Thu, 13 Feb 2020 13:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AlT4Fedk5tttHrgXorNWxAnrs6p3vhlPbrLOabKzwcA=; b=VTi7ej6lyMGV5bjwNQvxIT1GPIUGEBIuGsyMjuh8816I5uLnY7EqCPwFcHXO1jppgh s4mkW9VEShM1H5bDPngRHBaVnmG62wLWeSEBSTejTIqrtKHWoHu+1XrxpO/hw6QbpMRZ pmswXIgZyRFqbCXWU4CLGQ2UAjukzxg0HHAAk= 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=AlT4Fedk5tttHrgXorNWxAnrs6p3vhlPbrLOabKzwcA=; b=DT2hCLWpLGVaLQokQwjQBw7dAeDk5lsUYZdZ+oNgJld6UAl2P8BF8MjXxAtCE8Prhc t2QYC7kol9MfiICwUwUPJXm+L7/RfJVBUwYaC9IGiLijl2uI9MNqKRPODFevd8zq6Wpk 0bNrtIi/QbJwII+pNoCI3RsKpwBAE3coREpwpOHsXi5GRD7JFRBKnMq9GjH+QZK1CwGE bOiaUlVsdEFKvmhOrEG+5FxcTyfpOm8muu2d72hfcFl4mSQ8vJ/pXxp9yEjan7QWxW+P jCq+X2drxF9XZW6ZJnbG/2r2ZMFZxCOfb+BiT0kaKb0yItEht8RcK3hzRGDOZ+xhCxbA 1Giw== X-Gm-Message-State: APjAAAXVR333bZVssW9P4ctSYtmCUZSuRr7xy58tkU2zplQxuGzkeRy1 WL+RI4Wwy4Hl3kMUsdXOAPTulkXDN7na35kIN68zAQd81eM= X-Google-Smtp-Source: APXvYqy4ZWXHFisIsulTwud/La8uEzCgn6QLxTpVLIYH0Z1tmivwTLuxmXWJlea+AhaRLi6DKi9mlk87hrMrhau0ql8= X-Received: by 2002:a05:6102:190:: with SMTP id r16mr3324607vsq.215.1581630014328; Thu, 13 Feb 2020 13:40:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Thu, 13 Feb 2020 13:38:56 -0800 Message-ID: To: Joseph Salowey Cc: "" Content-Type: multipart/alternative; boundary="0000000000002bafd8059e7beffe" Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 21:40:22 -0000 --0000000000002bafd8059e7beffe Content-Type: text/plain; charset="UTF-8" I'm in favor of adopting this work. Nick On Thu, Feb 13, 2020 at 9:13 AM Joseph Salowey wrote: > The authors of "Hybrid Key Exchange" have asked for adoption of their > draft as a WG item. Please state whether you support adoption of this > draft as a WG item by posting a message to the TLS list by 2359 UTC 28 > February 2020. Please include any additional information that is helpful > in understanding your position. > > NOTE: > If the draft is adopted, the working group has change control over the > draft and the timing of its progression. This means the document does not > have to be perfect as the working group can and will make changes. > Adopting the draft means the working group thinks the topic is a good idea > and the draft is a good place to start the work. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000002bafd8059e7beffe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in favor of adopting this work.

Nick

On Thu, Feb 13, 2020 at 9:13 AM Joseph Salowey <joe@salowey.net> wrote:
The authors of "Hybrid Key Exchange= " have asked for adoption of their draft as a WG item.=C2=A0 Please st= ate whether you support adoption of this draft as a WG item by posting a me= ssage to the TLS list by 2359 UTC 28 February 2020.=C2=A0 Please include an= y additional information that is helpful in understanding your position.
NOTE:
If the draft is adopted, the working group has change control= over the draft and the timing of its progression.=C2=A0 This means the doc= ument does not have to be perfect as the working group can and will make ch= anges.=C2=A0 Adopting the draft means the working group thinks the topic is= a good idea and the draft is a good place to start the work. =C2=A0
Thanks,
Chris, Joe, and Sean

[0]=C2=A0https://datatra= cker.ietf.org/doc/draft-stebila-tls-hybrid-design/


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000002bafd8059e7beffe-- From nobody Thu Feb 13 14:28:51 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E2F12026E for ; Thu, 13 Feb 2020 14:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 xrZUEr39AuFu for ; Thu, 13 Feb 2020 14:28:47 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60F7120096 for ; Thu, 13 Feb 2020 14:28:47 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id n21so8358484ioo.10 for ; Thu, 13 Feb 2020 14:28:47 -0800 (PST) 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=gdvnjyyKws1kXGh7yzXmZqLxxPcnkhtcxa6/gw3PZI8=; b=UQ3zwHmBN2W2ZWqxHAbUVRQCjhz9fBsVpla+uqjnujKTduA/JmHY15SI7CgRwCuX0J TbjBEeYdFkYCmCS5zjQevaiusAvFXX9GLH9ZS/8x1svBstZCI8z8V06Ez158gGTA1vED OLKAvhKp0RjDhVCTX792+aU1hqrJKGlJvajYDjuWRspiXdNnEpMG//X/1ZJ5jhVlJpfE YLO1T2swRzmzUCrcVqWKxgkQ0Euuj/Dhh6X7T7HP/TaBmA6k/fx0MBesjgqJYE+61FUl LYArt3yYDHYELJTdoCugeYDaAcH114MDEjs9lADaCzXeVHRDkrUdpccOr8By4RmwIBpK YkEg== 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=gdvnjyyKws1kXGh7yzXmZqLxxPcnkhtcxa6/gw3PZI8=; b=VREB47fh1YOis67GIFp7gv07W1InWXmiX8jGlHYoIHxwffBGvnhgsWb5FnKZX/7y7s Im/JJO77n5K6s89u15OKPdj35crRQIewm9gC6p3CiCyIL4F5B/F+8tQgxC7v4gpW7TbV 3PvyIvqzNS24Lv3Zgztppr44EnQVL/rRz+OCl6ctqVfw0f26RErfHl4ENZkHfuM+giCf V1WfnP+PO4GPGOjFyJulDVR39yCHLrL/95N2Mw3HcrgApaJQY7X8AlMUkEdFd8kUkEt/ 4MphalbWSxr7dtJsQqaRO/w5w1YPY4O0vptw8wkFav264p7ZlMfGV8chDuOTeY7PhUhh PCIQ== X-Gm-Message-State: APjAAAVjs7cqp2E55eWSBnfxa5yIk250Et7EDJ6userjBmKLUq14i4Dd lO4NeCXuWflKW888BCt+LQSuy7AQpCHn/XqdiGgAvWsX X-Google-Smtp-Source: APXvYqy1vL9p1D3qt2qwhzr7WlQu4ZRDtw37774inRhNWuBmbfjkbm3QSC06nAnSb8nh/dO9ZjkYjdHJ8lpQqD1GPEI= X-Received: by 2002:a6b:bb45:: with SMTP id l66mr24390885iof.73.1581632927061; Thu, 13 Feb 2020 14:28:47 -0800 (PST) MIME-Version: 1.0 References: <64255C99-9C23-4F8E-A2F0-DA7B43572E2C@stebila.ca> In-Reply-To: <64255C99-9C23-4F8E-A2F0-DA7B43572E2C@stebila.ca> From: Rob Sayre Date: Thu, 13 Feb 2020 14:28:32 -0800 Message-ID: To: Douglas Stebila Cc: Shay Gueron , "" Content-Type: multipart/alternative; boundary="000000000000c85f59059e7c9cff" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 22:28:49 -0000 --000000000000c85f59059e7c9cff Content-Type: text/plain; charset="UTF-8" On Thu, Feb 13, 2020 at 3:48 AM Douglas Stebila wrote: > On Feb 12, 2020, at 11:24 PM, Rob Sayre wrote: > > > > Would it be ok to add a rationale to the "Goals" section around backward > compatibility? I'm not sure how the compatibility points will interact with > downgrade attacks. > > For now I don't think we're envisioning anything different on downgrade > compared to current DH group negotiation. For example, a client that > prefers curve25519 but also is willing to use nistp256 should be able to > talk to a server that only supports nistp256. > This idea is what my question concerns. I'm not sure there should be a negotiation of that sort, but the WG can sort that out. thanks, Rob --000000000000c85f59059e7c9cff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 13, 2020 at 3:48 AM Dougl= as Stebila <douglas@stebila.ca= > wrote:
On F= eb 12, 2020, at 11:24 PM, Rob Sayre <sayrer@gmail.com> wrote:
>
> Would it be ok to add a rationale to the "Goals" section aro= und backward compatibility? I'm not sure how the compatibility points w= ill interact with downgrade attacks.

For now I don't think we're envisioning anything different on downg= rade compared to current DH group negotiation.=C2=A0 For example, a client = that prefers curve25519 but also is willing to use nistp256 should be able = to talk to a server that only supports nistp256.=C2=A0

This idea is what my question concerns. I'm not sure th= ere should be a negotiation of that sort, but the WG can sort that out.

thanks,
Rob

--000000000000c85f59059e7c9cff-- From nobody Thu Feb 13 15:45:55 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0228120026 for ; Thu, 13 Feb 2020 15:45:53 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gYqeKwkCAa2 for ; Thu, 13 Feb 2020 15:45:52 -0800 (PST) Received: from mr85p00im-zteg06021601.me.com (mr85p00im-zteg06021601.me.com [17.58.23.187]) (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 3D211120020 for ; Thu, 13 Feb 2020 15:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1581637551; bh=oq3+7dQ0lUkD9krDkXywRmm8Cns0cFG2F4X5FuLKvsI=; h=From:Content-Type:Subject:Date:To:Message-Id; b=JHVg8qeOMdt6WRG6RfiTV7HxXG09F6sop6htO51Atkm0ARTKWhzvLy+uj5Xsgbrut +8gGKNuvj2JgiQ0+7C+hPSltQo9Iyek25AF8XTtvvI6nhlCmlejkAlX+INQzHQlHfv AVPdl+DgGgE9egLEXlGk/q6hpXgk81EWdMLF01wJcWu7IABGMBfUJY47PSkDuEKa/3 yae6AfkVjSzD8z3CZ5ixwQ+9urDNmPArIi4uYjlSyb4CA9yVaSjRSOkuEnZu0Ygx6v mjQcfhKf2IUFoJn3xQtUFQ+gsZfqkLGXBBPKO4FvCWwDQcIbGvXXyvmR2+VYKHQgwU JLed9eaj2Wm7w== Received: from [17.230.167.54] (unknown [17.230.167.54]) by mr85p00im-zteg06021601.me.com (Postfix) with ESMTPSA id A85B44002AC for ; Thu, 13 Feb 2020 23:45:51 +0000 (UTC) From: Carrick Bartle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.3\)) Date: Thu, 13 Feb 2020 15:45:50 -0800 References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> To: tls@ietf.org In-Reply-To: <158093501262.12877.10966121264461280401@ietfa.amsl.com> Message-Id: <45495A4A-F79D-49B3-9887-3BFF00C00589@icloud.com> X-Mailer: Apple Mail (2.3608.80.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-13_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2002130172 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 23:45:54 -0000 TL;DR: I find it difficult to understand the second-to-last paragraph of = the Introduction, so I took a stab at revising it. Let me know if I = should put it in a pull request. This is the paragraph I'm referring to: "These dependencies cause problems in practice. Server operators often = want to create short-lived certificates for servers in low- trust zones = such as Content Delivery Network (CDNs) or remote data centers. This = allows server operators to limit the exposure of keys in cases that they = do not realize a compromise has occurred. The risk inherent in = cross-organizational transactions makes it operationally infeasible to = rely on an external CA for such short- lived credentials. In Online = Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate = Status extension type ocsp [RFC8446], if an operator chooses to talk = frequently to the CA to obtain stapled responses, then failure to fetch = an OCSP stapled response results only in degraded performance. On the = other hand, failure to fetch a potentially large number of short lived = certificates would result in the service not being available, which = creates greater operational risk." Here are my issues with it: - I think OCSP is being brought up here as an example of a way that = dependence on a CA can go wrong, but that isn't really made explicit. - I'm not sure what "only" means in "only in degraded performance." Is = it "the worst that can happen is just degraded performance" or "it can = result only in degraded performance, as opposed to better performance"? = At first I thought it was the latter, but after reading the subsequent = sentence, I realized it was probably the former. - The use of "On the other hand" sounds like the rest of the sentence is = going to describe a way that failure to receive something from a CA = resulted in better performance, which obviously would be silly. Taking all these points together, here's my suggestion for a revision to = make what I think the thrust of the paragraph is more clear: "These dependencies cause problems in practice. Server operators often = want to create short-lived certificates for servers in low-trust zones = such as Content Delivery Network (CDNs) or remote data centers. This = allows server operators to limit the exposure of keys in cases where = they do not realize a compromise has occurred. But the risk inherent in = cross-organizational transactions makes it operationally infeasible to = rely on an external CA for such short-lived credentials. For instance, = in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., = using the Certificate Status extension type ocsp [RFC8446]), a CA may = fail to deliver OCSP stapled response. While this will result in = degraded performance, the ramifications of failing to deliver = short-lived certificates is even worse: the service that depends on = those certificates would go down entirely. Thus, ensuring independence = from CAs for short-lived certificates is critical to the uptime of a = service." Carrick > On Feb 5, 2020, at 12:36 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : Delegated Credentials for TLS > Authors : Richard Barnes > Subodh Iyengar > Nick Sullivan > Eric Rescorla > Filename : draft-ietf-tls-subcerts-06.txt > Pages : 15 > Date : 2020-02-05 >=20 > Abstract: > The organizational separation between the operator of a TLS endpoint > and the certification authority can create limitations. For = example, > the lifetime of certificates, how they may be used, and the > algorithms they support are ultimately determined by the > certification authority. This document describes a mechanism by > which operators may delegate their own credentials for use in TLS, > without breaking compatibility with peers that do not support this > specification. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-subcerts-06 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-06 >=20 >=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.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Feb 13 16:33:15 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B046212003E for ; Thu, 13 Feb 2020 16:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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_LOW=-0.7, SPF_HELO_NONE=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=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdAvAw87kHYB for ; Thu, 13 Feb 2020 16:33:13 -0800 (PST) Received: from mr85p00im-hyfv06011301.me.com (mr85p00im-hyfv06011301.me.com [17.58.23.184]) (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 37419120033 for ; Thu, 13 Feb 2020 16:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1581640392; bh=68BvygZvSp63aPTXW+DJof+HJtileeuMenttndqpBpY=; h=Content-Type:Subject:From:Date:Message-Id:To; b=eBjkCGfM5l0eGYKSde99GeoRXulh5AHiN0bbrN49/ytpUo1AG7CeBiEkeAk7/KeWP rEfnd4e1mBREEDP0nLrx/BF2dKAuLEMgnxcTvN6QQ/RYXJ8il7AByTGP6Q1b5bMbRr xBLuMXB9AH4CI/JItpSTxbScfV2qizF7YyZFcTsSIeL6nzywQvf24970VMQhoNUIZ+ n1hhUFOkMTKk9XahGyCQ+2sWw/9q5m6Ml5rB3bBCDwWttDgAwRC4tmY+/1OOfPhkNY KA3WEMJK9kErIyLLFrhP6IPM6wQ3KQB/8fivfjIkqqLvcJwoDekrsmORrKX85IHqBD sGKGda06Ws+rg== Received: from [17.230.167.54] (unknown [17.230.167.54]) by mr85p00im-hyfv06011301.me.com (Postfix) with ESMTPSA id 84B9F58051A; Fri, 14 Feb 2020 00:33:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.3\)) From: Carrick Bartle In-Reply-To: Date: Thu, 13 Feb 2020 16:33:12 -0800 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joseph Salowey X-Mailer: Apple Mail (2.3608.80.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-13_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2002140001 Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 00:33:15 -0000 I also support adoption of this draft. The concerns raised in the other = thread on this topic ([TLS] Requesting working group adoption of = draft-stebila-tls-hybrid-design) are irrelevant within the context of = adopting an informational draft, as it would be a "timely publication" = of "general information [for] the Internet community." > On Feb 13, 2020, at 9:12 AM, Joseph Salowey wrote: >=20 > The authors of "Hybrid Key Exchange" have asked for adoption of their = draft as a WG item. Please state whether you support adoption of this = draft as a WG item by posting a message to the TLS list by 2359 UTC 28 = February 2020. Please include any additional information that is = helpful in understanding your position. >=20 > NOTE: > If the draft is adopted, the working group has change control over the = draft and the timing of its progression. This means the document does = not have to be perfect as the working group can and will make changes. = Adopting the draft means the working group thinks the topic is a good = idea and the draft is a good place to start the work. =20 >=20 > Thanks, > Chris, Joe, and Sean >=20 > [0] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Feb 13 17:36:03 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6693C12001A; Thu, 13 Feb 2020 17:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 g2ebDb5TTfls; Thu, 13 Feb 2020 17:35:54 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3251E120019; Thu, 13 Feb 2020 17:35:54 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id x123so5286629vsc.2; Thu, 13 Feb 2020 17:35:54 -0800 (PST) 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=cgd3ywN5y2zc+28Pgg4FSfboXBs9VLjehiGQXv70F0A=; b=gyJtEYvG3mEA/RG528Xzpv0mM+S8Sh8aqEsEOumVVFQGhWK5DW3KjGV1RyoKNrdcqU ROXqJ6QzhKuFUWdPmySOEARDK69YaeEIPUvhD8azG0iMryGRC5Oq+3O5iE+SPtwE+ePC bZb/Z2GpbsZa6gk3DtmLlumb3+HS69jnffYhRqfWdTOs+kVRCwSkOWv0t5GpnBe8dgOq RCTzLogk6/yFyr6yeYV2mdFSapqoa0Ad/52d0B6kz2Mjo2r5TqXIyySEj3jJDX9Q24PG ECwGA6BaOQKfq7xZkfFiBKiXm9UBQ8ockNxjt7m5MG8W/PI9qDuSNq/rh6l6wV3zZfzj 4gzw== 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=cgd3ywN5y2zc+28Pgg4FSfboXBs9VLjehiGQXv70F0A=; b=bj8OhX6i7blVgpZMWjVDPLNQY4FYJG2iCD+U2i+hlgnex7ir/Tm+ZrJxd5WayRWAbl 8ENF99sOns1DToW42veaNvzunpzX5Fkp2Dxtujn8w5+/QZhqWfy1DxP6+7DUKppzG5Sm XkrQkSTazyufxNH1B27Z55iiQ0xCj090eK+mq+bfz0gXh2D9BCwypj+sji3CMCy1bKyX 6XYu9/EIzI5N4+mNWpqKHOF0UaIOzokOaBqDh8IIOIg9MWFtiw9eEgPyMj+HYqAEz3TM QXqNWfzJdCWSQf7pqr0TEyXtGuUqDikcmHcl1fwx6ttQwpDPjRvK9txatrzc7iPMupOJ sQwA== X-Gm-Message-State: APjAAAW1ZKKuSY9Ks/QBrcapcZScA6i0PjCVtRbP+IH5Aei+k1GdP9LK NK426SVvk+XuuRzlv6cIL1NBBQoLjBzYbduXWURAUmdcoMs= X-Google-Smtp-Source: APXvYqwSh6KwEne385dLstsDKm2JZDsIHM2m+mspqOT+BE5AUSmAnPUuuTF2s0QYbZ9+vRLaGFNGLk4/UomCzApQ0mY= X-Received: by 2002:a67:b309:: with SMTP id a9mr159690vsm.97.1581644153135; Thu, 13 Feb 2020 17:35:53 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 13 Feb 2020 20:35:42 -0500 Message-ID: To: saag , tls , IPsecME WG Content-Type: multipart/alternative; boundary="000000000000e8ab79059e7f395e" Archived-At: Subject: [TLS] Netdev 0x14 co-located with IETF107 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 01:35:57 -0000 --000000000000e8ab79059e7f395e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, This is just to let you know that Netdev 0x14 is back co-locating with IETF 107 in Vancouver. There are several security related talks that may be of interest= . Note: Early bird registration is still open until 17th and that many other talks, sessions, workshops are also happening https://netdevconf.info/0x14/accepted-sessions.html 1) Performance study of kernel based TLS handshakes https://netdevconf.info/0x14/session.html?talk-performance-study-of-kernel-= TLS-handshakes 2) TLS performance characterization on modern x86 CPUs https://netdevconf.info/0x14/session.html?talk-TLS-performance-characteriza= tion-on-modern-x86-CPUs 3) Kernel based TLS Hardware offload https://netdevconf.info/0x14/session.html?talk-kTLS-HW-offload-implementati= on-and-performance-gains 4) Addressing DDoS: Issuing SYN cookies in XDP https://netdevconf.info/0x14/session.html?talk-issuing-SYN-cookies-in-XDP 5) Security and Control of SR-IOV: What=E2=80=99s Our Responsibility if th= e Kernel is Bypassed? https://netdevconf.info/0x14/session.html?talk-security-and-control-of-SR-I= OV Yours, Daniel --000000000000e8ab79059e7f395e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

This is just to le= t you know that Netdev 0x14 is back co-locating with IETF 107 in
V= ancouver. There are several security related talks that may be of interest.=

Note: Early bird registration is still open until 17th and tha= t many other talks, sessions, workshops are also happening=C2=A0
https://netde= vconf.info/0x14/accepted-sessions.html=C2=A0=C2=A0

1) Performanc= e study of kernel based TLS handshakes
https://netdevconf.info/0x14/session.html?ta= lk-performance-study-of-kernel-TLS-handshakes

2) TLS performance= characterization on modern x86 CPUs
https://netdevconf.info/0x14/session.= html?talk-TLS-performance-characterization-on-modern-x86-CPUs

3)= Kernel based TLS Hardware offload
https://netdevconf.info/0x14/session.h= tml?talk-kTLS-HW-offload-implementation-and-performance-gains

4)= Addressing DDoS: Issuing SYN cookies in XDP
https://netdevconf.info/0x14/session.html?talk-issuing= -SYN-cookies-in-XDP

5)=C2=A0 Security and Control of SR-IOV: Wha= t=E2=80=99s Our Responsibility if the
Kernel is Bypassed?
https://netdevconf.info/0x14/sessi= on.html?talk-security-and-control-of-SR-IOV

Your= s,=C2=A0
Daniel

--000000000000e8ab79059e7f395e-- From nobody Thu Feb 13 23:02:18 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DD6120044 for ; Thu, 13 Feb 2020 23:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 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, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, 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 0mPbPIEi-XEI for ; Thu, 13 Feb 2020 23:02:15 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D220120047 for ; Thu, 13 Feb 2020 23:02:15 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id p17so9386412wma.1 for ; Thu, 13 Feb 2020 23:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=jQd78NrmY1e6WVEeZYUMczblfAr6AqNa4C5oTG+UFc0=; b=kTtP5ctYHigRkuChmqrGmACOfADIb0uJW/jGoa7QKWz7gQXsE1+O2tmo8SVNdW7172 s0Ntq19A0SRhQ0bW6DzIyaLZ6Noc34+dJ0dCss5vt5yb7ihPYKmbU3nDpX/z2RaLMFo6 1p+asVqew9wDLWYRFu6T92xSy8dPitUMBEaJ2yfD+LMsGyNHutIACtQtw+zHUY9wjP04 heonJxBasq8LIcVqguc6spOZrxa2x8VPMqCesOYuZd67mJLPM/cpIyiA2AX+f/3AcFiM 3C/DjJ/N84SBEu/FzAiTHSfFcQ9CjHVzxm9xuXiIBM7//V+V6K3EJOqid7nDtctHg1Pi qRgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=jQd78NrmY1e6WVEeZYUMczblfAr6AqNa4C5oTG+UFc0=; b=q9hBEhK2EEzjPuDhVzK999R5mafONs3KplIVVPg2CP3WEmG4VGFaaBv338BtGALW+x E/iJCtzAYxatwjI9XXK/I10c14tqop+mqEL86txnz4a7x+J6DsDj5p+0ufM0FAnmAM3i zflPirVJl0ORHeLRSSIo9zUmCyifqFp4UKWkzFe9q524ci+UH4YbB/P0AnLkjVfRTnbD 0boD0yE8+/hUOMAlWne33RXziGQGsihbaKXkX1Twxm7f42U4IU9AEeap2p3zXJls6SMx jKYGJgBgNY8PYNrUYMi8uEFoK2yC29ogeuxQyFqjwzB/rpsob/4TiwEEY9tDIURp0Baw O8Pg== X-Gm-Message-State: APjAAAWlW43gpI+lj1MyJYg41K/SGQh4PtcnebRyVqcLfoPD+D/owSE3 SNS2b5rM5v+guM723eH1E2Q= X-Google-Smtp-Source: APXvYqyTJ1x3ZxM4A8MfrhZIZZCQtgk4xggrgBCDvRcXX6MGIXCE/Q8Pi6PyxQTgbrebZ/WFckS/gA== X-Received: by 2002:a05:600c:22d3:: with SMTP id 19mr2878076wmg.92.1581663733926; Thu, 13 Feb 2020 23:02:13 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g15sm5621420wro.65.2020.02.13.23.02.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Feb 2020 23:02:13 -0800 (PST) From: "Valery Smyslov" To: "'Joseph Salowey'" , References: In-Reply-To: Date: Fri, 14 Feb 2020 10:02:08 +0300 Message-ID: <01dc01d5e304$ad2316f0$076944d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DD_01D5E31D.D2704EF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGDnA+6nXRxfhq1OwWpnQ6O3uUTHai+0OcQ Content-Language: ru Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 07:02:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01DD_01D5E31D.D2704EF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I support adoption of this document. =20 Regards, Valery Smyslov. =20 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey Sent: Thursday, February 13, 2020 8:13 PM To: Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design =20 The authors of "Hybrid Key Exchange" have asked for adoption of their = draft as a WG item. Please state whether you support adoption of this = draft as a WG item by posting a message to the TLS list by 2359 UTC 28 = February 2020. Please include any additional information that is = helpful in understanding your position. NOTE: If the draft is adopted, the working group has change control over the = draft and the timing of its progression. This means the document does = not have to be perfect as the working group can and will make changes. = Adopting the draft means the working group thinks the topic is a good = idea and the draft is a good place to start the work. =20 Thanks, Chris, Joe, and Sean [0] = https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ =20 =20 ------=_NextPart_000_01DD_01D5E31D.D2704EF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I support adoption of this document.

 

Regards,

Valery Smyslov.

 

From:= TLS = [mailto:tls-bounces@ietf.org] On Behalf Of Joseph = Salowey
Sent: Thursday, February 13, 2020 8:13 = PM
To: <tls@ietf.org>
Subject: [TLS] Call for = Adoption: = draft-stebila-tls-hybrid-design

 

The authors of "Hybrid = Key Exchange" have asked for adoption of their draft as a WG = item.  Please state whether you support adoption of this draft as a = WG item by posting a message to the TLS list by 2359 UTC 28 February = 2020.  Please include any additional information that is helpful in = understanding your position.

NOTE:
If the draft is adopted, = the working group has change control over the draft and the timing of = its progression.  This means the document does not have to be = perfect as the working group can and will make changes.  Adopting = the draft means the working group thinks the topic is a good idea and = the draft is a good place to start the work. =  

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/d= oc/draft-stebila-tls-hybrid-design/

 

 

------=_NextPart_000_01DD_01D5E31D.D2704EF0-- From nobody Fri Feb 14 02:40:02 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DC31202A0 for ; Fri, 14 Feb 2020 02:39:59 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 G7bE7nMRCENc for ; Fri, 14 Feb 2020 02:39:56 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606151207FD for ; Fri, 14 Feb 2020 02:39:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EE435BEB3; Fri, 14 Feb 2020 10:39:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnVnrVHDEFxB; Fri, 14 Feb 2020 10:39:51 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 925FCBE83; Fri, 14 Feb 2020 10:39:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1581676791; bh=mim9zKaKAgXEGdVvnK79FZCLLIXN4CurI6pgF2pYDjQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JrA6Q78blTy2Gx1xM85LK621NMLHLkihRPgpILJtvMfYc/sC7nVOnpsUFuzVTcTZy Dmsw9piiA02NqTDRStyB3nH6gwLanXXbA0L1ti7cLkvwrndNHofieivshIoZJmgi5k nI/KSG7aD59AJpZ2WF8S+sx9gz/GUpqmq8w4kDOw= To: Nick Sullivan , Justice Parham Cc: "" References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <269ad943-dd98-b6de-a0c2-1565e4a1c0fd@cs.tcd.ie> Date: Fri, 14 Feb 2020 10:39:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5ZB0ruLRJtWjEvOeX9spnWFPHmq27AJJt" Archived-At: Subject: Re: [TLS] ESNI Android Implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 10:40:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5ZB0ruLRJtWjEvOeX9spnWFPHmq27AJJt Content-Type: multipart/mixed; boundary="ugjRPLrLQ5T1b0dWTvGJP0akt6CcYpQR4"; protected-headers="v1" From: Stephen Farrell To: Nick Sullivan , Justice Parham Cc: "" Message-ID: <269ad943-dd98-b6de-a0c2-1565e4a1c0fd@cs.tcd.ie> Subject: Re: [TLS] ESNI Android Implementation References: In-Reply-To: --ugjRPLrLQ5T1b0dWTvGJP0akt6CcYpQR4 Content-Type: multipart/mixed; boundary="------------926D93F7DD32B7D1008FE5CB" Content-Language: en-US This is a multi-part message in MIME format. --------------926D93F7DD32B7D1008FE5CB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry, I had meant to reply to this but forgot... On 13/02/2020 21:34, Nick Sullivan wrote: > Hi Justice, >=20 > Thanks for reaching out and welcome. At this point, another implementat= ion > of draft-02 wouldn't hurt, but it also likely won't contribute much to = the > development process for this document. We've learned what we can from -= 02 > and the upcoming draft version will likely be radically different from = the > existing published version, so you likely won't be able to re-use much > code. If it's possible for your schedule I recommend waiting or explori= ng > questions like how applications with different TLS stacks can get acces= s to > ESNI records if they're fetched system-wide. I agree with Nick. If you did want to play with draft-02 code on android, then you could see if my fork of openssl [1] works. It has support for drafts -02 to -04. There is a CI setup that builds it for android but it hasn't really been tested ever. Happy to help if that was of interest. Cheers, S. [1] https://github.com/sftcd/openssl/ >=20 > Nick >=20 > On Tue, Jan 21, 2020 at 12:30 AM Justice Parham = > wrote: >=20 >> Hello tlsWG, >> >> First I would like to introduce myself to you. My name is Justice Parh= am >> (github mrsylerpowers) a current Senior Undergraduate Student at North= >> Carolina A&T State University. As my senior project I decided to creat= e a >> android system wide implementation of the ESNI Draft. I am planning on= >> implementing draft-ietf-tls-esni-02 because this is the version that >> cloudflare currently has published on their servers. I am planning on >> upgrading to newer versions of ESNI as more implementations come out o= n the >> server side >> >> My question to everyone is if creating this implementation will hurt o= r >> help this document? I would really like for this to be a standard that= is >> used everywhere in every browser and in every computer. But I understa= nd draft-ietf-tls-sni-encryption >> 3.4 >> 's >> importance about not sticking out. Is there a time where vendors all p= lan >> to implement or do you think this is a perfect time to create this? >> _______________________________________________ >> 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 --------------926D93F7DD32B7D1008FE5CB Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------926D93F7DD32B7D1008FE5CB-- --ugjRPLrLQ5T1b0dWTvGJP0akt6CcYpQR4-- --5ZB0ruLRJtWjEvOeX9spnWFPHmq27AJJt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5GePYACgkQWrL68XsX K+o+VxAAgj8gHg6XZnNvOXavff/J7X4wukyR8e5ZkUsh6LdxafSMfYol2ScqGOEF OnmYiDsD4Hz5wT3NkvIA6Ql5mHP8RtJshGyp3oCzF1yLWHjFLaIJt9AUqgjKxmZy 6dlbYAUCQXxXycenI5n9HArBnTdRucy/PgO8ZtgF2ZmZ5/xmmyv4UYtHL1YVb0QB P0k4MOQD/qyqQ5yf8SZFqZotxWF2SGSH6THJeYbAPoEUNWAoms83lWKJgmzV9ETg JTRStUWStEIY9At0HUcniWB5r7MyX09rjR5RS90BzYlP39VbJ63hZgcKp6Kq5oTU zSxEromDZJVk74rryX0cIpsCYIPv4V7+FW8ghMuBf9JPZU2BK6xw9Z6zN9FqyQaf V0EKaNROMdP9M2UMzK85G5S4Tm3KFDUwcuJYfypSHi0l7SBO2jokerQxj6fkCXjw C3FyhFofi27HxxWXA1GuUOkA+Wr9hFVgfgBMJMzCqEbVt3SK3c01TqcmPgjZXO+x QgwGzjt5UH+1cOvSlC8Nvf3PliUM6qnGZWINRqbnwKidEJQGDPB7GAdhKLLRIFbt Wq2qaHowqXok5FZfwE73lk5DCTHpO2ZlhCgs22+rnkTxlQTIVMggCrMQKYambrOc 8uzOEpZkxQId5P6ryCGXTGdtLORCSOBNfTzhFcPW3qkRpDGBLLk= =dGx0 -----END PGP SIGNATURE----- --5ZB0ruLRJtWjEvOeX9spnWFPHmq27AJJt-- From nobody Fri Feb 14 06:47:39 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2618B1200EB for ; Fri, 14 Feb 2020 06:47:37 -0800 (PST) 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=pobox.com header.b=mi/6MEP+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hZOqlXZ5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDZG00KzYKxj for ; Fri, 14 Feb 2020 06:47:33 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21A51200CC for ; Fri, 14 Feb 2020 06:47:33 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3BFC82218B for ; Fri, 14 Feb 2020 09:47:32 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Fri, 14 Feb 2020 09:47:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pobox.com; h= mime-version:message-id:date:from:to:subject:content-type; s= mar2016.fm; bh=NRKXk1PCYnyXcWcdgNr1uazLP/lT60wRkvM7T0cZ9EU=; b=m i/6MEP+QNrQ3ZcrNczQunm28ittyLcyKIMWjEk6dbkkzsEH9J9/syqMK+km0+Ue7 NuwB3yCC/MGlxU5szYZS6IX+PsKfoUyCR58BkqdsARd4s842vlHNgeNbDio9jw54 sGn89wOvVHf9Y+UUHQceVAdg6biqJPnGfSwgu5sry8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=NRKXk1PCYnyXcWcdgNr1uazLP/lT6 0wRkvM7T0cZ9EU=; b=hZOqlXZ5FkAOVr5fXi0F59EMVBfQiW6ndhVSc7ItvEFP6 K/phWVLWumWZFVxJM3XUBO97EgwOW4MZtuRfIrzBahjlddHHw1GIXP8diL5SXzVY QvWmSd2dIsTciOTgnOLYnISu/XFlS3jVcTx+t+WpGLCHVSqHGrkIXhDNbOg8eVmO mfWq3xfyQuJI/cxl7KHdvIviQsou07DKxMchRYp8OlXE+88TPpoWO6n8wqjUKxNJ o/XSZS6F/mVDIXPnUy2GIggh1CrDLWsU6D847eNZe8btpSnCosLDqJWE4k1e9xHD KvaUJHuYo4iLJrZZKiNlXk+uxPrp6kBmJR1lkfH0Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjedtgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdfoihgthhgrvghlucffkdfgrhhrihgtohdfuceomhhikhgvqdhl ihhsthesphhosghogidrtghomheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhikhgvqdhlihhsthesphhosghogidrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F34B5660065; Fri, 14 Feb 2020 09:47:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: Date: Fri, 14 Feb 2020 09:46:56 -0500 From: "Michael D'Errico" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: [TLS] New direction for TLS? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 14:47:37 -0000 Hi, It's been a long time since I posted to this list but saw that the charter is being updated and wanted to share an idea I had a while ago but have not found the time to work on. The TL;DR is to deprecate TLS and rebuild security on top of DTLS. With DTLS, you have encrypted packets, so think of them as the new IP and build TCP on top of that. It'd be like making the internet run on TCP/DTLS instead of TCP/IP, so most of the work is already done. I think this is all I need to say to get the idea across, but I can add detail if needed. Mike From nobody Fri Feb 14 06:51:04 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1D21200CC for ; Fri, 14 Feb 2020 06:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 2rOnMU8eVmhR for ; Fri, 14 Feb 2020 06:50:58 -0800 (PST) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B6F1200E6 for ; Fri, 14 Feb 2020 06:50:58 -0800 (PST) Received: by mail-yw1-xc2c.google.com with SMTP id f204so4331211ywc.10 for ; Fri, 14 Feb 2020 06:50:58 -0800 (PST) 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=4SBMvTstSZoeJgP7o5NHiXPH7jrjnatLfMC1yGIj2m0=; b=SjRtwRWK6dOMDFpi6WJwbl4WusmxMXnwqjLUyts4cu/FEkgyjZ4M0xljNz/vK6OETu N0PZR2xne6+UtQbrL8l4ALWvDVb+vhIrHZdoFVXmQJLkITnAseV/IhcFon5jkpdVXBke eBN8rUjI/rXJ85LL1ZbxymhNGSAfktArz4jv9YsehrgkZqZdaTHR/PLK4Msp8CQKAkYf I0C3F9DfnAykr9tCik51NUaG4q+wStISYnVg9JEQsexkMf1VW/tLA38W/6oKtZ4+3/6u k+e8daAqXFh8ubn5Si9M+Af3mK4qAgNfXQL3uOyprRy73fTMMLjE8OTGkMDG28wYJ0Vn ETZg== 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=4SBMvTstSZoeJgP7o5NHiXPH7jrjnatLfMC1yGIj2m0=; b=J4eC2azeaa+s4YDqFDpjMmlHGspNAQcTC1MCWjin0uJxIsG0jGTIy8YSS5Wtnlxmri aoiRKd51eoKpGXR9Hj9E0kRqfksNaFF+kyG8iO3B1JCFhbgbTMaBEhGsG9C9KPIwS86n Ih5jWTUjDsbYhEmiyvqJdqE9LmlYmqfJ4qUC1NUK8sC2OCDCtl22D/X8kQK33dHPKRBe GoefgzGyq7yPcf7N7RDCxxELLutfEOmgXC2dB4RaxS/WXlczJqI0f2i93nS5meeL3IzG /sgcMuqQjSPv6x7gsxbLB9geRXChFtGnWgajWqeMRIsK2/BldoR34anJZogNCgb+DYKU 6WVw== X-Gm-Message-State: APjAAAUqij2hKlQuTeLOIqveOKW50NwrU5ZT2q+HqTzsEjnqryKOcHGV 8lSl2vixI7j1A2q3+Dara1OZ6toldHiMPF60xMXBHQ== X-Google-Smtp-Source: APXvYqwWlp3kZFHpdd/+uENdw1BpqxpxzhntYk2FUkTv3zhYgH6GdxFxnZLMG/1FhGYVwD7gbJQaTU5neGl4jCs0l8I= X-Received: by 2002:a81:3ccf:: with SMTP id j198mr2710863ywa.83.1581691857638; Fri, 14 Feb 2020 06:50:57 -0800 (PST) MIME-Version: 1.0 References: <182336C5-9F86-4C80-99D8-155A8565ED9F@akamai.com> In-Reply-To: From: Jonathan Hammell Date: Fri, 14 Feb 2020 09:50:43 -0500 Message-ID: To: Martin Thomson Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000519957059e8a55a6" Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 14:51:02 -0000 --000000000000519957059e8a55a6 Content-Type: text/plain; charset="UTF-8" I would like to see this work adopted by the working group. I think the language issues can be addressed after adoption. However, given the disagreements raised, I would also be okay if the adoption decision was postponed until after discussion in Vancouver. Jonathan On Thu., Feb. 13, 2020, 4:29 p.m. Martin Thomson, wrote: > On Fri, Feb 14, 2020, at 06:00, Salz, Rich wrote: > > > I think the draft would be ok to adopt if we don't finish > > it until the outcome from the NIST competition is known. > > Otherwise I would be against adoption. > > > > I think I agree with this, but am not sure. Can we have this on the > > agenda for Vancouver? > > That's a good idea. Because I'm fairly sure that I disagree. > > This work might form the basis of experiments. If the competition result > is known, we might instead want to start the process of defining key > exchange with a single algorithm rather than concern ourselves with > compositions. Having the document in place so that we can define > experiments with a degree of surety with respect to their risks is best. > > In any case, we should adopt this work. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000519957059e8a55a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to see this work adopted by the working grou= p. I think the language issues can be addressed after adoption.=C2=A0

However, given the disagreements ra= ised, I would also be okay if the adoption decision was postponed until aft= er discussion in Vancouver.=C2=A0

Jonathan=C2=A0

On Thu., Feb. 13, 2020, 4:29 p.m. Martin Thom= son, <mt@lowentropy.net> wro= te:
On Fri, Feb 14, 2020, at 06:00,= Salz, Rich wrote:
> >=C2=A0 =C2=A0 I think the draft would be ok to adopt if we don'= ;t finish
>=C2=A0 =C2=A0 =C2=A0it until the outcome from the NIST competition is k= nown.
>=C2=A0 =C2=A0 =C2=A0Otherwise I would be against adoption.
>=C2=A0 =C2=A0
> I think I agree with this, but am not sure. Can we have this on the > agenda for Vancouver?

That's a good idea.=C2=A0 Because I'm fairly sure that I disagree.<= br>
This work might form the basis of experiments.=C2=A0 If the competition res= ult is known, we might instead want to start the process of defining key ex= change with a single algorithm rather than concern ourselves with compositi= ons.=C2=A0 Having the document in place so that we can define experiments w= ith a degree of surety with respect to their risks is best.

In any case, we should adopt this work.

_______________________________________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000519957059e8a55a6-- From nobody Fri Feb 14 09:36:01 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB3012098D for ; Fri, 14 Feb 2020 09:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=i3BFXBtT; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=rLQAr9o4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5RnB_l4Xwsy for ; Fri, 14 Feb 2020 09:35:53 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138BA120913 for ; Fri, 14 Feb 2020 09:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11182; q=dns/txt; s=iport; t=1581701753; x=1582911353; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=VXVkUwBtyPbvmwQtkCCHfmN8yrGpr9OeFv3EeyKMs00=; b=i3BFXBtTdn4ycWht/r74Mg4U+Hz9tQIaneI+Z/3naN/pR/d4m4adYTIh K1ihkHvdm0UIjaug2UVrOoCCHQ9y0NgEGRpR89VamnRbmdd9TZQwn6Fa7 WP7OYRTrKzJ2duUjVADcVLjDMv9gGHuHC7mSuancFCFQD/sSiKOJGF2PY Y=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AzA+O9x33KeRDnz/1smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEU7yKebjaSUSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYEwAm2kZe/4YNJK1mHgELHIFwC4E?= =?us-ascii?q?lL1AFbCstIAQLKgqECoNGA4p3ToIRhz6LcoRhglIDVAIHAQEBCQMBASMKAgQ?= =?us-ascii?q?BAYRAAoIBJDcGDgIDDQEBBQEBAQIBBQRthTcMhWYBAQEBAxILBgoTAQE4DwI?= =?us-ascii?q?BCA4DBAEBKwICAjAdCAIEARIIBhSDBYF9TQMfDwECDKMMAoE5iGJ1gTKCfwE?= =?us-ascii?q?BBYFDQYMfGIIFBwMGgTiBU4pRGoFBP4ERR4JMPoFUgRACAwGBYxUWgmMygiy?= =?us-ascii?q?QXYZumDMKgjqDbYI7gSWPIIJJiBSQO45oiG6SQAIEAgQFAg4BAQWBaCOBWHA?= =?us-ascii?q?VO4JsUBgNjh2Dc4UUhT90gSmOHwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,441,1574121600"; d="p7s'?scan'208,217";a="429196246" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Feb 2020 17:35:40 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 01EHZed4018270 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2020 17:35:40 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 14 Feb 2020 11:35:39 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 14 Feb 2020 11:35:39 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 14 Feb 2020 11:35:38 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H1xSl4rjh/gZnvrFzCVkBhSxl5xenc9RPl/+mzYbRQXRcwzB9gx57VMn+0OVm+Q++arRlQZuGLt/0zKCyjnB2tP1vv43tIYdfMQuiplx6Lw2a9gkXdr5Y1N310qhPkUOZXdSiZN80rC08G5UknC4yZFRGDuRJZhWqa+nAUQuFRx+uAO89YvSCs8zBwXAQW4z18CLEel6MSM3gUPd8Vl5001vHDNBNF3l4Gc02dSlO9t7CYtWABBXdvw+SlZjKm9TGg7CRtNeDyEQOT41+FfOVtQcS1Zl53I+MJoO5dM2wL7ViceTGPSQx91VFX1bvRw+n5eAJhj2uZJFzqyEcrQbNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TV0abrVDw3b/B4tm09KDRHqdkKDcdm645giVO8p6ix8=; b=ScIPpOLcs7vQTN2QgkdQ9JN7YymphGKgj6qp0JdPJLO2MSgQTT06zC+AnyPTjBRHVloKXTv3Myw4w5aed3AY820RPIgZaD/VqAgDPO/Q6axgI6Ks5/c4PrDDg5MWxlwupKHZ6wDHhIyTK/Bx7UziszMhKRIG3osCsgW4Lx/ZCLvYrOf8l/9DTPSKcRsYS8wosOMaw9ZriTjw94ZJ8MrAs3PJzZ2QUHgLQoozWrzR9jLoyG+wCdgvVNV+iWuX1ob/fxBIC0aoVlNdxaMX8GQk+oeQbTUAH+q9cdS/5Aq74AQJYNqjRqrqZf1EFbuaSVqdH5LYO/6WRNlPc/7pBZnm5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TV0abrVDw3b/B4tm09KDRHqdkKDcdm645giVO8p6ix8=; b=rLQAr9o42Fr9ahX6YcL+OQ+G0jq7tqcrBmxNF4NxKAo2Xy/c4Yf4wkPWIr/uSholtzmxEpZ5qjSy1WcN8HvaLSeZ/WmlJ2OBP0zeIJEDIRXWT9iRLDCGC0UwnqagcQ4a4q7C6UCnPlM/pYerhJVTrVDI4oGgcutAmLRHGghD3I4= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2738.namprd11.prod.outlook.com (52.135.245.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.22; Fri, 14 Feb 2020 17:35:38 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2d8b:4fd5:9d28:a1c7]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2d8b:4fd5:9d28:a1c7%6]) with mapi id 15.20.2729.025; Fri, 14 Feb 2020 17:35:38 +0000 From: "Panos Kampanakis (pkampana)" To: Joseph Salowey , "" Thread-Topic: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design Thread-Index: AQHV4pET1T914LkJ7kGkPWtr+V+qu6ga9SZw Date: Fri, 14 Feb 2020 17:35:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [68.93.142.48] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 85e7fe8b-a6ea-46c2-6395-08d7b1744e1e x-ms-traffictypediagnostic: BN7PR11MB2738: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03137AC81E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(396003)(346002)(376002)(199004)(189003)(478600001)(8676002)(4744005)(81156014)(53546011)(966005)(81166006)(26005)(6506007)(8936002)(7696005)(2906002)(55016002)(110136005)(66476007)(86362001)(64756008)(186003)(66946007)(66556008)(76116006)(66616009)(66446008)(316002)(5660300002)(52536014)(9686003)(33656002)(71200400001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2738; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m4AZFbqq2YBNkzyRSivH0Z+4PJIbKIx0mZvWVrkLQ6VBEASxSxcfdMxVJzxnuK/CLjOG2eQqmTw9jm1wnU5JvO63UMGct6AfhN7fO0LiVbhUS7mHOwjfpt8kXias7rpOlI6QPrsK8te+NivS2QDFTsMUPQr4d9ItoQCu8Xwg8X5562aY1w9lLfw6eF5KNBQzwqCsFTxk58dVwBG2BeegdYSTdXI+dQkhEfrCLuK0WgaabCyjQ+7nHN6KwlVXOa/oO8Dz6YllOB/NNt84iVMmG8bE9iFA64qZUwhny2/ih9d7L+EbmSPHuivgaxEeaFwEIT7P0RJlV/zqH77Tr4doBYu/Q0mt+HcJOnxZEfEWG4Ef2rZF9d1Q1p1DfZzKHFrNZszGECAPVKI8GrisFyVHCd8+4Rvr5rgcNBLctvGdxgp18nnrfeK9Htxgc80gbTuu5gIjrcMKxuaeL89LvzbjDXTK7vz8wVwArzfryJmtZi6cVDmfn246Zvvb5VXOTO1XyY4d+YelQy/iN5UeJ4GPKN9nxqS+5PqXx4+EmwyE2B2rFcZ0WA6Yl05UDCu1ZlTv x-ms-exchange-antispam-messagedata: pQ1Zs3b6dPHvtNNfaUJ4spn2LO/0sg80i3KM8nR9OcpwvFb1UJkg9g6lHi/UWJaDb8Va378t4rKi/zfm4caxoEMBaDjeacxAffc60i5sq1iEHWYgpvt7zmQB6ghAgf7iMunU73MOStV1PkpJCTljbQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0053_01D5E333.41EC9A80" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 85e7fe8b-a6ea-46c2-6395-08d7b1744e1e X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2020 17:35:37.7253 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XjW6AKA/X/OdS7lPXeggk5hUisiFU00TP+qnU/s6nd5OwfW/H7iqvejRvwR0qIYZ63ACfsio6XhCjgSkD6ibxg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2738 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 17:35:58 -0000 ------=_NextPart_000_0053_01D5E333.41EC9A80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0054_01D5E333.41EC9A80" ------=_NextPart_001_0054_01D5E333.41EC9A80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I support adoption From: TLS On Behalf Of Joseph Salowey Sent: Thursday, February 13, 2020 12:13 PM To: Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design The authors of "Hybrid Key Exchange" have asked for adoption of their draft as a WG item. Please state whether you support adoption of this draft as a WG item by posting a message to the TLS list by 2359 UTC 28 February 2020. Please include any additional information that is helpful in understanding your position. NOTE: If the draft is adopted, the working group has change control over the draft and the timing of its progression. This means the document does not have to be perfect as the working group can and will make changes. Adopting the draft means the working group thinks the topic is a good idea and the draft is a good place to start the work. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ ------=_NextPart_001_0054_01D5E333.41EC9A80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I support adoption

 

From: TLS <tls-bounces@ietf.org> On = Behalf Of Joseph Salowey
Sent: Thursday, February 13, 2020 = 12:13 PM
To: <tls@ietf.org> = <tls@ietf.org>
Subject: [TLS] Call for Adoption: = draft-stebila-tls-hybrid-design

 

The authors of "Hybrid = Key Exchange" have asked for adoption of their draft as a WG = item.  Please state whether you support adoption of this draft as a = WG item by posting a message to the TLS list by 2359 UTC 28 February = 2020.  Please include any additional information that is helpful in = understanding your position.

NOTE:
If the draft is adopted, = the working group has change control over the draft and the timing of = its progression.  This means the document does not have to be = perfect as the working group can and will make changes.  Adopting = the draft means the working group thinks the topic is a good idea and = the draft is a good place to start the work. =  

Thanks,
Chris, Joe, and Sean

[0] https://datatra= cker.ietf.org/doc/draft-stebila-tls-hybrid-design/<= /p>

 

 

------=_NextPart_001_0054_01D5E333.41EC9A80-- ------=_NextPart_000_0053_01D5E333.41EC9A80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMjE0MTczNTM2WjAvBgkqhkiG9w0BCQQxIgQgU/GPJ9tMMuSyMo6i4ssKK1a1BW1c490w Zd8/Z6uTLAUwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA E9tpSHS463pUOH8nYIta6q4wGzjurq0ETK+av8GLGIbwJCb7IeY2D3MKeazuFdGYK3JYeeOd11gz w+S+TS+T/6JeuipycYPHBQbo2cScPk05FOhuieqjef2oaqU6Zg1lIdm6oXns9ndRMEURtUqsN5QE yw2ruer9KCTxpa0gSP2c8sj3o9AQhw529dBx+81EHfuMs87/pjJgshmBzlVZVUIckwT2sqe+47n3 rAYswwoqKaZaXWAQBu0nss5bAfD+bzv6PKxw9io16Gn6VyavQMHZP4B0VQlV6A9tptMqTeYVlQch yDF4p/7PnUnIcNIUx5wy2G/941rnP6CKvO1vXAAAAAAAAA== ------=_NextPart_000_0053_01D5E333.41EC9A80-- From nobody Fri Feb 14 11:29:04 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED622120B33 for ; Fri, 14 Feb 2020 11:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.757 X-Spam-Level: X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 DuN2L0jkuE9Y for ; Fri, 14 Feb 2020 11:28:59 -0800 (PST) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE17120A3A for ; Fri, 14 Feb 2020 11:28:59 -0800 (PST) Received: by mail-vk1-xa30.google.com with SMTP id u6so2881924vkn.13 for ; Fri, 14 Feb 2020 11:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=05K6GTi0x6bJUkhLHiZFkFFL6U2Y5t63Y5f6AiyC0dA=; b=eBSTejmJ54svOgKNY/4fI9BQ0A6r1LRLEf9YK8D5g6X8igLIKo9yUDpXioYVylYg4L v4ZaUEpkvgTCvYyVy9v5Fubq7nnZK0ZjvasFWTVp5+O1RJE7gHM7z4skOGKIk2DJvQuP 1uk9Uha0gNTcePWm+lDEwuVB9SiYdltIqTrqs= 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=05K6GTi0x6bJUkhLHiZFkFFL6U2Y5t63Y5f6AiyC0dA=; b=q3eGoUmjyRW0R2ioZlWklxwBhitg4+wWE3ik2B59Q3P4QWnpSnM3CM7QNpTZy1UMfP GWYEG1MK5j9A2HJw+OGMaJAr2fTkv6C6ulo06VfV+KvL+4QfIQbvyybIt8JNt0QZq79C q/YYvmezxRdRoDoyn9sEowCTli2yr+yFYi8q+jtgIk4rNoOWvobCRz5Cq7ZCbSEdyjfa YzvFVOjJwRRrO6B3se7uW9sYA/r6Mi1weKYrFg/pX2t6Jyzbcvb5tqmHca2zbCAHGyqm lZv718Nx2amU+DZOZuUXe2j6PCJNurUc0ms4unY/CYFSuTk4cuEYBq4Ht04T62ClumS2 uWSA== X-Gm-Message-State: APjAAAXRJPifuumALQg2Yvp33YLalQlm7uXO2/svaGrxOBjSGGnXgmtx CN2duLAb5lYaTfhYqM1U8gVlt/w96gzKcJATHtssjuwZZtI= X-Google-Smtp-Source: APXvYqzfGTHS8z9j2AqqgF0yKiFf3SHT/Zs7zOvYJFuwg0LC4KPdYajlpOQXXmTYOn73fCGT4UDpJQ6TUnIyLdojohQ= X-Received: by 2002:a1f:a9d0:: with SMTP id s199mr197369vke.40.1581708538224; Fri, 14 Feb 2020 11:28:58 -0800 (PST) MIME-Version: 1.0 References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> <20200209140242.GA1489626@LK-Perkele-VII> In-Reply-To: <20200209140242.GA1489626@LK-Perkele-VII> From: Nick Sullivan Date: Fri, 14 Feb 2020 11:27:36 -0800 Message-ID: To: Ilari Liusvaara Cc: "" Content-Type: multipart/alternative; boundary="0000000000008f495d059e8e37b4" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 19:29:02 -0000 --0000000000008f495d059e8e37b4 Content-Type: text/plain; charset="UTF-8" Ilari, Thank you for identifying these errors in the document. There was no intention to allow the client to constrict the server certificate's algorithm with the delegated_credential extension, and no intention to restrict the delegated credential's algorithm with the signature_algorithms. Let me propose some minor text changes to address the issues. As a reminder, the CertificateVerify.algorithm is constrained by the signature_algorithms extension, as stated in RFC 8446: If the CertificateVerify message is sent by a server, the signature algorithm MUST be one offered in the client's "signature_algorithms" extension unless no valid certificate chain can be produced without unsupported algorithms (see Section 4.2.3 ). Original text from 4.1.2.: The expected_cert_verify_algorithm fields MUST be of a type advertised by the client in the SignatureSchemeList and are considered invalid otherwise. Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. proposed text: The expected_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList and is considered invalid otherwise. Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. As for the second point, we did not add the capability for the server to advertise a different set of signature_algorithms for client authentication other than the one advertised via the "signature_algorithms" extension. This was perhaps an oversight. I propose that we add that capability and I'd be happy to propose a PR to that effect. The new text of 4.3.2. would look something like: A server which supports this specification SHALL send an "delegated_credential" extension in the CertificateRequest message when requesting client authentication. The body of the extension consists of a SignatureSchemeList. If the server receives a delegated credential without indicating support in its CertificateRequest, then the server MUST abort with an "unexpected_message" alert. ... The algorithm field MUST be of a type advertised by the server in the "signature_algorithms" extension of the CertificateRequest message and the expected_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList and considered invalid otherwise. Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. Nick On Mon, Feb 10, 2020 at 7:59 AM Ilari Liusvaara wrote: > On Wed, Feb 05, 2020 at 12:36:52PM -0800, internet-drafts@ietf.org 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 WG of the IETF. > > > > Title : Delegated Credentials for TLS > > Authors : Richard Barnes > > Subodh Iyengar > > Nick Sullivan > > Eric Rescorla > > Filename : draft-ietf-tls-subcerts-06.txt > > Pages : 15 > > Date : 2020-02-05 > > I noticed the following: > > > The algorithm and expected_cert_verify_algorithm fields MUST be of a > > type advertised by the client in the SignatureSchemeList and are > > considered invalid otherwise. Clients that receive invalid delegated > > credentials MUST terminate the connection with an "illegal_parameter" > > alert. > > This can be interpretted that the delegated_credentials extension > constrains the end-entity certificate algorithm if DC is sent. This has > seemingly undesirable consequences if the list diverges from what the > signature_algorithms contains: > > 1) If delegated_credentials contains algorithm that signature_algorithms > does not, the server may use that as DC signing algorithm, which will > cause PKIX code to blow up. > > 2) If delgated_credentials is missing some algorithm that > signature_algorithms contains, the client needs to constrain the PKIX > validation further. > > These issues are made worse by the fact that delegated credential > validation code is seemingly intended to be separate from PKIX validation > code, meaning the two can diverge from one another (which is a reason > for having separate lists). > > Looking at the steps to validate the delegated credential, there is > no explicit step to validate signing algorithm, which would imply that > the signing algorithm is constrained by the PKIX code, which would > contradict the above. > > Then because *_rsae is not allowed in expected algorithm, clients would > need to include algorithm that can not be used, if they support *_rsae > for PKIX signatures (however, there could be reasons not to support > *_rsae for signing DCs, see below). > > > And: > > > The algorithm and expected_cert_verify_algorithm fields MUST be of a > > type advertised by the server in the "signature_algorithms" extension > > and are considered invalid otherwise. Servers that receive invalid > > delegated credentials MUST terminate the connection with an > > "illegal_parameter" alert. > > Is there a reason why client can specify another set of algorithms for > verification of delegated credentials, but the server can not? > > > Then in security considerations, I do not see the following issue > discussed: > > - Server has RSA key that has delegation_usage and is usable for > RSA encryption. > - Server is vulernable to BB98/ROBOT. > - Attacker uses BB98/ROBOT to sign a delegated credential. > - Attacker impersonates the server using the forged delegated > credential. > > It is much easier to perform this kind of attack than to use BB98/ROBOT > to impersonate without delgated credentials: > > - Much longer time window to perform the attack (limited by certificate > lifetime, not how long client waits). > - One can impersonate server multiple times per successful attack, not > just once. > > This could be generalized to any signing oracle, but the ones > associated with RSA encryption (BB98/ROBOT/DROWN) are the most common > ones. > > > > > > -Ilari > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000008f495d059e8e37b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ilari,

Thank you for identifying these = errors in the document. There was no intention to allow the client to const= rict the server certificate's algorithm with the=C2=A0delegated_credent= ial extension, and no intention to restrict the delegated credential's = algorithm with the signature_algorithms. Let me propose some minor text cha= nges to=C2=A0address the issues.

As a reminder, th= e CertificateVerify.algorithm is constrained by the=C2=A0signature_algorithms extension,= =C2=A0as stated in RFC 8446:

   If the CertificateVerify message is sent by a server, the signatu=
re
   algorithm MUST be one offered in the client's "signature_algori=
thms"
   extension unless no valid certificate chain can be produced without
   unsupported algorithms (see Section 4.2.3).

Original text from 4.1= .2.:

   The expect=
ed_cert_verify_algorithm fields MUST be of a
   type advertised by the client in the SignatureSchemeList and are
   considered invalid otherwise.  Clients that receive invalid delegated
   credentials MUST terminate the connection with an "illegal_paramete=
r"
   alert.

proposed text:

   The expected_cert_verify_algorithm field MUST be of a
   type advertised by the client in the Signat=
ureSchemeList and is
   considered invalid=
 otherwise.  Clients that receive invalid delegated
   credentials MUST terminate the connection with an "illega=
l_parameter"
   alert.

As for the second point, we did not add the capabilit= y for the server to advertise a different set of signature_algorithms for c= lient authentication other than the one advertised via the "signature_algorithms" exten= sion. This was perhaps an oversight. I propose that we add that capability = and I'd be happy to propose a PR to that effect.

The new text of 4.3.2= . would look something like:

 =
  A server which supports this specification SHALL send an
   "delegated_credential" extension in the CertificateRequest mes=
sage
   when requesting client authentication.  The body of the
   extension consists=
 of a SignatureSchemeList.  If the server receives a
   delegated credential without indicating support in its
   CertificateRequest, then the server MUST abort with an
   "unexpected_message" alert.
...
   The algorithm field MUST=
 be of a
   type advertised by the server in the "signature_algorithms" ex=
tension
   of the CertificateRequest messa=
ge and the expected_cert_verify_algorithm
=
   field MUST be of a type advertised by the client in the SignatureSchemeL=
ist
   and considered invalid otherwise.  =
Clients that receive invalid
   delegated credentials MUST terminate the connection with an
   "illegal_parameter" alert.

<= br>
<= br>

Nick


On Mon, Feb 10, 2020 at 7:59 AM Ilari Liu= svaara <il= ariliusvaara@welho.com> wrote:
On Wed, Feb 05, 2020 at 12:36:52PM -0800, internet-drafts@ietf.org= wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Transport Layer Security WG of the IE= TF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Delegated Credentials for TLS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Richard Barnes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Subodh Iyengar
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Nick Sullivan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Eric Rescorla
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tls-subcerts-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 15
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-02-05

I noticed the following:

> The algorithm and expected_cert_verify_algorithm fields MUST be of a > type advertised by the client in the SignatureSchemeList and are
> considered invalid otherwise.=C2=A0 Clients that receive invalid deleg= ated
> credentials MUST terminate the connection with an "illegal_parame= ter"
> alert.

This can be interpretted that the delegated_credentials extension
constrains the end-entity certificate algorithm if DC is sent. This has
seemingly undesirable consequences if the list diverges from what the
signature_algorithms contains:

1) If delegated_credentials contains algorithm that signature_algorithms does not, the server may use that as DC signing algorithm, which will
cause PKIX code to blow up.

2) If delgated_credentials is missing some algorithm that
signature_algorithms contains, the client needs to constrain the PKIX
validation further.

These issues are made worse by the fact that delegated credential
validation code is seemingly intended to be separate from PKIX validation code, meaning the two can diverge from one another (which is a reason
for having separate lists).

Looking at the steps to validate the delegated credential, there is
no explicit step to validate signing algorithm, which would imply that
the signing algorithm is constrained by the PKIX code, which would
contradict the above.

Then because *_rsae is not allowed in expected algorithm, clients would
need to include algorithm that can not be used, if they support *_rsae
for PKIX signatures (however, there could be reasons not to support
*_rsae for signing DCs, see below).


And:

> The algorithm and expected_cert_verify_algorithm fields MUST be of a > type advertised by the server in the "signature_algorithms" = extension
> and are considered invalid otherwise.=C2=A0 Servers that receive inval= id
> delegated credentials MUST terminate the connection with an
> "illegal_parameter" alert.

Is there a reason why client can specify another set of algorithms for
verification of delegated credentials, but the server can not?


Then in security considerations, I do not see the following issue
discussed:

- Server has RSA key that has delegation_usage and is usable for
=C2=A0 RSA encryption.
- Server is vulernable to BB98/ROBOT.
- Attacker uses BB98/ROBOT to sign a delegated credential.
- Attacker impersonates the server using the forged delegated
=C2=A0 credential.

It is much easier to perform this kind of attack than to use BB98/ROBOT
to impersonate without delgated credentials:

- Much longer time window to perform the attack (limited by certificate
=C2=A0 lifetime, not how long client waits).
- One can impersonate server multiple times per successful attack, not
=C2=A0 just once.

This could be generalized to any signing oracle, but the ones
associated with RSA encryption (BB98/ROBOT/DROWN) are the most common
ones.





-Ilari





_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000008f495d059e8e37b4-- From nobody Fri Feb 14 11:38:16 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8F1120B81 for ; Fri, 14 Feb 2020 11:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 vnOWlI93-zdV for ; Fri, 14 Feb 2020 11:38:04 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3265120B50 for ; Fri, 14 Feb 2020 11:38:03 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id x123so6972199vsc.2 for ; Fri, 14 Feb 2020 11:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6w41Kb6sUns/vji5FKqw5CFpbPoYM+wK13mZAb5Cj4U=; b=HQH+AzZGy7nDCOhOVz67CaAdWOr3eYCB88+4EifEavcPSZVhl+65NEJtHlVIa56cTM 0R3CzfSMdrX5uSSJXcLhhxrKqv1U0rwSCb38MDkbeZUIl/JNkPbFOT9nAV1hfvd2uNKy xJgIIfYQTcfv+B2ObVxJDDr9dFPHTa80if/+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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6w41Kb6sUns/vji5FKqw5CFpbPoYM+wK13mZAb5Cj4U=; b=iJy8fXNcO4ZLJ8fAMynggGGX9Y22jQhVQRKUtZBZfIxGFAv8eSYXfaoMkvhGmXDD0f Y9FVWoxfSDLASnDWta59QQoO5yxD/CMAn9bOo6Zi9FbsxtDcY75UixErticIvfyWvJBn b0R04u7FyAHLQVXkAjD+K5FQOBhwFxyGJ0S+ZFiNpP4B5uXnvTFrsLcRoPxcHZzuyo/2 vKeTFgPBPszaqZnXOAr8Qr4uiS9KUEeTsrjsx1E95B8i4YsW+qu+3Q8LApbR/+c/1PNA wFwX4AvdTzeUdLtOc0hU0AlbqM5HKcujcV8LQeQyHlxMMcFfLJV/wgB0oK4MrZ+8nK8f O/DA== X-Gm-Message-State: APjAAAW0BvgucKzQXfw6tij3fv4PWaOG6S0jnXhCcSF/Dfp66ZtIPIo0 F34h6PziAWdX34ZXzstVh0/fvvD40XFaw5N72/DTPA== X-Google-Smtp-Source: APXvYqy1QVZfVKUttXusIJDLr/iV74YvlEd+qtmizhZ/SdujsxYK98V7YQehU2tAIOzi/GxCi4iD0IhSEFDxukBsf7I= X-Received: by 2002:a67:f1ca:: with SMTP id v10mr2491262vsm.180.1581709082547; Fri, 14 Feb 2020 11:38:02 -0800 (PST) MIME-Version: 1.0 References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> <45495A4A-F79D-49B3-9887-3BFF00C00589@icloud.com> In-Reply-To: <45495A4A-F79D-49B3-9887-3BFF00C00589@icloud.com> From: Nick Sullivan Date: Fri, 14 Feb 2020 11:36:40 -0800 Message-ID: To: Carrick Bartle Cc: "" Content-Type: multipart/alternative; boundary="00000000000000f63d059e8e586e" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 19:38:14 -0000 --00000000000000f63d059e8e586e Content-Type: text/plain; charset="UTF-8" Carrick, Thank you for reading the document and identifying an embarrassingly difficult to parse motivating paragraph (with an annoying unclosed parenthesis to boot). You've correctly identified the meaning it was trying to convey and we'll happily review this as a PR here: https://github.com/tlswg/tls-subcerts/. I've noticed a few other readability issues in the document, if you find anything else, we'll happily look at those too. Nick On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle wrote: > TL;DR: I find it difficult to understand the second-to-last paragraph of > the Introduction, so I took a stab at revising it. Let me know if I should > put it in a pull request. > > > This is the paragraph I'm referring to: > > "These dependencies cause problems in practice. Server operators often > want to create short-lived certificates for servers in low- trust zones > such as Content Delivery Network (CDNs) or remote data centers. This allows > server operators to limit the exposure of keys in cases that they do not > realize a compromise has occurred. The risk inherent in > cross-organizational transactions makes it operationally infeasible to rely > on an external CA for such short- lived credentials. In Online Certificate > Status Protocol (OCSP) stapling (i.e., using the Certificate Status > extension type ocsp [RFC8446], if an operator chooses to talk frequently to > the CA to obtain stapled responses, then failure to fetch an OCSP stapled > response results only in degraded performance. On the other hand, failure > to fetch a potentially large number of short lived certificates would > result in the service not being available, which creates greater > operational risk." > > Here are my issues with it: > > - I think OCSP is being brought up here as an example of a way that > dependence on a CA can go wrong, but that isn't really made explicit. > > - I'm not sure what "only" means in "only in degraded performance." Is it > "the worst that can happen is just degraded performance" or "it can result > only in degraded performance, as opposed to better performance"? At first I > thought it was the latter, but after reading the subsequent sentence, I > realized it was probably the former. > > - The use of "On the other hand" sounds like the rest of the sentence is > going to describe a way that failure to receive something from a CA > resulted in better performance, which obviously would be silly. > > Taking all these points together, here's my suggestion for a revision to > make what I think the thrust of the paragraph is more clear: > > "These dependencies cause problems in practice. Server operators often > want to create short-lived certificates for servers in low-trust zones such > as Content Delivery Network (CDNs) or remote data centers. This allows > server operators to limit the exposure of keys in cases where they do not > realize a compromise has occurred. But the risk inherent in > cross-organizational transactions makes it operationally infeasible to rely > on an external CA for such short-lived credentials. For instance, in the > case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the > Certificate Status extension type ocsp [RFC8446]), a CA may fail to deliver > OCSP stapled response. While this will result in degraded performance, the > ramifications of failing to deliver short-lived certificates is even worse: > the service that depends on those certificates would go down entirely. > Thus, ensuring independence from CAs for short-lived certificates is > critical to the uptime of a service." > > > Carrick > > > > > On Feb 5, 2020, at 12:36 PM, internet-drafts@ietf.org 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 WG of the IETF. > > > > Title : Delegated Credentials for TLS > > Authors : Richard Barnes > > Subodh Iyengar > > Nick Sullivan > > Eric Rescorla > > Filename : draft-ietf-tls-subcerts-06.txt > > Pages : 15 > > Date : 2020-02-05 > > > > Abstract: > > The organizational separation between the operator of a TLS endpoint > > and the certification authority can create limitations. For example, > > the lifetime of certificates, how they may be used, and the > > algorithms they support are ultimately determined by the > > certification authority. This document describes a mechanism by > > which operators may delegate their own credentials for use in TLS, > > without breaking compatibility with peers that do not support this > > specification. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-subcerts-06 > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-06 > > > > > > 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 > --00000000000000f63d059e8e586e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Carrick,

Thank you for reading the docu= ment and identifying an embarrassingly difficult to parse motivating paragr= aph (with an annoying unclosed parenthesis to boot). You've correctly= =C2=A0identified the meaning it was trying to convey and we'll happily = review this as a PR here:=C2=A0https://github.com/tlswg/tls-subcerts/. I've noticed a few o= ther readability issues in the document, if you find anything else, we'= ll happily look at those too.

Nick

On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle <cbartle891= =3D40iclou= d.com@dmarc.ietf.org> wrote:
TL;DR: I find it difficult to understand the second-to-= last paragraph of the Introduction, so I took a stab at revising it. Let me= know if I should put it in a pull request.


This is the paragraph I'm referring to:

"These dependencies cause problems in practice. Server operators often= want to create short-lived certificates for servers in low- trust zones su= ch as Content Delivery Network (CDNs) or remote data centers. This allows s= erver operators to limit the exposure of keys in cases that they do not rea= lize a compromise has occurred. The risk inherent in cross-organizational t= ransactions makes it operationally infeasible to rely on an external CA for= such short- lived credentials. In Online Certificate Status Protocol (OCSP= ) stapling (i.e., using the Certificate Status extension type ocsp [RFC8446= ], if an operator chooses to talk frequently to the CA to obtain stapled re= sponses, then failure to fetch an OCSP stapled response results only in deg= raded performance. On the other hand, failure to fetch a potentially large = number of short lived certificates would result in the service not being av= ailable, which creates greater operational risk."

Here are my issues with it:

- I think OCSP is being brought up here as an example of a way that depende= nce on a CA can go wrong, but that isn't really made explicit.

- I'm not sure what "only" means in "only in degraded pe= rformance." Is it "the worst that can happen is just degraded per= formance" or "it can result only in degraded performance, as oppo= sed to better performance"? At first I thought it was the latter, but = after reading the subsequent sentence, I realized it was probably the forme= r.

- The use of "On the other hand" sounds like the rest of the sent= ence is going to describe a way that failure to receive something from a CA= resulted in better performance, which obviously would be silly.

Taking all these points together, here's my suggestion for a revision t= o make what I think the thrust of the paragraph is more clear:

"These dependencies cause problems in practice. Server operators often= want to create short-lived certificates for servers in low-trust zones suc= h as Content Delivery Network (CDNs) or remote data centers. This allows se= rver operators to limit the exposure of keys in cases where they do not rea= lize a compromise has occurred. But the risk inherent in cross-organization= al transactions makes it operationally infeasible to rely on an external CA= for such short-lived credentials. For instance, in the case of Online Cert= ificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status= extension type ocsp [RFC8446]), a CA may fail to deliver OCSP stapled resp= onse. While this will result in degraded performance, the ramifications of = failing to deliver short-lived certificates is even worse: the service that= depends on those certificates would go down entirely. Thus, ensuring indep= endence from CAs for short-lived certificates is critical to the uptime of = a service."


Carrick



> On Feb 5, 2020, at 12:36 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Transport Layer Security WG of the IE= TF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Delegated Credentials for TLS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Richard Barnes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Subodh Iyengar
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Nick Sullivan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Eric Rescorla
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tls-subcerts-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 15
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-02-05
>
> Abstract:
>=C2=A0 =C2=A0The organizational separation between the operator of a TL= S endpoint
>=C2=A0 =C2=A0and the certification authority can create limitations.=C2= =A0 For example,
>=C2=A0 =C2=A0the lifetime of certificates, how they may be used, and th= e
>=C2=A0 =C2=A0algorithms they support are ultimately determined by the >=C2=A0 =C2=A0certification authority.=C2=A0 This document describes a m= echanism by
>=C2=A0 =C2=A0which operators may delegate their own credentials for use= in TLS,
>=C2=A0 =C2=A0without breaking compatibility with peers that do not supp= ort this
>=C2=A0 =C2=A0specification.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft= -ietf-tls-subcerts/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tl= s-subcerts-06
> https://datatracker.ietf.org/do= c/html/draft-ietf-tls-subcerts-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-tls-subcerts-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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
--00000000000000f63d059e8e586e-- From nobody Fri Feb 14 11:50:56 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3E9120B3D for ; Fri, 14 Feb 2020 11:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03DdJcGXxZ3L for ; Fri, 14 Feb 2020 11:50:52 -0800 (PST) Received: from mr85p00im-hyfv06011401.me.com (mr85p00im-hyfv06011401.me.com [17.58.23.191]) (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 63AF4120B37 for ; Fri, 14 Feb 2020 11:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1581709492; bh=Hhu9aB4VeAxTgby+d9nTmr74sinNq5l23XskIlumwAc=; h=From:Message-Id:Content-Type:Subject:Date:To; b=lZTF3XFkkzFWtg0CvkFJ/RKXUZb7LjW7F2PiWp9L164vHA9O1QMaL+CBhdSSCnbrS hvHBnIHYjLABsKkUgpRi8HrE1WInsKoGIPNns6RWTlqzWEsDwWiuEAyLo6KWI55ITo DzBx7p1f5+g82/j+JJWokrjydAHgkh61WGWs/Mn45SFz5gSqGTYHKQmOVl1OjnuNU3 R1XsTPYH6iSicac/gwYyXcDt5M0lrzC0sz6Y+VZPxMRTxKn9sZEAgjkzF61ylJz40z xxodkv/9e3dEECYDuvi9+zRM69gB9bFSI6POWOH+gGr3DsL3yJry4coms9XoZc/wVD 3nZ7GmyspBFKw== Received: from [17.234.27.89] (unknown [17.234.27.89]) by mr85p00im-hyfv06011401.me.com (Postfix) with ESMTPSA id 5086FD203A8; Fri, 14 Feb 2020 19:44:52 +0000 (UTC) From: Carrick Bartle Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9820E1AB-9745-405F-9CDC-CB09BCF4885C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.3\)) Date: Fri, 14 Feb 2020 11:44:46 -0800 In-Reply-To: Cc: Carrick Bartle , "" To: Nick Sullivan References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> <45495A4A-F79D-49B3-9887-3BFF00C00589@icloud.com> X-Mailer: Apple Mail (2.3608.80.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2002140142 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 19:50:55 -0000 --Apple-Mail=_9820E1AB-9745-405F-9CDC-CB09BCF4885C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Great! I'll push it on over and continue reviewing. > On Feb 14, 2020, at 11:36 AM, Nick Sullivan = wrote: >=20 > Carrick, >=20 > Thank you for reading the document and identifying an embarrassingly = difficult to parse motivating paragraph (with an annoying unclosed = parenthesis to boot). You've correctly identified the meaning it was = trying to convey and we'll happily review this as a PR here: = https://github.com/tlswg/tls-subcerts/ = . I've noticed a few other = readability issues in the document, if you find anything else, we'll = happily look at those too. >=20 > Nick >=20 > On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle = > wrote: > TL;DR: I find it difficult to understand the second-to-last paragraph = of the Introduction, so I took a stab at revising it. Let me know if I = should put it in a pull request. >=20 >=20 > This is the paragraph I'm referring to: >=20 > "These dependencies cause problems in practice. Server operators often = want to create short-lived certificates for servers in low- trust zones = such as Content Delivery Network (CDNs) or remote data centers. This = allows server operators to limit the exposure of keys in cases that they = do not realize a compromise has occurred. The risk inherent in = cross-organizational transactions makes it operationally infeasible to = rely on an external CA for such short- lived credentials. In Online = Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate = Status extension type ocsp [RFC8446], if an operator chooses to talk = frequently to the CA to obtain stapled responses, then failure to fetch = an OCSP stapled response results only in degraded performance. On the = other hand, failure to fetch a potentially large number of short lived = certificates would result in the service not being available, which = creates greater operational risk." >=20 > Here are my issues with it: >=20 > - I think OCSP is being brought up here as an example of a way that = dependence on a CA can go wrong, but that isn't really made explicit. >=20 > - I'm not sure what "only" means in "only in degraded performance." Is = it "the worst that can happen is just degraded performance" or "it can = result only in degraded performance, as opposed to better performance"? = At first I thought it was the latter, but after reading the subsequent = sentence, I realized it was probably the former. >=20 > - The use of "On the other hand" sounds like the rest of the sentence = is going to describe a way that failure to receive something from a CA = resulted in better performance, which obviously would be silly. >=20 > Taking all these points together, here's my suggestion for a revision = to make what I think the thrust of the paragraph is more clear: >=20 > "These dependencies cause problems in practice. Server operators often = want to create short-lived certificates for servers in low-trust zones = such as Content Delivery Network (CDNs) or remote data centers. This = allows server operators to limit the exposure of keys in cases where = they do not realize a compromise has occurred. But the risk inherent in = cross-organizational transactions makes it operationally infeasible to = rely on an external CA for such short-lived credentials. For instance, = in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., = using the Certificate Status extension type ocsp [RFC8446]), a CA may = fail to deliver OCSP stapled response. While this will result in = degraded performance, the ramifications of failing to deliver = short-lived certificates is even worse: the service that depends on = those certificates would go down entirely. Thus, ensuring independence = from CAs for short-lived certificates is critical to the uptime of a = service." >=20 >=20 > Carrick >=20 >=20 >=20 > > On Feb 5, 2020, at 12:36 PM, internet-drafts@ietf.org = wrote: > >=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the Transport Layer Security WG of the = IETF. > >=20 > > Title : Delegated Credentials for TLS > > Authors : Richard Barnes > > Subodh Iyengar > > Nick Sullivan > > Eric Rescorla > > Filename : draft-ietf-tls-subcerts-06.txt > > Pages : 15 > > Date : 2020-02-05 > >=20 > > Abstract: > > The organizational separation between the operator of a TLS = endpoint > > and the certification authority can create limitations. For = example, > > the lifetime of certificates, how they may be used, and the > > algorithms they support are ultimately determined by the > > certification authority. This document describes a mechanism by > > which operators may delegate their own credentials for use in TLS, > > without breaking compatibility with peers that do not support this > > specification. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ = > >=20 > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-subcerts-06 = > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06 = > >=20 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-06 = > >=20 > >=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.ietf.org = . > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ = > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls = >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_9820E1AB-9745-405F-9CDC-CB09BCF4885C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Great! I'll push it on over and continue reviewing.


On Feb 14, 2020, at 11:36 AM, Nick Sullivan = <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:

Carrick,

Thank you for reading the document and identifying an = embarrassingly difficult to parse motivating paragraph (with an annoying = unclosed parenthesis to boot). You've correctly identified the = meaning it was trying to convey and we'll happily review this as a PR = here: https://github.com/tlswg/tls-subcerts/. I've noticed a = few other readability issues in the document, if you find anything else, = we'll happily look at those too.

Nick

On Thu, Feb 13, 2020 at 3:46 PM Carrick = Bartle <cbartle891=3D40icloud.com@dmarc.ietf.org> = wrote:
TL;DR: I find it difficult to = understand the second-to-last paragraph of the Introduction, so I took a = stab at revising it. Let me know if I should put it in a pull = request.


This is the paragraph I'm referring to:

"These dependencies cause problems in practice. Server operators often = want to create short-lived certificates for servers in low- trust zones = such as Content Delivery Network (CDNs) or remote data centers. This = allows server operators to limit the exposure of keys in cases that they = do not realize a compromise has occurred. The risk inherent in = cross-organizational transactions makes it operationally infeasible to = rely on an external CA for such short- lived credentials. In Online = Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate = Status extension type ocsp [RFC8446], if an operator chooses to talk = frequently to the CA to obtain stapled responses, then failure to fetch = an OCSP stapled response results only in degraded performance. On the = other hand, failure to fetch a potentially large number of short lived = certificates would result in the service not being available, which = creates greater operational risk."

Here are my issues with it:

- I think OCSP is being brought up here as an example of a way that = dependence on a CA can go wrong, but that isn't really made explicit.

- I'm not sure what "only" means in "only in degraded performance." Is = it "the worst that can happen is just degraded performance" or "it can = result only in degraded performance, as opposed to better performance"? = At first I thought it was the latter, but after reading the subsequent = sentence, I realized it was probably the former.

- The use of "On the other hand" sounds like the rest of the sentence is = going to describe a way that failure to receive something from a CA = resulted in better performance, which obviously would be silly.

Taking all these points together, here's my suggestion for a revision to = make what I think the thrust of the paragraph is more clear:

"These dependencies cause problems in practice. Server operators often = want to create short-lived certificates for servers in low-trust zones = such as Content Delivery Network (CDNs) or remote data centers. This = allows server operators to limit the exposure of keys in cases where = they do not realize a compromise has occurred. But the risk inherent in = cross-organizational transactions makes it operationally infeasible to = rely on an external CA for such short-lived credentials. For instance, = in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., = using the Certificate Status extension type ocsp [RFC8446]), a CA may = fail to deliver OCSP stapled response. While this will result in = degraded performance, the ramifications of failing to deliver = short-lived certificates is even worse: the service that depends on = those certificates would go down entirely. Thus, ensuring independence = from CAs for short-lived certificates is critical to the uptime of a = service."


Carrick



> On Feb 5, 2020, at 12:36 PM, internet-drafts@ietf.org 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 WG of the = IETF.
>
>        Title          =  : Delegated Credentials for TLS
>        Authors        =  : Richard Barnes
>                  =         Subodh Iyengar
>                  =         Nick Sullivan
>                  =         Eric Rescorla
>       Filename        : = draft-ietf-tls-subcerts-06.txt
>       Pages          =  : 15
>       Date          =   : 2020-02-05
>
> Abstract:
>   The organizational separation between the operator of a = TLS endpoint
>   and the certification authority can create = limitations.  For example,
>   the lifetime of certificates, how they may be used, and = the
>   algorithms they support are ultimately determined by = the
>   certification authority.  This document describes = a mechanism by
>   which operators may delegate their own credentials for = use in TLS,
>   without breaking compatibility with peers that do not = support this
>   specification.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ >
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-subcerts-06
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-06<= /a>
>
>
> 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
_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_9820E1AB-9745-405F-9CDC-CB09BCF4885C-- From nobody Fri Feb 14 12:03:13 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D40120B3F for ; Fri, 14 Feb 2020 12:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 drjR6eLUAvgV for ; Fri, 14 Feb 2020 12:03:10 -0800 (PST) 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 28A67120A99 for ; Fri, 14 Feb 2020 12:03:10 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 01EK1sdx027779; Fri, 14 Feb 2020 20:03:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=ugsWFbFouvO7SyvatnUKXYbI//XXrWAtFJgcLPls3dw=; b=AgRDRpzPfS7K79L2aUeC1HKdPXN88/xxaWPQQZ9Tk9+u/QjILi6uhw9/Y9xXGPeo9I5n fa6wtwUS318/O0Wlrbky5A/uybgQMNYhO+r5yZZCT5KX1m/IxZeHKa8CNwdNJ7XOETL3 mqxhAFCM0ENYFGPwxTJKhDMa1th4JhSKIt/MHfAQkIfzI6AQUR3UBYiNV4xMCWgCjYOJ QnmBGNJB7cpLzUJfbz0e12k42OLub9oIrfB4Z/kpyONAV3qQmGPaR4f5ZLkodvgn1nzL r6XZ5PPzldo+Xmhxi4sdoWAh7m7bGrWHkiTRHZh/tsW3hkPyN31V8gqYP6eaKj7oWfEv ZQ== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2y45815hj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Feb 2020 20:03:09 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01EJpT1m028532; Fri, 14 Feb 2020 15:03:08 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2y5bdcnb28-1; Fri, 14 Feb 2020 15:03:08 -0500 Received: from akamai.com (bos-lpczi.santaclara.corp.akamai.com [172.19.105.107]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 1063421F86; Fri, 14 Feb 2020 20:03:07 +0000 (GMT) Date: Fri, 14 Feb 2020 12:03:07 -0800 From: Benjamin Kaduk To: Michael D'Errico Cc: tls@ietf.org Message-ID: <20200214200306.GA27885@akamai.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=619 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002140143 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-14_07:2020-02-14, 2020-02-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 bulkscore=0 adultscore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 clxscore=1011 spamscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 mlxlogscore=641 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002140145 Archived-At: Subject: Re: [TLS] New direction for TLS? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 20:03:12 -0000 Hi Mike, On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote: > Hi, > > It's been a long time since I posted to this list but saw that the charter is being updated and wanted to share an idea I had a while ago but have not found the time to work on. The TL;DR is to deprecate TLS and rebuild security on top of DTLS. With DTLS, you have encrypted packets, so think of them as the new IP and build TCP on top of that. It'd be like making the internet run on TCP/DTLS instead of TCP/IP, so most of the work is already done. I think this is all I need to say to get the idea across, but I can add detail if needed. This sounds really similar to QUIC (https://datatracker.ietf.org/wg/quic/documents); perhaps you could take a look and try to describe any differences between your idea and what's being done there? -Ben From nobody Fri Feb 14 13:01:32 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF6D1201DE for ; Fri, 14 Feb 2020 13:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 wjm1SuWZBeek for ; Fri, 14 Feb 2020 13:01:27 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4C71200C3 for ; Fri, 14 Feb 2020 13:01:26 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id a6so12213498wme.2 for ; Fri, 14 Feb 2020 13:01:26 -0800 (PST) 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=zarNP9Orl6u/RR1Lpuug/VVf32lIXGrMszIevbed80E=; b=nUmypx1hcf/a9qLpOEQkNaFhQYJZPaIsGA6ydAMJp87Ux7tjoBIdAste3xqZ5FiGwL ziDgg6jttHkDg2bKM9z6SUX1pn8d33YWLBtmfx/mM8yGex1GxXX8OFwWcFHhoDlc/oLR as64wJpFF/rLgA9yJYZrG+d8sZh8swVwTfL+D/GYdeGo3hWKfS6RdVy52dLMZVOffQL6 3o3MP52Y8K4iaM8opt248wJJ/LReDRZ3KBGhiBFWrYymISsuOeA7qbqwX3KW4VpCg8UH ESJ7ATftgtEY+spfJ9wuX9v2Nz/kCvHT2M7mmLTyNUxx5p+LywcVrFg+hHu2paxQLtoX rA0A== 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=zarNP9Orl6u/RR1Lpuug/VVf32lIXGrMszIevbed80E=; b=YSXXV2OuQVdOYzKOqhM1MtbZtTVLZWeUXV3R13wSbBezrtSlavSpFObFUF3KMhL0gM DPEOzNgJyQf6GTkgO8VXDXlBHyVmimA9nWDup+cIRFyXD5DUf+Kv2/Rt8+sK1RZ7v0wF lOXYJcjZeCScqJ/neDUqJdAybGm8RtH25/7l7+X7Z15QcD6rxKEHOLKtwozMQuQbfaW/ zA5DZc+WIy8FZB9HKE7YIndxRpNUXjoFMlHcSTk9wre8O13+N0ly0FDej15/rFchq+OB c3YFZoDVa1wF94KkaAJ+WHrHXHljMFjDWZB46uGp+N0YMKo0DUEQQ8ePsYqDhPLtTMno 3RhQ== X-Gm-Message-State: APjAAAUb8nXZsJpJQNQ0NJS6sRxaSdXeitcXhSMpLsR9uC7GI3dSxYsO nXEIsnkv74LJABbvfJNTMGk= X-Google-Smtp-Source: APXvYqwxtfKdqaJOEGaIMxGtq21HyXVI74JmpzcuBKaUMZ9dTFJB6GoR33I/8NCM9xGKy7Ub5tg0bQ== X-Received: by 2002:a05:600c:2406:: with SMTP id 6mr6522787wmp.30.1581714085364; Fri, 14 Feb 2020 13:01:25 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id r6sm8676687wrq.92.2020.02.14.13.01.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Feb 2020 13:01:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Yoav Nir In-Reply-To: <20200214200306.GA27885@akamai.com> Date: Fri, 14 Feb 2020 23:01:22 +0200 Cc: Michael D'Errico , tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <81B6235D-EC94-4477-890C-D51D0EBEF5BE@gmail.com> References: <20200214200306.GA27885@akamai.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [TLS] New direction for TLS? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 21:01:30 -0000 > On 14 Feb 2020, at 22:03, Benjamin Kaduk wrote: >=20 > Hi Mike, >=20 > On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote: >> Hi, >>=20 >> It's been a long time since I posted to this list but saw that the = charter is being updated and wanted to share an idea I had a while ago = but have not found the time to work on. The TL;DR is to deprecate TLS = and rebuild security on top of DTLS. With DTLS, you have encrypted = packets, so think of them as the new IP and build TCP on top of that. = It'd be like making the internet run on TCP/DTLS instead of TCP/IP, so = most of the work is already done. I think this is all I need to say to = get the idea across, but I can add detail if needed. >=20 > This sounds really similar to QUIC If it=E2=80=99s TCP (rather than HTTP) on top of the encryption layer, = it sounds more like transport-mode IPsec. That gives you encrypted = packets. The difference is whether the authentication and encryption is part of = the service provided by the OS (like IP) or part of the application. Yoav From nobody Fri Feb 14 16:17:51 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FCA1201CE for ; Fri, 14 Feb 2020 16:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 Nd3dataUP_Uv for ; Fri, 14 Feb 2020 16:17:46 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEA412006F for ; Fri, 14 Feb 2020 16:17:46 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id c16so12456982ioh.6 for ; Fri, 14 Feb 2020 16:17:46 -0800 (PST) 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=kDaQe9JJBio5UKAHFvO9uZfjlkjH+itmAVbrKey65aM=; b=WOETj/0wX7N4itzI6KkoQEQ0DR3eUgJuQp9aSBvN1s4KhXthHT49Ja65tAiEVwzCjB jyUZZO4+wcOU4KBLQ0v1JCkoupcJU9Z09OXWVwLIHwiMAqh+2Iitkv3qCNBSwbFsbpRG LNEIp/rct1UkSckKyuuX0x3oZ/hgJ1g1voGrJeMo/ukTiSGHsdPir4MDn1wjflYxRVDz Guwu59T2qxjuZ9pO99oPVi8fTBTfrW1xqsSIjlImXpG61uXXn2AhtVxazq3P7sHG/0lo ZpWAKxa8525JpZ1sHHBo209TrroWcZB+HLLPTdbk41z7RNyzyArLGSTqWadFB4w4HTp+ /I2w== 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=kDaQe9JJBio5UKAHFvO9uZfjlkjH+itmAVbrKey65aM=; b=UFPyhBOlfhJcalAfCY37/jrT/DFIVLiNH1LUbbnJh5vUhXjaywytsjICUi+me1D5w0 C5lcrgrOob45xlbBTBBmmNtJg01XEGd7QZt+qnPIc1yHWsk96461Q8AEeas1bE4F0qdh 4NW4g/L+4CDDLUhJaHNWsCZo4zGAgPDQobh7nNBVKdsr/cugWRJYqD0Sg/ZBh5zYGYV1 Zs+j3aIKcucaGBWfet5NdSSPBqhEeM5tNwSE9IOQmoDcEIjGHgW41gfJBmFX+ErBZyaZ JIoCPG4nGc5m2EFoX0RMeChZJbd5EcsMEPhWfggn95XiteYdsGcu7qOEBNUTgTlVorUn yl/w== X-Gm-Message-State: APjAAAV/Qs0IK2eFCveA8Q3gM1xYI3EBfO98FUc47uQaxyPcLoE8EjlE 4aaiBT0B78AOwKgyg+gFQVfrSID4yAhyPQZvUn3XQTXh6uM= X-Google-Smtp-Source: APXvYqyFRlum0GuBfeeOnsPVau7JLRms4nZtcA4jc8cFblECS93wMUcbO5sAjq0UPVlpycZApiMVv/+ZKiOr7/v4NjM= X-Received: by 2002:a6b:ec08:: with SMTP id c8mr4400179ioh.257.1581725864950; Fri, 14 Feb 2020 16:17:44 -0800 (PST) MIME-Version: 1.0 From: Rob Sayre Date: Fri, 14 Feb 2020 16:17:29 -0800 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000050036a059e9240ac" Archived-At: Subject: [TLS] ESNI/ECHO updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 00:17:49 -0000 --00000000000050036a059e9240ac Content-Type: text/plain; charset="UTF-8" Hi, Are there any updates to ESNI/ECHO to share as a draft or an update? It's been a few months, so just wondering (even if there's not much to say). thanks, Rob --00000000000050036a059e9240ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Are there any updates to=C2=A0E= SNI/ECHO to share as a draft or an update?

It'= s been a few months, so just wondering (even if there's not much to say= ).

thanks,
Rob

--00000000000050036a059e9240ac-- From nobody Sat Feb 15 00:55:44 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24788120071 for ; Sat, 15 Feb 2020 00:55:43 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 zEFB8jCNKdkB for ; Sat, 15 Feb 2020 00:55:40 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5A712006D for ; Sat, 15 Feb 2020 00:55:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id CB71722F; Sat, 15 Feb 2020 10:55:35 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id TuuJ735CC0lU; Sat, 15 Feb 2020 10:55:32 +0200 (EET) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 673D472; Sat, 15 Feb 2020 10:55:30 +0200 (EET) Date: Sat, 15 Feb 2020 10:55:29 +0200 From: Ilari Liusvaara To: Nick Sullivan Cc: "" Message-ID: <20200215085529.GA1659089@LK-Perkele-VII> References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> <20200209140242.GA1489626@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 08:55:43 -0000 On Fri, Feb 14, 2020 at 11:27:36AM -0800, Nick Sullivan wrote: > Ilari, > > Thank you for identifying these errors in the document. There was no > intention to allow the client to constrict the server certificate's > algorithm with the delegated_credential extension, and no intention to > restrict the delegated credential's algorithm with the > signature_algorithms. Let me propose some minor text changes to address the > issues. > > As a reminder, the CertificateVerify.algorithm is constrained by the > signature_algorithms > extension, as stated in RFC 8446: > > If the CertificateVerify message is sent by a server, the signature > algorithm MUST be one offered in the client's "signature_algorithms" > extension unless no valid certificate chain can be produced without > unsupported algorithms (see Section 4.2.3 > ). > > > > Original text from 4.1.2.: > > The expected_cert_verify_algorithm fields MUST be of a > type advertised by the client in the SignatureSchemeList and are > considered invalid otherwise. Clients that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. > > > proposed text: > > The expected_cert_verify_algorithm field MUST be of a > type advertised by the client in the SignatureSchemeList and is > considered invalid otherwise. Clients that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. The section number looks incorrect (it is about client authentication) and the original looks to be copied from the new text. Did you mean section 4.1.1 (Server authentication) and: OLD: The algorithm and expected_cert_verify_algorithm fields MUST be of a type advertised by the client in the SignatureSchemeList and are considered invalid otherwise. Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. NEW: The expected_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList and is considered invalid otherwise. Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. > As for the second point, we did not add the capability for the server to > advertise a different set of signature_algorithms for client authentication > other than the one advertised via the "signature_algorithms" extension. > This was perhaps an oversight. I propose that we add that capability and > I'd be happy to propose a PR to that effect. > > The new text of 4.3.2. would look something like: > > A server which supports this specification SHALL send an > "delegated_credential" extension in the CertificateRequest message > when requesting client authentication. The body of the > extension consists of a SignatureSchemeList. If the server receives a > delegated credential without indicating support in its > CertificateRequest, then the server MUST abort with an > "unexpected_message" alert. > > ... > > The algorithm field MUST be of a > type advertised by the server in the "signature_algorithms" extension > of the CertificateRequest message and the expected_cert_verify_algorithm > field MUST be of a type advertised by the client in the SignatureSchemeList > and considered invalid otherwise. Clients that receive invalid > delegated credentials MUST terminate the connection with an > "illegal_parameter" alert. > There seems to be no section 4.3.2 (or 4.3 for that matter). Did you mean section 4.1.2 (Client authentication)? The latter proposed paragraph seems like it says "client" in two places it should say "server", did you mean: The algorithm field MUST be of a type advertised by the server in the "signature_algorithms" extension of the CertificateRequest message and the expected_cert_verify_algorithm field MUST be of a type advertised by the server in the SignatureSchemeList and considered invalid otherwise. Servers that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. -Ilari From nobody Sat Feb 15 08:39:56 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36841200D7 for ; Sat, 15 Feb 2020 08:39:54 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 Kn6Mu7dtXvPd for ; Sat, 15 Feb 2020 08:39:52 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A76712008A for ; Sat, 15 Feb 2020 08:39:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 46837C9F7 for ; Sat, 15 Feb 2020 18:39:49 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id K-nBWvACZHMy for ; Sat, 15 Feb 2020 18:39:48 +0200 (EET) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 69AEC7A for ; Sat, 15 Feb 2020 18:39:47 +0200 (EET) Date: Sat, 15 Feb 2020 18:39:46 +0200 From: Ilari Liusvaara To: "" Message-ID: <20200215163946.GA1687026@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 16:39:55 -0000 On Wed, Feb 12, 2020 at 02:26:21PM -0500, Douglas Stebila wrote: > Dear TLS working group, > > We would like to request the working group adopt > draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as > a working group item. We have updated the draft based on feedback > we've received over the past few months, including from our > presentations at IETF 104 and 105, and think the current version > represents the view of the WG to date. > > https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ Some comments and related sidenotes: - If additional round trips are to be avoided, the public key size should be kept low so client hello does not grow so large that significant amount of servers barf on it. [LANGLEY] notes that 3300 bytes was about the maximum they could use. - That TLS 1.3 does not talk about client-side key reuse seems to be a mistake. It for example says SHOULD NOT reuse tickets, with rationale that also appiles to client side keys. - The draft talks about "any KEM used in this document". Which sounds odd, given that this document does not define any KEMs. - The reasons to not reuse public keys, even with CCA-secure KEMs, impiles that the relevant benchmarks are: * Combined key generation and decapsulation time. * Single-thread encapsulation time. * Peak memory usage by key generation and decapsulation. * Peak memory usage by encapsulation. * Size of public key * Size of ciphertext For KEMs used as key exchanges, using decapsulation time alone is perverse due to problems with key reuse, again even with CCA-secure KEMs. - Assigning specific range for Hybrid KEX. What is the use of that? The server recognizing that client supports Hybrid KEX even if there is no algorithm overlap? What the server would do with that information? - The draft has specific data structures. This only makes sense if other drafts are to refer to it or are intended to copy the data structure definitions. It also has processing algorithms, which only makes sense to me if other drafts are to refer to this one. Being informational, referencing could lead to downref, but this should not be a significant problem. - I do not view supporting large public keys or ciphertexts as realistic. Making larger extension would mean extending TLS to support "extended extensions". This would impily extra RTT for most key exchanges, altough it could be absorbed into extra RTT for client missing speculation on group (so it would be 2-RTT). Referencing external key is not acceptable: * The client would need to have a way to publish its key. * Strong incentives to reuse keys, despite problems doing so. * The server would need to be able to fetch keys, which causes difficult security issues. * The server would need to freeze the handshake for obtaining the public key. Unless the server API already supports handshake freezing, adding that capability is going to be virtually impossible (let alone the annoyance of implementing it). Additionally, even if blowing the practical ClientHello size limit (4kB or so) would already force additional round trip, the >64kB key algorithms have such big keys that result would be severe performance degradation. So in summary, unless all the smaller algorithms are broken beyond repair (which is highly unlikely due to complexity reasons) the >64kB keys should not be accomodiated. And even in that case, external keys are not acceptable. - Avoiding duplication of key shares is difficult problem: * Using traditional scheme is easy on client and server, but can result in duplication of shares. And even single duplication of PQ share is signficant. * Making ServerHello key_share a list is clean specification-wise, but might be anything but clean implementation-wise. * Making separate extension could cause issues when doing hybrid -> next-gen transition in future. * Backreferences could be annoying to implement. - On resumption, I do not think there are currently any restrictions in TLS 1.3 about DH groups used in resumption? If that is indeed the case, I suspect that implementing such restrictions might turn to be annoying to implement. - On failures: All CCA-secure key exchanges have negligible failure rates (because anything else leads to attacks). And even if one considers non-CCA key exchanges from the NISTPQC 2nd round, AFAIK all of them meant for actual use have failure rate <10^-9. - On schemes vulernable to chosen-ciphertext attack, SIDH (which underlies SIKE) key can be recovered bit-by-bit (even with just guess oracle, instead of full decryption oracle) by sending suitable chosen ciphertexts. This takes a few hundred samples for full key recovery. -Ilari From nobody Sat Feb 15 08:50:24 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1650012008A for ; Sat, 15 Feb 2020 08:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 Bg4F6JbN18qe for ; Sat, 15 Feb 2020 08:50:20 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C71120058 for ; Sat, 15 Feb 2020 08:50:18 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id t17so10689938ilm.13 for ; Sat, 15 Feb 2020 08:50:18 -0800 (PST) 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=mo5/LiLjCwn/D1sCR9/MXcCNeYQeZiPtkWIBMIiKvjw=; b=tlKgp3LlkO2P/8qwN4RG5sv7kEBamyu7bDAcj8kiS/Y70EXQfqFTQIB1A97RqQmBj3 a5xZpIe4B8sN/tOtpVhp9+oZQZoMLr7so0DRLA7V6eaM1vSAYxOYp9zqWIvrDdFhg5DC dSz5YYsyzJugtQl/AhLaGramTLvT0dU+SuZGumrMdwO7Aq3gt8Sif3rCSv9OmfYaetsA OxP7HyWPvGeUc6WD5NUJ2koVNrjXkiQr7lMhBwnNJpnuT9Bb3drQDPQTEiNt0xTMpsp7 bncplHmz2wFQEmP35kVheoXIaYkdOALlhZbQ6r9eKXZwxLI5lv9Vpyo8nzj+yz21vJ7W RK5g== 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=mo5/LiLjCwn/D1sCR9/MXcCNeYQeZiPtkWIBMIiKvjw=; b=QxrS1d5iWCHsgB4FBRvgy1qN4eDV7pfer5sQMmQhEjmrY7lnQm4Vk058ancTX7msmf fLqR9XTSK2ivBBozld/q/3oRviIdKe7yY88zotl/6sXIdF/CH3JRtnzLXizDYKyOrGWB MdK8CscNJry9cATMEiRTiBVIhEAR2eCeEbBBBm9ClnW41xUMv/iXyoR+D9dd+k3nKyHh iSIwSdHlte+701fvSkid4Z5QOY7Owzz5gB0h3nko6wFfD5GBkOruHsBI21TdxDO8I8Bp D0sun+KtQ+AQxav8L2fnvLGo7HwYv/uopsRr6a2rRpZjblYyrPZWS+etor3XJFOq7L4s aQdw== X-Gm-Message-State: APjAAAXDjPgsU53T6hq7K6StO3KBdKfMW2DuQQ4syoGk8ZWHNZYJCHgt XvaUG7tZyCTONTGxgoyaG5zjF1KRPCq7Yjskv4TiyDCn X-Google-Smtp-Source: APXvYqyFcnf1tDJu2vxQONGOdNMn/PS6EsfVhTvJS26urXBafh/MOVXKHY3ZydHIrJbzhDBmJeif8DVev6zj3UNoQqw= X-Received: by 2002:a92:cc04:: with SMTP id s4mr7860615ilp.193.1581785411197; Sat, 15 Feb 2020 08:50:11 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a4f:f462:0:0:0:0:0 with HTTP; Sat, 15 Feb 2020 08:50:10 -0800 (PST) In-Reply-To: References: From: Loganaden Velvindron Date: Sat, 15 Feb 2020 20:50:10 +0400 Message-ID: To: Douglas Stebila Cc: "" , Shay Gueron Content-Type: multipart/alternative; boundary="0000000000008b9ff4059ea01dbc" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 16:50:23 -0000 --0000000000008b9ff4059ea01dbc Content-Type: text/plain; charset="UTF-8" I support adoption and I'm willing to review the document. On Wednesday, February 12, 2020, Douglas Stebila wrote: > Dear TLS working group, > > We would like to request the working group adopt > draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as > a working group item. We have updated the draft based on feedback > we've received over the past few months, including from our > presentations at IETF 104 and 105, and think the current version > represents the view of the WG to date. > > https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ > > Cheers, > > Douglas > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000008b9ff4059ea01dbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption and I'm willing to review the document.

On We= dnesday, February 12, 2020, Douglas Stebila <douglas@stebila.ca> wrote:
Dear TLS working group,

We would like to request the working group adopt
draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3&= quot;, as
a working group item.=C2=A0 We have updated the draft based on feedback
we've received over the past few months, including from our
presentations at IETF 104 and 105, and think the current version
represents the view of the WG to date.

https://datatracker.ietf.org/doc/draft-stebila-tl= s-hybrid-design/

Cheers,

Douglas

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--0000000000008b9ff4059ea01dbc-- From nobody Sat Feb 15 16:54:30 2020 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 08627120103; Sat, 15 Feb 2020 16:54:26 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <158181446568.16529.2271170848149741985@ietfa.amsl.com> Date: Sat, 15 Feb 2020 16:54:26 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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 Feb 2020 00:54:26 -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 WG of the IETF. Title : Importing External PSKs for TLS Authors : David Benjamin Christopher A. Wood Filename : draft-ietf-tls-external-psk-importer-03.txt Pages : 11 Date : 2020-02-15 Abstract: This document describes an interface for importing external PSK (Pre- Shared Key) into TLS 1.3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-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 Sat Feb 15 16:57:37 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4EC1200E3 for ; Sat, 15 Feb 2020 16:57:36 -0800 (PST) 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 (2048-bit key) header.d=heapingbits.net header.b=BlSTfoRE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LQC7qgnN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhEMYDUYX2vM for ; Sat, 15 Feb 2020 16:57:34 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E428712006F for ; Sat, 15 Feb 2020 16:57:34 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 198344F7 for ; Sat, 15 Feb 2020 19:57:34 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Sat, 15 Feb 2020 19:57:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=HimJg8utFqE/foIPZtnD18j9vt3Ai0H LlgFtnnduYXk=; b=BlSTfoRECnhM3gmzjH4hlsrfOuuJgK8DaMqDWF7zMg3HE6A n78nkBiejaucAQOsQS6i9zCP1MkBfr/X/DFTGei76zUTvS+wUcJ7dt1HSAMPlyi5 QIH3xSMTxayfOaTaLI5CHvDrnNQM3Y8hK8jVqS85H480KmNJyVKvvPy0ArJGvNa/ /RWbnQs1trJzZFLr2IwcC1J2PNeeQ+ysH2MrboKDfsKERAIIeAuOuHmRbbbQkL4S eyGPgbAMkKP9p3J5wAPXppvPdd0e/Wh2+7QFV2GywBquEEz9bBLPq6JDxCQByaT4 dSBmOoPEJsQ4cjgI22BH3kHf0+DCgDiemEG8y7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=HimJg8 utFqE/foIPZtnD18j9vt3Ai0HLlgFtnnduYXk=; b=LQC7qgnNXErhsi4HZmappS 85Bs0CF6umJdirYTPXwrRYCEI4aP62deQmhUg6MyB7QiyM5k23n4HcniZCrZt9SW j46ztRtccqlTf1sT/inJjLtoSOTfJK2KS9/ZJJA0dLu5bCVlMaYxXqKp6T5yEhkW MKDWf1xkmEhE091nft04MjPZVUc/RWquiw2w+WxwTFAEtxXwioDi8pbYTw3wNpmW 3refhpDoYrN660nglQ5Ge5Hs+iWFn1MvvDFlsmNcy/zLh9peoEBgNB4bmxekp+mE xTC2DBN+pqoVzh/wk4ttB0IE0Djwa0wqyvlGT31mIZDBgzg9eHYNTZ7Qz5oJbb3g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeefgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehh vggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 849D13C00A1; Sat, 15 Feb 2020 19:57:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <158181446568.16529.2271170848149741985@ietfa.amsl.com> References: <158181446568.16529.2271170848149741985@ietfa.amsl.com> Date: Sat, 15 Feb 2020 16:57:13 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 00:57:36 -0000 This update fixes some formatting issues and removes a lingering TODO (pointing to analysis, which shouldn't block things). Best, Chris (no hat) On Sat, Feb 15, 2020, at 4:54 PM, internet-drafts@ietf.org 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 WG of the IETF. > > Title : Importing External PSKs for TLS > Authors : David Benjamin > Christopher A. Wood > Filename : draft-ietf-tls-external-psk-importer-03.txt > Pages : 11 > Date : 2020-02-15 > > Abstract: > This document describes an interface for importing external PSK (Pre- > Shared Key) into TLS 1.3. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-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/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Feb 15 23:32:38 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D38712002F for ; Sat, 15 Feb 2020 23:32:36 -0800 (PST) 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=mnot.net header.b=n0duv000; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sO6KUHt1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5AEzM9HOJur for ; Sat, 15 Feb 2020 23:32:34 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8270A120026 for ; Sat, 15 Feb 2020 23:32:34 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 1C08239A for ; Sun, 16 Feb 2020 02:32:34 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 16 Feb 2020 02:32:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=OECwHw0voM5rRSkeM+KCjGefkRWXAq7x1SZbyKC0+kU=; b=n0duv000 Y1ySh2jN48WcTA9VSLCbyS6tTuiz/qafNy9iKrljZWJhCDfnyd1czqzO53YjP2mv JoPWmufOHrTHp+U5iaQncucQ3kEyk+6omGmfox1pUKuP+68TT1iUZ/0mD5Fkkaqk SRft4A5CYZS2DeMO90FjOlz7ZIrxhcprIqlzWkOs6zElbZPxCMx8MhCKOKXxO8TU j6mVSEk2Nuq6K1BeAQBKeqw30tZzKZIc5BMU3+3b1w3C841ibxsFy4HiUAlRXqlR uVwJJyGtpY6VssqKXoC/wwXlsHtS3qivvwuReLWa75XrYmj3biulWFqkp0IWv98+ GrALCrtR3uvpAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=OECwHw0voM5rRSkeM+KCjGefkRWXA q7x1SZbyKC0+kU=; b=sO6KUHt18amsr+4iD8Ajj9cPN+/tr8xp7XSTsNlwIFXID hZnZsFCjDJw8niHS4PQ6GyX6iglOk8iRarj7V8j87NxGUE4EAGyk/n8AFThxduPl GcU5CDSGXcvy3InnUXMr3gsEPE0KTOfQ0NbVpImjUTW0n1cEyP9vpp0e27NQojXX I9UrC3PPKRxH4CGhZ6ID0YNn9C3E8v19Fz2EHYwwDRaDnHrYByj/E2F+NW/5ytMx a1iZfinabBjikCk9pV36FYUIr9fNItrhnYsnpeRtnzrDLQSulikSvTnbgxvFGpML k/raPKP/6dL5ORDqf1JxBr/8AjBgySORriBBcTIpQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeefgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepudeikedriedurdegjedruddtjeenucevlhhushht vghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [168.61.47.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 8840A3280062 for ; Sun, 16 Feb 2020 02:32:33 -0500 (EST) Content-Type: multipart/alternative; boundary="===============3255699195048811220==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200216073233.8840A3280062@mailuser.nyi.internal> Date: Sun, 16 Feb 2020 02:32:33 -0500 (EST) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 07:32:36 -0000 --===============3255699195048811220== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/tls-flags (+0/-1/=F0=9F=92=AC0) 1 issues closed: - 63 or 247? https://github.com/tlswg/tls-flags/issues/1=20 Pull requests ------------- * tlswg/dtls-conn-id (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #71 Corrected reference to the RRC draft (1 by boaks) https://github.com/tlswg/dtls-conn-id/pull/71=20 * tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Revise an introductory paragraph for greater clarity. (by cbartle891) https://github.com/tlswg/tls-subcerts/pull/51=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============3255699195048811220== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday February 16, 2020

Issues

tlswg/tls-flags (+0/-1/=F0=9F=92=AC0)

1 issues closed:

Pull requests

tlswg/dtls-conn-id (+0/-0/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

Repositories tracked by this digest:

--===============3255699195048811220==-- From nobody Sun Feb 16 09:48:12 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66131120091 for ; Sun, 16 Feb 2020 09:48:11 -0800 (PST) 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=pobox.com header.b=ou9TlmDa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YRaBfoy1 Received: 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-mrR-Fsg_E5 for ; Sun, 16 Feb 2020 09:48:10 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7F412001B for ; Sun, 16 Feb 2020 09:48:09 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 07744698; Sun, 16 Feb 2020 12:48:07 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Sun, 16 Feb 2020 12:48:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pobox.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=mar2016.fm; bh=lFAMI70dzKttqfgR3oR7xQ3r EDeXYjZJbyRrT0G8rew=; b=ou9TlmDaqVAF/3IDagn4BMh2N7EgJ7VH/NrBZzZ0 1/CDgFQLMJX9hlJR/AVDGkHmVS4R14PxG1daR5SKr4YlUlNNOlmuJQUZRZFo5kgf 9hh9QeaB2sMs8U+SDuVADGAXvOOm0owzSjmhuIhZu3t92zKZa3Q65TCm/sOnWg/k CLQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lFAMI7 0dzKttqfgR3oR7xQ3rEDeXYjZJbyRrT0G8rew=; b=YRaBfoy1n4AN2ELN8gjnhc GHDzli1aWUJVceuQ6HiqoiUr/B32IfK8wx/qIfaKGScFlPnWdXeFysATPBXFJgOn mJuH4EOVw197OcrY9RimQsdvntKv8vs+lZlzy9TlQoxL1Qjq65PJGDhViym6sP1X KF6T2hqRFeQIA3WnmdDkZN5UNIA3uSLqRzIGsRUuQHSAGo+2FPvcFq/g7Vr4kiRz zAYJy17iT5e30V+gUBio+jGr4ZOldveXWZW4iW7zgvL5lJgkCX0NqJe48Ow5UBpT 16DZZJ1aT5OT+4ZUeswJxdhvhpUwbM3J2reD09Sfb/ZEUDcGU5oCkayLGWKKksbQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeeggddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfoihgt hhgrvghlucffkdfgrhhrihgtohdfuceomhhikhgvqdhlihhsthesphhosghogidrtghomh eqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmihhkvgdqlhhishhtsehpohgsohigrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 71BE5660069; Sun, 16 Feb 2020 12:48:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <9a237888-68ea-4290-89d6-12ed9a320890@www.fastmail.com> In-Reply-To: <20200214200306.GA27885@akamai.com> References: <20200214200306.GA27885@akamai.com> Date: Sun, 16 Feb 2020 12:47:45 -0500 From: "Michael D'Errico" To: "Benjamin Kaduk" Cc: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] New direction for TLS? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 17:48:11 -0000 Hi, It looks like QUIC is even better than what I proposed. Thank you for suggesting it. Mike On Fri, Feb 14, 2020, at 15:03, Benjamin Kaduk wrote: > Hi Mike, > > On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote: > > Hi, > > > > It's been a long time since I posted to this list but saw that the charter is being updated and wanted to share an idea I had a while ago but have not found the time to work on. The TL;DR is to deprecate TLS and rebuild security on top of DTLS. With DTLS, you have encrypted packets, so think of them as the new IP and build TCP on top of that. It'd be like making the internet run on TCP/DTLS instead of TCP/IP, so most of the work is already done. I think this is all I need to say to get the idea across, but I can add detail if needed. > > This sounds really similar to QUIC > (https://datatracker.ietf.org/wg/quic/documents); perhaps you could take a look > and try to describe any differences between your idea and what's being done > there? > > -Ben > From nobody Mon Feb 17 18:32:36 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32274120170 for ; Mon, 17 Feb 2020 05:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 Bg5Dg5ptr-SG for ; Mon, 17 Feb 2020 05:00:59 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C881200E5 for ; Mon, 17 Feb 2020 05:00:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3D042BE2F; Mon, 17 Feb 2020 13:00:55 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GHVX5YyJg1n; Mon, 17 Feb 2020 13:00:55 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F236BBE24; Mon, 17 Feb 2020 13:00:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1581944455; bh=BGZybO2du9n+tcpa+w87TyCmxodPgRzhafmDR5HdDR0=; h=To:References:From:Subject:Date:In-Reply-To:From; b=M5V45WmTQCKA7ezbnuGKzRuln0Tbg2Fz2BCb7atknr7a0t8JbZimzpQJnOHIKS/qK hPPkbgc8ZR5E4t91fj/FOic1rsV4f1rb4SRZYPd246HZhqx/zxx7F2hKMBBH1uNkNb m+4l/EyunD0alCd7qToZZ4YBI2K6Y0+mDGtO3rys= To: Rob Sayre , "TLS@ietf.org" References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <412affff-54a9-d244-886b-ea44ad972c94@cs.tcd.ie> Date: Mon, 17 Feb 2020 13:00:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bG3aix4pPpFZWCOxWJGQEgiwEltnIIyvs" Archived-At: Subject: Re: [TLS] ESNI/ECHO updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 13:01:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bG3aix4pPpFZWCOxWJGQEgiwEltnIIyvs Content-Type: multipart/mixed; boundary="pWi5lOG86tvCKk2x8Rca2QOJovDopFwV8"; protected-headers="v1" From: Stephen Farrell To: Rob Sayre , "TLS@ietf.org" Message-ID: <412affff-54a9-d244-886b-ea44ad972c94@cs.tcd.ie> Subject: Re: [TLS] ESNI/ECHO updates References: In-Reply-To: --pWi5lOG86tvCKk2x8Rca2QOJovDopFwV8 Content-Type: multipart/mixed; boundary="------------FE897D021C7FFBF072F0D0D8" Content-Language: en-US This is a multi-part message in MIME format. --------------FE897D021C7FFBF072F0D0D8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/02/2020 00:17, Rob Sayre wrote: > Hi, >=20 > Are there any updates to ESNI/ECHO to share as a draft or an update? I'm also interested:-) >=20 > It's been a few months, so just wondering (even if there's not much to = say). I did some initial hacking on a branch of my openssl fork to see how hard the inner CH stuff might be. [1] Turns out it's doable but there are some wrinkles with handling extensions that might be good to discuss on the list to improve our chances of interop. There are some notes at [2] - the ones I think might benefit from list discussion are: - PSKs - I ended up just putting the PSK extension in the inner CH (with binder calculated over the inner CH) and putting no PSK extension in the outer CH at all. That seems right for tickets, but I'm not sure for cases where the PSK isn't a ticket. Trying to support PSKs in both inner and outer seems pretty complex and likely hard to use as well. - I'm not sure what to do about the TLS key share (and supported groups) - in principle it might make sense for those to vary between inner and outer CH, but that'd not be very useful today, and could need a lot more code changes (I've not yet played with it) - if it made sense to punt on that for the first version of an ECHO RFC and just say different key shares MUST NOT be used in inner and outer that might be good, even if it's a little smelly. OTOH, it might be better to bite the bullet now, for better support for the split mode scenario, e.g. if the "front" server had more up to date algorithms or something. - I implemented support for varying ALPN between inner and outer and that wasn't hard and seems to make sense. A consequence is that the EncryptedExtensions with the ALPN from the server then also need (record layer) padding. Hopefully, supporting different inner and outer ALPNs doesn't need much list discussion but it would be a change from earlier drafts. And one might wanna put something in the HTTPSSVC or ESNIConfig for this I suppose, not sure. - inner CH padding - we're no longer just padding the (E)SNI but the entire inner CH so the padded_length in the ESNIConfig kinda makes (even:-) less sense to me. I'm not sure if padding the outer CH is still needed for something though. Note that I've only looked at the extensions supported by the OpenSSL build I'm using - there are some more in the IANA registry that might or might not need a bit of thought. And there are a bunch where it might (in principle) make sense for 'em to vary between inner and outer CH, but where I suspect there'd not be enough payoff to call for it to be supported. (Some of those are noted at [2].) Cheers, S. [1] https://github.com/sftcd/openssl/tree/encch [2] https://github.com/sftcd/openssl/blob/encch/esnistuff/echo.md#extension-s= pecific-handling >=20 > thanks, > Rob >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------FE897D021C7FFBF072F0D0D8 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------FE897D021C7FFBF072F0D0D8-- --pWi5lOG86tvCKk2x8Rca2QOJovDopFwV8-- --bG3aix4pPpFZWCOxWJGQEgiwEltnIIyvs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5KjoUACgkQWrL68XsX K+oUBA//XqywvbgHXVYDa3jWjsGioTAh4EqClxTXzGWgIDVl+FUuu4neoQgNoSMi dcDBpOLbshPir3Pgtkv7mae1wW2mXKDf7+Ln7ZRn3NYstTmXXdClENr56Ssl/gFL yEowI3HGYqVNlPQiXxeesm2fZc6twFWOWUxYeQ45pMI3O5QOmxV8kFmCM5HggItJ UNTCVXro9Q8C4W0Kh9oSNqX9SOMHO/U6Gd443Qsilw1K83h3J+rQaZiKZDsGWxFu 6jn88qD0PQ5ibrWaGo1dOYeTV4uZU74xapnJWPu4b5psHBlNFGWDVur23HYK9/yH yD8n7uHIYA+q7B6bZCgpWp3/QGn3meG8biA0ur1tqDKQw+s0nN3W+y13uMVIz2k8 bsPmDWcMNvKkEMUBPSQy44R/7CyxF08vx9qoXsrnKBXqD/4WUwUO6XvU7POK2W4e lWz3Nl6DqbHnvPm0vLEWmw3/0nzj+nyH5p2hXSKDhBofazK7z2oCisDmX6x+Team 3ehaT4iNuW1u23iEAi18mMMdWgnc6Aa0480ghed0jObXlb0CGM34Ku1Q1b4ttUqU QDCa6VrgsWgy7zE+EWYPmrBljipGs5JPRzgUdNm2Rp7kl2pjLeiiJKb580EKMUp2 VaicNqrrRm8nzZHi/W43XnV6/kyb4dds2NmcU9rHWdZOpmGxctQ= =2yEj -----END PGP SIGNATURE----- --bG3aix4pPpFZWCOxWJGQEgiwEltnIIyvs-- From nobody Mon Feb 17 18:40:33 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF61512007C for ; Mon, 17 Feb 2020 08:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 lNMZrJhtwxli for ; Mon, 17 Feb 2020 08:33:59 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60B4120018 for ; Mon, 17 Feb 2020 08:33:59 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id d9so12404778qte.12 for ; Mon, 17 Feb 2020 08:33:59 -0800 (PST) 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=+LKzp6f+oH8LT/SdWT6L9q2IVO6A67lJ3sHKNVPRS7Y=; b=MxuMQ2AkUkRDImS1pjt86w6kfSszcScItbMAQ4rlNNj/2Wfsa5rhPyveaELZLXcvbg 7PRjPao5srbin3FogAfTF31nyICeMjH+WgRMrUwSoOf2uog4oDeh3RwQP1hX69d0kkgc hiOQqb/9xx401gIghk03BP+0XI+drKltlO7GgAZgs6KgIZPI/DDPVCkg0nxdno6eNai5 xKkdQKr+JWZBbqwtgx031IS7uo5PDpwGECUnpjXOdqczFJqvzFw1KFenkF6qxblgI4O5 6LGa3M6XIgCF11qZjeA8R30wLW/PYond6TEPf5UQOn2Gs5tDcRtLZdr7XCjJGJ5s9xy6 fSxw== 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=+LKzp6f+oH8LT/SdWT6L9q2IVO6A67lJ3sHKNVPRS7Y=; b=pTpzZUFUuEChcIjFmRgwupCJNuRiUPjITF1/dBoSPayvQo0lgCsw3D8fhVqjeEPXYr SZZYo11XdEDWxk3+hdqMnNAecb6Dqaw5bECLNHGCihe+AK3k0NqWrDsdU1DRNCQfdR3o uEFyv/vePP7FbmXtdmgq2FNDZWk9tgBilL8mDA19t/EYyHIzp/U9LNcm9gD3E59UBSVV pzyxrPZBw0O3gC0Vgb/onjgeEzVekEnEPqWYo8D9FmVvF7ei3wJ6BcIAk4FlRTcDFnL+ p9PsJ2xopqXql4uJfHhG0oDDtqIXU49p7Fz0ZU0pnNzAe2gaky/0CHuukY0/V0n0GUgw MYwQ== X-Gm-Message-State: APjAAAWGxAeUGLIWK8wh18v2WpK3zjjLOKISDLSckcOmoco8v4iQjVXh DYPzPhAygQDislNTbJRZMv4jA0q3 X-Google-Smtp-Source: APXvYqwubTOIPWsPd/2JiAusjkY5SebJu85p7p63HyKO5+FJFtR1J4488nvb0yysgpkSj2qyd2zyWQ== X-Received: by 2002:aed:2e03:: with SMTP id j3mr13862700qtd.365.1581957237875; Mon, 17 Feb 2020 08:33:57 -0800 (PST) Received: from laptop-picard.coleridge (CPE881fa12cf37b-CMa84e3fc93e50.cpe.net.cable.rogers.com. [99.250.203.26]) by smtp.gmail.com with ESMTPSA id x126sm476080qkc.42.2020.02.17.08.33.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Feb 2020 08:33:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Douglas Stebila In-Reply-To: <20200215163946.GA1687026@LK-Perkele-VII> Date: Mon, 17 Feb 2020 11:33:55 -0500 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200215163946.GA1687026@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 16:34:03 -0000 Thanks for the feedback and observations, Ilari. =20 Regarding: > - The draft talks about "any KEM used in this document". Which sounds > odd, given that this document does not define any KEMs. Good point; I've updated the language to say "any KEM used in the manner = described in this document" and pushed it to my working copy on Github. Regarding the rest of the points, I don't think any of them are specific = actions to take, but are good points about the overall direction. =20 Douglas > On Feb 15, 2020, at 11:39, Ilari Liusvaara = wrote: >=20 > On Wed, Feb 12, 2020 at 02:26:21PM -0500, Douglas Stebila wrote: >> Dear TLS working group, >>=20 >> We would like to request the working group adopt >> draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as >> a working group item. We have updated the draft based on feedback >> we've received over the past few months, including from our >> presentations at IETF 104 and 105, and think the current version >> represents the view of the WG to date. >>=20 >> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ >=20 > Some comments and related sidenotes: >=20 > - If additional round trips are to be avoided, the public key size > should be kept low so client hello does not grow so large that > significant amount of servers barf on it. [LANGLEY] notes that > 3300 bytes was about the maximum they could use. >=20 > - That TLS 1.3 does not talk about client-side key reuse seems to > be a mistake. It for example says SHOULD NOT reuse tickets, with > rationale that also appiles to client side keys. >=20 > - The draft talks about "any KEM used in this document". Which sounds > odd, given that this document does not define any KEMs. >=20 > - The reasons to not reuse public keys, even with CCA-secure KEMs, > impiles that the relevant benchmarks are: >=20 > * Combined key generation and decapsulation time. > * Single-thread encapsulation time. > * Peak memory usage by key generation and decapsulation. > * Peak memory usage by encapsulation. > * Size of public key > * Size of ciphertext >=20 > For KEMs used as key exchanges, using decapsulation time alone is > perverse due to problems with key reuse, again even with CCA-secure > KEMs. >=20 > - Assigning specific range for Hybrid KEX. What is the use of that? > The server recognizing that client supports Hybrid KEX even if there > is no algorithm overlap? What the server would do with that > information? >=20 > - The draft has specific data structures. This only makes sense if > other drafts are to refer to it or are intended to copy the data > structure definitions. It also has processing algorithms, which only > makes sense to me if other drafts are to refer to this one. >=20 > Being informational, referencing could lead to downref, but this > should not be a significant problem. >=20 > - I do not view supporting large public keys or ciphertexts as > realistic. >=20 > Making larger extension would mean extending TLS to support > "extended extensions". This would impily extra RTT for most key > exchanges, altough it could be absorbed into extra RTT for client > missing speculation on group (so it would be 2-RTT). >=20 > Referencing external key is not acceptable: >=20 > * The client would need to have a way to publish its key. > * Strong incentives to reuse keys, despite problems doing so. > * The server would need to be able to fetch keys, which causes > difficult security issues. > * The server would need to freeze the handshake for obtaining > the public key. Unless the server API already supports handshake > freezing, adding that capability is going to be virtually > impossible (let alone the annoyance of implementing it). >=20 > Additionally, even if blowing the practical ClientHello size limit > (4kB or so) would already force additional round trip, the >64kB > key algorithms have such big keys that result would be severe > performance degradation. >=20 > So in summary, unless all the smaller algorithms are broken beyond > repair (which is highly unlikely due to complexity reasons) the >> 64kB keys should not be accomodiated. And even in that case, external > keys are not acceptable. >=20 > - Avoiding duplication of key shares is difficult problem: >=20 > * Using traditional scheme is easy on client and server, but can > result in duplication of shares. And even single duplication of > PQ share is signficant. > * Making ServerHello key_share a list is clean specification-wise, > but might be anything but clean implementation-wise. > * Making separate extension could cause issues when doing > hybrid -> next-gen transition in future. > * Backreferences could be annoying to implement. >=20 > - On resumption, I do not think there are currently any restrictions > in TLS 1.3 about DH groups used in resumption? >=20 > If that is indeed the case, I suspect that implementing such > restrictions might turn to be annoying to implement. >=20 > - On failures: All CCA-secure key exchanges have negligible failure > rates (because anything else leads to attacks). And even if one > considers non-CCA key exchanges from the NISTPQC 2nd round, AFAIK > all of them meant for actual use have failure rate <10^-9. >=20 > - On schemes vulernable to chosen-ciphertext attack, SIDH (which > underlies SIKE) key can be recovered bit-by-bit (even with just > guess oracle, instead of full decryption oracle) by sending suitable > chosen ciphertexts. This takes a few hundred samples for full key > recovery. >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Feb 18 17:06:02 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB48712085A for ; Tue, 18 Feb 2020 17:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 VZs-EvOR7oCz for ; Tue, 18 Feb 2020 17:05:51 -0800 (PST) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8CE12085D for ; Tue, 18 Feb 2020 17:05:51 -0800 (PST) Received: by mail-qv1-xf30.google.com with SMTP id s6so1039564qvq.4 for ; Tue, 18 Feb 2020 17:05:51 -0800 (PST) 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=mLn922Pg0n/qHkTwBPwZnVocNR6e9MeiXU73i0iQ6PQ=; b=eZBrqmOYE/iiUKiWwuHj9ZTakunamth6zpz7FRRpxfGS2SR/RA01idbpyP3TTgAlKP MJ0epyQu3Wvsyg4WyWGKBF5Tu+vm+5ymvidQzmMm9FbP6f78zTYsjmvWFj/d/9NAvV9A K8LAEJ4hrQVmOYrDQxumpyYdADkzwsQCbhPWo= 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=mLn922Pg0n/qHkTwBPwZnVocNR6e9MeiXU73i0iQ6PQ=; b=giAWlf/Eks/iFM+E7kQ1o+WbX7Kgmri/B2pGNNLWsgxyYcDnP5HfZzOW0p596p6gff hw9om11NO7nO6x9Sa6kgRM70usPNrhprp4fjxMRzkMmk5RiGkqnWYMu/4dA5edCFaqRB dSVaFkVk6kuKPDIWFseZX31mPse24VsN0OtDmIZPU9FUy3ux6h8H+5ihixQpJBGmk201 I35igMvgDUal9KXOWAVFPIpJyRb52WOV6InvvmFJyfXQkqPV1kFkH3DCUBQIyWscHFUY NVBG5DbN4TDTaIGh3uo/spOuN/dbJz1eAZ3VDJtxRUPE4fphK9W5eFrXX8br2RC34Dxo 03pA== X-Gm-Message-State: APjAAAWzfJ8zP9p2AQJumut6N9np9bO3xNfoW3/kD+hRUlgpBD74K10/ ELSv2WKH0V9byYo00g/jD0XMzVsA84nonQ== X-Google-Smtp-Source: APXvYqwGUn/hKN64BpGkOSjE8Tda4kuwhV47dgb67s8BSslDZTtbnrk6yTLROkV3CWb/g8QB0SfPUA== X-Received: by 2002:a05:6214:1708:: with SMTP id db8mr18839423qvb.129.1582074350665; Tue, 18 Feb 2020 17:05:50 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id y21sm129556qto.15.2020.02.18.17.05.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Feb 2020 17:05:50 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Tue, 18 Feb 2020 20:05:48 -0500 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] TLS@IETF017: Agenda Topics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 01:05:54 -0000 The TLS WG will be meeting @ IETF 107 in Vancouver. To help the chairs = get a better handle on how arrange our sessions, please send in your = agenda requests to tls-chairs@ietf.org. Along with your request please = provide an estimate for how much time you will need. Please note that = we will prioritize existing WG items. Cheers, Chris, Joe, and Sean= From nobody Tue Feb 18 22:39:27 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556D71200B1 for ; Tue, 18 Feb 2020 22:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 FTvTKbmVRBEN for ; Tue, 18 Feb 2020 22:39:24 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88195120074 for ; Tue, 18 Feb 2020 22:39:24 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id s24so25182771iog.5 for ; Tue, 18 Feb 2020 22:39:24 -0800 (PST) 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=K0zaNnIysrExMOzQHV6mMe6GdDa+ilT9JhQQtzIUR+g=; b=eiTEnF3xl5l8stcJUCkyhVZJmIfoZCMyYhspI8ljJx4f7bCKNS3hJvQowbTV4mPasi MU3AmtceJsHVJGF6ViDLjg5dp0cmKoG4j87RMwYGYtVRMlSUZStBiqOBBcS2oKj1G6jS x+TpssFHl5sCojTc+nRGcUqnIZpJGthv47pwL1DZEniMS2mRJj1xiaYtXH+/IefjhV8Y ZSUwmDIQiTfkqurEclyC196tV4dA0QvZc24czOxv5sT30onvDQ/1vzcoWrUefGXy3Ili 41pci9fX7/5OeZFg0Wubj6u/Y+5earKZzT1h6VMvZmNUcE1fM2ntZFSKckNIg9V7mmNW F7pA== 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=K0zaNnIysrExMOzQHV6mMe6GdDa+ilT9JhQQtzIUR+g=; b=QDg6G6juuxj0CUgrXJR2Ano285dws0I0FsW+NGFVL7ubUfiIeW1DeEfesCYnWOF9aH K3gyuAiVhTRhD/2zo5zVA+ndZKhMk3TFaeyhs874x2vEKTJRc9EktbO+1y7daJvgDCn8 fvOVdMMuCkR/diVZgmhppfMfspbZePJMy5sQ+OUxpZrG3onl2FygSoLiyCZAlADA1//g 8zIjdUO6uGr5sAe4PiU5GCn3KqOGjjbvfHkt0aFI2cPdGrDstzDtY98y1J6XqDrofYTg w9mjbAdH4C+/OS+WPFqLv65a33RwC0n1JPFWJ2DWP0s2ncn1ODzI9Qeg7j7/RxQePezg qHpA== X-Gm-Message-State: APjAAAX1oYmjn/4r+mmjFZ7rICP27EB6IFGo+Mi2ztJlp5K22VVH8zjL +GWy9RPz36B2iFwvbmvcPLoV2N8pBfzWdWjb/5M= X-Google-Smtp-Source: APXvYqy+mIlgAAzabFCGYmuHuDc2/B6xz15IRY3oq0Un4piuzLfpSnYnpspJAFIhPTjLJ9uYhTHVoG7L4C2vxz90olo= X-Received: by 2002:a02:cd82:: with SMTP id l2mr19196966jap.103.1582094363563; Tue, 18 Feb 2020 22:39:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Tue, 18 Feb 2020 22:39:12 -0800 Message-ID: To: Sean Turner Cc: TLS List Content-Type: multipart/alternative; boundary="0000000000008a9c7c059ee80c90" Archived-At: Subject: Re: [TLS] TLS@IETF017: Agenda Topics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 06:39:26 -0000 --0000000000008a9c7c059ee80c90 Content-Type: text/plain; charset="UTF-8" Hi, On Tue, Feb 18, 2020 at 5:06 PM Sean Turner wrote: > The TLS WG will be meeting @ IETF 107 in Vancouver. To help the chairs get > a better handle on how arrange our sessions, please send in your agenda > requests to tls-chairs@ietf.org. Along with your request please provide > an estimate for how much time you will need. Please note that we will > prioritize existing WG items. > Has the TLS WG been re-chartered? thanks, Rob --0000000000008a9c7c059ee80c90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Tue, Feb 18, 2020 at 5:06 PM Sean Turner <sean@sn3rd.com> wr= ote:
The TLS WG = will be meeting @ IETF 107 in Vancouver. To help the chairs get a better ha= ndle on how arrange our sessions, please send in your agenda requests to tls-chairs@ietf.org<= /a>.=C2=A0 Along with your request please provide an estimate for how much = time you will need.=C2=A0 Please note that we will prioritize existing WG i= tems.

Has the TLS WG been re-chartered?=

thanks,
Rob

<= /div> --0000000000008a9c7c059ee80c90-- From nobody Wed Feb 19 06:36:03 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105281200B5 for ; Wed, 19 Feb 2020 06:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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=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 z3FdS0TQZ0JK for ; Wed, 19 Feb 2020 06:35:56 -0800 (PST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A2912008D for ; Wed, 19 Feb 2020 06:35:55 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id s6so266863qvq.4 for ; Wed, 19 Feb 2020 06:35:55 -0800 (PST) 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=B6DzvnyM1Yz9CWOzEzKWIpQCwcrt/vlqKCVD5ZYl53c=; b=Zbi5U1tv/zT5jGNh7I0/YFNzVvhH1VPpCjnXeSt3bnsZ0X/IrWtZ1veHHzhWoATGqD 0G8zaXcdxkdkf6kc0atAMXuWgIporUsDaQvqnv74hUwWwTF9IpBEMWRtv627TCLFy2xW 4/vyg/4xSVTrRtkIJ3hd13X3A6+Hjlet+8Z/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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B6DzvnyM1Yz9CWOzEzKWIpQCwcrt/vlqKCVD5ZYl53c=; b=VuVjoyZM3X6dtFX/9PDNgccXV4ygyqhvu6St/lku2AkNzLHTWQaQw0qP77Ig6w1RGM /9nbKsBmv0KIugnctM6De8srFMwYHUj3TwuPcc1cjVXU3NH7b84yZSzQXNMzjSPBnA+P GWZQcfgb0zyyu6S8W76pfu9sjFf2Edp/haOgaRZTN64EY9I7IEHuI/kwXQ1+a1TeHSWs lNvnQdKmzQSDRWZ6izFDfMeeAw4y8uXYg9tMZwCyeJMt7uSMeY/LeytKzIfCN4xu+60E RArBceoEaBkLqLDoxvondy68tTvzjtjPEcH3EpDvhwW8cJy2da+eSGpzWzLK2WDLyits PSuA== X-Gm-Message-State: APjAAAVuiAocNf4G73IGMl/CEyvPA8yvx60qOgWHLd1HVRP1PVOkaKAb wF4ioZrKvPyAU2hfWy/GfCluTA== X-Google-Smtp-Source: APXvYqyByqucHGVNzYwgeSEDAvVL00H2t/W1XccrcatDryllWPfOK9UUMNmDjPGtbi7kKe3IRjo/QQ== X-Received: by 2002:ad4:4e50:: with SMTP id eb16mr21269776qvb.34.1582122954567; Wed, 19 Feb 2020 06:35:54 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id v50sm77661qtb.20.2020.02.19.06.35.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2020 06:35:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: Date: Wed, 19 Feb 2020 09:35:53 -0500 Cc: TLS List Content-Transfer-Encoding: quoted-printable Message-Id: <2777CD65-8021-4E6D-95D7-10247B9D7A69@sn3rd.com> References: To: Rob Sayre X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] TLS@IETF017: Agenda Topics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 14:35:59 -0000 > On Feb 19, 2020, at 01:39, Rob Sayre wrote: >=20 > Hi, >=20 > On Tue, Feb 18, 2020 at 5:06 PM Sean Turner wrote: > The TLS WG will be meeting @ IETF 107 in Vancouver. To help the chairs = get a better handle on how arrange our sessions, please send in your = agenda requests to tls-chairs@ietf.org. Along with your request please = provide an estimate for how much time you will need. Please note that = we will prioritize existing WG items. >=20 > Has the TLS WG been re-chartered? >=20 > thanks, > Rob Rechartering is in process. It=E2=80=99s with the IESG now. spt= From nobody Wed Feb 19 12:11:17 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152491201E3 for ; Wed, 19 Feb 2020 12:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 d8p5nla0XAL0 for ; Wed, 19 Feb 2020 12:11:13 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228AF12016E for ; Wed, 19 Feb 2020 12:11:13 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id 1so707823uao.1 for ; Wed, 19 Feb 2020 12:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QlwHCa3S2n/dTUNM8AaG9bJYhJ4ebkBkoUmGCbB4v+I=; b=jFB8O0BmfCYSfayiIDMOxddi8E+AzQ61KrIfLg3RlQAyFgIJcqqXN+O6Rq7ES1ltEa oqZ9tsyawzni56yppkFhbIVs2Cg2pV8wxMMnF+iHlM0qpA39WDu+ajk7NWdK3KrdwGeh i1yYzfyzDaWSzAMJoppVsuek7UYGPDhk0sTh8= 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=QlwHCa3S2n/dTUNM8AaG9bJYhJ4ebkBkoUmGCbB4v+I=; b=Krs9JErByR0TMIKQP5AuI9dlqacGTUJiX9TKIaW8D+0FJMz3lWLAs9R2TkBTqtKbyV r8/vipGJziNmHPuy22gVNikC5iTv2C5K6h0Cz7g4QjhhIoU3res39rq9nVb4BzLcsg4f 5A/1Wk+orXGovY2rU3M7krV9J7Wp0cC8REWHFwKR67ciXZRrenPVLl7gMKK1kTuofsFU 19I3DM5G5Di+SM7jYLvgHxYuqCs7R2xj4lMmaZ7IY1cWQrLO90zZz/oUuCYhfSaXFief hJ5pvVT6bWmKQBgCdp4Z8fYcNGF2qMzkAzC0z9aPRzh5k2lS4GnjU25R6xuv08TyYCgm TM0g== X-Gm-Message-State: APjAAAVQ6BxAuN1X9tzqbuZtrdj7HnlX0IWlr1vWvAXgnktQMYQxPyhx Kg7WxvVGeVJdj5FwOBX7fFmXZkzPHbpxTzVRGR2ekw== X-Google-Smtp-Source: APXvYqx38kKhFELxu8FxSdKDw/P8lfYCWjAUJ7sVk9Bea6nLyyKu02Cu7YK0Bu3YPRefxYhBX9ywJUGYz+xpcQI9ab0= X-Received: by 2002:ab0:7025:: with SMTP id u5mr14232372ual.52.1582143071951; Wed, 19 Feb 2020 12:11:11 -0800 (PST) MIME-Version: 1.0 References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> <20200209140242.GA1489626@LK-Perkele-VII> <20200215085529.GA1659089@LK-Perkele-VII> In-Reply-To: <20200215085529.GA1659089@LK-Perkele-VII> From: Nick Sullivan Date: Wed, 19 Feb 2020 12:09:39 -0800 Message-ID: To: Ilari Liusvaara Cc: "" Content-Type: multipart/alternative; boundary="000000000000c9ce41059ef3637f" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 20:11:16 -0000 --000000000000c9ce41059ef3637f Content-Type: text/plain; charset="UTF-8" Good catches on the section number and server/client questions. Confirming below. Here's a PR with the proposed change: https://github.com/tlswg/tls-subcerts/pull/54 On Sat, Feb 15, 2020 at 12:55 AM Ilari Liusvaara wrote: > On Fri, Feb 14, 2020 at 11:27:36AM -0800, Nick Sullivan wrote: > > Ilari, > > > > Thank you for identifying these errors in the document. There was no > > intention to allow the client to constrict the server certificate's > > algorithm with the delegated_credential extension, and no intention to > > restrict the delegated credential's algorithm with the > > signature_algorithms. Let me propose some minor text changes to address > the > > issues. > > > > As a reminder, the CertificateVerify.algorithm is constrained by the > > signature_algorithms > > extension, as stated in RFC 8446: > > > > If the CertificateVerify message is sent by a server, the signature > > algorithm MUST be one offered in the client's "signature_algorithms" > > extension unless no valid certificate chain can be produced without > > unsupported algorithms (see Section 4.2.3 > > ). > > > > > > > > Original text from 4.1.2.: > > > > The expected_cert_verify_algorithm fields MUST be of a > > type advertised by the client in the SignatureSchemeList and are > > considered invalid otherwise. Clients that receive invalid delegated > > credentials MUST terminate the connection with an "illegal_parameter" > > alert. > > > > > > proposed text: > > > > The expected_cert_verify_algorithm field MUST be of a > > type advertised by the client in the SignatureSchemeList and is > > considered invalid otherwise. Clients that receive invalid delegated > > credentials MUST terminate the connection with an "illegal_parameter" > > alert. > > The section number looks incorrect (it is about client authentication) > and the original looks to be copied from the new text. Did you mean > section 4.1.1 (Server authentication) and: > > OLD: > > The algorithm and expected_cert_verify_algorithm fields MUST be of a > type advertised by the client in the SignatureSchemeList and are > considered invalid otherwise. Clients that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. > > NEW: > > The expected_cert_verify_algorithm field MUST be of a > type advertised by the client in the SignatureSchemeList and is > considered invalid otherwise. Clients that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. > > Yes, 4.1.1. I'll put this into a PR. > > > As for the second point, we did not add the capability for the server to > > advertise a different set of signature_algorithms for client > authentication > > other than the one advertised via the "signature_algorithms" extension. > > This was perhaps an oversight. I propose that we add that capability and > > I'd be happy to propose a PR to that effect. > > > > The new text of 4.3.2. would look something like: > > > > A server which supports this specification SHALL send an > > "delegated_credential" extension in the CertificateRequest message > > when requesting client authentication. The body of the > > extension consists of a SignatureSchemeList. If the server receives a > > delegated credential without indicating support in its > > CertificateRequest, then the server MUST abort with an > > "unexpected_message" alert. > > > > ... > > > > The algorithm field MUST be of a > > type advertised by the server in the "signature_algorithms" extension > > of the CertificateRequest message and the > expected_cert_verify_algorithm > > field MUST be of a type advertised by the client in the > SignatureSchemeList > > and considered invalid otherwise. Clients that receive invalid > > delegated credentials MUST terminate the connection with an > > "illegal_parameter" alert. > > > > There seems to be no section 4.3.2 (or 4.3 for that matter). Did you mean > section 4.1.2 (Client authentication)? Yes, 4.1.2 is the right section. > The latter proposed paragraph > seems like it says "client" in two places it should say "server", did you > mean: > > The algorithm field MUST be of a > type advertised by the server in the "signature_algorithms" extension > of the CertificateRequest message and the expected_cert_verify_algorithm > field MUST be of a type advertised by the server in the > SignatureSchemeList > and considered invalid otherwise. Servers that receive invalid > delegated credentials MUST terminate the connection with an > "illegal_parameter" alert. > Yes, that's correct. > > > > -Ilari > --000000000000c9ce41059ef3637f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good catches on the section number and server/client = questions. Confirming below.

Here's a PR with = the proposed change:

On Sat, Feb = 15, 2020 at 12:55 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Fri, Feb 14, 2020 at 11:27:36AM -0800,= Nick Sullivan wrote:
> Ilari,
>
> Thank you for identifying these errors in the document. There was no > intention to allow the client to constrict the server certificate'= s
> algorithm with the delegated_credential extension, and no intention to=
> restrict the delegated credential's algorithm with the
> signature_algorithms. Let me propose some minor text changes to addres= s the
> issues.
>
> As a reminder, the CertificateVerify.algorithm is constrained by the > signature_algorithms
> extension, as stated in RFC 8446:
>
>=C2=A0 =C2=A0 If the CertificateVerify message is sent by a server, the= signature
>=C2=A0 =C2=A0 algorithm MUST be one offered in the client's "s= ignature_algorithms"
>=C2=A0 =C2=A0 extension unless no valid certificate chain can be produc= ed without
>=C2=A0 =C2=A0 unsupported algorithms (see Section 4.2.3
> <https://tools.ietf.org/html/rfc8446#secti= on-4.2.3>).
>
>
>
> Original text from 4.1.2.:
>
>=C2=A0 =C2=A0 The expected_cert_verify_algorithm fields MUST be of a >=C2=A0 =C2=A0 type advertised by the client in the SignatureSchemeList = and are
>=C2=A0 =C2=A0 considered invalid otherwise.=C2=A0 Clients that receive = invalid delegated
>=C2=A0 =C2=A0 credentials MUST terminate the connection with an "i= llegal_parameter"
>=C2=A0 =C2=A0 alert.
>
>
> proposed text:
>
>=C2=A0 =C2=A0 The expected_cert_verify_algorithm field MUST be of a
>=C2=A0 =C2=A0 type advertised by the client in the SignatureSchemeList = and is
>=C2=A0 =C2=A0 considered invalid otherwise.=C2=A0 Clients that receive = invalid delegated
>=C2=A0 =C2=A0 credentials MUST terminate the connection with an "i= llegal_parameter"
>=C2=A0 =C2=A0 alert.

The section number looks incorrect (it is about client authentication)
and the original looks to be copied from the new text. Did you mean
section 4.1.1 (Server authentication) and:

OLD:

=C2=A0 =C2=A0The algorithm and expected_cert_verify_algorithm fields MUST b= e of a
=C2=A0 =C2=A0type advertised by the client in the SignatureSchemeList and a= re
=C2=A0 =C2=A0considered invalid otherwise.=C2=A0 Clients that receive inval= id delegated
=C2=A0 =C2=A0credentials MUST terminate the connection with an "illega= l_parameter"
=C2=A0 =C2=A0alert.

NEW:

=C2=A0 =C2=A0The expected_cert_verify_algorithm field MUST be of a
=C2=A0 =C2=A0type advertised by the client in the SignatureSchemeList and i= s
=C2=A0 =C2=A0considered invalid otherwise.=C2=A0 Clients that receive inval= id delegated
=C2=A0 =C2=A0credentials MUST terminate the connection with an "illega= l_parameter"
=C2=A0 =C2=A0alert.

Yes, 4.1.1. I'll put this into a PR.=C2=A0
<= 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">
> As for the second point, we did not add the capability for the server = to
> advertise a different set of signature_algorithms for client authentic= ation
> other than the one advertised via the "signature_algorithms"= extension.
> This was perhaps an oversight. I propose that we add that capability a= nd
> I'd be happy to propose a PR to that effect.
>
> The new text of 4.3.2. would look something like:
>
>=C2=A0 =C2=A0 A server which supports this specification SHALL send an<= br> >=C2=A0 =C2=A0 "delegated_credential" extension in the Certifi= cateRequest message
>=C2=A0 =C2=A0 when requesting client authentication.=C2=A0 The body of = the
>=C2=A0 =C2=A0 extension consists of a SignatureSchemeList.=C2=A0 If the= server receives a
>=C2=A0 =C2=A0 delegated credential without indicating support in its >=C2=A0 =C2=A0 CertificateRequest, then the server MUST abort with an >=C2=A0 =C2=A0 "unexpected_message" alert.
>
> ...
>
>=C2=A0 =C2=A0 The algorithm field MUST be of a
>=C2=A0 =C2=A0 type advertised by the server in the "signature_algo= rithms" extension
>=C2=A0 =C2=A0 of the CertificateRequest message and the expected_cert_v= erify_algorithm
>=C2=A0 =C2=A0 field MUST be of a type advertised by the client in the S= ignatureSchemeList
>=C2=A0 =C2=A0 and considered invalid otherwise.=C2=A0 Clients that rece= ive invalid
>=C2=A0 =C2=A0 delegated credentials MUST terminate the connection with = an
>=C2=A0 =C2=A0 "illegal_parameter" alert.
>

There seems to be no section 4.3.2 (or 4.3 for that matter). Did you mean section 4.1.2 (Client authentication)?=C2=A0

Yes, 4.1.2 is the right section.
=C2=A0
The latter proposed paragraph
seems like it says "client" in two places it should say=C2=A0 &qu= ot;server", did you
mean:

=C2=A0 =C2=A0The algorithm field MUST be of a
=C2=A0 =C2=A0type advertised by the server in the "signature_algorithm= s" extension
=C2=A0 =C2=A0of the CertificateRequest message and the expected_cert_verify= _algorithm
=C2=A0 =C2=A0field MUST be of a type advertised by the server in the Signat= ureSchemeList
=C2=A0 =C2=A0and considered invalid otherwise.=C2=A0 Servers that receive i= nvalid
=C2=A0 =C2=A0delegated credentials MUST terminate the connection with an =C2=A0 =C2=A0"illegal_parameter" alert.

=
Yes, that's correct.=C2=A0



-Ilari
--000000000000c9ce41059ef3637f-- From nobody Thu Feb 20 09:50:54 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EC4120169 for ; Thu, 20 Feb 2020 09:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 FC4Ym6Ebm04E for ; Thu, 20 Feb 2020 09:50:49 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE5C120071 for ; Thu, 20 Feb 2020 09:50:48 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id a9so3013845wmj.3 for ; Thu, 20 Feb 2020 09:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=W2Bpmfe4IgSYUPilvO6nS9XpptU9nn2o5WA7Lq6xfpo=; b=GKAbwyZw+MMkUsO7AyHgk7ERo73GGrpCW1wCFXw1BtWC/U1XG8f8VME9qbCUwRfu1v MmsWLSSnYC+09NtziR+gjY9rLMlV4NeHYRv/lXQrs9NvYmIfRo55ZEVXdJUZ9JqzzyUv IcFzA31oTbWDd4bOxllw1fPpCMSRSzCU98lb+K5kpNdYdxsOrFumA9s/poZ8v0SXZ9xu 5/rLIGXzm9O8Av+a6SZFA8zN9dFIix8kre3EJE3PwfYc56Y8WFSs7ya8+RZnwk1jM61B 3hGaNjGAWiqz4dEvnDkpQQe+mKPgKAmKnxC8d4ut0T8dpxSIw8Z5H36ApTEhkWy6Nj6A +4sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=W2Bpmfe4IgSYUPilvO6nS9XpptU9nn2o5WA7Lq6xfpo=; b=RZRTvIfkqVI00vUvbP6aOqCYUrhGyPFc670ynkxYuG71SUToaKIQyhah2qsegbRsoU AYeWc534gg8+VpGLpGVi5c0JhL2HtQQ8qK9YApAUOHNeTN/MczhshirSiCSrIcHalNJz WxeAK3WSg2CMJiMGhZWvGlDJL/qfsPOs+BzhmmvTGVW2IYZHkOjOYzgAPt1kGlo6G7Pc UkbGRJ5EhINa7/eCo6htCDG+tNFw0R9FT3+z4NTIYhR45hE+JeAaKfor8O9uMcaGCNed F6Y2F825fA75z4oILPogrg5SpP2o9kopKnwNj2LhCWMCT15X+e2skkSJybvecNEi3tx+ l11w== X-Gm-Message-State: APjAAAUhizEy4ocWdm4TDMaLn3Rw1SzsUM7hCYauQk9QzUYM5N0jvHg1 dpfrECQBC+Pp27AaUA1k/Jcs3Fkt X-Google-Smtp-Source: APXvYqzvE0l7iPtayNQsNTR5iQOzoLlj/kHUe99eEThNJ7ZbsfU2G4Ner432vuEVWQunm1caMXN+pQ== X-Received: by 2002:a1c:e246:: with SMTP id z67mr6001663wmg.52.1582221046985; Thu, 20 Feb 2020 09:50:46 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l6sm25458wmg.42.2020.02.20.09.50.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Feb 2020 09:50:46 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_EC8B8FF9-5AA2-455E-B0E9-73225F148677" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: Date: Thu, 20 Feb 2020 19:50:44 +0200 To: "" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [TLS] tls-flags Guidance on Allocating Bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Feb 2020 17:50:51 -0000 --Apple-Mail=_EC8B8FF9-5AA2-455E-B0E9-73225F148677 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Following the discussion last month, especially my message from 31-Jan = [1], I=E2=80=99ve submitted a PR [2] for guidance on allocating the TLS = flags with the goal to minimize the size of the typical extension. Please comment here or in github. Yoav Nir [1] = https://mailarchive.ietf.org/arch/msg/tls/ld2rY9px71wrxlWfzXhey02vPcc = [2] https://github.com/tlswg/tls-flags/pull/3 = --Apple-Mail=_EC8B8FF9-5AA2-455E-B0E9-73225F148677 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

Following the discussion last month, especially my message = from 31-Jan [1], I=E2=80=99ve submitted a PR [2] for guidance on = allocating the TLS flags with the goal to minimize the size of the = typical extension.

Please comment here or in github.

Yoav Nir

[1] https://mailarchive.ietf.org/arch/msg/tls/ld2rY9px71wrxlWfzXhey= 02vPcc
[2] https://github.com/tlswg/tls-flags/pull/3


= --Apple-Mail=_EC8B8FF9-5AA2-455E-B0E9-73225F148677-- From nobody Thu Feb 20 16:45:34 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05655120801 for ; Thu, 20 Feb 2020 16:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=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 H8LHqaSQdh_W for ; Thu, 20 Feb 2020 16:45:31 -0800 (PST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D511207FE for ; Thu, 20 Feb 2020 16:45:31 -0800 (PST) Received: by mail-qv1-xf2c.google.com with SMTP id u10so315619qvi.2 for ; Thu, 20 Feb 2020 16:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+Z4KBpOTpe2VUCMcCvXb5orwPp7UuDrl2a9lkYT7ESo=; b=kMwk3hsFqQIRiUV9+rzZKsfr5fMSNlhvYUsmtjbCJsj6WlkJ+Nt+53t4+82hpCdRBM 4Bo8IMmreG4gKYEkWQOfR1Dv3T8gp6zhIHMRTU01tr8q/o3m8E/jLZzxwu4QpZbeW8q1 KAJEtxXaypM0D3hRzNUfRAk8HH8KWDUl/t2wPaQAszOHvbF/yzqvAshDBqccxmcXD5cd +SkppNV+K5M8Z+gW4K5dEuD1JA3JZwNm1QaFEB8rhPssfJeF7u034jMaiuHPEEfO+1fY RE51dwf9D3x29CQBxH4Ni7M/7qXm34JruSIzcN2/HzJG++zmtcf+zKB7DVfCmtYCk03s +d2w== 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=+Z4KBpOTpe2VUCMcCvXb5orwPp7UuDrl2a9lkYT7ESo=; b=Tw7YB8DekzveJ6rAzv/VkuQgHLrfhDJyhWbEfhWe8oTz1z2s11+y+C4kEk+3belttN nUrnrsePjT+ZwaW3O4f5igsAAlzSuFcXo9Qf9+I/b4iHh6yZfWEb6EBfA3xsy1A/nXOJ heKK3D1R3p22JvUxd4rz8OgtQDNVvv6dYL7fGjyxSsrNY2KdAu+Xi+1wuWdQwvL3byV5 QAhwYx6g7zSC5SreGJ/adeO+xyrs9KnKYQ7s59RswWj5PI6vQ3xAJyQxZqgNYhf3mkoY MejK0AVP08te3+MvcScNbHvuQ79Tgbhd9qc510y7yzEDa25tI1fk1NB4hTNNvHVamHuF hEQg== X-Gm-Message-State: APjAAAXN5zT0YsUsr2pu2R3hZZzUufXbqqyMio0g5jO6bhgczhpQAAvF gY94SVHYPHmDqKQ0BX9yQPR/xv4DWub89JLEOu/xdV0TKysTuw== X-Google-Smtp-Source: APXvYqzmHVrddyY8syURd17xhQZBhizT5H5D+wfYTG2nyVJeCFfhVDaw5JC1P5BbR/rhEUAhkr71y0+BZo8IEsV0H1U= X-Received: by 2002:a0c:eed2:: with SMTP id h18mr28362493qvs.184.1582245930242; Thu, 20 Feb 2020 16:45:30 -0800 (PST) MIME-Version: 1.0 From: Joseph Salowey Date: Thu, 20 Feb 2020 16:45:19 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000009eb0db059f0b5643" Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-external-psk-importer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 00:45:33 -0000 --0000000000009eb0db059f0b5643 Content-Type: text/plain; charset="UTF-8" Hi Folks, This is the working group last call for the "Importing External PSKs" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/. Please review the document and send your comments to the list by 2359 UTC on 6 March 2020. Note the the GH repo for this draft can be found at: https://github.com/tlswg/draft-ietf-tls-external-psk-importer Thanks, Sean and Joe --0000000000009eb0db059f0b5643 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Folks,

This is the working group last cal= l for the "Importing External PSKs" draft available at=C2=A0https://datatracker.ietf.org/doc/draft-ietf-tls-extern= al-psk-importer/. Please review the document and send your comments to = the list by 2359 UTC on 6 March 2020.

Note the the GH repo for this = draft can be found at:=C2=A0https://github.com/tlswg/draft= -ietf-tls-external-psk-importer

Thanks,

Sean = and Joe
--0000000000009eb0db059f0b5643-- From nobody Thu Feb 20 19:08:32 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE73120120 for ; Thu, 20 Feb 2020 19:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 SbGfmo_Dewls for ; Thu, 20 Feb 2020 19:08:29 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258FB1200FF for ; Thu, 20 Feb 2020 19:08:29 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id p8so466554iln.12 for ; Thu, 20 Feb 2020 19:08:29 -0800 (PST) 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=k6DpYMGWF8tAtok/uqMr2yThBsEmywVDQ8GcuRuKtO0=; b=sLh0EB/xl9YGp7UrQ5swSAX2kk0VwpJqRsfPWoAGR8zup1oC1Dq5/vqTufuqN71Z1V Wpw7WwvGQl7B3K2jNvJYeT3QyH28B4n3x9fSr19N5M1Czm0o6Nb3mFA3tuN9X0ywJA8y l9oJV537ECLRL/QkypLEQxecy8LH1AM7m8MTDwBq+bm2otqWI/u9eaTCRyCEYqIzWtkx Ji7Kzy90kEIyY0LpDCFfXlOky166AXGyW4WdsR1b7+wf6IqYfnTpmt4WVLbCwO3JOiay mx+WrQvv4j+vyek7cKzPWteFOuZDlmXbjaKP+aEou0Ex5IyUVDeY7lX0hDC1TOCspDiu U7PA== 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=k6DpYMGWF8tAtok/uqMr2yThBsEmywVDQ8GcuRuKtO0=; b=sGZud3IFjZw2Dq/EW+o/s3AGndxmqBvWFiKbAxq4mwHxZl2qnRTj7Fi3W7yJ8bLbwN Nje2kIKd4ojTy3XUaLTUnOtbtQ6KsLnlpn3111gsryJqYi9J0U9L5eGKQYi+Nm9pF8fb Wb433/6iAVe0kQxqocM5EObV3aOY59w6miGqXjuN1PZEo0MukHsPmuB6R86d+EGsx9QF 8YfIimKl0tsGkAZ/jl6Lg3SuiwTB2YO8yrLWSDRb75Vz0Hu5jdzCw9acWKRMvecxj6vu UCW7cX7uaQD93wNB+ZZKEMrXn7pCwgz5MKjZNvjo7h2qjk3rSCiAI8t4sCnw4lIBQ9+Y Udng== X-Gm-Message-State: APjAAAUwPCfEy8+TKhkLCJdg4UcKf6VkI0oLsNtw7Ml9CuTvCpYQgpo+ PUi0dmFFpycNoBuGsO2HKt2IMVPY4DGul/sE0zM= X-Google-Smtp-Source: APXvYqw7dbc7w7fWFJFw3cQKT49IF3ogGKBDq4Ru1N3gMDEidj0xDSjtvKfFuRu/hEJGBSxjdVZ3XZAcc+q2HI8f3l8= X-Received: by 2002:a92:1553:: with SMTP id v80mr34223135ilk.49.1582254508323; Thu, 20 Feb 2020 19:08:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Thu, 20 Feb 2020 19:08:17 -0800 Message-ID: To: Joseph Salowey Cc: "" Content-Type: multipart/alternative; boundary="000000000000e9b96f059f0d55df" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 03:08:31 -0000 --000000000000e9b96f059f0d55df Content-Type: text/plain; charset="UTF-8" Hi, I'm not sure how violations of these requirements would result in poor interoperability: Clients which import external keys TLS MUST NOT use these keys for any other purpose. Moreover, each external PSK MUST be associated with at most one hash function. These seem like aspirational security goals. It would be better to describe the consequences of violating these conditions. thanks, Rob On Thu, Feb 20, 2020 at 4:45 PM Joseph Salowey wrote: > Hi Folks, > > This is the working group last call for the "Importing External PSKs" > draft available at > https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/. > Please review the document and send your comments to the list by 2359 UTC > on 6 March 2020. > > Note the the GH repo for this draft can be found at: > https://github.com/tlswg/draft-ietf-tls-external-psk-importer > > Thanks, > > Sean and Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000e9b96f059f0d55df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm not sure how violations of = these requirements would result in poor=C2=A0interoperability:
=C2=A0 =C2=A0Clients which import external keys TLS MUST NOT u= se these keys for
=C2=A0 =C2=A0any other purpose.=C2=A0 Moreover, each e= xternal PSK MUST be associated
=C2=A0 =C2=A0with at most one hash functi= on.

These seem like aspirational security goal= s. It would be better to describe the consequences of violating these condi= tions.

thanks,
Rob

<= /div>


On Thu, Feb 20, 2020 at 4:45 PM = Joseph Salowey <joe= @salowey.net> wrote:
Hi Folks,

This is the working gr= oup last call for the "Importing External PSKs" draft available a= t=C2=A0https://datatracker.ietf.org/doc/draft-iet= f-tls-external-psk-importer/. Please review the document and send your = comments to the list by 2359 UTC on 6 March 2020.

Note the the GH re= po for this draft can be found at:=C2=A0https://github.com= /tlswg/draft-ietf-tls-external-psk-importer

Thanks,<= br>
Sean and Joe
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000e9b96f059f0d55df-- From nobody Fri Feb 21 08:35:07 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A5312088E for ; Fri, 21 Feb 2020 08:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=0.001, SPF_NONE=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=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 GYeeZCeZ9hzR for ; Fri, 21 Feb 2020 08:35:03 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 55888120888 for ; Fri, 21 Feb 2020 08:35:03 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id w1so2818136ljh.5 for ; Fri, 21 Feb 2020 08:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CWPhyKxybUbndxu2aDRYZHJknEi5VaAwo+4DU5igHx0=; b=aMv/oG2AB9qrcZBf1YqFtgNoIAqQI/BTezX9Olv4TKX8N8mZvrQ7pOVOaBQp9jHbWJ 2cSg0MFXGjxMS5QJTC/y0MHnFjt0pzDCqyezY2Bz8SjA3E3fz94gYqrWIVD78s2eNasR vnhUND0wKuu5YjBFYOWi2GZmbEc+CaZosZSaRgB5PfAlk1u0SSUC0iT+TsqZF2LH8ttd Q/4hRA+CoI7YiuJPLLx3LYxXi6z1bAkgJ4l0B8udXoHB2X4ULJBdIO+32FC/HCsXToAH MJcuFUw7kvHmNOMocaeV4LIuWeuF1d8ujqFAs6+qF9RNh1QHWrns0SGhuOgTcJHZElq5 FnMw== 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=CWPhyKxybUbndxu2aDRYZHJknEi5VaAwo+4DU5igHx0=; b=R87vfutEoaoIYKYkEoeH5Uugi51kUskmPpxCcyjG8Lhp9sqgLjoynVT6Zm+1hUw2Yu ocB9mlFwfwwAgYVYlBdE/JrUt/KbkicG7SxBHCY8d5KC+61aCzAfUcUMwpEpQRhf5E2+ 3xfHqMDMK2+EMuOkZQqB4SgUbO8coMq+ApYPvFBCnKHQtzLOMFNxBv0D/XXEjTAr0ndF 739t7DSHDdg8yq/HYrV1X31yL5U3oy4JeDaayR6CHHgLV9/A5TlrTaz5CIeIJL1wmdzB QfS0TyHSHt4h/XXRAz3ioVglpK+7u965zB59TeadVkZqWyyVsnndFD8EhKbC2LHPDeem Yufw== X-Gm-Message-State: APjAAAUe2FpZoZTrhQ4vWcONHV/kiGK8zcIPG0DAl6gyiV+cybwhOd+4 hRea88YJ6nu89mIM5PRVGGBaXxAiJkuUKS2Isclj+Q== X-Google-Smtp-Source: APXvYqztbS+uOXyzCl+gDuogyIcmwLBunhTM+d4MFkSEiHixRa4FUDNIbyPEchC9qW2qifTnkf7/Tunnqb+8aK+z4p0= X-Received: by 2002:a2e:90f:: with SMTP id 15mr21466698ljj.120.1582302901512; Fri, 21 Feb 2020 08:35:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 21 Feb 2020 08:34:23 -0800 Message-ID: To: Rob Sayre Cc: Joseph Salowey , "" Content-Type: multipart/alternative; boundary="0000000000005f4fed059f189a0d" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 16:35:06 -0000 --0000000000005f4fed059f189a0d Content-Type: text/plain; charset="UTF-8" On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre wrote: > Hi, > > I'm not sure how violations of these requirements would result in > poor interoperability: > > Clients which import external keys TLS MUST NOT use these keys for > any other purpose. Moreover, each external PSK MUST be associated > with at most one hash function. > > These seem like aspirational security goals. It would be better to > describe the consequences of violating these conditions. > I don't agree. They are requirements in order to be able to make the assertions we want to make about the security of the protocol. This is consistent with the following text of RFC 2119 S 6 ".. or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) " I don't think it would be unreasonable.to explain the reason for these, though this is already a requirement of 8446 S 4.2.11 (though without justification). -Ekr > thanks, > Rob > > > > On Thu, Feb 20, 2020 at 4:45 PM Joseph Salowey wrote: > >> Hi Folks, >> >> This is the working group last call for the "Importing External PSKs" >> draft available at >> https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/. >> Please review the document and send your comments to the list by 2359 UTC >> on 6 March 2020. >> >> Note the the GH repo for this draft can be found at: >> https://github.com/tlswg/draft-ietf-tls-external-psk-importer >> >> Thanks, >> >> Sean and Joe >> _______________________________________________ >> 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 > --0000000000005f4fed059f189a0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 20, 2020 at 7:08 PM Rob S= ayre <sayrer@gmail.com> wrote= :
Hi,

I'm not sure how violations of these requirem= ents would result in poor=C2=A0interoperability:

= =C2=A0 =C2=A0Clients which import external keys TLS MUST NOT use these keys= for
=C2=A0 =C2=A0any other purpose.=C2=A0 Moreover, each external PSK M= UST be associated
=C2=A0 =C2=A0with at most one hash function.
=

These seem like aspirational security goals. It would b= e better to describe the consequences of violating these conditions.
<= /div>

I don't agree. They are requireme= nts in order to be able to make the assertions we want to make about the se= curity of the protocol.

This is consistent with th= e following text of RFC 2119 S 6
".. or to limit behavior wh= ich has potential for causing harm (e.g., limiting retransmisssions) &quo= t;

I don't think it would be unreasonable.to explain the reason for these, though = this is already a requirement of 8446 S 4.2.11 (though without justificatio= n).

-Ekr


thank= s,
Rob



On Thu, Feb 20, 2020 at 4:45 PM Joseph Salowey <joe@salowey.net> wrote:
=
Hi Folks= ,

This is the working group last call for the "Importing= External PSKs" draft available at=C2=A0http= s://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/. Ple= ase review the document and send your comments to the list by 2359 UTC on 6= March 2020.

Note the the GH repo for this draft can be found at:=C2= =A0https://github.com/tlswg/draft-ietf-tls-external-psk-im= porter

Thanks,

Sean and Joe
_______________________________________________
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
--0000000000005f4fed059f189a0d-- From nobody Fri Feb 21 11:29:08 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB4912006E for ; Fri, 21 Feb 2020 11:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 KlDXUuy_rrKr for ; Fri, 21 Feb 2020 11:29:04 -0800 (PST) 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 DBB6812006B for ; Fri, 21 Feb 2020 11:29:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 529A5300B3C for ; Fri, 21 Feb 2020 14:02:22 -0500 (EST) 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 H55n75Z114qH for ; Fri, 21 Feb 2020 14:02:20 -0500 (EST) Received: from [192.168.1.161] (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 89DB1300595; Fri, 21 Feb 2020 14:02:20 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Fri, 21 Feb 2020 14:29:01 -0500 Cc: Carrick Bartle , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 19:29:07 -0000 > On Feb 12, 2020, at 6:22 PM, Martin Thomson wrote: >=20 > On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote: >> I'm brand new to the IETF, so please forgive me if I'm totally off = base=20 >> here, but my understanding is that Informational RFCs are explicitly=20= >> not recommendations (let alone mandates)? >=20 > This would of course be information, but my comment was about = phrasing. This document comes off as being quite prescriptive, where it = doesn't really need to be. Absent actual algorithms, it's just a set of = guidelines. That's reflected in its Informational status, but it would = be better if the verbiage also reflected that more clearly. >=20 > To address Stephen's comment at the same time: I think that we can = publish an RFC on this before the competition completes if it is just a = framework. That might in fact make standardizing the one true composite = scheme easier. I do not agree. I do not think the WG should adopt this draft. The CFRG has stated a position that the IETF should wait for the NIST = standardization process to be complete. There are at least two = approaches to mixing symmetric keying material into the TLS 1.3 key = schedule for information that needs to be protected for the next few = decades. (The two that I know about are = draft-ietf-tls-tls13-cert-with-extern-psk and draft-vanrein-tls-kdh.) = These approaches make existing key establishment techniques secure even = if a quantum computer gets developed as long as the symmetric key is not = disclosed. In my opinion, those techniques will hold us until the NIST = standardization process finishes. I do not understand the goal of mixing (EC)DH with one of candidate = algorithms. We do not know enough about the candidate algorithms in the = NIST process. If the goal is to add quantum resistance, we do not have = enough information to pick well. If the goal is to learn about mixing = in general, then I question the project altogether. Once the NIST = standardization process is complete, we can simply use the selected = algorithm without mixing. Russ From nobody Fri Feb 21 13:16:07 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50BF120089 for ; Fri, 21 Feb 2020 13:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 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_HELO_NONE=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 OGa3eVuxeQ4j for ; Fri, 21 Feb 2020 13:16:03 -0800 (PST) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE08812006B for ; Fri, 21 Feb 2020 13:16:02 -0800 (PST) Received: by mail-il1-x143.google.com with SMTP id p8so2771511iln.12 for ; Fri, 21 Feb 2020 13:16:02 -0800 (PST) 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=VJyVrtv5ecNs7VAX2GRKDcaHwMdl9rEK9rsoKfC/oBc=; b=FNGBjTJP/2ZfNthzBxBn7fxmUQ0orYId+ymLjNS0Ds111KG+K8Ad/SeCL5dGT90813 n07Je+kFx/AkcdUcPaEtLLm2qALnOy79xC2yWxf4iXsLFx3/64Ch+1uAFDo89IsL8RxJ 6hvqXxH4ZTZ0DWfGHrwjF1zi/csWBs6XsnFnX+9w3+A31aC1MafqgcyITwr/TpV5VHBa amUZTdV0dRQTyLopmwPJ66xy0eXQjx4VB/IuP5Mk8UFepSiB8SETnOT7uaeL1du7PYVT G2BVRq208VniIHnfuQunsdvDBg3eK2fwB1AEjl+VcIQX+vB3Iy1suZUbYrzS34HcXDTz AE3w== 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=VJyVrtv5ecNs7VAX2GRKDcaHwMdl9rEK9rsoKfC/oBc=; b=IitE29MaihyRQze6LND2mqYnSaZifudeje1/cgVSpAdtKV2lsVbCnQ9uke62MTXqUZ AuJQjLi+7IGEs3zbaUi5R8idBIsfAkN3ZZPKWQFDOxwr/jwCHQhuwJtf/nNtjlZ/c+/E 5QwB95Pkfh6PBJ7rIetCk1bUKJMwUQZiUkFhCpEoEQ8F8//OZjEmpo3tdbKx6/DkTlGN dRQkD7t1MfJ7OcHugwxZEE6o8MWGtsLuJNyKNTFBa3ooPaiGRp8UsvI6/dQ8HV1MeALG 7mBq7okJRdD9/1CqTKXMKE3bu2h8STezA3v2Cc7F6CiNwnwjYGTmBaAwprcnyJNkcTBA QSfg== X-Gm-Message-State: APjAAAXVGEBDVo7/V8+n0phI+A6ZOE/hpNogDNJ7og8TJi/QVSWx1mz7 QEej19k5MuXRll0VdsjGiydw6CujXdmR1HFMkOg= X-Google-Smtp-Source: APXvYqw/jmahu1cFSryFjb0rGJNoKLNf+x1vUzwXDzOcgJ8A0n7EopzrexnjelBmPQOAF/AJT05t1MH1YBiZz4Equ4E= X-Received: by 2002:a92:990b:: with SMTP id p11mr38766328ili.254.1582319761354; Fri, 21 Feb 2020 13:16:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Fri, 21 Feb 2020 13:15:50 -0800 Message-ID: To: Eric Rescorla Cc: Joseph Salowey , "" Content-Type: multipart/alternative; boundary="0000000000004bf519059f1c87c2" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 21:16:05 -0000 --0000000000004bf519059f1c87c2 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla wrote: > > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre wrote: > >> Hi, >> >> I'm not sure how violations of these requirements would result in >> poor interoperability: >> >> Clients which import external keys TLS MUST NOT use these keys for >> any other purpose. Moreover, each external PSK MUST be associated >> with at most one hash function. >> >> These seem like aspirational security goals. It would be better to >> describe the consequences of violating these conditions. >> > > I don't agree. They are requirements in order to be able to make the > assertions we want to make about the security of the protocol. > > This is consistent with the following text of RFC 2119 S 6 > ".. or to limit behavior which has potential for causing harm (e.g., > limiting retransmisssions) " > > I don't think it would be unreasonable.to explain the reason for these, > though this is already a requirement of 8446 S 4.2.11 (though without > justification). > I think that interpretation of 2119 is a stretch, but your idea to add an explanation while keeping the 2119 terms addresses my concern. At the very least, the draft should note this is already a requirement of 8446. thanks, Rob --0000000000004bf519059f1c87c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 21, 2020 at 8:35 AM Eric = Rescorla <ekr@rtfm.com> wrote:
<= div dir=3D"ltr">

On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <sayrer@gmail.com> wro= te:
Hi,

I'm not sure how violations of these requir= ements would result in poor=C2=A0interoperability:

=C2=A0 =C2=A0Clients which import external keys TLS MUST NOT use these key= s for
=C2=A0 =C2=A0any other purpose.=C2=A0 Moreover, each external PSK = MUST be associated
=C2=A0 =C2=A0with at most one hash function.

These seem like aspirational security goals. It would = be better to describe the consequences of violating these conditions.
=

I don't agree. They are requirem= ents in order to be able to make the assertions we want to make about the s= ecurity of the protocol.

This is consistent with t= he following text of RFC 2119 S 6
".. or to limit behavior w= hich has potential for causing harm (e.g., limiting retransmisssions) &qu= ot;

I don't think it would be unreasonable.to explain the reason= for these, though this is already a requirement of 8446 S 4.2.11 (though w= ithout justification).

I = think that interpretation of 2119 is a stretch, but your idea to add an exp= lanation while keeping the 2119 terms addresses my concern. At the very lea= st, the draft should note this is already a requirement of 8446.
=
thanks,
Rob

--0000000000004bf519059f1c87c2-- From nobody Fri Feb 21 13:24:47 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8552112008B for ; Fri, 21 Feb 2020 13:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NVlXyay+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=R9VhQGoX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR289UyrvXq7 for ; Fri, 21 Feb 2020 13:24:43 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE98C12008A for ; Fri, 21 Feb 2020 13:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4793; q=dns/txt; s=iport; t=1582320282; x=1583529882; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3FzO4XqpIcA0/cMGKK3N3VphtazRLHNvJqlw/q1Q+O4=; b=NVlXyay+REpJWBMMJNm11Tk+6gaJe0z2HlBoNpLW364qdFIvb0gem5iW I2NiGD2XQvlj/DN+5zIwaQE3aNvbkofo3aE9USRVUjQ49HC3pbgh50GrE LE7ku716GLWy/VYfzsXRQswtS+pmtV67K6L6SbqBPQr/8f1aBVU4rjUfH s=; IronPort-PHdr: =?us-ascii?q?9a23=3A3PEqZB00EtsrHs4gsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEkP/Mf7wYjYSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAADUSVBe/5JdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gVRQBYFEIAQLKgqHUAOKcYJfmBSCUgNUCQE?= =?us-ascii?q?BAQwBAS0CBAEBhEACggwkOBMCAw0BAQUBAQECAQUEbYU3DIVmAQEBAQIBEig?= =?us-ascii?q?GAQElCwcBBAcEAgEIEQQBAQEeEDIdCAIEAQ0FCBqFTwMOIAGjUwKBOYhSEII?= =?us-ascii?q?ngn8BAQWFKhiCDAmBOIwkGoFBP4ERR4JMPoEEAYMuGoNBgiyvJHYKgjyXAIJ?= =?us-ascii?q?JiBuQSo5wm0cCBAIEBQIOAQEFgWkigVhwFYMnUBgNjh2Dc4pVdIEpizAtgQQ?= =?us-ascii?q?BgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,469,1574121600"; d="scan'208";a="721030023" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Feb 2020 21:24:41 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 01LLOfel023955 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Feb 2020 21:24:41 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Feb 2020 15:24:40 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Feb 2020 16:24:39 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 21 Feb 2020 15:24:39 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NTrzjUCUbhAHFtd3N3nuGnZ2/05HXSZmMSsNj78CitmNk2EBpvFLqsBZ+wYsp1JiZ5nOIoR95TxThYYujONKHmsvJCU6OXz44G0AQHtC4uby/NHwCImH2/riRrC2wfIR7sjVUFDcQ6+ckKPWw6iaiFIbKpNePOD801K+6Q8koLgFZj4yz1T04gddfcaWYss9RlnIfzpenH3fjPCNVLzmKS/IriYD4kPKyjWLc18mY+M389BEskMQu9HhHDU8cydFCHuLjpUIeUTy2mMtA/Cx7bwOAJTmrCnrHSnHVjBPxfiSIqH3/gWxiZsgW7MvLP0Mds64parYHtYA7rg940tFLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nHaqk9dsTVHg5MhzKDk9Vj1rruunbLRQCU1xX6L1axo=; b=Xi+P0WiQrwUkpJXUEh//HXQ6dK/sJJaBaXbkOE5A3XA2Bqkl7xzm27EDgCjGGIbOZciT1ktr96dCmBqztTByEtgseM4Kbl9gOrh9sRn5S3j808Xb0uUgZs0Lb4kmeHvYn1cJOBpPvVl18EZKRo1x5LogTHjeeGxyZutFh0V0AmgGmsZA/vGdawbbwvove56AtdCWMUp+0yA8sqpfL15jTtQCvmii1DavJ3K8GHIx5NN123OSSviyIN4P8vsn/cAg3M6RG4Ls2jeM4O0qFF0Mr+QlcosDbqheQL9FvRHGEYasx5UskysmTCHnygYrK+q00V2x1/W2JusBKoe/FQ4A0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nHaqk9dsTVHg5MhzKDk9Vj1rruunbLRQCU1xX6L1axo=; b=R9VhQGoXewijBcEpIn4DsaQhxP5mJ14zRCcLg7lIJ0qItb6EovTNlpcBY9aMWva9+OlfsVPu/fqGdIfhJ9bY+vXzECFqyXY59k1w/UU8nm8wQHnIDzklb6K20OVNhechFjZBl+BNBomxjnsdStaurIZqV7dj7ZKM1z8t+y6Dsic= Received: from MN2PR11MB3936.namprd11.prod.outlook.com (10.255.180.15) by MN2PR11MB3966.namprd11.prod.outlook.com (10.255.180.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.17; Fri, 21 Feb 2020 21:24:38 +0000 Received: from MN2PR11MB3936.namprd11.prod.outlook.com ([fe80::71a0:2f72:8146:9d8]) by MN2PR11MB3936.namprd11.prod.outlook.com ([fe80::71a0:2f72:8146:9d8%6]) with mapi id 15.20.2729.033; Fri, 21 Feb 2020 21:24:38 +0000 From: "Scott Fluhrer (sfluhrer)" To: Russ Housley , Martin Thomson CC: IETF TLS Thread-Topic: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design Thread-Index: AQHV6O1CZfCw/3vKLUaife0PGSB7GKgmDcdQ Date: Fri, 21 Feb 2020 21:24:38 +0000 Message-ID: References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> In-Reply-To: <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sfluhrer@cisco.com; x-originating-ip: [173.38.117.68] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a7bf3ad-6766-4f17-3f3e-08d7b71474f8 x-ms-traffictypediagnostic: MN2PR11MB3966: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0320B28BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(396003)(376002)(366004)(199004)(189003)(8676002)(110136005)(66946007)(26005)(4326008)(2906002)(76116006)(81166006)(81156014)(5660300002)(66556008)(66446008)(71200400001)(33656002)(64756008)(66476007)(316002)(8936002)(7696005)(53546011)(6506007)(478600001)(9686003)(55016002)(52536014)(86362001)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3966; H:MN2PR11MB3936.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EOhMjtIcwb/mRyWWyd38Ag1nOSuHe57lNx5on1rZehMCRIXw24c3CPgl77GkDzxvex6M7EeBCEydldnauA2Y6DjFBQ0UlLq6sgEgkincthPt5zVRgbG+2Y/rmYZEIk9DoQWllcrfUDdb19Byq/Cddxf06JeyJ7Pn0o0T0deGq/Vl11SNfpvBntTOCg8G26EClkFvvRyRBb/g7lL22wgII/9onOfkGgH0ro08219DEW2FbgIVg8qt5hl50UOWXufC+qebdhOE17SLZ46wTYiA5IIMtcw32fiwZAVudtP49lMBqEJaMy5IqW1+MPjkxIwsK4g75UROGplsUTvr5vs6Un2lBLyap9OS/7R/v3bj4wYt/HnNkHFOJzlU78Ar6h5uMAhSI7Ou9dua70EbcmsaLxQLy1NFX4BVd3MZ0dbN8vWAN/nxFKoFrHXvHeW8iOru x-ms-exchange-antispam-messagedata: IUfL7z34CGcf6epz1BmkRB2jx/JFiagFB75VK0aZH+IROVvVNIJZm6bCzpnBWfAvMULO/yV7yU1hgs+Kvp7XbThcMx5p+UBsg+8A9TOekjhNA4jMfy/TGQMu6Mi79M/NmvbWEQwHwFGrtJRb5UOHkw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6a7bf3ad-6766-4f17-3f3e-08d7b71474f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2020 21:24:38.4820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eeuLBbu07tb7wHz9EPTFQb2uyhyZDH82in4/5l/bpsTDWRzXnNquye4g3L5pFMTt+S43Hzb4znp9CYXDfLQvKw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3966 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 21:24:46 -0000 > -----Original Message----- > From: TLS On Behalf Of Russ Housley > Sent: Friday, February 21, 2020 2:29 PM > To: Martin Thomson > Cc: IETF TLS > Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls= - > hybrid-design >=20 >=20 >=20 > > On Feb 12, 2020, at 6:22 PM, Martin Thomson > wrote: > > > > On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote: > >> I'm brand new to the IETF, so please forgive me if I'm totally off > >> base here, but my understanding is that Informational RFCs are > >> explicitly not recommendations (let alone mandates)? > > > > This would of course be information, but my comment was about phrasing. > This document comes off as being quite prescriptive, where it doesn't rea= lly > need to be. Absent actual algorithms, it's just a set of guidelines. Th= at's > reflected in its Informational status, but it would be better if the verb= iage > also reflected that more clearly. > > > > To address Stephen's comment at the same time: I think that we can > publish an RFC on this before the competition completes if it is just a > framework. That might in fact make standardizing the one true composite > scheme easier. >=20 > I do not agree. I do not think the WG should adopt this draft. >=20 > The CFRG has stated a position that the IETF should wait for the NIST > standardization process to be complete. I disagree with Russ's statement that what the CFRG has stated actually app= lies to this draft. This draft does not specify what postquantum algorithm= s should be used (which is what the CFRG is talking about). What it tries = to address is "once we have an approved algorithm, how do we integrate it i= nto TLS". Surely it would be better to get that preliminary work out of th= e way first, rather than waiting for the NIST process to conclude, and then= start spending the time working on the integration process. > There are at least two approaches > to mixing symmetric keying material into the TLS 1.3 key schedule for > information that needs to be protected for the next few decades. (The tw= o > that I know about are draft-ietf-tls-tls13-cert-with-extern-psk and draft= - > vanrein-tls-kdh.) These approaches make existing key establishment > techniques secure even if a quantum computer gets developed as long as > the symmetric key is not disclosed. In my opinion, those techniques will= hold > us until the NIST standardization process finishes. Symmetric keys solve the problem, but are usable only in scenarios where yo= u have a pre-existing relationship between the client and the server. It d= oesn't work in a more general "web-surfing" type scenario. >=20 > I do not understand the goal of mixing (EC)DH with one of candidate > algorithms. We do not know enough about the candidate algorithms in the > NIST process. If the goal is to add quantum resistance, we do not have > enough information to pick well. And, again, the draft does not attempt to pick one. > If the goal is to learn about mixing in > general, then I question the project altogether. Once the NIST > standardization process is complete, we can simply use the selected > algorithm without mixing. I can see someone disagreeing. Whatever postquantum algorithm NIST selects= , it will be a relatively recent one (and hence one that hasn't gone throug= h as much cryptographical scrutiny as one would like) [1]. And, given that= slapping on an ECDH exchange is relatively cheap (both in computation and = especially in bandwidth), I can see someone wanting to put it in there as a= safety measure, in case that the postquantum algorithm turns out to have a= weakness to classical computers. In any case, even if we ignore mixing, there are questions that need to be = considered for a postquantum algorithm (which doesn't behave precisely like= DH). For example, to what extent should we insist that fresh key shared b= e used each time? Should we require the key exchange mechanism to have "CC= A" security (which DH does, as long as you perform the proper validation te= sts), or is "CPA" security sufficient? Should we attempt to support key ex= changes with huge (e.g. a Megabyte) public keys? Those questions can be considered even before we learn which postquantum al= gorithms we will eventually use. [1]: Exception: McEliece has been around a long time, and has picked up eno= ugh scrutiny for us to trust it. However, it's also the one with Megabyte = keys, and even if we were to support it, it's likely to be only rarely used= ; the issue will still remain with whatever other postquantum key exchange = we also support From nobody Fri Feb 21 13:33:57 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B55112012A for ; Fri, 21 Feb 2020 13:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 UpLAbnsb2BPO for ; Fri, 21 Feb 2020 13:33:33 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3CA12011C for ; Fri, 21 Feb 2020 13:33:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 390C1BE2F; Fri, 21 Feb 2020 21:33:30 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khRV21Olgw4M; Fri, 21 Feb 2020 21:33:28 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5EA97BE2E; Fri, 21 Feb 2020 21:33:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582320808; bh=ROsj9eoi2rmrM0VU616Grh/sNQ3ExgaQp9GkbIdBLbY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QZkU5CdbmmhUWGyMZmoBUAdTxokWUZzjZd8GYhCHNv9f1JJW72jrfBzPsmPyg6epx LGhUAj/C71tshV0W9ToE5e2t1NPbDP5gzXLWBrQKHx7sAKHvHwZxjsHFOkLCwcEFBk TGX2u0YnfSlXEFR+wakKufnDXjjUbOrZTioXsdBk= To: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson Cc: IETF TLS References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> Date: Fri, 21 Feb 2020 21:33:26 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2UI46dsKVJIWsabQRRVRYgzjI7pHMZzLM" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 21:33:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2UI46dsKVJIWsabQRRVRYgzjI7pHMZzLM Content-Type: multipart/mixed; boundary="onxunotearIwDfHNnvEqOxXezL7KXCzIM"; protected-headers="v1" From: Stephen Farrell To: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson Cc: IETF TLS Message-ID: <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> In-Reply-To: --onxunotearIwDfHNnvEqOxXezL7KXCzIM Content-Type: multipart/mixed; boundary="------------E172BB9EFE9C0C56FAF482AC" Content-Language: en-US This is a multi-part message in MIME format. --------------E172BB9EFE9C0C56FAF482AC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/02/2020 21:24, Scott Fluhrer (sfluhrer) wrote: > What it tries to address is "once we have an > approved algorithm, how do we integrate it into TLS". =20 Except that we do not have an approved algorithm. We have 17 round 2 KEMs with vastly different properties. Even when NIST are done that number seems likely to be >1. > Surely it > would be better to get that preliminary work out of the way first, > rather than waiting for the NIST process to conclude, and then start > spending the time working on the integration process. Given the range of differences in sizes of public values, CPU etc and the fact that we don't know how those algs will be parameterised, I don't believe this is work that can be usefully gotten out of the way first. Cheers, S. PS: I do believe that we'll want to mix NIST PQC algs with classic DH after we know the details of the PQC algs, just not before. --------------E172BB9EFE9C0C56FAF482AC Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------E172BB9EFE9C0C56FAF482AC-- --onxunotearIwDfHNnvEqOxXezL7KXCzIM-- --2UI46dsKVJIWsabQRRVRYgzjI7pHMZzLM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5QTKcACgkQWrL68XsX K+rFAA/+MMxwqiw0MNk76Xqbm0EsC3UEmIk6a/GlmwHco2DUWoVDstN40rSoPEED xYX4ZOO+LCBt+ap81Y6AkCpZlj0UGWYpuIkAeIL7DFxJbLQfdDFg9RupnugMUEb2 7pLcWTS6DwKQwh/kKTiYGiT1j48+jem9DSFVApHgXdtJDqgb78s2G5myyTFBUDPA uUkJHg4JCflbMJ9zsio0FIeTpbHMFfCewqwuxFUakE8BOlz/MLQLIie/ydl/YwyR WuEJ4iTvEP9i4N86t/W4/HvMj+ESKKGRIGwwxuPbg/YUNAEiwkdYu4RH9V19Boow f0A5swYDPBVz9/sbcvJNOoD4qZFrNmj5k7+psx46ukwNKMkc+QGxGLfDF3PME4hY nlfN6HYKss4JuUsEw/Bs4hheFxbHdnG8yl9r+9YaPVpARPaNVXrQxQz7SH2rmyo1 yT7bTQ1FcGuLE5BvaLSN62hHtidSSZA7S5zfwfUfj9+CEbqwVzyugnJ3PA46+rRe GnZZ/zQZpPo/ZqXsVbJVyK0dk+BSRoGb/Mu3/V0yPKxNib1R3MCIfJ5gAwHkvS1s XDLauxzW2aNOOhYEOw+yK7NF5MfVSVmgrTS7s+GZgyNWOgClFtfSvObOJQSGLbKH 1GKu8D0T8Ai+B4wZHClo3f4W5mC2crFmKHJ6K82VorkDsfgELQI= =sC7R -----END PGP SIGNATURE----- --2UI46dsKVJIWsabQRRVRYgzjI7pHMZzLM-- From nobody Fri Feb 21 14:03:11 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F54C1200C3 for ; Fri, 21 Feb 2020 14:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 5TH_PD5Yb17T for ; Fri, 21 Feb 2020 14:03:04 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C33D12008A for ; Fri, 21 Feb 2020 14:03:02 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id c188so3335019qkg.4 for ; Fri, 21 Feb 2020 14:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m/W/Bz+n5ltu9alWyACO9/h2BT3SMWfYIi4hUX2YR3k=; b=IG56kra5bXRTi3M+2B9WL7SbLNjdrtps1mNyWV0CNyixDt9J+8gR/DLerj6hAoDtsS OfmQCdJusz84SAVTcIecym4GOYzpEUWuHod4vgbVYdVE0VqDhFgfDYEyW+Fx5cLHR/vz IkGDgDWE2pcX9qRUBKprPRX7QEh+mPLoPIjRE= 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=m/W/Bz+n5ltu9alWyACO9/h2BT3SMWfYIi4hUX2YR3k=; b=H/UhyL8G6cgxF5DFxbXO/CTH7Kh0qf/KYanVhmHDXM3iv01VjPJVJar9OLShugJZ5e B0Px3z2U8RB4kuzwSlCTUgIaJW6wI3Nz4BvpUtvEhFd4LKl7QkXv6qnM6lnNCH7TR+Jl xG1MmM946EHKXl+AYnf7A+oF4Bmc49DtkD861s4RxC2ASv1GkVBWch3NNwDTF2ukSkuF F4xizcYCYQ2q3DjJfDmPVfYciLQyBLuswLUa67YaQqJeZfXU90xhrfVhSUgAenf+oFlS HT3hmRJ41JkVsKsTlTz+uH3phXMghOxuoI+Y3bktzmB4cDuyxW13WdDt6zLHDFbH0p4Z j0kA== X-Gm-Message-State: APjAAAXRyAaB+zQoJvAjJ+HFhmbuYq3MyFZZG6z1BQwUxkcn3ZEzVTeX VDB1UjtSEPI2aPDc/H5cDYhQjRLVExwmErPqYFz2bx1HCvM= X-Google-Smtp-Source: APXvYqwSe8RY5BYAUf65sQyT2l+Sp8Deg8KG5FrETVKz3yVrAZ83G6H/9WQvqacJyYiNLGpHSZVgEoQDdChS52uYtuA= X-Received: by 2002:a37:9e09:: with SMTP id h9mr35716264qke.176.1582322581263; Fri, 21 Feb 2020 14:03:01 -0800 (PST) MIME-Version: 1.0 References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> In-Reply-To: <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> From: Watson Ladd Date: Fri, 21 Feb 2020 14:02:50 -0800 Message-ID: To: Stephen Farrell Cc: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:03:09 -0000 On Fri, Feb 21, 2020 at 1:37 PM Stephen Farrell wrote: > > > Hiya, > > On 21/02/2020 21:24, Scott Fluhrer (sfluhrer) wrote: > > What it tries to address is "once we have an > > approved algorithm, how do we integrate it into TLS". > > Except that we do not have an approved algorithm. We have > 17 round 2 KEMs with vastly different properties. Even > when NIST are done that number seems likely to be >1. All the KEMs are KEMs, meeting the same security properties, and fall into three categories of problem: lattice, code, and isogeny. > > > Surely it > > would be better to get that preliminary work out of the way first, > > rather than waiting for the NIST process to conclude, and then start > > spending the time working on the integration process. > Given the range of differences in sizes of public values, > CPU etc and the fact that we don't know how those algs > will be parameterised, I don't believe this is work that > can be usefully gotten out of the way first. We have already deployed widespread experiments that conducted the hybridization described in this draft, already have implementations supporting an approach similar to this draft, and that produced valuable input to the standardization process. It really didn't matter that it was SIKE or NewHope that was being hybridized, and they have very different characteristics. What will we know when NIST finishes that we need to know that we do not know today? Which algorithm we want to hybridize? That's easy to handle: the mechanism is generic. Sincerely, Watson Ladd From nobody Fri Feb 21 14:08:19 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760A81200C1 for ; Fri, 21 Feb 2020 14:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 xUYBoEzq6yju for ; Fri, 21 Feb 2020 14:08:16 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B6012008A for ; Fri, 21 Feb 2020 14:08:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 860A1BE2F; Fri, 21 Feb 2020 22:08:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2URJrEjUCpS; Fri, 21 Feb 2020 22:08:12 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DA5B8BE2E; Fri, 21 Feb 2020 22:08:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582322892; bh=bdPF4lamBlclZEkt4a/y75r2cAnQIrjpWZWIVxpDurg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Q2//XBZmNF7fjvMfr5xFZOLCyZksJ1hyRflsLG/kU4type/iBHY0QVXsS1J9L05mJ aW77xvbe26gwgAqFdE7XVPeXvBlEvzZLIKAN0dXvIihXhuoFXhD29RwEOoJ3VwsYYJ 39oC+2+mSlhJRjRsMDihI/bPETc6N1H5VrY8XHPU= To: Watson Ladd Cc: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson , IETF TLS References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> Date: Fri, 21 Feb 2020 22:08:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5zyOgEa5lZNB9SaJAZER4wjgxnzUdqnrY" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:08:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5zyOgEa5lZNB9SaJAZER4wjgxnzUdqnrY Content-Type: multipart/mixed; boundary="TJbzRsWcAF4Ve9q1CCxllfHrl6BTTcwam"; protected-headers="v1" From: Stephen Farrell To: Watson Ladd Cc: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson , IETF TLS Message-ID: <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> In-Reply-To: --TJbzRsWcAF4Ve9q1CCxllfHrl6BTTcwam Content-Type: multipart/mixed; boundary="------------7CA1B1E4D047F6BF60DE7367" Content-Language: en-US This is a multi-part message in MIME format. --------------7CA1B1E4D047F6BF60DE7367 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21/02/2020 22:02, Watson Ladd wrote: > We have already deployed widespread experiments that conducted the > hybridization described in this draft, already have implementations > supporting an approach similar to this draft, and that produced > valuable input to the standardization process. It really didn't matter > that it was SIKE or NewHope that was being hybridized, and they have > very different characteristics. Documented where? Ta, S. --------------7CA1B1E4D047F6BF60DE7367 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7CA1B1E4D047F6BF60DE7367-- --TJbzRsWcAF4Ve9q1CCxllfHrl6BTTcwam-- --5zyOgEa5lZNB9SaJAZER4wjgxnzUdqnrY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5QVMoACgkQWrL68XsX K+qX1RAAxXAIbkntngCbcwaVKc+AjUY710uXNtHZPli3txY59JYstkx1drVeySv0 lOJDZc8ypG5d7QMtukkXqkWxXbl/GFzGOxpXlS4mD+8NnP8KStmDfl/VtdhVetP6 N+59Fro0/eGmkV2Gi7aYvB2D8ZHtVQ6MfqO3l9IFDLKiKWI/p55eRJc12dj9POem WhzpZsHawt+74FRX/G2d8kZ29Y1dTczZ7vTQ9xqC4vEDxeHUe6KJvXmo36m/bW7C becJZkMGLRWzMrNfDdJGphjxOTozooqoKKO1wiJPpQSgYVrCUg3KzEQNUslQZszC za+J4fhAgZ1Uy/OIMDb3OXGRQOiKT7rvH++YXHyijMT0LuHWPg5FokBXKd3eMnJf QHBCZeg34gKd67F4MEXu3o04cun07D8KyCalrk265DkpjLFOZjkCI3gfucdVk9aD cXFpaQorOdk3S5vQrZa5G9ino/QGebFSqklfokfo58AICBl+mz8pwKNeUT/uaUqP yWOuOVg/dIOSJP09w7+Pnpi6DNRr3JYSEzu2Yg6y+dQkyz7HVcIjeNVdT1euuo+a PB6neVEhYYWOqF8EW03sGcrt3LmqBAAKWfeAY+7qcn/qYZNhxD+YcdUMpf6E7fW7 OSHNqyDeCND7Ghnqzd6XI9t9Zx3wagt8bV8n5Cofb0FJeBEQFDg= =G9p4 -----END PGP SIGNATURE----- --5zyOgEa5lZNB9SaJAZER4wjgxnzUdqnrY-- From nobody Fri Feb 21 14:11:46 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857811200C3 for ; Fri, 21 Feb 2020 14:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 SN44uTXn7EyX for ; Fri, 21 Feb 2020 14:11:42 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FFB1200C1 for ; Fri, 21 Feb 2020 14:11:42 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id z19so3339770qkj.5 for ; Fri, 21 Feb 2020 14:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ob8WxOk7PByaaLaXt55tg7uEplMfrxnlmOAiWoblXzU=; b=s+G67yjsdVhJv/84kOOU2dGO/aYccNAl1xPz/tcbnRarbz3hPb587ZlvGi0fGMmlbg TlkkumbBuymxPSyWhoPiLNoqw0dFJS1yYAHIo3Pq2vzxzT67GFLIG9p6yu0pKO7q/2T3 eF0LdTChMKwBHjxJMlnHX0dXvvB0CN9iZ766o= 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=Ob8WxOk7PByaaLaXt55tg7uEplMfrxnlmOAiWoblXzU=; b=LOb7Rf+6xP4GRu1r0oWXsGO71TJ/OkNzkP/N/mCGkRNuftukXUTmfjoVwMLVOfXSMH DIVa+fzkm+e85beNMBRZvm/SR/Dtfyrb9/FUd2LjCAWQYSusSdWXGheuzwIBQ29Xiwpq swKZkxSsaKCCcF32UiOT8aFhhRq0lysf6gtR/yQIottH0Pbfh268x8bGCP9ANGg/fAAq FDpOBbmnS9ZE3qQbUE7L7yClimTLvmGAx5NvxMhuMBQc3MGMIz+qQdPOQ3SF9PeIFDtH /5YSMDDnwOrSnGfTa6hQmnbISfIY8VVO4TuS8k2tEeF6jOYUzbqyiwh4cMnDwkjQTc/N 5slQ== X-Gm-Message-State: APjAAAV1/jfC76Ki7UlAfqE3pOAWFU7faDO0ATDGp6CdG9BqyEYOlpeF pPeTy4oAr9+Heb2O/FKhUvHcg51PChBDag1jycUZnQ== X-Google-Smtp-Source: APXvYqxKyAOzEtAh0V81Mg7eOreD8oBRV22mw+0K50JumOfIu+4iBwYYl/aLzJ6UrgdbeIMqQesKgLU+NFwuC/fCIwU= X-Received: by 2002:a37:9407:: with SMTP id w7mr35357611qkd.55.1582323101162; Fri, 21 Feb 2020 14:11:41 -0800 (PST) MIME-Version: 1.0 References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> In-Reply-To: <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> From: Watson Ladd Date: Fri, 21 Feb 2020 14:11:30 -0800 Message-ID: To: Stephen Farrell Cc: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:11:45 -0000 On Fri, Feb 21, 2020 at 2:08 PM Stephen Farrell wrote: > > > > On 21/02/2020 22:02, Watson Ladd wrote: > > We have already deployed widespread experiments that conducted the > > hybridization described in this draft, already have implementations > > supporting an approach similar to this draft, and that produced > > valuable input to the standardization process. It really didn't matter > > that it was SIKE or NewHope that was being hybridized, and they have > > very different characteristics. > > Documented where? https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/ https://blog.cloudflare.com/the-tls-post-quantum-experiment/ This was also presented at the NIST standardization workshop in October of 2019. > > Ta, > S. From nobody Fri Feb 21 14:22:19 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41101200C3 for ; Fri, 21 Feb 2020 14:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 A2iO_VCWXv-a for ; Fri, 21 Feb 2020 14:22:15 -0800 (PST) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (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 56A341200C1 for ; Fri, 21 Feb 2020 14:22:15 -0800 (PST) Received: from LLE2K16-MBX04.mitll.ad.local (LLE2K16-MBX04.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 01LMM7G6017633; Fri, 21 Feb 2020 17:22:07 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Watson Ladd CC: Stephen Farrell , IETF TLS Thread-Topic: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design Thread-Index: AQHV6O1N434rvusUuUeVDrTm3f3GWagmfJsAgAACdQCAAAg3AIAAAX4AgAAA7gCAAAL1gA== Date: Fri, 21 Feb 2020 22:22:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-58423437-D497-4F61-84C8-9EBDC6F00B66"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-21_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002210166 Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:22:18 -0000 --Apple-Mail-58423437-D497-4F61-84C8-9EBDC6F00B66 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFdhdHNvbidzIHJlYXNvbmluZy4NCg0KV2Uga25vdyBub3cgYWxsIHdlIG5l ZWQgdG8gdG8gc3RhcnQgd29ya2luZyBvbiBnZW5lcmljIG1lY2hhbmlzbXMuDQoNClJlZ2FyZHMs DQpVcmkNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIEZlYiAyMSwgMjAyMCwgYXQgMTc6 MTEsIFdhdHNvbiBMYWRkIDx3YXRzb249NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRmLm9yZz4g d3JvdGU6DQo+IA0KPiDvu79PbiBGcmksIEZlYiAyMSwgMjAyMCBhdCAyOjA4IFBNIFN0ZXBoZW4g RmFycmVsbA0KPiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6DQo+PiANCj4+IA0K Pj4gDQo+Pj4gT24gMjEvMDIvMjAyMCAyMjowMiwgV2F0c29uIExhZGQgd3JvdGU6DQo+Pj4gV2Ug aGF2ZSBhbHJlYWR5IGRlcGxveWVkIHdpZGVzcHJlYWQgZXhwZXJpbWVudHMgdGhhdCBjb25kdWN0 ZWQgdGhlDQo+Pj4gaHlicmlkaXphdGlvbiBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCwgYWxyZWFk eSBoYXZlIGltcGxlbWVudGF0aW9ucw0KPj4+IHN1cHBvcnRpbmcgYW4gYXBwcm9hY2ggc2ltaWxh ciB0byB0aGlzIGRyYWZ0LCBhbmQgdGhhdCBwcm9kdWNlZA0KPj4+IHZhbHVhYmxlIGlucHV0IHRv IHRoZSBzdGFuZGFyZGl6YXRpb24gcHJvY2Vzcy4gSXQgcmVhbGx5IGRpZG4ndCBtYXR0ZXINCj4+ PiB0aGF0IGl0IHdhcyBTSUtFIG9yIE5ld0hvcGUgdGhhdCB3YXMgYmVpbmcgaHlicmlkaXplZCwg YW5kIHRoZXkgaGF2ZQ0KPj4+IHZlcnkgZGlmZmVyZW50IGNoYXJhY3RlcmlzdGljcy4NCj4+IA0K Pj4gRG9jdW1lbnRlZCB3aGVyZT8NCj4gDQo+IGh0dHBzOi8vYmxvZy5jbG91ZGZsYXJlLmNvbS90 b3dhcmRzLXBvc3QtcXVhbnR1bS1jcnlwdG9ncmFwaHktaW4tdGxzLw0KPiBodHRwczovL2Jsb2cu Y2xvdWRmbGFyZS5jb20vdGhlLXRscy1wb3N0LXF1YW50dW0tZXhwZXJpbWVudC8NCj4gDQo+IFRo aXMgd2FzIGFsc28gcHJlc2VudGVkIGF0IHRoZSBOSVNUIHN0YW5kYXJkaXphdGlvbiB3b3Jrc2hv cCBpbiBPY3RvYmVyIG9mIDIwMTkuDQo+IA0KPj4gDQo+PiBUYSwNCj4+IFMuDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGlu ZyBsaXN0DQo+IFRMU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Rscw0K --Apple-Mail-58423437-D497-4F61-84C8-9EBDC6F00B66 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE7ww ggTAMIIDqKADAgECAgEGMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3Qg Q0EtMjAeFw0xNzAzMDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExM IENBLTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q 83Uv0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0gvYe HO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2TnQz0TkO jG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342seGy2s9YxNDnS E+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQv77vG DR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8B Af8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJodHRwOi8vY3JsLmxsLm1pdC5l ZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3Aw NAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTFJDQTIwgZIG A1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzAN BgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMB DjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ 91K7e2mA2Nj10W0o5JMHYkaa+ctL8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXh f0nsiY7TWJwAKw4AiO/yJ37/oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZra BjVe7PL95PhS7D+22NffInzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xW hSTQFWlhyA0/kkIi9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF 5IqgIfnSBWIrm3rfLhpZZJ/xJ7Yf6DCCBMAwggOooAMCAQICAQYwDQYJKoZIhvcNAQELBQAwVjEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE3MDMwMjEyMDAwMFoXDTI2MDMwMjIzNTk1 OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNV BAsMA1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKeagw69OR/DuerX2atZrMZpr5DzdS/T4BNdPerqSv5YTEgwhnzsLvhYJxFem87u6/Hse8yx hYAUdb3fBDCGPK3Ecg5mAo0nhWcZUNSX4ojuDSf35mO3eEHceEdty9t735jiPP5fMKIuXY5pi8gI pvG9sFIIu08R5lDrHpNvoQrTKbSC9h4c7eS65j5IkckyW1usuchUvGNms1VLvvNcq+7pDeFJ2REg HuQmARd8v6n/P/an3hsQRnZOdDPROQ6Mb4mrtSVeUVG2+xhwM8RAPdQ2RmxZxeALWFcbxMaSdRwC GUbFWGUqUUuY13vfjax4bLaz1jE0OdIT55dO1vQjkssCAwEAAaOCAZwwggGYMBIGA1UdEwEB/wQI MAYBAf8CAQAwHQYDVR0OBBYEFC/vu8YNHbvpav6sZ/MHOwh29ktZMB8GA1UdIwQYMBaAFP/JyWVM U4DxqQw8Ia6CKsfu+DL7MA4GA1UdDwEB/wQEAwIBhjBnBggrBgEFBQcBAQRbMFkwLgYIKwYBBQUH MAKGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTFJDQTIwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMUkNBMjCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3 EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqG SIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0G CSqGSIb3DQEBCwUAA4IBAQAwlhHAs8n3Urt7aYDY2PXRbSjkkwdiRpr5y0vz/FjxDMgcUjkiP6LJ 2k830oJif/hLLzRPdo2hiQWVLQZFBeF/SeyJjtNYnAArDgCI7/Infv+hEpGC3JGJy9onpGOUcJcE 5qUUvD1S2mh0/j+J0LnWXHOyiVpBmtoGNV7s8v3k+FLsP7bY198ifMt0hvUMF/ng3A5V88iAAG3E fV+FmuNrsSFH1GhTDkTU7qJZoC4//FaFJNAVaWHIDT+SQiL38ddpjSFieFyNxs8+qOnJ8iFIWONe GOoru3bA+tKsEUsVRucuI2WBAeu81gXkiqAh+dIFYiubet8uGllkn/Enth/oMIIE9jCCA96gAwIB AgITWQAAOzl+X6NDoiCtEQAAAAA7OTANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECwwDUEtJMRMwEQYDVQQDDApNSVRM TCBDQS01MB4XDTE4MDgyODIxNDUyOVoXDTIxMDgyNzIxNDUyOVowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCO VXNfUSnP+vZZsIaIAzo48z0G5nPLOmeq8z+qFBwLMAyAqmVsD7fhU2yq9GEwKkTbExDeGIltHzkS vnzUbwpaNKXYgqo9w8A0GS0SOA2pNck7FLVXt+aKJkG17TvtANC/wqMGK4v1CnkRtYtf9HF0n+Jg MdHnfcIdkqK3QG/KNhbjlNAdqaZ6o66NVRboBx1+kDoIGnixTqa0+YJ02VJqjN+/3eAxgfVw3U0I teOM0EsElipGlE4bMg/Qh0kTXAe/Rwb5WRkjPgZCG2sj3YUALs+MirDmRFj8f+i5zKLcwXr0rMJw g3/rvWowoDJ43lm62UTfsaGBLocnF8itm/PzAgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU2VKau0bH HL+NslPVEOML6IzpeKcwDgYDVR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MH Owh29ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBCTAl BgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAZBgNVHREEEjAQgQ51cmlAbGwu bWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAAsjemIYvSwKTj6X+tMqUldlpld7 Kp67K3ZT01vmpuMDCvzP+T2ZreYxVbV2hK5FmHa2zHY3qNqPxvTdg56xToc+5A2DPRwvQB/61gn6 EpCPwtjekav7g50SX2qOtcMr9+6irWpzXZKfq3si8XVT536Faw/1WZYuFFdvLuFwbmA5I1z8soh/ m29/eRZ8TrUwN1M+NToaXb6+qCzxLstCD+DD3yucA5kuhl3Afs3vbGBKfgycRO1gG5FuWOd+lj5f 631pv5OmQtSj1UkTO5kvmrZOOFToMzy15Jek7us2PLTHM36+RdKJtSXzfBudLOEA1BrbDIM1vi11 Q4RQ9uMZ1KIwggU2MIIEHqADAgECAhNZAARpQG+iYKftksc5AAAABGlAMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQL DANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTkwOTI2MTcyODI4WhcNMjQwOTI0MTcyODI4 WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UE CxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1RZEFBMyk8jWMsKZ8Jiy304S613jLwtQGxaJ PmrygWZksBrICa0WWrtSaRBkCt7ko/b4HFRGtJpPpjwp2WEssfX8R0ziHNlyEtGNsGrjpUsViddJ RZU2XlvZbIXWi4EQ5/9b8WxZhCkfgsHUgX8ByKs7kpYb6VANsqULPWKfPKYTQ/UFaApmXO0E1Tlg QShsPFPMERHr0uF1d0N+bGPIubYHlKxBCwo1+FsCbbs3Dk7bEgVxvELvNw7gbeB5xctzlgv6sZsr 4OdeVSvkoO9SC079tH746O1ZEkN3wpe/8J0ViTdkvWTqhihCFPT/Y38DswPqIliJyfWT7L045vFl eQIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFE/OnhhLa8qvqaTEevlxZpxbZqh0MA4GA1UdDwEB/wQE AwIGwDAfBgNVHSMEGDAWgBQv77vGDR276Wr+rGfzBzsIdvZLWTAzBgNVHR8ELDAqMCigJqAkhiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL2xsY2E1MGYGCCsGAQUFBwEBBFowWDAtBggrBgEF BQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvL2xsY2E1MCcGCCsGAQUFBzABhhtodHRw Oi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfs p2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQowLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisG AQQBgjcKAwwGCCsGAQUFBwMCMEEGA1UdEQQ6MDiBDnVyaUBsbC5taXQuZWR1oCYGCisGAQQBgjcU AgOgGAwWVVIyMDk4MEBtaXRsbC5hZC5sb2NhbDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMC0G CSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQEL BQADggEBAJ3UAKXEfsFVTKi480OL2e+3f/qtQuegbw51paVzURtaO7kw6BESDPDo2nOG60VH72BD j4r/X7BhzeItJHb+tJH1BL3NhI0yPlMXGWJzP09vZb7pxhetrXndo/XsSZ/fBSdOFY2u7Cy2FHjt 576JdZNJho5zkI1WeHC9iqs68bQCdWtWj2OtoHqi3jJdp4Du6Sl8Or3quLmrRXZ64gz7bogdiSLw g60ROzXeAm0jA7Pem9wrI3aZAWpf9hsmfmV14tU8iY6rJD7sCon3xMI1wRIYdELNIuA4Y/Xj9xvu XdXSrvgUKCQBuENQsOoz3wsrNu7zl1XvGeJ6Ar0kN9HiPxoxggL0MIIC8AIBATBoMFExCzAJBgNV BAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzAR BgNVBAMMCk1JVExMIENBLTUCE1kABGlAb6Jgp+2SxzkAAAAEaUAwDQYJYIZIAWUDBAIBBQCgggFd MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIyMTIyMjIwNVow LwYJKoZIhvcNAQkEMSIEIGgKsOBdzpWoK+y4hB4ooC/EhIPV7D/niYNShf7ZXYJkMHcGCSsGAQQB gjcQBDFqMGgwUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx DDAKBgNVBAsMA1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAAOzl+X6NDoiCtEQAAAAA7OTB5 BgsqhkiG9w0BCRACCzFqoGgwUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDDAKBgNVBAsMA1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAAOzl+X6NDoiCt EQAAAAA7OTANBgkqhkiG9w0BAQEFAASCAQCrbYtfnvl79IJCkSTAUgDUlrGDbCvRt4cGz6iHoxVu CO3K1xKFIMdhGdegvAhtz4nodlpkNEHwz748DohP93w04t6pC0uHsdCKwG5VZGmm63097N7D6kN0 kChjROp7pyIhemurKSoDrEwSkgPsd5h3zK3WEDB+HLNnCdQYG2mRYj9TJ51YJovgT6SlTrM7tOgz jN0gh8Zs3YW2r2eVLsuEbz81UFl3ifwuskKM1Q5VA5hFHAyqbcXu0D4jsUS26XYIai58Ov0aX4uB DjjLXR7DwelNDCpEBgQcdcJW7+dicFMPDiqaSwzkAzlqzWNP+UMcBcZuhdr2R26k4YBZ1iWfAAAA AAAA --Apple-Mail-58423437-D497-4F61-84C8-9EBDC6F00B66-- From nobody Fri Feb 21 14:26:12 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAECB120142 for ; Fri, 21 Feb 2020 14:25:57 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 oPO9Ehf4ImVG for ; Fri, 21 Feb 2020 14:25:55 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37FD120119 for ; Fri, 21 Feb 2020 14:25:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8FE6EBE3E; Fri, 21 Feb 2020 22:25:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wirsLHfzqwde; Fri, 21 Feb 2020 22:25:48 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8B23BE2E; Fri, 21 Feb 2020 22:25:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582323948; bh=SCxjf89+2RRHcwcul9J1Jj4t29vECgCKMkJPWrRhSeQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ab9BDOZLCxwX8sV7g5IDTtqMfhBILvRZ6z0SVKRt4ADXFkGgJMi6792dd2j+MtuF6 StVYUQ+655vpEyRuC/hnyMXpKPLo+79EAdXZpHDnX+dSpHKRY6oy2/fsVSqA3FXVkC J9rTpSJoZ8AyiGF0cVVXdrt2m9d5bp5ddrN29yGI= To: Watson Ladd Cc: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson , IETF TLS References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> Date: Fri, 21 Feb 2020 22:25:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ttg0b1S2S46hbneP6WE6tRvHPwHG21FnB" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:26:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ttg0b1S2S46hbneP6WE6tRvHPwHG21FnB Content-Type: multipart/mixed; boundary="yTIKmMSdhQWvp0wYOQRWXdUZjI9UAU0Km"; protected-headers="v1" From: Stephen Farrell To: Watson Ladd Cc: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson , IETF TLS Message-ID: <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> In-Reply-To: --yTIKmMSdhQWvp0wYOQRWXdUZjI9UAU0Km Content-Type: multipart/mixed; boundary="------------8A9574095CE72C1C7EB711E4" Content-Language: en-US This is a multi-part message in MIME format. --------------8A9574095CE72C1C7EB711E4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21/02/2020 22:11, Watson Ladd wrote: > https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/ > https://blog.cloudflare.com/the-tls-post-quantum-experiment/ >=20 > This was also presented at the NIST standardization workshop in October= of 2019. Thanks. I read through [1]. It's fine work, but does not convince me that this draft is ready to be an RFC before the "winning" algs are known, as some have characteristics that are quite different from the two that were tested here. I maintain my position that adoption is fine but finishing this before NIST are done is not. Cheers, S. [1] https://csrc.nist.gov/CSRC/media/Presentations/measuring-tls-key-exchange= -with-post-quantum-kem/images-media/sullivan-session-1-paper-pqc2019.pdf >=20 >> >> Ta, >> S. --------------8A9574095CE72C1C7EB711E4 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------8A9574095CE72C1C7EB711E4-- --yTIKmMSdhQWvp0wYOQRWXdUZjI9UAU0Km-- --ttg0b1S2S46hbneP6WE6tRvHPwHG21FnB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5QWOoACgkQWrL68XsX K+q2Dw/+Kp/lDCjjhcws0enYssaQcquEEkY5v3ngfxHbIldaDkSUG/ofAlSPVjVP DlBI7Hlc0+lB4UEcK9t7sfc61Acbdj0/Tsg+bdKnoY/DObQakusZzUlV3rhkd8MA LysQJF+I/dtUYUEqoRZx1fEjleDYFvG0ItaDVOIU5XbBtV0IkA/85Qmc//mcQTO7 b26fSdPF4fNBDq7Qs1cRF0YOxavHzgiZc471x17tdGExgOz1JyhOrQL7q583QtOV K7jVxFjYc96QLxSB9rtFKk7uVy+WYgau6HfKIrjnDk2eDQbvepvOtXpTMy4rruxg OuEZuoeX3NeoDn59P3y/WPgDOAmccQB4d1nSNmGel6+7FNMZAggDgnrYkiCsu/at VxPpsx7E2eqeA54ItsKLPNzQ3Rf0XIjmzAS3r08esbYn150cMD4mPxxMIFBzkTG2 F9O4hhNW3xhckmvFHtbvGR2YYUkpOPCkGHkTbgFWUkTbs7sUCT4UOVWfdtiFFUmC xJxX8QkmO4oYJ2xj91bzl4akiMOfjij71wNnAupKhLADzuduV2l9n4YW1HkEtDEC nDFJUZ1Sc1OsleEPvWi5rUt9g4kB+xiwNJkJl0wVf/yudxBiqtiS9PO8cIKtBsJ0 5DrPrZPchNIJEeIDWKDGFIVDsQJhOCrSeRSsYLs/hAVybcXwjW8= =dKci -----END PGP SIGNATURE----- --ttg0b1S2S46hbneP6WE6tRvHPwHG21FnB-- From nobody Fri Feb 21 14:28:51 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054841200C1 for ; Fri, 21 Feb 2020 14:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 hA6doMeTQUNf for ; Fri, 21 Feb 2020 14:28:48 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3507A12008A for ; Fri, 21 Feb 2020 14:28:48 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id e16so556656qkl.6 for ; Fri, 21 Feb 2020 14:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1t4RP8ti+/cS1lD5Y/Q+7E9pnPHCybplGAq/cjokrk8=; b=mCeiJpniFsfeBkualVdmPc06JphuAjxlvheGQv1RntkXs8FsV6akMcjmvzEeUKRNuh ZHa7expflIPXUgtooZFmqmLLaQZYn/sUwGkDuPLGxnUnjBbBhlpW++BqqiJdLeZN87G6 n6lXtnA0v9nIW4onke6VAlIbWgffSwCK3HDnA= 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=1t4RP8ti+/cS1lD5Y/Q+7E9pnPHCybplGAq/cjokrk8=; b=N/sH2W5JLdEl0IiGVs3kZCS2r5KksozFZHLIb5joAH0FG9nntDY1CYhU1IOyTsLVEF wRp1HGlwfMtCXGl8muoXMYSRPZRtdWuXqK31wUVSk2p2B3eSRCrbn+UTBBgYZi4LpAbJ EblEjvFjVsfTAxtZrply6c80YsymkMPUg/qsM5NtyEdOulcljADAtthArY9MsJDikq6S brExt+5SyvTaHse65nlSX3O/EQ81UQrN19GbJFJziGZv091o+kEGVDWj8T3yY6pdG+93 ipU9mw6Z1z9kkagYNI2c5obnDUiMjMwcMqO2Ep+4cYF4ywOUCngz+RHFisXE+lQ0uULK bGUw== X-Gm-Message-State: APjAAAXVz7wMDKeibs7A5RchUUUREkALT/Nu6TBSme8e9XC0UFzozu1h jh5S2GaGocYdqEJorpXMvfOGqwa1DXf+c7ysLmkTTQ== X-Google-Smtp-Source: APXvYqz/6Dub0jO060idUFFX4w7cWFy9QdxmAqrw/E1AFmGfd6bX7p5u2JImQDdFqiBDoH+d14PteRhDtSWOAVeWsEs= X-Received: by 2002:a05:620a:237:: with SMTP id u23mr34993052qkm.336.1582324127344; Fri, 21 Feb 2020 14:28:47 -0800 (PST) MIME-Version: 1.0 References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> In-Reply-To: <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> From: Watson Ladd Date: Fri, 21 Feb 2020 14:28:36 -0800 Message-ID: To: Stephen Farrell Cc: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson , IETF TLS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:28:50 -0000 On Fri, Feb 21, 2020 at 2:25 PM Stephen Farrell wrote: > > > > On 21/02/2020 22:11, Watson Ladd wrote: > > > https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/ > > https://blog.cloudflare.com/the-tls-post-quantum-experiment/ > > > > This was also presented at the NIST standardization workshop in October of 2019. > > Thanks. I read through [1]. It's fine work, but does not > convince me that this draft is ready to be an RFC before > the "winning" algs are known, as some have characteristics > that are quite different from the two that were tested > here. I maintain my position that adoption is fine but > finishing this before NIST are done is not. How do these characteristics affect the proposal in the draft? And I doubt given the relevant timelines we would finish before NIST is done in any case. > > Cheers, > S. > > [1] > https://csrc.nist.gov/CSRC/media/Presentations/measuring-tls-key-exchange-with-post-quantum-kem/images-media/sullivan-session-1-paper-pqc2019.pdf > > > > > >> > >> Ta, > >> S. From nobody Fri Feb 21 14:31:10 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0076F1200C3 for ; Fri, 21 Feb 2020 14:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 SS55dGdeZ5xd for ; Fri, 21 Feb 2020 14:31:07 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 1FED11200C1 for ; Fri, 21 Feb 2020 14:31:06 -0800 (PST) Received: from LLE2K16-MBX01.mitll.ad.local (LLE2K16-MBX01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 01LMV3SY029164; Fri, 21 Feb 2020 17:31:03 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Stephen Farrell CC: Watson Ladd , IETF TLS Thread-Topic: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design Thread-Index: AQHV6O1N434rvusUuUeVDrTm3f3GWagmfJsAgAACdQCAAAg3AIAAAX4AgAAA7gCAAAP8AIAAAXiA Date: Fri, 21 Feb 2020 22:31:02 +0000 Message-ID: <4466BCEA-E918-423B-B278-48FA7E64705B@ll.mit.edu> References: <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> In-Reply-To: <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-E0B71FCC-AF4C-44B2-B517-090DCB12F9ED"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-21_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002210168 Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:31:09 -0000 --Apple-Mail-E0B71FCC-AF4C-44B2-B517-090DCB12F9ED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WW91IG1heSBoYXZlIGEgcG9pbnQgcmVnYXJkaW5nIGZpbmlzaGluZyB0aGlzIGRyYWZ0IC0gYnV0 IGxldCdzIGNyb3NzIHRoYXQgYnJpZGdlIHdoZW4gd2UgZ2V0IHRoZXJlLiA6LSkNCg0KUmVnYXJk cywNClVyaQ0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCj4gT24gRmViIDIxLCAyMDIwLCBhdCAx NzoyNiwgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90ZToN Cj4gDQo+IO+7vw0KPiANCj4+IE9uIDIxLzAyLzIwMjAgMjI6MTEsIFdhdHNvbiBMYWRkIHdyb3Rl Og0KPj4gDQo+PiBodHRwczovL2Jsb2cuY2xvdWRmbGFyZS5jb20vdG93YXJkcy1wb3N0LXF1YW50 dW0tY3J5cHRvZ3JhcGh5LWluLXRscy8NCj4+IGh0dHBzOi8vYmxvZy5jbG91ZGZsYXJlLmNvbS90 aGUtdGxzLXBvc3QtcXVhbnR1bS1leHBlcmltZW50Lw0KPj4gDQo+PiBUaGlzIHdhcyBhbHNvIHBy ZXNlbnRlZCBhdCB0aGUgTklTVCBzdGFuZGFyZGl6YXRpb24gd29ya3Nob3AgaW4gT2N0b2JlciBv ZiAyMDE5Lg0KPiANCj4gVGhhbmtzLiBJIHJlYWQgdGhyb3VnaCBbMV0uIEl0J3MgZmluZSB3b3Jr LCBidXQgZG9lcyBub3QNCj4gY29udmluY2UgbWUgdGhhdCB0aGlzIGRyYWZ0IGlzIHJlYWR5IHRv IGJlIGFuIFJGQyBiZWZvcmUNCj4gdGhlICJ3aW5uaW5nIiBhbGdzIGFyZSBrbm93biwgYXMgc29t ZSBoYXZlIGNoYXJhY3RlcmlzdGljcw0KPiB0aGF0IGFyZSBxdWl0ZSBkaWZmZXJlbnQgZnJvbSB0 aGUgdHdvIHRoYXQgd2VyZSB0ZXN0ZWQNCj4gaGVyZS4gSSBtYWludGFpbiBteSBwb3NpdGlvbiB0 aGF0IGFkb3B0aW9uIGlzIGZpbmUgYnV0DQo+IGZpbmlzaGluZyB0aGlzIGJlZm9yZSBOSVNUIGFy ZSBkb25lIGlzIG5vdC4NCj4gDQo+IENoZWVycywNCj4gUy4NCj4gDQo+IFsxXQ0KPiBodHRwczov L2NzcmMubmlzdC5nb3YvQ1NSQy9tZWRpYS9QcmVzZW50YXRpb25zL21lYXN1cmluZy10bHMta2V5 LWV4Y2hhbmdlLXdpdGgtcG9zdC1xdWFudHVtLWtlbS9pbWFnZXMtbWVkaWEvc3VsbGl2YW4tc2Vz c2lvbi0xLXBhcGVyLXBxYzIwMTkucGRmDQo+IA0KPiANCj4+IA0KPj4+IA0KPj4+IFRhLA0KPj4+ IFMuDQo+IDwweDVBQjJGQUYxN0IxNzJCRUEuYXNjPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K --Apple-Mail-E0B71FCC-AF4C-44B2-B517-090DCB12F9ED Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE7ww ggTAMIIDqKADAgECAgEGMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3Qg Q0EtMjAeFw0xNzAzMDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExM IENBLTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q 83Uv0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0gvYe HO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2TnQz0TkO jG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342seGy2s9YxNDnS E+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQv77vG DR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8B Af8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJodHRwOi8vY3JsLmxsLm1pdC5l ZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3Aw NAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTFJDQTIwgZIG A1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzAN BgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMB DjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ 91K7e2mA2Nj10W0o5JMHYkaa+ctL8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXh f0nsiY7TWJwAKw4AiO/yJ37/oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZra BjVe7PL95PhS7D+22NffInzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xW hSTQFWlhyA0/kkIi9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF 5IqgIfnSBWIrm3rfLhpZZJ/xJ7Yf6DCCBMAwggOooAMCAQICAQYwDQYJKoZIhvcNAQELBQAwVjEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE3MDMwMjEyMDAwMFoXDTI2MDMwMjIzNTk1 OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNV BAsMA1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKeagw69OR/DuerX2atZrMZpr5DzdS/T4BNdPerqSv5YTEgwhnzsLvhYJxFem87u6/Hse8yx hYAUdb3fBDCGPK3Ecg5mAo0nhWcZUNSX4ojuDSf35mO3eEHceEdty9t735jiPP5fMKIuXY5pi8gI pvG9sFIIu08R5lDrHpNvoQrTKbSC9h4c7eS65j5IkckyW1usuchUvGNms1VLvvNcq+7pDeFJ2REg HuQmARd8v6n/P/an3hsQRnZOdDPROQ6Mb4mrtSVeUVG2+xhwM8RAPdQ2RmxZxeALWFcbxMaSdRwC GUbFWGUqUUuY13vfjax4bLaz1jE0OdIT55dO1vQjkssCAwEAAaOCAZwwggGYMBIGA1UdEwEB/wQI MAYBAf8CAQAwHQYDVR0OBBYEFC/vu8YNHbvpav6sZ/MHOwh29ktZMB8GA1UdIwQYMBaAFP/JyWVM U4DxqQw8Ia6CKsfu+DL7MA4GA1UdDwEB/wQEAwIBhjBnBggrBgEFBQcBAQRbMFkwLgYIKwYBBQUH MAKGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTFJDQTIwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMUkNBMjCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3 EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqG SIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0G CSqGSIb3DQEBCwUAA4IBAQAwlhHAs8n3Urt7aYDY2PXRbSjkkwdiRpr5y0vz/FjxDMgcUjkiP6LJ 2k830oJif/hLLzRPdo2hiQWVLQZFBeF/SeyJjtNYnAArDgCI7/Infv+hEpGC3JGJy9onpGOUcJcE 5qUUvD1S2mh0/j+J0LnWXHOyiVpBmtoGNV7s8v3k+FLsP7bY198ifMt0hvUMF/ng3A5V88iAAG3E fV+FmuNrsSFH1GhTDkTU7qJZoC4//FaFJNAVaWHIDT+SQiL38ddpjSFieFyNxs8+qOnJ8iFIWONe GOoru3bA+tKsEUsVRucuI2WBAeu81gXkiqAh+dIFYiubet8uGllkn/Enth/oMIIE9jCCA96gAwIB AgITWQAAOzl+X6NDoiCtEQAAAAA7OTANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECwwDUEtJMRMwEQYDVQQDDApNSVRM TCBDQS01MB4XDTE4MDgyODIxNDUyOVoXDTIxMDgyNzIxNDUyOVowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCO VXNfUSnP+vZZsIaIAzo48z0G5nPLOmeq8z+qFBwLMAyAqmVsD7fhU2yq9GEwKkTbExDeGIltHzkS vnzUbwpaNKXYgqo9w8A0GS0SOA2pNck7FLVXt+aKJkG17TvtANC/wqMGK4v1CnkRtYtf9HF0n+Jg MdHnfcIdkqK3QG/KNhbjlNAdqaZ6o66NVRboBx1+kDoIGnixTqa0+YJ02VJqjN+/3eAxgfVw3U0I teOM0EsElipGlE4bMg/Qh0kTXAe/Rwb5WRkjPgZCG2sj3YUALs+MirDmRFj8f+i5zKLcwXr0rMJw g3/rvWowoDJ43lm62UTfsaGBLocnF8itm/PzAgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU2VKau0bH HL+NslPVEOML6IzpeKcwDgYDVR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MH Owh29ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBCTAl BgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAZBgNVHREEEjAQgQ51cmlAbGwu bWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAAsjemIYvSwKTj6X+tMqUldlpld7 Kp67K3ZT01vmpuMDCvzP+T2ZreYxVbV2hK5FmHa2zHY3qNqPxvTdg56xToc+5A2DPRwvQB/61gn6 EpCPwtjekav7g50SX2qOtcMr9+6irWpzXZKfq3si8XVT536Faw/1WZYuFFdvLuFwbmA5I1z8soh/ m29/eRZ8TrUwN1M+NToaXb6+qCzxLstCD+DD3yucA5kuhl3Afs3vbGBKfgycRO1gG5FuWOd+lj5f 631pv5OmQtSj1UkTO5kvmrZOOFToMzy15Jek7us2PLTHM36+RdKJtSXzfBudLOEA1BrbDIM1vi11 Q4RQ9uMZ1KIwggU2MIIEHqADAgECAhNZAARpQG+iYKftksc5AAAABGlAMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQL DANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTkwOTI2MTcyODI4WhcNMjQwOTI0MTcyODI4 WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UE CxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1RZEFBMyk8jWMsKZ8Jiy304S613jLwtQGxaJ PmrygWZksBrICa0WWrtSaRBkCt7ko/b4HFRGtJpPpjwp2WEssfX8R0ziHNlyEtGNsGrjpUsViddJ RZU2XlvZbIXWi4EQ5/9b8WxZhCkfgsHUgX8ByKs7kpYb6VANsqULPWKfPKYTQ/UFaApmXO0E1Tlg QShsPFPMERHr0uF1d0N+bGPIubYHlKxBCwo1+FsCbbs3Dk7bEgVxvELvNw7gbeB5xctzlgv6sZsr 4OdeVSvkoO9SC079tH746O1ZEkN3wpe/8J0ViTdkvWTqhihCFPT/Y38DswPqIliJyfWT7L045vFl eQIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFE/OnhhLa8qvqaTEevlxZpxbZqh0MA4GA1UdDwEB/wQE AwIGwDAfBgNVHSMEGDAWgBQv77vGDR276Wr+rGfzBzsIdvZLWTAzBgNVHR8ELDAqMCigJqAkhiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL2xsY2E1MGYGCCsGAQUFBwEBBFowWDAtBggrBgEF BQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvL2xsY2E1MCcGCCsGAQUFBzABhhtodHRw Oi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfs p2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQowLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisG AQQBgjcKAwwGCCsGAQUFBwMCMEEGA1UdEQQ6MDiBDnVyaUBsbC5taXQuZWR1oCYGCisGAQQBgjcU AgOgGAwWVVIyMDk4MEBtaXRsbC5hZC5sb2NhbDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMC0G CSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQEL BQADggEBAJ3UAKXEfsFVTKi480OL2e+3f/qtQuegbw51paVzURtaO7kw6BESDPDo2nOG60VH72BD j4r/X7BhzeItJHb+tJH1BL3NhI0yPlMXGWJzP09vZb7pxhetrXndo/XsSZ/fBSdOFY2u7Cy2FHjt 576JdZNJho5zkI1WeHC9iqs68bQCdWtWj2OtoHqi3jJdp4Du6Sl8Or3quLmrRXZ64gz7bogdiSLw g60ROzXeAm0jA7Pem9wrI3aZAWpf9hsmfmV14tU8iY6rJD7sCon3xMI1wRIYdELNIuA4Y/Xj9xvu XdXSrvgUKCQBuENQsOoz3wsrNu7zl1XvGeJ6Ar0kN9HiPxoxggL0MIIC8AIBATBoMFExCzAJBgNV BAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzAR BgNVBAMMCk1JVExMIENBLTUCE1kABGlAb6Jgp+2SxzkAAAAEaUAwDQYJYIZIAWUDBAIBBQCgggFd MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIyMTIyMzEwMVow LwYJKoZIhvcNAQkEMSIEIKyuXUursX5K1hoaHOPYB3rYR8LByqYbBmzrhA7RhjQlMHcGCSsGAQQB gjcQBDFqMGgwUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx DDAKBgNVBAsMA1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAAOzl+X6NDoiCtEQAAAAA7OTB5 BgsqhkiG9w0BCRACCzFqoGgwUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDDAKBgNVBAsMA1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAAOzl+X6NDoiCt EQAAAAA7OTANBgkqhkiG9w0BAQEFAASCAQAvT6pegSIyBrLptyJ+Xpi/3q+7bp1Cb4MWRs+ipf4i IoR6pnH/tmSthx0553iZIBx84oYEGKKGGUQzqHCgO1nImPTajS6AS3gaFQyb5bhHiFM5/uxuS2Zl pgcLGT+lXHf/rCUQ/rWJgMJUu8IMkmYwj0I5VdSOOd05bZUu2Mp/5ycNTdeMOQfWoNLT2kJ6LPyF jCXLp3t4XyMP7DByA7e2jjt5D4aLfAyoSDPy9ZXh//fUKZBIL9AkCNAaVX/aI09D5U4BBNooC40b 7oEpGMvx90+8e8j7XVLMurO3H2LePBsviLkTsCi7fh1/ZD9s6YsOivZQjWDqNynEInEpFAneAAAA AAAA --Apple-Mail-E0B71FCC-AF4C-44B2-B517-090DCB12F9ED-- From nobody Fri Feb 21 14:38:04 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AF41200C3 for ; Fri, 21 Feb 2020 14:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 Nmiz8I0HGsD5 for ; Fri, 21 Feb 2020 14:37:58 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E26120810 for ; Fri, 21 Feb 2020 14:37:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 51FBBBE2F; Fri, 21 Feb 2020 22:37:56 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqLRNt53mFUC; Fri, 21 Feb 2020 22:37:54 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 83E1CBE2E; Fri, 21 Feb 2020 22:37:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582324674; bh=djKRwGrI6QxAGTSx8/T7hJsnKjcO4F7wPKWzoLyyMJA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=wC64Ar6QwEojbzTNzuEr8ydJBiSHkBN2MJ+VgdIuvNeuWnc9HD9BYeDyIJ8uon00I iBw0e9AkkNNRgf7optghkMhEvJaanZj7F9m6wcm2AvQGGn7Jagnsy5l1i0HaKqOE1A v9cJJ+GcfeXU9eKOxN/fBk4nv01ubeLgNfxFUgtA= To: Watson Ladd Cc: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson , IETF TLS References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 21 Feb 2020 22:37:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="N3Fj28RgHV17CAaLcgRK3MLyqftz7zphi" Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 22:38:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N3Fj28RgHV17CAaLcgRK3MLyqftz7zphi Content-Type: multipart/mixed; boundary="PM9EgqQCu1DIh4hLinr966y6ShSVp3LZw"; protected-headers="v1" From: Stephen Farrell To: Watson Ladd Cc: "Scott Fluhrer (sfluhrer)" , Russ Housley , Martin Thomson , IETF TLS Message-ID: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> In-Reply-To: --PM9EgqQCu1DIh4hLinr966y6ShSVp3LZw Content-Type: multipart/mixed; boundary="------------1DB15BC5A715BD9FA57C2AC0" Content-Language: en-US This is a multi-part message in MIME format. --------------1DB15BC5A715BD9FA57C2AC0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/02/2020 22:28, Watson Ladd wrote: > How do these characteristics affect the proposal in the draft?=20 I don't know. There are 17 of them. I'm not spending the time on this myself 'till there are a small number of winners. Speculating though, NIST often end up with a load of variants - if they do that again variant#1 of winner#1 might be usable with variant#2 of that same alg being no good at all. So I could see the definition of code points being wrong if done prematurely. (I remember the NULL algorithm parameter non-interop for RSA way back when and that was after the ASN.1 had existed for some time;-) I'd bet there'll be other issues discovered along the way as well. > And I > doubt given the relevant timelines we would finish before NIST is done > in any case. Great. In that case you must find my position fine, no? :-) All I'm asking is that we adopt with the explicit understanding that the WG don't request publication until the NIST winners are known. That is a weird ask, but I think justified in this case. The "Winner all right" call there can be left to the WG chairs - I'm not asking to wait for the final FIPS or whatever else NIST do to add another year or so to the endgame;-) Cheers, S. --------------1DB15BC5A715BD9FA57C2AC0 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------1DB15BC5A715BD9FA57C2AC0-- --PM9EgqQCu1DIh4hLinr966y6ShSVp3LZw-- --N3Fj28RgHV17CAaLcgRK3MLyqftz7zphi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5QW78ACgkQWrL68XsX K+qxDg//fAXQVyi84Mt5Gas5QYZPeiNXmm17jR4fUk4feeQpzkyuFAWR42oSexh3 i+DAatGEabiHXiCejfQoXhk2y+ZFS4ppFnmCCYRR02eMBLTRIj2fy4Ky5ouOd5ha TEEGMPIvSmNCdszU0tSjCj2OWtrlBKLJ8DRGiwe7AjjJn57QP6+XJU4lxiBZR9gY NIqzOwFUX8syGdOY2rt7uV8JB7nuWSn6aGbAaKVJn0bEBE2PEBJCJXUC+zAiwgix /Puosh6zLGpdRqBzGYM9Z+UFINLLVHJajG3uckGj+8ssn76SbTB3tDqjXfToe5P6 xPQcLo485+ToNXYckDuAxImHIWONGrEnJyxtjrXG/k8bjTiAhE08XJcLleoLdwW7 niuY6QDOIxop7Vw7rm2J1z1uHsvtkSvRnKU0h7FanPO3EPDFZ+poT7YRzbVLrxWv /hU5fOp2y0SwBN+IMj4fCx5FW8HlvEVBLQM65ihmU9cM96IEs3qerOF3oSHoamGm lQpATK5NwwbYEoOn4oOxAYJsBN111m2tNQ11N3sKNGmlWQ3YrgVDuhbEv6Aef45e 5JO2nIi318TKkoBZD1IsUzfXYUfZCURUcCRB9ZFXK/nPIsVbADBT4lBlGqXOYvuR NSiJUUB/Lc4om6QVM1YRRMKjJ1cFbc3tQJDRzRu6YA19g9r0DxU= =Uj2i -----END PGP SIGNATURE----- --N3Fj28RgHV17CAaLcgRK3MLyqftz7zphi-- From nobody Fri Feb 21 15:21:33 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B90C1200F3 for ; Fri, 21 Feb 2020 15:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsiOS6rEXcL2 for ; Fri, 21 Feb 2020 15:21:30 -0800 (PST) Received: from mr85p00im-hyfv06011301.me.com (mr85p00im-hyfv06011301.me.com [17.58.23.184]) (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 0DCB31200E5 for ; Fri, 21 Feb 2020 15:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1582327288; bh=pga+toeP2K7FIPs3GpfSNe3syGWbbvTUvxTnhXfCDsE=; h=Content-Type:Subject:From:Date:Message-Id:To; b=lWuy2PpAfO259EZQRkINmbfaP+V2f7K0xr1bjIJXlvQWvQUrpDJWTduLPyu/hDYry QClyrqZ67RucYtnk3ZlgvE6ZLOf9QJ61yaFFP9GcgDXcsmvZb1sG5SqUNtk8SSMsaA 7alG9n6nbTd/sthnjlIDVSR19KNvecZfaIGCEA9ZxjdMs4yBu7vRvClyBF8HvYhPzT pFjLFkYRguQqNfWtyQK/wAhSIDcc9lT0jDfptpNOOKu7UNZ+vLfgMgKmmP1O5WUjOd tAQIPsYKxc+GROGRXAMyjhGvqiGJc6lpEwjomx1zENJ8AvTLHY3xKUVCMsLvs0jAmX szxC2vCslPKzw== Received: from [17.230.163.14] (unknown [17.230.163.14]) by mr85p00im-hyfv06011301.me.com (Postfix) with ESMTPSA id 93DCB5804A2; Fri, 21 Feb 2020 23:21:28 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.3\)) From: Carrick Bartle In-Reply-To: Date: Fri, 21 Feb 2020 15:21:27 -0800 Cc: Watson Ladd , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <1C9EE750-B116-43E8-8B65-2FC264E89C41@icloud.com> References: To: "Blumenthal, Uri - 0553 - MITLL" X-Mailer: Apple Mail (2.3608.80.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-21_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=869 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2002210175 Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 23:21:31 -0000 > I agree with Watson's reasoning. Same. > On Feb 21, 2020, at 2:22 PM, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > I agree with Watson's reasoning. >=20 > We know now all we need to to start working on generic mechanisms. >=20 > Regards, > Uri >=20 > Sent from my iPhone >=20 >> On Feb 21, 2020, at 17:11, Watson Ladd = wrote: >>=20 >> =EF=BB=BFOn Fri, Feb 21, 2020 at 2:08 PM Stephen Farrell >> wrote: >>>=20 >>>=20 >>>=20 >>>> On 21/02/2020 22:02, Watson Ladd wrote: >>>> We have already deployed widespread experiments that conducted the >>>> hybridization described in this draft, already have implementations >>>> supporting an approach similar to this draft, and that produced >>>> valuable input to the standardization process. It really didn't = matter >>>> that it was SIKE or NewHope that was being hybridized, and they = have >>>> very different characteristics. >>>=20 >>> Documented where? >>=20 >> https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/ >> https://blog.cloudflare.com/the-tls-post-quantum-experiment/ >>=20 >> This was also presented at the NIST standardization workshop in = October of 2019. >>=20 >>>=20 >>> Ta, >>> S. >>=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 From nobody Sat Feb 22 09:57:51 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BCA3A053E; Sat, 22 Feb 2020 09:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 GuIwjXWu3g_g; Sat, 22 Feb 2020 09:57:21 -0800 (PST) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816B13A053F; Sat, 22 Feb 2020 09:57:21 -0800 (PST) Received: by mail-yw1-xc2c.google.com with SMTP id f204so3163648ywc.10; Sat, 22 Feb 2020 09:57:21 -0800 (PST) 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=NEEQagSV/x8YSoP51AKzrXJqXpOdwfatLpL8VeDDyF8=; b=S5V6qS9As3g+EJFM1Ot6ozLaKF893g8GHlklJZ3VlqRm0AINVYg1hbgNIt9vlVrOLc UcDgPTkQa4SmvuitWhKdRevhVFIjnhAxM7XvCdYa95tk6DwzUw/bSTXH12S5Vz/JP91i i5Gv4Tn3bGFKvaOocvKb+EnznAoc5C5kScLjXmulhpN0U1nPg+FKY1Fwddav2gMopvll ezd2na9XySI3GtBUofGtlaU3UQWkUD8WRFu/mbw1Lc4Pb9mnwh4Yk9Amm4Wn3sjO8D4r U6tMUMiOo4uZMN8IVhSew6KsH1kjMyp7/tsL3iD2yfie0bWd83BELdGgM6h+GYZ/qrrX L9Rw== 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=NEEQagSV/x8YSoP51AKzrXJqXpOdwfatLpL8VeDDyF8=; b=mGl4/RFqbNNyYvf83epEjyesrqXiRib1oms9C9ij9k0n9mkYihKWlNWccN4piu8cfL D4N5oA+WEV4KBwV8Nxgb9uWp9Z568rn7bwBzkhCPDeuDhGeHH7fCAgTO/xf9ERBYDIg0 C2IOC4D0B06buN/X8fddFGg+JauhYggCdbxPM7MH48+v5KZdqn17dOSWAr8Y4gCGAAf4 7kkaHJiPAlKT6MxrPyp6geimJ9O+FeEQ25GncFQnVfyX5rcNbaCBJQWbLfDi1khFrgdf KFONPg90pLAaTkOaaIMrV0uKrO3ubNZi2WswrX0x5ImnrC2X6/oQuk8rN4qfmGkbzhjk Ch2w== X-Gm-Message-State: APjAAAW+I6wbqBJfWLiEfWSm32qdR76LqIZZ/K7jOwWsgNhJw/PjtjcM lCkOlGMZ3HoCEvMXCdXaaIXVVfvHlthH8mpXmvJ+czot X-Google-Smtp-Source: APXvYqyOZR9VjQrXORj9fFzf52Wx/H7QYnU4osepy4KTVtz6GCT5QnVsCZlSFBuv9bAwgBwofX5/DPCXQhLX0KMaLto= X-Received: by 2002:ab0:74c8:: with SMTP id f8mr20481655uaq.114.1582390491500; Sat, 22 Feb 2020 08:54:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Sat, 22 Feb 2020 11:54:40 -0500 Message-ID: To: saag , tls , IPsecME WG , NVO3 , sfc@ietf.org, int-area , t2trg@irtf.org, tsv-area@ietf.org Content-Type: multipart/alternative; boundary="000000000000245448059f2cff2c" Archived-At: Subject: Re: [TLS] Netdev 0x14 co-located with IETF107 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 17:57:23 -0000 --000000000000245448059f2cff2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Just to follow-up with Netdev 0x14 co-located with the IETF. The schedule has been announced [1], and the schedule [2] published. You can even filter according to your own interests (AI, container, DDoS, driver, IoT, kubernetes, L2, L3, wireless, security, ... and many more!). Please have look and check here ! Check out registration information here [3] Yours, Daniel [1] https://netdevconf.info/0x14/news.html?schedule-up [2] https://netdevconf.info/0x14/schedule.html [3] https://netdevconf.info/0x14/registration.html On Thu, Feb 13, 2020 at 8:35 PM Daniel Migault wrote: > Hi, > > This is just to let you know that Netdev 0x14 is back co-locating with > IETF 107 in > Vancouver. There are several security related talks that may be of > interest. > > Note: Early bird registration is still open until 17th and that many othe= r > talks, sessions, workshops are also happening > https://netdevconf.info/0x14/accepted-sessions.html > > 1) Performance study of kernel based TLS handshakes > > https://netdevconf.info/0x14/session.html?talk-performance-study-of-kerne= l-TLS-handshakes > > 2) TLS performance characterization on modern x86 CPUs > > https://netdevconf.info/0x14/session.html?talk-TLS-performance-characteri= zation-on-modern-x86-CPUs > > 3) Kernel based TLS Hardware offload > > https://netdevconf.info/0x14/session.html?talk-kTLS-HW-offload-implementa= tion-and-performance-gains > > 4) Addressing DDoS: Issuing SYN cookies in XDP > https://netdevconf.info/0x14/session.html?talk-issuing-SYN-cookies-in-XDP > > 5) Security and Control of SR-IOV: What=E2=80=99s Our Responsibility if = the > Kernel is Bypassed? > > https://netdevconf.info/0x14/session.html?talk-security-and-control-of-SR= -IOV > > Yours, > Daniel > > --=20 Daniel Migault Ericsson --000000000000245448059f2cff2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Check out registration information here=C2=A0[3]

Yours,=C2=A0
Daniel=C2=A0

[1]=C2=A0https://netdev= conf.info/0x14/news.html?schedule-up


On Thu, Feb 13, 2020 at 8= :35 PM Daniel Migault <mglt.ietf@= gmail.com> wrote:
Hi,=C2=A0

This is= just to let you know that Netdev 0x14 is back co-locating with IETF 107 in=
Vancouver. There are several security related talks that may be o= f interest.

Note: Early bird registration is still open until 1= 7th and that many other talks, sessions, workshops are also happening=C2=A0=
https://netdevconf.info/0x14/accepted-sessions.html=C2= =A0=C2=A0

1) Performance study of kernel based TLS handshakes
https://netdev= conf.info/0x14/session.html?talk-performance-study-of-kernel-TLS-handshakes=

2) TLS performance characterization on modern x86 CPUs
https:/= /netdevconf.info/0x14/session.html?talk-TLS-performance-characterization-on= -modern-x86-CPUs

3) Kernel based TLS Hardware offload
https://= netdevconf.info/0x14/session.html?talk-kTLS-HW-offload-implementation-and-p= erformance-gains

4) Addressing DDoS: Issuing SYN cookies in XDP<= br>https://netdevconf.info/= 0x14/session.html?talk-issuing-SYN-cookies-in-XDP

5)=C2=A0 Secur= ity and Control of SR-IOV: What=E2=80=99s Our Responsibility if the
Kern= el is Bypassed?
http= s://netdevconf.info/0x14/session.html?talk-security-and-control-of-SR-IOV

Yours,=C2=A0
Daniel



--
Daniel Migault
Ericsson
--000000000000245448059f2cff2c-- From nobody Sat Feb 22 23:32:33 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1243A0FBA for ; Sat, 22 Feb 2020 23:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=HzzLW+EF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=v41/cOF2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO-WnAXLdyTh for ; Sat, 22 Feb 2020 23:32:27 -0800 (PST) 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 00A2D3A0F97 for ; Sat, 22 Feb 2020 23:32:26 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4180321443 for ; Sun, 23 Feb 2020 02:32:26 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 23 Feb 2020 02:32:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=f9W4WJmlmNM+hq87F2yJPQuHe+KDZxxx+YhS8VCIbTo=; b=HzzLW+EF o1bZu3Qy+AMFTUVioLL5lBcJ7N7l1Fgxt96SARpcdo/aZEzML3Y0b9vMgmOWNZLP ejsuzn5ACZdVIAzMYaLpBkrNDzfJ+IcMC5jZFJe13h4KXm4z2/+WnGi8ucgxX2Z2 b7SKmHsoAbG0/PnnQX1KUKTQlqd3HL6pim7lUiOd/w+V1/GRhQgm4b/LQTNwHBNJ YFiozU8Y+/mvel2IiI9lPETYggvXMxaqF/W4QMWFMW9B0mLh4Xi7IhuJMoXLugoe pw73Si1vlPPGKtx+rMkzCIj5j1vHZD7G9p/EXSMZ1eHQYg/hUfPEBxz6+EIjnVkg hWnjy0WgwY2FZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=f9W4WJmlmNM+hq87F2yJPQuHe+KDZ xxx+YhS8VCIbTo=; b=v41/cOF2HSKCGj4xMFVvioFEO7IXxwNS+3PgY6bwYCZcM nHlz4DSjM4LO7c/WurR2fBuMKmFr5JD34nzXE9wBn3bRkpbPKUQP1BSB/8s6UDDV yAUp6Kcta6hkBX3lJZ+8EtxSu2k2Dl45U6rn+EP+y/c5i4TTmqawEjrsZvzB7NVX 6ZuI6VexO0/Rw1PrzmfS7KXQah+J1BBP7G/Lus/SusAPeePGbFcHf4H59Tm5++vk w3GuBxN0l+PfhsOcBVwrUyPKqKLEr8sw4alU4Dle+m1gntjUT1F52f0fPQM1RPxM U8CxjI6IbrQ/RXib5Bf8ylyy0TfHtzu0aSv2CzKEw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeejgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepudefrdeikedrvddvtddrudejvdenucevlhhushht vghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [13.68.220.172]) by mail.messagingengine.com (Postfix) with ESMTPA id 0E9653060F9B for ; Sun, 23 Feb 2020 02:32:26 -0500 (EST) Content-Type: multipart/alternative; boundary="===============1271563910185008053==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200223073226.0E9653060F9B@mailuser.nyi.internal> Date: Sun, 23 Feb 2020 02:32:26 -0500 (EST) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 07:32:32 -0000 --===============1271563910185008053== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC2) 1 issues created: - Address issues in -06 raised by Ilari Liusvaara (by grittygrease) https://github.com/tlswg/tls-subcerts/issues/53=20 1 issues received 2 new comments: - #31 Point to Formal Analysis (2 by grittygrease, siyengar) https://github.com/tlswg/tls-subcerts/issues/31=20 Pull requests ------------- * tlswg/draft-ietf-tls-semistatic-dh (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Remove changes to the key schedule. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-semistatic-dh/pull/7=20 * tlswg/tls-flags (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Add IANA expert guidance (by yoavnir) https://github.com/tlswg/tls-flags/pull/3=20 * tlswg/tls-subcerts (+3/-2/=F0=9F=92=AC0) 3 pull requests submitted: - Minor tweak to OID format. (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/55=20 - Nick/53 (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/54=20 - adding markers (by seanturner) https://github.com/tlswg/tls-subcerts/pull/52=20 2 pull requests merged: - Nick/53 https://github.com/tlswg/tls-subcerts/pull/54=20 - adding markers https://github.com/tlswg/tls-subcerts/pull/52=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============1271563910185008053== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday February 23, 2020

Issues

tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC2)

1 issues created:

1 issues received 2 new comments:

Pull requests

tlswg/draft-ietf-tls-semistatic-dh (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

tlswg/tls-flags (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

tlswg/tls-subcerts (+3/-2/=F0=9F=92=AC0)

3 pull requests submitted:

2 pull requests merged:

Repositories tracked by this digest:

--===============1271563910185008053==-- From nobody Sun Feb 23 19:57:50 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DEC3A0991 for ; Sun, 23 Feb 2020 19:57:49 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=heapingbits.net header.b=TycZKrYJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A9yuc+f8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiGECaUblAKY for ; Sun, 23 Feb 2020 19:57:47 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2663A098F for ; Sun, 23 Feb 2020 19:57:47 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7C4BB490 for ; Sun, 23 Feb 2020 22:57:46 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Sun, 23 Feb 2020 22:57:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=83M8O KYdOpv1KeMWnDBSmV/XZ62Y+H0FS0qbdNDzKJU=; b=TycZKrYJ6KVsdqVrDbi5h +BiCQk3v7T6zV6vJLVqbHWpuDZgyIkncp4J06KMkkcLw/yBB0V/PxXb1aRGrrqsQ SPDq7/EzMZkliBJ6LS8SNr4r9u7lirGvDh61/igUG6Vt9x/Z6KDq7lVyDIIO/IBQ ZC83xL6RRJwF/9yfrDxUZ+f7lMfKEcmLQttpMBLVrJxV+QyTOer+obXjzYitF2+J +59uuYa3YJn07CsjDL7jpWL+gIn0JRbYuENsyppXRe45Pj4xhoVxkQksjipzSjqm bnbZNck6LAOR/fp/Q57dFvDFCMeLsrOt7OnfkbUcWfQrCTkjmF+6sPkgOzsgycug A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=83M8OKYdOpv1KeMWnDBSmV/XZ62Y+H0FS0qbdNDzK JU=; b=A9yuc+f8ydciqv4OtH4gIDNFZzynmez2UOopTGmaAgLbK7SyyYECUWkbm c7odBpReBBDxQXs3Mb+yJg/U1loQNxDcVJWvCPRjHqR2vP14lszEfQCbAmesp+i9 n3UTqcNLvZRhJ11aPBo9bLXaTxgrnXzFsHTdKxlegjwaY0ojxn0EOfrVx1c9sXf4 qvZCq/zWKSmzYlHyDKkqz3zmVoCf5s7/qakOkYxq9YdawMMfyRHo+JT7gksR62tD FWF7zGOENiiWyCZRUT2ssuVoGbNIfNZ+up3h7cx3JkqQcFGU+9ARTWKazoxrQMNG Eucv3FeEcYyyU1TYXhxiT4r1MUcgA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeelgdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C65423C00A1; Sun, 23 Feb 2020 22:57:45 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmstable-20200220v2 Mime-Version: 1.0 Message-Id: In-Reply-To: <412affff-54a9-d244-886b-ea44ad972c94@cs.tcd.ie> References: <412affff-54a9-d244-886b-ea44ad972c94@cs.tcd.ie> Date: Sun, 23 Feb 2020 19:57:24 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] ESNI/ECHO updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 03:57:49 -0000 Sorry for the delay in updating you (and others). Here=E2=80=99s the cur= rent status.=20 We=E2=80=99re actively analyzing ECHO. As of now, we expect this to comp= lete in March, unlikely before the Vancouver meeting. No red flags have = been discovered thus far. However, we are updating the tunnel PR and hop= e to post (and merge) it before the deadline. That will give folks enoug= h time to update implementations and discuss any remaining issues before= proceeding with the document. Best, Chris On Mon, Feb 17, 2020, at 5:00 AM, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 15/02/2020 00:17, Rob Sayre wrote: > > Hi, > >=20 > > Are there any updates to ESNI/ECHO to share as a draft or an update?= >=20 > I'm also interested:-) >=20 > >=20 > > It's been a few months, so just wondering (even if there's not much = to say). >=20 > I did some initial hacking on a branch of my openssl fork > to see how hard the inner CH stuff might be. [1] Turns > out it's doable but there are some wrinkles with handling > extensions that might be good to discuss on the list to > improve our chances of interop. >=20 > There are some notes at [2] - the ones I think might > benefit from list discussion are: >=20 > - PSKs - I ended up just putting the PSK extension in > the inner CH (with binder calculated over the inner CH) > and putting no PSK extension in the outer CH at all. > That seems right for tickets, but I'm not sure for > cases where the PSK isn't a ticket. Trying to support > PSKs in both inner and outer seems pretty complex and > likely hard to use as well. >=20 > - I'm not sure what to do about the TLS key share > (and supported groups) - in principle it might make > sense for those to vary between inner and outer CH, but > that'd not be very useful today, and could need a lot > more code changes (I've not yet played with it) - if > it made sense to punt on that for the first version of > an ECHO RFC and just say different key shares MUST NOT > be used in inner and outer that might be good, even if > it's a little smelly. OTOH, it might be better to bite > the bullet now, for better support for the split mode > scenario, e.g. if the "front" server had more up to > date algorithms or something. >=20 > - I implemented support for varying ALPN between inner > and outer and that wasn't hard and seems to make sense. > A consequence is that the EncryptedExtensions with the > ALPN from the server then also need (record layer) > padding. Hopefully, supporting different inner and > outer ALPNs doesn't need much list discussion but it > would be a change from earlier drafts. And one might > wanna put something in the HTTPSSVC or ESNIConfig for > this I suppose, not sure. >=20 > - inner CH padding - we're no longer just padding the > (E)SNI but the entire inner CH so the padded_length in > the ESNIConfig kinda makes (even:-) less sense to me. > I'm not sure if padding the outer CH is still needed > for something though. >=20 > Note that I've only looked at the extensions supported > by the OpenSSL build I'm using - there are some more > in the IANA registry that might or might not need a > bit of thought. And there are a bunch where it might > (in principle) make sense for 'em to vary between > inner and outer CH, but where I suspect there'd not > be enough payoff to call for it to be supported. > (Some of those are noted at [2].) >=20 > Cheers, > S. >=20 > [1] https://github.com/sftcd/openssl/tree/encch > [2] > https://github.com/sftcd/openssl/blob/encch/esnistuff/echo.md#extensio= n-specific-handling >=20 > >=20 > > thanks, > > Rob > >=20 > >=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 > Attachments: > * 0x5AB2FAF17B172BEA.asc > * signature.asc From nobody Mon Feb 24 01:36:06 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4923A09CA for ; Mon, 24 Feb 2020 01:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=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 kwVu2aMfbYga for ; Mon, 24 Feb 2020 01:36:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908EC3A09C6 for ; Mon, 24 Feb 2020 01:36:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 737E5BE39; Mon, 24 Feb 2020 09:36:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8NfG5NwAUE6; Mon, 24 Feb 2020 09:35:59 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C6871BE2E; Mon, 24 Feb 2020 09:35:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1582536958; bh=DlYw9Wj/Sw/vi8mxMPV7whxEOI/q5Gx3zsUtF0BvWIA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=J96JRRPOR1h+MxNRNtlHY0AqN4YmaZC0O6ORd5VzbBN2x/tgdi3T0SxvtPN+y3+Ys iASWJRuuA+kK8EBa2f26J0DaI/4ldGiKqLTwnkSQN9Ca7/RSKXMu+kD4vfKrBuc2dg Z0MYtsJAwfhiIQBlzIESWAI0IY3zLFze/DTD5piU= To: Christopher Wood , "TLS@ietf.org" References: <412affff-54a9-d244-886b-ea44ad972c94@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <25f2f45a-2290-53ef-75e9-f4cb0967944c@cs.tcd.ie> Date: Mon, 24 Feb 2020 09:35:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="maLGpmm1YCREpjtXEOtlg1HJI8HMnVuSn" Archived-At: Subject: Re: [TLS] ESNI/ECHO updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 09:36:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --maLGpmm1YCREpjtXEOtlg1HJI8HMnVuSn Content-Type: multipart/mixed; boundary="YmYUYuMBisOQPLyYD1d2PBOzoErZvMzi2"; protected-headers="v1" From: Stephen Farrell To: Christopher Wood , "TLS@ietf.org" Message-ID: <25f2f45a-2290-53ef-75e9-f4cb0967944c@cs.tcd.ie> Subject: Re: [TLS] ESNI/ECHO updates References: <412affff-54a9-d244-886b-ea44ad972c94@cs.tcd.ie> In-Reply-To: --YmYUYuMBisOQPLyYD1d2PBOzoErZvMzi2 Content-Type: multipart/mixed; boundary="------------2D370A30AA71C6A7509D7D5A" Content-Language: en-US This is a multi-part message in MIME format. --------------2D370A30AA71C6A7509D7D5A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 24/02/2020 03:57, Christopher Wood wrote: > We=E2=80=99re actively analyzing ECHO. As of now, we expect this to com= plete > in March, I would welcome seeing that done in a more open manner. S. --------------2D370A30AA71C6A7509D7D5A Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------2D370A30AA71C6A7509D7D5A-- --YmYUYuMBisOQPLyYD1d2PBOzoErZvMzi2-- --maLGpmm1YCREpjtXEOtlg1HJI8HMnVuSn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5TmP4ACgkQWrL68XsX K+rBtQ//QYHD8dzr26MTb1casyZLmzg4CmSXxL9WpJ/+54suNWPggumQQIfjYut9 lTAK207t2VkBNCl834PWCBP50y4VBpURlNVqQZrDZp2EGqpqiZT275g2S67R75Op QwJnbM+xgkDzn5S3v+3+9C2vCQB4JZ26SHLVkaWSQoBMPFlOvnkOUR9W83javK8v Tbj7nqF+aZFDdmiY2XqZ1Tp/NuFzNvVna+J5IXwzt8MfLSzJ3Qdk6E4eck31t0Cw 0sMfGRmQ0Ts6OgUlzmz5XZP73IPQjqY1YkWFY6awT4y3rhF/zohjMmw8ez3zy/Kf Mkv8lRGhCATbM1dnQuNED0QVsYNFyFVEBt417tdHtMbYDolaIlgAoV8ZDubKUOAz x9YaoJ7ezWfjgbnKokzlKOFS2bvk3c5830zUnL9KZVPB8WNQ7ReEAl/es4EY73jI 5PqwBYkfrTqn1yb93jJL9Ic9nKo8jvnOikh48myKzARW8MDxu9ZMm0Nh91SDYKQ0 zWnwA5qrr5aDQFgvigG12xe51BQXdBdpLVd+mgY2tKQnZvSE6SFEFR7QMmJK9Zfo aMDlHSMXQ7SOtYMbgWLNvhqcpvTMEFmTRbywnM2NIeIzD3Ape+ym5h59aq2UW2iE rnsrR0z2JEY4dpJGZPKyMz6/yNnVfpAnwJvNKYJ23i8YsZ9CIjc= =sNOI -----END PGP SIGNATURE----- --maLGpmm1YCREpjtXEOtlg1HJI8HMnVuSn-- From nobody Mon Feb 24 08:13:32 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32423A0EB7 for ; Mon, 24 Feb 2020 08:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nHRj0oxanaj2 for ; Mon, 24 Feb 2020 08:13:28 -0800 (PST) Received: from smtp-pg11.blackberry.com (smtp-pg11.blackberry.com [68.171.242.227]) (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 B58AD3A0EBD for ; Mon, 24 Feb 2020 08:13:28 -0800 (PST) Received: from pps.filterd (mhs401ykf.rim.net [127.0.0.1]) by mhs401ykf.rim.net (8.16.0.27/8.16.0.27) with SMTP id 01OG2eBB143847; Mon, 24 Feb 2020 11:13:27 -0500 Received: from xch210ykf.rim.net (xch210ykf.rim.net [10.2.27.110]) by mhs401ykf.rim.net with ESMTP id 2yb0ea4j00-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 24 Feb 2020 11:13:27 -0500 Received: from XCH210YKF.rim.net (10.2.27.110) by XCH210YKF.rim.net (10.2.27.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Mon, 24 Feb 2020 11:13:26 -0500 Received: from XCH210YKF.rim.net ([fe80::ac8d:3541:704c:478a]) by XCH210YKF.rim.net ([fe80::ac8d:3541:704c:478a%5]) with mapi id 15.01.1847.003; Mon, 24 Feb 2020 11:13:26 -0500 From: Dan Brown To: Joseph Salowey , "" Thread-Topic: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design Thread-Index: AQHV4pDu9Go5DG3bvEWKQxVxFPuB4agqfwvw Date: Mon, 24 Feb 2020 16:13:26 +0000 Message-ID: <5f2869e8978a4602be3dade68ec5ec3a@blackberry.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [100.64.97.242] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_000E_01D5EB03.6E3E8D00" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-24_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002240128 Archived-At: Subject: Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 16:13:31 -0000 ------=_NextPart_000_000E_01D5EB03.6E3E8D00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01D5EB03.6E3E8D00" ------=_NextPart_001_000F_01D5EB03.6E3E8D00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I support rapid adoption, if only based on general principles, as elaborate= d below. =20 *** =20 I have not studied the draft in detail, but I think that strongest-link sec= urity is important to allow, the sooner the better, for those that can affo= rd it, I think the benefit is worth cost. =20 I think that the how-to of strongest-link is straightforward enough to star= t working on it, and I trust the draft authors to have done a good job at i= t. Any subtleties or optimizations of strongest-link crypto can be perfect= ed as they arise. =20 I would also favor using both ECC and PQC, (a) _after_ NIST PQC is done, (b= ) _before_ a Shor-capable QC arrives. I=E2=80=99m hoping the time of (a) <= (b), and therefore hybrid should be ready to roll out. =20 I would also favor adding PQC support to TLS _before_ even NIST PQC is done= , then just switching over to NIST choices at the time, even though this se= ems not to be the interpretation consensus opinion, e.g. CFRG opted to wait= for NIST. I agree waiting for NIST is sensible, if one want the best PQC = protection, but not to the point of delaying having any PQC protection, see= next point. =20 Getting details right is a known difficulty, with mistakes inevitable. Has= te makes waste, sure, but delay is deadly, so let=E2=80=99s get to debuggin= g the details right away. Bugs are a nuisance, but better than nothing. =20 I realize that anybody worried about Shor-capable QC, can add a PQC out-of-= band to official TLS, but I understand TLS to offer many benefits as securi= ty protocol, such that adding in PQC would create synergy (excuse my word c= hoice here). =20 I think =E2=80=9Chybrid=E2=80=9D is the wrong word. CFRG has adopted anoth= er document where =E2=80=9Chybrid=E2=80=9D means weakest-link. Can we choo= se clearer words? I like =E2=80=9Ccompound=E2=80=9D, but strongest-link, a= nd defense-in-depth are clearer at the price of being longer. (I prefer hy= brid to synergy, of course!) =20 General arguments that attackers will find other system weaknesses than dir= ectly attacking crypto are valid, but these arguments already rely on good = crypto, and are invalid as an excuse to use weaker crypto, to stop improvin= g crypto. =20 Best regards, =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B Dan Brown BlackBerry =20 From: TLS On Behalf Of Joseph Salowey Sent: Thursday, February 13, 2020 12:13 PM To: Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design =20 The authors of "Hybrid Key Exchange" have asked for adoption of their draft= as a WG item. Please state whether you support adoption of this draft as = a WG item by posting a message to the TLS list by 2359 UTC 28 February 2020= . Please include any additional information that is helpful in understandi= ng your position. NOTE: If the draft is adopted, the working group has change control over the draf= t and the timing of its progression. This means the document does not have= to be perfect as the working group can and will make changes. Adopting th= e draft means the working group thinks the topic is a good idea and the dra= ft is a good place to start the work.=20=20 Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/draft-= stebila-tls-hybrid-design/ =20 =20 ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. ------=_NextPart_001_000F_01D5EB03.6E3E8D00 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I support rapid = adoption, if only based on general principles, as elaborated below.

 

***

 

I have not studied the draft in detail, but I think that strongest-link se= curity is important to allow, the sooner the better, for those that can aff= ord it, I think the benefit is worth cost.

 

I think that the how-to of str= ongest-link is straightforward enough to start working on it, and I trust t= he draft authors to have done a good job at it.=C2=A0 Any subtleties or opt= imizations of strongest-link crypto can be perfected as they arise.

 

I wou= ld also favor using both ECC and PQC, (a) _after_ NIST PQC is done, = (b) _before_ a Shor-capable QC arrives.=C2=A0 I=E2=80=99m hoping the= time of (a) < (b), and therefore hybrid should be ready to roll out.

 

= I would also favor adding PQC support to TLS _before_ even NIST PQC = is done, then just switching over to NIST choices at the time, even though = this seems not to be the interpretation consensus opinion, e.g. CFRG opted = to wait for NIST.=C2=A0 I agree waiting for NIST is sensible, if one want t= he best PQC protection, but not to the point of delaying having any PQC pro= tection, see next point.

 

Getting details right is a known difficulty, wit= h mistakes inevitable.=C2=A0 Haste makes waste, sure, but delay is deadly, = so let=E2=80=99s get to debugging the details right away.=C2=A0 Bugs are a = nuisance, but better than nothing.

=  

I realize that anybody worried about S= hor-capable QC, can add a PQC out-of-band to official TLS, but I understand= TLS to offer many benefits as security protocol, such that adding in PQC w= ould create synergy (excuse my word choice here).

 

I think =E2=80=9Chybrid= =E2=80=9D is the wrong word.=C2=A0 CFRG has adopted another document where = =E2=80=9Chybrid=E2=80=9D means weakest-link.=C2=A0 Can we choose clearer wo= rds?=C2=A0 I like =E2=80=9Ccompound=E2=80=9D, but strongest-link, and defen= se-in-depth are clearer at the price of being longer.=C2=A0 (I prefer hybri= d to synergy, of course!)

 

General arguments that attackers will find othe= r system weaknesses than directly attacking crypto are valid, but these arg= uments already rely on good crypto, and are invalid as an excuse to use wea= ker crypto, to stop improving crypto.

 

Best regards,

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

<= p class=3DMsoNormal>Dan Brown

BlackBerry=

 

From: TLS <tls-bounces@ietf.org> On= Behalf Of Joseph Salowey
Sent: Thursday, February 13, 2020 1= 2:13 PM
To: <tls@ietf.org> <tls@ietf.org>
Subje= ct: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design=

 

<= p class=3DMsoNormal>The authors of "Hybrid Key Exchange" have ask= ed for adoption of their draft as a WG item.  Please state whether you= support adoption of this draft as a WG item by posting a message to the TL= S list by 2359 UTC 28 February 2020.  Please include any additional in= formation that is helpful in understanding your position.

NOTE:
I= f the draft is adopted, the working group has change control over the draft= and the timing of its progression.  This means the document does not = have to be perfect as the working group can and will make changes.  Ad= opting the draft means the working group thinks the topic is a good idea an= d the draft is a good place to start the work.  

Thanks,
Chr= is, Joe, and Sean

[0] https://datatracker.ietf.org/doc/draft-stebi= la-tls-hybrid-design/

 

 

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have received this transmission in error, please= immediately reply to the sender and delete this information from your syst= em. Use, dissemination, distribution, or reproduction of this transmission = by unintended recipients is not authorized and may be unlawful.
------=_NextPart_001_000F_01D5EB03.6E3E8D00-- ------=_NextPart_000_000E_01D5EB03.6E3E8D00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCIdUw ggXJMIIDsaADAgECAgUA9lfgwDANBgkqhkiG9w0BAQ0FADB8MQswCQYDVQQGEwJDQTEbMBkGA1UE CgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJ MSwwKgYDVQQDDCNCbGFja0JlcnJ5IEVudGVycHJpc2UgUlNBIFJvb3QgQ0EgMTAeFw0xMzEyMTMx NzQ1NDdaFw0zODEyMTMxNzQ1NDdaMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0JlcnJ5 IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMMI0Js YWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMIICIDANBgkqhkiG9w0BAQEFAAOCAg0A MIICCAKCAgEAxkXAf/EHxa1okuoiPnKhHeaDfSRXq35g7JH34MqiM2cxMsL+WMe/8792DLEAe5Lm FLURmrkBiqwgzkrpejF1WBUaqrM0nGSkxTfO9ywXFHKZnK2wyxE+uNdIN5KzuzijEFJpnHxapdJg k8VmsgSnn+wTyRF8J/2DsaKV7UPYNkoGGZtCggI6Dh92G9AUKzZBSjfaZRfwStEv26wVgM8CiqSa O2FuwYriu+To03yDNiC0XOaGbPLyPAdyJbY71Bud3RQE1wciQV0nLwXnyCBmDK127NkjdewY4nAF TVuKaTVCqAdGKRo5idywpSHknZy01AvOJNuvL/BkN9Nv9nflelSml5TJNhfSa2hDRmHvr0+Jns+A qORC2WlvCybRGHkmTjpYLLMnIVprNBWPCCE6B/RaoLvcTvDeUwBVoqYzLSfLT6jAoXVcJM+XT948 TzAgCKcJg4oupgiMtYyL/oktajJbnpiLtRZ3jRX2hEgRW8tJZckvlxtrBGxQLYWNVe48OdBhbNnO bByGN2o0/GAttfkM8WrdjnCNv5YZ1d1eZPqCJicQ7ML4xRzUPwD1u7YvgdVRFidB3CsxM9nnlnam MYWQIV5nUuyK/1NUTiAEhGBYOsLeemgvPz41TsjERujbzHcj8MM3zMdwhWr86Dp1292C/bwyNgMm OfVgsHnZRnECAQOjVDBSMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBT4aYn4Y57vaF6BMGJwUqMO3bKWCDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQ0FAAOC AgEArBVGo/mS9/+yWzGI03ae5osTFt3v2acQVj1OrqSABZQXTdOXjJL31Q4QJABZlwllzKeIlFne 3c9yn39i3QMhoSjqkn4NjbPjKiiyzOLoI0PGq5UTQtpGm7X/EaXkcYDFhrIHnGfC9dmB5WeuwMwX fmKwUtiLPhgtgjGBqkxSOiFFbBUBiLGs/muE4IYbKJGPKqilOBLpeK1Kyp8zXIrJLLQ0zzkK6TkQ x6RULQ+px3geS5UWkrsFXCHK/x9vBxH313O7RV7vvwt2Opc0HFw9LzF50jie/wqx9HD3tm0GgvqD Aabtlao1V1mfLpk8k+nrWd589ZZSHmQMVFvzETnrS0BS4wZssImORAbv6tVCHZSf6gu1XApnxMaM Hy8qmL9lfkoTaxF7cxzzwrj5P49Xj+n4NZT95GyYNAoU3AhAFrQV+H6BXFTOHNX/ALubYWg5x+xu JFi+7HTcaCjZzjSGLWG3kilqn6JkT229jgYClzN8EylemXv3yz1vVjXbTRZNDK9G/p1Jj2SxlBC/ mTBvedATbkIMVm5Wzl8cE3rIp+A9lZ+bS9CfVx5OthHQxXn0fuVCakWp4a+KTsTtFlqbtVMesdcU Q1uMk8Tap11X43bkAyX25l76ejxuVCZYZaOxZFt689bVqRFh4DjyfagCRu65eQgOu013aZiAc28i WCEwggdJMIIGMaADAgECAgpyAx1HAAEAAlASMA0GCSqGSIb3DQEBCwUAMFYxEzARBgoJkiaJk/Is ZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAoBgNVBAMTIUJsYWNrQmVycnkgQ29ycG9y YXRlIElzc3VpbmcgQ0EgMTAeFw0xOTA0MTcyMDU4MjRaFw0yMDAyMjYyMjM2NTVaMIGpMRMwEQYK CZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMQ0wCwYDVQQLEwRBTUVSMQswCQYD VQQLEwJDQTEUMBIGA1UECxMLTWlzc2lzc2F1Z2ExDjAMBgNVBAsTBVVzZXJzMRIwEAYDVQQDEwlE YW4gQnJvd24xJzAlBgkqhkiG9w0BCQEWGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALQHoYbI3q25dSCAl6YGPubc51/jvsRg5VZl6f8cADT/ N6anVBzRl77zYVSEmqlrHG2/x++rOxdzcAi/LP+L7IEiU/TX+EyPR4OSLf3sQTJg/CzZLhKT+ouR CH1jn0QgFviHE4Ni0no/E4x+N0zjmhWpF7WcoaNbY0ZVW5g1jy7KtEoLwDGFylPVsrwLMzud4wjJ 32R/McoCAqaWr/vgUOoHYY6K+5fGp7wNyvhhc0sG+8ku2vNWhBo7sufwdehGISQsaBXS+Wqgy7g1 qNePiR/5i8OFgEFjO//iozFIeTPoFbSd+k4y/jv7wD+yLvVy84q9LteXpv92aFR+aTJxkEkCAwEA AaOCA8MwggO/MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIe/l0uGuYEkhsGBMoPb8iWC3NgB gQCxwyqHn/RAAgFkAgELMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjALBgNVHQ8EBAMC BsAwDAYDVR0TAQH/BAIwADBPBgNVHSABAf8ERTBDMEEGCisGAQQBm0oTAQIwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAnBgkrBgEEAYI3FQoEGjAY MAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBTb4N+ts9rY1LbQOi40ca8/M4cXVTAf BgNVHSMEGDAWgBQaL0tL2wfJSTuJ1jIIJ6KeC/MPazCCATIGA1UdHwSCASkwggElMIIBIaCCAR2g ggEZhkBodHRwOi8vY3JsLnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vpbmcl MjBDQSUyMDEuY3JshoHUbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWlu ZyUyMENBJTIwMSxDTj1NQ0EwMTBDTkMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZp Y2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQw ggEDBggrBgEFBQcBAQSB9jCB8zAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3Nw MIHKBggrBgEFBQcwAoaBvWxkYXA6Ly8vQ049QmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vp bmclMjBDQSUyMDEsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBNBgNVHREERjBEoCgGCisGAQQBgjcU AgOgGgwYZGFuaWJyb3duQGJsYWNrYmVycnkuY29tgRhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb20w DQYJKoZIhvcNAQELBQADggEBAEoWAOg0VEQNS86VaoPS9opseSqdMyxa/SyUNcoqeTRgadtmv1FX zUPytJUDgHQrMAmpHCurdPASknaqoHOaOyTf2AfJO9a36jIq+yC+7ybZFfiXOaFKOvAcDOpS0O25 PVZdG202Nt/g5hrOyd/hUplu0xz4h8CvihzW7AuUsBOBJn7vW5dvggrRx28FSBUARj4plfhNoGoI XJfFghQ1fWmjg8o9NjhTpXKDTy7kMNkUX2g+HACq4tzf0sjthqTFpGsAq+PhqFxKQLZ8GRAq67F+ mHWEvZArnHnDAk4JpqlGMZTVXRWZzW+21feqnog1FU6kgtM5/8uvtrEMQSe8Dn8wgggFMIIF7aAD AgECAgRDFVhfMA0GCSqGSIb3DQEBDQUAMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0Jl cnJ5IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMM I0JsYWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMB4XDTE0MDIyNjE2MjM1NloXDTI0 MDIyNjE2MjM1NloweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGltaXRlZDEi MCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcGA1UEAwwgQmxhY2tCZXJyeSBD b3Jwb3JhdGUgUG9saWN5IENBIDEwggIgMA0GCSqGSIb3DQEBAQUAA4ICDQAwggIIAoICAQC6JvZA kPpT2uIOJ8w4/hBW8IhdwmDtvzMEVmnYEmmr1cnQaD3NVSIxDfNFG2dVVeZJB4qmLwLkjMf0dgDo LtaPRaqZ2kW+fWuEeWqG4sRxCIWMgrdppkQoCenWGIiW7Q59bdNLk9MsiP2FPgFMVhSvXN38vl9t AEssQDmwPVnr9nBbBhW4OnaM2JDw0B5YEnMyXBJwslA+n4YDOTfzbIB5rzdzkG/Cy+Ss7NtOEIG1 Hfeur5RzruqaVRINsbk884T1TjR4q2BMhTE2uSjaANXkl+IM1YsfmIgCj/AKr4KhEAeM4to10mA8 3fUVLZzn5YPo8/jikzQ0qTge/7Yj2veffvkYkWG1pZGJvlofl/bi/62vrmrTkx9lDKLMl5zuK8qF znvSWVhntGsHWO0ZI+uSz5h7Alr0dOTdTOr1+SR2SzqL+uReyf2ViywiAEf7JtZj4QU2rlN7rxOi Suf7mz0D8RelA6TXaGlAe/q35kqAcciJZjMugO7+XG2chzjci5c/q+LJJTwz3M+QgSI21MhTcytC itBl0WFSg/vmE26nQnuryhWUoNvryGEP2xarae/oCiKZo41nc6LcVXCoJfq/pE5OKUhAi1N/RH26 OdDb3kOjdDdLIKY/yVThed1zESsuCUNkgy9APj5LgS95nSG/oQ9LlLL5g4YQd8WrwdFIZQIBA6OC ApIwggKOMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ7uMF3 DZ6tQ1j8Ja4V0LfykTKFmzAfBgNVHSMEGDAWgBT4aYn4Y57vaF6BMGJwUqMO3bKWCDCBhgYIKwYB BQUHAQEEejB4MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwUAYIKwYBBQUH MAKGRGh0dHA6Ly9jcnQucmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJv b3QlMjBDQSUyMDEuY3J0MIIBNwYDVR0fBIIBLjCCASowggEmoIIBIqCCAR6GRGh0dHA6Ly9jcmwu cmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEuY3Js hoHVbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUy MDEsQ049Um9vdENBLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl cyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0 aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDcGA1UdIAQwMC4w LAYEVR0gADAkMCIGCCsGAQUFBwIBFhZodHRwOi8vY3AucmltLm5ldC9jcHMvMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA0GCSqGSIb3DQEBDQUAA4ICAQC38TN+ EWKxTPBOf+yu0+eJD75HI0K1/VbX+/gkxxxthB+0rhaBVrJzU3j/ifE8ST9Icc+JgORZzCjZYUz7 Lj9DbvxbtUdaJGi7CHjjxgFm7aQkPX2BvpYHjjYeQ0349boayww1AG6iX42F/Gm+P4/UT4Jv5lo5 UepzMz8mgnOnAEqpzo7NFUixXZnLTTML6g8Co+Kpwl/gDOtTcXdit2SE4qugUCI9+4UIdO5cIFUK 2vkuev3JsjuUCl0p8g/591PyDxIUoRWt9I+8nkeDmdhr/Lyuh2OY82OXqCc7TdPPRdJdo0nWCJZu OxPrK1cJPPM/FMM7EwSruS1mFbMsHyXcmUBdfm8LudkPHPpszGlQ2cAcENzgyGCd2OWlggpp+y35 JIo9eKnLC5BGio6eno6MvfNMM5DzIr5hoVfLsbJUvlIIwOaqhWWPIjiQJgS8vAAZBONh6AXXs8TA smu0yt2cSp00HvUWAyJi8eOVUOiu+f7iXXUw+xhEcOyggo4JmJ4g+qM8wzx8pc4soKVMx4SLXXlR /uO3RNZ5ZNaVc3+qIqg4EbhGNQxyCGChFYemYvRdLmjqO0sGfofYaqRdhIBpKZYk7vDOwj0ZStzg TT55OAYF0jY+A9RXSiu6xm04F3C/2G7S19sHlhK28Prjf1Ahu5NwTnpaKdM5UiX4/SrKLTCCDK4w ggqWoAMCAQICBAsRTXAwDQYJKoZIhvcNAQELBQAweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJs YWNrQmVycnkgTGltaXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcG A1UEAwwgQmxhY2tCZXJyeSBDb3Jwb3JhdGUgUG9saWN5IENBIDEwHhcNMTkwMjI2MjIzNjU1WhcN MjAwMjI2MjIzNjU1WjBWMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSowKAYDVQQDEyFCbGFja0JlcnJ5IENvcnBvcmF0ZSBJc3N1aW5nIENBIDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDVHL/KEgF8NzTToTzGn4ZzdjfvMRN9YG1zaPkekwXrknWRKOTw 30fjw6bP7CF60nnJwGSVhoQ1DkNqVz0ZPI35dJW3EBEUyNVAtOGb+fiNmDsOKk2gbe+zwLb1ttrN 7BOgIDuqJKlujUBYxBk6Cl44KOoKwSzuvxuFHP7T6oev23Jh+DZmkm7M60iVLDzHjchFru696K8b vSiczJw0AVqWymaupeFveprrdJUz1y/G0Q0GoeZ3NFH0azM8JS6MB7Sz1zO/9SdlxvrRu0mCEN8E OgUTfG1l1sDILs7IhM9gUBF+tHJpeFc+xuSHpx7spkRzhESmuFD4h+6IIJ/B7SofAgMBAAGjgghf MIIIWzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUGi9LS9sH yUk7idYyCCeingvzD2swHwYDVR0jBBgwFoAUO7jBdw2erUNY/CWuFdC38pEyhZswgYEGCCsGAQUF BwEBBHUwczAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3NwMEsGCCsGAQUFBzAC hj9odHRwOi8vY3J0LnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMFBvbGljeSUyMENB JTIwMS5jcnQwggEsBgNVHR8EggEjMIIBHzCCARugggEXoIIBE4Y/aHR0cDovL2NybC5yaW0ubmV0 L0JsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBQb2xpY3klMjBDQSUyMDEuY3JshoHPbGRhcDovLy9D Tj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUG9saWN5JTIwQ0ElMjAxLENOPVN1YkNBLENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIGEgYDVR0gBIIGCTCCBgUwQQYKKwYBBAGbShQC ATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEG CisGAQQBm0oTAQMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVt ZW50Lmh0bTBBBgorBgEEAZtKEwECMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nw cy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3Au cmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTAgMwMzAxBggrBgEFBQcCARYl aHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwICMDMwMQYI KwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGb ShMCATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRt MEEGCisGAQQBm0oTAwMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3Rh dGVtZW50Lmh0bTBBBgorBgEEAZtKEwMCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0 L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMDATAzMDEGCCsGAQUFBwIBFiVodHRwOi8v Y3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBAAwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwUDMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYB BAGbShMFAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQu aHRtMEEGCisGAQQBm0oTBQEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQ U3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwYDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMGAjAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBgEwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwcD MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYK KwYBBAGbShMHAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1l bnQuaHRtMEEGCisGAQQBm0oTBwEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3Bz L0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwgDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5y aW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMIAjAzMDEGCCsGAQUFBwIBFiVo dHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTCAEwMzAxBggr BgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAQBgkrBgEEAYI3 FQEEAwIBATAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTANBgkqhkiG9w0BAQsFAAOCAgEAbML2 XftFHnmxEj1R+YXOw1IvY2cr3KtA2X5HweMk8WeDorircFlDGIP09Dgj2eEn7F8yg4vevOjtOj/O u+nMfxe2XdsxqbkOfOGncy2IQY0jp8Dznqg7iTJm2q5Rz+RhyICipwRhXVGhPz+UaBqzgPMRbOCy GVJFOfzIvI6IAARtWbFpDCIkIliQ36kd8UlXuAeCOqwLOQSenuL4kV+oaCKu1mNz3hC5jurnrTrt gPDYG0koEg40cxd4rv7Dy78U9jps82PFiMiA+yomtYZEsveyHHdsPupz8BN2Q6Oww99nR1ME+ING FK9r7dhEj6xAMVJ/eS2JHwtNSU3gxhhcQm/ZaP8Isfc7JKSI86II78DCyVVAJrMrt+pkNYWw8KDi yxuN5HxfGTBykx9H4lxdDTYT8AS1kf3GJUXo3/8+09g8ZIfbiSm5l96jvAL62ix/aSwFT01T7sTn CgPAcutQSnWoONApDZvqzDSJRwAtdkX+DMn2lDlocTpw99a8WkWJpNyyImvV5OeO/ra5RMCH9f2V /SerRLOQDBIjss7S3x48Fw0VsYxEIBxMV45X47lpwGfXK5oi9OuLGHBkLFavyFpLvbSDpFHfhUiD Ae2DviaDWkyLVZJXWdrujxEW2tchEcuytZw6i9k41/4mgOiy6HYwhRJhknXr5YQJ5wu5rwQxggI8 MIICOAIBATBkMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAo BgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3VpbmcgQ0EgMQIKcgMdRwABAAJQEjANBglg hkgBZQMEAgEFAKCBqjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0y MDAyMjQxNjEzMjRaMC8GCSqGSIb3DQEJBDEiBCCmsY8WYAdMMnMX5kdv6fYfDhRsZVZ8h+mWTpBB tSC0QTA/BgkqhkiG9w0BCQ8xMjAwMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBAJlBihsy9mQGjA9MVHcvP2ZpRlpoM1k2NjAg eAkCMgUtJ6Gi4/wFNVFh82fm7hbrm+FEUQ3f66+SnF0xo9+KyySeCbuJwozHvI0pBXDsqgh8bvDW ffDkwBEXhvIVTqXjhxKXYLPHdvgxDT2nHV6CTMYKA0lStTrmJQTXSsys0jcpUPZRqQSQRv1GEy6q KOIYie545T++2Zg0eORtDfCYL2C0Hih/iUOsL2M2WFcWb8wJ4+yeh/D1o+PXu6RqqTuGicYb2xSH rVV4eiAMKUKUyyGAlDTdyKo5GffPzSv1cY3MsH3X1nV5MCsSRqofQBGkHBUtbtXYYuOWbHJgZ+aR TUAAAAAAAAA= ------=_NextPart_000_000E_01D5EB03.6E3E8D00-- From nobody Mon Feb 24 09:08:39 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943D93A0EA9 for ; Mon, 24 Feb 2020 09:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 a_1jVxT3cyZC for ; Mon, 24 Feb 2020 09:08:33 -0800 (PST) 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 D1CBA3A0EAC for ; Mon, 24 Feb 2020 09:08:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 52D33300B50 for ; Mon, 24 Feb 2020 11:41:51 -0500 (EST) 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 QY_45WL9auBO for ; Mon, 24 Feb 2020 11:41:46 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 7890D3005D5; Mon, 24 Feb 2020 11:41:46 -0500 (EST) From: Russ Housley Message-Id: <65B3EA90-22AB-48C1-B1C2-C0BFB5351964@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C095410C-B463-48B8-BCAA-87156F0FB7B2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 24 Feb 2020 12:08:26 -0500 In-Reply-To: <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> Cc: Watson Ladd , Scott Fluhrer , Martin Thomson , IETF TLS To: Stephen Farrell References: <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com> <16f0a0d4-be96-64bf-cf64-a09d603beb86@cs.tcd.ie> <52568979-d53c-f3e4-ff5c-e652c97fd621@cs.tcd.ie> <68fe1d57-6bce-d649-d93a-4736a376d782@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 17:08:37 -0000 --Apple-Mail=_C095410C-B463-48B8-BCAA-87156F0FB7B2 Content-Type: multipart/alternative; boundary="Apple-Mail=_EA785C00-54F7-4D8C-8995-60B557B4A288" --Apple-Mail=_EA785C00-54F7-4D8C-8995-60B557B4A288 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 21, 2020, at 5:25 PM, Stephen Farrell = wrote: >=20 > On 21/02/2020 22:11, Watson Ladd wrote: >=20 >> https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/ >> https://blog.cloudflare.com/the-tls-post-quantum-experiment/ >>=20 >> This was also presented at the NIST standardization workshop in = October of 2019. >=20 > Thanks. I read through [1]. It's fine work, but does not > convince me that this draft is ready to be an RFC before > the "winning" algs are known, as some have characteristics > that are quite different from the two that were tested > here. I maintain my position that adoption is fine but > finishing this before NIST are done is not. >=20 > Cheers, > S. >=20 > [1] > = https://csrc.nist.gov/CSRC/media/Presentations/measuring-tls-key-exchange-= with-post-quantum-kem/images-media/sullivan-session-1-paper-pqc2019.pdf = These slides clearly indicate that an experiment is being performed. I = encourage the experimentation, but I do not think that the TLS WG should = adopt this draft. TLS 1.3 eliminated a lot of cruft from earlier versions. This is really = good, and it make the security analysis much more tractable. We all = know that adding complexity brings bugs. I would like adoption of a = draft in this general direction after the NIST competition completes so = that the TLS WG can focus on a small number of algorithms. Russ --Apple-Mail=_EA785C00-54F7-4D8C-8995-60B557B4A288 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Feb 21, 2020, at 5:25 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

On 21/02/2020 22:11, Watson = Ladd wrote:

https://blog.cloudflare.com/towards-post-quantum-cryptography-i= n-tls/
https://blog.cloudflare.com/the-tls-post-quantum-experiment/
This was also presented at the NIST = standardization workshop in October of 2019.

Thanks. I read through [1]. It's = fine work, but does not
convince me that this draft is = ready to be an RFC before
the "winning" algs are known, as = some have characteristics
that are quite different from = the two that were tested
here. I maintain my position that = adoption is fine but
finishing this before NIST are done = is not.

Cheers,
S.

[1]
https://csrc.nist.gov/CSRC/media/Presentations/measuring-tls-ke= y-exchange-with-post-quantum-kem/images-media/sullivan-session-1-paper-pqc= 2019.pdf

These slides clearly indicate that an experiment = is being performed.  I encourage the experimentation, but I do not = think that the TLS WG should adopt this draft.

TLS 1.3 eliminated a lot of cruft from earlier = versions.  This is really good, and it make the security analysis = much more tractable.  We all know that adding complexity brings = bugs.  I would like adoption of a draft in this general direction = after the NIST competition completes so that the TLS WG can focus on a = small number of algorithms.

Russ

= --Apple-Mail=_EA785C00-54F7-4D8C-8995-60B557B4A288-- --Apple-Mail=_C095410C-B463-48B8-BCAA-87156F0FB7B2 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----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXlQDCgAKCRCK5O7Q9ZwR yxeCAKCZ8gQyoaBlGFiMWfRFzvBcaVQpgQCg/yt/iOSuVgU1kWrmqtUrLf7yg/Y= =+Zfi -----END PGP SIGNATURE----- --Apple-Mail=_C095410C-B463-48B8-BCAA-87156F0FB7B2-- From nobody Mon Feb 24 12:26:19 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84ABB3A1295 for ; Mon, 24 Feb 2020 12:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 HuE6ec0tDn_y for ; Mon, 24 Feb 2020 12:26:15 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E193A1293 for ; Mon, 24 Feb 2020 12:26:15 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id f5so8859992ilq.5 for ; Mon, 24 Feb 2020 12:26:14 -0800 (PST) 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=UrdLV5/OEgFkytyvOWtkJPFA7ytUDyA5qam71Itu2ZM=; b=JPwgXeFEoQIaNFovhPxMWbre0kmITjMZx/VY9S2sx4JYADFUVOIYxZPUsW49lNvPnq mqJd4/I5H3QdbHfu5v4zO1/Pw5ZqkR179F8CaFoxbBEXLaTLVU6NS7TJTbqwQ2FRKc59 cHk1LYOLAPRl5SQnmKFnf5usP2Y7NvrQ0wZT+8/iluX74UBop370Wwq1zuTIQfirkUgJ MLmx+Mkv6J2BwZuGK5DGx85nxOLGg87KvqEsyYqgrTF8QhPcG8G2Fv/EMDDXWCv7VJUr ayFI3Mgdhyh6VeNBDbx81dZ1aTTL/HsdodyPCVKW3LD9P/c2/PIKEclLbFyFfF5mO+/U 4EoQ== 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=UrdLV5/OEgFkytyvOWtkJPFA7ytUDyA5qam71Itu2ZM=; b=J7M1yW32pAlUMiN6OSGsffRkR2TTR8wacM0FgrEkbywoGiEHy9n5k9UYP5xelhQCfa 1usq8jy+cMZ9rB56c//g7VrVxyh1x1iFHuH4//ycjnAcc30SBGwuicVEdrhw6Es1KaMx MMI9V1RO95mD8Nl/ggHkADTVt7vJ5yMUIXq+jeTgfrTH3M0D4cUiOX+FG0U+DioU3rQA 3yDrgYnw/NvHYAECjbgyhInxGEs+mGnHLeDeFae9YOLkojc2bJbsa4T39Xzjf3E7orsu vsy9+Z/LI95xi+sCApxYxEgcIbqhepTYKfDmlhMX4oQ5zsMrKEewlWBWsk2f57dUs7bJ JBoQ== X-Gm-Message-State: APjAAAUMSc1U6CmGnoiR0lXcz0WYgiOIU79ML5ReCJpxuD4QuUOfadga WITG2DDHvz7oWPPhOLwy/TXEn+13z7dAfXsidPQVXfJu X-Google-Smtp-Source: APXvYqyF2dNTtybGwDKd+LaLm9yZS4HCzVR9hr051g/ec/GZqFqRX7YLPgoOaFErCpSo5eOfxx2I+QUXB8TB7GDLS24= X-Received: by 2002:a92:9c1c:: with SMTP id h28mr57889765ili.189.1582575974225; Mon, 24 Feb 2020 12:26:14 -0800 (PST) MIME-Version: 1.0 References: <412affff-54a9-d244-886b-ea44ad972c94@cs.tcd.ie> <25f2f45a-2290-53ef-75e9-f4cb0967944c@cs.tcd.ie> In-Reply-To: <25f2f45a-2290-53ef-75e9-f4cb0967944c@cs.tcd.ie> From: Rob Sayre Date: Mon, 24 Feb 2020 12:26:03 -0800 Message-ID: To: Stephen Farrell Cc: Christopher Wood , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c61da7059f582ee1" Archived-At: Subject: Re: [TLS] ESNI/ECHO updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 20:26:17 -0000 --000000000000c61da7059f582ee1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 24, 2020 at 1:36 AM Stephen Farrell wrote: > > Hiya, > > On 24/02/2020 03:57, Christopher Wood wrote: > > We=E2=80=99re actively analyzing ECHO. As of now, we expect this to com= plete > > in March, > > I would welcome seeing that done in a more open > manner. > I took this to mean a ProVerif model--something like this: https://github.com/chris-wood/encrypted-sni-model/blob/master/stable/esni_a= nalysis_00.pdf If that's what's going on, I don't see too much value in doing this work in public, provided the WG can iterate a bit afterward. Maybe even check it in to the tlswg repo when it's ready. thanks, Rob --000000000000c61da7059f582ee1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 24, 2020 at 1:36 AM Stephen F= arrell <s= tephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 24/02/2020 03:57, Christopher Wood wrote:
> We=E2=80=99re actively analyzing ECHO. As of now, we expect this to co= mplete
> in March,

I would welcome seeing that done in a more open
manner.

I took this to mean a ProVerif = model--something like this:

If that's what'= s going on, I don't see too much value in doing this work in public, pr= ovided the WG can iterate a bit afterward. Maybe even check it in to the tl= swg=C2=A0repo when it's ready.

thanks,
Rob
=C2=A0
--000000000000c61da7059f582ee1-- From nobody Mon Feb 24 12:50:41 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E74F3A12DA for ; Mon, 24 Feb 2020 12:50:39 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=heapingbits.net header.b=HGkqHe+g; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=0qMFj2do Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAeG-EUWMhX6 for ; Mon, 24 Feb 2020 12:50:37 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14A83A12D9 for ; Mon, 24 Feb 2020 12:50:37 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A270F2181B for ; Mon, 24 Feb 2020 15:50:36 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Mon, 24 Feb 2020 15:50:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=DXHNgLAWO+qWl1M+UJ9ChDZTRcBjF5L 5Gl00BbQlK3s=; b=HGkqHe+g8mVNsPWXKs5PedxRA2uDmRTIYlvKWN9jE4YLgxa pam6AdmZMKVcQjO0gLR44ubfmlqB/Xh4sjmQt6msrWulLZPO6M/ewVr/lNNMrBSy 8qrVnJ7JTMzA1brx8fYRfjJMgYehJIT9xVgl2JxLxO1w4OGYaT16JCurO0H27len VOrTt/Qucj1XCjIN3HAK+Bt/zNJM1T/6fEITGNjex0g/JH7aJ9Wx37zI5CjdSIrW 8OcYvIW9u+Bke7xFZ/11TG4OSzvFNBUD5u1PVDa7P/pbm3NO5eii3VP2KQeO1tnk VCp5B6d4BRRWyJ2TY79rFSXtgwJXbZQ1NTTLMvg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=DXHNgL AWO+qWl1M+UJ9ChDZTRcBjF5L5Gl00BbQlK3s=; b=0qMFj2doypfeUERKEPjmP4 JedgrgP6iA1G/vxMGroPgQ6NPWWbShDh54D49R2ww4aYFCxQJPpfrRwHwRRMSXsw CGSuMuC5SNVtZE7ABM5TYm9Rl+Y/bQpkoVKCzEGuMKVQiyhhSMCtkwDNN74Hx6W8 rUVSsu2pEuZiKd/8ER2gIie8O3b6KbWy5nqwzL00itsgTbcWULjQCq6dMi8FKv55 lQWjtZG5qe3CiMW0dTIvaySbwmr+DiiQgjk49lpkLPnU7OHezK7nVv+FFCcBX060 BSS5JntTve3Vi6UsCr7eCyyxveAy8UogT4R2KK/7aiU4CsBGUDrdeblvVd5O967Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrledtgddugeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A3663C00A2; Mon, 24 Feb 2020 15:50:36 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmstable-20200220v2 Mime-Version: 1.0 Message-Id: <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com> In-Reply-To: References: Date: Mon, 24 Feb 2020 12:50:15 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 20:50:39 -0000 On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote: > > > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla wrote: > > > > > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre wrote: > >> Hi, > >> > >> I'm not sure how violations of these requirements would result in poor interoperability: > >> > >> Clients which import external keys TLS MUST NOT use these keys for > >> any other purpose. Moreover, each external PSK MUST be associated > >> with at most one hash function. > >> > >> These seem like aspirational security goals. It would be better to describe the consequences of violating these conditions. > > > > I don't agree. They are requirements in order to be able to make the assertions we want to make about the security of the protocol. > > > > This is consistent with the following text of RFC 2119 S 6 > > ".. or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) " > > > > I don't think it would be unreasonable.to explain the reason for these, though this is already a requirement of 8446 S 4.2.11 (though without justification). > > I think that interpretation of 2119 is a stretch, but your idea to add > an explanation while keeping the 2119 terms addresses my concern. At > the very least, the draft should note this is already a requirement of > 8446. That seems perfectly reasonable! We can point to the security considerations to clarify the "single hash function" requirement, and we can note cross protocol attack deterrence for the other claim. Would that suffice? If not, can you please recommend text? Thanks, Chris From nobody Mon Feb 24 13:33:47 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559763A13A6 for ; Mon, 24 Feb 2020 13:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 MaAf0DqzGhah for ; Mon, 24 Feb 2020 13:33:44 -0800 (PST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C163A13A5 for ; Mon, 24 Feb 2020 13:33:44 -0800 (PST) Received: by mail-ua1-x92e.google.com with SMTP id h32so3779752uah.4 for ; Mon, 24 Feb 2020 13:33:44 -0800 (PST) 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=EuUkruvgyQf6yQoAJurDmhJIjSkuJnYmW/1kWaR7vmk=; b=K0lcRRTDe6IRPTBnZkbGGHx5eeEuBhDBayImBqD/w+9Anzrsq7RR4v+boevFF11Gxu r8lKnseaHGvKVMo6N/WqWBBeAp5B82u9/HPJLrdj4pIYBjoM6ula2XI8+vohr7yhqExM 8584Lw776x3dFvx4I5toyHq9B7OWwr8MnTsKo1YuFudpbGF9n8vq+qzZu1SsmAFhPmIe +pBN+oQ5pQqYIyPaKEefNns8hO4JXWvyby4ZPL4NXKZ/xf4Moc+Y1ZUQm+lbAWvjLdQd NqeC+6jmqfeiTZRwP2mzXhXr7IwrJlcPMyzJ3s71cMZDBkn74R1wKKPzW9ntvTfGEJ49 QXww== 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=EuUkruvgyQf6yQoAJurDmhJIjSkuJnYmW/1kWaR7vmk=; b=qK/XKskPTFU9wPnCVhOUvMliA0ddVHelsoMKhkuhcVUFeVyK4GeuGW2bsgwryhIt9I xE4Xe1e7+cYSFbQa22CkobgoKuN44ITTMXr9GHLezRofVQJh9WO5olixsrrewlCSNzul cUfJ2shZNfN+93/bAdOuJmxV9kkYcLrZ9vsnyqXKuIVzirVcomjWCYfa4VlPZzmq6ygX LAuAQlrliKEg7Q2Tgv3IifCTpOzw2I695KgTKR2p5m7LtGNBH9mcejtNysWR6kuIUYDK c0Bkbx6fASClFHT6sWz1hKqmx9cgk89K7bTU+Mj2dDeiJu+uSRC98fSNdUL+JezaoSEc VHuw== X-Gm-Message-State: APjAAAUOMFXzSAN0UaQJWhnz6UlD/YBZ7YIAumQvXxqMt2oLAPXbaHHP lRJjzEr5oOkOwytAgh8rDhtBerZagZDECl462MHcPJxjjow= X-Google-Smtp-Source: APXvYqzRoReuzZaj7KOU1xu1ggUbWCqDofnySrBdfAcM38t2gN/H7YS9EHM//8pnguoCSK7HoUHrKZoa2hSPz6HGANU= X-Received: by 2002:ab0:2a93:: with SMTP id h19mr25365386uar.27.1582580023098; Mon, 24 Feb 2020 13:33:43 -0800 (PST) MIME-Version: 1.0 References: <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com> In-Reply-To: <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com> From: Jonathan Hoyland Date: Mon, 24 Feb 2020 21:33:32 +0000 Message-ID: To: Christopher Wood Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001aff1c059f592048" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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 Feb 2020 21:33:46 -0000 --0000000000001aff1c059f592048 Content-Type: text/plain; charset="UTF-8" Just looking at this again, it might be better to make a slightly different tweak to the key schedule. Instead of: 0 | v PSK -> HKDF-Extract = Early Secret | +-----> Derive-Secret(., "ext binder" | | "res binder" | | "imp binder", "") | = binder_key v We should do: 0 | v PSK -> HKDF-Extract = Early Secret | +-----> Derive-Secret(., "ext binder" | | "res binder" | | "imp e binder" | | "imp r binder", "") | = binder_key v or at least: 0 | v PSK -> HKDF-Extract = Early Secret | +-----> Derive-Secret(., "ext binder" | | "res binder" | | "imp e binder", "") | = binder_key v Just so that we can distinguish between external imported binders and resumed imported binders, should we at some point decide to do both. Regards, Jonathan On Mon, 24 Feb 2020 at 20:50, Christopher Wood wrote: > On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote: > > > > > > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla wrote: > > > > > > > > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre wrote: > > >> Hi, > > >> > > >> I'm not sure how violations of these requirements would result in > poor interoperability: > > >> > > >> Clients which import external keys TLS MUST NOT use these keys for > > >> any other purpose. Moreover, each external PSK MUST be associated > > >> with at most one hash function. > > >> > > >> These seem like aspirational security goals. It would be better to > describe the consequences of violating these conditions. > > > > > > I don't agree. They are requirements in order to be able to make the > assertions we want to make about the security of the protocol. > > > > > > This is consistent with the following text of RFC 2119 S 6 > > > ".. or to limit behavior which has potential for causing harm (e.g., > limiting retransmisssions) " > > > > > > I don't think it would be unreasonable.to explain the reason for > these, though this is already a requirement of 8446 S 4.2.11 (though > without justification). > > > > I think that interpretation of 2119 is a stretch, but your idea to add > > an explanation while keeping the 2119 terms addresses my concern. At > > the very least, the draft should note this is already a requirement of > > 8446. > > That seems perfectly reasonable! We can point to the security > considerations to clarify the "single hash function" requirement, and we > can note cross protocol attack deterrence for the other claim. Would that > suffice? If not, can you please recommend text? > > Thanks, > Chris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001aff1c059f592048 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just looking at this again, it might be better to make a s= lightly different tweak to the key schedule.
Instead of:
0 | v PSK -> HKDF-Extract =3D Early Secret | +-----> Derive-Secret(., "ext binder" | | "res binder" | | "imp binder", "&quo= t;) | =3D binder_key
                v


We should do:

0 | v PSK -> HKDF-Extract =3D Early Secret | +-----> Derive-Secret(., "ext binder" | | "res binder" | | "imp e binder" | = | "imp r binder", "") | =3D binder_key
                v

or at least:
                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder", "&q=
uot;)
                |                     =3D binder_key
                v



Just so that we can distinguish between exter=
nal imported binders and resumed imported binders, should we at some point =
decide to do both.=C2=A0

Regards,

Jonathan

On Mon, 24 Feb 2020 at 20:50, Christopher Wood <caw@heapingbits.net> wrote:
On Fri, Feb 21, 2020, at=
 1:15 PM, Rob Sayre wrote:

> 

> 

> On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla <ekr@rtfm.com> wrote:

> > 

> > 

> > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <sayrer@gmail.com> wrote:

> >> Hi,

> >> 

> >> I'm not sure how violations of these requirements would r=
esult in poor interoperability:

> >> 

> >>=C2=A0 Clients which import external keys TLS MUST NOT use the=
se keys for

> >>=C2=A0 any other purpose. Moreover, each external PSK MUST be =
associated

> >>=C2=A0 with at most one hash function.

> >> 

> >> These seem like aspirational security goals. It would be bett=
er to describe the consequences of violating these conditions.

> > 

> > I don't agree. They are requirements in order to be able to m=
ake the assertions we want to make about the security of the protocol.

> > 

> > This is consistent with the following text of RFC 2119 S 6

> > ".. or to limit behavior which has potential for causing har=
m (e.g., limiting retransmisssions) "

> > 

> > I don't think it would be unreasonable.to explain the reason=
 for these, though this is already a requirement of 8446 S 4.2.11 (though w=
ithout justification).

> 

> I think that interpretation of 2119 is a stretch, but your idea to add=
 

> an explanation while keeping the 2119 terms addresses my concern. At <=
br>
> the very least, the draft should note this is already a requirement of=
 

> 8446.



That seems perfectly reasonable! We can point to the security consideration=
s to clarify the "single hash function" requirement, and we can n=
ote cross protocol attack deterrence for the other claim. Would that suffic=
e? If not, can you please recommend text?



Thanks,

Chris



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--0000000000001aff1c059f592048--


From nobody Mon Feb 24 14:23:47 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243953A147F for ; Mon, 24 Feb 2020 14:23:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Level: 
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 UI-TC1u9hJrW for ; Mon, 24 Feb 2020 14:23:44 -0800 (PST)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC5D3A147A for ; Mon, 24 Feb 2020 14:23:44 -0800 (PST)
Received: by mail-pj1-x1030.google.com with SMTP id 12so365000pjb.5 for ; Mon, 24 Feb 2020 14:23:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DGRUl0eZ65s3McJjl1jLJV0m7ODzFpqtg8Y9StjIBDM=; b=em5mvNTwc0o8iFL1TjU0lbEot+IeMzR6i74aTgjGb5Dc/al9N0MiGgViTG+7qCGcfc em4ZbnXfw5B9THgDKxysXNe6kQaGmfB4y+RvrJbErRcNRDFBUKgDUAg268UsvmiiScHy Wyd3J3t/JHsr3cqK9W57W+Vb+kbCFe+ciyOD4=
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=DGRUl0eZ65s3McJjl1jLJV0m7ODzFpqtg8Y9StjIBDM=; b=S3RgFksH4BwlDs27UgPKsGblnPt5EKsrlE2yrktTaadDFr0Y1928mkeA9nyIlITTLQ p6RHAU8Ezns9EJD6ooBFFcVDnHYhmApmQq5Zn6/I28JuTN2ds+AIxJMNT/uw8ZhZkgWR M8rbYCQHl+izQOUZh1U5LuQUdTnsDap4aUSzqC8pgx0Kyxz16Iww/a74TyatUksKVziE i7SDOqszMYdw9FTa1l99kpzJdOeTKFjSOZIEmVt9qxfljhfk9McNIJ3duZgJvcAeavjO IzMMJzRMd97GercPBVA2VWP6qtXLcSZtVoJVC0VYHzY2R6xCCPx4xiqUMRWvaE8F+v/m VMkw==
X-Gm-Message-State: APjAAAVFSE5ySOExOdzdt2EwJyH0QnIbWrIxy2zDw20E7vdh9hPx8Sgg oAYfxEUqwCymoeb29APK1d3QV8Z2hqjwNbPYsn2y
X-Google-Smtp-Source: APXvYqzIFeiM1uQba5eVb2ZHGYYUAXSqsAyB5zBBLOW8GKnmWgoOh1IP/nra2HdIYR+P415mtAqthONKD+Hnn1Z/dJ8=
X-Received: by 2002:a17:90a:f013:: with SMTP id bt19mr1417448pjb.47.1582583022611;  Mon, 24 Feb 2020 14:23:42 -0800 (PST)
MIME-Version: 1.0
References:     <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com> 
In-Reply-To: 
From: David Benjamin 
Date: Mon, 24 Feb 2020 17:23:26 -0500
Message-ID: 
To: Jonathan Hoyland 
Cc: Christopher Wood , "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000e4557f059f59d25f"
Archived-At: 
Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 22:23:46 -0000

--000000000000e4557f059f59d25f
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland 
wrote:

> Just looking at this again, it might be better to make a slightly
> different tweak to the key schedule.
> Instead of:
>
>                 0
>                 |
>                 v
>       PSK ->  HKDF-Extract = Early Secret
>                 |
>                 +-----> Derive-Secret(., "ext binder"
>                 |                      | "res binder"
>                 |                      | "imp binder", "")
>                 |                     = binder_key
>
>                 v
>
>
>
> We should do:
>
>                 0
>                 |
>                 v
>       PSK ->  HKDF-Extract = Early Secret
>                 |
>                 +-----> Derive-Secret(., "ext binder"
>                 |                      | "res binder"
>                 |                      | "imp e binder"
>
>                 |                      | "imp r binder", "")
>                 |                     = binder_key
>
>                 v
>
>
> or at least:
>
>                 0
>                 |
>                 v
>       PSK ->  HKDF-Extract = Early Secret
>                 |
>                 +-----> Derive-Secret(., "ext binder"
>                 |                      | "res binder"
>                 |                      | "imp e binder", "")
>                 |                     = binder_key
>
>                 v
>
>
>
>
> Just so that we can distinguish between external imported binders and
> resumed imported binders, should we at some point decide to do both.
>

I may just be confused, but what would a resumed imported binder mean? I
see this mechanism as largely a bugfix for TLS 1.3 external PSKs, rather
than a new kind of adjective describing PSKs.

("imp binder" also doesn't preclude "imp r binder" later if we later define
something which needs it, but I'm confused what the concept even would be.)

David


> On Mon, 24 Feb 2020 at 20:50, Christopher Wood 
> wrote:
>
>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
>> >
>> >
>> > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla  wrote:
>> > >
>> > >
>> > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre  wrote:
>> > >> Hi,
>> > >>
>> > >> I'm not sure how violations of these requirements would result in
>> poor interoperability:
>> > >>
>> > >>  Clients which import external keys TLS MUST NOT use these keys for
>> > >>  any other purpose. Moreover, each external PSK MUST be associated
>> > >>  with at most one hash function.
>> > >>
>> > >> These seem like aspirational security goals. It would be better to
>> describe the consequences of violating these conditions.
>> > >
>> > > I don't agree. They are requirements in order to be able to make the
>> assertions we want to make about the security of the protocol.
>> > >
>> > > This is consistent with the following text of RFC 2119 S 6
>> > > ".. or to limit behavior which has potential for causing harm (e.g.,
>> limiting retransmisssions) "
>> > >
>> > > I don't think it would be unreasonable.to explain the reason for
>> these, though this is already a requirement of 8446 S 4.2.11 (though
>> without justification).
>> >
>> > I think that interpretation of 2119 is a stretch, but your idea to add
>> > an explanation while keeping the 2119 terms addresses my concern. At
>> > the very least, the draft should note this is already a requirement of
>> > 8446.
>>
>> That seems perfectly reasonable! We can point to the security
>> considerations to clarify the "single hash function" requirement, and we
>> can note cross protocol attack deterrence for the other claim. Would that
>> suffice? If not, can you please recommend text?
>>
>> Thanks,
>> Chris
>>
>> _______________________________________________
>> 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
>

--000000000000e4557f059f59d25f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Mon, Feb 24, 2020 at 4:33 PM Jonathan =
Hoyland <jonathan.hoyland@gmail.com> wrote:
Just=
 looking at this again, it might be better to make a slightly different twe=
ak to the key schedule.
Instead of:
                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp binder", "&quo=
t;)
                |                     =3D binder_key
                v


We should do:

<=
pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef=
ore:page;color:rgb(0,0,0)">                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder"                |                      | "imp =
r binder", "")
                |                     =3D binder_key
                v

or =
at least:
                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder", "&q=
uot;)
                |                     =3D binder_key
                v


<=
br>
Just so that we can distinguish between external imported binders =
and resumed imported binders, should we at some point decide to do both.=C2=
=A0

I may just be confused, but=
 what would a resumed imported binder mean? I see this mechanism as largely=
 a bugfix for TLS 1.3 external=C2=A0PSKs, rather than a new kind of adjecti=
ve describing PSKs.

("imp binder" also d=
oesn't preclude "imp r binder" later if we later define somet=
hing which needs it, but I'm confused what the concept even would be.)<=
br>

David
=C2=A0
On Mon, 24 Feb 2020 at 20:50, Christopher Wood <<=
a href=3D"mailto:caw@heapingbits.net" target=3D"_blank">caw@heapingbits.net=
> wrote:
=
On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:

> 

> 

> On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla <ekr@rtfm.com> wrote:

> > 

> > 

> > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <sayrer@gmail.com> wrote:

> >> Hi,

> >> 

> >> I'm not sure how violations of these requirements would r=
esult in poor interoperability:

> >> 

> >>=C2=A0 Clients which import external keys TLS MUST NOT use the=
se keys for

> >>=C2=A0 any other purpose. Moreover, each external PSK MUST be =
associated

> >>=C2=A0 with at most one hash function.

> >> 

> >> These seem like aspirational security goals. It would be bett=
er to describe the consequences of violating these conditions.

> > 

> > I don't agree. They are requirements in order to be able to m=
ake the assertions we want to make about the security of the protocol.

> > 

> > This is consistent with the following text of RFC 2119 S 6

> > ".. or to limit behavior which has potential for causing har=
m (e.g., limiting retransmisssions) "

> > 

> > I don't think it would be unreasonable.to explain the reason=
 for these, though this is already a requirement of 8446 S 4.2.11 (though w=
ithout justification).

> 

> I think that interpretation of 2119 is a stretch, but your idea to add=
 

> an explanation while keeping the 2119 terms addresses my concern. At <=
br>
> the very least, the draft should note this is already a requirement of=
 

> 8446.



That seems perfectly reasonable! We can point to the security consideration=
s to clarify the "single hash function" requirement, and we can n=
ote cross protocol attack deterrence for the other claim. Would that suffic=
e? If not, can you please recommend text?



Thanks,

Chris



_______________________________________________

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




--000000000000e4557f059f59d25f--


From nobody Mon Feb 24 14:27:22 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38173A148A for ; Mon, 24 Feb 2020 14:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 l8pn23Pcf4SZ for ; Mon, 24 Feb 2020 14:27:18 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A98D3A1489 for ; Mon, 24 Feb 2020 14:27:18 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id m25so11975232ioo.8 for ; Mon, 24 Feb 2020 14:27:17 -0800 (PST)
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=yj30CCE6u1zfDE/WoIAyYNlo4e+gxaihOaPZ2pfFHA0=; b=tVge+pQ7GmHqkJECy+gbxUDsds3ml3F+MCZn7AXaIuojJve1iif8vUJnLPh7Yed/l3 yocCIkBTidsD0m30UcuqmpcsY+sIQLmrpL5jOl+yNLeT928SR4+lVSpNFvrV7eQrI1s1 hpfQYqhgQuVzv4o56bbHwWASKPrCBYvgvzw6RaLtK2VD752FUm0kc/zA7X8/9g33sY5q V7yX5qTG7rI2QJeZaGSAydUREjLTIpjzaRENz33XiD6yCJYAmRCH58SV2iON//7m6rf0 pOcEMvGMQBwQUuKtQdSe3Pt7tZ5kb1KgTuVXkbyxBtiK7Ke2AdnfUPKVBv+LCIdcUIDA p96A==
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=yj30CCE6u1zfDE/WoIAyYNlo4e+gxaihOaPZ2pfFHA0=; b=SxPxtO1Sqlr1FcoJ+Py8zel+JC+jkvFe8pipKL24ddG+vRsLoloucMD1TrCCojFlrn ZfncVfwQuYVc4R4u3fmh1WY5xEFpxvFnATKOjaxOi74fsK9+nzSAufRBbKiZ+auTYfl+ xdygbtR63VUUjMsHjJt77PzjBt6mq1et7OzQ5M8PuVnoOtmm+OWkZHiD26aiHyrshDm3 MThDje/iYkyMzoYRlV6YInVOmPYHScfwhsQvGogaDBffhwc0qZz3nNY/vpqxBzBeBBT3 nVTqfA7ltBOV0JGzkWw8gHnIdUicPHELrHzP+kF0HEzXEz40MVe5gz8pFy8Dg5KLohc+ PDmA==
X-Gm-Message-State: APjAAAUXkM6JvGecHkEkIt4kE8tE46kQFSsJbNuQlwY2M0oJSQTPwHvM 2xBFmz0212nz7bFu2Q/dHkPcvfKdBOWRVqHHKQdVMj3a
X-Google-Smtp-Source: APXvYqzMU/dwRSolLAW3JDPzbZTHKzVr3MaG5sfrgdgUvvg4X63CaKIb7TC4cNJKFXtsE6NWfYjXH6ubkfX1S30/gLs=
X-Received: by 2002:a02:c886:: with SMTP id m6mr1742340jao.53.1582583237064; Mon, 24 Feb 2020 14:27:17 -0800 (PST)
MIME-Version: 1.0
References:     <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>
In-Reply-To: <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>
From: Rob Sayre 
Date: Mon, 24 Feb 2020 14:27:05 -0800
Message-ID: 
To: Christopher Wood 
Cc: "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000ac3f59059f59dfdd"
Archived-At: 
Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 22:27:20 -0000

--000000000000ac3f59059f59dfdd
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 24, 2020 at 12:50 PM Christopher Wood 
wrote:

> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
> >
> >
> > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla  wrote:
> > >
> > >
> > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre  wrote:
> > >> Hi,
> > >>
> > >> I'm not sure how violations of these requirements would result in
> poor interoperability:
> > >>
> > >>  Clients which import external keys TLS MUST NOT use these keys for
> > >>  any other purpose. Moreover, each external PSK MUST be associated
> > >>  with at most one hash function.
> > >>
> > >> These seem like aspirational security goals. It would be better to
> describe the consequences of violating these conditions.
> > >
> > > I don't agree. They are requirements in order to be able to make the
> assertions we want to make about the security of the protocol.
> > >
> > > This is consistent with the following text of RFC 2119 S 6
> > > ".. or to limit behavior which has potential for causing harm (e.g.,
> limiting retransmisssions) "
> > >
> > > I don't think it would be unreasonable.to explain the reason for
> these, though this is already a requirement of 8446 S 4.2.11 (though
> without justification).
> >
> > I think that interpretation of 2119 is a stretch, but your idea to add
> > an explanation while keeping the 2119 terms addresses my concern. At
> > the very least, the draft should note this is already a requirement of
> > 8446.
>
> That seems perfectly reasonable! We can point to the security
> considerations to clarify the "single hash function" requirement, and we
> can note cross protocol attack deterrence for the other claim. Would that
> suffice? If not, can you please recommend text?
>

That sounds fine. If I have nits with what's written, I'll suggest text.

thanks,
Rob

--000000000000ac3f59059f59dfdd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Feb 24, 2020 at 12:50 PM Chri=
stopher Wood <caw@heapingbits.net=
> wrote:
=
On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:

> 

> 

> On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla <ekr@rtfm.com> wrote:

> > 

> > 

> > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <sayrer@gmail.com> wrote:

> >> Hi,

> >> 

> >> I'm not sure how violations of these requirements would r=
esult in poor interoperability:

> >> 

> >>=C2=A0 Clients which import external keys TLS MUST NOT use the=
se keys for

> >>=C2=A0 any other purpose. Moreover, each external PSK MUST be =
associated

> >>=C2=A0 with at most one hash function.

> >> 

> >> These seem like aspirational security goals. It would be bett=
er to describe the consequences of violating these conditions.

> > 

> > I don't agree. They are requirements in order to be able to m=
ake the assertions we want to make about the security of the protocol.

> > 

> > This is consistent with the following text of RFC 2119 S 6

> > ".. or to limit behavior which has potential for causing har=
m (e.g., limiting retransmisssions) "

> > 

> > I don't think it would be unreasonable.to explain the reason=
 for these, though this is already a requirement of 8446 S 4.2.11 (though w=
ithout justification).

> 

> I think that interpretation of 2119 is a stretch, but your idea to add=
 

> an explanation while keeping the 2119 terms addresses my concern. At <=
br>
> the very least, the draft should note this is already a requirement of=
 

> 8446.



That seems perfectly reasonable! We can point to the security consideration=
s to clarify the "single hash function" requirement, and we can n=
ote cross protocol attack deterrence for the other claim. Would that suffic=
e? If not, can you please recommend text?

That sounds fine. If I have nits with what's written, I'll sugge=
st text.

thanks,
Rob
=C2=A0


--000000000000ac3f59059f59dfdd--


From nobody Mon Feb 24 14:58:26 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA6D3A14F7 for ; Mon, 24 Feb 2020 14:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 QiImWqxvPFz6 for ; Mon, 24 Feb 2020 14:58:18 -0800 (PST)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799D43A14F5 for ; Mon, 24 Feb 2020 14:58:07 -0800 (PST)
Received: by mail-vs1-xe36.google.com with SMTP id b79so6784729vsd.9 for ; Mon, 24 Feb 2020 14:58:07 -0800 (PST)
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=VPJl8aU33+cye/2C8xj56FUzDY3E5MdXrVH+mH4ZlZE=; b=qc0X6bAsSFNT01deGQsTo7KCLd2t7ssRSIeJAO60mg+VOLXq43DQNOYFQWN7bCQ4KQ F7Nzri3jFt7gQ/0cvwNFMQAPtzqiXOxNhi/PFZMbbqvs777mKNN7FFUIKTNgDhHW01Se fEHAiDP/G1iXeCv8FIpr/uJNJYdKbyHMh+41X2NTHHbgIux2UUcHjc/8GrrhykR3bAoh d+HlZ6C9QvXCelFx167PFDvazhrNXD6pyBHt8wnTY9ko8uHrAvNPfDUQv92VIzSjPTjF HRDjdgawG43CiC+FKX8AjZ8pXPgGzGonS/DhgiWUOY0LetixCe5kj//qOU9Wv21O0jKu n5uQ==
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=VPJl8aU33+cye/2C8xj56FUzDY3E5MdXrVH+mH4ZlZE=; b=iE7GdYQAulEYwc5efuFhW9JoiqvhUTql998i8dKXteNGfSew8FnC9ExQbkjEHCE9l1 XUmIkIBMrLae1cZ79NX2gVSm134ioTVmCEoceHT2iDI320sFFgR24diIDPBbdDu3LVun lQUhnDakbueCdaFtokApZjfxARV8g3fHzdy6qqjWrI0zoo0a2L3pUfVOlPJhXsZPrcaM 1+TY9hw8N2btH9cGEE7+rsclK+rmAaUJ3NIvlUZ85nSk9k7t0IUmh3eDuCXaU1KSgaXO kziUesC+Jv+EV/sJCxO7BiI2OgzskXHSPCAFzxo7A/x+5fP0bvWlM5ZCWlZuFlSNJWJd V12Q==
X-Gm-Message-State: APjAAAXy26CVGYvsgUeXKLruUjN5CBcBexiZ1Q2O3tgBy/yPRKPLQH0Y qkhFGexjMlTLVSgP3ShbWGnlHPxmIf0XQPkLmo17mJLt
X-Google-Smtp-Source: APXvYqzpI4bSlzJtnw66SoSfPyqdoGUYv8bZIbUNbmUYKezTTXstTnWFd9iFlVU0xHfOLv7Kpru/2NJJfct2y2576CI=
X-Received: by 2002:a67:eac5:: with SMTP id s5mr27899568vso.148.1582585081388;  Mon, 24 Feb 2020 14:58:01 -0800 (PST)
MIME-Version: 1.0
References:     <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>  
In-Reply-To: 
From: Jonathan Hoyland 
Date: Mon, 24 Feb 2020 22:57:50 +0000
Message-ID: 
To: David Benjamin 
Cc: Christopher Wood , "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000009a6dc9059f5a4dcf"
Archived-At: 
Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 22:58:25 -0000

--0000000000009a6dc9059f5a4dcf
Content-Type: text/plain; charset="UTF-8"

This would be for cases where we want to inject extra context into a
resumption.
That would be anything that changes an authentication property, so
for example if you wanted to include some agreement on the status of a
post-handshake auth or Exported Authenticator.

So for example imagine I had a session during which I received an EA and
when I came to resume that session I wished to indicate that I was still
willing to accept the EA.
I would offer a special PSK and inject some extra material into the
handshake*, and if the server was able / willing to agree to this it would
select the PSK.
I could also offer a PSK with no extra injected material, as a fallback,
and request the EA again.

* This would only affect the binder for the PSK in the ClientHello.

Another potential use would be the binding for ECHO, although I don't have
a clear enough picture of the precise mechanics of that to know if it would
be helpful.

Something that would allow for a consistent naming in the future would be
my preference, because just as "imp binder" doesn't preclude "imp r
binder", using "imp e binder" doesn't preclude us never adopting "imp r
binder".
I vaguely remember discussing whether the longer name would tip us into an
extra hash invocation at the last IETF,  and concluding that it didn't,
although I'd have to double check that.

Regards,

Jonathan

On Mon, 24 Feb 2020, 22:23 David Benjamin,  wrote:

> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <
> jonathan.hoyland@gmail.com> wrote:
>
>> Just looking at this again, it might be better to make a slightly
>> different tweak to the key schedule.
>> Instead of:
>>
>>                 0
>>                 |
>>                 v
>>       PSK ->  HKDF-Extract = Early Secret
>>                 |
>>                 +-----> Derive-Secret(., "ext binder"
>>                 |                      | "res binder"
>>                 |                      | "imp binder", "")
>>                 |                     = binder_key
>>
>>                 v
>>
>>
>>
>> We should do:
>>
>>                 0
>>                 |
>>                 v
>>       PSK ->  HKDF-Extract = Early Secret
>>                 |
>>                 +-----> Derive-Secret(., "ext binder"
>>                 |                      | "res binder"
>>                 |                      | "imp e binder"
>>
>>                 |                      | "imp r binder", "")
>>                 |                     = binder_key
>>
>>                 v
>>
>>
>> or at least:
>>
>>                 0
>>                 |
>>                 v
>>       PSK ->  HKDF-Extract = Early Secret
>>                 |
>>                 +-----> Derive-Secret(., "ext binder"
>>                 |                      | "res binder"
>>                 |                      | "imp e binder", "")
>>                 |                     = binder_key
>>
>>                 v
>>
>>
>>
>>
>> Just so that we can distinguish between external imported binders and
>> resumed imported binders, should we at some point decide to do both.
>>
>
> I may just be confused, but what would a resumed imported binder mean? I
> see this mechanism as largely a bugfix for TLS 1.3 external PSKs, rather
> than a new kind of adjective describing PSKs.
>
> ("imp binder" also doesn't preclude "imp r binder" later if we later
> define something which needs it, but I'm confused what the concept even
> would be.)
>
> David
>
>
>> On Mon, 24 Feb 2020 at 20:50, Christopher Wood 
>> wrote:
>>
>>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
>>> >
>>> >
>>> > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla  wrote:
>>> > >
>>> > >
>>> > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre  wrote:
>>> > >> Hi,
>>> > >>
>>> > >> I'm not sure how violations of these requirements would result in
>>> poor interoperability:
>>> > >>
>>> > >>  Clients which import external keys TLS MUST NOT use these keys for
>>> > >>  any other purpose. Moreover, each external PSK MUST be associated
>>> > >>  with at most one hash function.
>>> > >>
>>> > >> These seem like aspirational security goals. It would be better to
>>> describe the consequences of violating these conditions.
>>> > >
>>> > > I don't agree. They are requirements in order to be able to make the
>>> assertions we want to make about the security of the protocol.
>>> > >
>>> > > This is consistent with the following text of RFC 2119 S 6
>>> > > ".. or to limit behavior which has potential for causing harm (e.g.,
>>> limiting retransmisssions) "
>>> > >
>>> > > I don't think it would be unreasonable.to explain the reason for
>>> these, though this is already a requirement of 8446 S 4.2.11 (though
>>> without justification).
>>> >
>>> > I think that interpretation of 2119 is a stretch, but your idea to add
>>> > an explanation while keeping the 2119 terms addresses my concern. At
>>> > the very least, the draft should note this is already a requirement of
>>> > 8446.
>>>
>>> That seems perfectly reasonable! We can point to the security
>>> considerations to clarify the "single hash function" requirement, and we
>>> can note cross protocol attack deterrence for the other claim. Would that
>>> suffice? If not, can you please recommend text?
>>>
>>> Thanks,
>>> Chris
>>>
>>> _______________________________________________
>>> 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
>>
>

--0000000000009a6dc9059f5a4dcf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This would be for cases where=C2=A0we wa=
nt to inject extra context into a resumption.=C2=A0
That would be=
 anything that changes an authentication property, so for=C2=A0example if y=
ou wanted to include some agreement on the status of a post-handshake auth =
or Exported Authenticator.

So for example imagine =
I had a session during which I received an EA and when I came to resume tha=
t session I wished to indicate that I was still willing to accept the EA.
I would offer a special PSK and inject some extra material into th=
e handshake*, and if the server was able / willing to agree to this it woul=
d select the PSK.=C2=A0
I could also offer a PSK with no extra in=
jected material, as a fallback, and request the EA again.=C2=A0
<=
br>
* This would only affect the binder for the PSK in the Client=
Hello.=C2=A0

Another potential use would be the bi=
nding=C2=A0for ECHO, although I don't have a clear enough picture of th=
e precise mechanics of that to know if it would be helpful.

<=
/div>
Something that would allow for a consistent naming in the future =
would be my preference, because just as "imp binder" doesn't =
preclude "imp r binder", using "imp e binder" doesn'=
;t preclude us never adopting "imp r binder".
I vaguely=
 remember discussing whether the longer name would tip us into an extra has=
h invocation at the last IETF,=C2=A0 and concluding that it didn't, alt=
hough I'd have to double check that.=C2=A0

Reg=
ards,

Jonathan=C2=A0

On Mon, 24 Feb 2020, 22:=
23 David Benjamin, <davidben@chromium.org> wrote:
On Mon, Feb 2=
4, 2020 at 4:33 PM Jonathan Hoyland <jonathan.hoyland@gmail.com<=
/a>> wrote:
Just looking at this again, it m=
ight be better to make a slightly different tweak to the key schedule.
=
Instead of:
                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp binder", "&quo=
t;)
                |                     =3D binder_key
                v


We should do:

<=
pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef=
ore:page;color:rgb(0,0,0)">                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder"                |                      | "imp =
r binder", "")
                |                     =3D binder_key
                v

or =
at least:
                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder", "&q=
uot;)
                |                     =3D binder_key
                v


<=
br>
Just so that we can distinguish between external imported binders =
and resumed imported binders, should we at some point decide to do both.=C2=
=A0



On Mon, 24 Feb 2020 at 20:50, Christopher Wood <<=
a href=3D"mailto:caw@heapingbits.net" rel=3D"noreferrer" target=3D"_blank">=
caw@heapingbits.net> wrote:
On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:

> 

> 

> On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla <ekr@rtfm.com> wrote=
:

> > 

> > 

> > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <sayrer@gmail.com&=
gt; wrote:

> >> Hi,

> >> 

> >> I'm not sure how violations of these requirements would r=
esult in poor interoperability:

> >> 

> >>=C2=A0 Clients which import external keys TLS MUST NOT use the=
se keys for

> >>=C2=A0 any other purpose. Moreover, each external PSK MUST be =
associated

> >>=C2=A0 with at most one hash function.

> >> 

> >> These seem like aspirational security goals. It would be bett=
er to describe the consequences of violating these conditions.

> > 

> > I don't agree. They are requirements in order to be able to m=
ake the assertions we want to make about the security of the protocol.

> > 

> > This is consistent with the following text of RFC 2119 S 6

> > ".. or to limit behavior which has potential for causing har=
m (e.g., limiting retransmisssions) "

> > 

> > I don't think it would be unreasonable.to explain=
 the reason for these, though this is already a requirement of 8446 S 4.2.1=
1 (though without justification).

> 

> I think that interpretation of 2119 is a stretch, but your idea to add=
 

> an explanation while keeping the 2119 terms addresses my concern. At <=
br>
> the very least, the draft should note this is already a requirement of=
 

> 8446.



That seems perfectly reasonable! We can point to the security consideration=
s to clarify the "single hash function" requirement, and we can n=
ote cross protocol attack deterrence for the other claim. Would that suffic=
e? If not, can you please recommend text?



Thanks,

Chris



_______________________________________________

TLS mailing list

TLS@ie=
tf.org

https://www.ietf.org/mailman/listinfo/tls


_______________________________________________

TLS mailing list

TLS@ie=
tf.org

https://www.ietf.org/mailman/listinfo/tls





--0000000000009a6dc9059f5a4dcf--


From nobody Mon Feb 24 23:33:25 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F5D3A0933 for ; Mon, 24 Feb 2020 23:33:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=openfortress.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl7Nzk-6gMAy for ; Mon, 24 Feb 2020 23:33:19 -0800 (PST)
Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2087C3A092D for ; Mon, 24 Feb 2020 23:33:16 -0800 (PST)
Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud8.xs4all.net with ESMTP id 6UiMjBuErPKvK6UiNjp26Y; Tue, 25 Feb 2020 08:33:12 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl;  i=rick@openfortress.nl; q=dns/txt; s=fame; t=1582615981;  h=message-id : date : from : mime-version : to : cc :  subject : content-type : content-transfer-encoding : date  : from : subject;  bh=NkwD78lxQHG82gMe8x+wMvs4RzET8Zsr71Wq19y+Qh0=;  b=VIdaEURVBCfdoCC3Vh+tA/mWiwARCuL1mEjy4KQFbl+CQwPRqZfJZ/Xd E0BEAocIDUFp5h5+G7TcxhlhU4AyHEIVqTwX0ZPprcRtD7JVh+ZKe9BXQI L1LG2q3w1FrezyEtYvy98yBComVUdInqL2pUxUYi9ASKlUvtNpTZvJ0OM=
Received: by fame.vanrein.org (Postfix, from userid 1006) id DE68B26542; Tue, 25 Feb 2020 07:32:53 +0000 (UTC)
X-Original-To: tls@ietf.org
Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 8452126753; Tue, 25 Feb 2020 07:32:49 +0000 (UTC)
Message-ID: <5E54CDA0.8070209@openfortress.nl>
Date: Tue, 25 Feb 2020 08:32:48 +0100
From: Rick van Rein 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: TLS WG 
CC: "Tom Vrancken (ARPA2)" 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4
X-CMAE-Envelope: MS4wfP4A0SgKjQnVhecFhgPFaisIW/nk2b/WXxTmB/7/f7wqYzJlAOCvun0kvvfk5Fh5JTOWjucEtSPfpUkg5ZJY/MiBWTGoeqqCYyGpq9sGjymU9OJ4zbG1 gFQ8tSKo7dzrRtaB6vMfbjvO6MKNo6x30r6Zz94knM4se4sPrs91Y+Pq
Archived-At: 
Subject: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 07:33:23 -0000

Hello,

We have prepared the following draft, and request feedback on it.  The
main points are

 * Introduction of (anonymous) Kerberos tickets as added entropy to mix
with ECDH, and thereby provide Quantum Relief; it generalises this idea
to allow for other ways of adding entropy
 * Introduction of Kerberos Tickets for Certificate and
CertificateVerify messages
 * User identity on the server side; how TLS can be relayed to a peer,
which Kerberos can handle with its user-to-user authentication
mechanism; it generalises this idea, and perhaps it might be better as a
separate TLS Extension under ClientHello encryption.
 * Everything applies to TLS 1.3 as well as 1.2.

Our intention is to launch this as an independent proposal.

Your insights are highly appreciated!


Best,

Rick van Rein
Tom Vrancken



A new version of I-D, draft-vanrein-tls-kdh-06.txt
has been successfully submitted by Rick van Rein and posted to the
IETF repository.

Name:		draft-vanrein-tls-kdh
Revision:	06
Title:		Quantum Relief with TLS and Kerberos
Document date:	2020-01-22
Group:		Individual Submission
Pages:		19
URL:
https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-06.txt
Status:         https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/
Htmlized:       https://tools.ietf.org/html/draft-vanrein-tls-kdh-06
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vanrein-tls-kdh
Diff:           https://www.ietf.org/rfcdiff?url2=draft-vanrein-tls-kdh-06

Abstract:
   This specification describes a mechanism to use Kerberos
   authentication within the TLS protocol.  This gives users of TLS a
   strong alternative to classic PKI-based authentication, and at the
   same introduces a way to insert entropy into TLS' key schedule such
   that the resulting protocol becomes resistant against attacks from
   quantum computers.  We call this Quantum Relief, and specify it as
   part of a more general framework to make it easier for other
   technologies to achieve similar benefits.


From nobody Tue Feb 25 08:25:17 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08693A0D39 for ; Tue, 25 Feb 2020 08:25:15 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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 UvocBY8r9mxi for ; Tue, 25 Feb 2020 08:25:13 -0800 (PST)
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 BBEFA3A1038 for ; Tue, 25 Feb 2020 08:25:13 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01PGCR8M019830; Tue, 25 Feb 2020 16:25:09 GMT
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-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=DfOREPFQR704+xhb6PjVBcMMBmuWxmOv1DAuvTWqons=; b=WtHeEmVYWzf00E3Vheld54Z+hdUfs34WaOfiw96+1hhMSby3vH+Xg3ZCRVjypLW1p84Z twFf5j4WJ4QVciRJi2Wwz8Y5+DlSsOHkJ6WUsF8Tkpiv+ys55I6R/QY6k1JkKFC1ct9m lLrVqu+ogFrffnw6awmk8tMoBe6UkZ//7+76b3Bfi0JGd0CYADqEc18iC7eBk3nV7DqM BAfkvFLYSdyWTywUkhW0gXA3lmdO0icX5aY1jCKdLDqjdfBmxwulpFahRQy4JjXRksEk 49N17y9UylV8OjIuIYfUmaE05B17okoCnnkZ1YW05v1x8l1WSsqs6NaXvD9rkIk4fKwU 1Q== 
Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2yaw7rdky7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 16:25:09 +0000
Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01PFo1n5021455; Tue, 25 Feb 2020 11:25:07 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint6.akamai.com with ESMTP id 2yb0gyj9e6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 11:25:07 -0500
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.1473.3; Tue, 25 Feb 2020 11:25:06 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Tue, 25 Feb 2020 11:25:04 -0500
From: "Salz, Rich" 
To: Rick van Rein , TLS WG 
CC: "Tom Vrancken (ARPA2)" 
Thread-Topic: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
Thread-Index: AQHV664smMYOQGzncUmp8C0Yy6BnoKgsGOoA
Date: Tue, 25 Feb 2020 16:25:04 +0000
Message-ID: <735DE784-87A7-4084-B804-C6199C3F5D49@akamai.com>
References: <5E54CDA0.8070209@openfortress.nl>
In-Reply-To: <5E54CDA0.8070209@openfortress.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.22.0.200209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.117.11]
Content-Type: text/plain; charset="utf-8"
Content-ID: <1D8E90B32A97BD43AD5CE0141457992F@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-25_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=618 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002250123
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-25_05:2020-02-21, 2020-02-25 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 malwarescore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 suspectscore=0 mlxlogscore=585 spamscore=0 adultscore=0 mlxscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002250124
Archived-At: 
Subject: Re: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 16:25:16 -0000

ICAgICAqIEludHJvZHVjdGlvbiBvZiAoYW5vbnltb3VzKSBLZXJiZXJvcyB0aWNrZXRzIGFzIGFk
ZGVkIGVudHJvcHkgdG8gbWl4DQogICAgd2l0aCBFQ0RILCBhbmQgdGhlcmVieSBwcm92aWRlIFF1
YW50dW0gUmVsaWVmOyBpdCBnZW5lcmFsaXNlcyB0aGlzIGlkZWENCiAgICB0byBhbGxvdyBmb3Ig
b3RoZXIgd2F5cyBvZiBhZGRpbmcgZW50cm9weQ0KDQpIYXZlIHlvdSBzZWVuIGh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlydGYtY2ZyZy1yYW5kb21uZXNzLWltcHJvdmVt
ZW50cy8gPw0KDQoNCg==


From nobody Tue Feb 25 11:15:42 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0203A1437 for ; Tue, 25 Feb 2020 11:15:34 -0800 (PST)
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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=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 tAIawN_W-jC4 for ; Tue, 25 Feb 2020 11:15:33 -0800 (PST)
Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (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 ECFAF3A1440 for ; Tue, 25 Feb 2020 11:15:32 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 396973419C2; Tue, 25 Feb 2020 19:15:32 +0000 (UTC)
Received: from pdx1-sub0-mail-a24.g.dreamhost.com (100-96-215-18.trex.outbound.svc.cluster.local [100.96.215.18]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B19F334198E; Tue, 25 Feb 2020 19:15:31 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a24.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 25 Feb 2020 19:15:32 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Thread-Trouble: 3e4d270f3659496f_1582658131977_719992035
X-MC-Loop-Signature: 1582658131977:1582693301
X-MC-Ingress-Time: 1582658131977
Received: from pdx1-sub0-mail-a24.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTP id DCC417FC4A; Tue, 25 Feb 2020 11:15:27 -0800 (PST)
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=5Itdnibzly6Ge8 nS+slzPrGHV/U=; b=cH6mP5ZFQxCBl1jz0v405WG/JC2Qb1OP4p4tFJoTEu/Owq 1ujVK/T2mF8Bf5pXIs/jevX1vfHSzYcaFzpQIwmQ82HpyhiEMltcZUJC1SaIpHHJ BspLM4sWM2dbi3dXPdosV4MxXY8zvoQFjBBtZbp8xMoyr2BENLXje9zbSfCTA=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTPSA id B16B17FC7A; Tue, 25 Feb 2020 11:15:23 -0800 (PST)
Date: Tue, 25 Feb 2020 13:15:20 -0600
X-DH-BACKEND: pdx1-sub0-mail-a24
From: Nico Williams 
To: Rick van Rein 
Cc: TLS WG , "Tom Vrancken (ARPA2)" 
Message-ID: <20200225191519.GH18021@localhost>
References: <5E54CDA0.8070209@openfortress.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5E54CDA0.8070209@openfortress.nl>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrledvgdduvddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: 
Subject: Re: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 19:15:34 -0000

On Tue, Feb 25, 2020 at 08:32:48AM +0100, Rick van Rein wrote:
> We have prepared the following draft, and request feedback on it.  The
> main points are
> 
>  * Introduction of (anonymous) Kerberos tickets as added entropy to mix
> with ECDH, and thereby provide Quantum Relief; it generalises this idea
> to allow for other ways of adding entropy

I don't believe that using Kerberos helps on the _entropy_ side as much
as on the PQ side.

Specifically, Needham-Schroeder is PQ provided you're using a PQ cipher,
which AES-256 essentially is.  Kerberos being based on
Needhamr-Shcroeder...

Now, the biggest problem with Kerberos is that with manually-keyed
cross-realm trusts doesn't scale to Internet scale.  But there's a way
to fix that too: use PQ PK with PKINIT as a form of "PKCROSS", and now
Kerberos can function as a way of amortizing PQ PK costs.

>  * Introduction of Kerberos Tickets for Certificate and
> CertificateVerify messages

Kerberos tickets and AP-REQs could be used as session resumption
tickets.  That only works for TLS 1.3, but I'm OK with that.

Nico
-- 


From nobody Tue Feb 25 11:31:03 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3C73A141A for ; Tue, 25 Feb 2020 11:31:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=openfortress.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpa3HE9X9vZM for ; Tue, 25 Feb 2020 11:30:59 -0800 (PST)
Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0903A139A for ; Tue, 25 Feb 2020 11:30:58 -0800 (PST)
Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud8.xs4all.net with ESMTP id 6fuvjEiLzPKvK6fuwjqj6X; Tue, 25 Feb 2020 20:30:54 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl;  i=rick@openfortress.nl; q=dns/txt; s=fame; t=1582659044;  h=message-id : date : from : mime-version : to : cc :  subject : references : in-reply-to : content-type :  content-transfer-encoding : date : from : subject;  bh=xPa84fDUBFND8BLuwvngQgDmAICPsAm2JqOUPcHmczQ=;  b=SipBU6EZGD0HKfLPGqMZWMDkQ8dY+B3NuXomvPShXI2rPWiTE8oseD+X B3Yr5T9Cjsufme2lMsz22oWsLFvYpAU7YTEexieQk5GNrGglEBv2eIxQhJ BB5eEiOqetlHh27NfXUI2zLkv1+Gin+M119XPoMh+bIMrfsPIsNzQ80Mw=
Received: by fame.vanrein.org (Postfix, from userid 1006) id 6DC18267F3; Tue, 25 Feb 2020 19:30:26 +0000 (UTC)
X-Original-To: tls@ietf.org
Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id DAEAC26433; Tue, 25 Feb 2020 19:30:22 +0000 (UTC)
Message-ID: <5E5575CD.2040806@openfortress.nl>
Date: Tue, 25 Feb 2020 20:30:21 +0100
From: Rick van Rein 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "Salz, Rich" 
CC: TLS WG ,  "Tom Vrancken (ARPA2)" 
References: <5E54CDA0.8070209@openfortress.nl> <735DE784-87A7-4084-B804-C6199C3F5D49@akamai.com>
In-Reply-To: <735DE784-87A7-4084-B804-C6199C3F5D49@akamai.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4
X-CMAE-Envelope: MS4wfPb1dL+QTNSFqkTKVkqxOkaq2nHpntOkkeoMMXWN3U1N7lQLhPDFDAHCVCJXPg811bqbrVeEGC+iODxSvJQEaOu0HRP8hAByWbFNPvJ0Mf1fghvJ9TNT U5Z37ETNDz0PUcEs6HRXOIY61h7q023EIlo3lcL1gsXX2xqRxqAf7x0r
Archived-At: 
Subject: Re: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 19:31:02 -0000

Hi Rich,

Salz, Rich wrote:
>      * Introduction of (anonymous) Kerberos tickets as added entropy to mix
>     with ECDH, and thereby provide Quantum Relief; it generalises this idea
>     to allow for other ways of adding entropy
>
> Have you seen https://datatracker.ietf.org/doc/draft-irtf-cfrg-randomness-improvements/ ?

I hadn't.  Are you suggesting to insert the session key, or anything derived from it, into this CPRNG-alternative mechanism?

The spec speaks of ways of communicating entropy, not necessarily having them available on two ends yet.  That's a mild generalistion over the idea of passing a Kerberos ticket, which is essentially the pupose of this proposal.  I am however listening here if the generalisation is useful.  (I do have a few immature ideas that could use it.)

-Rick


From nobody Tue Feb 25 11:36:23 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95A73A12BE for ; Tue, 25 Feb 2020 11:36:21 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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 dVGSUm8Uq2Ev for ; Tue, 25 Feb 2020 11:36:20 -0800 (PST)
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 B023B3A111D for ; Tue, 25 Feb 2020 11:36:20 -0800 (PST)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01PJWDvd026789; Tue, 25 Feb 2020 19:36:15 GMT
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-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Po1OKeqB7vWuqkPJ1HQnZPbDhT0DKBmNioHxbBKLzLw=; b=J/uvgXT4XwY0Gicj1Q5shbzcuHlZYS2hJmhCxAuG5a8nAY8UKMwFYChkVAas4/MvBa+C W/2kwDEXL2AzLKLbOppe6imhILY1TsQXoNmjtlMyaU55/NnGj3uZ9E+Ri3+2U/PmSbgZ gonk9QALz29RyR/N4JeSxj5vjEXkxDVmWoBsytGeX3YVbizLy6MKxQFeISkxbzbYH0Ee CO0+1jWEgx5qfk6RqriNrLKWNg0C1iKLeqZ8isYcXOGknX2MLEq024m99HhF1vr3IC4G TCaUti61RlhMjGl7FWSWpsnOpdMwm7gabbH/9c03q22auZ3mAPwzqE+KVZWjdJYG9SKS +A== 
Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2yavu2x5hf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 19:36:15 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01PJW2mH031691; Tue, 25 Feb 2020 14:36:14 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint8.akamai.com with ESMTP id 2yb0h1j74s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 14:36:14 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Feb 2020 14:36:13 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 25 Feb 2020 14:36:12 -0500
From: "Salz, Rich" 
To: Rick van Rein 
CC: TLS WG , "Tom Vrancken (ARPA2)" 
Thread-Topic: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
Thread-Index: AQHV664smMYOQGzncUmp8C0Yy6BnoKgsGOoAgACHlID//63RAA==
Date: Tue, 25 Feb 2020 19:36:11 +0000
Message-ID: 
References: <5E54CDA0.8070209@openfortress.nl> <735DE784-87A7-4084-B804-C6199C3F5D49@akamai.com> <5E5575CD.2040806@openfortress.nl>
In-Reply-To: <5E5575CD.2040806@openfortress.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.22.0.200209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.114.190]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4C5A20E5DF62E64CAE6881434AA2939F@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-25_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=865 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002250137
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-25_07:2020-02-25, 2020-02-25 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 phishscore=0 suspectscore=0 mlxlogscore=838 mlxscore=0 bulkscore=0 clxscore=1015 impostorscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002250137
Archived-At: 
Subject: Re: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 19:36:22 -0000

ICAgID4gSGF2ZSB5b3Ugc2VlbiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1pcnRmLWNmcmctcmFuZG9tbmVzcy1pbXByb3ZlbWVudHMvID8NCiAgICANCiAgICBJIGhhZG4n
dC4gIEFyZSB5b3Ugc3VnZ2VzdGluZyB0byBpbnNlcnQgdGhlIHNlc3Npb24ga2V5LCBvciBhbnl0
aGluZyBkZXJpdmVkIGZyb20gaXQsIGludG8gdGhpcyBDUFJORy1hbHRlcm5hdGl2ZSBtZWNoYW5p
c20/DQoNCkknbSBub3Qgc3VnZ2VzdGluZyBhbnl0aGluZywganVzdCBwb2ludGluZyBvdXQgc29t
ZSBwb3NzaWJseS1yZWxhdGVkIHdvcmsuIDopDQoNCg==


From nobody Wed Feb 26 01:41:24 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589A23A119C for ; Wed, 26 Feb 2020 01:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=openfortress.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LmfJoi7o06x for ; Wed, 26 Feb 2020 01:41:19 -0800 (PST)
Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (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 6D8A03A1199 for ; Wed, 26 Feb 2020 01:41:18 -0800 (PST)
Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud8.xs4all.net with ESMTP id 6tBqjHRYVPKvK6tBrjs3S0; Wed, 26 Feb 2020 10:41:16 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl;  i=rick@openfortress.nl; q=dns/txt; s=fame; t=1582710065;  h=message-id : date : from : mime-version : to : cc :  subject : references : in-reply-to : content-type :  content-transfer-encoding : date : from : subject;  bh=Lh/XYtu6FrMwjZTqcYlUJwAgZCBf35A0trERzLUYFPQ=;  b=aVQt983uOIz3LCgiaEqVeKMbx9RQgcfHR3aVv5rDkMXZgtDQvdbyBC06 o4qzytPg6jiCxmzthTiXGNy07cMsEV5SCCjUiD6z7l5jEIWlwQkhcVgHxU pbhJ29sf3B2NCbMuL9vDGpg6gTfvb34ihi/7Vw0gqthLgJ3JrTBGxw9lE=
Received: by fame.vanrein.org (Postfix, from userid 1006) id 972F02689A; Wed, 26 Feb 2020 09:40:47 +0000 (UTC)
X-Original-To: tls@ietf.org
Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id B2B9026899; Wed, 26 Feb 2020 09:40:46 +0000 (UTC)
Message-ID: <5E563D1C.9010209@openfortress.nl>
Date: Wed, 26 Feb 2020 10:40:44 +0100
From: Rick van Rein 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Nico Williams 
CC: TLS WG ,  "Tom Vrancken (ARPA2)" 
References: <5E54CDA0.8070209@openfortress.nl> <20200225191519.GH18021@localhost>
In-Reply-To: <20200225191519.GH18021@localhost>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4
X-CMAE-Envelope: MS4wfDmAmmNx7wyl6qDGor5kJX4zvxq/KJOiGlkcfd0EPRbFOg8V37MIrldPwx/gvbHtD1ik3HCvb/7RyjxLxZcY+VFQX/aUYRsQ9FR6d/NHCKl5vXTLovgf g1alShcLAFGL0nMFRAFMc+dUPQJJifyViP1L78S17rMeivrM+NjiXCWr
Archived-At: 
Subject: Re: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 09:41:22 -0000

Hello Nico,

> I don't believe that using Kerberos helps on the _entropy_ side as much
> as on the PQ side.

Ah; I meant to (be terse and) say that it adds an independent source of entropy that leaves no traces in the TLS flow subject to, indeed, Quantum Computer cracking.

> Now, the biggest problem with Kerberos is that with manually-keyed
> cross-realm trusts doesn't scale to Internet scale.  But there's a way
> to fix that too: use PQ PK with PKINIT as a form of "PKCROSS", and now
> Kerberos can function as a way of amortizing PQ PK costs.

Indeed :- though I'd have mentioned KXOVER or Kerberos Realm Crossover,
https://gitlab.com/arpa2/kxover
This is founded on DNSSEC, DANE and TLS.

Thanks,
 -Rick


From nobody Wed Feb 26 14:53:02 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911423A09C8 for ; Wed, 26 Feb 2020 14:53:00 -0800 (PST)
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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=mozilla.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeGJCfkL3vtP for ; Wed, 26 Feb 2020 14:52:58 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6523A09C7 for ; Wed, 26 Feb 2020 14:52:58 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id s24so1033988iog.5 for ; Wed, 26 Feb 2020 14:52:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=mime-version:from:date:message-id:subject:to; bh=kUmYbAfq2vnNXSoJ4dzoqk4TF2x7V6o+ryXoWqY+JAE=; b=f7YTOJ66cE55W84A3OqTHlhq2m2DtsyciBsep3ZhZ0GKZ8HR7Y5hbrx1x7QKH/R+wY 10/X3VTOKSpEqSerYN96CfwHnUGckjgj2AaET+wYL84OJ/GGK2GWIS98dd1DdItAR9Z3 ksRxNx7nb1v9mTCkSuOG9eT9kpS0p9TJENNsg=
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=kUmYbAfq2vnNXSoJ4dzoqk4TF2x7V6o+ryXoWqY+JAE=; b=tefva9ruRMWeKYNd6r74RTwJcGwQ7bDr05gzLS3ECP2osYf7y8nCbdukc/qzumuYRg oq+tPPL7o5bkrkWJSFDdK0RdkWp1wMnfTH6MUl3MeniKJfkagJkFteAm1wPbGCTfwi6B A1TIY5n1ahEtcoJ0SMFaxKiE1EW+8h/kenUwIZi98UR1i2wdxTx9/1gMGCEzln6AlpIL EX9H3ArTHOUK3OLpacMEUZ2seUtzrlsXGtAvQU7C8BXfwdgsJj+QRU3OXTi7M45VsdYP 9ns1RQPRCK46mCuOQC+6kuPm5QOIgmD333es2bGKL1f3sQX1VlpGElg7D/Xho7vMcHf0 HnEQ==
X-Gm-Message-State: APjAAAVdFIIRgkAI4QW+jyeK5BN9cUlwJ2T8d1tVtAOaGz+wfdXRA8+g ezEJJyu3dDc+FZ+DofikREDb5BcLpS0x83Kgz0J/DtILz2Y=
X-Google-Smtp-Source: APXvYqx8s70di2pZ57JyQNu2LMTe6f5E3z1+D2XGwF030T1QtkeZdtfMcCezLNVPec+qTw8X1qfGJgC4Juc8N99EsmE=
X-Received: by 2002:a5d:9c05:: with SMTP id 5mr963012ioe.18.1582757577690; Wed, 26 Feb 2020 14:52:57 -0800 (PST)
MIME-Version: 1.0
From: Kevin Jacobs 
Date: Wed, 26 Feb 2020 14:52:46 -0800
Message-ID: 
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002f2f03059f82774e"
Archived-At: 
Subject: [TLS] Clarification on Delegated Credential validation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 22:53:02 -0000

--0000000000002f2f03059f82774e
Content-Type: text/plain; charset="UTF-8"

TLSWG,

There seems to be some ambiguity in draft-ietf-tls-subcerts. [4.1.3
Validating a Delegated Credential] states: "1. Verify that the current
time is within the validity interval of the credential and that the
credential's time to live is no more than the maximum validity period.
This is done by asserting that the current time is no more than the
delegation certificate's notBefore value plus
DelegatedCredential.cred.valid_time."

There are two issues with this:


   1. The described assertion only ensures that the first condition is met.
   2. The second condition - "and that the credential's time to live is no
   more than the maximum validity period" - is unclear:
      1. If we assume "time to live" on a DC to be the remaining time
      (based on the verifying peer's clock), the described check should also
      assert "EECert.notBefore + DC.valid_time - currentTime <=
maximum validity
      period".
      2. If we assume "time to live" on a DC to be the initial TTL
      (spanning issuance to expiration), we lack the information needed to
      effectively verify this, as DC.valid_time is based on EECert.notBefore
      rather than DC.notBefore (which does not exist). For example, if
7-day DCs
      are issued, "EECert.notBefore + DC.valid_time" will be a 7-day
span on the
      first issuance, a 14-day span on the second, etc. until the EE cert is
      reissued.

I believe the first interpretation is intended, but the client is then
unable to verify that the DC lifespan is actually less than the
maximum validity period (should such a check be desired), only that
the DC will expire within that period. Either way, the expected
behavior should be clarified.

Thanks,
Kevin

--0000000000002f2f03059f82774e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


TLSWG, =


There seems to be some ambiguity in draft-ietf-tls-subcerts. [4.1.3=
 Validating a Delegated Credential] states: "1. Verify that the curren=
t time is within the validity interval of the credential and that the crede=
ntial's time to live is no more than the maximum validity period. This =
is done by asserting that the current time is no more than the delegation c=
ertificate's notBefore value plus DelegatedCredential.cred.valid_time.&=
quot;

There are two issues with this:
=

  1. The described assertion only ensures that the f=
irst condition is met.
  2. The=
 second condition - "and that the credential's time to live is no =
more than the maximum validity period" - is unclear:
    1. If we assume "time to live" o=
n a DC to be the remaining time (based on the verifying peer's clock), =
the described check should also assert "EECert.notBefore + DC.valid_ti=
me - currentTime <=3D maximum validity period".
    2. If we assume "time to live" on a DC=
 to be the initial TTL (spanning issuance to expiration), we lack the infor=
mation needed to effectively verify this, as DC.valid_time is based on EECe=
rt.notBefore rather than DC.notBefore (which does not exist). For example, =
if 7-day DCs are issued, "EECert.notBefore + DC.valid_time" will =
be a 7-day span on the first issuance, a 14-day span on the second, etc. un=
til the EE cert is reissued. 
I believe the first interpretation=
 is intended, but the client is then unable to verify that the DC lifespan =
is actually less than the maximum validity period (should such a check be d=
esired), only that the DC will expire within that period. Either way, the e=
xpected behavior should be clarified. 

Thanks,
Kevin


--0000000000002f2f03059f82774e--


From nobody Thu Feb 27 08:20:38 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC543A0C32 for ; Thu, 27 Feb 2020 08:20:29 -0800 (PST)
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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=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 xHw3_nD6VJF0 for ; Thu, 27 Feb 2020 08:20:28 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85FE33A0C0F for ; Thu, 27 Feb 2020 08:20:28 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id o28so3653783qkj.9 for ; Thu, 27 Feb 2020 08:20:28 -0800 (PST)
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=u+8Is3vtoVqLn52Wl5YWYfFUgdaCs1UtaquS86DsJWU=; b=ZztZ8mKodjxWtT4Ax96eOUZPpU20cV9/I8j7zSWM6qqXbhv5qglZQxmPqFGUpPlY8B rKqHJZDWToffKcEcu4W7gWdNvhKAvhfJ1q0tcbipzIi7wOvg6XEHQOIKiKULeEJFhMjX 9lPGAsnRETI9mJ8+EtIF7V/emnQm7hj6SGjkE=
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=u+8Is3vtoVqLn52Wl5YWYfFUgdaCs1UtaquS86DsJWU=; b=jny0fD7TP1CLKt+Ht9fqzfkkPNShT8VTV84yDgNFG5gkgBw1Vto0J6lzgH7KHtXg0T UNOFZfLYLxPJkv9UE2+56hXXP3AhG528hyNnxucPLjyVW1vJUOdOVlWHxqolE3mCjr7P J9MuUChcGKB7ovDvi94CCz/ACEZ1l0gK03UyKe7M4nSLryKW3uwNrnZOEg4rPbi4DwCO OMmpl9ys8qmN51ykTW5W8c0UJs3QJ1vTd5GOZRMv68DgTV47Zb1QAVGxXKSlF77kmJ2w XPE+AIBFSdR8wKBwsyn+w8kv1s+SS+ll1lhMX2RZATZZxC01KbHlllPFyNWQDE92LIoq iKgg==
X-Gm-Message-State: APjAAAVi1vri3/7+iC3Imz+XUi92PCMFJqrJcuGHQzpl2sg//GAJ6Dzv HG4zg7c7EytNMdIqjfy28sVh/jXE6/g=
X-Google-Smtp-Source: APXvYqxWkEfWE0YPG+Byj1kbpUFpAzDDYIRASZz9SVz7UIbf7b7zlLhHL5FAH04miPA2bs9lImGOjw==
X-Received: by 2002:a05:620a:958:: with SMTP id w24mr6537762qkw.87.1582820427506;  Thu, 27 Feb 2020 08:20:27 -0800 (PST)
Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id v10sm3276676qtp.22.2020.02.27.08.20.26 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 08:20:26 -0800 (PST)
From: Sean Turner 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <66B0A0BC-9255-4397-9B29-76C6CEFE7D1C@sn3rd.com>
Date: Thu, 27 Feb 2020 11:20:26 -0500
To: TLS List 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: [TLS] tls@IETF107 Important Dates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 16:20:36 -0000

FYI - the I-D submission deadline for IETF 107 is:
2020-03-09 (Monday) by UTC 23:59

Other dates can be found here:
https://datatracker.ietf.org/meeting/important-dates/

Cheers,

spt


From nobody Thu Feb 27 12:32:37 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336F23A0B8C for ; Thu, 27 Feb 2020 12:32:28 -0800 (PST)
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, 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=evequefou.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 Gah5-l6-TCla for ; Thu, 27 Feb 2020 12:32:26 -0800 (PST)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2091.outbound.protection.outlook.com [40.107.236.91]) (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 E9C833A0B91 for ; Thu, 27 Feb 2020 12:32:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UUXanKSQxCjPcOPERrbJmF/mI0y7n3Lz5BEFu+pRzHvMHEvo1z8i9AVcF1XmwMLjNIhKZI5Kb5pCmzPtbWR30wRL4KJRAx9QCT+oeFjIxZGENQSUVLX6Xreo96Wqjn7RaBPn4TB7EjDEh4q0Vx8Pu8M7NRokbw3njJBvfwgvzONCXo71u1Z4bTb8M362cdhV9HTl2zLkqOV2ZOncs5oGJiqGvEfc+EMtzfdddzDVs1fQOQmKWexmxx3MYqNMGdBR8UYEZ5IzsusXUZl60HSLECy7ADeSq6uVQIWzGmrOYPB3kgL9mcjtef+SND59xJIbVG+neCcHwpRRLFpWikQUvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/UwUHA+OdW7K55ivLcLjwfV8uYloZqV1O+2Hk/osd2I=; b=g3FW84emafyFbdDCUZVD6TcsdrU1UbYnrgX/lx9IhsfP7PM/rhRrHuwUFu0t21g5VfjYqO00Jzv25/9zkshd79YSdFHLQ8qCchfhtl+2EppfDi6y4drlOi4lJeqv7x1NqkaeY9xUSjN6nu6bo1Imr96z/68PgM6pe3Lewkg96y/TGFEnuv7pyXHPBY7OZAiV+1+nU3dQYROl+SbgCJzvvj+v0rLbJoMxDqMZpjVcRTnMgcdRnAQLA31fHqGYYnAq7wiYJ8ZyWbU0RthzUsoh6cY+WVYKrwu63ttiTWMUAvNFcsJGF1b64BqKFyLquXwp02YR7LGSviZk5MX29x1ehQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/UwUHA+OdW7K55ivLcLjwfV8uYloZqV1O+2Hk/osd2I=; b=bquWN+H3fxpqcPEV6w/l4xrUyq6qXlaocj2IhPcmmumb832qZ82c6P0SSukOKgHRpDwcgi5Ad2M2sjLv8yGsHgXLpvP2/YPqFpWZO8JsPQc98mcsnnAUNIfDGjowjnvl4X97/4TR1ZJ80zX0leWnn4sLO+PgCoGe9OuJ9aHYOwE=
Received: from CH2PR22MB2086.namprd22.prod.outlook.com (2603:10b6:610:8c::8) by CH2PR22MB2088.namprd22.prod.outlook.com (2603:10b6:610:89::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Thu, 27 Feb 2020 20:32:23 +0000
Received: from CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::fc4c:de9:3fcd:96dd]) by CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::fc4c:de9:3fcd:96dd%7]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 20:32:23 +0000
From: Mike Bishop 
To: Kevin Jacobs , "tls@ietf.org" 
Thread-Topic: [TLS] Clarification on Delegated Credential validation
Thread-Index: AQHV7PeSlJIrLeOhrU6EdQPKiXodsKgvf6WQ
Date: Thu, 27 Feb 2020 20:32:23 +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=mbishop@evequefou.be; 
x-originating-ip: [2600:2b00:9317:a001:c168:aed1:949b:628]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7fa57143-e698-45a0-c939-08d7bbc426ee
x-ms-traffictypediagnostic: CH2PR22MB2088:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03264AEA72
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(346002)(366004)(39830400003)(396003)(199004)(189003)(5660300002)(2906002)(66946007)(186003)(64756008)(66446008)(52536014)(66476007)(71200400001)(508600001)(66556008)(76116006)(316002)(6506007)(81156014)(8676002)(81166006)(8936002)(110136005)(86362001)(55016002)(7696005)(33656002)(53546011)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR22MB2088; H:CH2PR22MB2086.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Xk7xVYCBV80ip5q+yRXdHQO1mO3NLSnK4+M+Y4mXPWGRicENyMbiNNvTR+uUCQt2QLoy3sJQHqsN3kEDqsbrTpnFOJ/CsEg9Yk66WYvi+1sVGzL+putXdAvpExuT74aITGsgAaxKVK21v9HguWKPJfHOvqdbFzPUqu6pLjTxs2qq3Yf0d1d/DjWj6NCPZMvVjldzXIWlNEyMgTvJIfsGJpFFjqXHXxQFsEW8oWHEpona45MrqO2kLs8xqVBVQuS6jDry1E0vfb6TlaIOWO4U3XnMusF//g9cePIDvbZzL38Jh9agxaUId1geaebg4lT58j0EcMKrDtq8nZ0OD+U7+sReID4v/RBnzRmGFIenHu8ylIjeF7WnpVf/sHHTfyusopEfUbnbR/AH6JY33CF51c47zbkyYQkSFp97VXHGHZOORGzmoRpvJlsEtYraz1Jj
x-ms-exchange-antispam-messagedata: Vh4QCapK9IBSD1xVreULugkMkQpLTSwS3JVkHeKpHz3AjqTD4C6LLBpNLpNrpR1W5KOSljRElDGi2W/JvPNjbfi3EB0xTZF/UnRp147w8WsV+fM/+yVA0FByBKeYpSat1aXLfg7Y7Yki0BZnZPS8Pin6ACe3lQ1+9ByGZjgzo8aDYNeleMpdaaK+28jHy3gGMOw3G+YElhE2m/D0w028Ng==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR22MB2086C8D1BE1EB75A3868BDCDDAEB0CH2PR22MB2086namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fa57143-e698-45a0-c939-08d7bbc426ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 20:32:23.5440 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8emgiODAE8eLD5cYFC0/peA2oj9oaNK5Pel4BUjGO8wkTp9cUooAui4WVpMXjbgOizUpjgOAFzZ8FnKNuwQIEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR22MB2088
Archived-At: 
Subject: Re: [TLS] Clarification on Delegated Credential validation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 20:32:35 -0000

--_000_CH2PR22MB2086C8D1BE1EB75A3868BDCDDAEB0CH2PR22MB2086namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB3b3VsZCBoYXZlIGFzc3VtZWQgdGhlIHNlY29uZCBpbnRlcnByZXRhdGlvbiBhcyB0aGUgaW50
ZW50LCBidXQgeW914oCZcmUgY29ycmVjdCB0aGF0IHZhbHVlIGRvZXNu4oCZdCBleGlzdC4gIFBl
cmhhcHMgd2Ugc2hvdWxkIHNheSB0aGF0IHRoZSBjcmVkZW50aWFs4oCZcyDigJxyZW1haW5pbmfi
gJ0gdGltZSB0byBsaXZlIGlzIG5vIG1vcmUgdGhhbiB0aGUgbWF4aW11bSB2YWxpZGl0eSBwZXJp
b2Q/ICBBbmQgZml4IHRoZSBhc3NlcnRpb24sIG9mIGNvdXJzZS4NCg0KRnJvbTogVExTIDx0bHMt
Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEtldmluIEphY29icw0KU2VudDogV2VkbmVz
ZGF5LCBGZWJydWFyeSAyNiwgMjAyMCA1OjUzIFBNDQpUbzogdGxzQGlldGYub3JnDQpTdWJqZWN0
OiBbVExTXSBDbGFyaWZpY2F0aW9uIG9uIERlbGVnYXRlZCBDcmVkZW50aWFsIHZhbGlkYXRpb24N
Cg0KDQpUTFNXRywNCg0KVGhlcmUgc2VlbXMgdG8gYmUgc29tZSBhbWJpZ3VpdHkgaW4gZHJhZnQt
aWV0Zi10bHMtc3ViY2VydHMuIFs0LjEuMyBWYWxpZGF0aW5nIGEgRGVsZWdhdGVkIENyZWRlbnRp
YWxdIHN0YXRlczogIjEuIFZlcmlmeSB0aGF0IHRoZSBjdXJyZW50IHRpbWUgaXMgd2l0aGluIHRo
ZSB2YWxpZGl0eSBpbnRlcnZhbCBvZiB0aGUgY3JlZGVudGlhbCBhbmQgdGhhdCB0aGUgY3JlZGVu
dGlhbCdzIHRpbWUgdG8gbGl2ZSBpcyBubyBtb3JlIHRoYW4gdGhlIG1heGltdW0gdmFsaWRpdHkg
cGVyaW9kLiBUaGlzIGlzIGRvbmUgYnkgYXNzZXJ0aW5nIHRoYXQgdGhlIGN1cnJlbnQgdGltZSBp
cyBubyBtb3JlIHRoYW4gdGhlIGRlbGVnYXRpb24gY2VydGlmaWNhdGUncyBub3RCZWZvcmUgdmFs
dWUgcGx1cyBEZWxlZ2F0ZWRDcmVkZW50aWFsLmNyZWQudmFsaWRfdGltZS4iDQoNClRoZXJlIGFy
ZSB0d28gaXNzdWVzIHdpdGggdGhpczoNCg0KICAxLiAgVGhlIGRlc2NyaWJlZCBhc3NlcnRpb24g
b25seSBlbnN1cmVzIHRoYXQgdGhlIGZpcnN0IGNvbmRpdGlvbiBpcyBtZXQuDQogIDIuICBUaGUg
c2Vjb25kIGNvbmRpdGlvbiAtICJhbmQgdGhhdCB0aGUgY3JlZGVudGlhbCdzIHRpbWUgdG8gbGl2
ZSBpcyBubyBtb3JlIHRoYW4gdGhlIG1heGltdW0gdmFsaWRpdHkgcGVyaW9kIiAtIGlzIHVuY2xl
YXI6DQoNCiAgICAgKiAgIElmIHdlIGFzc3VtZSAidGltZSB0byBsaXZlIiBvbiBhIERDIHRvIGJl
IHRoZSByZW1haW5pbmcgdGltZSAoYmFzZWQgb24gdGhlIHZlcmlmeWluZyBwZWVyJ3MgY2xvY2sp
LCB0aGUgZGVzY3JpYmVkIGNoZWNrIHNob3VsZCBhbHNvIGFzc2VydCAiRUVDZXJ0Lm5vdEJlZm9y
ZSArIERDLnZhbGlkX3RpbWUgLSBjdXJyZW50VGltZSA8PSBtYXhpbXVtIHZhbGlkaXR5IHBlcmlv
ZCIuDQogICAgICogICBJZiB3ZSBhc3N1bWUgInRpbWUgdG8gbGl2ZSIgb24gYSBEQyB0byBiZSB0
aGUgaW5pdGlhbCBUVEwgKHNwYW5uaW5nIGlzc3VhbmNlIHRvIGV4cGlyYXRpb24pLCB3ZSBsYWNr
IHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8gZWZmZWN0aXZlbHkgdmVyaWZ5IHRoaXMsIGFzIERD
LnZhbGlkX3RpbWUgaXMgYmFzZWQgb24gRUVDZXJ0Lm5vdEJlZm9yZSByYXRoZXIgdGhhbiBEQy5u
b3RCZWZvcmUgKHdoaWNoIGRvZXMgbm90IGV4aXN0KS4gRm9yIGV4YW1wbGUsIGlmIDctZGF5IERD
cyBhcmUgaXNzdWVkLCAiRUVDZXJ0Lm5vdEJlZm9yZSArIERDLnZhbGlkX3RpbWUiIHdpbGwgYmUg
YSA3LWRheSBzcGFuIG9uIHRoZSBmaXJzdCBpc3N1YW5jZSwgYSAxNC1kYXkgc3BhbiBvbiB0aGUg
c2Vjb25kLCBldGMuIHVudGlsIHRoZSBFRSBjZXJ0IGlzIHJlaXNzdWVkLg0KDQpJIGJlbGlldmUg
dGhlIGZpcnN0IGludGVycHJldGF0aW9uIGlzIGludGVuZGVkLCBidXQgdGhlIGNsaWVudCBpcyB0
aGVuIHVuYWJsZSB0byB2ZXJpZnkgdGhhdCB0aGUgREMgbGlmZXNwYW4gaXMgYWN0dWFsbHkgbGVz
cyB0aGFuIHRoZSBtYXhpbXVtIHZhbGlkaXR5IHBlcmlvZCAoc2hvdWxkIHN1Y2ggYSBjaGVjayBi
ZSBkZXNpcmVkKSwgb25seSB0aGF0IHRoZSBEQyB3aWxsIGV4cGlyZSB3aXRoaW4gdGhhdCBwZXJp
b2QuIEVpdGhlciB3YXksIHRoZSBleHBlY3RlZCBiZWhhdmlvciBzaG91bGQgYmUgY2xhcmlmaWVk
Lg0KDQpUaGFua3MsDQpLZXZpbg0K

--_000_CH2PR22MB2086C8D1BE1EB75A3868BDCDDAEB0CH2PR22MB2086namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3
Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy
ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN
Cgl7bXNvLWxpc3QtaWQ6MTQ1MDc4Mzk0MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzQyNDc2
ODY7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj
OTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5JIHdvdWxkIGhhdmUgYXNzdW1lZCB0aGUgc2Vjb25kIGludGVycHJldGF0aW9uIGFzIHRoZSBp
bnRlbnQsIGJ1dCB5b3XigJlyZSBjb3JyZWN0IHRoYXQgdmFsdWUgZG9lc27igJl0IGV4aXN0LiZu
YnNwOyBQZXJoYXBzIHdlIHNob3VsZCBzYXkgdGhhdCB0aGUgY3JlZGVudGlhbOKAmXMg4oCccmVt
YWluaW5n4oCdIHRpbWUgdG8gbGl2ZSBpcyBubyBtb3JlIHRoYW4gdGhlIG1heGltdW0gdmFsaWRp
dHkgcGVyaW9kPyZuYnNwOyBBbmQgZml4IHRoZSBhc3NlcnRpb24sDQogb2YgY291cnNlLjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVExTICZsdDt0bHMtYm91bmNlc0BpZXRm
Lm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCktldmluIEphY29iczxicj4NCjxiPlNlbnQ6
PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDIwIDU6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+
IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVExTXSBDbGFyaWZpY2F0aW9uIG9u
IERlbGVnYXRlZCBDcmVkZW50aWFsIHZhbGlkYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDozLjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206My4w
cHQ7bWFyZ2luLWxlZnQ6MGluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VExTV0csIDxicj48YnI+VGhlcmUgc2VlbXMg
dG8gYmUgc29tZSBhbWJpZ3VpdHkgaW4gZHJhZnQtaWV0Zi10bHMtc3ViY2VydHMuIFs0LjEuMyBW
YWxpZGF0aW5nIGEgRGVsZWdhdGVkIENyZWRlbnRpYWxdIHN0YXRlczogJnF1b3Q7MS4gVmVyaWZ5
IHRoYXQgdGhlIGN1cnJlbnQgdGltZSBpcyB3aXRoaW4gdGhlIHZhbGlkaXR5IGludGVydmFsIG9m
IHRoZSBjcmVkZW50aWFsIGFuZCB0aGF0IHRoZSBjcmVkZW50aWFsJ3MgdGltZSB0byBsaXZlIGlz
IG5vIG1vcmUgdGhhbiB0aGUgbWF4aW11bSB2YWxpZGl0eSBwZXJpb2QuIFRoaXMgaXMgZG9uZSBi
eSBhc3NlcnRpbmcgdGhhdCB0aGUgY3VycmVudCB0aW1lIGlzIG5vIG1vcmUgdGhhbiB0aGUgZGVs
ZWdhdGlvbiBjZXJ0aWZpY2F0ZSdzIG5vdEJlZm9yZSB2YWx1ZSBwbHVzIERlbGVnYXRlZENyZWRl
bnRpYWwuY3JlZC52YWxpZF90aW1lLiZxdW90Ozxicj48YnI+VGhlcmUgYXJlIHR3byBpc3N1ZXMg
d2l0aCB0aGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIx
Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIGRlc2NyaWJlZCBhc3NlcnRpb24gb25seSBlbnN1
cmVzIHRoYXQgdGhlIGZpcnN0IGNvbmRpdGlvbiBpcyBtZXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9s
aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBzZWNvbmQgY29uZGl0aW9uIC0gJnF1b3Q7YW5kIHRo
YXQgdGhlIGNyZWRlbnRpYWwncyB0aW1lIHRvIGxpdmUgaXMgbm8gbW9yZSB0aGFuIHRoZSBtYXhp
bXVtIHZhbGlkaXR5IHBlcmlvZCZxdW90OyAtIGlzIHVuY2xlYXI6PC9zcGFuPjxvOnA+PC9vOnA+
PC9saT48L29sPg0KPG9sIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxvbCBzdGFydD0iMSIgdHlwZT0i
MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPklmIHdlIGFzc3VtZSAmcXVvdDt0aW1lIHRvIGxpdmUm
cXVvdDsgb24gYSBEQyB0byBiZSB0aGUgcmVtYWluaW5nIHRpbWUgKGJhc2VkIG9uIHRoZSB2ZXJp
ZnlpbmcgcGVlcidzIGNsb2NrKSwgdGhlIGRlc2NyaWJlZCBjaGVjayBzaG91bGQgYWxzbyBhc3Nl
cnQgJnF1b3Q7RUVDZXJ0Lm5vdEJlZm9yZSAmIzQzOyBEQy52YWxpZF90aW1lIC0gY3VycmVudFRp
bWUNCiAmbHQ7PSBtYXhpbXVtIHZhbGlkaXR5IHBlcmlvZCZxdW90Oy48L3NwYW4+PG86cD48L286
cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWYgd2UgYXNzdW1lICZxdW90O3RpbWUgdG8gbGl2
ZSZxdW90OyBvbiBhIERDIHRvIGJlIHRoZSBpbml0aWFsIFRUTCAoc3Bhbm5pbmcgaXNzdWFuY2Ug
dG8gZXhwaXJhdGlvbiksIHdlIGxhY2sgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0byBlZmZlY3Rp
dmVseSB2ZXJpZnkgdGhpcywgYXMgREMudmFsaWRfdGltZSBpcyBiYXNlZCBvbiBFRUNlcnQubm90
QmVmb3JlDQogcmF0aGVyIHRoYW4gREMubm90QmVmb3JlICh3aGljaCBkb2VzIG5vdCBleGlzdCku
IEZvciBleGFtcGxlLCBpZiA3LWRheSBEQ3MgYXJlIGlzc3VlZCwgJnF1b3Q7RUVDZXJ0Lm5vdEJl
Zm9yZSAmIzQzOyBEQy52YWxpZF90aW1lJnF1b3Q7IHdpbGwgYmUgYSA3LWRheSBzcGFuIG9uIHRo
ZSBmaXJzdCBpc3N1YW5jZSwgYSAxNC1kYXkgc3BhbiBvbiB0aGUgc2Vjb25kLCBldGMuIHVudGls
IHRoZSBFRSBjZXJ0IGlzIHJlaXNzdWVkLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L29sPg0K
PC9vbD4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDozLjBwdDttYXJnaW4tcmlnaHQ6
MGluO21hcmdpbi1ib3R0b206My4wcHQ7bWFyZ2luLWxlZnQ6MGluO2JveC1zaXppbmc6aW5oZXJp
dDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ym9yZGVy
LXJhZGl1czo0cHg7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtZGVjb3JhdGlvbi1zdHls
ZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO3dvcmQtc3BhY2luZzowcHgi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOmJsYWNrIj5JIGJlbGlldmUgdGhlIGZpcnN0IGludGVycHJldGF0aW9uIGlzIGludGVuZGVk
LCBidXQgdGhlIGNsaWVudCBpcyB0aGVuIHVuYWJsZSB0byB2ZXJpZnkgdGhhdCB0aGUgREMgbGlm
ZXNwYW4gaXMgYWN0dWFsbHkgbGVzcyB0aGFuIHRoZSBtYXhpbXVtIHZhbGlkaXR5IHBlcmlvZCAo
c2hvdWxkIHN1Y2ggYSBjaGVjayBiZSBkZXNpcmVkKSwgb25seSB0aGF0IHRoZSBEQyB3aWxsIGV4
cGlyZSB3aXRoaW4gdGhhdCBwZXJpb2QuIEVpdGhlciB3YXksIHRoZSBleHBlY3RlZCBiZWhhdmlv
ciBzaG91bGQgYmUgY2xhcmlmaWVkLiA8YnI+PGJyPlRoYW5rcyw8YnI+S2V2aW48L3NwYW4+PG86
cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_CH2PR22MB2086C8D1BE1EB75A3868BDCDDAEB0CH2PR22MB2086namp_--


From nobody Thu Feb 27 13:32:02 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAB53A0C66 for ; Thu, 27 Feb 2020 13:32:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Level: 
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 F6gu2N1a7PfR for ; Thu, 27 Feb 2020 13:31:58 -0800 (PST)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB303A0C65 for ; Thu, 27 Feb 2020 13:31:58 -0800 (PST)
Received: by mail-pj1-x102b.google.com with SMTP id ep11so339672pjb.2 for ; Thu, 27 Feb 2020 13:31:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qr/1YhmW7bQxjCFVxVRxQEij6Mqx7KoFKWnKOoUe2xA=; b=XlExyikEhSjqPlfn4BvOgrXpUdPKiGDRFA4Q3c8YOFJDzGesVIC/KsILdT0/Af0Wm4 XPnGIJNt0Q/pHl13jX0WiEYF0XboASk9ZSR1KPOpJd3lUvUkXRvnYwkblycTszxo5/+P KEOfyNSAXh2L9clh6FFIzGUlEt778kYKwfhx0=
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=Qr/1YhmW7bQxjCFVxVRxQEij6Mqx7KoFKWnKOoUe2xA=; b=FPi5PJbPGSLAGZPi9tlO8EQBo7xvo5a/SriJpgCLso3r+/02dy8dgAekSgqM/1xFqM NgEACKBy76tE9koPDGLtEjt0a7krb7kNbhdhyp6a7wddlc9De36H6wVcueM7nlsg4ol6 cGl+8mGIKtukzYgBbIK2qgYXoITpQltoCItOZ2EsKrycaff/7rrYWCFrxiBzAvWWeoeq Sbj2xAvp/YmT093aCTf+omBxVw3UN2Qy94yGmBsXHgP5NbS76LycuVsRm0YRrwF2+jyS jP1YSfgHFtJvLKZNT96Qzrx/uA7cLqWz3eoK83IpGJi5aTlCJ6oP2ZQ2JdAceofe19ti +w9A==
X-Gm-Message-State: APjAAAU/quHQo7Ptqmvh2TcZCjNIpWthgakG2BDRe1Phi5WwejzWmeig d0rEpv22ld2va4hA0aooOepbxmrao5aMXmxCgpPdnbY=
X-Google-Smtp-Source: APXvYqylU2q0XGofqrR2eUPYYHV6pG0bMsWwCCMxyantqBMKHEY8Vybj19Tl/9pcCeFrodP8s4Sw73NT3vKKriyMpVY=
X-Received: by 2002:a17:90a:e2ce:: with SMTP id fr14mr938923pjb.99.1582839117087;  Thu, 27 Feb 2020 13:31:57 -0800 (PST)
MIME-Version: 1.0
References:     <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>   
In-Reply-To: 
From: David Benjamin 
Date: Thu, 27 Feb 2020 16:31:40 -0500
Message-ID: 
To: Jonathan Hoyland 
Cc: Christopher Wood , "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000004ff80a059f957315"
Archived-At: 
Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for 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 Feb 2020 21:32:00 -0000

--0000000000004ff80a059f957315
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland 
wrote:

> This would be for cases where we want to inject extra context into a
> resumption.
> That would be anything that changes an authentication property, so
> for example if you wanted to include some agreement on the status of a
> post-handshake auth or Exported Authenticator.
>
> So for example imagine I had a session during which I received an EA and
> when I came to resume that session I wished to indicate that I was still
> willing to accept the EA.
> I would offer a special PSK and inject some extra material into the
> handshake*, and if the server was able / willing to agree to this it would
> select the PSK.
> I could also offer a PSK with no extra injected material, as a fallback,
> and request the EA again.
>
> * This would only affect the binder for the PSK in the ClientHello.
>

I'm still not following. If you're resuming, this is a PSK issued from a
NewSessionTicket, in which case this isn't an imported PSK at all. It's a
resumption PSK and uses "res binder". If we needed to negotiate variations
on a resumption, this importer mechanism wouldn't give us a way to express
that anyway. I expect we'd instead lean on some combination of multiple
tickets, NewSessionTicket extensions, and plain ClientHello extensions. But
maybe I'm still not understanding the scenario.


> Another potential use would be the binding for ECHO, although I don't have
> a clear enough picture of the precise mechanics of that to know if it would
> be helpful.
>

Chris is probably more up-to-date here, but I don't believe the current
ECHO design looks like a funny PSK.


> Something that would allow for a consistent naming in the future would be
> my preference, because just as "imp binder" doesn't preclude "imp r
> binder", using "imp e binder" doesn't preclude us never adopting "imp r
> binder".
> I vaguely remember discussing whether the longer name would tip us into an
> extra hash invocation at the last IETF,  and concluding that it didn't,
> although I'd have to double check that.
>

Of course. Yeah, I think the more pertinent question is whether "imp r
binder" is actually a thing.


> Regards,
>
> Jonathan
>
> On Mon, 24 Feb 2020, 22:23 David Benjamin,  wrote:
>
>> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <
>> jonathan.hoyland@gmail.com> wrote:
>>
>>> Just looking at this again, it might be better to make a slightly
>>> different tweak to the key schedule.
>>> Instead of:
>>>
>>>                 0
>>>                 |
>>>                 v
>>>       PSK ->  HKDF-Extract = Early Secret
>>>                 |
>>>                 +-----> Derive-Secret(., "ext binder"
>>>                 |                      | "res binder"
>>>                 |                      | "imp binder", "")
>>>                 |                     = binder_key
>>>
>>>                 v
>>>
>>>
>>>
>>> We should do:
>>>
>>>                 0
>>>                 |
>>>                 v
>>>       PSK ->  HKDF-Extract = Early Secret
>>>                 |
>>>                 +-----> Derive-Secret(., "ext binder"
>>>                 |                      | "res binder"
>>>                 |                      | "imp e binder"
>>>
>>>                 |                      | "imp r binder", "")
>>>                 |                     = binder_key
>>>
>>>                 v
>>>
>>>
>>> or at least:
>>>
>>>                 0
>>>                 |
>>>                 v
>>>       PSK ->  HKDF-Extract = Early Secret
>>>                 |
>>>                 +-----> Derive-Secret(., "ext binder"
>>>                 |                      | "res binder"
>>>                 |                      | "imp e binder", "")
>>>                 |                     = binder_key
>>>
>>>                 v
>>>
>>>
>>>
>>>
>>> Just so that we can distinguish between external imported binders and
>>> resumed imported binders, should we at some point decide to do both.
>>>
>>
>> I may just be confused, but what would a resumed imported binder mean? I
>> see this mechanism as largely a bugfix for TLS 1.3 external PSKs, rather
>> than a new kind of adjective describing PSKs.
>>
>> ("imp binder" also doesn't preclude "imp r binder" later if we later
>> define something which needs it, but I'm confused what the concept even
>> would be.)
>>
>> David
>>
>>
>>> On Mon, 24 Feb 2020 at 20:50, Christopher Wood 
>>> wrote:
>>>
>>>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
>>>> >
>>>> >
>>>> > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla  wrote:
>>>> > >
>>>> > >
>>>> > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre  wrote:
>>>> > >> Hi,
>>>> > >>
>>>> > >> I'm not sure how violations of these requirements would result in
>>>> poor interoperability:
>>>> > >>
>>>> > >>  Clients which import external keys TLS MUST NOT use these keys for
>>>> > >>  any other purpose. Moreover, each external PSK MUST be associated
>>>> > >>  with at most one hash function.
>>>> > >>
>>>> > >> These seem like aspirational security goals. It would be better to
>>>> describe the consequences of violating these conditions.
>>>> > >
>>>> > > I don't agree. They are requirements in order to be able to make
>>>> the assertions we want to make about the security of the protocol.
>>>> > >
>>>> > > This is consistent with the following text of RFC 2119 S 6
>>>> > > ".. or to limit behavior which has potential for causing harm
>>>> (e.g., limiting retransmisssions) "
>>>> > >
>>>> > > I don't think it would be unreasonable.to explain the reason for
>>>> these, though this is already a requirement of 8446 S 4.2.11 (though
>>>> without justification).
>>>> >
>>>> > I think that interpretation of 2119 is a stretch, but your idea to
>>>> add
>>>> > an explanation while keeping the 2119 terms addresses my concern. At
>>>> > the very least, the draft should note this is already a requirement
>>>> of
>>>> > 8446.
>>>>
>>>> That seems perfectly reasonable! We can point to the security
>>>> considerations to clarify the "single hash function" requirement, and we
>>>> can note cross protocol attack deterrence for the other claim. Would that
>>>> suffice? If not, can you please recommend text?
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>

--0000000000004ff80a059f957315
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Mon, Feb 24, 2020 at 5:58 PM Jonathan =
Hoyland <jonathan.hoyland@gmail.com> wrote:
This would be for cases where=C2=A0we want to inject extra co=
ntext into a resumption.=C2=A0
That would be anything that change=
s an authentication property, so for=C2=A0example if you wanted to include =
some agreement on the status of a post-handshake auth or Exported Authentic=
ator.

So for example imagine I had a session durin=
g which I received an EA and when I came to resume that session I wished to=
 indicate that I was still willing to accept the EA.
I would offe=
r a special PSK and inject some extra material into the handshake*, and if =
the server was able / willing to agree to this it would select the PSK.=C2=
=A0
I could also offer a PSK with no extra injected material, as =
a fallback, and request the EA again.=C2=A0

* This=
 would only affect the binder for the PSK in the ClientHello.=C2=A0

I'm still not following. If you=
9;re resuming, this is a PSK issued from a NewSessionTicket, in which case =
this isn't an imported PSK at all. It's a resumption PSK and uses &=
quot;res binder". If we needed to negotiate=C2=A0variations on a resum=
ption, this importer mechanism wouldn't give us a way to express that a=
nyway. I expect we'd instead lean on some combination of multiple ticke=
ts, NewSessionTicket extensions, and plain ClientHello extensions. But mayb=
e I'm still not understanding the scenario.
=C2=A0
Another =
potential use would be the binding=C2=A0for ECHO, although I don't have=
 a clear enough picture of the precise mechanics of that to know if it woul=
d be helpful.

Chris is probably=
 more up-to-date here, but I don't believe the current ECHO design look=
s like a funny PSK.
=C2=A0
Something that would allow for a con=
sistent naming in the future would be my preference, because just as "=
imp binder" doesn't preclude "imp r binder", using "=
;imp e binder" doesn't preclude us never adopting "imp r bind=
er".
I vaguely remember discussing whether the longer name w=
ould tip us into an extra hash invocation at the last IETF,=C2=A0 and concl=
uding that it didn't, although I'd have to double check that.=C2=A0=


Of course. Yeah, I think the m=
ore pertinent question is whether "imp r binder" is actually a th=
ing.
=C2=A0
Regards,

Jonathan=C2=A0

On Mon, 24 Feb 2020, 22:23 David Benjamin, <davidben@chromium.org> wrote:
<=
/div>
On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <jonathan.hoyland@gmail.com> wrote:
Just=
 looking at this again, it might be better to make a slightly different twe=
ak to the key schedule.
Instead of:
                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp binder", "&quo=
t;)
                |                     =3D binder_key
                v


We should do:

<=
pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef=
ore:page;color:rgb(0,0,0)">                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder"                |                      | "imp =
r binder", "")
                |                     =3D binder_key
                v

or =
at least:
                0
                |
                v
      PSK ->  HKDF-Extract =3D Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder", "&q=
uot;)
                |                     =3D binder_key
                v


<=
br>
Just so that we can distinguish between external imported binders =
and resumed imported binders, should we at some point decide to do both.=C2=
=A0

I may just be confused, but=
 what would a resumed imported binder mean? I see this mechanism as largely=
 a bugfix for TLS 1.3 external=C2=A0PSKs, rather than a new kind of adjecti=
ve describing PSKs.

("imp binder" also d=
oesn't preclude "imp r binder" later if we later define somet=
hing which needs it, but I'm confused what the concept even would be.)<=
br>

David
=C2=A0
On Mon, 24 Feb 2020 at 20:50, Christopher Wood <<=
a href=3D"mailto:caw@heapingbits.net" rel=3D"noreferrer" target=3D"_blank">=
caw@heapingbits.net> wrote:
On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:

> 

> 

> On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla <ekr@rtfm.com> wrote=
:

> > 

> > 

> > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <sayrer@gmail.com&=
gt; wrote:

> >> Hi,

> >> 

> >> I'm not sure how violations of these requirements would r=
esult in poor interoperability:

> >> 

> >>=C2=A0 Clients which import external keys TLS MUST NOT use the=
se keys for

> >>=C2=A0 any other purpose. Moreover, each external PSK MUST be =
associated

> >>=C2=A0 with at most one hash function.

> >> 

> >> These seem like aspirational security goals. It would be bett=
er to describe the consequences of violating these conditions.

> > 

> > I don't agree. They are requirements in order to be able to m=
ake the assertions we want to make about the security of the protocol.

> > 

> > This is consistent with the following text of RFC 2119 S 6

> > ".. or to limit behavior which has potential for causing har=
m (e.g., limiting retransmisssions) "

> > 

> > I don't think it would be unreasonable.to explain=
 the reason for these, though this is already a requirement of 8446 S 4.2.1=
1 (though without justification).

> 

> I think that interpretation of 2119 is a stretch, but your idea to add=
 

> an explanation while keeping the 2119 terms addresses my concern. At <=
br>
> the very least, the draft should note this is already a requirement of=
 

> 8446.



That seems perfectly reasonable! We can point to the security consideration=
s to clarify the "single hash function" requirement, and we can n=
ote cross protocol attack deterrence for the other claim. Would that suffic=
e? If not, can you please recommend text?



Thanks,

Chris



_______________________________________________

TLS mailing list

TLS@ie=
tf.org

https://www.ietf.org/mailman/listinfo/tls


_______________________________________________

TLS mailing list

TLS@ie=
tf.org

https://www.ietf.org/mailman/listinfo/tls







--0000000000004ff80a059f957315--


From nobody Thu Feb 27 20:49:52 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2993A0F5C for ; Thu, 27 Feb 2020 20:49:50 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=heapingbits.net header.b=E3H0hrGD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=onsALUde
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCdJi_dtoiNI for ; Thu, 27 Feb 2020 20:49:48 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFEC3A0F32 for ; Thu, 27 Feb 2020 20:49:48 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id ADE7D21F57; Thu, 27 Feb 2020 23:49:46 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Thu, 27 Feb 2020 23:49:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=xBASIH5kSFjddj2DnpXBdbVv7TF0 nxXO0kAdA4knIzo=; b=E3H0hrGDAt6CJtCOsU3api2j588iwuIaz/GckhxLb8u9 MyKTfH6myvhw9KBK+Ql5h8y0qf3F/FIrXXZnmktaR3DLinMziR2pJYgu/MTIG7Nl mJhRfuLO8GM+gcNkyLU/K9Rr1HZWe6/5J7GRJz+1lt5brhDqjWsvjs1jHbdX55Tf 8cTA+LIe8wBvY9+Z2MTyDGBYs39nbL9WZ9ruH5fRG8plgEekx7cfz5Nrx9U/GOds EcuEXzs7OBLq4Dui4Q2Nu5+fCUj9f/6ZoLvQumbLvnqpRDGPNCLNA010dwkXVBut 5aUh7xh7sW9ouIBAJXUWxLR3bRa1Ltat+TtpAocokQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xBASIH 5kSFjddj2DnpXBdbVv7TF0nxXO0kAdA4knIzo=; b=onsALUdedi4XeHhgQoKrfQ IqF9o2gJnTK9CzPHl0sIexn7zJJrWyO0cc9Bfy9YxehU1nmRF3AjrKVQqZDAf4xb /ftublcXQxgFErUStABf6E8SgkxQibTI+72X/LtlXQwSNpbfTxqkeo9s9NMDadCv zDpIAjUHS3CsF6fnTi+E0cPtiu4E4q3tKGqAIq0Ps4JlWIJUdTNLAbm4MPW/Hn0E VwTTZZ52JsqDhTuUmat7hdI8byAg5Gp4qyVVoONQ+o7/n6xTAgLaxzQ9+GowFjUY xHMm5JeVgS9CSgv3etYKtgOpiZ18DTeLymGdUalO3Vs/SgEFOtrY36RHwiSV90bw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrleejgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1E88A3C00A1; Thu, 27 Feb 2020 23:49:46 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-967-g014f925-fmstable-20200226v1
Mime-Version: 1.0
Message-Id: <75b70352-9cc5-4aa1-9cca-42f37fe615d2@www.fastmail.com>
In-Reply-To: 
References:     <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>    
Date: Thu, 27 Feb 2020 20:49:23 -0800
From: "Christopher Wood" 
To: "David Benjamin" , "Jonathan Hoyland" 
Cc: "TLS@ietf.org" 
Content-Type: text/plain
Archived-At: 
Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 04:49:50 -0000

On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
> On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland 
>  wrote:
> > This would be for cases where we want to inject extra context into a resumption. 
> > That would be anything that changes an authentication property, so for example if you wanted to include some agreement on the status of a post-handshake auth or Exported Authenticator.
> > 
> > So for example imagine I had a session during which I received an EA and when I came to resume that session I wished to indicate that I was still willing to accept the EA.
> > I would offer a special PSK and inject some extra material into the handshake*, and if the server was able / willing to agree to this it would select the PSK. 
> > I could also offer a PSK with no extra injected material, as a fallback, and request the EA again. 
> > 
> > * This would only affect the binder for the PSK in the ClientHello. 
> 
> I'm still not following. If you're resuming, this is a PSK issued from 
> a NewSessionTicket, in which case this isn't an imported PSK at all. 
> It's a resumption PSK and uses "res binder". If we needed to negotiate 
> variations on a resumption, this importer mechanism wouldn't give us a 
> way to express that anyway. I expect we'd instead lean on some 
> combination of multiple tickets, NewSessionTicket extensions, and plain 
> ClientHello extensions. But maybe I'm still not understanding the 
> scenario.
> > Another potential use would be the binding for ECHO, although I don't have a clear enough picture of the precise mechanics of that to know if it would be helpful.
> 
> Chris is probably more up-to-date here, but I don't believe the current 
> ECHO design looks like a funny PSK.

That's right -- it's just another extension in the outer CH. 

Best,
Chriss

> > Something that would allow for a consistent naming in the future would be my preference, because just as "imp binder" doesn't preclude "imp r binder", using "imp e binder" doesn't preclude us never adopting "imp r binder".
> > I vaguely remember discussing whether the longer name would tip us into an extra hash invocation at the last IETF, and concluding that it didn't, although I'd have to double check that. 
> 
> Of course. Yeah, I think the more pertinent question is whether "imp r 
> binder" is actually a thing.
> > Regards,
> > 
> > Jonathan 
> > 
> > On Mon, 24 Feb 2020, 22:23 David Benjamin,  wrote:
> >> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland  wrote:
> >>> Just looking at this again, it might be better to make a slightly different tweak to the key schedule.
> >>> Instead of:
> >>>                 0
>                 |
>                 v
>       PSK ->  HKDF-Extract = Early Secret
>                 |
>                 +-----> Derive-Secret(., "ext binder"
>                 |                      | "res binder"
>                 |                      | "imp binder", "")
>                 |                     = binder_key                v
> >>> 
> >>> We should do:
> >>> 
> >>>                 0
>                 |
>                 v
>       PSK ->  HKDF-Extract = Early Secret
>                 |
>                 +-----> Derive-Secret(., "ext binder"
>                 |                      | "res binder"
>                 |                      | "imp e binder"                
> |                      | "imp r binder", "")
>                 |                     = binder_key                v
> >>> or at least:
> >>>                 0
>                 |
>                 v
>       PSK ->  HKDF-Extract = Early Secret
>                 |
>                 +-----> Derive-Secret(., "ext binder"
>                 |                      | "res binder"
>                 |                      | "imp e binder", "")
>                 |                     = binder_key                v
> >>> 
> >>> 
> >>> Just so that we can distinguish between external imported binders and resumed imported binders, should we at some point decide to do both. 
> >> 
> >> I may just be confused, but what would a resumed imported binder mean? I see this mechanism as largely a bugfix for TLS 1.3 external PSKs, rather than a new kind of adjective describing PSKs.
> >> 
> >> ("imp binder" also doesn't preclude "imp r binder" later if we later define something which needs it, but I'm confused what the concept even would be.)
> >> 
> >> David
> >>> On Mon, 24 Feb 2020 at 20:50, Christopher Wood  wrote:
> >>>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
> >>>>  > 
> >>>>  > 
> >>>>  > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla  wrote:
> >>>>  > > 
> >>>>  > > 
> >>>>  > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre  wrote:
> >>>>  > >> Hi,
> >>>>  > >> 
> >>>>  > >> I'm not sure how violations of these requirements would result in poor interoperability:
> >>>>  > >> 
> >>>>  > >> Clients which import external keys TLS MUST NOT use these keys for
> >>>>  > >> any other purpose. Moreover, each external PSK MUST be associated
> >>>>  > >> with at most one hash function.
> >>>>  > >> 
> >>>>  > >> These seem like aspirational security goals. It would be better to describe the consequences of violating these conditions.
> >>>>  > > 
> >>>>  > > I don't agree. They are requirements in order to be able to make the assertions we want to make about the security of the protocol.
> >>>>  > > 
> >>>>  > > This is consistent with the following text of RFC 2119 S 6
> >>>>  > > ".. or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) "
> >>>>  > > 
> >>>>  > > I don't think it would be unreasonable.to explain the reason for these, though this is already a requirement of 8446 S 4.2.11 (though without justification).
> >>>>  > 
> >>>>  > I think that interpretation of 2119 is a stretch, but your idea to add 
> >>>>  > an explanation while keeping the 2119 terms addresses my concern. At 
> >>>>  > the very least, the draft should note this is already a requirement of 
> >>>>  > 8446.
> >>>> 
> >>>>  That seems perfectly reasonable! We can point to the security considerations to clarify the "single hash function" requirement, and we can note cross protocol attack deterrence for the other claim. Would that suffice? If not, can you please recommend text?
> >>>> 
> >>>>  Thanks,
> >>>>  Chris
> >>>> 
> >>>>  _______________________________________________
> >>>>  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 Fri Feb 28 03:50:32 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64B63A1692 for ; Fri, 28 Feb 2020 03:50:29 -0800 (PST)
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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=ekMrwBqo; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=ekMrwBqo
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAKZlIGV9AMD for ; Fri, 28 Feb 2020 03:50:27 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70044.outbound.protection.outlook.com [40.107.7.44]) (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 C01643A168F for ; Fri, 28 Feb 2020 03:50:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nB/sMnIDmlP0B94QI+fsYX1qtlgf98mvs4urYuAushg=; b=ekMrwBqoWlJ/bO7MyN6UoBCbXMSaQ00NbGpqZbILNd+fuMeCxvWvFRjJUFhAQRUSuJNjnWI3veE1Yl10JVC0OKAgJpBqkZahTn/l+Gzpm7gtznYdKCKx4gbDfZVWjJRW3Z8XjQ2Dhtt6WDEWAwD2JDZvucYMzRHECATitDHGOPs=
Received: from VI1PR0801CA0080.eurprd08.prod.outlook.com (2603:10a6:800:7d::24) by AM7PR08MB5350.eurprd08.prod.outlook.com (2603:10a6:20b:101::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Fri, 28 Feb 2020 11:50:23 +0000
Received: from VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::206) by VI1PR0801CA0080.outlook.office365.com (2603:10a6:800:7d::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Fri, 28 Feb 2020 11:50:23 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT032.mail.protection.outlook.com (10.152.18.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Fri, 28 Feb 2020 11:50:23 +0000
Received: ("Tessian outbound 1f9bda537fdc:v42"); Fri, 28 Feb 2020 11:50:23 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 2902b3e5e1af02cb
X-CR-MTA-TID: 64aa7808
Received: from 69ee9bda03f1.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 764FE611-45E3-4AB3-B315-DE89D4C2B714.1;  Fri, 28 Feb 2020 11:50:17 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 69ee9bda03f1.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 28 Feb 2020 11:50:17 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=judhal980Up4j3wfIsti2taFSR6y8sd9KVt7icVQCaPTjyJp2EP+WchJ6xT8jo0Ai2FOKGbl9VVQjHIBds1eh3/ivhvyrSTu6Bl79Eoz0SoQDqk+kbfm6a87DIfjf57coxOBnTKn5RU7b7U1WvoB5VM4TXGmwtLTWh2hPzflKLF//d4f/I7zfKvftO48OMZRwkb7iYQNEXh12U3uZUWmbYjZ3bfJ0VBNPsOVkAXK3bnUIY6bHNTCrARbwWfPq0khZ655ueX2hmkZ5mYUEg3KV+YkJgmND6TVAcBLTODcsZAVgh7lLnXZjF4Afh+K02xtedmaBkJH3M1BXHmtRO2cug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nB/sMnIDmlP0B94QI+fsYX1qtlgf98mvs4urYuAushg=; b=gRqGcqqWhG839H/fWeHo8UBZmRn94iahzUEF5YHVoIZvjq3aFWW702rd2UgAjBbPXcwK9HdlUX1WohV4ChxAZkesL3cvyXxHoLeID2dl0E2hvxLuvuqjpNrd2AX0TN/MLi3i163g3nuTbLWwLnkSqOdjaVQexDFm9CN/eCGrg9oF6ia90RC518QxP13fGlO6Md2Jv8sw3ZchxkkVcgmHz6UTKwhAMvtXxi/28FLEzr94rf7cPytGvjGbHGyBRltj2CQoVPDK0OZfJWHPbZJT0YB98yWxaZxske2mhE/Oswx6pCAstBDmfGiLwotETkcb6DgHlHl8R0pMB/sPURJ9iw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nB/sMnIDmlP0B94QI+fsYX1qtlgf98mvs4urYuAushg=; b=ekMrwBqoWlJ/bO7MyN6UoBCbXMSaQ00NbGpqZbILNd+fuMeCxvWvFRjJUFhAQRUSuJNjnWI3veE1Yl10JVC0OKAgJpBqkZahTn/l+Gzpm7gtznYdKCKx4gbDfZVWjJRW3Z8XjQ2Dhtt6WDEWAwD2JDZvucYMzRHECATitDHGOPs=
Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB4005.eurprd08.prod.outlook.com (20.179.0.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Fri, 28 Feb 2020 11:50:16 +0000
Received: from AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::cc7b:fca1:7ea2:9c61]) by AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::cc7b:fca1:7ea2:9c61%6]) with mapi id 15.20.2750.021; Fri, 28 Feb 2020 11:50:16 +0000
From: Hanno Becker 
To: "tls@ietf.org" 
Thread-Topic: Record-level ACKs in DTLS 1.3
Thread-Index: AQHV7ix8mXje6TWNu0+lhHSpDYxOZA==
Date: Fri, 28 Feb 2020 11:50:16 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; 
x-originating-ip: [217.140.106.52]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: d27e4664-93f1-4e51-1645-08d7bc44650b
X-MS-TrafficTypeDiagnostic: AM6PR08MB4005:|AM7PR08MB5350:
X-Microsoft-Antispam-PRVS: 
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0327618309
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(39860400002)(376002)(366004)(189003)(199004)(81156014)(19627405001)(81166006)(8676002)(52536014)(478600001)(316002)(5660300002)(33656002)(9686003)(2906002)(55016002)(71200400001)(8936002)(86362001)(186003)(6506007)(7696005)(6916009)(64756008)(66556008)(66476007)(66946007)(66446008)(26005)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4005; H:AM6PR08MB3318.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: tKJKc+rGFfbLptgdSVQnc3ET7P68qCHu9qwoXvGWm3hRGRudA57dhNE4WtYi30hY3gC3yBnu2RcvWd+AnBzShEa8t8Db3EUEzmGZn0FFzDroHgTUUKTU1dNTMdzLz7+fE7Lz5tFXEXFgAbL3y50TBNEZI8UfYPngyCFwoZmv+1bBBt6qDYQ8BCCIWSzMyDynWw4o88B7UDPs9OlN0vcLW4NYBo5/dOw91m4OikG9zBb/L6yDJZEVhxX6iw4/xWsNzdQJpJLf1oEq8BYn8j/pjYyT0fg+BUPw5AVbgS5JawijPQfVaY4sF92Q4lyl3a96DohxAsQ+s9OkacaIaDTCivgBJsoLwvqasIUGjCk80SeHQBL6JGZrXmbsTZNLegg9wU0Sigz1eOAZeno8q3ixNapGpy1q2Jyb3r6od2sRFp0fsVMdv5BQR/SLtNqrlCkF
x-ms-exchange-antispam-messagedata: nmyQQPmaVtiTTNE9rkQgncC6v4zete6SM6E1xPqQyUgeyoQwKKO6/7DjbGx9uJxXjgLbUS5+qH2bD3sJmdXz6XAUEL/29yDLU/X5w/+ZIRDdnm5ASZqXmyx30/3AgfbstOmfIXgyF/ebnBbxTfxVjw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318E5A347314EB509AC91759BE80AM6PR08MB3318eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4005
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(136003)(39860400002)(376002)(199004)(189003)(336012)(2906002)(81166006)(186003)(70586007)(30864003)(33656002)(6916009)(81156014)(8936002)(26005)(70206006)(8676002)(478600001)(55016002)(36906005)(316002)(356004)(7696005)(5660300002)(52536014)(26826003)(6506007)(86362001)(19627405001)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7PR08MB5350; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; 
X-MS-Office365-Filtering-Correlation-Id-Prvs: 3ac10e97-daad-429b-a6c1-08d7bc4460d2
X-Forefront-PRVS: 0327618309
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Rg1ISlH4Ei3x3uT36EkORg2men+BvV5j7dBFZ5NMM/Wra0W6BGN9cV7JtGGJpk3Wi5wgqeX6TjL3+2+aTAgtNi+V/qbUdrv2O/UHjFaEIVpj53HyNmAzcd48EfaBIi+zBhv/Hl1DCOFiS46TgPyF5hQyArSw8JHHP/DM/pfphCwj5Cvfqb3tuZtR0UXVZ6YB+tACQxV4fMAIrdJHCE3DMLY4veuzGCInD7eWqMclihtK0DqfTWu4wUP8mNpWGCdlxJfoB7KxopP1cNV2Wvh1tTsdOXuAWyC4jCLZQJT3+iTdWCokrEibc9Qjbzn4ndrSdwuj5nFM1ygAYo/RzZF4q+s8OXwM6BegRx1d5+IsqoJvZXAwgbM+h5d96GlbIHlHpyHu+xFLWieFgHHta7OVThxag87Ibu4R0Q2qc7/wxzwyODa115WN0k+FZ7PZVNRy
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2020 11:50:23.3816 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d27e4664-93f1-4e51-1645-08d7bc44650b
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];  Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5350
Archived-At: 
Subject: [TLS] Record-level ACKs in DTLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 11:50:30 -0000

--_000_AM6PR08MB3318E5A347314EB509AC91759BE80AM6PR08MB3318eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

TL;DR
This is all about various aspects of how ACKs work in DTLS 1.3:
- The DTLS 1.3 specification requires clarification regarding
  when ACKs should be sent.
- Record-level ACKs make efficient implementations for IoT
  devices harder. I argue that handshake-level ACKs reduce
  implementation complexity and allow for optimized
  implementations.

Details:
To illustrate, consider the following flight exchange, where the
second and third message in the second flight get reordered:

      Client                                  Server
   +----------+
   | Seq No 1 |-------------------------->   Received
   | Rec No a |
   +----------+
                                         +---------------+
    Received    <------------------------|   Seq No 1    |
                                         |   Rec No b    |
                                         +---------------+
                                         +---------------+
                           +-------------|   Seq No 2    |
                           |             |   Rec No c    |
                           |             +---------------+
                           |
                           |             +---------------+
    Received    <------------------------|   Seq No 3    |
                           |             |   Rec No d    |
                           |             +---------------+
  +-----------+            |
  |    ACK    |------------------------->
  | RecNo ??? |            |
  +-----------+            |
                           |
                           |
                           |
    Received    <----------+

The specification recommends that the client SHOULD send an ACK
when it receives out-of-order handshake message - here message (3,d)
while awaiting (2,c). However:

Question:
Which records does the client acknowledge in the ACK?

This is in fact implementation-dependent:
The client must only acknowledge record (3,d) if it has buffered it.
Implementations which don't implement out of order buffering of handshake
messages (to save RAM and ROM) must not acknowledge messages that weren't
buffered. The reason is that otherwise the server is mislead in which messa=
ges
need resending and which don't.

Conclusion 1:
If ACKs must only be sent for records which contain handshake messages
which were actually fed into the flight buffering / reassembly module
of the implementation, the specification should clearly say so.
I consider this point to be prone to misinterpretation, potentially
leading to incompatible implementations, because ACKs acknowledge
receipt at record granularity, and yet they must be sent only under
some assumptions on how their content was processed.


Next, given that the generation of record-ACKs is therefore content-specifi=
c,
I wonder why ACKs acknowledge records in the first place, and not triples
of (handshake seq nr, fragment offset, fragment length). It appears to me
that the latter matches their semantics much closer and allows for more
simpler and more efficient implementations. I'll elaborate on that in
the following.

As I understand, the simplest implementation of the retransmission state
machine using record-level ACKs works by buffering copies of records sent
in a flight and retransmits those that don't get acknowledged. The record
sequence numbers of the original and retransmitted records are internally
associated with the opaque record content, so that ACKs for both the origin=
al
and the retransmitted records can be recognized.

In this approach, the record contents are opaque to the sender's retransmis=
sion
state machine, which simplifies the implementation. However, it has major d=
rawbacks:

(1) It requires buffering the entire flight, which incurs high memory
    overhead that can be significant on constrained devices.

    Implementations should be allowed to not buffer handshake
    messages but re-generate them on the fly through a callback whenever
    retransmission is needed.

    Two examples:
    - Consider the Certificate message: The raw certificate
      (chain) must reside in RAM/ROM already, and the Certificate message
      could easily be re-regenerated from that. Buffering handshake message=
s
      instead creates significant and unnecessary overhead.

    - This is of increasing importance with the advent of post-quantum
      cryptography, which comes with significantly larger key material.

(2) It doesn't allow switching the MTU for retransmission.

    Once the MTU may change for retransmission, the sender cannot keep
    track anymore of a single set of record sequence numbers per message su=
ch
    that an ACK for any of them confirms receipt of the message.

Of course, no implementation is strictly _forced_ to follow the above appro=
ach,
but the current record-level ACKs design significantly hardens any other ap=
proach:

For example, retransmission through callbacks or support for MTU switching
requires maintaining the tuples (record seq nr, lists of handshake fragment=
s)
for all transmissions of the last flight. (Note that, in particular, just
remembering the mapping for the last transmission isn't enough, since an
acknowledgement for an earlier transmission might arrive late.)
The _sender_ would need to maintain less state, and would have an easier ti=
me
figuring out what to retransmit, if ACKs acknowledged handshake fragments
directly. On the _receiver_ side, there's no benefit of ACKing at the recor=
d level,
either, because -- as we have just seen -- it is _not_ the case that it can=
 be
implemented as an automated mechanism at the record level, but needs to be =
triggered
from the handshake layer, at a point where all information about the handsh=
ake content
are available.

Implementations following the above buffering-based approach don't increase
in complexity through a switch to handshake level acknowledgements instead
of record level acknowledgements: They can just treat the acknowledged hand=
shake
metadata as an _opaque_ identifier, replacing what was previously the recor=
d
sequence number.

Conclusion 2:
Handshake-level ACKs simplify the retransmission state machine
for non-buffering implementations on constrained devices, while
not hardening buffering implementations using record-level ACKs
so far. I'm aware of the lateness of this proposal, but would be
happy if the group would discuss and consider handshake-level ACKs
instead of record-level ACKs.


Let me know what you think,
Cheers,
Hanno
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.

--_000_AM6PR08MB3318E5A347314EB509AC91759BE80AM6PR08MB3318eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi,=









TL;DR=





This =
is all about various aspects of how ACKs work in DTLS 1.3:




- The=
 DTLS 1.3 specification requires clarification regarding




 =
; when ACKs should be sent.




- Rec=
ord-level ACKs make efficient implementations for IoT




 =
; devices harder. I argue that handshake-level ACKs reduce




 =
; implementation complexity and allow for optimized




 =
; implementations.









Detai=
ls:




To il=
lustrate, consider the following flight exchange, where the




secon=
d and third message in the second flight get reordered:









 =
;     Client               &nb=
sp;                  Server




 =
;  +----------+




 =
;  | Seq No 1 |-------------------------->   Received



 =
;  | Rec No a |




 =
;  +----------+




 =
;                     &nb=
sp;                  +----=
-----------+




 =
;   Received    <------------------------|   Seq No =
1    |




 =
;                     &nb=
sp;                  |   =
Rec No b    |




 =
;                     &nb=
sp;                  +----=
-----------+




 =
;                     &nb=
sp;                  +----=
-----------+




 =
;                     &nb=
sp;    +-------------|   Seq No 2    |<=
br>



 =
;                     &nb=
sp;    |             |   Rec N=
o c    |




 =
;                     &nb=
sp;    |             +---------=
------+




 =
;                     &nb=
sp;    |




 =
;                     &nb=
sp;    |             +---------=
------+




 =
;   Received    <------------------------|   Seq No =
3    |




 =
;                     &nb=
sp;    |             |   Rec N=
o d    |




 =
;                     &nb=
sp;    |             +---------=
------+




 =
; +-----------+            |



 =
; |    ACK    |------------------------->




 =
; | RecNo ??? |            |




 =
; +-----------+            |



 =
;                     &nb=
sp;    |




 =
;                     &nb=
sp;    |




 =
;                     &nb=
sp;    |




 =
;   Received    <----------+









The s=
pecification recommends that the client SHOULD send an ACK




when =
it receives out-of-order handshake message - here message (3,d)




while=
 awaiting (2,c). However:









Quest=
ion:




Which=
 records does the client acknowledge in the ACK?









This =
is in fact implementation-dependent:




The c=
lient must only acknowledge record (3,d) if it has buffered it.




Imple=
mentations which don't implement out of order buffering of handshake=





messa=
ges (to save RAM and ROM) must not acknowledge messages that weren't=





buffe=
red. The reason is that otherwise the server is mislead in which messages




need =
resending and which don't.









Concl=
usion 1:




If AC=
Ks must only be sent for records which contain handshake messages



which=
 were actually fed into the flight buffering / reassembly module




of th=
e implementation, the specification should clearly say so.




I con=
sider this point to be prone to misinterpretation, potentially




leadi=
ng to incompatible implementations, because ACKs acknowledge




recei=
pt at record granularity, and yet they must be sent only under




some =
assumptions on how their content was processed.














Next,=
 given that the generation of record-ACKs is therefore content-specific,




I won=
der why ACKs acknowledge records in the first place, and not triples=





of (h=
andshake seq nr, fragment offset, fragment length). It appears to me=





that =
the latter matches their semantics much closer and allows for more



simpl=
er and more efficient implementations. I'll elaborate on that in




the f=
ollowing.









As I =
understand, the simplest implementation of the retransmission state<=
br>



machi=
ne using record-level ACKs works by buffering copies of records sent=





in a =
flight and retransmits those that don't get acknowledged. The record=





seque=
nce numbers of the original and retransmitted records are internally=





assoc=
iated with the opaque record content, so that ACKs for both the original




and t=
he retransmitted records can be recognized.









In th=
is approach, the record contents are opaque to the sender's retransmission<=
/span>




state=
 machine, which simplifies the implementation. However, it has major drawba=
cks:









(1) I=
t requires buffering the entire flight, which incurs high memory




 =
;   overhead that can be significant on constrained devices.








 =
;   Implementations should be allowed to not buffer handshake



 =
;   messages but re-generate them on the fly through a callback whenev=
er




 =
;   retransmission is needed.









 =
;   Two examples:




 =
;   - Consider the Certificate message: The raw certificate




 =
;     (chain) must reside in RAM/ROM already, and the Certificate=
 message




 =
;     could easily be re-regenerated from that. Buffering handsha=
ke messages




 =
;     instead creates significant and unnecessary overhead.









 =
;   - This is of increasing importance with the advent of post-quantum=





 =
;     cryptography, which comes with significantly larger key mat=
erial.









(2) I=
t doesn't allow switching the MTU for retransmission.









 =
;   Once the MTU may change for retransmission, the sender cannot keep=





 =
;   track anymore of a single set of record sequence numbers per messa=
ge such




 =
;   that an ACK for any of them confirms receipt of the message.









Of co=
urse, no implementation is strictly _forced_ to follow the above approach,<=
/span>




but t=
he current record-level ACKs design significantly hardens any other approac=
h:









For e=
xample, retransmission through callbacks or support for MTU switching




requi=
res maintaining the tuples (record seq nr, lists of handshake fragments)




for a=
ll transmissions of the last flight. (Note that, in particular, just=





remem=
bering the mapping for the last transmission isn't enough, since an<=
br>



ackno=
wledgement for an earlier transmission might arrive late.)




The _=
sender_ would need to maintain less state, and would have an easier time




figur=
ing out what to retransmit, if ACKs acknowledged handshake fragments=





direc=
tly. On the _receiver_ side, there's no benefit of ACKing at the record lev=
el,




eithe=
r, because -- as we have just seen -- it is _not_ the case that it can be




imple=
mented as an automated mechanism at the record level, but needs to be trigg=
ered




from =
the handshake layer, at a point where all information about the handshake c=
ontent




are a=
vailable.









Imple=
mentations following the above buffering-based approach don't increase




in co=
mplexity through a switch to handshake level acknowledgements instead




of re=
cord level acknowledgements: They can just treat the acknowledged handshake=





metad=
ata as an _opaque_ identifier, replacing what was previously the record




seque=
nce number.









Concl=
usion 2:




Hands=
hake-level ACKs simplify the retransmission state machine




for n=
on-buffering implementations on constrained devices, while




not h=
ardening buffering implementations using record-level ACKs




so fa=
r. I'm aware of the lateness of this proposal, but would be




happy=
 if the group would discuss and consider handshake-level ACKs




inste=
ad of record-level ACKs.














Let m=
e know what you think,




Cheer=
s,



Hanno



IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose,
 or store or copy the information in any medium. Thank you.



--_000_AM6PR08MB3318E5A347314EB509AC91759BE80AM6PR08MB3318eurp_--


From nobody Fri Feb 28 06:44:58 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FA53A195D for ; Fri, 28 Feb 2020 06:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 hkgDwn0kn-VX for ; Fri, 28 Feb 2020 06:44:46 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 5AE483A1943 for ; Fri, 28 Feb 2020 06:44:45 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id d10so3574097ljl.9 for ; Fri, 28 Feb 2020 06:44:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uxk92BoTIgvF9ag/eSuAKZjZZQ1AG1BSLncjHQIELx4=; b=G4HmoK7LKHvNd9ekyLlD+NnuSlxgKtI+XvyB7Lj9dr4ErfIvSmC4Dm2xvf0zm4drbL +5z0nS0yNpedIT9pAZ6u/yH18+hTiMNqOyVfi0P3+1qkozI9VrHF+Vz5khVhymCQW3F7 NDzhlg7SWOzSYJbglr0rvz/V3RkBwzB+QlLrbpGnXJPrl8b5ccVOPDJtyTOtEcV9edBd OYphzZvxXU2MdrP30WabIY7fbLhi41ZBF31kaj+9KDCi5eDVBegzTuM33nO6q/MSoqB/ /JL3FmunayANjvFfqctRhbsHe6S6w39LYIP3MnKGBjlxyXDPVPYBh+b0uf3Po0s+rGf2 pn8A==
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=Uxk92BoTIgvF9ag/eSuAKZjZZQ1AG1BSLncjHQIELx4=; b=i0GiFE5YZLTwK11LVZBm1sdmY53D7GPtrjxy+H0OLWA1PPETzVOm4zJmZvsTp1OlOK lYAeG6dOxzm+kjjyBaG9NrgQoglty+9J0g0xUXtyxKOd/btCrZkWKhsLkO0sRWAVpglJ G/hXMZL/WCKytuGsqVYZs5ozK1rQZib5t5nAETcly9QdkL6ExDcZ0+qI37+IJzBqTrIS JR4azIquLy6bt443LaYm9bsReWxzUB0vToVrO1dXCsZ+H9W9Viy8BOtcCmWVOdP2ljgn ks8M90gJTzLv9gKMLuPwxUP6WNI7dYzoesp2orMuJTEtc9JfC6S77SfKnZogAimpyY8c CfNQ==
X-Gm-Message-State: ANhLgQ2ghmi/0zLN6v0gqlv8lCthMHpvo/QKW1d5wF9howFIw0IzMTi6 z8JRcM7sZMmO9a2Yzjvr6sVPmyhJn8nARKN4Y+HM1g==
X-Google-Smtp-Source: ADFU+vvwEbwF4/LSYpxDKNxj6w93GmKBQtG9C7NfIJZuOp2Fxm7K7zabPH1MfDv7cBqnsbCjTavSSWocVeqCfg5NXzQ=
X-Received: by 2002:a2e:b0c4:: with SMTP id g4mr3172351ljl.83.1582901083480; Fri, 28 Feb 2020 06:44:43 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Eric Rescorla 
Date: Fri, 28 Feb 2020 06:44:07 -0800
Message-ID: 
To: Hanno Becker 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000cbae9a059fa3e031"
Archived-At: 
Subject: Re: [TLS] Record-level ACKs in DTLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 14:44:55 -0000

--000000000000cbae9a059fa3e031
Content-Type: text/plain; charset="UTF-8"

Hanno,

Thanks for your note. I don't think your proposal will be an
improvement. It destroys information which could otherwise be used for
improve round-trip and loss estimation (cf. the difference between
QUIC and TCP ACKs). Second, it prevents the receiver from saying
some non-sensical things like acknowledging part of a received packet.
It's of course true that the current design allows you to ACK
non-received packets, but that's much more straightforward to
detect.

I agree that the current design requires keeping somewhat more
state during the period when no ACKs have been received. However,
your proposal actually requires retaining a simila data structure
once they have been received.

Some detailed comments below.





> Hi,
>
> TL;DR
> This is all about various aspects of how ACKs work in DTLS 1.3:
> - The DTLS 1.3 specification requires clarification regarding
>   when ACKs should be sent.
> - Record-level ACKs make efficient implementations for IoT
>   devices harder. I argue that handshake-level ACKs reduce
>   implementation complexity and allow for optimized
>   implementations.
>
> Details:
> To illustrate, consider the following flight exchange, where the
> second and third message in the second flight get reordered:
>
>       Client                                  Server
>    +----------+
>    | Seq No 1 |-------------------------->   Received
>    | Rec No a |
>    +----------+
>                                          +---------------+
>     Received    <------------------------|   Seq No 1    |
>                                          |   Rec No b    |
>                                          +---------------+
>                                          +---------------+
>                            +-------------|   Seq No 2    |
>                            |             |   Rec No c    |
>                            |             +---------------+
>                            |
>                            |             +---------------+
>     Received    <------------------------|   Seq No 3    |
>                            |             |   Rec No d    |
>                            |             +---------------+
>   +-----------+            |
>   |    ACK    |------------------------->
>   | RecNo ??? |            |
>   +-----------+            |
>                            |
>                            |
>                            |
>     Received    <----------+
>
> The specification recommends that the client SHOULD send an ACK
> when it receives out-of-order handshake message - here message (3,d)
> while awaiting (2,c). However:
>
> Question:
> Which records does the client acknowledge in the ACK?
>
> This is in fact implementation-dependent:
> The client must only acknowledge record (3,d) if it has buffered it.
> Implementations which don't implement out of order buffering of handshake
> messages (to save RAM and ROM) must not acknowledge messages that weren't
> buffered. The reason is that otherwise the server is mislead in which
messages
> need resending and which don't.
>
> Conclusion 1:
> If ACKs must only be sent for records which contain handshake messages
> which were actually fed into the flight buffering / reassembly module
> of the implementation, the specification should clearly say so.
> I consider this point to be prone to misinterpretation, potentially
> leading to incompatible implementations, because ACKs acknowledge
> receipt at record granularity, and yet they must be sent only under
> some assumptions on how their content was processed.

Yes, I agree that you need to only ACK data which you have processed.
I would be happy to take a PR to clarify this point.


> As I understand, the simplest implementation of the retransmission state
> machine using record-level ACKs works by buffering copies of records sent
> in a flight and retransmits those that don't get acknowledged. The record
> sequence numbers of the original and retransmitted records are internally
> associated with the opaque record content, so that ACKs for both the
original
> and the retransmitted records can be recognized.
>
> In this approach, the record contents are opaque to the sender's
retransmission
> state machine, which simplifies the implementation. However, it has major
drawbacks:
>
> (1) It requires buffering the entire flight, which incurs high memory
>     overhead that can be significant on constrained devices.
>
>     Implementations should be allowed to not buffer handshake
>     messages but re-generate them on the fly through a callback whenever
>     retransmission is needed.

Note that many handshake messages cannot be re-generated without extensive
caching (for instance, ServerHello). However, as long as the messages
are generated consistently (a requirement in any case), then you in
fact need-not buffer them in memory; you merely keep the record -> offset
mappings as an edit list.


>     Two examples:
>     - Consider the Certificate message: The raw certificate
>       (chain) must reside in RAM/ROM already, and the Certificate message
>       could easily be re-regenerated from that. Buffering handshake
messages
>       instead creates significant and unnecessary overhead.
>
>     - This is of increasing importance with the advent of post-quantum
>       cryptography, which comes with significantly larger key material.
>
> (2) It doesn't allow switching the MTU for retransmission.
>
>     Once the MTU may change for retransmission, the sender cannot keep
>     track anymore of a single set of record sequence numbers per message
such
>     that an ACK for any of them confirms receipt of the message.
>
> Of course, no implementation is strictly _forced_ to follow the above
approach,
> but the current record-level ACKs design significantly hardens any other
approach:



> For example, retransmission through callbacks or support for MTU switching
> requires maintaining the tuples (record seq nr, lists of handshake
fragments)
> for all transmissions of the last flight. (Note that, in particular, just
> remembering the mapping for the last transmission isn't enough, since an
> acknowledgement for an earlier transmission might arrive late.)

Well, sort of. Nothing forbids duplicate transmission, so just remembering
the last transmission is mostly just inefficient.


> Conclusion 2:
> Handshake-level ACKs simplify the retransmission state machine
> for non-buffering implementations on constrained devices, while
> not hardening buffering implementations using record-level ACKs
> so far. I'm aware of the lateness of this proposal, but would be
> happy if the group would discuss and consider handshake-level ACKs
> instead of record-level ACKs.

As noted above, I do not believe we should make this change.

-Ekr

--000000000000cbae9a059fa3e031
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hanno,

Thanks for your note. I don't think your=
 proposal will be an
improvement. It destroys information which could ot=
herwise be used for
improve round-trip and loss estimation (cf. the diff=
erence between
QUIC and TCP ACKs). Second, it prevents the receiver from=
 saying
some non-sensical things like acknowledging part of a received p=
acket.
It's of course true that the current design allows you to ACK=

non-received packets, but that's much more straightforward to
de=
tect.

I agree that the current design requires keeping somewhat more=

state during the period when no ACKs have been received. However,
yo=
ur proposal actually requires retaining a simila data structure
once the=
y have been received.

Some detailed comments below.



<=
br>
> Hi,
> 
> TL;DR
> This is all about various as=
pects of how ACKs work in DTLS 1.3:
> - The DTLS 1.3 specification re=
quires clarification regarding
> =C2=A0 when ACKs should be sent.
=
> - Record-level ACKs make efficient implementations for IoT
> =C2=
=A0 devices harder. I argue that handshake-level ACKs reduce
> =C2=A0=
 implementation complexity and allow for optimized
> =C2=A0 implement=
ations.
> 
> Details:
> To illustrate, consider the follo=
wing flight exchange, where the
> second and third message in the sec=
ond flight get reordered:
> 
> =C2=A0 =C2=A0 =C2=A0 Client =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server
> =C2=A0 =C2=A0+-----=
-----+
> =C2=A0 =C2=A0| Seq No 1 |--------------------------> =C2=
=A0 Received
> =C2=A0 =C2=A0| Rec No a |
> =C2=A0 =C2=A0+------=
----+
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0+---------------+
> =C2=A0 =C2=A0 Received =C2=A0 =C2=A0=
<------------------------| =C2=A0 Seq No 1 =C2=A0 =C2=A0|
> =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =
Rec No b =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------+
> =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------+> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------| =C2=A0 Seq No 2 =C2=A0 =C2=A0|<=
br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
| =C2=A0 Rec No c =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------------+
> =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 +---------------+
> =C2=A0 =C2=A0 Received =C2=A0 =C2=A0<--=
----------------------| =C2=A0 Seq No 3 =C2=A0 =C2=A0|
> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 Rec No d =
=C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 +---------------+
> =C2=A0 +-----------+ =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 | =C2=A0 =C2=A0ACK =C2=A0 =C2=
=A0|------------------------->
> =C2=A0 | RecNo ??? | =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 +-----------+ =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0=
 Received =C2=A0 =C2=A0<----------+
> 
> The specification r=
ecommends that the client SHOULD send an ACK
> when it receives out-o=
f-order handshake message - here message (3,d)
> while awaiting (2,c)=
. However:
> 
> Question:
> Which records does the client=
 acknowledge in the ACK?
>
> This is in fact implementation-dep=
endent:
> The client must only acknowledge record (3,d) if it has buf=
fered it.
> Implementations which don't implement out of order bu=
ffering of handshake
> messages (to save RAM and ROM) must not acknow=
ledge messages that weren't
> buffered. The reason is that otherw=
ise the server is mislead in which messages
> need resending and whic=
h don't.
> 
> Conclusion 1:
> If ACKs must only be se=
nt for records which contain handshake messages
> which were actually=
 fed into the flight buffering / reassembly module
> of the implement=
ation, the specification should clearly say so.
> I consider this poi=
nt to be prone to misinterpretation, potentially
> leading to incompa=
tible implementations, because ACKs acknowledge
> receipt at record g=
ranularity, and yet they must be sent only under
> some assumptions o=
n how their content was processed.

Yes, I agree that you need to onl=
y ACK data which you have processed.
I would be happy to take a PR to cl=
arify this point.


> As I understand, the simplest implementat=
ion of the retransmission state
> machine using record-level ACKs wor=
ks by buffering copies of records sent
> in a flight and retransmits =
those that don't get acknowledged. The record
> sequence numbers =
of the original and retransmitted records are internally
> associated=
 with the opaque record content, so that ACKs for both the original
>=
 and the retransmitted records can be recognized.
> 
> In this =
approach, the record contents are opaque to the sender's retransmission=

> state machine, which simplifies the implementation. However, it ha=
s major drawbacks:
> 
> (1) It requires buffering the entire fl=
ight, which incurs high memory
> =C2=A0 =C2=A0 overhead that can be s=
ignificant on constrained devices.
> 
> =C2=A0 =C2=A0 Implement=
ations should be allowed to not buffer handshake
> =C2=A0 =C2=A0 mess=
ages but re-generate them on the fly through a callback whenever
> =
=C2=A0 =C2=A0 retransmission is needed.

Note that many handshake mes=
sages cannot be re-generated without extensive
caching (for instance, Se=
rverHello). However, as long as the messages
are generated consistently =
(a requirement in any case), then you in
fact need-not buffer them in me=
mory; you merely keep the record -> offset
mappings as an edit list.<=
br>

> =C2=A0 =C2=A0 Two examples:
> =C2=A0 =C2=A0 - Conside=
r the Certificate message: The raw certificate
> =C2=A0 =C2=A0 =C2=A0=
 (chain) must reside in RAM/ROM already, and the Certificate message
>=
; =C2=A0 =C2=A0 =C2=A0 could easily be re-regenerated from that. Buffering =
handshake messages
> =C2=A0 =C2=A0 =C2=A0 instead creates significant=
 and unnecessary overhead.
> 
> =C2=A0 =C2=A0 - This is of incr=
easing importance with the advent of post-quantum
> =C2=A0 =C2=A0 =C2=
=A0 cryptography, which comes with significantly larger key material.
&g=
t; 
> (2) It doesn't allow switching the MTU for retransmission.<=
br>> 
> =C2=A0 =C2=A0 Once the MTU may change for retransmission, =
the sender cannot keep
> =C2=A0 =C2=A0 track anymore of a single set =
of record sequence numbers per message such
> =C2=A0 =C2=A0 that an A=
CK for any of them confirms receipt of the message.
> 
> Of cou=
rse, no implementation is strictly _forced_ to follow the above approach,> but the current record-level ACKs design significantly hardens any o=
ther approach:



> For example, retransmission through call=
backs or support for MTU switching
> requires maintaining the tuples =
(record seq nr, lists of handshake fragments)
> for all transmissions=
 of the last flight. (Note that, in particular, just
> remembering th=
e mapping for the last transmission isn't enough, since an
> ackn=
owledgement for an earlier transmission might arrive late.)

Well, so=
rt of. Nothing forbids duplicate transmission, so just remembering
the l=
ast transmission is mostly just inefficient.


> Conclusion 2:<=
br>> Handshake-level ACKs simplify the retransmission state machine
&=
gt; for non-buffering implementations on constrained devices, while
>=
 not hardening buffering implementations using record-level ACKs
> so=
 far. I'm aware of the lateness of this proposal, but would be
> =
happy if the group would discuss and consider handshake-level ACKs
> =
instead of record-level ACKs.

As noted above, I do not believe we sh=
ould make this change.

-Ekr




--000000000000cbae9a059fa3e031--


From nobody Fri Feb 28 07:58:32 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1133A1A7E for ; Fri, 28 Feb 2020 07:58:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 zEIzrS-c22lk for ; Fri, 28 Feb 2020 07:58:28 -0800 (PST)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78483A1A94 for ; Fri, 28 Feb 2020 07:58:27 -0800 (PST)
Received: by mail-vs1-xe35.google.com with SMTP id u26so2249193vsg.2 for ; Fri, 28 Feb 2020 07:58:27 -0800 (PST)
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=WZ/eUolWLzLCWTVwbnvoXM5iUswtwytIUCUr6E0FC9o=; b=qaF4qH3w3qJp89tHB1omMKme//6/0KF1jOBkIyGavCypYQizbxhsWftznSC/7INRXs CcRClXQxYTJcxTUejBovKjRYG4GhAtPVeL7StmiQk78F+tCQLZ50+lp5/1nSuCEM+EAY WEBiNLxpcqd4c52DP2fx9Rhs2vLiI7cp+GDjKGHriyXfPqS8O0MAqDAjNL8h+YvibMQZ aMnnP88CZqFi17elehfAWSLOdJ8uiDzLQMfLbZKxiHBefucZkYnPL2Vcp/UYso1PD84C N9DsPkjaBK6b+NtBtdm/K2yqvKzsZwwNyQvok9F982m/y8ZfQ5dXYEo2eMNN3AQG37GU QzIA==
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=WZ/eUolWLzLCWTVwbnvoXM5iUswtwytIUCUr6E0FC9o=; b=VFf2ZPLheyfQtErfwjH+TiXyCqOxvrk2+j5rgRIkQclRYFSoy/7Im9Fv+qSNFkQ5hU IvwbKQA5HX+Lc/xf7D/Li1v6hS0wwDOIkOwV3oeQiC/3pOkJvYDCRNkNttCVPAuFmdVi F125E+zSKT83LKtFYix7jafiHrEy4dKbV2as6PZs/HZKVzwxXZ2fvBLrhxKXWNvM5ogH s8eZucn8FFEbtAMqP51v8eVvv2Xm3s/eMKSZhcy053GamKLvwXvt19XG8fttW1/R2o+/ 1jgqRgN2IdD+NWbLR2uwcMZBz09awCXtpevg76ZJL1mmIRVumxRplI60ZTu+lIC8pJiQ ricw==
X-Gm-Message-State: ANhLgQ0Gs0cYz9/V79joQikXsJdY2aDbIupY73AlGCsvN4vgC+W2pjP6 Lh9O2MB+kMhcMPAUN3hWrsHk9lmwekvNEdJyDSs=
X-Google-Smtp-Source: ADFU+vu4IQ1e0wQfZTptojVtDgZnmF4yDtp3T6Y3EenIHMv4Ly3s57hlq0at6YkRZkK6GE4W7D7UkoaSaCctGjDSsaQ=
X-Received: by 2002:a05:6102:2e4:: with SMTP id j4mr2891428vsj.134.1582905506688;  Fri, 28 Feb 2020 07:58:26 -0800 (PST)
MIME-Version: 1.0
References:     <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>     <75b70352-9cc5-4aa1-9cca-42f37fe615d2@www.fastmail.com>
In-Reply-To: <75b70352-9cc5-4aa1-9cca-42f37fe615d2@www.fastmail.com>
From: Jonathan Hoyland 
Date: Fri, 28 Feb 2020 15:58:15 +0000
Message-ID: 
To: Christopher Wood 
Cc: David Benjamin , "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000707390059fa4e8de"
Archived-At: 
Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 15:58:30 -0000

--000000000000707390059fa4e8de
Content-Type: text/plain; charset="UTF-8"

On Fri, 28 Feb 2020 at 04:49, Christopher Wood  wrote:

>
>
> On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
> > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland
> >  wrote:
> > > This would be for cases where we want to inject extra context into a
> resumption.
> > > That would be anything that changes an authentication property, so for
> example if you wanted to include some agreement on the status of a
> post-handshake auth or Exported Authenticator.
> > >
> > > So for example imagine I had a session during which I received an EA
> and when I came to resume that session I wished to indicate that I was
> still willing to accept the EA.
> > > I would offer a special PSK and inject some extra material into the
> handshake*, and if the server was able / willing to agree to this it would
> select the PSK.
> > > I could also offer a PSK with no extra injected material, as a
> fallback, and request the EA again.
> > >
> > > * This would only affect the binder for the PSK in the ClientHello.
> >
> > I'm still not following. If you're resuming, this is a PSK issued from
> > a NewSessionTicket, in which case this isn't an imported PSK at all.
> > It's a resumption PSK and uses "res binder". If we needed to negotiate
> > variations on a resumption, this importer mechanism wouldn't give us a
> > way to express that anyway. I expect we'd instead lean on some
> > combination of multiple tickets, NewSessionTicket extensions, and plain
> > ClientHello extensions. But maybe I'm still not understanding the
> > scenario.
>
The security of combinations of tickets is non-trivial to reason about
(though not impossible), in the same way as Exported Authenticators (which
makes sense given that EAs would be a reason to do this).
I'll have to give some thought to a compelling use case, but I just like
the option for consistency.
Then again it is said "A foolish consistency is the hobgoblin of little
minds [...]", so ...


> > > Another potential use would be the binding for ECHO, although I don't
> have a clear enough picture of the precise mechanics of that to know if it
> would be helpful.
> >
> > Chris is probably more up-to-date here, but I don't believe the current
> > ECHO design looks like a funny PSK.
>
> That's right -- it's just another extension in the outer CH.
>

I was thinking about the ECHO design from a forward/backward binding
perspective.
I think we should make the smallest number of changes to the key schedule
possible that will cover all possible future use cases, so an overall
consistent approach would be ideal.
If the WG doesn't adopt a key schedule extension draft (either mine,
draft-Stebila, or some other one) then this looks like the strongest choice.


> Best,
> Chriss
>
> > > Something that would allow for a consistent naming in the future would
> be my preference, because just as "imp binder" doesn't preclude "imp r
> binder", using "imp e binder" doesn't preclude us never adopting "imp r
> binder".
> > > I vaguely remember discussing whether the longer name would tip us
> into an extra hash invocation at the last IETF, and concluding that it
> didn't, although I'd have to double check that.
> >
> > Of course. Yeah, I think the more pertinent question is whether "imp r
> > binder" is actually a thing.
> > > Regards,
> > >
> > > Jonathan
> > >
> > > On Mon, 24 Feb 2020, 22:23 David Benjamin, 
> wrote:
> > >> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <
> jonathan.hoyland@gmail.com> wrote:
> > >>> Just looking at this again, it might be better to make a slightly
> different tweak to the key schedule.
> > >>> Instead of:
> > >>>                 0
> >                 |
> >                 v
> >       PSK ->  HKDF-Extract = Early Secret
> >                 |
> >                 +-----> Derive-Secret(., "ext binder"
> >                 |                      | "res binder"
> >                 |                      | "imp binder", "")
> >                 |                     = binder_key                v
> > >>>
> > >>> We should do:
> > >>>
> > >>>                 0
> >                 |
> >                 v
> >       PSK ->  HKDF-Extract = Early Secret
> >                 |
> >                 +-----> Derive-Secret(., "ext binder"
> >                 |                      | "res binder"
> >                 |                      | "imp e binder"
> > |                      | "imp r binder", "")
> >                 |                     = binder_key                v
> > >>> or at least:
> > >>>                 0
> >                 |
> >                 v
> >       PSK ->  HKDF-Extract = Early Secret
> >                 |
> >                 +-----> Derive-Secret(., "ext binder"
> >                 |                      | "res binder"
> >                 |                      | "imp e binder", "")
> >                 |                     = binder_key                v
> > >>>
> > >>>
> > >>> Just so that we can distinguish between external imported binders
> and resumed imported binders, should we at some point decide to do both.
> > >>
> > >> I may just be confused, but what would a resumed imported binder
> mean? I see this mechanism as largely a bugfix for TLS 1.3 external PSKs,
> rather than a new kind of adjective describing PSKs.
> > >>
> > >> ("imp binder" also doesn't preclude "imp r binder" later if we later
> define something which needs it, but I'm confused what the concept even
> would be.)
> > >>
> > >> David
> > >>> On Mon, 24 Feb 2020 at 20:50, Christopher Wood 
> wrote:
> > >>>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
> > >>>>  >
> > >>>>  >
> > >>>>  > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla 
> wrote:
> > >>>>  > >
> > >>>>  > >
> > >>>>  > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre 
> wrote:
> > >>>>  > >> Hi,
> > >>>>  > >>
> > >>>>  > >> I'm not sure how violations of these requirements would
> result in poor interoperability:
> > >>>>  > >>
> > >>>>  > >> Clients which import external keys TLS MUST NOT use these
> keys for
> > >>>>  > >> any other purpose. Moreover, each external PSK MUST be
> associated
> > >>>>  > >> with at most one hash function.
> > >>>>  > >>
> > >>>>  > >> These seem like aspirational security goals. It would be
> better to describe the consequences of violating these conditions.
> > >>>>  > >
> > >>>>  > > I don't agree. They are requirements in order to be able to
> make the assertions we want to make about the security of the protocol.
> > >>>>  > >
> > >>>>  > > This is consistent with the following text of RFC 2119 S 6
> > >>>>  > > ".. or to limit behavior which has potential for causing harm
> (e.g., limiting retransmisssions) "
> > >>>>  > >
> > >>>>  > > I don't think it would be unreasonable.to explain the reason
> for these, though this is already a requirement of 8446 S 4.2.11 (though
> without justification).
> > >>>>  >
> > >>>>  > I think that interpretation of 2119 is a stretch, but your idea
> to add
> > >>>>  > an explanation while keeping the 2119 terms addresses my
> concern. At
> > >>>>  > the very least, the draft should note this is already a
> requirement of
> > >>>>  > 8446.
> > >>>>
> > >>>>  That seems perfectly reasonable! We can point to the security
> considerations to clarify the "single hash function" requirement, and we
> can note cross protocol attack deterrence for the other claim. Would that
> suffice? If not, can you please recommend text?
> > >>>>
> > >>>>  Thanks,
> > >>>>  Chris
> > >>>>
> > >>>>  _______________________________________________
> > >>>>  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
>

--000000000000707390059fa4e8de
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, 28 Feb 2020 at 04:=
49, Christopher Wood <caw@heaping=
bits.net> wrote:




On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:

> On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland 

> <jo=
nathan.hoyland@gmail.com> wrote:

> > This would be for cases where we want to inject extra context int=
o a resumption. 

> > That would be anything that changes an authentication property, s=
o for example if you wanted to include some agreement on the status of a po=
st-handshake auth or Exported Authenticator.

> > 

> > So for example imagine I had a session during which I received an=
 EA and when I came to resume that session I wished to indicate that I was =
still willing to accept the EA.

> > I would offer a special PSK and inject some extra material into t=
he handshake*, and if the server was able / willing to agree to this it wou=
ld select the PSK. 

> > I could also offer a PSK with no extra injected material, as a fa=
llback, and request the EA again. 

> > 

> > * This would only affect the binder for the PSK in the ClientHell=
o. 

> 

> I'm still not following. If you're resuming, this is a PSK iss=
ued from 

> a NewSessionTicket, in which case this isn't an imported PSK at al=
l. 

> It's a resumption PSK and uses "res binder". If we neede=
d to negotiate 

> variations on a resumption, this importer mechanism wouldn't give =
us a 

> way to express that anyway. I expect we'd instead lean on some 
> combination of multiple tickets, NewSessionTicket extensions, and plai=
n 

> ClientHello extensions. But maybe I'm still not understanding the =


> scenario.
The security of combinations of tickets=
 is non-trivial to reason about (though not impossible), in the same way as=
 Exported Authenticators (which makes sense given that EAs would be a reaso=
n to do this).
I'll have to give some thought to a compelling=
 use case, but I just like the option for consistency.=C2=A0
Then=
 again it is said "A foolish consistency is the hobgoblin of little mi=
nds [...]", so ...
=C2=A0

> > Another potential use would be the binding for ECHO, although I d=
on't have a clear enough picture of the precise mechanics of that to kn=
ow if it would be helpful.

> 

> Chris is probably more up-to-date here, but I don't believe the cu=
rrent 

> ECHO design looks like a funny PSK.



That's right -- it's just another extension in the outer CH. 

I was thinking about the ECHO design from a forwa=
rd/backward binding perspective.=C2=A0
I think=C2=A0we should make the =
smallest number of changes to the key schedule possible that will cover all=
 possible future use cases, so an overall consistent approach would be idea=
l.=C2=A0
If the WG doesn't adopt a key schedule ex=
tension draft (either mine, draft-Stebila, or some other one) then this loo=
ks like the strongest choice.




Best,

Chriss



> > Something that would allow for a consistent naming in the future =
would be my preference, because just as "imp binder" doesn't =
preclude "imp r binder", using "imp e binder" doesn'=
;t preclude us never adopting "imp r binder".

> > I vaguely remember discussing whether the longer name would tip u=
s into an extra hash invocation at the last IETF, and concluding that it di=
dn't, although I'd have to double check that. 

> 

> Of course. Yeah, I think the more pertinent question is whether "=
imp r 

> binder" is actually a thing.

> > Regards,

> > 

> > Jonathan 

> > 

> > On Mon, 24 Feb 2020, 22:23 David Benjamin, <davidben@chromium.org> wrot=
e:

> >> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <jonathan.hoyland@g=
mail.com> wrote:

> >>> Just looking at this again, it might be better to make a =
slightly different tweak to the key schedule.

> >>> Instead of:

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A00

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v

>=C2=A0 =C2=A0 =C2=A0 =C2=A0PSK ->=C2=A0 HKDF-Extract =3D Early Secre=
t

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----->=
; Derive-Secret(., "ext binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;res binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;imp binder", "")

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D bi=
nder_key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v

> >>> 

> >>> We should do:

> >>> 

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A00

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v

>=C2=A0 =C2=A0 =C2=A0 =C2=A0PSK ->=C2=A0 HKDF-Extract =3D Early Secre=
t

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----->=
; Derive-Secret(., "ext binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;res binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;imp e binder"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 

> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 | "imp r binder", "")

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D bi=
nder_key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v

> >>> or at least:

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A00

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v

>=C2=A0 =C2=A0 =C2=A0 =C2=A0PSK ->=C2=A0 HKDF-Extract =3D Early Secre=
t

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----->=
; Derive-Secret(., "ext binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;res binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;imp e binder", "")

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D bi=
nder_key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v

> >>> 

> >>> 

> >>> Just so that we can distinguish between external imported=
 binders and resumed imported binders, should we at some point decide to do=
 both. 

> >> 

> >> I may just be confused, but what would a resumed imported bin=
der mean? I see this mechanism as largely a bugfix for TLS 1.3 external PSK=
s, rather than a new kind of adjective describing PSKs.

> >> 

> >> ("imp binder" also doesn't preclude "imp r=
 binder" later if we later define something which needs it, but I'=
m confused what the concept even would be.)

> >> 

> >> David

> >>> On Mon, 24 Feb 2020 at 20:50, Christopher Wood <caw@heapingbits.net&=
gt; wrote:

> >>>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
> >>>>=C2=A0 > 

> >>>>=C2=A0 > 

> >>>>=C2=A0 > On Fri, Feb 21, 2020 at 8:35 AM Eric Resco=
rla <ekr@rtfm.com&=
gt; wrote:

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > On Thu, Feb 20, 2020 at 7:08 PM Rob S=
ayre <sayrer@gmail=
.com> wrote:

> >>>>=C2=A0 > >> Hi,

> >>>>=C2=A0 > >> 

> >>>>=C2=A0 > >> I'm not sure how violations o=
f these requirements would result in poor interoperability:

> >>>>=C2=A0 > >> 

> >>>>=C2=A0 > >> Clients which import external key=
s TLS MUST NOT use these keys for

> >>>>=C2=A0 > >> any other purpose. Moreover, each=
 external PSK MUST be associated

> >>>>=C2=A0 > >> with at most one hash function.
> >>>>=C2=A0 > >> 

> >>>>=C2=A0 > >> These seem like aspirational secu=
rity goals. It would be better to describe the consequences of violating th=
ese conditions.

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > I don't agree. They are requireme=
nts in order to be able to make the assertions we want to make about the se=
curity of the protocol.

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > This is consistent with the following=
 text of RFC 2119 S 6

> >>>>=C2=A0 > > ".. or to limit behavior which h=
as potential for causing harm (e.g., limiting retransmisssions) "

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > I don't think it would be unreasonab=
le.to explain the reason for these, though this is already a requiremen=
t of 8446 S 4.2.11 (though without justification).

> >>>>=C2=A0 > 

> >>>>=C2=A0 > I think that interpretation of 2119 is a s=
tretch, but your idea to add 

> >>>>=C2=A0 > an explanation while keeping the 2119 term=
s addresses my concern. At 

> >>>>=C2=A0 > the very least, the draft should note this=
 is already a requirement of 

> >>>>=C2=A0 > 8446.

> >>>> 

> >>>>=C2=A0 That seems perfectly reasonable! We can point t=
o the security considerations to clarify the "single hash function&quo=
t; requirement, and we can note cross protocol attack deterrence for the ot=
her claim. Would that suffice? If not, can you please recommend text?

> >>>> 

> >>>>=C2=A0 Thanks,

> >>>>=C2=A0 Chris

> >>>> 

> >>>>=C2=A0 _______________________________________________=


> >>>>=C2=A0 TLS mailing list

> >>>> TLS=
@ietf.org

> >>>> https://www.ietf.org/mailman/listinfo=
/tls

> >>>=C2=A0 _______________________________________________

> >>>=C2=A0 TLS mailing list

> >>> TLS@iet=
f.org

> >>> https://www.ietf.org/mailman/listinfo/tls=





--000000000000707390059fa4e8de--


From nobody Fri Feb 28 08:03:20 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127F83A1AE0 for ; Fri, 28 Feb 2020 08:03:18 -0800 (PST)
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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=Vny030/+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XqxISDQy
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DZ7MH4qyu-4 for ; Fri, 28 Feb 2020 08:03:16 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77C03A1AD8 for ; Fri, 28 Feb 2020 08:03:15 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0B70D22022; Fri, 28 Feb 2020 11:03:15 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 28 Feb 2020 11:03:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=7J/HmpdvRpMdIjP7yvUNRdkRKTz0 +Xqj77D5QfLNM3g=; b=Vny030/+EoZQijmfVW81nDemcl/t0qrWG9xmFhjg53hN U+BRxSqobs/QqUER0+SbU+4UBcnQzVrFMYc2EWUViNz3JJyUV0k1aJFBOnGJGACH I06+QquSC2rCJTpD86U0qKFaSGC4zWuE+wms5HXBwUZhcNSZaNHTZoiqvUAklwk4 s/y34uiARMK4VWFZKBWwMU0yfaIVr6xxUypzMv31BD4GCHVSUYX5y0Guo6KHHMTt Utg72MSdkePVruLoL+flLlEjk/bga5O4pbVQh9BEVkLIup5U9nSiVlM8tmPGp6fQ Q+ikuJykD7MG+TLd/qu7YTZDaIlGUDhPFe++fOC64A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7J/Hmp dvRpMdIjP7yvUNRdkRKTz0+Xqj77D5QfLNM3g=; b=XqxISDQyyiogx9yUXiLgyu WqqLGFDL4zjwmsdLrfwT6/FOSzGocdrJ95ONH/ng7nRldrkXClnssCdx8XPC5SKg sUtbdfpMMfiTgOJ8/I8Lw4FsDCUB9K+ioqkYzucrMeFfEaxAnJn0TfQyTScPs1VM CUOKuPAh7mz6Jc1QnDX6Xq/FQBuzmjRv2bgochBg2krAgY5at2/kXrmQVWNqn4wu 5AA/48BVOsOjhnXxa+kiCTvzFiNLr7AC1Syn3R00qIZaEj6N3I/SFqupMl4MWuir MFFI1jDFKY8S+ksKZwJs6q7asYpdixfUZgYIP78rhI8pNq1RiKl4QlH10YFcVOPA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrleekgdekvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 56E4C3C00A1; Fri, 28 Feb 2020 11:03:14 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-967-g014f925-fmstable-20200226v1
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:     <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>     <75b70352-9cc5-4aa1-9cca-42f37fe615d2@www.fastmail.com> 
Date: Fri, 28 Feb 2020 08:02:54 -0800
From: "Christopher Wood" 
To: "Jonathan Hoyland" 
Cc: "David Benjamin" , "TLS@ietf.org" 
Content-Type: text/plain
Archived-At: 
Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 16:03:18 -0000

On Fri, Feb 28, 2020, at 7:58 AM, Jonathan Hoyland wrote:
> 
> 
> On Fri, 28 Feb 2020 at 04:49, Christopher Wood  wrote:
> > 
> > 
> >  On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
> >  > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland 
> >  >  wrote:
> >  > > This would be for cases where we want to inject extra context into a resumption. 
> >  > > That would be anything that changes an authentication property, so for example if you wanted to include some agreement on the status of a post-handshake auth or Exported Authenticator.
> >  > > 
> >  > > So for example imagine I had a session during which I received an EA and when I came to resume that session I wished to indicate that I was still willing to accept the EA.
> >  > > I would offer a special PSK and inject some extra material into the handshake*, and if the server was able / willing to agree to this it would select the PSK. 
> >  > > I could also offer a PSK with no extra injected material, as a fallback, and request the EA again. 
> >  > > 
> >  > > * This would only affect the binder for the PSK in the ClientHello. 
> >  > 
> >  > I'm still not following. If you're resuming, this is a PSK issued from 
> >  > a NewSessionTicket, in which case this isn't an imported PSK at all. 
> >  > It's a resumption PSK and uses "res binder". If we needed to negotiate 
> >  > variations on a resumption, this importer mechanism wouldn't give us a 
> >  > way to express that anyway. I expect we'd instead lean on some 
> >  > combination of multiple tickets, NewSessionTicket extensions, and plain 
> >  > ClientHello extensions. But maybe I'm still not understanding the 
> >  > scenario.
> The security of combinations of tickets is non-trivial to reason about 
> (though not impossible), in the same way as Exported Authenticators 
> (which makes sense given that EAs would be a reason to do this).
> I'll have to give some thought to a compelling use case, but I just 
> like the option for consistency. 
> Then again it is said "A foolish consistency is the hobgoblin of little 
> minds [...]", so ...
> >  > > Another potential use would be the binding for ECHO, although I don't have a clear enough picture of the precise mechanics of that to know if it would be helpful.
> >  > 
> >  > Chris is probably more up-to-date here, but I don't believe the current 
> >  > ECHO design looks like a funny PSK.
> > 
> >  That's right -- it's just another extension in the outer CH. 
> 
> I was thinking about the ECHO design from a forward/backward binding 
> perspective. 
> I think we should make the smallest number of changes to the key 
> schedule possible that will cover all possible future use cases, so an 
> overall consistent approach would be ideal. 
> If the WG doesn't adopt a key schedule extension draft (either mine, 
> draft-Stebila, or some other one) then this looks like the strongest 
> choice.

The ECHO design presented in Singapore doesn't require any key schedule modification. It tunnels an entire encrypted CH inside an outer CH. Servers pick one and use that for the remainder of the handshake.

I'm inclined to agree with David on this one. I don't think this additional label is necessary.

Best,
Chris

> 
> > 
> >  Best,
> >  Chriss
> > 
> >  > > Something that would allow for a consistent naming in the future would be my preference, because just as "imp binder" doesn't preclude "imp r binder", using "imp e binder" doesn't preclude us never adopting "imp r binder".
> >  > > I vaguely remember discussing whether the longer name would tip us into an extra hash invocation at the last IETF, and concluding that it didn't, although I'd have to double check that. 
> >  > 
> >  > Of course. Yeah, I think the more pertinent question is whether "imp r 
> >  > binder" is actually a thing.
> >  > > Regards,
> >  > > 
> >  > > Jonathan 
> >  > > 
> >  > > On Mon, 24 Feb 2020, 22:23 David Benjamin,  wrote:
> >  > >> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland  wrote:
> >  > >>> Just looking at this again, it might be better to make a slightly different tweak to the key schedule.
> >  > >>> Instead of:
> >  > >>> 0
> >  > |
> >  > v
> >  > PSK -> HKDF-Extract = Early Secret
> >  > |
> >  > +-----> Derive-Secret(., "ext binder"
> >  > | | "res binder"
> >  > | | "imp binder", "")
> >  > | = binder_key v
> >  > >>> 
> >  > >>> We should do:
> >  > >>> 
> >  > >>> 0
> >  > |
> >  > v
> >  > PSK -> HKDF-Extract = Early Secret
> >  > |
> >  > +-----> Derive-Secret(., "ext binder"
> >  > | | "res binder"
> >  > | | "imp e binder" 
> >  > | | "imp r binder", "")
> >  > | = binder_key v
> >  > >>> or at least:
> >  > >>> 0
> >  > |
> >  > v
> >  > PSK -> HKDF-Extract = Early Secret
> >  > |
> >  > +-----> Derive-Secret(., "ext binder"
> >  > | | "res binder"
> >  > | | "imp e binder", "")
> >  > | = binder_key v
> >  > >>> 
> >  > >>> 
> >  > >>> Just so that we can distinguish between external imported binders and resumed imported binders, should we at some point decide to do both. 
> >  > >> 
> >  > >> I may just be confused, but what would a resumed imported binder mean? I see this mechanism as largely a bugfix for TLS 1.3 external PSKs, rather than a new kind of adjective describing PSKs.
> >  > >> 
> >  > >> ("imp binder" also doesn't preclude "imp r binder" later if we later define something which needs it, but I'm confused what the concept even would be.)
> >  > >> 
> >  > >> David
> >  > >>> On Mon, 24 Feb 2020 at 20:50, Christopher Wood  wrote:
> >  > >>>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
> >  > >>>> > 
> >  > >>>> > 
> >  > >>>> > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla  wrote:
> >  > >>>> > > 
> >  > >>>> > > 
> >  > >>>> > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre  wrote:
> >  > >>>> > >> Hi,
> >  > >>>> > >> 
> >  > >>>> > >> I'm not sure how violations of these requirements would result in poor interoperability:
> >  > >>>> > >> 
> >  > >>>> > >> Clients which import external keys TLS MUST NOT use these keys for
> >  > >>>> > >> any other purpose. Moreover, each external PSK MUST be associated
> >  > >>>> > >> with at most one hash function.
> >  > >>>> > >> 
> >  > >>>> > >> These seem like aspirational security goals. It would be better to describe the consequences of violating these conditions.
> >  > >>>> > > 
> >  > >>>> > > I don't agree. They are requirements in order to be able to make the assertions we want to make about the security of the protocol.
> >  > >>>> > > 
> >  > >>>> > > This is consistent with the following text of RFC 2119 S 6
> >  > >>>> > > ".. or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) "
> >  > >>>> > > 
> >  > >>>> > > I don't think it would be unreasonable.to explain the reason for these, though this is already a requirement of 8446 S 4.2.11 (though without justification).
> >  > >>>> > 
> >  > >>>> > I think that interpretation of 2119 is a stretch, but your idea to add 
> >  > >>>> > an explanation while keeping the 2119 terms addresses my concern. At 
> >  > >>>> > the very least, the draft should note this is already a requirement of 
> >  > >>>> > 8446.
> >  > >>>> 
> >  > >>>> That seems perfectly reasonable! We can point to the security considerations to clarify the "single hash function" requirement, and we can note cross protocol attack deterrence for the other claim. Would that suffice? If not, can you please recommend text?
> >  > >>>> 
> >  > >>>> Thanks,
> >  > >>>> Chris
> >  > >>>> 
> >  > >>>> _______________________________________________
> >  > >>>> 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 Fri Feb 28 08:09:32 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652413A1A7B for ; Fri, 28 Feb 2020 08:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Level: 
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 0xAt4IJnUUrO for ; Fri, 28 Feb 2020 08:09:27 -0800 (PST)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47E63A07B8 for ; Fri, 28 Feb 2020 08:09:26 -0800 (PST)
Received: by mail-pg1-x534.google.com with SMTP id h8so1732887pgs.9 for ; Fri, 28 Feb 2020 08:09:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/IRq/LskjTyw6K91EAQBzehEYxDNjTHcAlBvUXsqces=; b=Dw/0M6qELKR/D2P1kp7gQg+JFpvfWhIjjm+f3QXaH+j+hskATyLTKuSHakQ//QTiiu MCBDcXzuPm4wQiZfsRjmUehbOByLNPnfUgL85RGWDYU40zLNudNqGzNIztsQZU9mcim7 8Mdb+CTbQykKISNelr1Vx3ylpmS15+8dDUAw8=
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=/IRq/LskjTyw6K91EAQBzehEYxDNjTHcAlBvUXsqces=; b=L99R4PLr1EAf5lslWfIy3GVdz/prVcLG0ScvfilzAhXmYcZBqiChp6y+wzXIbZh9Jk ohNs8JXiiYI9Ih2W6OS16Bc9v2601uSh4DIXQdCH620fhWvtksABB2foWzR/LEYqX/qb 95fTFQhKMpdCnqounZJ3JEX2MSnq7kTwlu/QcREKVXhl+tL7Dmvs1S+IlwUxJgv+ioFl J2LEoEK0KYGITzi9POrkCpsdrZxjoTjiqpaY8mFELDiUbd7r4TyEHQVDx5F49ObV9/ZL mh5ja6ZCeZYHWeNqzqn668KJFpBO6BnjE72ZsYxmf7TnSoD3EqcBGX9Xo4z9VRiZg/zS GPig==
X-Gm-Message-State: APjAAAW8bpaeXrIRY5I48wOkhBjchwCuvf2kujcLNNvFw7PhW2XZ+s/t rsj5JIqw07cPTuVESZev5Nxds555P8KormzOSGApGDo=
X-Google-Smtp-Source: APXvYqwUjlASbM0hMRvoUbrL+eDRY7CFlkbqk/CiVZ/MWJE18TbTuDTwXlUbwPLjm/AjIQ31fOVENJbm9wQTAw+rbXc=
X-Received: by 2002:a63:e5d:: with SMTP id 29mr5281535pgo.124.1582906165862; Fri, 28 Feb 2020 08:09:25 -0800 (PST)
MIME-Version: 1.0
References:     <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>     <75b70352-9cc5-4aa1-9cca-42f37fe615d2@www.fastmail.com> 
In-Reply-To: 
From: David Benjamin 
Date: Fri, 28 Feb 2020 11:09:09 -0500
Message-ID: 
To: Jonathan Hoyland 
Cc: Christopher Wood , "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000bb275d059fa50fe6"
Archived-At: 
Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 16:09:30 -0000

--000000000000bb275d059fa50fe6
Content-Type: text/plain; charset="UTF-8"

On Fri, Feb 28, 2020 at 10:58 AM Jonathan Hoyland <
jonathan.hoyland@gmail.com> wrote:

> On Fri, 28 Feb 2020 at 04:49, Christopher Wood 
> wrote:
>
>> On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
>> > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland
>> >  wrote:
>> > > This would be for cases where we want to inject extra context into a
>> resumption.
>> > > That would be anything that changes an authentication property, so
>> for example if you wanted to include some agreement on the status of a
>> post-handshake auth or Exported Authenticator.
>> > >
>> > > So for example imagine I had a session during which I received an EA
>> and when I came to resume that session I wished to indicate that I was
>> still willing to accept the EA.
>> > > I would offer a special PSK and inject some extra material into the
>> handshake*, and if the server was able / willing to agree to this it would
>> select the PSK.
>> > > I could also offer a PSK with no extra injected material, as a
>> fallback, and request the EA again.
>> > >
>> > > * This would only affect the binder for the PSK in the ClientHello.
>> >
>> > I'm still not following. If you're resuming, this is a PSK issued from
>> > a NewSessionTicket, in which case this isn't an imported PSK at all.
>> > It's a resumption PSK and uses "res binder". If we needed to negotiate
>> > variations on a resumption, this importer mechanism wouldn't give us a
>> > way to express that anyway. I expect we'd instead lean on some
>> > combination of multiple tickets, NewSessionTicket extensions, and plain
>> > ClientHello extensions. But maybe I'm still not understanding the
>> > scenario.
>>
> The security of combinations of tickets is non-trivial to reason about
> (though not impossible), in the same way as Exported Authenticators (which
> makes sense given that EAs would be a reason to do this).
> I'll have to give some thought to a compelling use case, but I just like
> the option for consistency.
> Then again it is said "A foolish consistency is the hobgoblin of little
> minds [...]", so ...
>

Well, if we never end up adding "imp r binder", then the current spelling
is more consistent. If we later add "imp r binder", then your proposed
spelling is more consistent. If we later add "imp r binder" but spell it
"xyz binder", then I guess the current spelling is more consistent.

The label values don't *actually* matter so this is all aesthetics at this
point. My assertion is that if we have clear reason to believe we'll add
"imp r binder", then "imp e binder" seems reasonable. If we don't have a
reason to believe we will, let's just leave it as is. Either way, it's
probably not worth expending too much effort on it. :-)


> > > Another potential use would be the binding for ECHO, although I don't
>> have a clear enough picture of the precise mechanics of that to know if it
>> would be helpful.
>> >
>> > Chris is probably more up-to-date here, but I don't believe the current
>> > ECHO design looks like a funny PSK.
>>
>> That's right -- it's just another extension in the outer CH.
>>
>
> I was thinking about the ECHO design from a forward/backward binding
> perspective.
> I think we should make the smallest number of changes to the key schedule
> possible that will cover all possible future use cases, so an overall
> consistent approach would be ideal.
> If the WG doesn't adopt a key schedule extension draft (either mine,
> draft-Stebila, or some other one) then this looks like the strongest choice.
>
>
>> Best,
>> Chriss
>>
>> > > Something that would allow for a consistent naming in the future
>> would be my preference, because just as "imp binder" doesn't preclude "imp
>> r binder", using "imp e binder" doesn't preclude us never adopting "imp r
>> binder".
>> > > I vaguely remember discussing whether the longer name would tip us
>> into an extra hash invocation at the last IETF, and concluding that it
>> didn't, although I'd have to double check that.
>> >
>> > Of course. Yeah, I think the more pertinent question is whether "imp r
>> > binder" is actually a thing.
>> > > Regards,
>> > >
>> > > Jonathan
>> > >
>> > > On Mon, 24 Feb 2020, 22:23 David Benjamin, 
>> wrote:
>> > >> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <
>> jonathan.hoyland@gmail.com> wrote:
>> > >>> Just looking at this again, it might be better to make a slightly
>> different tweak to the key schedule.
>> > >>> Instead of:
>> > >>>                 0
>> >                 |
>> >                 v
>> >       PSK ->  HKDF-Extract = Early Secret
>> >                 |
>> >                 +-----> Derive-Secret(., "ext binder"
>> >                 |                      | "res binder"
>> >                 |                      | "imp binder", "")
>> >                 |                     = binder_key                v
>> > >>>
>> > >>> We should do:
>> > >>>
>> > >>>                 0
>> >                 |
>> >                 v
>> >       PSK ->  HKDF-Extract = Early Secret
>> >                 |
>> >                 +-----> Derive-Secret(., "ext binder"
>> >                 |                      | "res binder"
>> >                 |                      | "imp e binder"
>> > |                      | "imp r binder", "")
>> >                 |                     = binder_key                v
>> > >>> or at least:
>> > >>>                 0
>> >                 |
>> >                 v
>> >       PSK ->  HKDF-Extract = Early Secret
>> >                 |
>> >                 +-----> Derive-Secret(., "ext binder"
>> >                 |                      | "res binder"
>> >                 |                      | "imp e binder", "")
>> >                 |                     = binder_key                v
>> > >>>
>> > >>>
>> > >>> Just so that we can distinguish between external imported binders
>> and resumed imported binders, should we at some point decide to do both.
>> > >>
>> > >> I may just be confused, but what would a resumed imported binder
>> mean? I see this mechanism as largely a bugfix for TLS 1.3 external PSKs,
>> rather than a new kind of adjective describing PSKs.
>> > >>
>> > >> ("imp binder" also doesn't preclude "imp r binder" later if we later
>> define something which needs it, but I'm confused what the concept even
>> would be.)
>> > >>
>> > >> David
>> > >>> On Mon, 24 Feb 2020 at 20:50, Christopher Wood 
>> wrote:
>> > >>>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
>> > >>>>  >
>> > >>>>  >
>> > >>>>  > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla 
>> wrote:
>> > >>>>  > >
>> > >>>>  > >
>> > >>>>  > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre 
>> wrote:
>> > >>>>  > >> Hi,
>> > >>>>  > >>
>> > >>>>  > >> I'm not sure how violations of these requirements would
>> result in poor interoperability:
>> > >>>>  > >>
>> > >>>>  > >> Clients which import external keys TLS MUST NOT use these
>> keys for
>> > >>>>  > >> any other purpose. Moreover, each external PSK MUST be
>> associated
>> > >>>>  > >> with at most one hash function.
>> > >>>>  > >>
>> > >>>>  > >> These seem like aspirational security goals. It would be
>> better to describe the consequences of violating these conditions.
>> > >>>>  > >
>> > >>>>  > > I don't agree. They are requirements in order to be able to
>> make the assertions we want to make about the security of the protocol.
>> > >>>>  > >
>> > >>>>  > > This is consistent with the following text of RFC 2119 S 6
>> > >>>>  > > ".. or to limit behavior which has potential for causing harm
>> (e.g., limiting retransmisssions) "
>> > >>>>  > >
>> > >>>>  > > I don't think it would be unreasonable.to explain the reason
>> for these, though this is already a requirement of 8446 S 4.2.11 (though
>> without justification).
>> > >>>>  >
>> > >>>>  > I think that interpretation of 2119 is a stretch, but your idea
>> to add
>> > >>>>  > an explanation while keeping the 2119 terms addresses my
>> concern. At
>> > >>>>  > the very least, the draft should note this is already a
>> requirement of
>> > >>>>  > 8446.
>> > >>>>
>> > >>>>  That seems perfectly reasonable! We can point to the security
>> considerations to clarify the "single hash function" requirement, and we
>> can note cross protocol attack deterrence for the other claim. Would that
>> suffice? If not, can you please recommend text?
>> > >>>>
>> > >>>>  Thanks,
>> > >>>>  Chris
>> > >>>>
>> > >>>>  _______________________________________________
>> > >>>>  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
>>
>

--000000000000bb275d059fa50fe6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Fri, Feb 28, 2020 at 10:58 AM Jonathan=
 Hoyland <jonathan.hoyland=
@gmail.com> wrote:
On Fri, 28 Feb 2020 at 04:49, Christopher Wood <caw@heapingbits.net> wrote:
<=
/div>

On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:

> On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland 

> <jo=
nathan.hoyland@gmail.com> wrote:

> > This would be for cases where we want to inject extra context int=
o a resumption. 

> > That would be anything that changes an authentication property, s=
o for example if you wanted to include some agreement on the status of a po=
st-handshake auth or Exported Authenticator.

> > 

> > So for example imagine I had a session during which I received an=
 EA and when I came to resume that session I wished to indicate that I was =
still willing to accept the EA.

> > I would offer a special PSK and inject some extra material into t=
he handshake*, and if the server was able / willing to agree to this it wou=
ld select the PSK. 

> > I could also offer a PSK with no extra injected material, as a fa=
llback, and request the EA again. 

> > 

> > * This would only affect the binder for the PSK in the ClientHell=
o. 

> 

> I'm still not following. If you're resuming, this is a PSK iss=
ued from 

> a NewSessionTicket, in which case this isn't an imported PSK at al=
l. 

> It's a resumption PSK and uses "res binder". If we neede=
d to negotiate 

> variations on a resumption, this importer mechanism wouldn't give =
us a 

> way to express that anyway. I expect we'd instead lean on some 
> combination of multiple tickets, NewSessionTicket extensions, and plai=
n 

> ClientHello extensions. But maybe I'm still not understanding the =


> scenario.
The security of combinations of tickets=
 is non-trivial to reason about (though not impossible), in the same way as=
 Exported Authenticators (which makes sense given that EAs would be a reaso=
n to do this).
I'll have to give some thought to a compelling=
 use case, but I just like the option for consistency.=C2=A0
Then=
 again it is said "A foolish consistency is the hobgoblin of little mi=
nds [...]", so ...

W=
ell, if we never end up adding "imp r binder", then the current s=
pelling is more consistent. If we later add "imp r binder", then =
your proposed spelling is more consistent. If we later add "imp r bind=
er" but spell it "xyz binder", then I guess the current spel=
ling is more consistent.

The label values don'=
t=C2=A0actually=C2=A0matter so this is all aesthetics at this point.=
 My assertion is that if we have clear reason to believe we'll add &quo=
t;imp r binder", then "imp e binder" seems reasonable. If we=
 don't have a reason to believe we will, let's just leave it as is.=
 Either way, it's probably not worth expending too much effort on it. :=
-)
=C2=A0
=


> > Another potential use would be the binding for ECHO, although I d=
on't have a clear enough picture of the precise mechanics of that to kn=
ow if it would be helpful.

> 

> Chris is probably more up-to-date here, but I don't believe the cu=
rrent 

> ECHO design looks like a funny PSK.



That's right -- it's just another extension in the outer CH. 

I was thinking about the ECHO design from a forwa=
rd/backward binding perspective.=C2=A0
I think=C2=A0we should make the =
smallest number of changes to the key schedule possible that will cover all=
 possible future use cases, so an overall consistent approach would be idea=
l.=C2=A0
If the WG doesn't adopt a key schedule ex=
tension draft (either mine, draft-Stebila, or some other one) then this loo=
ks like the strongest choice.




Best,

Chriss



> > Something that would allow for a consistent naming in the future =
would be my preference, because just as "imp binder" doesn't =
preclude "imp r binder", using "imp e binder" doesn'=
;t preclude us never adopting "imp r binder".

> > I vaguely remember discussing whether the longer name would tip u=
s into an extra hash invocation at the last IETF, and concluding that it di=
dn't, although I'd have to double check that. 

> 

> Of course. Yeah, I think the more pertinent question is whether "=
imp r 

> binder" is actually a thing.

> > Regards,

> > 

> > Jonathan 

> > 

> > On Mon, 24 Feb 2020, 22:23 David Benjamin, <davidben@chromium.org> wrot=
e:

> >> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <jonathan.hoyland@g=
mail.com> wrote:

> >>> Just looking at this again, it might be better to make a =
slightly different tweak to the key schedule.

> >>> Instead of:

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A00

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v

>=C2=A0 =C2=A0 =C2=A0 =C2=A0PSK ->=C2=A0 HKDF-Extract =3D Early Secre=
t

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----->=
; Derive-Secret(., "ext binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;res binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;imp binder", "")

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D bi=
nder_key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v

> >>> 

> >>> We should do:

> >>> 

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A00

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v

>=C2=A0 =C2=A0 =C2=A0 =C2=A0PSK ->=C2=A0 HKDF-Extract =3D Early Secre=
t

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----->=
; Derive-Secret(., "ext binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;res binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;imp e binder"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 

> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 | "imp r binder", "")

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D bi=
nder_key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v

> >>> or at least:

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A00

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v

>=C2=A0 =C2=A0 =C2=A0 =C2=A0PSK ->=C2=A0 HKDF-Extract =3D Early Secre=
t

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----->=
; Derive-Secret(., "ext binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;res binder"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | &qu=
ot;imp e binder", "")

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D bi=
nder_key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v

> >>> 

> >>> 

> >>> Just so that we can distinguish between external imported=
 binders and resumed imported binders, should we at some point decide to do=
 both. 

> >> 

> >> I may just be confused, but what would a resumed imported bin=
der mean? I see this mechanism as largely a bugfix for TLS 1.3 external PSK=
s, rather than a new kind of adjective describing PSKs.

> >> 

> >> ("imp binder" also doesn't preclude "imp r=
 binder" later if we later define something which needs it, but I'=
m confused what the concept even would be.)

> >> 

> >> David

> >>> On Mon, 24 Feb 2020 at 20:50, Christopher Wood <caw@heapingbits.net&=
gt; wrote:

> >>>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
> >>>>=C2=A0 > 

> >>>>=C2=A0 > 

> >>>>=C2=A0 > On Fri, Feb 21, 2020 at 8:35 AM Eric Resco=
rla <ekr@rtfm.com&=
gt; wrote:

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > On Thu, Feb 20, 2020 at 7:08 PM Rob S=
ayre <sayrer@gmail=
.com> wrote:

> >>>>=C2=A0 > >> Hi,

> >>>>=C2=A0 > >> 

> >>>>=C2=A0 > >> I'm not sure how violations o=
f these requirements would result in poor interoperability:

> >>>>=C2=A0 > >> 

> >>>>=C2=A0 > >> Clients which import external key=
s TLS MUST NOT use these keys for

> >>>>=C2=A0 > >> any other purpose. Moreover, each=
 external PSK MUST be associated

> >>>>=C2=A0 > >> with at most one hash function.
> >>>>=C2=A0 > >> 

> >>>>=C2=A0 > >> These seem like aspirational secu=
rity goals. It would be better to describe the consequences of violating th=
ese conditions.

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > I don't agree. They are requireme=
nts in order to be able to make the assertions we want to make about the se=
curity of the protocol.

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > This is consistent with the following=
 text of RFC 2119 S 6

> >>>>=C2=A0 > > ".. or to limit behavior which h=
as potential for causing harm (e.g., limiting retransmisssions) "

> >>>>=C2=A0 > > 

> >>>>=C2=A0 > > I don't think it would be unreasonab=
le.to explain the reason for these, though this is already a requiremen=
t of 8446 S 4.2.11 (though without justification).

> >>>>=C2=A0 > 

> >>>>=C2=A0 > I think that interpretation of 2119 is a s=
tretch, but your idea to add 

> >>>>=C2=A0 > an explanation while keeping the 2119 term=
s addresses my concern. At 

> >>>>=C2=A0 > the very least, the draft should note this=
 is already a requirement of 

> >>>>=C2=A0 > 8446.

> >>>> 

> >>>>=C2=A0 That seems perfectly reasonable! We can point t=
o the security considerations to clarify the "single hash function&quo=
t; requirement, and we can note cross protocol attack deterrence for the ot=
her claim. Would that suffice? If not, can you please recommend text?

> >>>> 

> >>>>=C2=A0 Thanks,

> >>>>=C2=A0 Chris

> >>>> 

> >>>>=C2=A0 _______________________________________________=


> >>>>=C2=A0 TLS mailing list

> >>>> TLS=
@ietf.org

> >>>> https://www.ietf.org/mailman/listinfo=
/tls

> >>>=C2=A0 _______________________________________________

> >>>=C2=A0 TLS mailing list

> >>> TLS@iet=
f.org

> >>> https://www.ietf.org/mailman/listinfo/tls=







--000000000000bb275d059fa50fe6--


From nobody Fri Feb 28 08:23:58 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33B23A1B36 for ; Fri, 28 Feb 2020 08:23:56 -0800 (PST)
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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=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 7TZUDd6UU-3h for ; Fri, 28 Feb 2020 08:23:52 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A483A1B1D for ; Fri, 28 Feb 2020 08:23:51 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id 11so3514395qkd.1 for ; Fri, 28 Feb 2020 08:23:51 -0800 (PST)
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=T3STduNHxCb0/yRENUy+EbfK0f7wZnjk5NrK1TIjMt4=; b=V0GABeGVjoZ+M5RNbq4iWSvJclbf2217ICUaG1UQcFN1L5BnZVWpRaUp4fEfzIIWvI dExjk5xhKRv4OAcsGF2yXU5WuWlcMO5MQ2LiX4EL7jiI4mAcpC+67/9teNkDvV/DZpkg ZkIG52A4zna/DRHVWhNVxzXgoP323sHUVELmc=
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=T3STduNHxCb0/yRENUy+EbfK0f7wZnjk5NrK1TIjMt4=; b=HGuU7BxLxizezcC+vlDiJWFia8OQEAy/BFCnc1nxU8dznZHOrmfoQG30KA+7AD1VkS EWXeVmzdIn3QbAZ0F47ShY9BIPUK60MglWj5uYb3rw3KZpIEogEL/cNXaMrR2FfuA6KM gMcHCnIHEoSoB916s2qdGINm6F30GgpgaJX4/oZ0BwoVhU9ltC3OyhHstXNnJJia/BTp QVlDMOR1Sj4IS7TjDdT6OsGvY0yFRhG7nddnDfg+2ppNAKCsnZai/uV33MnXKTOJp2Vq JTtMZa1/NyfOaT9yZMevESXRkdKzuS30PYCLqGbXcHo0IqO6XzhoSUNbKwJDIK2H8Lhi mXhQ==
X-Gm-Message-State: APjAAAU+ZCxUQwVWVTkWt/k0c7Z1iahA50JAMV16v1b91DfhcOIkdbuf 1IVd0yk8yy3aWOvsUxhfI6Fm0TyU6EQ=
X-Google-Smtp-Source: APXvYqzrzuMxFsM1f/6mvoBlZ3wXF540DeU2tkNXvM+/QADzQB8OfXmKcZmLvHM1ZN+aistf/wLiPA==
X-Received: by 2002:a37:48c4:: with SMTP id v187mr5356755qka.198.1582907030324;  Fri, 28 Feb 2020 08:23:50 -0800 (PST)
Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id l19sm5265228qkl.3.2020.02.28.08.23.49 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 08:23:49 -0800 (PST)
From: Sean Turner 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com>
Date: Fri, 28 Feb 2020 11:23:48 -0500
To: TLS List 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 16:23:57 -0000

Hi!

Based on Tommy Pauly=E2=80=99s suggestion [0], Joe and I believe that =
the best way for us to get to the place where we can declare rough =
consensus is to:

* Consider the PR: [1].  This PR explains that when racing connections, =
the client will not necessarily know the number of tickets it will =
=E2=80=9Cconsume=E2=80=9D, so it should either have enough tickets for =
two subsequent handshake resumptions; or else use fewer tickets but =
potentially run out.

* Consider adoption of an individual draft that describes an extension =
for hinting ticket reuse. This draft will also discuss the use cases =
around ticket reuse.

Obviously, the rationale here is to progress this relatively simple =
draft, but allow the reuse discussion to continue. Again, we believe =
this allows us to declare rough consensus and avoid any deadlocks.

Please let us know your thoughts on the PR, which (assuming the PR gets =
consensus) we plan to ask the authors to merge sometime around 6 March.

Thanks,
Joe and Sean

[0] =
https://mailarchive.ietf.org/arch/msg/tls/fOmUYve5DLomjx3-Df9xQy0bocg/
[1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/17=


From nobody Fri Feb 28 14:39:12 2020
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 9A3AD3A1F8A; Fri, 28 Feb 2020 14:35:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: kaduk@mit.edu, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158292932461.19931.5515991597686791012@ietfa.amsl.com>
Date: Fri, 28 Feb 2020 14:35:24 -0800
Archived-At: 
Subject: [TLS] tls - Requested sessions have been scheduled for IETF 107
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is the mailing list 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 Feb 2020 22:35:31 -0000

Dear Christopher Wood,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


    tls Session 1 (1:00 requested)
    Monday, 23 March 2020, Afternoon Session III 1810-1910
    Room Name: Plaza B/C size: 300
    ---------------------------------------------
    tls Session 2 (2:00 requested)
    Friday, 27 March 2020, Morning Session I 1000-1200
    Room Name: Regency C size: 300
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/107/sessions/tls.ics

Request Information:


---------------------------------------------------------
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Christopher Wood

Number of Sessions: 2
Length of Session(s):  2 Hours, 1 Hour
Number of Attendees: 120
Conflicts to Avoid: 
 Chair Conflict: pearg git mls emu
 Technology Overlap: cfrg dprive dnsop lake
 Key Participant Conflict: quic httpbis taps secdispatch saag wpack


People who must be present:
  Eric Rescorla
  Rich Salz
  Sean Turner
  Joseph A. Salowey
  Yoav Nir
  Benjamin Kaduk
  Christopher A. Wood
  Nick Sullivan

Resources Requested:

Special Requests:
  
---------------------------------------------------------



From nobody Fri Feb 28 14:41:28 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0123A1F20 for ; Fri, 28 Feb 2020 14:41:06 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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 0P5MkzYm8L7o for ; Fri, 28 Feb 2020 14:41:05 -0800 (PST)
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 F25BD3A1FB6 for ; Fri, 28 Feb 2020 14:41:03 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01SMbDMr022007; Fri, 28 Feb 2020 22:41:03 GMT
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-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=7TfAo/FS8CdMMJx3MfsxRk2ukND/xMi0jTDpkrESjvE=; b=fSwerumedbyrco3z4zmF+kttVcSvgVUq9s54xYoBV4o8wDKepdGR/dRaLQt0FF291zrf kLsQ5I/aeN0uaTz4G6lzFgR03a2l/5kuUZFfvqsRKT13tyzMp46vudc093+s1BnBcTXA MsroV1QoK8p4fpG1tqdMQ0aJxsJJGk22BN5ofhvHuuL7LQumQcE/ltIaW1onbz20ShzZ oEJdS9boYuctS58XySagvMtZ4RMd9sZwTBGTo0Ze9b89OxxrG28MKsYn6P7VqYR5QtV4 akVsXZFyrGeEncaPaUJubE+BZVAQ/SyW6Zu+Wc5HA2YVosmI46XF0qKghCazu2ZUR3Js pg== 
Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2yepyevw0w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Feb 2020 22:41:03 +0000
Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01SMWSo6026691; Fri, 28 Feb 2020 17:41:02 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint6.akamai.com with ESMTP id 2yepvp8wxw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 28 Feb 2020 17:41:01 -0500
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.1497.2; Fri, 28 Feb 2020 17:41:01 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Fri, 28 Feb 2020 17:41:01 -0500
From: "Salz, Rich" 
To: Sean Turner , "tls@ietf.org" 
Thread-Topic: [TLS] progressing draft-ietf-tls-ticket-request
Thread-Index: AQHV7lOJFpEf+o2rqECT2Bk6BH36eKgxM6UA
Date: Fri, 28 Feb 2020 22:41:00 +0000
Message-ID: 
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com>
In-Reply-To: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.22.0.200209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.112.176]
Content-Type: text/plain; charset="utf-8"
Content-ID: <39B14A7374D5D54E9C497DE9AAE65454@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-28_08:2020-02-28, 2020-02-28 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=735 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002280162
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-28_08:2020-02-28, 2020-02-28 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 phishscore=0 spamscore=0 priorityscore=1501 suspectscore=0 clxscore=1015 malwarescore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=733 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002280162
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 22:41:13 -0000

Q2FuIHdlIG1vZGlmeSB0aGUgZXhpc3RpbmcgZHJhZnQgdG8gc2F5IDAtMjAwIHRpY2tldHMgbm90
IDAtMjU1Pw0KDQogDQoNCg==


From nobody Fri Feb 28 15:05:32 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1933A09D5 for ; Fri, 28 Feb 2020 15:05:27 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=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 Xdl_vJ9wChLU for ; Fri, 28 Feb 2020 15:05:19 -0800 (PST)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0D13A0D1A for ; Fri, 28 Feb 2020 15:03:21 -0800 (PST)
Received: by mail-qk1-x731.google.com with SMTP id e16so4670651qkl.6 for ; Fri, 28 Feb 2020 15:03:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v4/Ow3Fjy8HY2tuC0cdwdI/Ym4zG14tWzKfO2XAcHgw=; b=dFU0zuePqnSiNaSvIlSWEmjGVa7LnQPGD0Rh1CNzk2/odekIf6HoyuNCATf0cZaC8u xrwHAOnu6y9d6UrdREkow7N5SGnXQ93JQIqfF6draDkQu4QRLPQcaaQ0uqDsCTpR3CKz wf2ZB8UEzZyxTfJ1c1Ar7iD8wVk/n61hgK8KI=
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=v4/Ow3Fjy8HY2tuC0cdwdI/Ym4zG14tWzKfO2XAcHgw=; b=dBkg1jarV+X/TfKkUtr1ZG2++zU7bAbNoOVUtPV7MJqjIgRs9uFMF8PLYYoihPPl4s 8Wwp5/i75/lRbK41uRPeYVhRtpn3mxc+O3pq2GAmY3GOmr4YesOu1UjrszCQGuRgz9iZ 3h9xbEqzMrKVjj224+CK/AT56rjXUoCV06ExFG5jjOIAsNWosD05EJQ85ftbdtz8j5uI mZ8ICgsuyIU7PgVkJv+h11QnT8xcLaGa/cR1nAOJ8gD96FeTR4lvYX4WlfntiLsxGFTW G+X1H+HZNm8XiqcE+Zbw41YcnnGMB4uRNlQp6YXuF5e4rEjDPq/5eVKmEvalSaF1VZQs JUCw==
X-Gm-Message-State: APjAAAXI7hN1HOU2HlQKNJ+LKSW1LhuPpsBQIeMMYIuoO3qMVLXUX0g1 CJCQkeLVkvZvtIPIdU2SYMXktOugYWSlYOYpCSS/eXfxSBk=
X-Google-Smtp-Source: APXvYqwNmAMWbCalZkFjjeGpSxEa0CmM2/iEDdvlXegFgCrM+dQribDV0FqsZd+XjTSn9t+4LXeEKG7sGuWps3nTbm4=
X-Received: by 2002:a37:9e84:: with SMTP id h126mr5438996qke.336.1582930999582;  Fri, 28 Feb 2020 15:03:19 -0800 (PST)
MIME-Version: 1.0
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com>
In-Reply-To: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com>
From: Watson Ladd 
Date: Fri, 28 Feb 2020 15:03:08 -0800
Message-ID: 
To: Sean Turner 
Cc: TLS List 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 23:05:28 -0000

The PR looks good to me.


From nobody Sat Feb 29 01:17:35 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9721B3A0CF0 for ; Sat, 29 Feb 2020 01:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 4ydQ7iaqlsfP for ; Sat, 29 Feb 2020 01:17:31 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0473B3A0CEF for ; Sat, 29 Feb 2020 01:17:29 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id C0FC21AABFB; Sat, 29 Feb 2020 04:17:28 -0500 (EST)
Date: Sat, 29 Feb 2020 04:17:28 -0500
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20200229091728.GY7977@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 09:17:34 -0000

On Fri, Feb 28, 2020 at 11:23:48AM -0500, Sean Turner wrote:

> * Consider the PR: [1].  This PR explains that when racing connections, the client will not necessarily know the number of tickets it will “consume”, so it should either have enough tickets for two subsequent handshake resumptions; or else use fewer tickets but potentially run out.
> 

My sincere and deep apologies about tardiness in drafting my PR, it is
now done.  This builds on the above PR, but also addresses more fully
happy eyeballs, etc. by observing that even clients that never reuse
ticket can benefit from separate counts for resumption vs. full
handshakes, and can't generally predict which they'll get.

https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18

-- 
    Viktor.


From nobody Sat Feb 29 12:41:01 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3848B3A12FB for ; Sat, 29 Feb 2020 12:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 211qRoj4khJC for ; Sat, 29 Feb 2020 12:40:57 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 C92323A12E2 for ; Sat, 29 Feb 2020 12:40:56 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id e18so7248215ljn.12 for ; Sat, 29 Feb 2020 12:40:56 -0800 (PST)
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=X7v9L3ARb+AEtdUnaDTUQegytVjV2JAI9aG9FEC516U=; b=eO3amBRCtMXqC44L8d28MJYBtAK52rrH+8Kxq7jRWlJFTN6RRFtcD6pJxGsc4HEq/d r/X9m+ZaEAafL78fnjog+vfiHl3TbidKh7OgNNnAp0nMhqizrEKzOhAotP1EifoNAJBz bAWB2YTk0LeaF8VCNC3bftDOFTptkD1wPg65DZSXUEJB8Cj2StJbZPgWIamJX725jkwg is/vXIo40qrehtkeKu4Yw7Zq4ARBZoP22gh80SASDiiPVZnN13yPUwVghwm7ebj4CyR+ sFd2G8DmVrYTGBabEHDRFyZ1oWa6r5ZPCWRav+op6/ZGeYwqfmFN4Up/bltWIUSTtMyL iRJQ==
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=X7v9L3ARb+AEtdUnaDTUQegytVjV2JAI9aG9FEC516U=; b=CcJNfKXAekUikcvJBqhTevX4tvYL+s5T6bYLEqjiW4CSq0xm4ovpe5eHAQl8EHOibi Q2NHuh68c+W/EqIhsCJGdwVpUKClfjc4THBhkNDiAtA2SvtJCAfxB9se1Wf2crveiGbl 9j/3jj5Z1pV4sNMvynFJZ6kFTz+0CPAavHg5unKnt0N4WxAYwh5QmGJKGrFF2C0j19vt P+ZUx+7/Yuy/LMzAXqTXWSQpu48RdyU8kGvGAG04TUwNez8QU34FmA3y6AAObhhJZgt8 HVLiy2A2ggc7cLsRzKpAoRIM1uV2W0WZo9/pZcC6hCNa1xyKbzAyHpOlw1Nd66xwJ2Wt gvhg==
X-Gm-Message-State: ANhLgQ0Ep1ie6nyaa4yRm+HagIQICAXC3SWsWjoB3ArOGTt8FqyiUE+/ WJ32nsQ7mAja/TQ5biHEv6UO9XHNJ5R/lq9LGKMzZGVN
X-Google-Smtp-Source: ADFU+vvbxIo7QuqVONlPE0jhnY3FSGRwRhHz4EGitHRi/Nl3MZYT19pLb1QlrwlJRBF+sbbbE/vJONUGKl4z1JAcnac=
X-Received: by 2002:a2e:8e31:: with SMTP id r17mr7186060ljk.211.1583008854713;  Sat, 29 Feb 2020 12:40:54 -0800 (PST)
MIME-Version: 1.0
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com> <20200229091728.GY7977@straasha.imrryr.org>
In-Reply-To: <20200229091728.GY7977@straasha.imrryr.org>
From: David Schinazi 
Date: Sat, 29 Feb 2020 12:40:43 -0800
Message-ID: 
To: "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000762c9f059fbcf85b"
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 20:40:59 -0000

--000000000000762c9f059fbcf85b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Viktor,

I like the editorial changes in your PR #18, as they do a good job of
explaining things.
However, I don't think we should add a second count in this extension.
Allowing ticket
reuse is not something we have consensus for in the WG, and I would like to
see this
discussion happen in the TLS WG, but not preventing this draft from moving
forward.

Thanks,
David

On Sat, Feb 29, 2020 at 1:18 AM Viktor Dukhovni 
wrote:

> On Fri, Feb 28, 2020 at 11:23:48AM -0500, Sean Turner wrote:
>
> > * Consider the PR: [1].  This PR explains that when racing connections,
> the client will not necessarily know the number of tickets it will
> =E2=80=9Cconsume=E2=80=9D, so it should either have enough tickets for tw=
o subsequent
> handshake resumptions; or else use fewer tickets but potentially run out.
> >
>
> My sincere and deep apologies about tardiness in drafting my PR, it is
> now done.  This builds on the above PR, but also addresses more fully
> happy eyeballs, etc. by observing that even clients that never reuse
> ticket can benefit from separate counts for resumption vs. full
> handshakes, and can't generally predict which they'll get.
>
> https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18
>
> --
>     Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--000000000000762c9f059fbcf85b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Viktor,

I like the editorial changes=
 in your PR #18, as they do a good job of explaining things.
Howe=
ver, I don't think we should add a second count in this extension. Allo=
wing ticket
reuse is not something we have consensus for in the W=
G, and I would like to see this
discussion happen in the TLS WG, =
but not preventing this draft from moving forward.

=

Thanks,
David

On Sat, Feb 29, 2020 at 1:18 AM Viktor Du=
khovni <ietf-dane@dukhovni.org=
> wrote:
=
On Fri, Feb 28, 2020 at 11:23:48AM -0500, Sean Turner wrote:



> * Consider the PR: [1].=C2=A0 This PR explains that when racing connec=
tions, the client will not necessarily know the number of tickets it will =
=E2=80=9Cconsume=E2=80=9D, so it should either have enough tickets for two =
subsequent handshake resumptions; or else use fewer tickets but potentially=
 run out.

> 



My sincere and deep apologies about tardiness in drafting my PR, it is

now done.=C2=A0 This builds on the above PR, but also addresses more fully<=
br>
happy eyeballs, etc. by observing that even clients that never reuse

ticket can benefit from separate counts for resumption vs. full

handshakes, and can't generally predict which they'll get.



https://github.com/tlswg/draft-ietf-tls=
-ticketrequest/pull/18



-- 

=C2=A0 =C2=A0 Viktor.



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--000000000000762c9f059fbcf85b--


From nobody Sat Feb 29 14:28:17 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F98F3A14D7 for ; Sat, 29 Feb 2020 14:28:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 joTXzzeLfmVZ for ; Sat, 29 Feb 2020 14:28:13 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6D53A14D6 for ; Sat, 29 Feb 2020 14:28:12 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 347F81ABC40; Sat, 29 Feb 2020 17:28:11 -0500 (EST)
Date: Sat, 29 Feb 2020 17:28:11 -0500
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20200229222811.GZ7977@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com> <20200229091728.GY7977@straasha.imrryr.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 22:28:15 -0000

On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:

> I like the editorial changes in your PR #18, as they do a good job of
> explaining things.

Thanks!  I could add a bit more text to guide client implementations on
how to update their ticket caches in response to tickets from the
server, but first wanted to see how this first cut will be received. 
And perhaps there's a risk of explaining too much.

> However, I don't think we should add a second
> count in this extension.  Allowing ticket reuse is not something we
> have consensus for in the WG, and I would like to see this discussion
> happen in the TLS WG, but not preventing this draft from moving
> forward.

But the second count is not just or even primarily for reuse, it is also
useful for the non-reuse case as explained in the new text.  The fact
that it then possible to cleanly express reuse is a byproduct, and I
also don't mean to encourage reuse in general, but it does have
non-trivial applications, where the privacy impact is zero (no client
privacy is possible or desirable).

The TLS WG can maintain a strong focus on *enabling* privacy, and a
strong recommendation that applications need to take privacy into
account, but WITHOUT forcing pointless privacy-related counter-measures
down everybody's throat, whether you need it or not.

Ignoring the needs of market segments other than the principal one
of browser-to-website is IMHO not something that the TLS WG should
do.  The browsers are perfectly capable of not doing reuse, and
even if some misguided client erroneously offers reuse, the server
can decline.  Ticket reuse requires the coöperation of both client
and server, by which point a reasonable position to take is that
it is their choice to make.

-- 
    Viktor.


From nobody Sat Feb 29 14:57:18 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77633A153B for ; Sat, 29 Feb 2020 14:57:16 -0800 (PST)
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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=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 bbDbJgcWtMXJ for ; Sat, 29 Feb 2020 14:57:15 -0800 (PST)
Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) (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 6299F3A153C for ; Sat, 29 Feb 2020 14:57:15 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 90EC39209EA; Sat, 29 Feb 2020 22:57:14 +0000 (UTC)
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (100-96-1-27.trex.outbound.svc.cluster.local [100.96.1.27]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 04C1F920AEE; Sat, 29 Feb 2020 22:57:14 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a89.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sat, 29 Feb 2020 22:57:14 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Thread-Lonely: 15d96a07194c150b_1583017034261_1602394846
X-MC-Loop-Signature: 1583017034261:2911870688
X-MC-Ingress-Time: 1583017034261
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTP id 2CE357F476; Sat, 29 Feb 2020 14:57:10 -0800 (PST)
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=ssclDO6wqwi0/7 d10guf+CGUUKg=; b=bVI23H5l/MmFnAsBF1YQQgfdM1ZHnK1XR3azqYCR0RzHc6 4EMNwF/qd8QTir0acEDafb0uE5lS753a5HxreXU4HLZS8e0dTj63eUMnjkeHzbO3 Tx5B9ZKwJ6gjIeIxDAdrxuF18Cck+xRw1LA6X29EE1d1GOTrdGskHbQuL6TK4=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 5BC3E7F38F; Sat, 29 Feb 2020 14:57:09 -0800 (PST)
Date: Sat, 29 Feb 2020 16:57:03 -0600
X-DH-BACKEND: pdx1-sub0-mail-a89
From: Nico Williams 
To: David Schinazi 
Cc: "TLS@ietf.org" 
Message-ID: <20200229225701.GM18021@localhost>
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com> <20200229091728.GY7977@straasha.imrryr.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedruddtuddgtdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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 Feb 2020 22:57:17 -0000

On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> However, I don't think we should add a second count in this extension.
> Allowing ticket reuse is not something we have consensus for in the
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Did I miss a consensus call or something?

> WG, and I would like to see this discussion happen in the TLS WG, but
> not preventing this draft from moving forward.


Nico
-- 


From nobody Sat Feb 29 16:29:54 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C173A168A for ; Sat, 29 Feb 2020 16:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 nZWN75qjYMKL for ; Sat, 29 Feb 2020 16:29:51 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37253A1688 for ; Sat, 29 Feb 2020 16:29:50 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id s1so4499705lfd.3 for ; Sat, 29 Feb 2020 16:29:50 -0800 (PST)
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=5vjQ4s18RiJxmxmmx1Tu/CKYcGa6GfKZEl5jeqRmFXQ=; b=m0T72NvD+8KEiCXxVkIYDgWFvAYWDogFN/EEYYVUbaDFWgvDX3YUo8sk/wA/qFcIC2 5B2MdSIIdIcuFLP1U8/6pWJPwhdwTtZaRDjKy/UxXpQxoOpgCYw7L14bnhSSorars/Ic tQwcHbkgOpKWWkZbZqbijI7IcS6KYGQxNAUEIR01FN3unbfpw1O4p+1QjgouNwaNdvAG znXXnaf5/4JpzF71WWVpLC+TS4BCTtzUfHkuKwgiMVHMH2f20BG7vcokVVg9SIW4WnSx AglqIQTbaVPSMuStRf5In+cXs5rExFShYrNbnqRN49G0QUyCNwud7Rl+TnrPDGxy2gHL 6cDA==
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=5vjQ4s18RiJxmxmmx1Tu/CKYcGa6GfKZEl5jeqRmFXQ=; b=OGTKtOMsg5rJZxQh0PBi7LkTS1brXL/yy2FlrMNPV8+8Dggxp7IMwLc1V6vobhvXhD 7+0orUtZaGr4PvtlxkuZd/mM8qWVLKkhFyiT982HLUVo4MxTIcPiYkRxsJDgibn6EIwq aQot71FUkL2ZEEmlf8yF+nHmTy+BSgITK4QUUzo0blRAagUvyAhk9oY0D61hxS7FLA8d NhJlvYd6w1BpxA1/UQmuVe6hnCy3g+77v9NEhwKl0TlpU0X9yFGqXiBT3bloL4rAvi7d j4hyoe1uuxNgTchIiCtA/MNwDx60s68OUMoDQSMQFT+Z26TxgElxndtVmmy8EOn00CdZ BpVw==
X-Gm-Message-State: ANhLgQ3Brjtgb9yTyJICw1YW9tLSMv8jKPr21UrA/1uXM3n7Qxma2I4G UArhaKL8bP5XvtnEfROdcp6Fso8v0UD4NYHzQRGOD4sN
X-Google-Smtp-Source: ADFU+vuhJy+F7HWhhSr5uoXJFhwWrPGlhUVjQ4hPHH76qT287+Z3T8W96b7SODEySBTYe+rO5ad4Y6bLEtHH1d1j7dw=
X-Received: by 2002:a19:8556:: with SMTP id h83mr6669607lfd.40.1583022589059;  Sat, 29 Feb 2020 16:29:49 -0800 (PST)
MIME-Version: 1.0
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com> <20200229091728.GY7977@straasha.imrryr.org>  <20200229225701.GM18021@localhost>
In-Reply-To: <20200229225701.GM18021@localhost>
From: David Schinazi 
Date: Sat, 29 Feb 2020 16:29:38 -0800
Message-ID: 
To: Nico Williams 
Cc: "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000017a5ad059fc02b6f"
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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, 01 Mar 2020 00:29:53 -0000

--00000000000017a5ad059fc02b6f
Content-Type: text/plain; charset="UTF-8"

On Sat, Feb 29, 2020 at 2:57 PM Nico Williams  wrote:

> On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> > However, I don't think we should add a second count in this extension.
> > Allowing ticket reuse is not something we have consensus for in the
>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Did I miss a consensus call or something?
>

Hi Nico,

To clarify what I said: I meant that there has not been a consensus call
here,
and additionally I've heard that some folks would like to enable ticket
reuse,
whereas some other folks are very opposed to any kind of reuse.

In other words, I meant "we do not have consensus to allow reuse";
I did not mean "we have consensus to not allow reuse".

I'm not a TLS WG chair, I cannot judge consensus here. I was simply
noting that there indeed had not been a consensus call on this topic.

Furthermore, I still think the topic of reuse is out of scope for
draft-ietf-tls-ticket-request.

Hope this helps.
David

--00000000000017a5ad059fc02b6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sat, Feb 29, 2020 at 2:57 PM Nico Will=
iams <nico@cryptonector.com=
> wrote:
On S=
at, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:

> However, I don't think we should add a second count in this extens=
ion.

> Allowing ticket reuse is not something we have consensus for in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^



Did I miss a consensus call or something?

Hi Nico,

To clarify what I said: I meant that t=
here has not been a consensus call here,
and additionally I'v=
e heard that some folks would like to enable ticket reuse,
wherea=
s some other folks are very opposed to any kind of reuse.

In other words, I meant "we do not have consensus to allow reu=
se";
I did not mean "we have consensus to not allow reu=
se".

I'm not a TLS WG chair, I cannot jud=
ge consensus here. I was simply
noting that there indeed had not =
been a consensus call on this topic.

Furthermore, =
I still think the topic of reuse is out of scope for
draft-ietf-t=
ls-ticket-request.

Hope this helps.
=
David


--00000000000017a5ad059fc02b6f--


From nobody Sat Feb 29 16:34:37 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7783A1698 for ; Sat, 29 Feb 2020 16:34:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 Dpx6zsju6GW9 for ; Sat, 29 Feb 2020 16:34:31 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D732D3A0DF5 for ; Sat, 29 Feb 2020 16:34:30 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id s1so4506860lfd.3 for ; Sat, 29 Feb 2020 16:34:30 -0800 (PST)
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=4OzlCpKFX5kCwwTp9QhPDMU9N+FjulwcWFPnbQJYhks=; b=nWkAzJrw8lPTua1GMofxi1RjjASc5LVduSQEZWN2aGPhwG3kXxirwd8UPJ914ctRv7 /2j3BItbCGZlsJAdLX61yqjuxHfWIrI13oz4fdwY8QRz+xwbw5bHsjP+fAWPX3ea+RgZ MTJGB+4Hu8+zEY/t/IluzTfoTrDHkDLdwR18xL0zutGHDBSWUpVMt1UJTHWjloRvVgSg 5AG6+Xo6k2IPu1Q0gitWeMPdEKjRu1wt7N9uNhy6jXGvgtPh6ILo/ti7PfZuyz/p/M0+ nqYa/FWZ9Spy7v+0Jy963pMNmmZMA2lrTxJGNua9zfh+IQmVKHDVkSvgfHJanY9wEB7x Ybiw==
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=4OzlCpKFX5kCwwTp9QhPDMU9N+FjulwcWFPnbQJYhks=; b=U9MSO1Ycm5f6Z3trKiSx0AB48rhCGCe+D3zxWkrIANhliCEBFMwa8VGa85HQDlJqRW Naxa86nMdzIEUC4KWhCo89WKlEfZoVjCXSAfONX+v3qHJFfynw4kIghlThhWCCXxW6Qr cPO3JzWwH0h3aOto3xowhRcUF225qnDOfFdvsFw/zG+8FNl4TVPmpCxUqLEfb9mfP3Uk +xav9kChjbaNlOA7y/aFaGywFCpV7anfB4gE0vmTM29Q9YBlH7dA3W4/zjIoDVkkPMJD MbzEQ0Q58paRmHYoaYnlu6UTjYfQ0HckbJh1ruQwsw6/t+X+Xky20TEtQ3L5w9q+X+fu yfKg==
X-Gm-Message-State: ANhLgQ2tKclytISN01LeVdo2foiDjxcpUL/GofY9hGGtgmADO6zQbpN0 dVSiNaF92zVTMg8zRrnzwssFwSU2kfXeNECQCBSYIUcB
X-Google-Smtp-Source: ADFU+vvXfo3x6cU2rV+036SS/XU/+2fOE+fj+sqg0uZKoTIlmgq3ZD51bdV3moVgX8U/4xc3YtM5wb4gRH3W3Evvv+c=
X-Received: by 2002:ac2:5f7c:: with SMTP id c28mr6493900lfc.204.1583022868533;  Sat, 29 Feb 2020 16:34:28 -0800 (PST)
MIME-Version: 1.0
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com> <20200229091728.GY7977@straasha.imrryr.org>  <20200229222811.GZ7977@straasha.imrryr.org>
In-Reply-To: <20200229222811.GZ7977@straasha.imrryr.org>
From: David Schinazi 
Date: Sat, 29 Feb 2020 16:34:17 -0800
Message-ID: 
To: "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000c015b9059fc03bf8"
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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, 01 Mar 2020 00:34:35 -0000

--000000000000c015b9059fc03bf8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 29, 2020 at 2:28 PM Viktor Dukhovni 
wrote:

> But the second count is not just or even primarily for reuse, it is also
> useful for the non-reuse case as explained in the new text.  The fact
> that it then possible to cleanly express reuse is a byproduct, and I
> also don't mean to encourage reuse in general, but it does have
> non-trivial applications, where the privacy impact is zero (no client
> privacy is possible or desirable).
>
> The TLS WG can maintain a strong focus on *enabling* privacy, and a
> strong recommendation that applications need to take privacy into
> account, but WITHOUT forcing pointless privacy-related counter-measures
> down everybody's throat, whether you need it or not.
>
> Ignoring the needs of market segments other than the principal one
> of browser-to-website is IMHO not something that the TLS WG should
> do.  The browsers are perfectly capable of not doing reuse, and
> even if some misguided client erroneously offers reuse, the server
> can decline.  Ticket reuse requires the co=C3=B6peration of both client
> and server, by which point a reasonable position to take is that
> it is their choice to make.
>

Hi Viktor,

I think that what you bring up here has value, but I do not see it in
scope of draft-ietf-tls-ticket-request. The draft as currently written
addresses the use-cases that it was scoped to address. I would
encourage you to propose another draft with your use-cases, as
that would be a great starting point for that discussion. I appreciate
your editorial work on draft-ietf-tls-ticket-request and I'm willing to
make those editorial changes (assuming the other editors agree),
but we shouldn't change the normative text to support an
out-of-scope use-case.

Thanks,
David

--000000000000c015b9059fc03bf8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sat, Feb 29, 2020 at 2:28 PM Viktor Du=
khovni <ietf-dane@dukhovni.org=
> wrote:

But the second count is not just or even primarily for reuse, it is also
useful for the non-reuse case as explained in the new text.=C2=A0 The fact<=
br>
that it then possible to cleanly express reuse is a byproduct, and I

also don't mean to encourage reuse in general, but it does have

non-trivial applications, where the privacy impact is zero (no client

privacy is possible or desirable).



The TLS WG can maintain a strong focus on *enabling* privacy, and a

strong recommendation that applications need to take privacy into

account, but WITHOUT forcing pointless privacy-related counter-measures

down everybody's throat, whether you need it or not.



Ignoring the needs of market segments other than the principal one

of browser-to-website is IMHO not something that the TLS WG should

do.=C2=A0 The browsers are perfectly capable of not doing reuse, and

even if some misguided client erroneously offers reuse, the server

can decline.=C2=A0 Ticket reuse requires the co=C3=B6peration of both clien=
t

and server, by which point a reasonable position to take is that

it is their choice to make.

Hi Viktor,<=
/div>

I think that what you bring up here has value, but=
 I do not see it in
scope of draft-ietf-tls-ticket-request. The d=
raft as currently written
addresses the use-cases that it was sco=
ped to address. I would
encourage you to propose another draft wi=
th your use-cases, as
that would be a great starting point for th=
at discussion. I appreciate
your editorial work on=C2=A0draft-iet=
f-tls-ticket-request and I'm willing to
make those editorial =
changes (assuming the other editors agree),
but we shouldn't =
change the normative text to support an
out-of-scope use-case.

Thanks,
David


--000000000000c015b9059fc03bf8--


From nobody Sat Feb 29 16:47:18 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CEB3A16BE for ; Sat, 29 Feb 2020 16:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 FPRyrWAJ61xG for ; Sat, 29 Feb 2020 16:47:16 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F8B3A16BD for ; Sat, 29 Feb 2020 16:47:15 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 2CFCF1ABE36; Sat, 29 Feb 2020 19:47:15 -0500 (EST)
Date: Sat, 29 Feb 2020 19:47:15 -0500
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20200301004715.GB7977@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com> <20200229091728.GY7977@straasha.imrryr.org>  <20200229225701.GM18021@localhost> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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, 01 Mar 2020 00:47:18 -0000

On Sat, Feb 29, 2020 at 04:29:38PM -0800, David Schinazi wrote:

> Furthermore, I still think the topic of reuse is out of scope for
> draft-ietf-tls-ticket-request.

But is not at all out of scope.  This extension is negotiating ticket
requirements between client and server.  It is not possible for reuse to
be "out of scope", if reuse is ever allowed, then it should be possible
to negotiate it.

A decision needs to be made.  Is the TLS WG mandating non-reuse even
where there is zero privacy gain and efficiency gains on both sides
from just using a single ticket until it is replaced by the server?

However, if one *really* wanted to punt on the decision, the two
counters could be specified, without defining the case where the
resumption count is zero as being "reuse".  The "reuse case" could
then be deferred to a subsequent draft.  In *this* draft any "<= 1"
resumption_count case could then be treated as "1" (server does not
at present support reuse).

I don't think that making reuse possible is really such a hot potato.
But if it so toxic, that we're collectively unable to touch it, then
it could be deferred in a way that leaves room to get it done later
without fundamentally revising the extension.

-- 
    Viktor.


From nobody Sat Feb 29 16:50:17 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CF03A1657 for ; Sat, 29 Feb 2020 16:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 dICevP-olysg for ; Sat, 29 Feb 2020 16:50:14 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291203A07DD for ; Sat, 29 Feb 2020 16:50:14 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 8CE501AC007; Sat, 29 Feb 2020 19:50:13 -0500 (EST)
Date: Sat, 29 Feb 2020 19:50:13 -0500
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20200301005013.GC7977@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com> <20200229091728.GY7977@straasha.imrryr.org>  <20200229222811.GZ7977@straasha.imrryr.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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, 01 Mar 2020 00:50:16 -0000

On Sat, Feb 29, 2020 at 04:34:17PM -0800, David Schinazi wrote:

> I think that what you bring up here has value, but I do not see it in
> scope of draft-ietf-tls-ticket-request.

I don't see how it can be out of scope.  The abstract clearly
puts it in scope:

   TLS session tickets enable stateless connection resumption for
   clients without server-side, per-client state.  Servers vend an
   arbitrary number of session tickets to clients, at their discretion,
   upon connection establishment.  Clients store and use tickets when
   resuming future connections.  This document describes a mechanism by
   which clients can specify the desired number of tickets needed for
   future connections.  This extension aims to provide a means for
   servers to determine the number of tickets to generate in order to
   reduce ticket waste, while simultaneously priming clients for future
   connection attempts.

And even without reuse, the two separate counters aid in producing the
right number of tickets on routine resumption vs. session renegotiation.

-- 
    Viktor.


From nobody Sat Feb 29 17:19:55 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C77D3A171F for ; Sat, 29 Feb 2020 17:19:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.077
X-Spam-Level: 
X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, 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 5ascfXiEtD1R for ; Sat, 29 Feb 2020 17:19:39 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943CD3A171D for ; Sat, 29 Feb 2020 17:19:38 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id y17so5039515lfe.8 for ; Sat, 29 Feb 2020 17:19:38 -0800 (PST)
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=aSyMQDY4mB+H+k0kuGALBOBcslM8BaxN+GNPS3gBdv4=; b=XJtVJnjhlFVeWJr1Juq5jiMYt+grf1pSeLhENfkObMJMoh1chTmwYJk82uOmU4wSXQ RT2aWi9CbbhkI5mmkr4Pn1Iw0CsoBr5cH2xAduyuCtBkXrJSwP0fBIxc4Jg+EBbeN3ee Jx9BsAlTJ6Ummi5gq+qpW5f3HyDDk9DeurzFe6V0UL62QTJOIzZ+RQuypVewVkCaLevO sTNE8w77lqMxNYzaqWDjgZ0A/gaUHymQyv6EjdbtQJovzkT2bKhPfBkXoAT+8ofBnQP3 UWs9d4cwXhkBJEpq4lG2s3hDWF6on38yRgCn0ZUMRYdK2yGERjnoDVYKSZ3SW+G3rPdX z1rg==
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=aSyMQDY4mB+H+k0kuGALBOBcslM8BaxN+GNPS3gBdv4=; b=mC3cNFJJv48FyqNF2Sa2JzTyv/I5MpvladtiidBqKqOycWXs3xe1lXmzxx12qlOfpA VPG/QwMT35myxNwDExgsQ3Skt4SZV5KGN0z7jhdq9l8KW0l7bsJgd1WZVbF876P+X2cs woseMLjtm4eEIocSPpQk4q/m9rw3XGMImhY3D5GpqQ1uj9ODcfLt8CA0GuE4OOwJYpGM 5KyMHgrtV4DDvtNYSpeU5CnZEC9qGa93+QE+thV4iD0AXlxo0jPD2yHZy3L9M0DAlmQ3 9abzwSkJc9VnV8jh7Xw+9J4qmIVOlcecSgIPQjUd2/rUG/glAS3OqGZPaoeCxguyND9C 8hPg==
X-Gm-Message-State: ANhLgQ0yMOOukiPBHUoelw/X1vVin5oG5pJe2Y8R8Ck8DW2c/L7kBBUz KGlA2jN8aMsMRU9QHFAGgbXKqSZnKppqHfS6ILxYtA==
X-Google-Smtp-Source: ADFU+vtSkUmx/AVvV8+hkvzg+O4IRBg5MV2KgqTHja6oi8STDqN5gY3pfBBBaLS9BHNecKrGpKa/U4RF6lSPUS4H+I0=
X-Received: by 2002:a19:8556:: with SMTP id h83mr6757077lfd.40.1583025574555;  Sat, 29 Feb 2020 17:19:34 -0800 (PST)
MIME-Version: 1.0
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com> <20200229091728.GY7977@straasha.imrryr.org>  <20200229222811.GZ7977@straasha.imrryr.org>  <20200301005013.GC7977@straasha.imrryr.org>
In-Reply-To: <20200301005013.GC7977@straasha.imrryr.org>
From: David Schinazi 
Date: Sat, 29 Feb 2020 17:19:23 -0800
Message-ID: 
To: "TLS@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000000ab4fb059fc0dddb"
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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, 01 Mar 2020 01:19:53 -0000

--0000000000000ab4fb059fc0dddb
Content-Type: text/plain; charset="UTF-8"

My personal opinion is that reuse is clearly out of scope,
especially given the diverging opinions in the working
group on this topic.

I'm going to let the chairs step in and let us know what
their view of the scope is.

David

On Sat, Feb 29, 2020 at 4:50 PM Viktor Dukhovni 
wrote:

> On Sat, Feb 29, 2020 at 04:34:17PM -0800, David Schinazi wrote:
>
> > I think that what you bring up here has value, but I do not see it in
> > scope of draft-ietf-tls-ticket-request.
>
> I don't see how it can be out of scope.  The abstract clearly
> puts it in scope:
>
>    TLS session tickets enable stateless connection resumption for
>    clients without server-side, per-client state.  Servers vend an
>    arbitrary number of session tickets to clients, at their discretion,
>    upon connection establishment.  Clients store and use tickets when
>    resuming future connections.  This document describes a mechanism by
>    which clients can specify the desired number of tickets needed for
>    future connections.  This extension aims to provide a means for
>    servers to determine the number of tickets to generate in order to
>    reduce ticket waste, while simultaneously priming clients for future
>    connection attempts.
>
> And even without reuse, the two separate counters aid in producing the
> right number of tickets on routine resumption vs. session renegotiation.
>
> --
>     Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--0000000000000ab4fb059fc0dddb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


My personal opinion is that reuse is clearly out of s=
cope,
especially given the diverging opinions in the working
group on this topic.

I'm going to let the cha=
irs step in and let us know what
their view of the scope is.
=

David

On Sat, Feb 29, 2020 at 4:50 PM Viktor Dukhovni &=
lt;ietf-dane@dukhovni.org>=
 wrote:
On Sat, =
Feb 29, 2020 at 04:34:17PM -0800, David Schinazi wrote:



> I think that what you bring up here has value, but I do not see it in<=
br>
> scope of draft-ietf-tls-ticket-request.



I don't see how it can be out of scope.=C2=A0 The abstract clearly

puts it in scope:



=C2=A0 =C2=A0TLS session tickets enable stateless connection resumption for=


=C2=A0 =C2=A0clients without server-side, per-client state.=C2=A0 Servers v=
end an

=C2=A0 =C2=A0arbitrary number of session tickets to clients, at their discr=
etion,

=C2=A0 =C2=A0upon connection establishment.=C2=A0 Clients store and use tic=
kets when

=C2=A0 =C2=A0resuming future connections.=C2=A0 This document describes a m=
echanism by

=C2=A0 =C2=A0which clients can specify the desired number of tickets needed=
 for

=C2=A0 =C2=A0future connections.=C2=A0 This extension aims to provide a mea=
ns for

=C2=A0 =C2=A0servers to determine the number of tickets to generate in orde=
r to

=C2=A0 =C2=A0reduce ticket waste, while simultaneously priming clients for =
future

=C2=A0 =C2=A0connection attempts.



And even without reuse, the two separate counters aid in producing the

right number of tickets on routine resumption vs. session renegotiation.


-- 

=C2=A0 =C2=A0 Viktor.



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--0000000000000ab4fb059fc0dddb--


From nobody Sat Feb 29 19:19:54 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E273A18B1 for ; Sat, 29 Feb 2020 19:19:52 -0800 (PST)
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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=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 zmWAolMhxO2H for ; Sat, 29 Feb 2020 19:19:50 -0800 (PST)
Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (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 9DE323A18B0 for ; Sat, 29 Feb 2020 19:19:50 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id EC51E340EF1; Sun,  1 Mar 2020 03:19:49 +0000 (UTC)
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (100-96-217-41.trex.outbound.svc.cluster.local [100.96.217.41]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 503EE341986; Sun,  1 Mar 2020 03:19:49 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a89.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sun, 01 Mar 2020 03:19:49 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Abortive-Company: 25fc603f6e38ddb8_1583032789754_2836592145
X-MC-Loop-Signature: 1583032789753:3164441241
X-MC-Ingress-Time: 1583032789753
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTP id 2BCEC7F4D2; Sat, 29 Feb 2020 19:19:45 -0800 (PST)
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=JheSh6ERjcjjtJ x1jdQRX4OtWpA=; b=EQR7kppDa5IguCedQCgkGgpDSL9jUUBHME389735NP6sXB uYDo3HRULYyqVyB4fLq3voWBVmmqHQF6Wp70Lf0odoCuwE8p5KtaepPWqweQlt5w 0m9QlwuutJ2mm0g3lnuYXjFXKaoHy9hQOq1u4V0zQd3umPc69L1Jf0x1ugxjw=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 567267F4D4; Sat, 29 Feb 2020 19:19:43 -0800 (PST)
Date: Sat, 29 Feb 2020 21:19:33 -0600
X-DH-BACKEND: pdx1-sub0-mail-a89
From: Nico Williams 
To: David Schinazi 
Cc: "TLS@ietf.org" 
Message-ID: <20200301031932.GN18021@localhost>
References: <86B6EF5B-9351-4304-8A85-5969C88810E1@sn3rd.com> <20200229091728.GY7977@straasha.imrryr.org>  <20200229225701.GM18021@localhost> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedruddtuddgheehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Archived-At: 
Subject: Re: [TLS] progressing draft-ietf-tls-ticket-request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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, 01 Mar 2020 03:19:53 -0000

On Sat, Feb 29, 2020 at 04:29:38PM -0800, David Schinazi wrote:
> On Sat, Feb 29, 2020 at 2:57 PM Nico Williams  wrote:
> > On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> > > However, I don't think we should add a second count in this extension.
> > > Allowing ticket reuse is not something we have consensus for in the
> >                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Did I miss a consensus call or something?
> 
> To clarify what I said: I meant that there has not been a consensus
> call here, and additionally I've heard that some folks would like to
> enable ticket reuse, whereas some other folks are very opposed to any
> kind of reuse.
> 
> In other words, I meant "we do not have consensus to allow reuse"; I
> did not mean "we have consensus to not allow reuse".

I don't think even that is correct.  Without a consensus call we don't
know.  Viktor has raised serious concerns and a simple fix.

> I'm not a TLS WG chair, I cannot judge consensus here. I was simply
> noting that there indeed had not been a consensus call on this topic.
> 
> Furthermore, I still think the topic of reuse is out of scope for
> draft-ietf-tls-ticket-request.

Well, you think so, and I don't.  Now what?

Nico
-- 


From nobody Sat Feb 29 23:32:30 2020
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812483A094C for ; Sat, 29 Feb 2020 23:32:24 -0800 (PST)
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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=mnot.net header.b=AESnoy+N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nGCE6DmE
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgdtDY-okO94 for ; Sat, 29 Feb 2020 23:32:23 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7AB63A095C for ; Sat, 29 Feb 2020 23:32:22 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2383450C for ; Sun,  1 Mar 2020 02:32:22 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 01 Mar 2020 02:32:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=dh4hNIrqkKyxYSaYM9kFWP6/6ogQbDfUT8at/grplxc=; b=AESnoy+N LOQ2PEaGbg8cKcCLaP8XNNe+5dRSxZ2BLnTBX04bvEDMeVtS7OYVLjZeu0Fo5Z/h 2Qqx/9l+yRF5fodey5EIVjBvrf/BAwW3DooTwkhLE1mwl+ole6Tct2I5GMf/n6St FMSdB7IrWislQtmGEcwsxzHYs9fFpMutBlhFLJeFzOylQqn02+n30fDIblMjgSpO UGYD3NgchxbmtaB9U8mWR2sr0IJV4ELBZk65CAaxctyQX4tuCTmz2ut14ySqI7A/ CSK1p+W4hUMp5zvbdmoS2mUMzXJFRL5KV/fb3hq5YTvbNBQtnmXfhY3iEaCjeHLr e/8++l7089YAhQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=dh4hNIrqkKyxYSaYM9kFWP6/6ogQb DfUT8at/grplxc=; b=nGCE6DmEzgoZA+RdE0xc505Y4AnUe5zThI02+ndGeYV70 KCd1jIAXNXwud2WElcWGIdc6AptE2YHCvA3+aPrDfo2aovUh0JY3YUnvff3RPGXd ZtgqOV7563vpib3TExSmz37mESD/Er0rz5aLAJOvz7srfnh+OoN2fdIGRcrB4jGY NUhQu5CvAk6lgzAV8l8zAfGNzTSjfa3W0mOV95k9bfHs/3/jSKGqkNCVQpmakFQT poosChLFtHFlVsxWNayM7GeQoIvKgwBYDMrCo9/GbemtOoiLtNO0t3hSeyLCJsji HXOJauKLWadGg6ldjvpB9XTPEnzgdVUDrdMRsaLcQ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtuddguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmnecukfhppeehvddrudejledrudefvddrudegvdenucevlhhu shhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprh gvphhlhiesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: from [10.1.0.4] (unknown [52.179.132.142]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D067328005A for ; Sun,  1 Mar 2020 02:32:21 -0500 (EST)
Content-Type: multipart/alternative; boundary="===============8174766471755026997=="
MIME-Version: 1.0
From: Repository Activity Summary Bot 
To: tls@ietf.org
Message-Id: <20200301073221.8D067328005A@mailuser.nyi.internal>
Date: Sun,  1 Mar 2020 02:32:21 -0500 (EST)
Archived-At: 
Subject: [TLS] Weekly github digest (TLS Working Group Drafts)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list 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, 01 Mar 2020 07:32:25 -0000

--===============8174766471755026997==
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; format="flowed"




Issues
------
* tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC0)
  1 issues created:
  - legacy cookie field (by martinthomson)
    https://github.com/tlswg/dtls13-spec/issues/118=20

* tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC0)
  1 issues created:
  - Editor drafts are out-of-date (by Lekensteyn)
    https://github.com/tlswg/tls-subcerts/issues/57=20



Pull requests
-------------
* tlswg/draft-ietf-tls-esni (+0/-3/=F0=9F=92=AC1)
  1 pull requests received 1 new comments:
  - #111 break RRData into ESNIKeys and ESNIInclude (1 by chris-wood)
    https://github.com/tlswg/draft-ietf-tls-esni/pull/111=20

  3 pull requests merged:
  - Add description about "cipher suites" via an ESNIKeys extension
    https://github.com/tlswg/draft-ietf-tls-esni/pull/184=20
  - Clarify rules on order and repetition for ESNIConfig extensions
    https://github.com/tlswg/draft-ietf-tls-esni/pull/195=20
  - Flatten ESNI negotiation mechanisms
    https://github.com/tlswg/draft-ietf-tls-esni/pull/201=20

* tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC0)
  1 pull requests merged:
  - Less circular definitions for identity
    https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/25=20

* tlswg/draft-ietf-tls-ticketrequest (+2/-1/=F0=9F=92=AC0)
  2 pull requests submitted:
  - Ticket request with separate resumption and new_session counts. (by vdu=
khovni)
    https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18=20
  - Clarify racing pre-conditions (by chris-wood)
    https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/17=20

  1 pull requests merged:
  - adding security consideration on reflection attack
    https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/12=20

* tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC0)
  1 pull requests submitted:
  - Add arc names for OIDs (by Lekensteyn)
    https://github.com/tlswg/tls-subcerts/pull/58=20


Repositories tracked by this digest:
-----------------------------------
* https://github.com/tlswg/draft-ietf-tls-semistatic-dh
* https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
* https://github.com/tlswg/draft-ietf-tls-esni
* https://github.com/tlswg/certificate-compression
* https://github.com/tlswg/draft-ietf-tls-external-psk-importer
* https://github.com/tlswg/draft-ietf-tls-ticketrequest
* https://github.com/tlswg/tls-flags
* https://github.com/tlswg/dtls13-spec
* https://github.com/tlswg/dtls-conn-id
* https://github.com/tlswg/tls-subcerts
* https://github.com/tlswg/oldversions-deprecate
* https://github.com/tlswg/sniencryption
* https://github.com/tlswg/tls-exported-authenticator
* https://github.com/tlswg/draft-ietf-tls-grease

--===============8174766471755026997==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable





Weekly github digest (TLS Working Group Drafts)





Sunday March 01, 2020




Issues



tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC0)

  
1 issues created:

  




tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC0)

  
1 issues created:

  






Pull requests


tlswg/draft-ietf-tls-esni (+0/-3/=F0=9F=92=AC1)


  
1 pull requests received 1 new comments:

  

  
3 pull requests merged:

  


tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC0)



  
1 pull requests merged:

  


tlswg/draft-ietf-tls-ticketrequest (+2/-1/=F0=9F=92=AC0)

  
2 pull requests submitted:

  


  
1 pull requests merged:

  


tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC0)

  
1 pull requests submitted:

  





Repositories tracked by this digest:





--===============8174766471755026997==--