From nobody Sun Dec 1 16:46:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995B012011B; Sun, 1 Dec 2019 16:46:23 -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 VHjndzuhHZWh; Sun, 1 Dec 2019 16:46:22 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CBCA8120052; Sun, 1 Dec 2019 16:46:21 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xB20kEc0032079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Dec 2019 19:46:17 -0500 Date: Sun, 1 Dec 2019 16:46:14 -0800 From: Benjamin Kaduk To: Christian Huitema Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org Message-ID: <20191202004614.GB32847@mit.edu> References: <157498929764.5575.7815291384505057169@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157498929764.5575.7815291384505057169@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-certificate-compression-07 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, 02 Dec 2019 00:46:24 -0000 Hi Christian, Thanks for the constant vigilance on the privacy front; it's good to work through what the differential exposure is, here, both with and without ESNI. Authors, please consider how you would like to handle this topic in the document. Thanks, Ben On Thu, Nov 28, 2019 at 05:01:37PM -0800, Christian Huitema via Datatracker wrote: > Reviewer: Christian Huitema > Review result: Has Issues > > I have reviewed draft-ietf-tls-certificate-compression-07 as part of the > security directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written primarily for the benefit of > the security area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Draft-ietf-tls-certificate-compression-07 defines two new TLS extensions to > negotiate and then apply compression of the Certificate message. The draft is > clear and well written, and the extensions are already widely deployed. I would > like to say "ready", but I have to say "almost". > > This document is almost ready, except for one nit and one issue. > > First, one nit. The draft references the "Certificate message", but there is no > formal reference section 4.4.2 of RFC8446. Please add that, maybe at the > beginning of section 4. It may seem obvious to members of the TLS WG, but > uninformed readers will appreciate. > > Second, my actual concern. Compression may leak information, because different > certificate chains will compress differently. The authors mention that an > attacker will not be able to inject data in the certificate chain, and thus > that attacks of the CRIME variety are unlikely. That's correct, but that's not > the entire story. > > TLS 1.3 will encrypt the compressed certificate message but the length of that > message could be deduced from the length of the server's encrypted message. > Attackers might be able to derive from that length the identity of the server, > even if the SNI is encrypted. > > One could say that in the absence of compression the length of the certificate > chain is also available. Indeed, the problem is flagged in > draft-ietf-tls-esni-05, which states in section 5.3 that "it (the server) > SHOULD pad the Certificate message, via padding at the record layer, such that > its length equals the size of the largest possible Certificate (message) > covered by the same ESNI key." > > Certificate compression introduces a level of complexity here. If only some > servers in the anonymity set support compression, attackers can work with a > smaller anonymity subset. If all attackers support compression, the padding > should try to match the largest Compressed Certificate. > > It might be good to discuss this issue in the security consideration section. > > From nobody Sun Dec 1 23:54:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377A712021C for ; Sun, 1 Dec 2019 23:54:57 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 dxDhfD0hwepE for ; Sun, 1 Dec 2019 23:54:55 -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 2D990120154 for ; Sun, 1 Dec 2019 23:54:54 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xB27sqsw025049; Mon, 2 Dec 2019 07:54:52 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=KSZVdfYphfLAcn4ihHwS6EpZ+XmVPKleud2gmBeamFA=; b=VLwkH3nZ6PuBvVsBxwIOA1Wj3205rehvU2rIb3KNLFUBxz7qsh7luogswIr+5ClYh3UQ S5m31TJcAAXYDOLx3b1BTqqSoXFoPpePoHdZw5DCv2+UyFyuFMrSjCxb73wq02TefDv+ 6y/9kv+JXQq6/+BJtORVDIgExxGMPvFL3bZ91Mz9oxfIZphgSiEkrvyLo4fmMJ/NE8Ks EP6w7gzN7SV4uXm7aFvI+vlafWirbVgUsXdjZ+XYlFdzgXeanvBPWrniSIFU81DI2kDN dNdq5CakMetVI88oaggtfS2gh0ckx8oyDt6jaHC27yN8f3vRUUykH4hI2WATvkTTRKNM 8Q== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2wkhqdhrqv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Dec 2019 07:54:52 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xB27l3CH008154; Mon, 2 Dec 2019 02:54:47 -0500 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2wkmmxym6n-1; Mon, 02 Dec 2019 02:54:47 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id E300A1FC95; Mon, 2 Dec 2019 07:54:46 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1ibgXd-0004Tg-Hv; Sun, 01 Dec 2019 23:54:45 -0800 Date: Sun, 1 Dec 2019 23:54:45 -0800 From: Benjamin Kaduk To: Xuan k Cc: Eric Rescorla , "" Message-ID: <20191202075444.GI3397@akamai.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-01_04:, , 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-1912020070 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-01_04:2019-11-29,2019-12-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 spamscore=0 suspectscore=0 clxscore=1011 mlxscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912020071 Archived-At: Subject: Re: [TLS] [DTLS1.3]About the retransmission of Handshake records 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, 02 Dec 2019 07:54:57 -0000 That might be an artifact from Ack having at one point (the -00) been a handshake message. Though, it seems that the Server's message_seq space should also start at 0 with ServerHello, if I am understanding correctly. -Ben On Thu, Nov 28, 2019 at 03:15:38PM +0800, Xuan k wrote: > Hi Ekr, > > Thanks for your help. > > I have another question about the "message_seq" in section "6. Example of > Handshake with Timeout and Retransmission". > Could you please explain it? > > In the secion 6, the Client send message_seq = 0 in Record 0 and > message_seq = 2,3,4 in Record 2. > > Why message_seq = 1 is skipped by Client? > I think the ClientHello in the figure should begin with message_seq=1. The > message_seq = 0 is used by the first ClientHello which is the one without > cookies. > > > Thanks, > Zhai Zhaoxuan > > On 11/28/19 5:37 AM, Eric Rescorla wrote: > > > > On Tue, Nov 26, 2019 at 10:05 PM Xuan k wrote: > > > Hi all, > > > > I'm trying to implement a DTLS1.3 library for embedded devices. But It > > seems something weird about retransmissions and ACKs. > > > > In the section "5.2. DTLS Handshake Message Format": > > > > The first message each side transmits in each association always has > > message_seq = 0. Whenever a new message is generated, the > > message_seq value is incremented by one. When a message is > > retransmitted, the old *message_seq value is re-used*, i.e., not > > incremented. From the perspective of the DTLS record layer, the > > retransmission is a new record. This record will have a *new* > > * DTLSPlaintext.sequence_number* value. > > > > > > In the section "7. ACK Message", the ACK message use the record_numbers > > (corresponds to *DTLSPlaintext.sequence_number*). > > > > For my understanding, the "message_seq" belongs to "Handshake" and the > > "sequence_number" or "record_numbers" belongs to > > record layer. > > > > Yes. > > The retransmission detection is done by "Handshake" using "message_seq", > > but the "acknowledge" is done by "record layer" using "record_numbers". > > It is so weird. > > > > Hmm... I don't think that this is particularly weird. This is, for > instance, how QUIC stream acknowledgement and retransmission works. > > > The retransmission, retransmission detection and acknowledge should be done > > in handshake process, but we need the record layer passing the > > record_numebrs to the handshake process. > > > > Since a new "sequence_number" is used for retransmission, we have to > > maintain a "record_numbers" to "message_seq" map with dynamic size. > > Each retransmission attempt creates a new relationship between a new > > "record_numbers" to an old "message_seq". > > > > Yes, that's how it works in NSS. > > > Since ACK is only used with Handshake messages, is it possible that we use > > "message_seq" in ACK messages? > > > Or we use *old* "sequence_number" for retransmission, > > > > Both of these give you strictly less information about the network. One of > the cool innovations in QUIC is to label each packet separately so you can > determine whether an ACK is an ACK of the original packet or a retransmit. > We are trying to inherit tha there > > -Ekr > > so we do not need maintain the dynamic map. And if replay detection is > > implemented, the retransmitted > > record can be dropped by record layer (by replay detection), the > > "Handshake Protocol" do not need to do retransmission detection. > > > > Thanks > > Zhai Zhaoxuan > > _______________________________________________ > > 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 Mon Dec 2 03:18:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C436B120047 for ; Mon, 2 Dec 2019 03:18:12 -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 yLDUZZc0Z_Jt for ; Mon, 2 Dec 2019 03:18:10 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC068120020 for ; Mon, 2 Dec 2019 03:18:09 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id l24so1856863vsr.12 for ; Mon, 02 Dec 2019 03:18:09 -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=UN7oviwrLt1HzQVeqS36fa8Z3983yiF1hM8VKIpPH2g=; b=RitbTE/Io8p34JaqhTjAqoDgJ+xOVn4W+eHa7vkrmM2HtD6AxfaSBrjns5xKPBSQ/R vYlXlU/y/HN74/czSgAnq63lvhzLRbZJ3uSoZhNveETZ8NWghu8NM0SGmROPK5s6DLL4 0rnp07M1yokkBygVNmvgyDTe3tSxzNL6nnp/LaiObWmArX24vXEdpS7jtYkWA+qrXGjV AzTz/gxLotXJAjSbxXXtmuv0wPNuCZnftHFSrYyY2JmP5m+LCA+rh+pO7LXAT/CbA69u 5dHbymtXjXzTrMXbMi81YCQQnokgUHJGF+BFRybXv9zCocfhczFb0S8SPT1d5hTiNzR4 WtDQ== 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=UN7oviwrLt1HzQVeqS36fa8Z3983yiF1hM8VKIpPH2g=; b=lY6omhbOp7mHinvjRYESNzmlgd8Zmp0eo8QUnVKC+s9Nxo9dWfwXSR9EktKCVO9vlw esnI7uSXkWELGZiW1hf5UBxK1rJQ3cv6ZXPF+zCDG5x+Axhv4LK4dBxO5A1VSg0SFgCx r0GSStK/t0hWmNRn5xxA0730Czy0okJV8p1OJiB7mseuRgpbR9sSmUzDyegcwukr5E9w IXYmA3d3a5iKOtetFEzCqCNtYhj2qKO2TnZ8XWzSFs2l3QPw+mJnXIUSVtuKTHR77dHG Uf2qtJSS8oIebmY0rhkU+ZIUEkb/1H9HN+eJwfIAZKmVqeWB/W/+d5dFIp7lePm8S9FW /yow== X-Gm-Message-State: APjAAAUh7bfVXlER+qNHrb+cQUBgMXV6XKpoM/n+3EHxt3BGPyopjjTL enqDpl+lHdw3s6gD91bpQJZTz82/ZdM7ATuStBtgTKEuSNM= X-Google-Smtp-Source: APXvYqwOtkMN1q8XtWLxEz67/ICa7wGJnZgbUTE9oWtXhBafRZ75h2GmPbjcuoVm/P1xxHHqgTN5YAGVeeAxKUBo53g= X-Received: by 2002:a67:7d17:: with SMTP id y23mr4743531vsc.162.1575285488744; Mon, 02 Dec 2019 03:18:08 -0800 (PST) MIME-Version: 1.0 References: <20191202075444.GI3397@akamai.com> In-Reply-To: <20191202075444.GI3397@akamai.com> From: Xuan k Date: Mon, 2 Dec 2019 19:17:32 +0800 Message-ID: To: Benjamin Kaduk Cc: Eric Rescorla , "" Content-Type: multipart/alternative; boundary="000000000000f9fda30598b6bbc4" Archived-At: Subject: Re: [TLS] [DTLS1.3]About the retransmission of Handshake records 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, 02 Dec 2019 11:18:13 -0000 --000000000000f9fda30598b6bbc4 Content-Type: text/plain; charset="UTF-8" Hi Ben, Thanks for your reply. But we understand may not be the same. Since ACK messages are not retransmitted, I think they should not consume message_seqs. If an ACK really use a message_seq and it is lost in network, new handshake records will always use a larger message_seq than the peer expected (next_receive_seq). The peer will unable to continue the handshake process. And I think the ServerHello in the figure should start with 1, as the figure shows. The message_seq = 0 is used by HelloVerifyRequest, which is also been processed by client and been fed into its transcript hash function. So I think the HelloVerifyRequest should be counted and new ServerHello in the figure should start with message_seq = 1. Thanks, Zhai Zhaoxuan On Mon, Dec 2, 2019 at 3:54 PM Benjamin Kaduk wrote: > That might be an artifact from Ack having at one point (the -00) been > a handshake message. Though, it seems that the Server's message_seq > space should also start at 0 with ServerHello, if I am understanding > correctly. > > -Ben > > On Thu, Nov 28, 2019 at 03:15:38PM +0800, Xuan k wrote: > > Hi Ekr, > > > > Thanks for your help. > > > > I have another question about the "message_seq" in section "6. Example of > > Handshake with Timeout and Retransmission". > > Could you please explain it? > > > > In the secion 6, the Client send message_seq = 0 in Record 0 and > > message_seq = 2,3,4 in Record 2. > > > > Why message_seq = 1 is skipped by Client? > > I think the ClientHello in the figure should begin with message_seq=1. > The > > message_seq = 0 is used by the first ClientHello which is the one without > > cookies. > > > > > > Thanks, > > Zhai Zhaoxuan > > > > On 11/28/19 5:37 AM, Eric Rescorla wrote: > > > > > > > > On Tue, Nov 26, 2019 at 10:05 PM Xuan k wrote: > > > > > Hi all, > > > > > > I'm trying to implement a DTLS1.3 library for embedded devices. But It > > > seems something weird about retransmissions and ACKs. > > > > > > In the section "5.2. DTLS Handshake Message Format": > > > > > > The first message each side transmits in each association always has > > > message_seq = 0. Whenever a new message is generated, the > > > message_seq value is incremented by one. When a message is > > > retransmitted, the old *message_seq value is re-used*, i.e., not > > > incremented. From the perspective of the DTLS record layer, the > > > retransmission is a new record. This record will have a *new* > > > * DTLSPlaintext.sequence_number* value. > > > > > > > > > In the section "7. ACK Message", the ACK message use the record_numbers > > > (corresponds to *DTLSPlaintext.sequence_number*). > > > > > > For my understanding, the "message_seq" belongs to "Handshake" and the > > > "sequence_number" or "record_numbers" belongs to > > > record layer. > > > > > > > Yes. > > > > The retransmission detection is done by "Handshake" using "message_seq", > > > but the "acknowledge" is done by "record layer" using "record_numbers". > > > It is so weird. > > > > > > > Hmm... I don't think that this is particularly weird. This is, for > > instance, how QUIC stream acknowledgement and retransmission works. > > > > > > The retransmission, retransmission detection and acknowledge should be > done > > > in handshake process, but we need the record layer passing the > > > record_numebrs to the handshake process. > > > > > > Since a new "sequence_number" is used for retransmission, we have to > > > maintain a "record_numbers" to "message_seq" map with dynamic size. > > > Each retransmission attempt creates a new relationship between a new > > > "record_numbers" to an old "message_seq". > > > > > > > Yes, that's how it works in NSS. > > > > > > Since ACK is only used with Handshake messages, is it possible that we > use > > > "message_seq" in ACK messages? > > > > > Or we use *old* "sequence_number" for retransmission, > > > > > > > Both of these give you strictly less information about the network. One > of > > the cool innovations in QUIC is to label each packet separately so you > can > > determine whether an ACK is an ACK of the original packet or a > retransmit. > > We are trying to inherit tha there > > > > -Ekr > > > > so we do not need maintain the dynamic map. And if replay detection is > > > implemented, the retransmitted > > > record can be dropped by record layer (by replay detection), the > > > "Handshake Protocol" do not need to do retransmission detection. > > > > > > Thanks > > > Zhai Zhaoxuan > > > _______________________________________________ > > > 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 > > --000000000000f9fda30598b6bbc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks for your repl= y.=C2=A0But we understand may not be the same.

Since AC= K messages are not retransmitted, I think they should not consume message_s= eqs.
If an ACK really use a message_seq and it is lost in network,= new handshake records will
always use a larger message_seq than = the peer expected (next_receive_seq).
The peer will unable to con= tinue the handshake process.

And I think the= ServerHello in the figure should start with 1, as the figure shows.
<= div>The message_seq =3D 0 is used by HelloVerifyRequest, which is also been= processed by client
and been fed into its transcript hash functi= on.=C2=A0

So I think the HelloVerifyRequest should= be counted and new ServerHello in the figure
should start with m= essage_seq =3D 1.

Thanks,

Zhai Zhaoxuan
On Mon, Dec 2, 2019 at 3:54 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
<= 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">That might be an artifact = from Ack having at one point (the -00) been
a handshake message.=C2=A0 Though, it seems that the Server's message_s= eq
space should also start at 0 with ServerHello, if I am understanding correc= tly.

-Ben

On Thu, Nov 28, 2019 at 03:15:38PM +0800, Xuan k wrote:
>=C2=A0 Hi Ekr,
>
> Thanks for your help.
>
> I have another question about the "message_seq" in section &= quot;6. Example of
> Handshake with Timeout and Retransmission".
> Could you please explain it?
>
> In the secion 6, the Client send message_seq =3D 0 in Record 0 and
> message_seq =3D 2,3,4 in Record 2.
>
> Why message_seq =3D 1 is skipped by Client?
> I think the ClientHello in the figure should begin with message_seq=3D= 1. The
> message_seq =3D 0 is used by the first ClientHello which is the one wi= thout
> cookies.
>
>
> Thanks,
> Zhai Zhaoxuan
>
> On 11/28/19 5:37 AM, Eric Rescorla wrote:
>
>
>
> On Tue, Nov 26, 2019 at 10:05 PM Xuan k <kxuanobj@gmail.com> wrote:
>
> > Hi all,
> >
> > I'm trying to implement a DTLS1.3 library for embedded device= s. But It
> > seems something weird about retransmissions and ACKs.
> >
> > In the section "5.2. DTLS Handshake Message Format": > >
> >=C2=A0 =C2=A0 The first message each side transmits in each associ= ation always has
> >=C2=A0 =C2=A0 message_seq =3D 0.=C2=A0 Whenever a new message is g= enerated, the
> >=C2=A0 =C2=A0 message_seq value is incremented by one.=C2=A0 When = a message is
> >=C2=A0 =C2=A0 retransmitted, the old *message_seq value is re-used= *, i.e., not
> >=C2=A0 =C2=A0 incremented.=C2=A0 From the perspective of the DTLS = record layer, the
> >=C2=A0 =C2=A0 retransmission is a new record.=C2=A0 This record wi= ll have a *new*
> > *=C2=A0 =C2=A0DTLSPlaintext.sequence_number* value.
> >
> >
> > In the section "7. ACK Message", the ACK message use th= e record_numbers
> > (corresponds to *DTLSPlaintext.sequence_number*).
> >
> > For my understanding, the "message_seq" belongs to &quo= t;Handshake" and the
> > "sequence_number" or "record_numbers" belongs= to
> > record layer.
> >
>
> Yes.
>
> The retransmission detection is done by "Handshake" using &q= uot;message_seq",
> > but the "acknowledge" is done by "record layer&quo= t; using "record_numbers".
> > It is so weird.
> >
>
> Hmm... I don't think that this is particularly weird. This is, for=
> instance, how QUIC stream acknowledgement and retransmission works. >
>
> The retransmission, retransmission detection and acknowledge should be= done
> > in handshake process, but we need the record layer passing the > > record_numebrs to the handshake process.
> >
> > Since a new "sequence_number" is used for retransmissio= n, we have to
> > maintain a "record_numbers" to "message_seq" = map with dynamic size.
> > Each retransmission attempt creates a new relationship between a = new
> > "record_numbers" to an old "message_seq".
> >
>
> Yes, that's how it works in NSS.
>
>
> Since ACK is only used with Handshake messages, is it possible that we= use
> > "message_seq" in ACK messages?
> >
> Or we use *old* "sequence_number" for retransmission,
> >
>
> Both of these give you strictly less information about the network. On= e of
> the cool innovations in QUIC is to label each packet separately so you= can
> determine whether an ACK is an ACK of the original packet or a retrans= mit.
> We are trying to inherit tha there
>
> -Ekr
>
> so we do not need maintain the dynamic map. And if replay detection is=
> > implemented, the retransmitted
> > record can be dropped by record layer (by replay detection), the<= br> > > "Handshake Protocol" do not need to do retransmission d= etection.
> >
> > Thanks
> > Zhai Zhaoxuan
> > _______________________________________________
> > 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

--000000000000f9fda30598b6bbc4-- From nobody Mon Dec 2 03:21:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADF212002E for ; Mon, 2 Dec 2019 03:21:24 -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 n4hdyO_4Z5pn for ; Mon, 2 Dec 2019 03:21:21 -0800 (PST) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CB9120020 for ; Mon, 2 Dec 2019 03:21:21 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id i31so11454738uae.13 for ; Mon, 02 Dec 2019 03:21: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 :cc; bh=or/8M8raychvftSHWfbBhASbQq54bWe8hqn2vhnBmZo=; b=lNJizuwwtRjCXm9UC9ZGKAPIpB3Z7g7kVGAXrDopt9m1zGSkX9fYhHVmlKZd+K5N51 R2uauXYGsqUwCDymE4addEZVE88W94JexRjHrstOGGAMVYoDnz9G9zAxHSYynVXVSr4m Ug8Y/rIX4Mo5aXZ4fjaTrWaJZFvc0vpoJmYPEfHtIgqyVH0f892bkW5+dOF2NeYoX3E1 XSK2uiSU/mpEMK08luQKvNMlAqJAiIbfhO9URG1IV3t4m+jaHq5yJkd2EMvbUKdbJ0Pu rJUyEyifN9uUHE4RQAzpGzcyanV3ZJjlraGHlyfbZAllZOgJgMu7mCUabVKzrw+gQ0oW BQ3g== 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=or/8M8raychvftSHWfbBhASbQq54bWe8hqn2vhnBmZo=; b=hVc7Klp0gaOsGvVtucySmUd4UsOWj1VNN6ye9Wmb1pNkIJaU8ZYmI3Al2CdxVmHjOM 78fTdp8fiJeVyI4L1hg8gT3rg96I4digNiHZ7CpTf5NqipsWmRzewA9Pky8DukrOiHTh GXf+jd0DH6rReDhf3lJqzBuv4uNXuEbcCd5Bsb0RJOHW4UfP9jOR++ufhdwzw5/gYA+9 ZL/+EmZHvVOXbzwWvq2ESUAMETRKwCuCPATHVYTxqZRB6PJeAgTn4+CjB7cpuOrhZ+9s 3RBOg3XvtKFsYfhfsLwWJZ2qVV9idysG+gdPtlkvCNwjEIMtM0mfKPXfmZ3bvwuxq3JR dMmg== X-Gm-Message-State: APjAAAVpSiJKdn5RMEsYw50i0ltK191m74Ac8+X9fwZMBgGayLLkdE9b FV4yINNVUx12s1Og3Di+fFhd86LYRNkAjS2Lixo= X-Google-Smtp-Source: APXvYqx+289UbMMAc1A4MhcnwOBRirA9xEImb/9N1wf5/n2x97ttbcni3ri4on/HK2hrCJVUOLjknKNWndrrcLxHgdA= X-Received: by 2002:ab0:786:: with SMTP id c6mr17322408uaf.62.1575285680060; Mon, 02 Dec 2019 03:21:20 -0800 (PST) MIME-Version: 1.0 References: <20191202075444.GI3397@akamai.com> In-Reply-To: From: Xuan k Date: Mon, 2 Dec 2019 19:20:43 +0800 Message-ID: To: Benjamin Kaduk Cc: Eric Rescorla , "" Content-Type: multipart/alternative; boundary="0000000000006140870598b6c74d" Archived-At: Subject: Re: [TLS] [DTLS1.3]About the retransmission of Handshake records 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, 02 Dec 2019 11:21:24 -0000 --0000000000006140870598b6c74d Content-Type: text/plain; charset="UTF-8" Sorry for my mistake. The HelloVerifyRequest in the previous email should be replace with "HelloRetryRequest". On Mon, Dec 2, 2019 at 7:17 PM Xuan k wrote: > Hi Ben, > > Thanks for your reply. But we understand may not be the same. > > Since ACK messages are not retransmitted, I think they should not consume > message_seqs. > If an ACK really use a message_seq and it is lost in network, new > handshake records will > always use a larger message_seq than the peer expected (next_receive_seq). > The peer will unable to continue the handshake process. > > And I think the ServerHello in the figure should start with 1, as the > figure shows. > The message_seq = 0 is used by HelloVerifyRequest, which is also been > processed by client > and been fed into its transcript hash function. > > So I think the HelloVerifyRequest should be counted and new ServerHello in > the figure > should start with message_seq = 1. > > Thanks, > > Zhai Zhaoxuan > > On Mon, Dec 2, 2019 at 3:54 PM Benjamin Kaduk wrote: > >> That might be an artifact from Ack having at one point (the -00) been >> a handshake message. Though, it seems that the Server's message_seq >> space should also start at 0 with ServerHello, if I am understanding >> correctly. >> >> -Ben >> >> On Thu, Nov 28, 2019 at 03:15:38PM +0800, Xuan k wrote: >> > Hi Ekr, >> > >> > Thanks for your help. >> > >> > I have another question about the "message_seq" in section "6. Example >> of >> > Handshake with Timeout and Retransmission". >> > Could you please explain it? >> > >> > In the secion 6, the Client send message_seq = 0 in Record 0 and >> > message_seq = 2,3,4 in Record 2. >> > >> > Why message_seq = 1 is skipped by Client? >> > I think the ClientHello in the figure should begin with message_seq=1. >> The >> > message_seq = 0 is used by the first ClientHello which is the one >> without >> > cookies. >> > >> > >> > Thanks, >> > Zhai Zhaoxuan >> > >> > On 11/28/19 5:37 AM, Eric Rescorla wrote: >> > >> > >> > >> > On Tue, Nov 26, 2019 at 10:05 PM Xuan k wrote: >> > >> > > Hi all, >> > > >> > > I'm trying to implement a DTLS1.3 library for embedded devices. But It >> > > seems something weird about retransmissions and ACKs. >> > > >> > > In the section "5.2. DTLS Handshake Message Format": >> > > >> > > The first message each side transmits in each association always >> has >> > > message_seq = 0. Whenever a new message is generated, the >> > > message_seq value is incremented by one. When a message is >> > > retransmitted, the old *message_seq value is re-used*, i.e., not >> > > incremented. From the perspective of the DTLS record layer, the >> > > retransmission is a new record. This record will have a *new* >> > > * DTLSPlaintext.sequence_number* value. >> > > >> > > >> > > In the section "7. ACK Message", the ACK message use the >> record_numbers >> > > (corresponds to *DTLSPlaintext.sequence_number*). >> > > >> > > For my understanding, the "message_seq" belongs to "Handshake" and the >> > > "sequence_number" or "record_numbers" belongs to >> > > record layer. >> > > >> > >> > Yes. >> > >> > The retransmission detection is done by "Handshake" using "message_seq", >> > > but the "acknowledge" is done by "record layer" using >> "record_numbers". >> > > It is so weird. >> > > >> > >> > Hmm... I don't think that this is particularly weird. This is, for >> > instance, how QUIC stream acknowledgement and retransmission works. >> > >> > >> > The retransmission, retransmission detection and acknowledge should be >> done >> > > in handshake process, but we need the record layer passing the >> > > record_numebrs to the handshake process. >> > > >> > > Since a new "sequence_number" is used for retransmission, we have to >> > > maintain a "record_numbers" to "message_seq" map with dynamic size. >> > > Each retransmission attempt creates a new relationship between a new >> > > "record_numbers" to an old "message_seq". >> > > >> > >> > Yes, that's how it works in NSS. >> > >> > >> > Since ACK is only used with Handshake messages, is it possible that we >> use >> > > "message_seq" in ACK messages? >> > > >> > Or we use *old* "sequence_number" for retransmission, >> > > >> > >> > Both of these give you strictly less information about the network. One >> of >> > the cool innovations in QUIC is to label each packet separately so you >> can >> > determine whether an ACK is an ACK of the original packet or a >> retransmit. >> > We are trying to inherit tha there >> > >> > -Ekr >> > >> > so we do not need maintain the dynamic map. And if replay detection is >> > > implemented, the retransmitted >> > > record can be dropped by record layer (by replay detection), the >> > > "Handshake Protocol" do not need to do retransmission detection. >> > > >> > > Thanks >> > > Zhai Zhaoxuan >> > > _______________________________________________ >> > > 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 >> >> --0000000000006140870598b6c74d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for my mistake.

The=C2=A0HelloVerifyReq= uest in the previous email should be replace with "HelloRetryRequest&q= uot;.


On Mon, Dec 2, 2019 at 7:17 PM X= uan k <kxuanobj@gmail.com> = wrote:
Hi Ben,

Thanks for your reply.=C2=A0= But we understand may not be the same.

Since ACK messag= es are not retransmitted, I think they should not consume message_seqs.
If an ACK really use a message_seq and it is lost in network, new han= dshake records will
always use a larger message_seq than the peer= expected (next_receive_seq).
The peer will unable to continue th= e handshake process.

And I think the ServerH= ello in the figure should start with 1, as the figure shows.
The = message_seq =3D 0 is used by HelloVerifyRequest, which is also been process= ed by client
and been fed into its transcript hash function.=C2= =A0

So I think the HelloVerifyRequest should be co= unted and new ServerHello in the figure
should start with message= _seq =3D 1.

Thanks,

Zhai = Zhaoxuan

On Mon, Dec 2, 2019 at 3:54 PM Benjamin Kaduk <bkaduk@akamai.com> w= rote:
That might= be an artifact from Ack having at one point (the -00) been
a handshake message.=C2=A0 Though, it seems that the Server's message_s= eq
space should also start at 0 with ServerHello, if I am understanding correc= tly.

-Ben

On Thu, Nov 28, 2019 at 03:15:38PM +0800, Xuan k wrote:
>=C2=A0 Hi Ekr,
>
> Thanks for your help.
>
> I have another question about the "message_seq" in section &= quot;6. Example of
> Handshake with Timeout and Retransmission".
> Could you please explain it?
>
> In the secion 6, the Client send message_seq =3D 0 in Record 0 and
> message_seq =3D 2,3,4 in Record 2.
>
> Why message_seq =3D 1 is skipped by Client?
> I think the ClientHello in the figure should begin with message_seq=3D= 1. The
> message_seq =3D 0 is used by the first ClientHello which is the one wi= thout
> cookies.
>
>
> Thanks,
> Zhai Zhaoxuan
>
> On 11/28/19 5:37 AM, Eric Rescorla wrote:
>
>
>
> On Tue, Nov 26, 2019 at 10:05 PM Xuan k <kxuanobj@gmail.com> wrote:
>
> > Hi all,
> >
> > I'm trying to implement a DTLS1.3 library for embedded device= s. But It
> > seems something weird about retransmissions and ACKs.
> >
> > In the section "5.2. DTLS Handshake Message Format": > >
> >=C2=A0 =C2=A0 The first message each side transmits in each associ= ation always has
> >=C2=A0 =C2=A0 message_seq =3D 0.=C2=A0 Whenever a new message is g= enerated, the
> >=C2=A0 =C2=A0 message_seq value is incremented by one.=C2=A0 When = a message is
> >=C2=A0 =C2=A0 retransmitted, the old *message_seq value is re-used= *, i.e., not
> >=C2=A0 =C2=A0 incremented.=C2=A0 From the perspective of the DTLS = record layer, the
> >=C2=A0 =C2=A0 retransmission is a new record.=C2=A0 This record wi= ll have a *new*
> > *=C2=A0 =C2=A0DTLSPlaintext.sequence_number* value.
> >
> >
> > In the section "7. ACK Message", the ACK message use th= e record_numbers
> > (corresponds to *DTLSPlaintext.sequence_number*).
> >
> > For my understanding, the "message_seq" belongs to &quo= t;Handshake" and the
> > "sequence_number" or "record_numbers" belongs= to
> > record layer.
> >
>
> Yes.
>
> The retransmission detection is done by "Handshake" using &q= uot;message_seq",
> > but the "acknowledge" is done by "record layer&quo= t; using "record_numbers".
> > It is so weird.
> >
>
> Hmm... I don't think that this is particularly weird. This is, for=
> instance, how QUIC stream acknowledgement and retransmission works. >
>
> The retransmission, retransmission detection and acknowledge should be= done
> > in handshake process, but we need the record layer passing the > > record_numebrs to the handshake process.
> >
> > Since a new "sequence_number" is used for retransmissio= n, we have to
> > maintain a "record_numbers" to "message_seq" = map with dynamic size.
> > Each retransmission attempt creates a new relationship between a = new
> > "record_numbers" to an old "message_seq".
> >
>
> Yes, that's how it works in NSS.
>
>
> Since ACK is only used with Handshake messages, is it possible that we= use
> > "message_seq" in ACK messages?
> >
> Or we use *old* "sequence_number" for retransmission,
> >
>
> Both of these give you strictly less information about the network. On= e of
> the cool innovations in QUIC is to label each packet separately so you= can
> determine whether an ACK is an ACK of the original packet or a retrans= mit.
> We are trying to inherit tha there
>
> -Ekr
>
> so we do not need maintain the dynamic map. And if replay detection is=
> > implemented, the retransmitted
> > record can be dropped by record layer (by replay detection), the<= br> > > "Handshake Protocol" do not need to do retransmission d= etection.
> >
> > Thanks
> > Zhai Zhaoxuan
> > _______________________________________________
> > 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

--0000000000006140870598b6c74d-- From nobody Mon Dec 2 05:35:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5E7120274 for ; Mon, 2 Dec 2019 05:35:09 -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 XLAio5eVKlfX for ; Mon, 2 Dec 2019 05:35:05 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3991B12006D for ; Mon, 2 Dec 2019 05:35:05 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id v201so26931151lfa.11 for ; Mon, 02 Dec 2019 05:35:05 -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=3PJs95NOGsdV7fXxd+XEM0GbWWQLX2nSnvKBzfu2bks=; b=TpKwfHEyYMQkUic0S0iuNfnv4+qApLHct7Et43fjcWZexplrgAPISqjVs/mQy7z5ZU v3uDaFWzsFEMiwz9zUltuSiVlqrm2m4CZnsKz+d7vZ/cip0J5j9ZAyow1/Yc0A+7cXWS d2DUEYcYRYRufEG3cZkRyCGzoq2drIOlw77g1XD2YOiD8z1PQhNF1V6ruEP9ctc7lfJI 8whhqdrnLX8Ou2oXBogu9Pnb1C8aJ7E5ONHhnfo+l4cGWMCgyojPZwlSKYoTGo2AYA6R PUZXpwPTCqKCzK0GJ7a3Ll7lGbDrgCahnMlB0ip633YVczm1JBvH2ifMobYc2dgu1wgV Lrnw== 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=3PJs95NOGsdV7fXxd+XEM0GbWWQLX2nSnvKBzfu2bks=; b=mUinQbsgEMEtLWrYp+cEPSniy/ip0z539VlGbQSqriHD+ZNdRWotBKZ+bj/Juvsu5G dAavlGfsyP2Ljem4voLzxj/4mv0b3UIvKrDdvqbrur73Yt7udFhqfWjqdJ7d8nkpmVg2 LuUDj+UO9UK7OJJDsgUtnFDbc5RZwmYfi9adxKhCVNEy+t/+ap9+x3AsBhcNNm7I+EQY +oBO5I+8cG/WHIzsNLAxLg3AFl2Ak7BxgO1b/dt0oe6bthvZtp3q256zm4IL6EnuaJ8S dp35vLPGtIf1Y2qMgpN3drUi5reYmIVfuVLA3++9DiWRBlswfSZ6b7EM6EZi6kyFrbXi jUIA== X-Gm-Message-State: APjAAAXpThhFXYQDUpzhfHbolMaYzhb1MODZrsuZEF/jdsKOdwQ/TD1J w8RSwGxLuS5dGxcJWG5IgUOTmnkRYTup2BtNVLWT8ok4 X-Google-Smtp-Source: APXvYqxuxauj3bMC0ErjaRBbwDLq+fThbpVijJJHC6MzgVKFbvkbRAG2/rIdyE8kPZdO53XdGEy+uSIyCd1d93RZXVo= X-Received: by 2002:a19:7b1a:: with SMTP id w26mr2490749lfc.17.1575293702467; Mon, 02 Dec 2019 05:35:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 2 Dec 2019 05:34:25 -0800 Message-ID: To: Xuan k Cc: "" Content-Type: multipart/alternative; boundary="0000000000008d87a80598b8a5ae" Archived-At: Subject: Re: [TLS] [DTLS1.3]About the retransmission of Handshake records 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, 02 Dec 2019 13:35:10 -0000 --0000000000008d87a80598b8a5ae Content-Type: text/plain; charset="UTF-8" U On Wed, Nov 27, 2019 at 11:16 PM Xuan k wrote: > Hi Ekr, > > Thanks for your help. > > I have another question about the "message_seq" in section "6. Example of > Handshake with Timeout and Retransmission". > Could you please explain it? > > In the secion 6, the Client send message_seq = 0 in Record 0 and > message_seq = 2,3,4 in Record 2. > > Why message_seq = 1 is skipped by Client? > It's a typo in the example. The Certificate should be 1. I think the ClientHello in the figure should begin with message_seq=1. The > message_seq = 0 is used by the first ClientHello which is the one without > cookies. > I agree in principle, but that's not this example, because, as you can see, there is no HRR. Rather, this needs to remove +cookie. -Ekr > Thanks, > Zhai Zhaoxuan > > On 11/28/19 5:37 AM, Eric Rescorla wrote: > > > > On Tue, Nov 26, 2019 at 10:05 PM Xuan k wrote: > >> Hi all, >> >> I'm trying to implement a DTLS1.3 library for embedded devices. But It >> seems something weird about retransmissions and ACKs. >> >> In the section "5.2. DTLS Handshake Message Format": >> >> The first message each side transmits in each association always has >> message_seq = 0. Whenever a new message is generated, the >> message_seq value is incremented by one. When a message is >> retransmitted, the old *message_seq value is re-used*, i.e., not >> incremented. From the perspective of the DTLS record layer, the >> retransmission is a new record. This record will have a *new* >> * DTLSPlaintext.sequence_number* value. >> >> >> In the section "7. ACK Message", the ACK message use the record_numbers >> (corresponds to *DTLSPlaintext.sequence_number*). >> >> For my understanding, the "message_seq" belongs to "Handshake" and the >> "sequence_number" or "record_numbers" belongs to >> record layer. >> > > Yes. > > The retransmission detection is done by "Handshake" using "message_seq", >> but the "acknowledge" is done by "record layer" using "record_numbers". >> It is so weird. >> > > Hmm... I don't think that this is particularly weird. This is, for > instance, how QUIC stream acknowledgement and retransmission works. > > > The retransmission, retransmission detection and acknowledge should be >> done in handshake process, but we need the record layer passing the >> record_numebrs to the handshake process. >> >> Since a new "sequence_number" is used for retransmission, we have to >> maintain a "record_numbers" to "message_seq" map with dynamic size. >> Each retransmission attempt creates a new relationship between a new >> "record_numbers" to an old "message_seq". >> > > Yes, that's how it works in NSS. > > > Since ACK is only used with Handshake messages, is it possible that we use >> "message_seq" in ACK messages? >> > Or we use *old* "sequence_number" for retransmission, >> > > Both of these give you strictly less information about the network. One of > the cool innovations in QUIC is to label each packet separately so you can > determine whether an ACK is an ACK of the original packet or a retransmit. > We are trying to inherit tha there > > -Ekr > > so we do not need maintain the dynamic map. And if replay detection is >> implemented, the retransmitted >> record can be dropped by record layer (by replay detection), the >> "Handshake Protocol" do not need to do retransmission detection. >> >> Thanks >> Zhai Zhaoxuan >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --0000000000008d87a80598b8a5ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
U

On Wed, Nov 27, 2019 at 11:16 PM Xuan k <kxuanobj@gmail.com&= gt; wrote:
=20 =20 =20
Hi Ekr,

Thanks for your help.

I have another question about the "message_seq" in section &= quot;6. Example of Handshake with Timeout and Retransmission".
Could you please explain it?

In the secion 6, the Client send message_seq =3D 0 in Record 0 and mes= sage_seq =3D 2,3,4 in Record 2.

Why message_seq =3D 1 is skipped by Client?

It's a typo in the example. The Certifica= te should be 1.



I think the ClientHello in the figure should begin with message_seq=3D1. Th= e message_seq =3D 0 is used by the first ClientHello which is the=20 one without cookies.
=C2=A0
I agree in principle, = but that's not this example, because, as you can see, there is no HRR. = Rather, this needs to remove +cookie.

-Ekr

=

Thanks,
Zhai Zhaoxuan

On 11/28/19 5:37 AM, Eric Rescorla wrote:
=20


On Tue, Nov 26, 2019 at 10:05 PM Xuan k <kxuanobj@gmail.com> wrote:
Hi all,

I'm trying to implement a DTLS1.3 library for embedded devices. But It seems something weird about retransmissions and ACKs.

In the section "5.2. DTLS Handshake Message Format&= quot;:
=C2=A0 =C2=A0The first message each side transmits in = each association always has
=C2=A0 =C2=A0message_seq =3D 0.=C2=A0 Whenever a new m= essage is generated, the
=C2=A0 =C2=A0message_seq value is incremented by one.= =C2=A0 When a message is
=C2=A0 =C2=A0retransmitted, the old message_seq val= ue is re-used, i.e., not
=C2=A0 =C2=A0incremented.=C2=A0 From the perspective o= f the DTLS record layer, the
=C2=A0 =C2=A0retransmission is a new record.=C2=A0 Thi= s record will have a new
=C2=A0 =C2=A0DTLSPlaintext.sequence_number valu= e.

In the section "7. ACK Message", the ACK messa= ge use the record_numbers (corresponds to DTLSPlaintext.sequenc= e_number).

For my understanding, the "message_seq" belo= ngs to "Handshake" and the "sequence_number"= or "record_numbers" belongs to
record layer.

Yes.

The retransmission detection is done by "Handshak= e" using "message_seq", but the "acknowledge&= quot; is done by "record layer" using "record_numbers"= .
It is so weird.=C2=A0

Hmm... I don't think that this is particularly weird. This is, for instance, how QUIC stream acknowledgement and retransmission works.


The retransmission,=C2=A0retransmission detection and=C2=A0acknowledge should be done in handshake process, but we need the record layer passing the
record_numebrs to the handshake process.

Since a new "sequence_number" is used for retransmission, we have to maintain a "record_number= s" to "message_seq" map with dynamic size.
Each retransmission attempt creates a new relationship between a new "record_numbers" to an= old "message_seq".

Yes, that's how it works in NSS.


Since ACK is only used with Handshake messages, is it possible that we use "message_seq" in ACK message= s?
Or we use old "sequence_number" for retransmission,

Both of these give you strictly less information about the network. One of the cool innovations in QUIC is to label each packet separately so you can determine whether an ACK is an ACK of the original packet or a retransmit. We are trying to inherit tha there

-Ekr

so we do not need maintain the dynamic map. And if replay detection is implemented, the retransmitted
record can be dropped by record layer (by replay detection), the "Handshake Protocol" do not need = to do=C2=A0retransmission detection.

Thanks
Zhai Zhaoxuan
_______________________________________________
TLS mailing list
TLS@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/tls
--0000000000008d87a80598b8a5ae-- From nobody Mon Dec 2 06:18:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16E812006D for ; Mon, 2 Dec 2019 06:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=I3IykX0J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fud3rVq7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHmMfHQxe1vd for ; Mon, 2 Dec 2019 06:18:05 -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 8D85E12000F for ; Mon, 2 Dec 2019 06:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16884; q=dns/txt; s=iport; t=1575296285; x=1576505885; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D1sTRU6oHP9/06XMmj30DS055meYds69p8jgQjwKq/M=; b=I3IykX0JjhWXrgjDb7PoLODw9oknnVH6T28r5lnS+f2ztaUGSngvtEft vtbirsUXNbMir5iYRDPXPR2XJ1sBDT4nVPaDroXDoeZDSBQFShaYlk3An q1iduF+hQKRv5W2C9wSGvfuwUSAkGWy69agMm8W4yY3Wmk5oG6Jz1omM9 w=; IronPort-PHdr: =?us-ascii?q?9a23=3A4enlgxGuM3J3T6Y1e+T/1Z1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eebpZikiFcJLfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAQAuHOVd/4YNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBfoEcLyknBWxYIAQLKoQrg0YDinWCX4EBkiGEYoJSA1Q?= =?us-ascii?q?JAQEBDAEBGAEKCgIBAYRAAheBdCQ4EwIDDQEBBAEBAQIBBQRthTcMhVIBAQE?= =?us-ascii?q?BAwEBEAsGChMBASwLAQsEAgEIEQQBASgDAgICJQsUCQgCBA4FCBqDAYF5TQM?= =?us-ascii?q?uAQIMplwCgTiIYHWBMoJ+AQEFgUlBgncYghcDBoE2jBYagUE/gRFHghc1PoJ?= =?us-ascii?q?kAQEDAYFJCQ8rCYJaMoIsjQuDD4VMmFwKgi6HHoUniS+CQYdtj3WXBpFbAgQ?= =?us-ascii?q?CBAUCDgEBBYFpIoFYcBU7gmxQERSMZoEnAQyCP4UUhT90gSiNZ4I/AQE?= X-IronPort-AV: E=Sophos;i="5.69,268,1571702400"; d="scan'208,217";a="669006817" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Dec 2019 14:18:04 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xB2EI11J023898 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Dec 2019 14:18:02 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Dec 2019 08:18:01 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Dec 2019 08:18:00 -0600 Received: from NAM04-BN3-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, 2 Dec 2019 08:18:00 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=duSGLTKmzwnP+Qg3p/xkhuVOQitp8jj8G8c5sliPEcz9d/LxMrbkmtdEOQ5uLrF5gBDSUkuDccc6fbVHsOTcvSl4cb/UTkKYdZje3cCRWVWmK1c+2NGY/gXWaFXVN4G2LHwKPihrZZFOktrrqnnJNdeqGhju6kOZJwQJliwMnTb5eguTogL/NtxB3Gwo/gOVdMOI47S4G1BxWyhGtIgZzHRJ246ppBreuYVREzDdeFJ+XxoWjDQegh8UloLDDblGGUejti/wZjTsuiYw+czGbjhriXKVwavFQk2p4v3oD6L6l5UXesaR57jgRcqqqlS4cFGwiMk1H8sEF4/ajgcKtg== 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=D1sTRU6oHP9/06XMmj30DS055meYds69p8jgQjwKq/M=; b=WiQoUjjU1SkJVH8L44y2oW/ah5KDenY3G/RNITGqIEx39jfSOPeXEUjMC1uNaDQlBebqAzY38sTIsehdg9dsuAK3tKWFKY/ClPBAZQGW6dqhelLSInv9tRjywTiHKkRtyth3ZY4tfKzjcrc7y83QSMMq4ITC3xumgPAkce9fEpU2ZwhFxUxKPLmBnZ6dl85uJgmY1T+lS/ft1vI+Pe4uhf5j54Q6eM7GHQg98O3MlO4s6ksT44CviCVkQPjyA/1752JOFK/ekKXmzw1MSHr8CLMtl98MdStmIUZdTfqD/LCvogC9a/kNZtaS9r004Td/kxLJ24E+kjTrWSTElqwEIQ== 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=D1sTRU6oHP9/06XMmj30DS055meYds69p8jgQjwKq/M=; b=fud3rVq7liaehQsjcCODCV0U0woDqioeXcTQwLf1p+Gg3TsYc2+edshnlk867VC/KgJ4fHRFGfghkVTQXNxd5ZF778dxPmjeGxzikTPQGCkBV47uTHIh5rbnGPXG0chIgrC6lxigfE7EqsjtBvTqw+xU/sjWDSfGcORmf2N27s4= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2737.namprd11.prod.outlook.com (52.135.244.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.19; Mon, 2 Dec 2019 14:17:59 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2495.014; Mon, 2 Dec 2019 14:17:59 +0000 From: "Panos Kampanakis (pkampana)" To: David Benjamin CC: Sean Turner , TLS List Thread-Topic: [TLS] Adoption call for draft-davidben-tls-batch-signing Thread-Index: AQHVoMubo2uwrcUz4kKnCRDJOcjVN6em8dBg Date: Mon, 2 Dec 2019 14:17:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::10c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d7f1cedc-3162-47f2-05ab-08d777326f11 x-ms-traffictypediagnostic: BN7PR11MB2737: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(396003)(376002)(346002)(39860400002)(199004)(189003)(13464003)(99286004)(46003)(81156014)(81166006)(6116002)(66946007)(790700001)(66476007)(64756008)(8936002)(66556008)(66446008)(8676002)(76116006)(6916009)(229853002)(25786009)(5660300002)(2906002)(52536014)(102836004)(6506007)(446003)(11346002)(186003)(53546011)(76176011)(54906003)(86362001)(71190400001)(71200400001)(7696005)(256004)(316002)(14444005)(55016002)(6246003)(9686003)(236005)(478600001)(4326008)(6436002)(54896002)(14454004)(966005)(7736002)(6306002)(74316002)(606006)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2737; 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: 3nc2G8dQJfYdVs8Ozj431+VItYdeajGhedtO6ZbUq8EoApVowvXhUk/9jK+a+/84Rz3G1gowPcKkaqT/FiU8x9pPxJs7kv199o2ZLxE2ULyN9YvMIe79RP1/WE6uf22o7+l4JMhZmla3c4T7HTA6HIxKVek/aoGufyGWp5xLtwmZwJrpl7SXf2lLFPqeJCqCh56nqu24Oa4fJ8MMRQX+O1HitcWJ/g4RYRUEV3wVtpcI4LriT/7uhkpc3cBNGPtTC0gAj+IbAjn2JK+jWI6VJchw3JYE28if4/a59NqX548zjgbB/fa1hKVa9MvIt/ND7lPvyaYUOTV3VCQ8jCQcam2XMB6Qb3Cpnmn9yBx+8LQYgdq3gth9Agj0oZdHGMjKXi6xF/SKIbKKZJizN8CsJOXkPCq8JgZ/ZemBFLDROcJsU7Kp4g5pt9WFTkcQo4eG1RZs1G1klvXpo6VOxXAJpqhv4ZJa6OX/FE8+Akpurvo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB25476085C61E094BCF8A8BEFC9430BN7PR11MB2547namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d7f1cedc-3162-47f2-05ab-08d777326f11 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 14:17:59.0591 (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: CRXiM2aY92GRP9wsvhNAEYsmATC/WwgRvYuxuOSXogt84zo36g9eNLO13RXjskmxrFb2TDPDj241muO29FYP1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2737 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing 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, 02 Dec 2019 14:18:10 -0000 --_000_BN7PR11MB25476085C61E094BCF8A8BEFC9430BN7PR11MB2547namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERhdmlkLCB1bmRlcnN0b29kLg0KDQpJdCBzb3VuZHMgdGhhdCBpdCB3b3VsZCBiZSBl YXNpZXIgdG8gc3dpdGNoIGF3YXkgZnJvbSBSU0EgdG8gYXZvaWQgdGhlIGV4dHJhIGNvbXBsaWNh dGlvbnMgb2YgYmF0Y2hpbmcsIGJ1dCBJIHVuZGVyc3RhbmQgdGhhdCBpcyBub3QgYWx3YXlzIHBv c3NpYmxlLiBHaXZlbiB0aGF0IHRoaXMgaXMgYW4gRXhwZXJpbWVudGFsIGRyYWZ0LCBJIGFtIG9r IHdpdGggdGhlIFdHIGFkb3B0aW5nIGl0LCBnaXZlbiB0aGF0IGl0IGhhcyBtZXJpdCBmb3Igc29t ZSB2ZW5kb3Jz4oCZIHVzZWNhc2VzLg0KDQoNCg0KRnJvbTogRGF2aWQgQmVuamFtaW4gPGRhdmlk YmVuQGNocm9taXVtLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyMSwgMjAxOSA3OjI3 IFBNDQpUbzogUGFub3MgS2FtcGFuYWtpcyAocGthbXBhbmEpIDxwa2FtcGFuYUBjaXNjby5jb20+ DQpDYzogU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPjsgVExTIExpc3QgPHRsc0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbVExTXSBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1kYXZpZGJlbi10 bHMtYmF0Y2gtc2lnbmluZw0KDQpEZXBsb3ltZW50cyB3aG9zZSBsb25nLXRlcm0gcHJpdmF0ZSBr ZXkgaXMgYW4gRUNEU0Egb3IgRWREU0Ega2V5IHN0b3JlZCBpbiBtZW1vcnkgcHJvYmFibHkgaGF2 ZSBubyBwYXJ0aWN1bGFyIG5lZWQgZm9yIHRoaXMsIG5vLiBTdWNoIGRlcGxveW1lbnRzIHByb2Jh Ymx5IHNlZSBhIHNpZ25hdHVyZSBjb3N0IGNvbXBhcmFibGUgdG8gdGhlIEVDREggY29zdCB0aGlz IGRvY3VtZW50IGRvZXMgbm90IGFtb3J0aXNlLiBUaGUgZXhpc3Rpbmcgc2lnbmF0dXJlIGFsZ29y aXRobXMgYXJlIHN1ZmZpY2llbnQgYW5kIG5vIG9uZSdzIHByb3Bvc2luZyByZW1vdmluZyB0aGVt Lg0KDQpIb3dldmVyLCB0aGVyZSBhcmUgbWFueSBkZXBsb3ltZW50cyB3aGVyZSB0aGF0IGlzIG5v dCB0aGUgY2FzZS4gSG9zdGluZyBwcm92aWRlcnMgb2Z0ZW4gZ2V0IHRoZWlyIGNlcnRpZmljYXRl cyBhbmQga2V5cyBmcm9tIGN1c3RvbWVycywgd2hvIG1heSBqdXN0IHVwbG9hZCBhbiBSU0Ega2V5 LiBSU0Ega2V5cyBhcmUgZXhwZW5zaXZlIGVub3VnaCB0byBiZSB0aGUgdGFyZ2V0IG9mIERvUyBh dHRhY2tzLiBCZXlvbmQgdGhhdCwgbG9uZy10ZXJtIGNyZWRlbnRpYWxzIGFyZSB2ZXJ5IHNlbnNp dGl2ZSBhbmQsIHllcywgdGhlcmUgYXJlIGRlcGxveW1lbnRzIHRoYXQgUlBDIHRvIGEgcmVtb3Rl IGxvY2F0aW9uIG9yIGV2ZW4gdXNlIGhhcmR3YXJlIG1vZHVsZXMuIER1ZSB0byBwZXJmb3JtYW5j ZSwgSSBkb3VidCB0aGUgaGFyZHdhcmUgbW9kdWxlIGlzIGNvbW1vbiBmb3Igc2VydmVyIGtleXMs IGJ1dCB0aGlzIGRyYWZ0IGNhbiBhcHBseSBpbiBib3RoIGRpcmVjdGlvbnMuIFdlJ3ZlIHNlZW4g Y2xpZW50IGNlcnRpZmljYXRlIGRlcGxveW1lbnRzIHRoYXQgZG8gdGhpcyBhbmQgaGl0IHBlcmZv cm1hbmNlIHByb2JsZW1zIHdoZW4gdGhlIGhhcmR3YXJlIGNhbm5vdCBldmVuIGtlZXAgdXAgd2l0 aCBjbGllbnQgY29ubmVjdGlvbiBsb2Fkcy4gQmF0Y2ggc2lnbmluZyBpcyBhaW1lZCBhdCB0aGVz ZSBraW5kcyBvZiBzY2VuYXJpb3MuDQoNCllvdSdyZSByaWdodCB0aGF0IHBlZXJzIG5lZWQgdG8g YmUgdXBkYXRlZCwgYnV0IHVudXBncmFkZWQgcGVlcnMgZG8gbm90IGJsb2NrIHJlc3VsdHMuIExv YWQgZGVjcmVhc2VzIGFzIHBlZXJzIGFkb3B0IHRoaXMgYW5kIERvUyBtaXRpZ2F0aW9ucyBvZnRl biBpbnZvbHZlIHNlbGVjdGl2ZWx5IHNlcnZpbmcgYW5kIGRyb3BwaW5nIHJlcXVlc3RzIGJhc2Vk IG9uIGZhY3RvcnMgc3VjaCBhcyBjb3N0LiBUaGlzIGRlY3JlYXNlcyB0aGUgY29zdCBvZiBhIGNs YXNzIG9mIHJlcXVlc3RzLCB3aGljaCBhbGxvd3Mgc2lnbmVycyB1bmRlciBsb2FkIHRvIHNlcnZl IG1vcmUgb2YgdGhlbS4NCg0KRm9yIG15IHBhcnQgaW4gdGhlIGNsaWVudCBzcGFjZSwgd2UgYXJl IGludGVyZXN0ZWQgaW4gaW1wbGVtZW50aW5nIHRoaXMgaW4gQm9yaW5nU1NMIGFuZCBDaHJvbWUu DQoNCk9uIEZyaSwgTm92IDIyLCAyMDE5IGF0IDEyOjQwIEFNIFBhbm9zIEthbXBhbmFraXMgKHBr YW1wYW5hKSA8cGthbXBhbmFAY2lzY28uY29tPG1haWx0bzpwa2FtcGFuYUBjaXNjby5jb20+PiB3 cm90ZToNCkkgYW0gbm90IGluIGZhdm9yIG9mIGFkb3B0aW9uLCBidXQgSSBjb3VsZCBiZSBjb252 aW5jZWQgb3RoZXJ3aXNlLg0KDQpTb3JyeSBhcyB0aGlzIG1heSBoYXZlIGJlZW4gZGlzY3Vzc2Vk IGluIElFVEYtMTA2LCBidXQgYXJlIHdlIHRoYXQgd29ycmllZCBhYm91dCB0aGUgQ1BVIGNvc3Qg b2YgRUNEU0Egb3IgRWREU0EgdGhhdCB3ZSBhcmUgd2lsbGluZyB0byBoYXZlIHRoZSBzZXJ2ZXIg YnVmZmVyL3Nsb3cgZG93biBjbGllbnQgY29ubmVjdGlvbnMsIGdlbmVyYXRlIHRoZSBNZXJrbGUg dHJlZSBhbmQgdGhlIGJhdGNoIHNpZ25hdHVyZT8gRG8gd2UgcmVhbGx5IHB1bGwgdGhlIHByaXZh dGUga2V5IGZyb20gYSBoYXJkd2FyZSBtb2R1bGUgb3IgcmVtb3RlIGxvY2F0aW9uIHdpdGggZXZl cnkgc2lnbmF0dXJlIGluc3RlYWQgb2Yga2VlcGluZyBpdCBpbiB2b2xhdGlsZSBtZW1vcnkgaW4g b3VyIGFwcGxpY2F0aW9uPw0KDQpJIGZpbmQgaXQgaGFyZCB0byBidXkgdGhlIHByb2JsZW0gc3Rh dGVtZW50IGJhc2VkIG9uIHRoZSB1c2VjYXNlcyBJIGtub3cgb2YsIGFuZCBzdWNoIGEgZHJhZnQg d291bGQgcmVxdWlyZSBhIGxvdCBvZiBjbGllbnQgdXBncmFkZXMgYW5kIHBhcnRpY2lwYXRpb24g aW4gb3JkZXIgdG8gaGF2ZSBmcnVpdGZ1bCByZXN1bHRzLiBJIGFtIHJlYWR5IHRvIGJ1eSB0aGUg YXJndW1lbnQsIGlmIHRoZXJlIGlzIGNvbmNyZXRlIGRhdGEgb24gYWN0dWFsIHVzZWNhc2VzLg0K DQpSZ3MsDQpQYW5vcw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRM UyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPj4gT24g QmVoYWxmIE9mIFNlYW4gVHVybmVyDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjEsIDIwMTkg MTo1NyBBTQ0KVG86IFRMUyBMaXN0IDx0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4+ DQpTdWJqZWN0OiBbVExTXSBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1kYXZpZGJlbi10bHMtYmF0 Y2gtc2lnbmluZw0KDQpBdCBJRVRGIDEwNiB0aGVyZSB3YXMgc3VwcG9ydCBmb3IgYWRvcHRpb24g b2YgIkJhdGNoIFNpZ25pbmcgZm9yIFRMUyIgWzBdIGFzIGEgV0cgaXRlbS4gIFRvIGNvbmZpcm0g dGhpcyBvbiB0aGUgbGlzdDogaWYgeW91IGJlbGlldmUgdGhhdCB0aGUgVExTIFdHIHNob3VsZCBu b3QgYWRvcHQgdGhpcyBhcyBhIFdHIGl0ZW0sIHRoZW4gcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtu b3cgYnkgcG9zdGluZyBhIG1lc3NhZ2UgdG8gdGhlIFRMUyBsaXN0IGJ5IDIzNTkgVVRDIDEzIERl Y2VtYmVyIDIwMTkgKGFuZCBzYXkgd2h5KS4NCg0KTk9URToNCjogSWYgdGhlIGNvbnNlbnN1cyBp cyB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIGJlIGFkb3B0ZWQgYXMgYSBXRyBpdGVtLCB0aGVuIHRo aXMgd2lsbCBuZWNlc3NhcmlseSByZXN1bHQgaW4gYSBXRyByZWNoYXJ0ZXJpbmcgZGlzY3Vzc2lv bnMuICBXZSB3b3VsZCBoYXZlIGdvdHRlbiB0byB0aGlzIHJlY2hhcnRlcmluZyBkaXNjdXNzaW9u IGFueXdheSBub3cgdGhhdCBEVExTIDEuMyBpcyBwcm9ncmVzc2luZyBvdXQgb2YgdGhlIFdHLg0K DQpUaGFua3MsDQpDaHJpcywgSm9lLCBhbmQgU2Vhbg0KDQpbMF0gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZGF2aWRiZW4tdGxzLWJhdGNoLXNpZ25pbmcvDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlz dA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpU TFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K --_000_BN7PR11MB25476085C61E094BCF8A8BEFC9430BN7PR11MB2547namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIERhdmlkLCB1bmRl cnN0b29kLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IHNvdW5kcyB0 aGF0IGl0IHdvdWxkIGJlIGVhc2llciB0byBzd2l0Y2ggYXdheSBmcm9tIFJTQSB0byBhdm9pZCB0 aGUgZXh0cmEgY29tcGxpY2F0aW9ucyBvZiBiYXRjaGluZywgYnV0IEkgdW5kZXJzdGFuZCB0aGF0 IGlzIG5vdCBhbHdheXMgcG9zc2libGUuIEdpdmVuIHRoYXQgdGhpcyBpcyBhbiBFeHBlcmltZW50 YWwgZHJhZnQsIEkgYW0gb2sgd2l0aCB0aGUNCiBXRyBhZG9wdGluZyBpdCwgZ2l2ZW4gdGhhdCBp dCBoYXMgbWVyaXQgZm9yIHNvbWUgdmVuZG9yc+KAmSB1c2VjYXNlcy4gPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IERhdmlk IEJlbmphbWluICZsdDtkYXZpZGJlbkBjaHJvbWl1bS5vcmcmZ3Q7IDxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgTm92ZW1iZXIgMjEsIDIwMTkgNzoyNyBQTTxicj4NCjxiPlRvOjwvYj4gUGFu b3MgS2FtcGFuYWtpcyAocGthbXBhbmEpICZsdDtwa2FtcGFuYUBjaXNjby5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBTZWFuIFR1cm5lciAmbHQ7c2VhbkBzbjNyZC5jb20mZ3Q7OyBUTFMgTGlzdCAm bHQ7dGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gQWRvcHRp b24gY2FsbCBmb3IgZHJhZnQtZGF2aWRiZW4tdGxzLWJhdGNoLXNpZ25pbmc8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZXBsb3ltZW50cyB3aG9zZSBsb25nLXRlcm0gcHJp dmF0ZSBrZXkgaXMgYW4gRUNEU0Egb3IgRWREU0Ega2V5IHN0b3JlZCBpbiBtZW1vcnkgcHJvYmFi bHkgaGF2ZSBubyBwYXJ0aWN1bGFyIG5lZWQgZm9yIHRoaXMsIG5vLiBTdWNoIGRlcGxveW1lbnRz IHByb2JhYmx5IHNlZSBhIHNpZ25hdHVyZSBjb3N0IGNvbXBhcmFibGUgdG8gdGhlIEVDREggY29z dCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGFtb3J0aXNlLg0KIFRoZSBleGlzdGluZyBzaWduYXR1 cmUgYWxnb3JpdGhtcyBhcmUgc3VmZmljaWVudCBhbmQgbm8gb25lJ3MgcHJvcG9zaW5nIHJlbW92 aW5nIHRoZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhvd2V2ZXIsIHRoZXJlIGFyZSBtYW55IGRlcGxveW1lbnRzIHdoZXJlIHRoYXQgaXMg bm90IHRoZSBjYXNlLiBIb3N0aW5nIHByb3ZpZGVycyBvZnRlbiBnZXQgdGhlaXIgY2VydGlmaWNh dGVzIGFuZCBrZXlzIGZyb20gY3VzdG9tZXJzLCB3aG8gbWF5IGp1c3QgdXBsb2FkIGFuIFJTQSBr ZXkuIFJTQSBrZXlzIGFyZSBleHBlbnNpdmUgZW5vdWdoIHRvIGJlIHRoZSB0YXJnZXQgb2YgRG9T IGF0dGFja3MuIEJleW9uZA0KIHRoYXQsIGxvbmctdGVybSBjcmVkZW50aWFscyBhcmUgdmVyeSBz ZW5zaXRpdmUgYW5kLCB5ZXMsIHRoZXJlIGFyZSBkZXBsb3ltZW50cyB0aGF0IFJQQyB0byBhIHJl bW90ZSBsb2NhdGlvbiBvciBldmVuIHVzZSBoYXJkd2FyZSBtb2R1bGVzLiBEdWUgdG8gcGVyZm9y bWFuY2UsIEkgZG91YnQgdGhlIGhhcmR3YXJlIG1vZHVsZSBpcyBjb21tb24gZm9yIHNlcnZlciBr ZXlzLCBidXQgdGhpcyBkcmFmdCBjYW4gYXBwbHkgaW4gYm90aCBkaXJlY3Rpb25zLg0KIFdlJ3Zl IHNlZW4gY2xpZW50IGNlcnRpZmljYXRlIGRlcGxveW1lbnRzIHRoYXQgZG8gdGhpcyBhbmQgaGl0 IHBlcmZvcm1hbmNlIHByb2JsZW1zIHdoZW4gdGhlIGhhcmR3YXJlIGNhbm5vdCBldmVuIGtlZXAg dXAgd2l0aA0KPGk+Y2xpZW50PC9pPiZuYnNwO2Nvbm5lY3Rpb24gbG9hZHMuIEJhdGNoIHNpZ25p bmcgaXMgYWltZWQgYXQgdGhlc2Uga2luZHMgb2Ygc2NlbmFyaW9zLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UncmUgcmlnaHQgdGhhdCBw ZWVycyBuZWVkIHRvIGJlIHVwZGF0ZWQsIGJ1dCB1bnVwZ3JhZGVkIHBlZXJzIGRvIG5vdCBibG9j ayByZXN1bHRzLiBMb2FkIGRlY3JlYXNlcyBhcyBwZWVycyBhZG9wdCB0aGlzIGFuZCBEb1MgbWl0 aWdhdGlvbnMgb2Z0ZW4gaW52b2x2ZSBzZWxlY3RpdmVseSBzZXJ2aW5nIGFuZCBkcm9wcGluZyBy ZXF1ZXN0cyBiYXNlZCBvbiBmYWN0b3JzIHN1Y2ggYXMgY29zdC4gVGhpcyBkZWNyZWFzZXMNCiB0 aGUgY29zdCBvZiBhIGNsYXNzIG9mIHJlcXVlc3RzLCB3aGljaCBhbGxvd3Mgc2lnbmVycyB1bmRl ciBsb2FkIHRvIHNlcnZlIG1vcmUgb2YgdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIG15IHBhcnQgaW4gdGhlIGNsaWVudCBzcGFj ZSwgd2UgYXJlIGludGVyZXN0ZWQgaW4gaW1wbGVtZW50aW5nIHRoaXMgaW4gQm9yaW5nU1NMIGFu ZCBDaHJvbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBGcmksIE5vdiAyMiwgMjAxOSBhdCAxMjo0MCBBTSBQYW5vcyBLYW1wYW5ha2lzIChwa2FtcGFu YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwa2FtcGFuYUBjaXNjby5jb20iPnBrYW1wYW5hQGNpc2Nv LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgaW4gZmF2b3Igb2YgYWRvcHRpb24sIGJ1dCBJ IGNvdWxkIGJlIGNvbnZpbmNlZCBvdGhlcndpc2UuPGJyPg0KPGJyPg0KU29ycnkgYXMgdGhpcyBt YXkgaGF2ZSBiZWVuIGRpc2N1c3NlZCBpbiBJRVRGLTEwNiwgYnV0IGFyZSB3ZSB0aGF0IHdvcnJp ZWQgYWJvdXQgdGhlIENQVSBjb3N0IG9mIEVDRFNBIG9yIEVkRFNBIHRoYXQgd2UgYXJlIHdpbGxp bmcgdG8gaGF2ZSB0aGUgc2VydmVyIGJ1ZmZlci9zbG93IGRvd24gY2xpZW50IGNvbm5lY3Rpb25z LCBnZW5lcmF0ZSB0aGUgTWVya2xlIHRyZWUgYW5kIHRoZSBiYXRjaCBzaWduYXR1cmU/IERvIHdl IHJlYWxseSBwdWxsIHRoZQ0KIHByaXZhdGUga2V5IGZyb20gYSBoYXJkd2FyZSBtb2R1bGUgb3Ig cmVtb3RlIGxvY2F0aW9uIHdpdGggZXZlcnkgc2lnbmF0dXJlIGluc3RlYWQgb2Yga2VlcGluZyBp dCBpbiB2b2xhdGlsZSBtZW1vcnkgaW4gb3VyIGFwcGxpY2F0aW9uPzxicj4NCjxicj4NCkkgZmlu ZCBpdCBoYXJkIHRvIGJ1eSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYmFzZWQgb24gdGhlIHVzZWNh c2VzIEkga25vdyBvZiwgYW5kIHN1Y2ggYSBkcmFmdCB3b3VsZCByZXF1aXJlIGEgbG90IG9mIGNs aWVudCB1cGdyYWRlcyBhbmQgcGFydGljaXBhdGlvbiBpbiBvcmRlciB0byBoYXZlIGZydWl0ZnVs IHJlc3VsdHMuIEkgYW0gcmVhZHkgdG8gYnV5IHRoZSBhcmd1bWVudCwgaWYgdGhlcmUgaXMgY29u Y3JldGUgZGF0YSBvbiBhY3R1YWwgdXNlY2FzZXMuPGJyPg0KPGJyPg0KUmdzLDxicj4NClBhbm9z PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpG cm9tOiBUTFMgJmx0OzxhIGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnRscy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIFNlYW4g VHVybmVyPGJyPg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIxLCAyMDE5IDE6NTcgQU08YnI+ DQpUbzogVExTIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFtUTFNdIEFkb3B0aW9u IGNhbGwgZm9yIGRyYWZ0LWRhdmlkYmVuLXRscy1iYXRjaC1zaWduaW5nPGJyPg0KPGJyPg0KQXQg SUVURiAxMDYgdGhlcmUgd2FzIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mICZxdW90O0JhdGNoIFNp Z25pbmcgZm9yIFRMUyZxdW90OyBbMF0gYXMgYSBXRyBpdGVtLiZuYnNwOyBUbyBjb25maXJtIHRo aXMgb24gdGhlIGxpc3Q6IGlmIHlvdSBiZWxpZXZlIHRoYXQgdGhlIFRMUyBXRyBzaG91bGQgbm90 IGFkb3B0IHRoaXMgYXMgYSBXRyBpdGVtLCB0aGVuIHBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93 IGJ5IHBvc3RpbmcgYSBtZXNzYWdlIHRvIHRoZSBUTFMgbGlzdCBieQ0KIDIzNTkgVVRDIDEzIERl Y2VtYmVyIDIwMTkgKGFuZCBzYXkgd2h5KS48YnI+DQo8YnI+DQpOT1RFOjxicj4NCjogSWYgdGhl IGNvbnNlbnN1cyBpcyB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIGJlIGFkb3B0ZWQgYXMgYSBXRyBp dGVtLCB0aGVuIHRoaXMgd2lsbCBuZWNlc3NhcmlseSByZXN1bHQgaW4gYSBXRyByZWNoYXJ0ZXJp bmcgZGlzY3Vzc2lvbnMuJm5ic3A7IFdlIHdvdWxkIGhhdmUgZ290dGVuIHRvIHRoaXMgcmVjaGFy dGVyaW5nIGRpc2N1c3Npb24gYW55d2F5IG5vdyB0aGF0IERUTFMgMS4zIGlzIHByb2dyZXNzaW5n IG91dCBvZiB0aGUgV0cuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkNocmlzLCBKb2UsIGFuZCBT ZWFuPGJyPg0KPGJyPg0KWzBdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWRhdmlkYmVuLXRscy1iYXRjaC1zaWduaW5nLyIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZGF2aWRiZW4tdGxzLWJhdGNo LXNpZ25pbmcvPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRM UyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN7PR11MB25476085C61E094BCF8A8BEFC9430BN7PR11MB2547namp_-- From nobody Mon Dec 2 10:26:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80537120089 for ; Mon, 2 Dec 2019 10:26:28 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 miRmishMdNPr for ; Mon, 2 Dec 2019 10:26:27 -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 5D3C5120072 for ; Mon, 2 Dec 2019 10:26:27 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xB2IOsWK016232; Mon, 2 Dec 2019 18:26:26 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=SNyyflynHBO+JDjBEW7cH2YcjJ8KijR5+u2R9HssPPA=; b=G7uHmjBk70saGv7W1Y6Hgh/SiYKEdeHjcZN616zfRkovFYSubD1BNoVv2A221evYNMIS 5+X26xAbZ4whru+v+AVJR9a/RL63dAlsqyLVUpTRc0cFqw70Iu5N1qZkboxQ9EOJds/U ZYH0do5m6xVf1OKurabw+lmLcglu4YbQ4+rqsdDL+sychbdXJzsgbF94xlDxCy1URyFY MY/LJrfzNHmwgqhlMLf1NEPAW5bjIf/jpbMU+v6h+EPdsvn+NhHn53+pI2nNbnhkKApy p+1548Ktpl10VzEHNMCh5BZ3qOKdMxgQQGJRgzlseCO8JtWDn74MuY92dyY8aTIzEg0o 2A== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2wkhqdm1sk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Dec 2019 18:26:25 +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 xB2IGvgU028225; Mon, 2 Dec 2019 13:26:25 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint8.akamai.com with ESMTP id 2wkmn18u19-1; Mon, 02 Dec 2019 13:26:23 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 739AA20064; Mon, 2 Dec 2019 18:26:14 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1ibqOj-0006BN-4b; Mon, 02 Dec 2019 10:26:13 -0800 Date: Mon, 2 Dec 2019 10:26:12 -0800 From: Benjamin Kaduk To: Xuan k Cc: "" Message-ID: <20191202182612.GJ3397@akamai.com> References: <20191202075444.GI3397@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-02_04:, , 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=974 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912020155 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-02_04:2019-11-29,2019-12-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 spamscore=0 suspectscore=0 clxscore=1015 mlxscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=984 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912020156 Archived-At: Subject: Re: [TLS] [DTLS1.3]About the retransmission of Handshake records 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, 02 Dec 2019 18:26:29 -0000 On Mon, Dec 02, 2019 at 07:17:32PM +0800, Xuan k wrote: > Hi Ben, > > Thanks for your reply. But we understand may not be the same. > > Since ACK messages are not retransmitted, I think they should not consume > message_seqs. > If an ACK really use a message_seq and it is lost in network, new handshake > records will > always use a larger message_seq than the peer expected (next_receive_seq). > The peer will unable to continue the handshake process. You are correct; they should not and do not. But in an early version of the draft the ACK messages used the same data structure that has an associated message_seq, and as you note, that was problematic, so it was changed. -Ben From nobody Mon Dec 2 15:59:23 2019 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 D5C9C1200E3; Mon, 2 Dec 2019 15:59:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles via Datatracker To: Cc: last-call@ietf.org, tls@ietf.org, draft-ietf-tls-tls13-cert-with-extern-psk.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Ines Robles Message-ID: <157533115179.2256.879699004944357388@ietfa.amsl.com> Date: Mon, 02 Dec 2019 15:59:11 -0800 Archived-At: Subject: [TLS] Genart last call review of draft-ietf-tls-tls13-cert-with-extern-psk-03 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: Mon, 02 Dec 2019 23:59:12 -0000 Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-tls13-cert-with-extern-psk-?? Reviewer: Ines Robles Review Date: 2019-12-02 IETF LC End Date: 2019-12-02 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written. This document specifies a TLS 1.3 extension permitting certificate-based server authentication to be combined with an external PSK as an input to the TLS 1.3 key schedule. Major issues: Not found Minor issues: Not found Nits/editorial comments: I think that would be nice to add in IANA Considerations a table specifying the fields of the TLS ExtensionType Values indicated in https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml Thank you for this document, Ines. From nobody Tue Dec 3 14:16:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D0712004D for ; Tue, 3 Dec 2019 14:16:28 -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 qJDvShJBh5NQ for ; Tue, 3 Dec 2019 14:16:26 -0800 (PST) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FD912003F for ; Tue, 3 Dec 2019 14:16:26 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id x18so3513836vsq.4 for ; Tue, 03 Dec 2019 14:16:26 -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=fs6z+ULDyOc8pUWb1BF8wPQVgH98ubQ8yNZWw0ujfoo=; b=IZZ5rO6XFImBqNUEZxkrMMbE4VqTpIJDFBjhVrz9nNzkIf6eJt/OBxqJfOM8VfeNif Nhz7bXyfP+fEzIlQ656xWen6lVTd2bpuRc2IW7q0tYGKNa2ur1PVGPmUmqdfCWJl2KNX eOV36if1To1tKC0IuBHQ6UXuOaSzuN6hDxxeePFn865zUCnwdRRrjbY04TyKRsUCztjs NQA1d5HOsZAxF9bLrdkgUzopdV/AjdLQW5d3nirlX2ZvOUpgspg9BnTzFfCyi3JIzHqI /8AqRTUFtw7o/KNWmkXHO3zStnDugHF4QejyE7sfHYom9nUhFcA5FEMYbhZRjFej7I08 0mcQ== 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=fs6z+ULDyOc8pUWb1BF8wPQVgH98ubQ8yNZWw0ujfoo=; b=iU6rLpkqsrU+Dn0pETTILTWEVQ6vRI3+2+2SnZbLQMaGV1400b7QlAJCVB+EW+pEWa Hkn34zjnynDksawVnyNOzqV0+di+ZJBQ9RHoNjPXY6j0fUmsiyiopY+slwDOLoRXb0HT 0ROoTXPav+ylP9PdJ2zKdqezRNEQamHcAAOKr36Q4TYH/LtZ9l4YGodpg8avTq6j0BMc yt2E4fnHGHiugLeeIvr4eAYHMj7kiONG7oByF0Ul4/S+T5JdzQkZGOyn8uFvLeu8wJdz PQ/2ni2pARZSAsH6q8VfHyiUrznnC26p17s9RsPwVj4WE3gKL/lZw/BWpNuG77dQPCcQ 84Zw== X-Gm-Message-State: APjAAAXoBTIUiS8j9lIuFXcJcI3Hfonm1h94SQgvrSYEQkFop4hLf/l9 ko9TWhGFfwyoWF4zuQPdzqy9LWo4HuLxOKaxe9Ny5PW3JHy/0Q== X-Google-Smtp-Source: APXvYqwfpsiY68UdJT41Q4PkAL8DLgPuiWO47Rc/Ko36fcWtlifLeGvlyxOkbOZb2hxrSFSEwrjj44siOIQTPqLtrAY= X-Received: by 2002:a05:6102:3099:: with SMTP id l25mr951296vsb.235.1575411385424; Tue, 03 Dec 2019 14:16:25 -0800 (PST) MIME-Version: 1.0 From: Pascal Urien Date: Tue, 3 Dec 2019 23:16:14 +0100 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="00000000000000df5d0598d40c1c" Archived-At: Subject: [TLS] DH security issue in 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: Tue, 03 Dec 2019 22:16:28 -0000 --00000000000000df5d0598d40c1c Content-Type: text/plain; charset="UTF-8" I wonder if g**x , with x =(1-p)/2 is checked in current TLS 1.2 implementation ? In RFC https://tools.ietf.org/html/rfc7919 "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)" "Traditional finite field Diffie-Hellman has each peer choose their secret exponent from the range [2, p-2]. Using exponentiation by squaring, this means each peer must do roughly 2*log_2(p) multiplications, twice (once for the generator and once for the peer's public key)." Not True !!! Even for p= safe prime (i.e. Sophie Germain prime, p=2*q+1, with p & q prime number) secret exponent x= (p-1)/2 is a security issue since : g**xy = 1 with y an even integer g**xy = g**x for y an odd integer If p is not a safe prime (like in RFC 5114) other issues occur... Pascal --00000000000000df5d0598d40c1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wonder if g**x , with x =3D(1-p)/2 is checked in current= TLS 1.2 implementation ?

In RFC https://tools.ietf.org/html/rfc7919
"Negotiated Fi= nite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security= (TLS)"

"Traditional finite field Diffie-Hellman has each = peer choose their secret exponent from the range [2, p-2]. =C2=A0
Using = exponentiation by squaring, this means each peer must do roughly 2*log_2(p)= multiplications,
twice (once for the generator and once for the peer= 9;s public key)."

Not True !!!
Even for p=3D safe prime (i.e= . Sophie Germain prime, p=3D2*q+1, with p & q prime number) secret expo= nent x=3D (p-1)/2 is a security issue since :

g**xy =3D 1 =C2=A0 =C2= =A0 =C2=A0 with y an even integer
g**xy =3D g**x =C2=A0 for y an odd int= eger

If p is not a safe prime (like in RFC 5114) other issues occur.= ..

Pascal
--00000000000000df5d0598d40c1c-- From nobody Tue Dec 3 15:03:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FAC120096 for ; Tue, 3 Dec 2019 15:03:27 -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, 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, 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=GyGeYYPc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wdJcatye Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eujMPBWdorVx for ; Tue, 3 Dec 2019 15:03:24 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFF1120045 for ; Tue, 3 Dec 2019 15:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13286; q=dns/txt; s=iport; t=1575414204; x=1576623804; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=shNVCVeNFYdMiOZ0yYKYJZ1NZI0sxQDiRGGh5FHHqDM=; b=GyGeYYPcg0sH/XKgrx/rtTztpAzUa5Kid0n2MEeKzJrIpQgvPWSqrVf8 DfqvWpSYa7B56KLRn0lNq27w/mtagzqXJuO3FGR0UH72CPpmuylXV98zJ PBuA0gW5ujlpOKN85q3HgVMDR4eWERWNCDKVXbRGpCa8J0wuytU+zA2ru Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AAmKnFhEWb894kXJFyfnY751GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeXkazE6BslYfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAAAf6eZd/5NdJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBawUBAQELAYEbL1AFbFggBAsqCoQhg0YDinlOghGTIoR?= =?us-ascii?q?igS6BJANUCQEBAQwBAR8OAgEBhEACF4F2JDUIDgIDDQEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhVIBAQEBAxIRChMBASsNDwIBCBEEAQErAgICMB0IAgQBEggagwGBeU0DLgE?= =?us-ascii?q?CDKZpAoE4iGB1gTKCfgEBBYULGIIXAwaBNgGMFRqBQT+BWIIXNT6CZAEBA4F?= =?us-ascii?q?iK4JjMoIskB6FTJhdCoIuhx6OVpokjkqIPpFfAgQCBAUCDgEBBYFTATeBWHA?= =?us-ascii?q?VgydQERSMZoNzhRSFP3SBKI9HAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.69,275,1571702400"; d="scan'208,217";a="677255781" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Dec 2019 23:03:22 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id xB3N3M0Q008399 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2019 23:03:23 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 3 Dec 2019 17:03:22 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 3 Dec 2019 17:03:21 -0600 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 3 Dec 2019 17:03:21 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZyN2Z63DC/fpypIAW7Q3Ow433vzaLhuO0MqgGzCQ96LZAl7zVMFR5VBAOfUxCyOxRuaGG3uLyyNBewX4Pb/1lW/D0UbUrF8ePkYmoewiyAP0qyP0n9hhQXujc1Onoamd8Nw7y74K+tVlKgZ8wBZj7Y275pcR3SOpRLZTm/ZLF5ruRhUOC92HqfRDuNpErQmlRr65GbTYnMD5ZRp/R9/L8VjebOjhNDt2mT+9+zqRaWsxeSEJkcEFIPt6wGkMZWtp1tVO3LaDwQ2uG8uzAHQS3LedikNnNY9hzRtJ1cFrI8dLEdltrEwDZM2qB3Nz9dYIvrS7nG0HwCMkhVJhCcWx8g== 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=shNVCVeNFYdMiOZ0yYKYJZ1NZI0sxQDiRGGh5FHHqDM=; b=ag49Xt0Tg2dse/3YEGq0y/H7Srp6hW6P5CaGMWzSO4AA4AQ0kfr24IjsVoOXKeL00WR11nleouo4sDSS0p8sASp02P4KZP8hBdv2q1+rOcl2/XE/vFC2Av0jl9quW/v+GM2o++IcZ4SvWN+Bbxe2UvxdvpYmEXDqCPqtmhwWdutnjEASYrDcnoIiuWN8879LcIj/xFZddjh+mkFQZJMqQEXHJ0x/XPA1SDGCAAmbABkEqeOuebGf+rlgaWSarQ7eZW33Qz3L8gh22Of9juLb4ty4bkcbbsEnIXe6TFdRdnC5G/9rseaN4UYTtF744gzMBiduVAivhV2bnJ6jAkNy+w== 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=shNVCVeNFYdMiOZ0yYKYJZ1NZI0sxQDiRGGh5FHHqDM=; b=wdJcatyeWIsUntEd85DPqlL5C7bbxFhOEyWIWXEpc+hBaZsELcB70864ofB/7jmbo8om2Gxxyr7SLjkSbYtcvLgU9PeALbB95OTeWuOU1PPlPSFE0d72rq3hFuoKpbfk5OaVJG5JCCXq2n6hEwfth1ZYSdPnaRzxmOAzH2qj3QM= Received: from BN8PR11MB3666.namprd11.prod.outlook.com (20.178.221.19) by BN8PR11MB3684.namprd11.prod.outlook.com (20.178.219.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.17; Tue, 3 Dec 2019 23:03:20 +0000 Received: from BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::815c:974a:5eab:868b]) by BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::815c:974a:5eab:868b%7]) with mapi id 15.20.2495.014; Tue, 3 Dec 2019 23:03:20 +0000 From: "Scott Fluhrer (sfluhrer)" To: Pascal Urien , "tls@ietf.org" Thread-Topic: [TLS] DH security issue in TLS Thread-Index: AQHVqieAYle6LbLNokyo/QnWl+zL16eo/MqQ Date: Tue, 3 Dec 2019 23:03:20 +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=sfluhrer@cisco.com; x-originating-ip: [173.38.117.71] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0494c7c5-3656-458c-f8c4-08d77844fde1 x-ms-traffictypediagnostic: BN8PR11MB3684: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(199004)(189003)(54094003)(76116006)(64756008)(81166006)(66446008)(8676002)(71200400001)(71190400001)(33656002)(66946007)(186003)(2501003)(5660300002)(966005)(81156014)(9686003)(478600001)(8936002)(6436002)(66476007)(25786009)(6306002)(54896002)(66556008)(55016002)(15650500001)(86362001)(6246003)(74316002)(236005)(2420400007)(7736002)(14454004)(76176011)(26005)(606006)(11346002)(446003)(7696005)(3846002)(7110500001)(229853002)(2906002)(99286004)(110136005)(256004)(102836004)(53546011)(6116002)(52536014)(6506007)(790700001)(14444005)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3684; H:BN8PR11MB3666.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: z3ElNaNaeQ0Dbp5nP0qHqDMrDlH6pnf9esuOfTljwqTC455BA85mSZOqmpIWHSuwGZR/EAKI/CgoWnNRxu6JSmmQM4lGc+rhr/hC8et430ITQyxbaFEPw1b64iyILospbtghUOvQx3yrSbxZ2NJ3gvO39UMvz2zhqpxsE9t5fs9tvZZng1+ouyGf+gs2k2aLwQ1U42CVechTypIf5zXRClVWy7liMb5MgMGkDN6X+sTMuFclBxaMtsFXaqrFRfscmTj9zXvq8jIAAY16MG7Eq3ORBIvdkD9YWCV4qdffdncfE3DIoWHwklh+WZ1QbC9jeVZPcAGEOeFzE7nBf0KjinQiUUWgnXqqbqqilY/wVYOdSNWm4KagM3ZYXy2hSZm+lV77oQdtrKaub/FZVfvDHRtt3RwDf3UWoT5PSk4UlfIqmA4b7amih3u6L9bB6fp00v2H/uYQ1LS8Q9e50hFSPw6YleXuvL3PWKrm5sy6jbk= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN8PR11MB36661739568DB959F7C9D2C4C1420BN8PR11MB3666namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0494c7c5-3656-458c-f8c4-08d77844fde1 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 23:03:20.6220 (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: PQxHjbSfL9D6R3Vr/7VbWeY/VAg1hcFyh2rNlPheBMKMy2B6TQQvGgBaWHMT5dwvorhk8gH03q22hpkwy6jwgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3684 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [TLS] DH security issue in 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: Tue, 03 Dec 2019 23:03:27 -0000 --_000_BN8PR11MB36661739568DB959F7C9D2C4C1420BN8PR11MB3666namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlIFNSRg0KDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg UGFzY2FsIFVyaWVuDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwMywgMjAxOSA1OjE2IFBNDQpU bzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBbVExTXSBESCBzZWN1cml0eSBpc3N1ZSBpbiBUTFMN Cg0KSSB3b25kZXIgaWYgZyoqeCAsIHdpdGggeCA9KDEtcCkvMiBpcyBjaGVja2VkIGluIGN1cnJl bnQgVExTIDEuMiBpbXBsZW1lbnRhdGlvbiA/DQoNCkluIFJGQyBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzkxOQ0KIk5lZ290aWF0ZWQgRmluaXRlIEZpZWxkIERpZmZpZS1IZWxsbWFu IEVwaGVtZXJhbCBQYXJhbWV0ZXJzIGZvciBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUyki DQoNCiJUcmFkaXRpb25hbCBmaW5pdGUgZmllbGQgRGlmZmllLUhlbGxtYW4gaGFzIGVhY2ggcGVl ciBjaG9vc2UgdGhlaXIgc2VjcmV0IGV4cG9uZW50IGZyb20gdGhlIHJhbmdlIFsyLCBwLTJdLg0K VXNpbmcgZXhwb25lbnRpYXRpb24gYnkgc3F1YXJpbmcsIHRoaXMgbWVhbnMgZWFjaCBwZWVyIG11 c3QgZG8gcm91Z2hseSAyKmxvZ18yKHApIG11bHRpcGxpY2F0aW9ucywNCnR3aWNlIChvbmNlIGZv ciB0aGUgZ2VuZXJhdG9yIGFuZCBvbmNlIGZvciB0aGUgcGVlcidzIHB1YmxpYyBrZXkpLiINCg0K Tm90IFRydWUgISEhDQpFdmVuIGZvciBwPSBzYWZlIHByaW1lIChpLmUuLiBTb3BoaWUgR2VybWFp biBwcmltZSwgcD0yKnErMSwgd2l0aCBwICYgcSBwcmltZSBudW1iZXIpIHNlY3JldCBleHBvbmVu dCB4PSAocC0xKS8yIGlzIGEgc2VjdXJpdHkgaXNzdWUgc2luY2UgOg0KDQpnKip4eSA9IDEgICAg ICAgd2l0aCB5IGFuIGV2ZW4gaW50ZWdlcg0KZyoqeHkgPSBnKip4ICAgZm9yIHkgYW4gb2RkIGlu dGVnZXINCg0KU1JGOiBhY3R1YWxseSwgZyoqeHkgID0gMSBpbiBib3RoIGNhc2VzLCBhcyBnKip4 ID0gMSAoZm9yIHRoZSBnLCBwIHZhbHVlcyBzcGVjaWZpZWQgaW4gUkZDNzkxOSk7IHRoaXMgaXMg ZWFzaWx5IHNlZW4gYXMgYWxsIGxpc3RlZCBwIHZhbHVlcyBhcmUgc2FmZSBwcmltZXMsIGFuZCBp biBhbGwgY2FzZXMsIGc9MiBhbmQgcD03IG1vZCA4Lg0KDQpJbiBhbnkgY2FzZSwgd2h5IHdvdWxk IHRoYXQgYmUgYSBzZWN1cml0eSBpc3N1ZT8gIElmIGJvdGggc2lkZXMgYXJlIGhvbmVzdCAoYW5k IHNlbGVjdCB0aGVpciB4LCB5IHZhbHVlcyBob25lc3RseSksIHRoZSBwcm9iYWJpbGl0eSBvZiBv bmUgb2YgdGhlbSBzZWxlY3RpbmcgKHAtMSkvMiBhcyB0aGVpciBwcml2YXRlIHZhbHVlIGlzIG5l Z2xpZ2libGUgKGV2ZW4gaWYgb3VyIHNlbGVjdGlvbiBsb2dpYyBhbGxvd2VkIHRoYXQgYXMgYSBw b3NzaWJsZSB2YWx1ZSDigJMgaXQgZ2VuZXJhbGx5IGRvZXNu4oCZdCkuICBJZiB3ZSBoYXZlIHR3 byBob25lc3QgcGFydGllcyB3aXRoIGFuIGFkdmVyc2FyeSByZXBsYWNpbmcgb25lIG9mIHRoZSBz aWRl4oCZcyBrZXkgc2hhcmUgd2l0aCBnKioocC0xKS8yLCB3ZWxsLCB0aGUgcHJvdG9jb2wgdHJh bnNtaXRzIHNpZ25hdHVyZXMgb2YgdGhlIHRyYW5zY3JpcHQsIGFuZCBzbyB0aGF04oCZbGwgYmUg ZGV0ZWN0ZWQuIElmIHlvdSBoYXZlIGFuIGhvbmVzdCBzaWRlIG5lZ290aWF0aW5nIHdpdGggYSBk aXNob25lc3Qgb25lLCB3ZWxsLCB0aGUgZGlzaG9uZXN0IG9uZSBjb3VsZCBzZWxlY3QgKHAtMSkv MiBhcyBpdHMgcHJpdmF0ZSB2YWx1ZSDigJMgaG93ZXZlciwgdGhleSBjb3VsZCBhbHNvIHJ1biB0 aGUgcHJvdG9jb2wgaG9uZXN0bHkgKGFuZCBsZWFybiB0aGUgc2hhcmVkIHNlY3JldCBhbmQgdGhl IHN5bW1ldHJpYyBrZXlzLCB3aGljaCBhcmUgdXN1YWxseSB0aGUgdGFyZ2V0KSwgYW5kIHRoZXJl 4oCZcyBub3RoaW5nIHRoZSBwcm90b2NvbCBjYW4gZG8gYWJvdXQgdGhhdC4NCg0KTm93LCBpZiBh biBob25lc3QgcGFydHkgcmV1c2VkIHRoZWlyIHByaXZhdGUgdmFsdWVzIGZvciBtdWx0aXBsZSBl eGNoYW5nZXMsIGEgc2ltaWxhciBvYnNlcnZhdGlvbiB3b3VsZCBhbGxvdyBhbiBhZHZlcnNhcnkg dG8gb2J0YWluIGEgc2luZ2xlIGJpdCBvZiB0aGUgcHJpdmF0ZSB2YWx1ZS4gIEhlIHdvdWxkIGRv IHRoYXQgYnkgcGVyZm9ybWluZyBhbiBleGNoYW5nZSB3aXRoIHRoZSBob25lc3QgcGFydHkgbW9z dGx5IGhvbmVzdGx5LCBzZWxlY3RpbmcgYSB2YWx1ZSB4IGFzIGhpcyBwcml2YXRlIHZhbHVlLCBi dXQgaW5zdGVhZCBvZiB0cmFuc21pdHRpbmcgZyoqeCBhcyBoaXMga2V5IHNoYXJlLCBoZSB3b3Vs ZCB0cmFuc21pdCAtZyoqeC4gIFRoZW4sIHRoZSBzaGFyZWQgdmFsdWUgdGhhdCB0aGUgaG9uZXN0 IHBhcnR5IHdvdWxkIGRlcml2ZSBpczoNCg0KICBnKip4eSAgd2l0aCB5IGFuIGV2ZW4gaW50ZWdl cg0KICAtZyoqeHkgIHdpdGggeSBhbiBvZGQgaW50ZWdlcg0KDQpUaGUgYWR2ZXJzYXJ5IGNhbiBj b21wdXRlIGJvdGggdGhlc2UgdmFsdWVzLCBhbmQgZGV0ZXJtaW5lIHdoaWNoIGlzIGJlaW5nIHVz ZWQgbGF0ZXIgaW4gdGhlIHByb3RvY29sLg0KDQpTbywgdGhlIGFkdmVyc2FyeSBjYW4gbGVhcm4g YSBzaW5nbGUgYml0IG9mIHRoZSBwcml2YXRlIHZhbHVlICh3aGljaCBkb2VzbuKAmXQgdHJhbnNs YXRlIHRvIGhpbSBsZWFybmluZyBhbnkgYml0IG9mIHRoZSBzaGFyZWQgc2VjcmV0LCBtdWNoIGxl c3MgdGhlIHN5bW1ldHJpYyBrZXlzKSDigJMgaG93ZXZlciwgaGUgY2Fubm90IGxldmVyYWdlIHRo aXMgdG8gbGVhcm4gYW55dGhpbmcgZWxzZSBvZiB0aGUgcHJpdmF0ZSBrZXkuICBJIGRvIG5vdCBi ZWxpZXZlIHRoYXQgYSBzaW5nbGUgYml0IGlzIHdvcnRoIHdvcnJ5aW5nIGFib3V0LiAgQW5kLCBh Z2FpbiwgaWYgd2UgZ2VuZXJhdGUgYSBmcmVzaCBESCBwcml2YXRlIHZhbHVlIGZvciBldmVyeSBl eGNoYW5nZSAod2hpY2ggd2UgZW5jb3VyYWdlIHBlb3BsZSB0byBkbyBmb3IgUEZTKSwgZXZlbiB0 aGF0IHNpbmdsZSBiaXQgZG9lc27igJl0IGFwcGx5IHRvIGFueSBvdGhlciBleGNoYW5nZS4NCg0K DQoNCklmIHAgaXMgbm90IGEgc2FmZSBwcmltZSAobGlrZSBpbiBSRkMgNTExNCkgb3RoZXIgaXNz dWVzIG9jY3VyLi4uLg0KDQoNClBhc2NhbA0K --_000_BN8PR11MB36661739568DB959F7C9D2C4C1420BN8PR11MB3666namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZSBTUkY8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVExTICZsdDt0bHMtYm91bmNlc0BpZXRmLm9y ZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NClBhc2NhbCBVcmllbjxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBEZWNlbWJlciAwMywgMjAxOSA1OjE2IFBNPGJyPg0KPGI+VG86PC9iPiB0bHNA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1RMU10gREggc2VjdXJpdHkgaXNzdWUgaW4g VExTPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b25k ZXIgaWYgZyoqeCAsIHdpdGggeCA9KDEtcCkvMiBpcyBjaGVja2VkIGluIGN1cnJlbnQgVExTIDEu MiBpbXBsZW1lbnRhdGlvbiA/PGJyPg0KPGJyPg0KSW4gUkZDIDxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTE5Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzkxOTwvYT48YnI+DQomcXVvdDtOZWdvdGlhdGVkIEZpbml0ZSBGaWVsZCBEaWZmaWUtSGVsbG1h biBFcGhlbWVyYWwgUGFyYW1ldGVycyBmb3IgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMp JnF1b3Q7PGJyPg0KPGJyPg0KJnF1b3Q7VHJhZGl0aW9uYWwgZmluaXRlIGZpZWxkIERpZmZpZS1I ZWxsbWFuIGhhcyBlYWNoIHBlZXIgY2hvb3NlIHRoZWlyIHNlY3JldCBleHBvbmVudCBmcm9tIHRo ZSByYW5nZSBbMiwgcC0yXS4gJm5ic3A7PGJyPg0KVXNpbmcgZXhwb25lbnRpYXRpb24gYnkgc3F1 YXJpbmcsIHRoaXMgbWVhbnMgZWFjaCBwZWVyIG11c3QgZG8gcm91Z2hseSAyKmxvZ18yKHApIG11 bHRpcGxpY2F0aW9ucyw8YnI+DQp0d2ljZSAob25jZSBmb3IgdGhlIGdlbmVyYXRvciBhbmQgb25j ZSBmb3IgdGhlIHBlZXIncyBwdWJsaWMga2V5KS4mcXVvdDs8YnI+DQo8YnI+DQpOb3QgVHJ1ZSAh ISE8YnI+DQpFdmVuIGZvciBwPSBzYWZlIHByaW1lIChpLmUuLiBTb3BoaWUgR2VybWFpbiBwcmlt ZSwgcD0yKnEmIzQzOzEsIHdpdGggcCAmYW1wOyBxIHByaW1lIG51bWJlcikgc2VjcmV0IGV4cG9u ZW50IHg9IChwLTEpLzIgaXMgYSBzZWN1cml0eSBpc3N1ZSBzaW5jZSA6PGJyPg0KPGJyPg0KZyoq eHkgPSAxICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdpdGggeSBhbiBldmVuIGludGVnZXI8YnI+DQpn Kip4eSA9IGcqKnggJm5ic3A7IGZvciB5IGFuIG9kZCBpbnRlZ2VyPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNSRjogYWN0dWFsbHksIGcqKnh5ICZuYnNwOz0gMSBpbiBib3RoIGNhc2VzLCBhcyBn Kip4ID0gMSAoZm9yIHRoZSBnLCBwIHZhbHVlcyBzcGVjaWZpZWQgaW4gUkZDNzkxOSk7IHRoaXMg aXMgZWFzaWx5IHNlZW4gYXMgYWxsIGxpc3RlZCBwIHZhbHVlcyBhcmUgc2FmZSBwcmltZXMsIGFu ZCBpbiBhbGwgY2FzZXMsIGc9MiBhbmQgcD03IG1vZCA4LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbiBhbnkgY2FzZSwgd2h5IHdvdWxkIHRoYXQgYmUgYSBzZWN1cml0eSBpc3N1ZT8mbmJzcDsg SWYgYm90aCBzaWRlcyBhcmUgaG9uZXN0IChhbmQgc2VsZWN0IHRoZWlyIHgsIHkgdmFsdWVzIGhv bmVzdGx5KSwgdGhlIHByb2JhYmlsaXR5IG9mIG9uZSBvZiB0aGVtIHNlbGVjdGluZyAocC0xKS8y IGFzIHRoZWlyIHByaXZhdGUgdmFsdWUgaXMgbmVnbGlnaWJsZSAoZXZlbiBpZiBvdXIgc2VsZWN0 aW9uIGxvZ2ljIGFsbG93ZWQNCiB0aGF0IGFzIGEgcG9zc2libGUgdmFsdWUg4oCTIGl0IGdlbmVy YWxseSBkb2VzbuKAmXQpLiZuYnNwOyBJZiB3ZSBoYXZlIHR3byBob25lc3QgcGFydGllcyB3aXRo IGFuIGFkdmVyc2FyeSByZXBsYWNpbmcgb25lIG9mIHRoZSBzaWRl4oCZcyBrZXkgc2hhcmUgd2l0 aCBnKioocC0xKS8yLCB3ZWxsLCB0aGUgcHJvdG9jb2wgdHJhbnNtaXRzIHNpZ25hdHVyZXMgb2Yg dGhlIHRyYW5zY3JpcHQsIGFuZCBzbyB0aGF04oCZbGwgYmUgZGV0ZWN0ZWQuIElmIHlvdSBoYXZl IGFuDQogaG9uZXN0IHNpZGUgbmVnb3RpYXRpbmcgd2l0aCBhIGRpc2hvbmVzdCBvbmUsIHdlbGws IHRoZSBkaXNob25lc3Qgb25lIGNvdWxkIHNlbGVjdCAocC0xKS8yIGFzIGl0cyBwcml2YXRlIHZh bHVlIOKAkyBob3dldmVyLCB0aGV5IGNvdWxkIGFsc28gcnVuIHRoZSBwcm90b2NvbCBob25lc3Rs eSAoYW5kIGxlYXJuIHRoZSBzaGFyZWQgc2VjcmV0IGFuZCB0aGUgc3ltbWV0cmljIGtleXMsIHdo aWNoIGFyZSB1c3VhbGx5IHRoZSB0YXJnZXQpLCBhbmQgdGhlcmXigJlzDQogbm90aGluZyB0aGUg cHJvdG9jb2wgY2FuIGRvIGFib3V0IHRoYXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdywg aWYgYW4gaG9uZXN0IHBhcnR5IHJldXNlZCB0aGVpciBwcml2YXRlIHZhbHVlcyBmb3IgbXVsdGlw bGUgZXhjaGFuZ2VzLCBhIHNpbWlsYXIgb2JzZXJ2YXRpb24gd291bGQgYWxsb3cgYW4gYWR2ZXJz YXJ5IHRvIG9idGFpbiBhIHNpbmdsZSBiaXQgb2YgdGhlIHByaXZhdGUgdmFsdWUuJm5ic3A7IEhl IHdvdWxkIGRvIHRoYXQgYnkgcGVyZm9ybWluZyBhbiBleGNoYW5nZSB3aXRoIHRoZSBob25lc3Qg cGFydHkgbW9zdGx5DQogaG9uZXN0bHksIHNlbGVjdGluZyBhIHZhbHVlIHggYXMgaGlzIHByaXZh dGUgdmFsdWUsIGJ1dCBpbnN0ZWFkIG9mIHRyYW5zbWl0dGluZyBnKip4IGFzIGhpcyBrZXkgc2hh cmUsIGhlIHdvdWxkIHRyYW5zbWl0IC1nKip4LiZuYnNwOyBUaGVuLCB0aGUgc2hhcmVkIHZhbHVl IHRoYXQgdGhlIGhvbmVzdCBwYXJ0eSB3b3VsZCBkZXJpdmUgaXM6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyBnKip4eSZuYnNwOyB3aXRoIHkgYW4gZXZlbiBpbnRlZ2VyPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgLWcqKnh5ICZuYnNwO3dpdGggeSBh biBvZGQgaW50ZWdlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYWR2ZXJzYXJ5IGNhbiBj b21wdXRlIGJvdGggdGhlc2UgdmFsdWVzLCBhbmQgZGV0ZXJtaW5lIHdoaWNoIGlzIGJlaW5nIHVz ZWQgbGF0ZXIgaW4gdGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgdGhl IGFkdmVyc2FyeSBjYW4gbGVhcm4gYSBzaW5nbGUgYml0IG9mIHRoZSBwcml2YXRlIHZhbHVlICh3 aGljaCBkb2VzbuKAmXQgdHJhbnNsYXRlIHRvIGhpbSBsZWFybmluZyBhbnkgYml0IG9mIHRoZSBz aGFyZWQgc2VjcmV0LCBtdWNoIGxlc3MgdGhlIHN5bW1ldHJpYyBrZXlzKSDigJMgaG93ZXZlciwg aGUgY2Fubm90IGxldmVyYWdlIHRoaXMgdG8gbGVhcm4gYW55dGhpbmcgZWxzZSBvZiB0aGUgcHJp dmF0ZQ0KIGtleS4mbmJzcDsgSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGEgc2luZ2xlIGJpdCBpcyB3 b3J0aCB3b3JyeWluZyBhYm91dC4mbmJzcDsgQW5kLCBhZ2FpbiwgaWYgd2UgZ2VuZXJhdGUgYSBm cmVzaCBESCBwcml2YXRlIHZhbHVlIGZvciBldmVyeSBleGNoYW5nZSAod2hpY2ggd2UgZW5jb3Vy YWdlIHBlb3BsZSB0byBkbyBmb3IgUEZTKSwgZXZlbiB0aGF0IHNpbmdsZSBiaXQgZG9lc27igJl0 IGFwcGx5IHRvIGFueSBvdGhlciBleGNoYW5nZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KSWYgcCBpcyBub3QgYSBzYWZlIHByaW1lIChsaWtlIGluIFJGQyA1MTE0KSBvdGhl ciBpc3N1ZXMgb2NjdXIuLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhc2Nh bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_BN8PR11MB36661739568DB959F7C9D2C4C1420BN8PR11MB3666namp_-- From nobody Tue Dec 3 17:52:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3352812000F for ; Tue, 3 Dec 2019 17:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.073, 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 W9yAVNjaSy9m for ; Tue, 3 Dec 2019 17:52:33 -0800 (PST) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E47312001A for ; Tue, 3 Dec 2019 17:52:32 -0800 (PST) Received: by mail-qk1-f171.google.com with SMTP id a10so5595258qko.9 for ; Tue, 03 Dec 2019 17:52:32 -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:cc; bh=2+q+Cp+frvvpk/AEfCwpt249/lx3XyvGcKoZSp7HGuc=; b=A/XcL0OFmi/j5U6iwZza9L/YrUEbKsXvrd1DOBHTsKcdeshRPPgm08yrgJ8YyNcDf0 ZG0iigLguHp1DjsVnETEn9QZSrAXwK8bGobcAp6N9mBOuApZk+Z/zcp3ZRI3xHFhnQXo dGlacozs99KTXEtJa9UtHv84c5HvRaHXstYs3fmpdqJxcc7mtyedsjWNQpJS/ckR/OdU 3b04XuzZ5+j11bS/fCj0SJ41ofC7kNQW4RfxQNhw62eQxbjEHioWUdKmcOBlsET4a3cV pax8Xi3dXVsuC1UnMqVKN6t+Gba3/Sf1P4n58rgpc/p1YJ5BUuwmUhBf40ge2FG5fx6M za/A== X-Gm-Message-State: APjAAAVgUl/3FN9CQ4e3Jo96euG9UpV/Ee5goUhAzNQFdV7Gtg8bl84T 4dg2E2u6nxFBhNzUu1XOwJ7Ae7kBPXNwbNtfMJSFmQ== X-Received: by 2002:a37:4d02:: with SMTP id a2mt451378qkb.355.1575424351762; Tue, 03 Dec 2019 17:52:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Jivsov Date: Tue, 3 Dec 2019 17:52:21 -0800 Message-ID: Cc: Pascal Urien , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dce75c0598d71027" Archived-At: Subject: Re: [TLS] DH security issue in 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: Wed, 04 Dec 2019 01:52:35 -0000 --000000000000dce75c0598d71027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=3D(p-1)/2 becau= se this results in a peer's public key g^x=3D 1. Allowing this makes some man-in-the middle attacks on TLS easier, because the attacker can predict the value of the ephemeral secret key on another leg of the connection. On Tue, Dec 3, 2019 at 3:03 PM Scott Fluhrer (sfluhrer) wrote: > See SRF > > > > *From:* TLS *On Behalf Of * Pascal Urien > *Sent:* Tuesday, December 03, 2019 5:16 PM > *To:* tls@ietf.org > *Subject:* [TLS] DH security issue in TLS > > > > I wonder if g**x , with x =3D(1-p)/2 is checked in current TLS 1.2 > implementation ? > > In RFC https://tools.ietf.org/html/rfc7919 > "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transpor= t > Layer Security (TLS)" > > "Traditional finite field Diffie-Hellman has each peer choose their secre= t > exponent from the range [2, p-2]. > Using exponentiation by squaring, this means each peer must do roughly > 2*log_2(p) multiplications, > twice (once for the generator and once for the peer's public key)." > > Not True !!! > Even for p=3D safe prime (i.e.. Sophie Germain prime, p=3D2*q+1, with p &= q > prime number) secret exponent x=3D (p-1)/2 is a security issue since : > > g**xy =3D 1 with y an even integer > g**xy =3D g**x for y an odd integer > > > > SRF: actually, g**xy =3D 1 in both cases, as g**x =3D 1 (for the g, p va= lues > specified in RFC7919); this is easily seen as all listed p values are saf= e > primes, and in all cases, g=3D2 and p=3D7 mod 8. > > > > In any case, why would that be a security issue? If both sides are hones= t > (and select their x, y values honestly), the probability of one of them > selecting (p-1)/2 as their private value is negligible (even if our > selection logic allowed that as a possible value =E2=80=93 it generally d= oesn=E2=80=99t). > If we have two honest parties with an adversary replacing one of the side= =E2=80=99s > key share with g**(p-1)/2, well, the protocol transmits signatures of the > transcript, and so that=E2=80=99ll be detected. If you have an honest sid= e > negotiating with a dishonest one, well, the dishonest one could select > (p-1)/2 as its private value =E2=80=93 however, they could also run the p= rotocol > honestly (and learn the shared secret and the symmetric keys, which are > usually the target), and there=E2=80=99s nothing the protocol can do abou= t that. > > > > Now, if an honest party reused their private values for multiple > exchanges, a similar observation would allow an adversary to obtain a > single bit of the private value. He would do that by performing an > exchange with the honest party mostly honestly, selecting a value x as hi= s > private value, but instead of transmitting g**x as his key share, he woul= d > transmit -g**x. Then, the shared value that the honest party would deriv= e > is: > > > > g**xy with y an even integer > > -g**xy with y an odd integer > > > > The adversary can compute both these values, and determine which is being > used later in the protocol. > > > > So, the adversary can learn a single bit of the private value (which > doesn=E2=80=99t translate to him learning any bit of the shared secret, m= uch less > the symmetric keys) =E2=80=93 however, he cannot leverage this to learn a= nything > else of the private key. I do not believe that a single bit is worth > worrying about. And, again, if we generate a fresh DH private value for > every exchange (which we encourage people to do for PFS), even that singl= e > bit doesn=E2=80=99t apply to any other exchange. > > > > > > If p is not a safe prime (like in RFC 5114) other issues occur.... > > > > > > Pascal > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000dce75c0598d71027 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://tools.ietf.org/html/rfc79= 19#section-5.1 prohibits x=3D(p-1)/2 because this results in a peer'= ;s public key g^x=3D 1.

Allowing this makes some man-in-the middle attacks on TLS easier, because the=20 attacker can predict the value of the ephemeral secret key on another=20 leg of the connection.

On Tue, Dec 3, 2019 at 3:03 PM Scott Flu= hrer (sfluhrer) <sfluhrer@cisco.co= m> wrote:

See SRF

=C2=A0

From: TLS <tls-bounces@ietf.org> On Behalf Of Pascal Urien
Sent: Tuesday, December 03, 2019 5:16 PM
To: tls@ietf.org
Subject: [TLS] DH security issue in TLS

=C2=A0

I wonder if g**x , with x =3D(1-p)/2 is checked in c= urrent TLS 1.2 implementation ?

In RFC ht= tps://tools.ietf.org/html/rfc7919
"Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Trans= port Layer Security (TLS)"

"Traditional finite field Diffie-Hellman has each peer choose their se= cret exponent from the range [2, p-2]. =C2=A0
Using exponentiation by squaring, this means each peer must do roughly 2*lo= g_2(p) multiplications,
twice (once for the generator and once for the peer's public key)."= ;

Not True !!!
Even for p=3D safe prime (i.e.. Sophie Germain prime, p=3D2*q+1, with p &am= p; q prime number) secret exponent x=3D (p-1)/2 is a security issue since :=

g**xy =3D 1 =C2=A0 =C2=A0 =C2=A0 with y an even integer
g**xy =3D g**x =C2=A0 for y an odd integer

=C2=A0

SRF: actually, g**xy =C2=A0=3D 1 in both cases, as g= **x =3D 1 (for the g, p values specified in RFC7919); this is easily seen a= s all listed p values are safe primes, and in all cases, g=3D2 and p=3D7 mo= d 8.

=C2=A0

In any case, why would that be a security issue?=C2= =A0 If both sides are honest (and select their x, y values honestly), the p= robability of one of them selecting (p-1)/2 as their private value is negli= gible (even if our selection logic allowed that as a possible value =E2=80=93 it generally doesn=E2=80=99t).=C2=A0 If= we have two honest parties with an adversary replacing one of the side=E2= =80=99s key share with g**(p-1)/2, well, the protocol transmits signatures = of the transcript, and so that=E2=80=99ll be detected. If you have an honest side negotiating with a dishonest one, well, the dishonest one coul= d select (p-1)/2 as its private value =E2=80=93 however, they could also ru= n the protocol honestly (and learn the shared secret and the symmetric keys= , which are usually the target), and there=E2=80=99s nothing the protocol can do about that.

=C2=A0

Now, if an honest party reused their private values = for multiple exchanges, a similar observation would allow an adversary to o= btain a single bit of the private value.=C2=A0 He would do that by performi= ng an exchange with the honest party mostly honestly, selecting a value x as his private value, but instead of transmi= tting g**x as his key share, he would transmit -g**x.=C2=A0 Then, the share= d value that the honest party would derive is:

=C2=A0

=C2=A0 g**xy=C2=A0 with y an even integer<= /u>

=C2=A0 -g**xy =C2=A0with y an odd integer<= /u>

=C2=A0

The adversary can compute both these values, and det= ermine which is being used later in the protocol.

=C2=A0

So, the adversary can learn a single bit of the priv= ate value (which doesn=E2=80=99t translate to him learning any bit of the s= hared secret, much less the symmetric keys) =E2=80=93 however, he cannot le= verage this to learn anything else of the private key.=C2=A0 I do not believe that a single bit is worth worrying about.=C2= =A0 And, again, if we generate a fresh DH private value for every exchange = (which we encourage people to do for PFS), even that single bit doesn=E2=80= =99t apply to any other exchange.

=C2=A0



If p is not a safe prime (like in RFC 5114) other issues occur....

=C2=A0

=C2=A0

Pascal

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000dce75c0598d71027-- From nobody Wed Dec 4 08:23:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DFF120025 for ; Wed, 4 Dec 2019 08:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 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, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, 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 1o5TUkz2ndji for ; Wed, 4 Dec 2019 08:23:23 -0800 (PST) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5131F12083E for ; Wed, 4 Dec 2019 08:23:23 -0800 (PST) Received: by mail-ua1-x932.google.com with SMTP id f7so2998537uaa.8 for ; Wed, 04 Dec 2019 08:23:23 -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=neOw+uJa3rBsuTeL5AsurVSh16jCFzfc5o7gdsii81w=; b=VQGkcGwu4pUTvo54mzUHiD4xGxOxOyD+h0s77Xn/md6+Imom8wyFzBxxaq4s33nvj/ vbu5haYqAn8zan5Ec4zKwPJnxRG3xaHb1NwgUjDG2JgfeY2A8fTdr23C/QZqx6JPwK7l 1TXTR+Wpz5vFU5FmkeMUZ5gHtIsMV72uOjaSTLLcvBeBAGWdzCackK4TfUo0vX/LPd8p /t2VLTgoN6Nwkd6G7AWaFs6wFZmoJp+tOvdbqqy/zMcmpTA6cXhAAw+7S5gJWpL31rIh C+D3adQq/6f+IUh33/X/+dLvGb19WzDoIq9jVuAQwZAngWf8czUlRvLE11uakEY78pnN s49A== 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=neOw+uJa3rBsuTeL5AsurVSh16jCFzfc5o7gdsii81w=; b=NK7r5ByImubO+w1LKxPPbx2F6wsAsxXp/BwzNXafNosYpg1dVcG3K60jmSIKjDTbL1 Mkmczv/8xhrAfxVW1dOaPb83MVJp/lQBJ7RdOo/6nWLPHGcoEXe8DuyhDPbxvAZhe72x OMJWIDY9qgZ0on+UADv/aXo5DK3+qMVmY8oqN2fnF8GSpDfWvOiDaFaoE+ZoYsfDc1ud z3i7QWVfhsx19MVuSrqeHecqTTtD64OUhBQXDzSNU3xNzdjMaggK6sSWCgI+PUu28Yid 4WbGB8HqXqoW3BR36SEUVl0tI7nngFoBz1ndG5uj7Y1uO/6uT7fr7PL8sOCgtQzkNUBa v3qg== X-Gm-Message-State: APjAAAV5fOX5MJK58mNUPqDx6dub1KU+s73+txIKj83Hxy99zHDAC3vr lZXuSv5Bx/DVSi2Ze9KSzM/yZkc9n4Gouo6RuYt5tDVwrtYBIg== X-Google-Smtp-Source: APXvYqyZCe7CIxtrWeCKrYwe5n2Y09uMz5NfyRpDy+elwGZA2z8YQyU8j1Jaj+WSd8kX6BQ5h24i64oVCusF+hA8fLU= X-Received: by 2002:ab0:2783:: with SMTP id t3mr3130591uap.48.1575476602100; Wed, 04 Dec 2019 08:23:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pascal Urien Date: Wed, 4 Dec 2019 17:23:11 +0100 Message-ID: To: Andrey Jivsov Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000038630b0598e33b80" Archived-At: Subject: Re: [TLS] DH security issue in 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: Wed, 04 Dec 2019 16:23:25 -0000 --00000000000038630b0598e33b80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all https://tools.ietf.org/html/rfc7919 seems somewhat confusing because the order of the generator (2) is q=3D(p-1)/2 and not (p-1 ) So in place of "Traditional finite field Diffie-Hellman has each peer choose their secret exponent from the range [2, p-2]." It should suggest to use "Traditional finite field Diffie-Hellman has each peer choose their secret exponent from the range [2, q-1]." I put below some basic background that could help to understand the DH security If a safe prime p=3D2q+1 is congruent to 7 modulo 8, then it is a divisor o= f the Mersenne number with its matching Sophie Germain prime (q) as exponent. a Mersenne prime is a prime number that is one less than a power of two. That is, it is a prime number of the form Mn =3D 2**n - 1 for some integer = n. 2**q-1 =3D kp; 2**(p-1)/2 =3D 1 mod p Therefore 2 is a generator of order q=3D(p-1)/2 (p-1) is a generator of order 2, since (p-1)**2 =3D (p**2+1-2p) =3D 1 mod q Example p=3D7 =3D 2x3 +1, q=3D3 p =3D 7 mod 8 6 =3D 2x3 1 group of order 6, phi(6)=3D 2 generators (q-1) 1 group of order 3, phi(3)=3D 2 generators (q-1) 1 group of order 2, phi(2)=3D 1 generators 2 4 1 3 2 6 4 5 1 4 2 1 5 4 6 2 3 1 6 1 Le mer. 4 d=C3=A9c. 2019 =C3=A0 02:52, Andrey Jivsov = a =C3=A9crit : > https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=3D(p-1)/2 > because this results in a peer's public key g^x=3D 1. > > Allowing this makes some man-in-the middle attacks on TLS easier, because > the attacker can predict the value of the ephemeral secret key on another > leg of the connection. > > On Tue, Dec 3, 2019 at 3:03 PM Scott Fluhrer (sfluhrer) < > sfluhrer@cisco.com> wrote: > >> See SRF >> >> >> >> *From:* TLS *On Behalf Of * Pascal Urien >> *Sent:* Tuesday, December 03, 2019 5:16 PM >> *To:* tls@ietf.org >> *Subject:* [TLS] DH security issue in TLS >> >> >> >> I wonder if g**x , with x =3D(1-p)/2 is checked in current TLS 1.2 >> implementation ? >> >> In RFC https://tools.ietf.org/html/rfc7919 >> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for >> Transport Layer Security (TLS)" >> >> "Traditional finite field Diffie-Hellman has each peer choose their >> secret exponent from the range [2, p-2]. >> Using exponentiation by squaring, this means each peer must do roughly >> 2*log_2(p) multiplications, >> twice (once for the generator and once for the peer's public key)." >> >> Not True !!! >> Even for p=3D safe prime (i.e.. Sophie Germain prime, p=3D2*q+1, with p = & q >> prime number) secret exponent x=3D (p-1)/2 is a security issue since : >> >> g**xy =3D 1 with y an even integer >> g**xy =3D g**x for y an odd integer >> >> >> >> SRF: actually, g**xy =3D 1 in both cases, as g**x =3D 1 (for the g, p v= alues >> specified in RFC7919); this is easily seen as all listed p values are sa= fe >> primes, and in all cases, g=3D2 and p=3D7 mod 8. >> >> >> >> In any case, why would that be a security issue? If both sides are >> honest (and select their x, y values honestly), the probability of one o= f >> them selecting (p-1)/2 as their private value is negligible (even if our >> selection logic allowed that as a possible value =E2=80=93 it generally = doesn=E2=80=99t). >> If we have two honest parties with an adversary replacing one of the sid= e=E2=80=99s >> key share with g**(p-1)/2, well, the protocol transmits signatures of th= e >> transcript, and so that=E2=80=99ll be detected. If you have an honest si= de >> negotiating with a dishonest one, well, the dishonest one could select >> (p-1)/2 as its private value =E2=80=93 however, they could also run the = protocol >> honestly (and learn the shared secret and the symmetric keys, which are >> usually the target), and there=E2=80=99s nothing the protocol can do abo= ut that. >> >> >> >> Now, if an honest party reused their private values for multiple >> exchanges, a similar observation would allow an adversary to obtain a >> single bit of the private value. He would do that by performing an >> exchange with the honest party mostly honestly, selecting a value x as h= is >> private value, but instead of transmitting g**x as his key share, he wou= ld >> transmit -g**x. Then, the shared value that the honest party would deri= ve >> is: >> >> >> >> g**xy with y an even integer >> >> -g**xy with y an odd integer >> >> >> >> The adversary can compute both these values, and determine which is bein= g >> used later in the protocol. >> >> >> >> So, the adversary can learn a single bit of the private value (which >> doesn=E2=80=99t translate to him learning any bit of the shared secret, = much less >> the symmetric keys) =E2=80=93 however, he cannot leverage this to learn = anything >> else of the private key. I do not believe that a single bit is worth >> worrying about. And, again, if we generate a fresh DH private value for >> every exchange (which we encourage people to do for PFS), even that sing= le >> bit doesn=E2=80=99t apply to any other exchange. >> >> >> >> >> >> If p is not a safe prime (like in RFC 5114) other issues occur.... >> >> >> >> >> >> Pascal >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --00000000000038630b0598e33b80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all

https://tools.ietf.org/html/rfc7919 seems somewhat conf= using because the order of the generator=C2=A0(2) is q=3D(p-1)/2 and not=C2= =A0 (p-1 )

So in place of=C2=A0
= "Traditional finite field Diffie-Hellman has each peer choose their se= cret exponent from the range [2, p-2]."
It should suggest to= use
"Traditional finite field Diffie-Hellman has each peer choose their se= cret exponent from the range [2, q-1]." =C2=A0 =C2=A0

I put below some basic backgroun= d that could help to understand the DH security

If= a safe prime p=3D2q+1 is congruent to 7 modulo 8,=C2=A0then it is a diviso= r of the Mersenne number
with its matching Sophie Germain prime (q) as e= xponent.
a Mersenne prime is a prime number that is one less than a powe= r of two.
That is, it is a prime number of the form Mn =3D 2**n - 1 for= some integer n.

2**q-1 =3D kp;
2**(p-1)/2 =3D 1 mod p
There= fore 2 is a generator of order q=3D(p-1)/2

(p-1) is a generator of o= rder 2, since (p-1)**2 =3D (p**2+1-2p) =3D 1 mod q

Example
p=3D7 = =3D 2x3 +1, q=3D3
p =3D 7 mod 8
6 =3D 2x3 =C2=A0
1 group of order = 6, phi(6)=3D 2 generators (q-1)
1 group of order 3, phi(3)=3D 2 generato= rs (q-1)
1 group of order 2, phi(2)=3D 1 generators

2 4 1
3 2 = 6 4 5 1
4 2 1
5 4 6 2 3 1
6 1

Le=C2=A0mer. 4 d=C3=A9c. 20= 19 =C3=A0=C2=A002:52, Andrey Jivsov <crypto@brainhub.org> a =C3=A9crit=C2=A0:
= https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=3D(p-1)/= 2 because this results in a peer's public key g^x=3D 1.
=
Allowing this makes some man-in-the middle attacks on TLS easier, because the=20 attacker can predict the value of the ephemeral secret key on another=20 leg of the connection.

On Tue, Dec 3, 2019 at 3:03 PM Scott Flu= hrer (sfluhrer) <sfluhrer@cisco.com> wrote:

See SRF

=C2=A0

From: TLS <tls-bounces@ietf.org> On Behalf Of Pascal Urien
Sent: Tuesday, December 03, 2019 5:16 PM
To: tls@ietf.org
Subject: [TLS] DH security issue in TLS

=C2=A0

I wonder if g**x , with x =3D(1-p)/2 is checked in c= urrent TLS 1.2 implementation ?

In RFC ht= tps://tools.ietf.org/html/rfc7919
"Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Trans= port Layer Security (TLS)"

"Traditional finite field Diffie-Hellman has each peer choose their se= cret exponent from the range [2, p-2]. =C2=A0
Using exponentiation by squaring, this means each peer must do roughly 2*lo= g_2(p) multiplications,
twice (once for the generator and once for the peer's public key)."= ;

Not True !!!
Even for p=3D safe prime (i.e.. Sophie Germain prime, p=3D2*q+1, with p &am= p; q prime number) secret exponent x=3D (p-1)/2 is a security issue since :=

g**xy =3D 1 =C2=A0 =C2=A0 =C2=A0 with y an even integer
g**xy =3D g**x =C2=A0 for y an odd integer

=C2=A0

SRF: actually, g**xy =C2=A0=3D 1 in both cases, as g= **x =3D 1 (for the g, p values specified in RFC7919); this is easily seen a= s all listed p values are safe primes, and in all cases, g=3D2 and p=3D7 mo= d 8.

=C2=A0

In any case, why would that be a security issue?=C2= =A0 If both sides are honest (and select their x, y values honestly), the p= robability of one of them selecting (p-1)/2 as their private value is negli= gible (even if our selection logic allowed that as a possible value =E2=80=93 it generally doesn=E2=80=99t).=C2=A0 If= we have two honest parties with an adversary replacing one of the side=E2= =80=99s key share with g**(p-1)/2, well, the protocol transmits signatures = of the transcript, and so that=E2=80=99ll be detected. If you have an honest side negotiating with a dishonest one, well, the dishonest one coul= d select (p-1)/2 as its private value =E2=80=93 however, they could also ru= n the protocol honestly (and learn the shared secret and the symmetric keys= , which are usually the target), and there=E2=80=99s nothing the protocol can do about that.

=C2=A0

Now, if an honest party reused their private values = for multiple exchanges, a similar observation would allow an adversary to o= btain a single bit of the private value.=C2=A0 He would do that by performi= ng an exchange with the honest party mostly honestly, selecting a value x as his private value, but instead of transmi= tting g**x as his key share, he would transmit -g**x.=C2=A0 Then, the share= d value that the honest party would derive is:

=C2=A0

=C2=A0 g**xy=C2=A0 with y an even integer<= /u>

=C2=A0 -g**xy =C2=A0with y an odd integer<= /u>

=C2=A0

The adversary can compute both these values, and det= ermine which is being used later in the protocol.

=C2=A0

So, the adversary can learn a single bit of the priv= ate value (which doesn=E2=80=99t translate to him learning any bit of the s= hared secret, much less the symmetric keys) =E2=80=93 however, he cannot le= verage this to learn anything else of the private key.=C2=A0 I do not believe that a single bit is worth worrying about.=C2= =A0 And, again, if we generate a fresh DH private value for every exchange = (which we encourage people to do for PFS), even that single bit doesn=E2=80= =99t apply to any other exchange.

=C2=A0



If p is not a safe prime (like in RFC 5114) other issues occur....

=C2=A0

=C2=A0

Pascal

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000038630b0598e33b80-- From nobody Wed Dec 4 09:16:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4814C1208FC for ; Wed, 4 Dec 2019 09:16:16 -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 (2048-bit key) header.d=delignat-lavaud.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_t3fIQpBneS for ; Wed, 4 Dec 2019 09:16:12 -0800 (PST) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E781208E0 for ; Wed, 4 Dec 2019 09:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=8hDk5HHHE5NtPMKt8GelQUg7/rqFyB3DPGiD4OUrIXc=; b=VaVBfrR7Mx5ExSwGHVXjVUZjlA sQgbaF85y4q0CnWb+LBZ0ZJh9sL9PGjpC0uS2crvIWW6uMwcEN/uVZbrMcg7tMSfL5fdn0xPwFJ5c 4hvVJ/cDz6NmOZd4Vmi1/4mPduez6qKVt2/1XcWH002CKtgw0ZDXj+ptrZnMhApmksJQW6veCn9aL i1AiKXb9KnpMzdPIIq6VKhRyPNHBKGDKQrFoHyYrREvPze2i8GB0vsrsMTtiCvQAXj2Y+cSt50R9p SlPWXzeFOHljsXPGftnGWfS87Ts0chjnGrvco7zcetCZqdeg8+yoWOTsM8EVa4qiVv1AmgV7SS+Un 797pj3RQ==; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpa (envelope-from ) id 1icYG0-0004rg-Ie ; Wed, 04 Dec 2019 18:16:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 04 Dec 2019 17:16:07 +0000 From: Antoine Delignat-Lavaud To: Pascal Urien Cc: Andrey Jivsov , tls@ietf.org Organization: Microsoft Research In-Reply-To: References: Message-ID: <9a3bcf305595e769458687a872ed26c3@delignat-lavaud.fr> X-Sender: antoine@delignat-lavaud.fr User-Agent: Roundcube Webmail/1.2.3 Archived-At: Subject: Re: [TLS] DH security issue in 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: Wed, 04 Dec 2019 17:16:16 -0000 Hi Pascal, TLS 1.2 does not mandate servers to use safe DH primes. As a client, you get g and p from the server. You don't know if p is a safe prime, or indeed if it is a prime at all. You don't even know if g is a generator of Zp* - it could also be a generator for a small order subgroup. In that sense, RFC 7919 is correct in that, in general TLS 1.2, clients could pick any private exponent between 2 and p-2 when you have no information on p and g. When using an arbitrary server-selected prime and generator there is no guarantee that the server selected a share that is not in a small subgroup, and similarly there is no guarantee for the server that the client share is not of small order. In fact you don't even have this guarantee either with ECDH (where the curves are chosen from a fixed list) because some curves also have small subgroups. If you want the guarantee that your DH key exchange is contributive, that is, that neither single party can determine with high-probability the DH secret produced by the key exchange, you can either 1. use one of the safe groups defined in RFC7919. When using these groups, you should pick an exponent between 2 and q-1. 2. Figure out all of the low-order elements of Zp* and check that the DH secret is not one of them. Most implementations will do (2), i.e. they check that g^xy is not 0, 1, p-1. This is sufficient if p is a safe prime, but it is too expensive to check that p and p-1/2 are prime. For X25519 most implementations now check that x(yG) <> I, as it is much simpler than checking xG and yG for the 8 small order elements. You may be interested in checking Section III.B of [1] Best, Antoine [1] http://antoine.delignat-lavaud.fr/doc/ndss15.pdf On 2019-12-04 16:23, Pascal Urien wrote: > Hi all > > https://tools.ietf.org/html/rfc7919 seems somewhat confusing because > the order of the generator (2) is q=(p-1)/2 and not (p-1 ) > > So in place of > > "Traditional finite field Diffie-Hellman has each peer choose their > secret exponent from the range [2, p-2]." > It should suggest to use > "Traditional finite field Diffie-Hellman has each peer choose their > secret exponent from the range [2, q-1]." > > I put below some basic background that could help to understand the DH > security > > If a safe prime p=2q+1 is congruent to 7 modulo 8, then it is a > divisor of the Mersenne number > with its matching Sophie Germain prime (q) as exponent. > a Mersenne prime is a prime number that is one less than a power of > two. > That is, it is a prime number of the form Mn = 2**n - 1 for some > integer n. > > 2**q-1 = kp; > 2**(p-1)/2 = 1 mod p > Therefore 2 is a generator of order q=(p-1)/2 > > (p-1) is a generator of order 2, since (p-1)**2 = (p**2+1-2p) = 1 mod > q > > Example > p=7 = 2x3 +1, q=3 > p = 7 mod 8 > 6 = 2x3 > 1 group of order 6, phi(6)= 2 generators (q-1) > 1 group of order 3, phi(3)= 2 generators (q-1) > 1 group of order 2, phi(2)= 1 generators > > 2 4 1 > 3 2 6 4 5 1 > 4 2 1 > 5 4 6 2 3 1 > 6 1 > > Le mer. 4 déc. 2019 à 02:52, Andrey Jivsov a > écrit : > >> https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=(p-1)/2 >> because this results in a peer's public key g^x= 1. >> >> Allowing this makes some man-in-the middle attacks on TLS easier, >> because the attacker can predict the value of the ephemeral secret >> key on another leg of the connection. >> >> On Tue, Dec 3, 2019 at 3:03 PM Scott Fluhrer (sfluhrer) >> wrote: >> >>> See SRF >>> >>> FROM: TLS ON BEHALF OF Pascal Urien >>> SENT: Tuesday, December 03, 2019 5:16 PM >>> TO: tls@ietf.org >>> SUBJECT: [TLS] DH security issue in TLS >>> >>> I wonder if g**x , with x =(1-p)/2 is checked in current TLS 1.2 >>> implementation ? >>> >>> In RFC https://tools.ietf.org/html/rfc7919 >>> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for >>> Transport Layer Security (TLS)" >>> >>> "Traditional finite field Diffie-Hellman has each peer choose >>> their secret exponent from the range [2, p-2]. >>> Using exponentiation by squaring, this means each peer must do >>> roughly 2*log_2(p) multiplications, >>> twice (once for the generator and once for the peer's public >>> key)." >>> >>> Not True !!! >>> Even for p= safe prime (i.e.. Sophie Germain prime, p=2*q+1, with >>> p & q prime number) secret exponent x= (p-1)/2 is a security issue >>> since : >>> >>> g**xy = 1 with y an even integer >>> g**xy = g**x for y an odd integer >>> >>> SRF: actually, g**xy = 1 in both cases, as g**x = 1 (for the g, p >>> values specified in RFC7919); this is easily seen as all listed p >>> values are safe primes, and in all cases, g=2 and p=7 mod 8. >>> >>> In any case, why would that be a security issue? If both sides >>> are honest (and select their x, y values honestly), the >>> probability of one of them selecting (p-1)/2 as their private >>> value is negligible (even if our selection logic allowed that as a >>> possible value – it generally doesn’t). If we have two honest >>> parties with an adversary replacing one of the side’s key share >>> with g**(p-1)/2, well, the protocol transmits signatures of the >>> transcript, and so that’ll be detected. If you have an honest >>> side negotiating with a dishonest one, well, the dishonest one >>> could select (p-1)/2 as its private value – however, they could >>> also run the protocol honestly (and learn the shared secret and >>> the symmetric keys, which are usually the target), and there’s >>> nothing the protocol can do about that. >>> >>> Now, if an honest party reused their private values for multiple >>> exchanges, a similar observation would allow an adversary to >>> obtain a single bit of the private value. He would do that by >>> performing an exchange with the honest party mostly honestly, >>> selecting a value x as his private value, but instead of >>> transmitting g**x as his key share, he would transmit -g**x. >>> Then, the shared value that the honest party would derive is: >>> >>> g**xy with y an even integer >>> >>> -g**xy with y an odd integer >>> >>> The adversary can compute both these values, and determine which >>> is being used later in the protocol. >>> >>> So, the adversary can learn a single bit of the private value >>> (which doesn’t translate to him learning any bit of the shared >>> secret, much less the symmetric keys) – however, he cannot >>> leverage this to learn anything else of the private key. I do not >>> believe that a single bit is worth worrying about. And, again, if >>> we generate a fresh DH private value for every exchange (which we >>> encourage people to do for PFS), even that single bit doesn’t >>> apply to any other exchange. >>> >>> If p is not a safe prime (like in RFC 5114) other issues occur.... >>> >>> >>> Pascal _______________________________________________ >>> 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 Thu Dec 5 08:42:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0508120870; Thu, 5 Dec 2019 08:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH9x63BEUnpP; Thu, 5 Dec 2019 08:42:20 -0800 (PST) Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A625120865; Thu, 5 Dec 2019 08:42:18 -0800 (PST) Received: from localhost (unknown [IPv6:2a02:8010:6241:1:dd55:accf:56f0:dc88]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 0840ADF287; Thu, 5 Dec 2019 16:42:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1575564136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KpZLPiYmt/m1coi0nQXt8YhbFG98w2KwkdUUeDqNK3U=; b=VSgq/asPqJ9njj3XNg/B9C9LAeSzxbNoCQomPrLPsi8SQYyaREnaStD9KU5gGYpOBuKulQ r9wYCW58IIi+jEfuV7bYY+DTz6hhgtSIU/17XI5EQ7Ulf0Gf9JERcH/Xq+jf7ImRFBbNiN 0nNBf1ji7/v8yUlcomy65iutVWAAp/k= Date: Thu, 5 Dec 2019 16:42:12 +0000 From: Alessandro Ghedini To: Christian Huitema Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org Message-ID: <20191205164212.GB12839@sokka.flat11.house> References: <157498929764.5575.7815291384505057169@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157498929764.5575.7815291384505057169@ietfa.amsl.com> User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-certificate-compression-07 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, 05 Dec 2019 16:42:23 -0000 On Thu, Nov 28, 2019 at 05:01:37PM -0800, Christian Huitema via Datatracker wrote: > Reviewer: Christian Huitema > Review result: Has Issues > > I have reviewed draft-ietf-tls-certificate-compression-07 as part of the > security directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written primarily for the benefit of > the security area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. Thank you for the review! > Draft-ietf-tls-certificate-compression-07 defines two new TLS extensions to > negotiate and then apply compression of the Certificate message. The draft is > clear and well written, and the extensions are already widely deployed. I would > like to say "ready", but I have to say "almost". > > This document is almost ready, except for one nit and one issue. > > First, one nit. The draft references the "Certificate message", but there is no > formal reference section 4.4.2 of RFC8446. Please add that, maybe at the > beginning of section 4. It may seem obvious to members of the TLS WG, but > uninformed readers will appreciate. Makes sense. I created https://github.com/tlswg/certificate-compression/pull/30 to address this. > Second, my actual concern. Compression may leak information, because different > certificate chains will compress differently. The authors mention that an > attacker will not be able to inject data in the certificate chain, and thus > that attacks of the CRIME variety are unlikely. That's correct, but that's not > the entire story. > > TLS 1.3 will encrypt the compressed certificate message but the length of that > message could be deduced from the length of the server's encrypted message. > Attackers might be able to derive from that length the identity of the server, > even if the SNI is encrypted. > > One could say that in the absence of compression the length of the certificate > chain is also available. Indeed, the problem is flagged in > draft-ietf-tls-esni-05, which states in section 5.3 that "it (the server) > SHOULD pad the Certificate message, via padding at the record layer, such that > its length equals the size of the largest possible Certificate (message) > covered by the same ESNI key." > > Certificate compression introduces a level of complexity here. If only some > servers in the anonymity set support compression, attackers can work with a > smaller anonymity subset. If all attackers support compression, the padding > should try to match the largest Compressed Certificate. > > It might be good to discuss this issue in the security consideration section. I agree tha this is worth discussing, but it seems like it belongs in the ESNI draft itself, so implementers of ESNI will be more likely to take compression into consideration. That is, we can expand the section you quoted to also explicitly mention certificate compression. What do you think? I can look into proposing a PR for this. Cheers From nobody Thu Dec 5 08:51:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F086120241 for ; Thu, 5 Dec 2019 08:51:45 -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 V6NpokEidw0c for ; Thu, 5 Dec 2019 08:51:42 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DD112012D for ; Thu, 5 Dec 2019 08:51:42 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id 59so1562488uap.12 for ; Thu, 05 Dec 2019 08:51:42 -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=x8GWk8vftgNBMC5NuERHFdVr3lUWpGmFvnPjKHgOIvw=; b=LvYX86wjHM/ntA/CU2vjS8AZmstXGvn4ahypGiwdmAxcgg9gOEimfoY2R+SlFcIyn0 OyIfHWeLkBPCwB8VF+FODhwctgmbnd8aZVwEBJi4MNTRINgzGXddWssUm3YWP+itsn4c fZOh3Gqw60GXHlO/c3PA+UmOLcratt/OXgvmuHcx2Ox05CjbeRoBvq9gbk4ZJJDqYAfU wOZHJLlaNrL/1qS5CGv85HGL9aaixtAUzkMrDAo7GtSMvHxKtcV6Uz2MYONbowKHzNoL bCe/RHnCcrJr39TLjwhFHzBs9j2lJjNMoXghNDNgAR1M2rCmLs4IUIx8bo7CT5yFVPJJ 6c5g== 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=x8GWk8vftgNBMC5NuERHFdVr3lUWpGmFvnPjKHgOIvw=; b=hOUsdsd8cLGYw1iODHSb/PFW2xk/uiG6ckO/izeOU9UaHCuQi5y4N5iGyC9hmMFx7g lQIpuFGhdsRzzafS7dUjdbqiwSNgX0GlO62Rd174FxsrkSpwkX4nzgrr+X8il2YdVN9e vsdEIXbA4hZ0ArNJNdnXsDLLW3y81lqx86b7ZE90K8z8sG7xpG5selJdOfcZFmznFast DC6nWOsRdC6gotkmR1f96T+lKduv/tsqxCHqOfpa4c1Cc2pBww2nfri9FXbRoXkj7m0s aD/SaNSelonv36y10bbc6Qb4ZhuxAw3Coc5rsbs1qQW9Lfwn2DXnt4bDgdB9QXJkZdy9 ZJ7g== X-Gm-Message-State: APjAAAW4znkRDKgffyp3GSPBKVD47M1fyBxg/zAwfAe1awQN8PzFb/wL 74SeWcPgAnEwb3hhYrB22ny0TbK/7myfzC1U1B26z3yuQzc= X-Google-Smtp-Source: APXvYqydI+Gywb0R4brqhbG8C83q5vXMLY5Sdyonbo5vg2vJPW7ETChMPZEy2REGRbFukmerTgZAwd3BlVZq60HLShs= X-Received: by 2002:ab0:2783:: with SMTP id t3mr7972528uap.48.1575564700914; Thu, 05 Dec 2019 08:51:40 -0800 (PST) MIME-Version: 1.0 References: <9a3bcf305595e769458687a872ed26c3@delignat-lavaud.fr> In-Reply-To: <9a3bcf305595e769458687a872ed26c3@delignat-lavaud.fr> From: Pascal Urien Date: Thu, 5 Dec 2019 17:51:30 +0100 Message-ID: To: Antoine Delignat-Lavaud Cc: Andrey Jivsov , tls@ietf.org Content-Type: multipart/alternative; boundary="00000000000051a8250598f7be3d" Archived-At: Subject: Re: [TLS] DH security issue in 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: Thu, 05 Dec 2019 16:51:45 -0000 --00000000000051a8250598f7be3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All I found in NIST Special Publication 800-56A Revision 3 5.6.2.3.1 FFC Full Public-Key Validation Routine 2. Verify that 1 =3D y q mod p. This test is implemented in OPENSSL This test relies on the fact that q and p are prime Pascal Le mer. 4 d=C3=A9c. 2019 =C3=A0 18:16, Antoine Delignat-Lavaud < antoine@delignat-lavaud.fr> a =C3=A9crit : > Hi Pascal, > > TLS 1.2 does not mandate servers to use safe DH primes. As a client, you > get g and p from the server. You don't know if p is a safe prime, or > indeed if it is a prime at all. You don't even know if g is a generator > of Zp* - it could also be a generator for a small order subgroup. In > that sense, RFC 7919 is correct in that, in general TLS 1.2, clients > could pick any private exponent between 2 and p-2 when you have no > information on p and g. When using an arbitrary server-selected prime > and generator there is no guarantee that the server selected a share > that is not in a small subgroup, and similarly there is no guarantee for > the server that the client share is not of small order. In fact you > don't even have this guarantee either with ECDH (where the curves are > chosen from a fixed list) because some curves also have small subgroups. > > If you want the guarantee that your DH key exchange is contributive, > that is, that neither single party can determine with high-probability > the DH secret produced by the key exchange, you can either 1. use one of > the safe groups defined in RFC7919. When using these groups, you should > pick an exponent between 2 and q-1. 2. Figure out all of the low-order > elements of Zp* and check that the DH secret is not one of them. > > Most implementations will do (2), i.e. they check that g^xy is not 0, 1, > p-1. This is sufficient if p is a safe prime, but it is too expensive to > check that p and p-1/2 are prime. For X25519 most implementations now > check that x(yG) <> I, as it is much simpler than checking xG and yG for > the 8 small order elements. You may be interested in checking Section > III.B of [1] > > Best, > > Antoine > > [1] http://antoine.delignat-lavaud.fr/doc/ndss15.pdf > > On 2019-12-04 16:23, Pascal Urien wrote: > > Hi all > > > > https://tools.ietf.org/html/rfc7919 seems somewhat confusing because > > the order of the generator (2) is q=3D(p-1)/2 and not (p-1 ) > > > > So in place of > > > > "Traditional finite field Diffie-Hellman has each peer choose their > > secret exponent from the range [2, p-2]." > > It should suggest to use > > "Traditional finite field Diffie-Hellman has each peer choose their > > secret exponent from the range [2, q-1]." > > > > I put below some basic background that could help to understand the DH > > security > > > > If a safe prime p=3D2q+1 is congruent to 7 modulo 8, then it is a > > divisor of the Mersenne number > > with its matching Sophie Germain prime (q) as exponent. > > a Mersenne prime is a prime number that is one less than a power of > > two. > > That is, it is a prime number of the form Mn =3D 2**n - 1 for some > > integer n. > > > > 2**q-1 =3D kp; > > 2**(p-1)/2 =3D 1 mod p > > Therefore 2 is a generator of order q=3D(p-1)/2 > > > > (p-1) is a generator of order 2, since (p-1)**2 =3D (p**2+1-2p) =3D 1 m= od > > q > > > > Example > > p=3D7 =3D 2x3 +1, q=3D3 > > p =3D 7 mod 8 > > 6 =3D 2x3 > > 1 group of order 6, phi(6)=3D 2 generators (q-1) > > 1 group of order 3, phi(3)=3D 2 generators (q-1) > > 1 group of order 2, phi(2)=3D 1 generators > > > > 2 4 1 > > 3 2 6 4 5 1 > > 4 2 1 > > 5 4 6 2 3 1 > > 6 1 > > > > Le mer. 4 d=C3=A9c. 2019 =C3=A0 02:52, Andrey Jivsov a > > =C3=A9crit : > > > >> https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=3D(p-1)/2 > >> because this results in a peer's public key g^x=3D 1. > >> > >> Allowing this makes some man-in-the middle attacks on TLS easier, > >> because the attacker can predict the value of the ephemeral secret > >> key on another leg of the connection. > >> > >> On Tue, Dec 3, 2019 at 3:03 PM Scott Fluhrer (sfluhrer) > >> wrote: > >> > >>> See SRF > >>> > >>> FROM: TLS ON BEHALF OF Pascal Urien > >>> SENT: Tuesday, December 03, 2019 5:16 PM > >>> TO: tls@ietf.org > >>> SUBJECT: [TLS] DH security issue in TLS > >>> > >>> I wonder if g**x , with x =3D(1-p)/2 is checked in current TLS 1.2 > >>> implementation ? > >>> > >>> In RFC https://tools.ietf.org/html/rfc7919 > >>> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for > >>> Transport Layer Security (TLS)" > >>> > >>> "Traditional finite field Diffie-Hellman has each peer choose > >>> their secret exponent from the range [2, p-2]. > >>> Using exponentiation by squaring, this means each peer must do > >>> roughly 2*log_2(p) multiplications, > >>> twice (once for the generator and once for the peer's public > >>> key)." > >>> > >>> Not True !!! > >>> Even for p=3D safe prime (i.e.. Sophie Germain prime, p=3D2*q+1, with > >>> p & q prime number) secret exponent x=3D (p-1)/2 is a security issue > >>> since : > >>> > >>> g**xy =3D 1 with y an even integer > >>> g**xy =3D g**x for y an odd integer > >>> > >>> SRF: actually, g**xy =3D 1 in both cases, as g**x =3D 1 (for the g, = p > >>> values specified in RFC7919); this is easily seen as all listed p > >>> values are safe primes, and in all cases, g=3D2 and p=3D7 mod 8. > >>> > >>> In any case, why would that be a security issue? If both sides > >>> are honest (and select their x, y values honestly), the > >>> probability of one of them selecting (p-1)/2 as their private > >>> value is negligible (even if our selection logic allowed that as a > >>> possible value =E2=80=93 it generally doesn=E2=80=99t). If we have t= wo honest > >>> parties with an adversary replacing one of the side=E2=80=99s key sha= re > >>> with g**(p-1)/2, well, the protocol transmits signatures of the > >>> transcript, and so that=E2=80=99ll be detected. If you have an honest > >>> side negotiating with a dishonest one, well, the dishonest one > >>> could select (p-1)/2 as its private value =E2=80=93 however, they cou= ld > >>> also run the protocol honestly (and learn the shared secret and > >>> the symmetric keys, which are usually the target), and there=E2=80=99= s > >>> nothing the protocol can do about that. > >>> > >>> Now, if an honest party reused their private values for multiple > >>> exchanges, a similar observation would allow an adversary to > >>> obtain a single bit of the private value. He would do that by > >>> performing an exchange with the honest party mostly honestly, > >>> selecting a value x as his private value, but instead of > >>> transmitting g**x as his key share, he would transmit -g**x. > >>> Then, the shared value that the honest party would derive is: > >>> > >>> g**xy with y an even integer > >>> > >>> -g**xy with y an odd integer > >>> > >>> The adversary can compute both these values, and determine which > >>> is being used later in the protocol. > >>> > >>> So, the adversary can learn a single bit of the private value > >>> (which doesn=E2=80=99t translate to him learning any bit of the share= d > >>> secret, much less the symmetric keys) =E2=80=93 however, he cannot > >>> leverage this to learn anything else of the private key. I do not > >>> believe that a single bit is worth worrying about. And, again, if > >>> we generate a fresh DH private value for every exchange (which we > >>> encourage people to do for PFS), even that single bit doesn=E2=80=99t > >>> apply to any other exchange. > >>> > >>> If p is not a safe prime (like in RFC 5114) other issues occur.... > >>> > >>> > >>> Pascal _______________________________________________ > >>> 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 > --00000000000051a8250598f7be3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All

I found in NIST Speci= al Publication 800-56A Revision 3
5.6.2.3.1 FFC Full Public-Key V= alidation Routine
2. Verify=C2=A0 that=C2=A0 1 =3D y=C2=A0q m= od p.=C2=A0

This test is implemented in OPENSS= L

This test relies on the fact=C2=A0 that q and p = are prime

Pascal



Le=C2=A0mer. 4 d=C3=A9c. 2019 =C3=A0=C2=A018:16, Antoine Delignat-La= vaud <an= toine@delignat-lavaud.fr> a =C3=A9crit=C2=A0:
Hi Pascal,

TLS 1.2 does not mandate servers to use safe DH primes. As a client, you get g and p from the server. You don't know if p is a safe prime, or indeed if it is a prime at all. You don't even know if g is a generator=
of Zp* - it could also be a generator for a small order subgroup. In
that sense, RFC 7919 is correct in that, in general TLS 1.2, clients
could pick any private exponent between 2 and p-2 when you have no
information on p and g. When using an arbitrary server-selected prime
and generator there is no guarantee that the server selected a share
that is not in a small subgroup, and similarly there is no guarantee for the server that the client share is not of small order. In fact you
don't even have this guarantee either with ECDH (where the curves are <= br> chosen from a fixed list) because some curves also have small subgroups.
If you want the guarantee that your DH key exchange is contributive,
that is, that neither single party can determine with high-probability
the DH secret produced by the key exchange, you can either 1. use one of the safe groups defined in RFC7919. When using these groups, you should pick an exponent between 2 and q-1. 2. Figure out all of the low-order
elements of Zp* and check that the DH secret is not one of them.

Most implementations will do (2), i.e. they check that g^xy is not 0, 1, p-1. This is sufficient if p is a safe prime, but it is too expensive to check that p and p-1/2 are prime. For X25519 most implementations now
check that x(yG) <> I, as it is much simpler than checking xG and yG = for
the 8 small order elements. You may be interested in checking Section
III.B of [1]

Best,

Antoine

[1] http://antoine.delignat-lavaud.fr/doc/ndss15.pdf=

On 2019-12-04 16:23, Pascal Urien wrote:
> Hi all
>
> https://tools.ietf.org/html/rfc7919 seems somewhat confu= sing because
> the order of the generator (2) is q=3D(p-1)/2 and not=C2=A0 (p-1 )
>
> So in place of
>
> "Traditional finite field Diffie-Hellman has each peer choose the= ir
> secret exponent from the range [2, p-2]."
> It should suggest to use
>=C2=A0 "Traditional finite field Diffie-Hellman has each peer choo= se their
> secret exponent from the range [2, q-1]."
>
> I put below some basic background that could help to understand the DH=
> security
>
> If a safe prime p=3D2q+1 is congruent to 7 modulo 8, then it is a
> divisor of the Mersenne number
> with its matching Sophie Germain prime (q) as exponent.
> a Mersenne prime is a prime number that is one less than a power of > two.
> That is, it is a prime number of the form Mn =3D 2**n - 1 for some
> integer n.
>
> 2**q-1 =3D kp;
> 2**(p-1)/2 =3D 1 mod p
> Therefore 2 is a generator of order q=3D(p-1)/2
>
> (p-1) is a generator of order 2, since (p-1)**2 =3D (p**2+1-2p) =3D 1 = mod
> q
>
> Example
> p=3D7 =3D 2x3 +1, q=3D3
> p =3D 7 mod 8
> 6 =3D 2x3
> 1 group of order 6, phi(6)=3D 2 generators (q-1)
> 1 group of order 3, phi(3)=3D 2 generators (q-1)
> 1 group of order 2, phi(2)=3D 1 generators
>
> 2 4 1
> 3 2 6 4 5 1
> 4 2 1
> 5 4 6 2 3 1
> 6 1
>
> Le mer. 4 d=C3=A9c. 2019 =C3=A0 02:52, Andrey Jivsov <crypto@brainhub.org> a > =C3=A9crit :
>
>> https://tools.ietf.org/html/rfc7919#section-= 5.1 prohibits x=3D(p-1)/2
>> because this results in a peer's public key g^x=3D 1.
>>
>> Allowing this makes some man-in-the middle attacks on TLS easier,<= br> >> because the attacker can predict the value of the ephemeral secret=
>> key on another leg of the connection.
>>
>> On Tue, Dec 3, 2019 at 3:03 PM Scott Fluhrer (sfluhrer)
>> <sfluhr= er@cisco.com> wrote:
>>
>>> See SRF
>>>
>>> FROM: TLS <tls-bounces@ietf.org> ON BEHALF OF Pascal Urien
>>> SENT: Tuesday, December 03, 2019 5:16 PM
>>> TO: tls@ietf= .org
>>> SUBJECT: [TLS] DH security issue in TLS
>>>
>>> I wonder if g**x , with x =3D(1-p)/2 is checked in current TLS= 1.2
>>> implementation ?
>>>
>>> In RFC https://tools.ietf.org/html/rfc7919
>>> "Negotiated Finite Field Diffie-Hellman Ephemeral Paramet= ers for
>>> Transport Layer Security (TLS)"
>>>
>>> "Traditional finite field Diffie-Hellman has each peer ch= oose
>>> their secret exponent from the range [2, p-2].
>>> Using exponentiation by squaring, this means each peer must do=
>>> roughly 2*log_2(p) multiplications,
>>> twice (once for the generator and once for the peer's publ= ic
>>> key)."
>>>
>>> Not True !!!
>>> Even for p=3D safe prime (i.e.. Sophie Germain prime, p=3D2*q+= 1, with
>>> p & q prime number) secret exponent x=3D (p-1)/2 is a secu= rity issue
>>> since :
>>>
>>> g**xy =3D 1=C2=A0 =C2=A0 =C2=A0 =C2=A0with y an even integer >>> g**xy =3D g**x=C2=A0 =C2=A0for y an odd integer
>>>
>>> SRF: actually, g**xy=C2=A0 =3D 1 in both cases, as g**x =3D 1 = (for the g, p
>>> values specified in RFC7919); this is easily seen as all liste= d p
>>> values are safe primes, and in all cases, g=3D2 and p=3D7 mod = 8.
>>>
>>> In any case, why would that be a security issue?=C2=A0 If both= sides
>>> are honest (and select their x, y values honestly), the
>>> probability of one of them selecting (p-1)/2 as their private<= br> >>> value is negligible (even if our selection logic allowed that = as a
>>> possible value =E2=80=93 it generally doesn=E2=80=99t).=C2=A0 = If we have two honest
>>> parties with an adversary replacing one of the side=E2=80=99s = key share
>>> with g**(p-1)/2, well, the protocol transmits signatures of th= e
>>> transcript, and so that=E2=80=99ll be detected. If you have an= honest
>>> side negotiating with a dishonest one, well, the dishonest one=
>>> could select (p-1)/2 as its private value =E2=80=93 however, t= hey could
>>> also run the protocol honestly (and learn the shared secret an= d
>>> the symmetric keys, which are usually the target), and there= =E2=80=99s
>>> nothing the protocol can do about that.
>>>
>>> Now, if an honest party reused their private values for multip= le
>>> exchanges, a similar observation would allow an adversary to >>> obtain a single bit of the private value.=C2=A0 He would do th= at by
>>> performing an exchange with the honest party mostly honestly,<= br> >>> selecting a value x as his private value, but instead of
>>> transmitting g**x as his key share, he would transmit -g**x. >>> Then, the shared value that the honest party would derive is:<= br> >>>
>>> g**xy=C2=A0 with y an even integer
>>>
>>> -g**xy=C2=A0 with y an odd integer
>>>
>>> The adversary can compute both these values, and determine whi= ch
>>> is being used later in the protocol.
>>>
>>> So, the adversary can learn a single bit of the private value<= br> >>> (which doesn=E2=80=99t translate to him learning any bit of th= e shared
>>> secret, much less the symmetric keys) =E2=80=93 however, he ca= nnot
>>> leverage this to learn anything else of the private key.=C2=A0= I do not
>>> believe that a single bit is worth worrying about.=C2=A0 And, = again, if
>>> we generate a fresh DH private value for every exchange (which= we
>>> encourage people to do for PFS), even that single bit doesn=E2= =80=99t
>>> apply to any other exchange.
>>>
>>> If p is not a safe prime (like in RFC 5114) other issues occur= ....
>>>
>>>
>>> Pascal _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/tls<= br> > _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
--00000000000051a8250598f7be3d-- From nobody Thu Dec 5 09:29:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FB7120130 for ; Thu, 5 Dec 2019 09:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_NONE=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 UNfObRQoYYrm for ; Thu, 5 Dec 2019 09:29:26 -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 C94AF120073 for ; Thu, 5 Dec 2019 09:29:25 -0800 (PST) IronPort-SDR: /5AChqlJtJksfoQYtI2AFX00HIVtwP7M+Zoyl/oCCmWpTS7kAcpV2kCV6qlqpdfX148L9Y0v47 OExGDoBBkC6DxQHIvp0neAi9o6AxNAGbsaXLciMurwkkUBEGS0cM6/JZZwKau6D+hTK2BGcBnE sGJwAQ21pmitLHWimtk+vrwpqiFWxHiMJeymPaOUG2jRkOE/pLupk/4THbMpw1p0YJGbHWXlI4 ZfPEzINXuIYcelwn6b2Fx9ePHqPbIkSoBpKNf8YR2Jtvt+BNWlHLoNPc6I8b+zVuGvXp1rRCEH fM4= Received: from unknown (HELO V0501WEXGPR01.isaracorp.com) ([10.5.8.20]) by ip1.isaracorp.com with ESMTP; 05 Dec 2019 17:29:25 +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; Thu, 5 Dec 2019 12:30:10 -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; Thu, 5 Dec 2019 12:30:10 -0500 From: Daniel Van Geest To: "tls@ietf.org" Thread-Topic: TLS 1.3 supported versions and downgrade protection Thread-Index: AQHVq5GkH/CAXcP3Nk2Xq8wyW2l/YA== Date: Thu, 5 Dec 2019 17:30:10 +0000 Message-ID: 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_D49043848893410AA51606B0226FFA4Eisaracom_" MIME-Version: 1.0 Archived-At: Subject: [TLS] TLS 1.3 supported versions and downgrade protection 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, 05 Dec 2019 17:29:28 -0000 --_000_D49043848893410AA51606B0226FFA4Eisaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHRoaW5rIHRoZXJlIG1pZ2h0IGJlIGFtYmlndWl0eSBvciBhbiBpbnRlcm9w ZXJhYmlsaXR5IGlzc3VlIHdpdGggdGhlIFRMUyAxLjMgU2VydmVySGVsbG8gUmFuZG9tIHZhbHVl IGRvd25ncmFkZSBwcm90ZWN0aW9uIGFuZCBzb21lIChwb3NzaWJseT8pIGxlZ2l0aW1hdGUgbmVn b3RpYXRpb24gb2YgVExTIDEuMiB1c2luZyB0aGUgc3VwcG9ydGVkX3ZlcnNpb25zIGV4dGVuc2lv bi4gIExvb2tpbmcgdGhyb3VnaCBSRkMgODQ0NiBhbmQgdGhlIG1haWwgYXJjaGl2ZXMgSSBkb27i gJl0IHNlZSBhbnl0aGluZyB0aGF0IGFkZHJlc3NlcyB0aGlzLCBtYXliZSBJ4oCZdmUgbWlzc2Vk IHNvbWV0aGluZz8NCg0KUkZDIDg0NDYgU2VjdGlvbiA0LjEuMzoNCg0KICAgVExTIDEuMyBoYXMg YSBkb3duZ3JhZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZW1iZWRkZWQgaW4gdGhlIHNlcnZlcidz DQogICByYW5kb20gdmFsdWUuICBUTFMgMS4zIHNlcnZlcnMgd2hpY2ggbmVnb3RpYXRlIFRMUyAx LjIgb3IgYmVsb3cgaW4NCiAgIHJlc3BvbnNlIHRvIGEgQ2xpZW50SGVsbG8gTVVTVCBzZXQgdGhl IGxhc3QgOCBieXRlcyBvZiB0aGVpciBSYW5kb20NCiAgIHZhbHVlIHNwZWNpYWxseSBpbiB0aGVp ciBTZXJ2ZXJIZWxsby4NCg0KICAgSWYgbmVnb3RpYXRpbmcgVExTIDEuMiwgVExTIDEuMyBzZXJ2 ZXJzIE1VU1Qgc2V0IHRoZSBsYXN0IDggYnl0ZXMgb2YNCiAgIHRoZWlyIFJhbmRvbSB2YWx1ZSB0 byB0aGUgYnl0ZXM6DQoNCiAgICAgNDQgNEYgNTcgNEUgNDcgNTIgNDQgMDENCg0KICAgSWYgbmVn b3RpYXRpbmcgVExTIDEuMSBvciBiZWxvdywgVExTIDEuMyBzZXJ2ZXJzIE1VU1QsIGFuZCBUTFMg MS4yDQogICBzZXJ2ZXJzIFNIT1VMRCwgc2V0IHRoZSBsYXN0IDggYnl0ZXMgb2YgdGhlaXIgU2Vy dmVySGVsbG8uUmFuZG9tDQogICB2YWx1ZSB0byB0aGUgYnl0ZXM6DQoNCiAgICAgNDQgNEYgNTcg NEUgNDcgNTIgNDQgMDANCg0KICAgVExTIDEuMyBjbGllbnRzIHJlY2VpdmluZyBhIFNlcnZlckhl bGxvIGluZGljYXRpbmcgVExTIDEuMiBvciBiZWxvdw0KICAgTVVTVCBjaGVjayB0aGF0IHRoZSBs YXN0IDggYnl0ZXMgYXJlIG5vdCBlcXVhbCB0byBlaXRoZXIgb2YgdGhlc2UNCiAgIHZhbHVlcy4g IFRMUyAxLjIgY2xpZW50cyBTSE9VTEQgYWxzbyBjaGVjayB0aGF0IHRoZSBsYXN0IDggYnl0ZXMg YXJlDQogICBub3QgZXF1YWwgdG8gdGhlIHNlY29uZCB2YWx1ZSBpZiB0aGUgU2VydmVySGVsbG8g aW5kaWNhdGVzIFRMUyAxLjEgb3INCiAgIGJlbG93LiAgSWYgYSBtYXRjaCBpcyBmb3VuZCwgdGhl IGNsaWVudCBNVVNUIGFib3J0IHRoZSBoYW5kc2hha2Ugd2l0aA0KICAgYW4gImlsbGVnYWxfcGFy YW1ldGVyIiBhbGVydC4NCg0KU28gd2hlbmV2ZXIgYSBUTFMgMS4zLWNhcGFibGUgc2VydmVyIG5l Z290aWF0ZXMgYSBUTFMgMS4yIG9yIGxvd2VyIHNlc3Npb24gaXQgTVVTVCBzZXQgdGhlIGFwcHJv cHJpYXRlIFJhbmRvbSB2YWx1ZXMuDQoNCkFuZCBhIFRMUyAxLjMgY2xpZW50IE1VU1QgY2hlY2sg Zm9yIHRoZXNlIHZhbHVlcyBhbmQgYWJvcnQgaWYgZm91bmQuIEZ1dHVyZSBUTFMgdmVyc2lvbnMg YXJlbuKAmXQgbWVudGlvbmVkIHNvIHBlcmhhcHMgb25lIG9mIHRoZSB1c2UgY2FzZXMgSeKAmWxs IG1lbnRpb24gYmVsb3cgaXMgbm90IGEgY29uY2VybiB1bnRpbCB0aGUgbmV4dCB2ZXJzaW9uIGlz IGRlZmluZWQgYW5kIHRoZSBiZWhhdmlvciBjYW4gYmUgYWRqdXN0ZWQgdGhlbi4NCg0KQ29uc2lk ZXIgdGhlIHBvdGVudGlhbCBjYXNlcyBmb3IgdGhlIENsaWVudEhlbGxvIHN1cHBvcnRlZF92ZXJz aW9ucyB2YWx1ZXM6DQoNCg0KICAxLiAgc3VwcG9ydGVkX3ZlcnNpb25zID0geyAweDAzMDUgKFRM UyAxLjQpLCAweDAzMDMgKFRMUyAxLjIpIH0NCk9rYXksIFRMUyAxLjQgZG9lc27igJl0IGV4aXN0 IHNvIG1heWJlIHRoaXMgY2FuIGJlIGFkZHJlc3NlZCBpbiB0aGUgZnV0dXJlLiAgSWYgdGhlIHNl cnZlciBzdXBwb3J0cyBUTFMgMS4yIGFuZCBUTFMgMS4zLCBpdCB3aWxsIG5lZ290aWF0ZSBUTFMg MS4yIGFuZCBhZGQgdGhlIFRMUyAxLjIgZG93bmdyYWRlIHByb3RlY3Rpb24gUmFuZG9tIHZhbHVl LiAgVGhlIENsaWVudCB3aWxsIHNlZSB0aGUgVExTIDEuMiB2ZXJzaW9uLCBjaGVjayB0aGUgZG93 bmdyYWRlIHByb3RlY3Rpb24gYW5kIGFib3J0IHRoZSBjb25uZWN0aW9uLiAgQnV0IHRoaXMgaXMg bm90IGEgZG93bmdyYWRlIGlzc3VlLCB0aGlzIGlzIHRoZSBvbmx5IG11dHVhbGx5IGFjY2VwdGFi bGUgVExTIHZlcnNpb24uDQoNCiAgMi4gIHN1cHBvcnRlZF92ZXJzaW9ucyA9IHsgMHgwMzAzIChU TFMgMS4yKSwgMHgwMzA0IChUTFMgMS4zKSB9DQpUaGUgc3VwcG9ydGVkX3ZlcnNpb25zIGxpc3Qg aXMgaW4gb3JkZXIgb2YgY2xpZW50IHByZWZlcmVuY2UsIGJ1dCBpdOKAmXMgbm90IHJlcXVpcmVk IHRoYXQgdGhlIHNlcnZlciByZXNwZWN0IHRoZSBwcmVmZXJlbmNlLiAgSeKAmXZlIHNlZW4gaW1w bGVtZW50YXRpb25zIHdoaWNoIHJlc3BlY3QgdGhlIGNsaWVudOKAmXMgcHJlZmVyZW5jZSBhbmQg b25lcyB3aGljaCBwaWNrIHRoZSBoaWdoZXN0IG11dHVhbGx5IGFjY2VwdGFibGUgdmVyc2lvbi4g IElmIGEgc2VydmVyIHN1cHBvcnRzIFRMUyAxLjIgYW5kIFRMUyAxLjMgYW5kIHJlc3BlY3RzIHRo ZSBjbGllbnTigJlzIHByZWZlcmVuY2UgaXQgd2lsbCBuZWdvdGlhdGUgVExTIDEuMiBhbmQgYWRk IHRoZSBkb3duZ3JhZGUgcHJvdGVjdGlvbiByYW5kb20gdmFsdWUuICBUaGUgY2xpZW50IHdvdWxk IHRoZW4gYWJvcnQgdGhlIGNvbm5lY3Rpb24gZXZlbiB0aG91Z2ggdGhpcyB3b3VsZCBzZWVtIHRv IGJlIGEgbGVnaXRpbWF0ZSBub24tZG93bmdyYWRlIHNpdHVhdGlvbiAgT3IgY2FuIHdlIHdhdmUg b3VyIGhhbmRzIGF0IHRoaXMgYW5kIHNheSBpZiBhIGNsaWVudCBkb2VzbuKAmXQgcHJlZmVyIFRM UyAxLjMgYWJvdmUgVExTIDEuMiB0aGVuIGl04oCZcyBub3QgcmVhbGx5IGEgdHJ1ZSBTY290c21h biBUTFMgMS4zIGNsaWVudCBhbmQgdGhvc2UgTVVTVHMgZG9u4oCZdCByZWFsbHkgYXBwbHkgdG8g aXQ/Lg0KDQpBbmQgc28sIGFyZSB0aGVzZSBsZWdpdGltYXRlIGNhc2VzIHdoaWNoIHNob3VsZCBi ZSBhZGRyZXNzZWQ/DQoNClRoYW5rcywNCkRhbmllbCBWYW4gR2Vlc3QNCg0K --_000_D49043848893410AA51606B0226FFA4Eisaracom_ Content-Type: text/html; charset="utf-8" Content-ID: <81E78511EE9D424895934C36F886F9FD@isara.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2MDIxMDc2MTI7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjkwMDY0NDAwNiA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSB0aGlu ayB0aGVyZSBtaWdodCBiZSBhbWJpZ3VpdHkgb3IgYW4gaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZSB3 aXRoIHRoZSBUTFMgMS4zIFNlcnZlckhlbGxvIFJhbmRvbSB2YWx1ZSBkb3duZ3JhZGUgcHJvdGVj dGlvbiBhbmQgc29tZSAocG9zc2libHk/KSBsZWdpdGltYXRlIG5lZ290aWF0aW9uIG9mIFRMUyAx LjIgdXNpbmcgdGhlIHN1cHBvcnRlZF92ZXJzaW9ucw0KIGV4dGVuc2lvbi4mbmJzcDsgTG9va2lu ZyB0aHJvdWdoIFJGQyA4NDQ2IGFuZCB0aGUgbWFpbCBhcmNoaXZlcyBJIGRvbuKAmXQgc2VlIGFu eXRoaW5nIHRoYXQgYWRkcmVzc2VzIHRoaXMsIG1heWJlIEnigJl2ZSBtaXNzZWQgc29tZXRoaW5n PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5SRkMgODQ0NiBTZWN0aW9uIDQuMS4zOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUTFMgMS4zIGhhcyBhIGRv d25ncmFkZSBwcm90ZWN0aW9uIG1lY2hhbmlzbSBlbWJlZGRlZCBpbiB0aGUgc2VydmVyJ3M8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IHJhbmRvbSB2YWx1ZS4mbmJzcDsgVExTIDEuMyBzZXJ2ZXJzIHdo aWNoIG5lZ290aWF0ZSBUTFMgMS4yIG9yIGJlbG93IGluPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBy ZXNwb25zZSB0byBhIENsaWVudEhlbGxvIE1VU1Qgc2V0IHRoZSBsYXN0IDggYnl0ZXMgb2YgdGhl aXIgUmFuZG9tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB2YWx1ZSBzcGVjaWFsbHkgaW4gdGhlaXIg U2VydmVySGVsbG8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgSWYgbmVn b3RpYXRpbmcgVExTIDEuMiwgVExTIDEuMyBzZXJ2ZXJzIE1VU1Qgc2V0IHRoZSBsYXN0IDggYnl0 ZXMgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZWlyIFJhbmRvbSB2YWx1ZSB0byB0aGUgYnl0 ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNDQg NEYgNTcgNEUgNDcgNTIgNDQgMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBJZiBuZWdvdGlhdGluZyBUTFMgMS4xIG9yIGJlbG93LCBUTFMgMS4zIHNlcnZlcnMgTVVTVCwg YW5kIFRMUyAxLjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHNlcnZlcnMgU0hPVUxELCBzZXQgdGhl IGxhc3QgOCBieXRlcyBvZiB0aGVpciBTZXJ2ZXJIZWxsby5SYW5kb208bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IHZhbHVlIHRvIHRoZSBieXRlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA0NCA0RiA1NyA0RSA0NyA1MiA0NCAwMDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRMUyAxLjMgY2xpZW50cyByZWNlaXZpbmcgYSBTZXJ2 ZXJIZWxsbyBpbmRpY2F0aW5nIFRMUyAxLjIgb3IgYmVsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IE1VU1QgY2hlY2sgdGhhdCB0aGUgbGFzdCA4IGJ5dGVzIGFyZSBub3QgZXF1YWwgdG8gZWl0aGVy IG9mIHRoZXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB2YWx1ZXMuJm5ic3A7IFRMUyAxLjIgY2xp ZW50cyBTSE9VTEQgYWxzbyBjaGVjayB0aGF0IHRoZSBsYXN0IDggYnl0ZXMgYXJlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBub3QgZXF1YWwgdG8gdGhlIHNlY29uZCB2YWx1ZSBpZiB0aGUgU2VydmVy SGVsbG8gaW5kaWNhdGVzIFRMUyAxLjEgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGJlbG93LiZu YnNwOyBJZiBhIG1hdGNoIGlzIGZvdW5kLCB0aGUgY2xpZW50IE1VU1QgYWJvcnQgdGhlIGhhbmRz aGFrZSB3aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbiAmcXVvdDtpbGxlZ2FsX3BhcmFtZXRl ciZxdW90OyBhbGVydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U28gd2hlbmV2ZXIgYSBUTFMgMS4zLWNhcGFibGUg c2VydmVyIG5lZ290aWF0ZXMgYSBUTFMgMS4yIG9yIGxvd2VyIHNlc3Npb24gaXQgTVVTVCBzZXQg dGhlIGFwcHJvcHJpYXRlIFJhbmRvbSB2YWx1ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFuZCBhIFRMUyAxLjMg Y2xpZW50IE1VU1QgY2hlY2sgZm9yIHRoZXNlIHZhbHVlcyBhbmQgYWJvcnQgaWYgZm91bmQuIEZ1 dHVyZSBUTFMgdmVyc2lvbnMgYXJlbuKAmXQgbWVudGlvbmVkIHNvIHBlcmhhcHMgb25lIG9mIHRo ZSB1c2UgY2FzZXMgSeKAmWxsIG1lbnRpb24gYmVsb3cgaXMgbm90IGEgY29uY2VybiB1bnRpbCB0 aGUgbmV4dCB2ZXJzaW9uDQogaXMgZGVmaW5lZCBhbmQgdGhlIGJlaGF2aW9yIGNhbiBiZSBhZGp1 c3RlZCB0aGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db25zaWRlciB0aGUgcG90ZW50aWFsIGNhc2VzIGZvciB0 aGUgQ2xpZW50SGVsbG8gc3VwcG9ydGVkX3ZlcnNpb25zIHZhbHVlczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0i bWFyZ2luLXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5zdXBwb3J0ZWRfdmVy c2lvbnMgPSB7IDB4MDMwNSAoVExTIDEuNCksIDB4MDMwMyAoVExTIDEuMikgfTxicj4NCk9rYXks IFRMUyAxLjQgZG9lc27igJl0IGV4aXN0IHNvIG1heWJlIHRoaXMgY2FuIGJlIGFkZHJlc3NlZCBp biB0aGUgZnV0dXJlLiZuYnNwOyBJZiB0aGUgc2VydmVyIHN1cHBvcnRzIFRMUyAxLjIgYW5kIFRM UyAxLjMsIGl0IHdpbGwgbmVnb3RpYXRlIFRMUyAxLjIgYW5kIGFkZCB0aGUgVExTIDEuMiBkb3du Z3JhZGUgcHJvdGVjdGlvbiBSYW5kb20gdmFsdWUuJm5ic3A7IFRoZSBDbGllbnQgd2lsbCBzZWUg dGhlIFRMUyAxLjIgdmVyc2lvbiwgY2hlY2sgdGhlIGRvd25ncmFkZQ0KIHByb3RlY3Rpb24gYW5k IGFib3J0IHRoZSBjb25uZWN0aW9uLiZuYnNwOyBCdXQgdGhpcyBpcyBub3QgYSBkb3duZ3JhZGUg aXNzdWUsIHRoaXMgaXMgdGhlIG9ubHkgbXV0dWFsbHkgYWNjZXB0YWJsZSBUTFMgdmVyc2lvbi48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5zdXBwb3J0ZWRfdmVyc2lv bnMgPSB7IDB4MDMwMyAoVExTIDEuMiksIDB4MDMwNCAoVExTIDEuMykgfTxicj4NClRoZSBzdXBw b3J0ZWRfdmVyc2lvbnMgbGlzdCBpcyBpbiBvcmRlciBvZiBjbGllbnQgcHJlZmVyZW5jZSwgYnV0 IGl04oCZcyBub3QgcmVxdWlyZWQgdGhhdCB0aGUgc2VydmVyIHJlc3BlY3QgdGhlIHByZWZlcmVu Y2UuJm5ic3A7IEnigJl2ZSBzZWVuIGltcGxlbWVudGF0aW9ucyB3aGljaCByZXNwZWN0IHRoZSBj bGllbnTigJlzIHByZWZlcmVuY2UgYW5kIG9uZXMgd2hpY2ggcGljayB0aGUgaGlnaGVzdCBtdXR1 YWxseSBhY2NlcHRhYmxlIHZlcnNpb24uJm5ic3A7IElmIGEgc2VydmVyDQogc3VwcG9ydHMgVExT IDEuMiBhbmQgVExTIDEuMyBhbmQgcmVzcGVjdHMgdGhlIGNsaWVudOKAmXMgcHJlZmVyZW5jZSBp dCB3aWxsIG5lZ290aWF0ZSBUTFMgMS4yIGFuZCBhZGQgdGhlIGRvd25ncmFkZSBwcm90ZWN0aW9u IHJhbmRvbSB2YWx1ZS4mbmJzcDsgVGhlIGNsaWVudCB3b3VsZCB0aGVuIGFib3J0IHRoZSBjb25u ZWN0aW9uIGV2ZW4gdGhvdWdoIHRoaXMgd291bGQgc2VlbSB0byBiZSBhIGxlZ2l0aW1hdGUgbm9u LWRvd25ncmFkZSBzaXR1YXRpb24mbmJzcDsgT3INCiBjYW4gd2Ugd2F2ZSBvdXIgaGFuZHMgYXQg dGhpcyBhbmQgc2F5IGlmIGEgY2xpZW50IGRvZXNu4oCZdCBwcmVmZXIgVExTIDEuMyBhYm92ZSBU TFMgMS4yIHRoZW4gaXTigJlzIG5vdCByZWFsbHkgYSB0cnVlDQo8cz5TY290c21hbjwvcz4gVExT IDEuMyBjbGllbnQgYW5kIHRob3NlIE1VU1RzIGRvbuKAmXQgcmVhbGx5IGFwcGx5IHRvIGl0Py48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+QW5kIHNvLCBhcmUgdGhlc2UgbGVnaXRpbWF0ZSBjYXNlcyB3aGlj aCBzaG91bGQgYmUgYWRkcmVzc2VkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5EYW5pZWwgVmFuIEdlZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_D49043848893410AA51606B0226FFA4Eisaracom_-- From nobody Thu Dec 5 09:36:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE561208C0 for ; Thu, 5 Dec 2019 09:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 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, PDS_BTC_ID=0.499, 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=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 9wMZB2NieQtk for ; Thu, 5 Dec 2019 09:35:57 -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 1BCDC1208AB for ; Thu, 5 Dec 2019 09:35:57 -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 xB5HTHsK005244; Thu, 5 Dec 2019 17:35:56 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 : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=QVFQCWvscu3Zjt56ts4iyX1Yb7etnMVtCJqgouzAuJs=; b=DX696YzTQESVgph/+TF2GEj4qAjigz0IhZBTbQdod2AXrqW2FGuEPTAmH95uafV15YMK S7cqHmi04Mtf38Qy28ugdZTRXkPuOHssRXeK+v9KVmulqasW+lZ7OXHaEHkMeVukHAVs EjhKta5qBhJ6MOBb+oZq3XXU5OHQhV9wvUUG4oTHdNblke0G6+d3pxAsrqOP9Uxtu/nD aC4NZasMY44wFsidgPQw/5WeaExeyaGx6IbvnKcAGUZspYsx3hd+mQr5slrJqMypgIXS buK/7h+2jxXiw9b+msDwb79LPu1ductkgNQu80i7eEBfnDT/V1imDFjtWluLc0fQYnfk Ww== 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 2wnk9tbeer-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Dec 2019 17:35:56 +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 xB5HWS95022730; Thu, 5 Dec 2019 12:35:55 -0500 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint6.akamai.com with ESMTP id 2wkmn3g9bp-1; Thu, 05 Dec 2019 12:35:55 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 2D86C1FCD8; Thu, 5 Dec 2019 17:35:55 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1icv2f-0004hQ-Pd; Thu, 05 Dec 2019 09:35:53 -0800 Date: Thu, 5 Dec 2019 09:35:53 -0800 From: Benjamin Kaduk To: Daniel Van Geest Cc: "tls@ietf.org" Message-ID: <20191205173553.GS3397@akamai.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-05_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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912050147 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-05_05:2019-12-04,2019-12-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 clxscore=1011 spamscore=0 impostorscore=0 mlxscore=0 adultscore=0 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912050147 Archived-At: Subject: Re: [TLS] TLS 1.3 supported versions and downgrade protection 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, 05 Dec 2019 17:35:59 -0000 On Thu, Dec 05, 2019 at 05:30:10PM +0000, Daniel Van Geest wrote: > Hi all, > > I think there might be ambiguity or an interoperability issue with the TLS 1.3 ServerHello Random value downgrade protection and some (possibly?) legitimate negotiation of TLS 1.2 using the supported_versions extension. Looking through RFC 8446 and the mail archives I don’t see anything that addresses this, maybe I’ve missed something? > > RFC 8446 Section 4.1.3: > > TLS 1.3 has a downgrade protection mechanism embedded in the server's > random value. TLS 1.3 servers which negotiate TLS 1.2 or below in > response to a ClientHello MUST set the last 8 bytes of their Random > value specially in their ServerHello. > > If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of > their Random value to the bytes: > > 44 4F 57 4E 47 52 44 01 > > If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2 > servers SHOULD, set the last 8 bytes of their ServerHello.Random > value to the bytes: > > 44 4F 57 4E 47 52 44 00 > > TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below > MUST check that the last 8 bytes are not equal to either of these > values. TLS 1.2 clients SHOULD also check that the last 8 bytes are > not equal to the second value if the ServerHello indicates TLS 1.1 or > below. If a match is found, the client MUST abort the handshake with > an "illegal_parameter" alert. > > So whenever a TLS 1.3-capable server negotiates a TLS 1.2 or lower session it MUST set the appropriate Random values. > > And a TLS 1.3 client MUST check for these values and abort if found. Future TLS versions aren’t mentioned so perhaps one of the use cases I’ll mention below is not a concern until the next version is defined and the behavior can be adjusted then. > > Consider the potential cases for the ClientHello supported_versions values: > > > 1. supported_versions = { 0x0305 (TLS 1.4), 0x0303 (TLS 1.2) } > Okay, TLS 1.4 doesn’t exist so maybe this can be addressed in the future. If the server supports TLS 1.2 and TLS 1.3, it will negotiate TLS 1.2 and add the TLS 1.2 downgrade protection Random value. The Client will see the TLS 1.2 version, check the downgrade protection and abort the connection. But this is not a downgrade issue, this is the only mutually acceptable TLS version. This is analogous to the case of wanting to support TLS 1.0 and 1.2 but not 1.1, which did (IIRC) get a little bit of discussion including from Andrei Popov. My recollection is that we didn't really feel a need to support "gaps" in supported versions for this downgrade-protection scheme. > 2. supported_versions = { 0x0303 (TLS 1.2), 0x0304 (TLS 1.3) } > The supported_versions list is in order of client preference, but it’s not required that the server respect the preference. I’ve seen implementations which respect the client’s preference and ones which pick the highest mutually acceptable version. If a server supports TLS 1.2 and TLS 1.3 and respects the client’s preference it will negotiate TLS 1.2 and add the downgrade protection random value. The client would then abort the connection even though this would seem to be a legitimate non-downgrade situation Or can we wave our hands at this and say if a client doesn’t prefer TLS 1.3 above TLS 1.2 then it’s not really a true Scotsman TLS 1.3 client and those MUSTs don’t really apply to it?. I had forgotten that we implied a potential for client preference of supported versions. We could perhaps debate whether it's "legitimate" for a server to prefer 1.2 over 1.3, but I think it's clear that (assuming the negotiation is protected by a full transcript hash, as in 1.3 or 1.2 with extended master secret) a server negotiating 1.2 in this case should not apply the downgrade-protection scheme. -Ben From nobody Thu Dec 5 09:48:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B71209C2 for ; Thu, 5 Dec 2019 09:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.751 X-Spam-Level: X-Spam-Status: No, score=-8.751 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, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5YMZoVXqr4Sq for ; Thu, 5 Dec 2019 09:48:28 -0800 (PST) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B41D12095C for ; Thu, 5 Dec 2019 09:48:28 -0800 (PST) Received: by mail-pl1-x644.google.com with SMTP id k20so1526707pll.13 for ; Thu, 05 Dec 2019 09:48:28 -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=GfN93Yec3wpUnscSsotc5LkuqUS9Nqx5xbOWeXmw/8w=; b=SpIcg7nhHNx4EqHRrfqHdTYce+ERWNnOLaGA00IxCQNUBXeRFex6BZt6ruMob5l8Cg kkJ6EvoZdKViup84aGnQb+l9MYSmcWMdYQf2HAehl2u78lisxcq2TU4xEjfxa89TLv28 ZcrJod9rDrhWH4EcjCAsVBymC5g5UUGOP3tNo= 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=GfN93Yec3wpUnscSsotc5LkuqUS9Nqx5xbOWeXmw/8w=; b=e/IZPWm8JEYBMq4//l3jZa8pEESl3UuB5fxxGpPIOUH5totRq8IOAyxAwmP+fCPcgW 4jemOHrFDvEa1fpd8tC/9O7n0iunnBtJuJZlicx2nr/n9rcSlHIgzgg50x4ib+bW0C4h ZqkrlKJ3bpzc9Z7pLrfQnAnrSB/1WX3/9dVFucT9VW2Uqd6Ey0E9zCfiiiEu9tjZD/ox l3UjT6z09WMghqXfAyfSrQ3AuPY7yU+sxbU7ns0G/PsW08Wt7BxrSMKMykPqXMX7PNT5 v/2mNRV8lmeAn6SW64no08BFGFWi4tWwVtE3dM6LD754xgehijvyVjEpEI+1YXZ/zmzM AvZg== X-Gm-Message-State: APjAAAW25UgsvxML7+iy5YKk0JW7V0F0whyTtT9KcMlOVpiJcP003VBf VXOd+moGpAGD62yXoOfQ6Hw14REzeSOaEU4aYvRa X-Google-Smtp-Source: APXvYqyT4ENGIiYDmWfyeSsgKFv8pZ9p0ToBs6pyIaLyyPVZho49qxmwFL2bwyKWhmgvbwXZCuwdnYMZ/KCbA7RuWAc= X-Received: by 2002:a17:90a:2188:: with SMTP id q8mr10613689pjc.47.1575568107667; Thu, 05 Dec 2019 09:48:27 -0800 (PST) MIME-Version: 1.0 References: <20191205173553.GS3397@akamai.com> In-Reply-To: <20191205173553.GS3397@akamai.com> From: David Benjamin Date: Thu, 5 Dec 2019 12:48:11 -0500 Message-ID: To: Benjamin Kaduk Cc: Daniel Van Geest , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006118f60598f8890e" Archived-At: Subject: Re: [TLS] TLS 1.3 supported versions and downgrade protection 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, 05 Dec 2019 17:48:33 -0000 --0000000000006118f60598f8890e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 5, 2019 at 12:36 PM Benjamin Kaduk wrote: > On Thu, Dec 05, 2019 at 05:30:10PM +0000, Daniel Van Geest wrote: > > Hi all, > > > > I think there might be ambiguity or an interoperability issue with the > TLS 1.3 ServerHello Random value downgrade protection and some (possibly?= ) > legitimate negotiation of TLS 1.2 using the supported_versions extension. > Looking through RFC 8446 and the mail archives I don=E2=80=99t see anythi= ng that > addresses this, maybe I=E2=80=99ve missed something? > > > > RFC 8446 Section 4.1.3: > > > > TLS 1.3 has a downgrade protection mechanism embedded in the server'= s > > random value. TLS 1.3 servers which negotiate TLS 1.2 or below in > > response to a ClientHello MUST set the last 8 bytes of their Random > > value specially in their ServerHello. > > > > If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of > > their Random value to the bytes: > > > > 44 4F 57 4E 47 52 44 01 > > > > If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2 > > servers SHOULD, set the last 8 bytes of their ServerHello.Random > > value to the bytes: > > > > 44 4F 57 4E 47 52 44 00 > > > > TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below > > MUST check that the last 8 bytes are not equal to either of these > > values. TLS 1.2 clients SHOULD also check that the last 8 bytes are > > not equal to the second value if the ServerHello indicates TLS 1.1 o= r > > below. If a match is found, the client MUST abort the handshake wit= h > > an "illegal_parameter" alert. > > > > So whenever a TLS 1.3-capable server negotiates a TLS 1.2 or lower > session it MUST set the appropriate Random values. > > > > And a TLS 1.3 client MUST check for these values and abort if found. > Future TLS versions aren=E2=80=99t mentioned so perhaps one of the use ca= ses I=E2=80=99ll > mention below is not a concern until the next version is defined and the > behavior can be adjusted then. > > > > Consider the potential cases for the ClientHello supported_versions > values: > > > > > > 1. supported_versions =3D { 0x0305 (TLS 1.4), 0x0303 (TLS 1.2) } > > Okay, TLS 1.4 doesn=E2=80=99t exist so maybe this can be addressed in t= he > future. If the server supports TLS 1.2 and TLS 1.3, it will negotiate TL= S > 1.2 and add the TLS 1.2 downgrade protection Random value. The Client wi= ll > see the TLS 1.2 version, check the downgrade protection and abort the > connection. But this is not a downgrade issue, this is the only mutually > acceptable TLS version. > > This is analogous to the case of wanting to support TLS 1.0 and 1.2 but > not 1.1, which did (IIRC) get a little bit of discussion including from > Andrei Popov. My recollection is that we didn't really feel a need to > support "gaps" in supported versions for this downgrade-protection scheme= . > Prior to supported_versions we didn't have gaps at all. We can now do gaps, but only starting at TLS 1.3. You're right that gaps which span TLS 1.3 are problematic. This is related to why we couldn't ship the downgrade signal in early draft deployments. Note TLS is still downgrade-protected without this signal by way of the transcript. The signal fixes some fragilities in the downgrade when you get all the way down to TLS 1.2. > > 2. supported_versions =3D { 0x0303 (TLS 1.2), 0x0304 (TLS 1.3) } > > The supported_versions list is in order of client preference, but it=E2= =80=99s > not required that the server respect the preference. I=E2=80=99ve seen > implementations which respect the client=E2=80=99s preference and ones wh= ich pick > the highest mutually acceptable version. If a server supports TLS 1.2 an= d > TLS 1.3 and respects the client=E2=80=99s preference it will negotiate TL= S 1.2 and > add the downgrade protection random value. The client would then abort t= he > connection even though this would seem to be a legitimate non-downgrade > situation Or can we wave our hands at this and say if a client doesn=E2= =80=99t > prefer TLS 1.3 above TLS 1.2 then it=E2=80=99s not really a true Scotsman= TLS 1.3 > client and those MUSTs don=E2=80=99t really apply to it?. > > I had forgotten that we implied a potential for client preference of > supported versions. We could perhaps debate whether it's "legitimate" fo= r > a server to prefer 1.2 over 1.3, but I think it's clear that (assuming th= e > negotiation is protected by a full transcript hash, as in 1.3 or 1.2 with > extended master secret) a server negotiating 1.2 in this case should not > apply the downgrade-protection scheme. > (FWIW, our server implementation uses server preference and doesn't pay attention to the client order.) Having the server sometimes omit the "PS: I support TLS 1.3" signal in TLS 1.2 ServerHellos would break the protection. The ServerHello random signal is a hardening measure because TLS 1.2 failed to include the entire handshake transcript in the ServerKeyExchange signature, only the randoms. As a result the downgrade protection is rather fragile. This signal takes advantage of the few pieces which are signed. But because the signature does not include the ClientHello which triggered it, it's important that *all* TLS 1.2 ServerHellos from the server include it. I think a client which advertises something like (2) probably shouldn't enforce the signal because it apparently doesn't actually prefer TLS 1.3 over TLS 1.2. Better yet, don't advertise (2). :-) David --0000000000006118f60598f8890e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 12:36 PM Benjamin = Kaduk <bkaduk@akamai.com> wr= ote:
On Thu, Dec 05, 2019 at 05:30:10PM +0000, Daniel Van Geest = wrote:
> Hi all,
>
> I think there might be ambiguity or an interoperability issue with the= TLS 1.3 ServerHello Random value downgrade protection and some (possibly?)= legitimate negotiation of TLS 1.2 using the supported_versions extension.= =C2=A0 Looking through RFC 8446 and the mail archives I don=E2=80=99t see a= nything that addresses this, maybe I=E2=80=99ve missed something?
>
> RFC 8446 Section 4.1.3:
>
>=C2=A0 =C2=A0 TLS 1.3 has a downgrade protection mechanism embedded in = the server's
>=C2=A0 =C2=A0 random value.=C2=A0 TLS 1.3 servers which negotiate TLS 1= .2 or below in
>=C2=A0 =C2=A0 response to a ClientHello MUST set the last 8 bytes of th= eir Random
>=C2=A0 =C2=A0 value specially in their ServerHello.
>
>=C2=A0 =C2=A0 If negotiating TLS 1.2, TLS 1.3 servers MUST set the last= 8 bytes of
>=C2=A0 =C2=A0 their Random value to the bytes:
>
>=C2=A0 =C2=A0 =C2=A0 44 4F 57 4E 47 52 44 01
>
>=C2=A0 =C2=A0 If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, an= d TLS 1.2
>=C2=A0 =C2=A0 servers SHOULD, set the last 8 bytes of their ServerHello= .Random
>=C2=A0 =C2=A0 value to the bytes:
>
>=C2=A0 =C2=A0 =C2=A0 44 4F 57 4E 47 52 44 00
>
>=C2=A0 =C2=A0 TLS 1.3 clients receiving a ServerHello indicating TLS 1.= 2 or below
>=C2=A0 =C2=A0 MUST check that the last 8 bytes are not equal to either = of these
>=C2=A0 =C2=A0 values.=C2=A0 TLS 1.2 clients SHOULD also check that the = last 8 bytes are
>=C2=A0 =C2=A0 not equal to the second value if the ServerHello indicate= s TLS 1.1 or
>=C2=A0 =C2=A0 below.=C2=A0 If a match is found, the client MUST abort t= he handshake with
>=C2=A0 =C2=A0 an "illegal_parameter" alert.
>
> So whenever a TLS 1.3-capable server negotiates a TLS 1.2 or lower ses= sion it MUST set the appropriate Random values.
>
> And a TLS 1.3 client MUST check for these values and abort if found. F= uture TLS versions aren=E2=80=99t mentioned so perhaps one of the use cases= I=E2=80=99ll mention below is not a concern until the next version is defi= ned and the behavior can be adjusted then.
>
> Consider the potential cases for the ClientHello supported_versions va= lues:
>
>
>=C2=A0 =C2=A01.=C2=A0 supported_versions =3D { 0x0305 (TLS 1.4), 0x0303= (TLS 1.2) }
> Okay, TLS 1.4 doesn=E2=80=99t exist so maybe this can be addressed in = the future.=C2=A0 If the server supports TLS 1.2 and TLS 1.3, it will negot= iate TLS 1.2 and add the TLS 1.2 downgrade protection Random value.=C2=A0 T= he Client will see the TLS 1.2 version, check the downgrade protection and = abort the connection.=C2=A0 But this is not a downgrade issue, this is the = only mutually acceptable TLS version.

This is analogous to the case of wanting to support TLS 1.0 and 1.2 but not= 1.1, which did (IIRC) get a little bit of discussion including from Andrei= Popov.=C2=A0 My recollection is that we didn't really feel a need to s= upport "gaps" in supported versions for this downgrade-protection= scheme.

Prior to supported_versions we= didn't have gaps at all. We can now do gaps, but only starting at TLS = 1.3. You're right that gaps which span TLS 1.3 are problematic. This is= related to why we couldn't ship the downgrade signal in early draft de= ployments.

Note TLS is still downgrade-protected w= ithout this signal by way of the transcript. The signal fixes some fragilit= ies in the downgrade when you get all the way down to TLS 1.2.
= =C2=A0
>=C2=A0 =C2=A02.=C2=A0 supported_versions =3D { 0x0303 (TLS 1.2), 0x0304= (TLS 1.3) }
> The supported_versions list is in order of client preference, but it= =E2=80=99s not required that the server respect the preference.=C2=A0 I=E2= =80=99ve seen implementations which respect the client=E2=80=99s preference= and ones which pick the highest mutually acceptable version.=C2=A0 If a se= rver supports TLS 1.2 and TLS 1.3 and respects the client=E2=80=99s prefere= nce it will negotiate TLS 1.2 and add the downgrade protection random value= .=C2=A0 The client would then abort the connection even though this would s= eem to be a legitimate non-downgrade situation=C2=A0 Or can we wave our han= ds at this and say if a client doesn=E2=80=99t prefer TLS 1.3 above TLS 1.2= then it=E2=80=99s not really a true Scotsman TLS 1.3 client and those MUST= s don=E2=80=99t really apply to it?.

I had forgotten that we implied a potential for client preference of suppor= ted versions.=C2=A0 We could perhaps debate whether it's "legitima= te" for a server to prefer 1.2 over 1.3, but I think it's clear th= at (assuming the negotiation is protected by a full transcript hash, as in = 1.3 or 1.2 with extended master secret) a server negotiating 1.2 in this ca= se should not apply the downgrade-protection scheme.
<= br>
(FWIW, our server implementation uses server preference and d= oesn't pay attention to the client order.)

Hav= ing the server sometimes omit the "PS: I support TLS 1.3" signal = in TLS 1.2 ServerHellos would=C2=A0break the protection. The ServerHello ra= ndom signal is a hardening measure because TLS 1.2 failed to include the en= tire handshake transcript in the ServerKeyExchange signature, only the rand= oms. As a result the downgrade protection is rather fragile. This signal ta= kes advantage of the few pieces which are signed. But because the signature= does not include the ClientHello which triggered it, it's important th= at all=C2=A0TLS 1.2 ServerHellos from the server include it.

I think a client which advertises something like (2) prob= ably shouldn't enforce the signal because it apparently doesn't act= ually prefer TLS 1.3 over TLS 1.2. Better yet, don't advertise (2). :-)=

David
--0000000000006118f60598f8890e-- From nobody Thu Dec 5 13:41:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEF5120220 for ; Thu, 5 Dec 2019 13:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 1NxhKQz7ipO6 for ; Thu, 5 Dec 2019 13:41:51 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA36120867 for ; Thu, 5 Dec 2019 13:41:50 -0800 (PST) Received: from xse21.mail2web.com ([66.113.196.21] helo=xse.mail2web.com) by mx66.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1icysc-0006Jc-It for tls@ietf.org; Thu, 05 Dec 2019 22:41:48 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 47TTgr0Jkpz1tPr for ; Thu, 5 Dec 2019 13:41:44 -0800 (PST) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1icysZ-0005O1-TX for tls@ietf.org; Thu, 05 Dec 2019 13:41:43 -0800 Received: (qmail 20224 invoked from network); 5 Dec 2019 21:41:43 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Dec 2019 21:41:43 -0000 To: Alessandro Ghedini Cc: last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org, secdir@ietf.org References: <157498929764.5575.7815291384505057169@ietfa.amsl.com> <20191205164212.GB12839@sokka.flat11.house> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <1740c80a-498f-e706-5622-82d8115cf773@huitema.net> Date: Fri, 6 Dec 2019 05:41:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191205164212.GB12839@sokka.flat11.house> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.21 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.21/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.21/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fKZ8wcD78QFAaYhvfMzLIKpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4ZiU+WAv3O8Su+j08Sej1iFgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+eXohGLM8tFKoQ6vM7cAlL2mdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnKW/tiYHEZti Qrr+6ZrIG1ZIkTy17ZAQacqCFwSs+WhjxvH8+JPMngXom5w3xXAoi3eueQZINNaNebrXzVQ+VIMk 6Q9V9YO5wBS5yaTKclLkqt3efQtwMZ/Qk+syj1/xbxg66gs5OuzYxJgw5atIxePaw4mGPOB1lCDk b7ANR1sP2yV1bTpbC+aqtbvkBWfMoNQ84QG89JN6MvpNdzLqW7o5K9HfWgh6ZcxrIvtE/drAHHAS JNUmoOHSoqgqxfHmWfZIwxxhwvMcWh0MGcvUtQj262mS97p/5Wms4KQevObv1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] [Last-Call] Secdir last call review of draft-ietf-tls-certificate-compression-07 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, 05 Dec 2019 21:41:55 -0000 On 12/6/2019 12:42 AM, Alessandro Ghedini wrote: > On Thu, Nov 28, 2019 at 05:01:37PM -0800, Christian Huitema via Datatra= cker wrote: >> Reviewer: Christian Huitema >> Review result: Has Issues >> >> I have reviewed draft-ietf-tls-certificate-compression-07 as part of t= he >> security directorate's ongoing effort to review all IETF documents bei= ng >> processed by the IESG. These comments were written primarily for the b= enefit of >> the security area directors. Document editors and WG chairs should tre= at these >> comments just like any other last call comments. > Thank you for the review! > >> Draft-ietf-tls-certificate-compression-07 defines two new TLS extensio= ns to >> negotiate and then apply compression of the Certificate message. The d= raft is >> clear and well written, and the extensions are already widely deployed= =2E I would >> like to say "ready", but I have to say "almost". >> >> This document is almost ready, except for one nit and one issue. >> >> First, one nit. The draft references the "Certificate message", but th= ere is no >> formal reference section 4.4.2 of RFC8446. Please add that, maybe at t= he >> beginning of section 4. It may seem obvious to members of the TLS WG, = but >> uninformed readers will appreciate. > Makes sense. I created https://github.com/tlswg/certificate-compression= /pull/30 > to address this. Thanks. > >> Second, my actual concern. Compression may leak information, because d= ifferent >> certificate chains will compress differently. The authors mention that= an >> attacker will not be able to inject data in the certificate chain, and= thus >> that attacks of the CRIME variety are unlikely. That's correct, but th= at's not >> the entire story. >> >> TLS 1.3 will encrypt the compressed certificate message but the length= of that >> message could be deduced from the length of the server's encrypted mes= sage. >> Attackers might be able to derive from that length the identity of the= server, >> even if the SNI is encrypted. >> >> One could say that in the absence of compression the length of the cer= tificate >> chain is also available. Indeed, the problem is flagged in >> draft-ietf-tls-esni-05, which states in section 5.3 that "it (the serv= er) >> SHOULD pad the Certificate message, via padding at the record layer, s= uch that >> its length equals the size of the largest possible Certificate (messag= e) >> covered by the same ESNI key." >> >> Certificate compression introduces a level of complexity here. If only= some >> servers in the anonymity set support compression, attackers can work w= ith a >> smaller anonymity subset. If all attackers support compression, the pa= dding >> should try to match the largest Compressed Certificate. >> >> It might be good to discuss this issue in the security consideration s= ection. > I agree tha this is worth discussing, but it seems like it belongs in t= he ESNI > draft itself, so implementers of ESNI will be more likely to take compr= ession > into consideration. That is, we can expand the section you quoted to al= so > explicitly mention certificate compression. What do you think? I can lo= ok into > proposing a PR for this. I agree with you that the bulk of the work belongs in the ESNI draft. However, it would be nice to have a short reminder of the issue in the security section of the compression draft. Something like: Although the Certificate extension is encrypted in TLS 1.3, third parties can deduce some information about the certificate from the length of the handshake messages. Compression does not prevent this issue, as different certificate chains will compress to different lengths. When privacy is desired, implementers need to consider appropriate padding strategies. Discussion of these padding strategies is out of scope for this document. -- Christian Huitema From nobody Thu Dec 5 17:37:45 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1524212004D for ; Thu, 5 Dec 2019 17:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJMM_sTCui1u for ; Thu, 5 Dec 2019 17:37:41 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255109.outbound.protection.outlook.com [40.92.255.109]) (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 9D5BE12004C for ; Thu, 5 Dec 2019 17:37:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UN2OPUW1UqEr/fH8+wD4kuz6aKWSvvDzFa+0+0thwGDceZtKbYdIdA54jExbqS1YgA+JIO9gAMF5Zf/YWfNv+rK/2zITAxQB+OoaVMeC+KIL8ln8jf7KGyt788wYVdSJEaEbfi3Qn2NTPapY7uV0HiEYYuCcXSXBB9bMCOaPRegJbFSo4/VmIP5Vj+4bjmzdT1jo7GiX/H1YrDmn4l8469/QHmkLMK+ctRaiT8WGOG+ORR96TKHt9chsVW3sal8MTcjuZmRna3TU9YdiG9kohoOukZyiitT4mFbqPZPBl3jVqbq7EKTrkkBu1vtn5KXj8d2pW1dMbQPkbjM3GfTeZg== 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=m3IiZSAq5O8i/BsXryCpl8/ctsnVmsV4WkBMdh11pe8=; b=gMLtHxRptkk0jEos+5amC2Qhv5LH4Q/nGfDRZQjPwe5JMElKH1/P2hsA6aARFp1pfMiICPKc9ZucLvqssp+Oyz1G83/CjHPxBB3BDosAsB+Hds1dKr3fsC0AphSgwpbvuDVXsKfRX3jYVHRvArQht1zINxg90Il8Yng/iKvM0WS1xDutNo2suTeRJCtY32z/zhrCN/TESVoJm+I6I41ynhRl5tNozY7Y1sOqOxFu0hyJ+K+KVyCHedNg94NZV8/3gMIFTi8CocHbLhXE701qE2zQfk/rFMR/7HSuO6WARkDmG6gsYUDxKP7o3gaslFmnPDJH9amblVv3EAQ2tu/MsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m3IiZSAq5O8i/BsXryCpl8/ctsnVmsV4WkBMdh11pe8=; b=a+RC1q3KcM/Gq2j+HckeqVJch/0SgvaE0OxHoStgBNk3CklMN/bNjuNLOxeuksta7df4cmjIyeWODyeXVDjj56laRgKs2mTtNGxWMyp86q9gtWgGbo5IlqopadfSeQTEjvUkqgzq+QfdqDZh5alZssXa2FZU6iHC1aWa3ZH0m2cKTb2XYkFHKgg3Ok1gL7bs4GM1jbf5SXEIih0IiuRag2/cHzQ+Wq6nqVQpc2gVJhP++qAKEyqPVKCBb6/MU6f0MQNXJ1a019oZ+9RwTI874bHOep4SCxYjjHB+dTFHmiIj8RPgWnnJ7T1eND0yXg8vxyQ6kmu29a4XMuj9QBPuBA== Received: from HK2APC01FT106.eop-APC01.prod.protection.outlook.com (10.152.248.55) by HK2APC01HT246.eop-APC01.prod.protection.outlook.com (10.152.249.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.25; Fri, 6 Dec 2019 01:37:38 +0000 Received: from PU1PR01MB1947.apcprd01.prod.exchangelabs.com (10.152.248.52) by HK2APC01FT106.mail.protection.outlook.com (10.152.249.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.25 via Frontend Transport; Fri, 6 Dec 2019 01:37:38 +0000 Received: from PU1PR01MB1947.apcprd01.prod.exchangelabs.com ([fe80::3076:a7ea:eac2:8b10]) by PU1PR01MB1947.apcprd01.prod.exchangelabs.com ([fe80::3076:a7ea:eac2:8b10%5]) with mapi id 15.20.2495.026; Fri, 6 Dec 2019 01:37:37 +0000 From: Nasrul Zikri To: "tls@ietf.org" Thread-Topic: [TLS] DH security issue in TLS Thread-Index: AQHVq6XdgNNXYqyQtES5UWU5It4MXA== Date: Fri, 6 Dec 2019 01:37:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:5CBA10D1CBB9573FA5A7D0DEC0804DD15CB1B0BCE831A3F9279E56500F147B99; UpperCasedChecksum:AF43AFD23C7DDD1E81DB417E0E69A98A9D000EDB856A44A7FD11E3D601A3C068; SizeAsReceived:6698; Count:42 x-tmn: [HF0b5rBEuG+AywnhWmca7K0++/gxe1Ah] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 0800b7bd-9d70-491b-c71a-08d779ece01c x-ms-traffictypediagnostic: HK2APC01HT246: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dBcLRpdLnCm/HVEvJtQZQEUVmgPFMC97J9ZhkAACT64mKdn4Tw0gHhgQ73UEfpD0ulg+nqtoejouzqjJe6ZEYlUrYuQcUwPYMQrqR+IsjRTxfHpNbMcJ73IS2y2Q0+a8iGYIdvOmLheQwywTzSbncbEZWauIrrCc3zH660me+XaOwzUR0mvuyzFqrbV4uJZj x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PU1PR01MB19478C2D4355867979F8C82CA85C0PU1PR01MB1947apcp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 0800b7bd-9d70-491b-c71a-08d779ece01c X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 01:37:37.4750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT246 Archived-At: Subject: Re: [TLS] DH security issue in 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, 06 Dec 2019 01:37:44 -0000 --_000_PU1PR01MB19478C2D4355867979F8C82CA85C0PU1PR01MB1947apcp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Hi All > > I found in NIST Special Publication 800-56A Revision 3 > 5.6.2.3.1 FFC Full Public-Key Validation Routine > 2. Verify that 1 =3D y q mod p. That should be, 1 =3D y^q mod p. > > This test is implemented in OPENSSL > > This test relies on the fact that q and p are prime > > Pascal > > > If you want the guarantee that your DH key exchange is contributive, > > that is, that neither single party can determine with high-probability > > the DH secret produced by the key exchange, you can either 1. use one o= f > > the safe groups defined in RFC7919. When using these groups, you should > > pick an exponent between 2 and q-1. 2. Figure out all of the low-order > > elements of Zp* and check that the DH secret is not one of them. What must the server do if the client is old and does not support the safe = groups in RFC 7919? The advice from Mozilla is generate a 1024-bit Diffie-H= ellman group. Is there good code to generate safe group efficiently? Will O= penSSL generate safe group? Tk, Nasrul --_000_PU1PR01MB19478C2D4355867979F8C82CA85C0PU1PR01MB1947apcp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 

> Hi All=0A=
> =0A=
> I found in NIST Special Publication 800-56A Revision 3=0A=
> 5.6.2.3.1 FFC Full Public-Key Validation Routine=0A=
> 2. Verify  that  1 =3D y q mod p.

That should be, 1 =3D y^q mod=
 p.

> =0A=
> This test is implemented in OPENSSL=0A=
> =0A=
> This test relies on the fact  that q and p are prime=0A=
> =0A=
> Pascal=0A=
> =0A=

> > If you want the guarantee that your DH key exchange is contr=
ibutive,=0A=
> > that is, that neither single party can determine with high-probab=
ility=0A=
> > the DH secret produced by the key exchange, you can either 1. use=
 one of=0A=
> > the safe groups defined in RFC7919. When using these groups, you =
should=0A=
> > pick an exponent between 2 and q-1. 2. Figure out all of the low-=
order=0A=
> > elements of Zp* and check that the DH secret is not one of them.<=
br>
What must the= server do if the client is old and does not support the safe groups in RFC= 7919? The advice from Mozilla is generate a 1024-bit Diffie-Hellman group.= Is there good code to generate safe group efficiently? Will OpenSSL generate safe group?

Tk, Nasrul=

--_000_PU1PR01MB19478C2D4355867979F8C82CA85C0PU1PR01MB1947apcp_-- From nobody Thu Dec 5 18:33:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1D912004C for ; Thu, 5 Dec 2019 18:33:14 -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 Vo5ONhM8rIwN for ; Thu, 5 Dec 2019 18:33:12 -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 1DAB9120018 for ; Thu, 5 Dec 2019 18:33:12 -0800 (PST) Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (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 485BD30DA8E for ; Thu, 5 Dec 2019 21:33:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 5 Dec 2019 21:33:07 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: "openssl-users@openssl.org" Message-Id: <186747D1-C8A6-43D0-8084-71DD50B91EAE@dukhovni.org> References: To: IETF TLS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] DH security issue in 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, 06 Dec 2019 02:33:14 -0000 > On Dec 5, 2019, at 8:37 PM, Nasrul Zikri = wrote: >=20 > What must the server do if the client is old and does not support the = safe groups in RFC 7919? Presumably the old client is doing TLS 1.2 (or 1.0), since with TLS 1.3, the client MUST specify which groups it supports, and no others can be used. The server can use any FFDHE group of its choice (provided = suitable DHE ciphers are supported by the client), including one of 7919 groups, or use ECDHE if that's supported... > The advice from Mozilla is generate a 1024-bit Diffie-Hellman group. > Is there good code to generate safe group efficiently? FFDHE parameter generation is too slow to do on the fly. Such groups are pre-generated, and so the efficiency is not a significant concern. > Will OpenSSL generate safe group? Yes, if you ask nicely, but that's more of a question for the = openssl-users list than for the TLS WG. It seems this thread is no longer on topic for this list, perhaps time = to consider moving any residual questions to more appropriate lists. --=20 Viktor. From nobody Thu Dec 5 20:52:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3C6120045 for ; Thu, 5 Dec 2019 20:52:36 -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 jZ0GQiSDMRSg for ; Thu, 5 Dec 2019 20:52:34 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B929C12001A for ; Thu, 5 Dec 2019 20:52:34 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id g15so4187297vsf.1 for ; Thu, 05 Dec 2019 20:52:34 -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=iU6YODMO3BwYsaTDgfCdrf0cEjSMFB6LJq8zFvVTr2o=; b=SBH6KuMN3JgRh2uwW8HHaQChkxeT+0aOUt24IzESdfqFKs62oJlOiaDlqPrjAheNBj JcVhBtN66ipN0v3I3FKGa8F690gGqd5FZNwPvhyd1xMAlEh6YrPFM0mr8Kt6vt8BLnRW onVHq7pF2Q6ul5xUQC8BDl7RULYoQAMeFpgePTgdBKuw6mUZHfSoBf3rlBFd6MSO6KDU y7Ci9oARLrMEoHAxTRIQOgMn0E+Ho7oNsqD1iDAUEMw/PmiGzgKEFkVB6SorZV9GxbrL onNFFdJLvetghoRU8WgZG0d2nHm0x101dAcCQHHJ44Gh9mGGx2TwrWnrgUD5duu+AhzG ZyCA== 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=iU6YODMO3BwYsaTDgfCdrf0cEjSMFB6LJq8zFvVTr2o=; b=Bv3D6gsH43s8GKl2YJkwNb2eOSmCdpXJQ3qDWmfzL18r56FPjR4fUqG5krHQAwcQ8H KS0uI7rpdX2z/DVrX5LVLhbNBtvpvptbuOs7WNpOjKwAFNZHCiGTKXnpUtJRTC59Oxe5 b4KNgWAeV0GOi7Zq9SRhLO1QsCLK0SXPSrj8xMczQKnIuYbKzqJdYSE4fwT+GOCkRSmy lrnROmcLZHV5YO5Rnoh2BWrXwzIFVIPtJptnex3IaQXM32DGD52mgmIVcN5Acpp/hB3f MorhruFbL1jjHpQZhgnGAFyFoJXe5L19YXhMmd90j8URulOpcRgxXebg5P7SbRVfkIBJ 04oA== X-Gm-Message-State: APjAAAXVvLHcbFgXFxHIxhE3V1BncUcC0RkTiNj/4mPuJ8F9uYIy592c Kte2ug14ySbq0HO8OSXRGK/cSHJ50sKmsg1Wp7A= X-Google-Smtp-Source: APXvYqzhsctBwUIEFY/UGSTnm0i/rjJAcmBz85LQX0m5NIYfNCkAqSmL9RMXuZY9Uj4xHXyN7ZmnPs9B5ae1BsH/nz8= X-Received: by 2002:a67:fa89:: with SMTP id f9mr8131360vsq.145.1575607953629; Thu, 05 Dec 2019 20:52:33 -0800 (PST) MIME-Version: 1.0 References: <765a4916-5869-442d-b796-ff6e3c04a4ae@www.fastmail.com> <5737AC81-EEFC-4E03-9241-6E554E485140@akamai.com> In-Reply-To: <5737AC81-EEFC-4E03-9241-6E554E485140@akamai.com> From: Kazuho Oku Date: Fri, 6 Dec 2019 13:52:23 +0900 Message-ID: To: "Salz, Rich" Cc: Martin Thomson , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000061a76f059901d0d5" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing 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, 06 Dec 2019 04:52:36 -0000 --00000000000061a76f059901d0d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for adoption. 2019=E5=B9=B411=E6=9C=8821=E6=97=A5(=E6=9C=A8) 18:49 Salz, Rich : > I am against the working group NOT adopting this. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Kazuho Oku --00000000000061a76f059901d0d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption.

2019=E5=B9=B411=E6=9C=8821=E6=97=A5(=E6=9C= =A8) 18:49 Salz, Rich <rsalz@akamai.= com>:
I am against the working group NOT a= dopting this.


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


--
Kazuho Oku
--00000000000061a76f059901d0d5-- From nobody Fri Dec 6 00:32:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268D612022C for ; Fri, 6 Dec 2019 00:32:33 -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 y2vkMLRDQ_gG for ; Fri, 6 Dec 2019 00:32:31 -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 D773E12000F for ; Fri, 6 Dec 2019 00:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1575621151; x=1607157151; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=26z2g2ZCq/Mx/smNlF4qTC8SWi/V4asiTkV0XDVvzLA=; b=Nis7XNAnK1gO+tEKH5APruB6ujWkZRvNOSxQFO2jHqsn10Y+qgaGue9u ajdC5fqnKmxzKY0/+VwtgXBRXpmHW0dm6iGmPVGNbdKfQCZNYdflK/Vyx gCoIw9XpQ3AzJQ+ThIHr3wZa8rg/yDflw2tl7PNGLBvkUiCBMOCZUTLCc 0x73lMVlZXJyH6hbEtChGUQq1Sfi2z1fBQwCjt15As9JmLzR8qSTdi4E9 z4nnyukscFmEO80CGZYlwt2KPE4hYYhiFlWX16IYdYJwrkMexjXo58+DN sv5tenV69FkLHDLz65UR3647Qa9GCKF8LV/L85GH481cNuakHqZHc6892 w==; X-IronPort-AV: E=Sophos;i="5.69,283,1571655600"; d="scan'208";a="103536651" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Dec 2019 21:32:20 +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 Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 6 Dec 2019 21:32:19 +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, 6 Dec 2019 21:32:19 +1300 From: Peter Gutmann To: Pascal Urien , Antoine Delignat-Lavaud CC: "tls@ietf.org" Thread-Topic: [TLS] DH security issue in TLS Thread-Index: AQHVqidYPanAW3gS7kO2WHQOxdvuBKeoLXkAgAAvOYCAAPNPgIAADsqAgAGLdACAAeCl9w== Date: Fri, 6 Dec 2019 08:32:18 +0000 Message-ID: <1575621138755.48706@cs.auckland.ac.nz> References: <9a3bcf305595e769458687a872ed26c3@delignat-lavaud.fr>, 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] DH security issue in 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, 06 Dec 2019 08:32:33 -0000 Pascal Urien writes:=0A= =0A= >I found in NIST Special Publication 800-56A Revision 3=0A= >=0A= >5.6.2.3.1 FFC Full Public-Key Validation Routine=0A= >2. Verify=A0 that=A0 1 =3D y q mod p.=A0=0A= =0A= This only works for FIPS 186-style DH values where q is present, not PKCS #= 3=0A= values as used in SSH and SSL/TLS.=A0 Only TLS-LTS sends the q value allowi= ng=0A= this check.=0A= =0A= Peter.=0A= = From nobody Fri Dec 6 07:26:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0B512085B for ; Fri, 6 Dec 2019 07:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, 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] 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 sAK6yPI5wTQv for ; Fri, 6 Dec 2019 07:26:30 -0800 (PST) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4AD120861 for ; Fri, 6 Dec 2019 07:26:27 -0800 (PST) Received: by mail-vs1-f52.google.com with SMTP id b79so217172vsd.9 for ; Fri, 06 Dec 2019 07:26:27 -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=Cl/1dbQmq+5Mr8GM/eDUFtbNf6vWuoVUr+tYPdIxBuU=; b=ESyfcq1DrVTlr7cUs8CWftU1sINRLJkIuHNTwS37URa3OS80B/ln6fSQxdBLlLmE4Y mm1RfQPRTrtoeiOeGXveY3WDxWwtMVc/tZPD5OXPoIclITBb6GYaWGVS9F230XNdXSHi pYIPD6qUL+UVVC8COFLIpf+P2YF5fDYoTQKcrEEpdsnggJ54soRePVdLrTSlW5q+IEIW M8qfCb6JcWIP178HVNK0mLgrVSIkzvnbRt923aeE+kmlf+lOf/JEJkMFXX1ynQOVtIUS r6dHI5RGmgPgt+FIw8pCeLQIv9WtsfQHb6CkFp72MdkvoP0ODl29p8eXWCjDIhmGhipH 9j2Q== X-Gm-Message-State: APjAAAW+0tkOOkxTUNq2yVCwTV9VPLYwWthBz1T3hZJLQXR0pGtgyexD BBebx33bNueVclrXjmNIfkBJEVYcFK3HuUWbEK4= X-Google-Smtp-Source: APXvYqwhltLQzcIMLZrVGhYbCpNEqX3e8M2kR7XDnnLTRbPE0oGf8vLFXtiPFBbhAT/CKi9b9ApLCUQUj1g34l8Y/Ew= X-Received: by 2002:a67:ead6:: with SMTP id s22mr10177243vso.69.1575645986363; Fri, 06 Dec 2019 07:26:26 -0800 (PST) MIME-Version: 1.0 References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <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> In-Reply-To: From: Daniel Migault Date: Fri, 6 Dec 2019 10:26:14 -0500 Message-ID: To: David Schinazi Cc: tls Content-Type: multipart/alternative; boundary="0000000000004f212f05990aabdf" 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: Fri, 06 Dec 2019 15:26:33 -0000 --0000000000004f212f05990aabdf Content-Type: text/plain; charset="UTF-8" Hi, Being the last in the queue for a while I realized [1] presents a typo that may prevent my response to be seen. If that were the case, in order to move the document forward, I am re-iterating: I agree with the proposed text from David. This ends the MUST/SHOULD discussion. I also think we agreed the security consideration should provide some text related to an amplification attack - when tickets are sent right after the server Finished. If that helps I believe something around the the following lines could be added: """ In some cases, a server may sent NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. An attacker may take advantage of this behavior to create an amplification attack proportional to the count value toward a target by performing the key exchange over UDP with spoofed packets. The limit on the number of NewSessionTicket messages sent in response to a "ticket_request" MUST be based on the applicability and the amplification factor of such attack. """ The remaining discussion in the list seems related to Viktor proposal, which I think would greatly improve the document. Yours, Daniel [1] https://mailarchive.ietf.org/arch/msg/tls/7Z0p1O2GzN52ztq46KdzpBVX0Hw On Mon, Nov 25, 2019 at 12:04 PM Daniel Migault wrote: > > > On Wed, Nov 20, 2019 at 10:20 PM David Schinazi > wrote: > >> Hi folks, >> >> I've chatted with Daniel and Chris offline, and I think there might >> have been some miscommunication here. Please allow me to >> rephrase what I think is going on, and please let me know if >> this accurately represents your views. >> >> Daniel has a IoT use-case where due to memory constraints, >> a client knows it can only handle a certain number of tickets, >> and therefore Daniel was wondering if it would make sense to >> make the requested number of tickets a required maximum >> (as in a RFC 2119 MUST). However, server operators on this >> thread have indicated that a MUST would get in the way of >> implementing this, due to STEK rotation for example. Daniel >> understands this, and is OK with the current mindset of the >> document (which is only a hint, not a MUST). Additionally, >> Daniel would prefer to see the document move forward. >> >> In order to try to address Daniel's comments, I attempted >> to rephrase the normative section to suggest in more >> stronger terms that servers really shouldn't be sending >> more than the client's request, but keeping it a SHOULD. >> >> Here is the PR with the rephrase: >> https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10 >> >> Here's a copy of the updated paragraph in the PR: >> Clients can use TicketRequestContents.count to indicate the number of >> tickets they would prefer to receive. Servers SHOULD NOT send more >> tickets than TicketRequestContents.count, as clients will most likely >> discard any additional tickets. Servers SHOULD additionally place a >> limit on the number of tickets they are willing to send to save >> resources. Therefore, the number of NewSessionTicket messages sent >> SHOULD be the minimum of the server's self-imposed limit and >> TicketRequestContents.count. >> >> I apology for the late response. This addresses my MUST/SHOULD concern. > Thanks David. > > >> Regarding Viktor's suggestion, I personally believe it would increase the >> complexity of the proposal, and I don't see use-cases compelling enough >> to warrant that complexity. I would rather keep this proposal as simple as >> possible. >> > > I particularly like the proposal from Viktor and - at least as I see it - > its associated simplicity. I believe it would be beneficial for the > document to include it. > > >> >> Thanks, >> David >> >> >> On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni >> wrote: >> >>> On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote: >>> >>> > > Somebody should try to avoid ending up with N new tickets after >>> > > every connection, but in could well be the client. >>> > >>> > Yes, I think that can and ought to be the client. The client is really >>> the >>> > only party that can know how many tickets have been "consumed" by >>> potentially >>> > failed attempts to connect that the server didn't see in time or got >>> dropped. >>> >>> OK, in that case, the proposal, is that on resumption, if the proposed >>> extension is *absent*, then the server should generally send just one >>> rather >>> than any larger default. >>> >>> If the extension is present, it is up to the client to not blindly ask >>> for N >>> tickets each time, and generally ask for just one ticket on resumption, >>> once it >>> has sufficiently many tickets for the desired concurrency level, with >>> each >>> parallel thread obtaining one replacement ticket its next connection. >>> >>> As discussed clients that prefer to reuse tickets, can ask for zero, and >>> get 1 >>> only as-needed. If the server supports reuse then all is well. >>> >>> If the server does not support and refuses reuse, then it will issue a >>> new >>> ticket each time and may only accept it once, but the client may have a >>> single-slot cache. If the client makes only one connection at a time, >>> this >>> also works, but if/when its handshakes with the server overlap (a narrow >>> window >>> of ~1RTT) and two connections attempt to resume with the same ticket, >>> one of >>> them will end up doing a full handshake, but only when the client and >>> server >>> applications have incompatible ticket reuse expectations. Some friction >>> when the client and server are mismatched is not the end of the world. >>> >>> So on the whole I think the proposal still works with just a numeric >>> signal >>> (tweaked with 0xff == none and 0 == reuse), and the onus to "generally >>> send 1" >>> on resumption moved to the client (i.e. clients that don't solicit >>> ticket reuse >>> should request only 1 ticket once they have enough). >>> >>> -- >>> 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 >> > --0000000000004f212f05990aabdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Being the la= st in the queue for a while I realized [1] presents a typo that may prevent= my response to be seen. If that were the case,=C2=A0 in order to move the = document forward, I am re-iterating:=C2=A0

I agree= with the proposed text from David. This ends the MUST/SHOULD discussion.= =C2=A0=C2=A0

I also think we agreed the security c= onsideration should provide some text related to an amplification attack - = when tickets are sent right after the server Finished. If that helps I beli= eve something around the the following lines could be added:
&quo= t;""=C2=A0
In some cases, a server may sent NewSessionTicket immediately upon sen=
ding its Finished rather than waiting for the client Finished. An attacker =
may take advantage of this behavior to create an amplification attack propo=
rtional to the count value toward a target by performing the key exchange o=
ver UDP with spoofed packets. The limit on the number of NewSessionTicket m=
essages sent in response to a "ticket_request"  MUST be based on =
the applicability and the amplification factor of such attack. 
"""

The remaini= ng discussion in the list seems=C2=A0related to Viktor proposal, which I th= ink would greatly improve the document.=C2=A0

Your= s,=C2=A0
Daniel

=C2=A0
=C2=A0
On Mon, Nov 25, 2019 at 12:04 P= M Daniel Migault <daniel.migault@ericsson.com> wrote:

On Wed, Nov 20, 2019 at 10:20 PM David Schinazi <dschinazi.ietf@gmail.com> w= rote:
Hi folks,

I've chatted with Daniel and Chri= s offline, and I think there might
have been some miscommunicatio= n here. Please allow me to
rephrase what I think is going on, and= please let me know if
this accurately represents your views.

Daniel has a IoT use-case where due to memory constra= ints,
a client knows it can only handle a certain number of ticke= ts,
and therefore Daniel was wondering if it would make sense to<= /div>
make the requested number of tickets a required maximum
(as in a RFC 2119 MUST). However, server operators=C2=A0on this
= thread have indicated that a MUST would get in the way of
impleme= nting this, due to STEK rotation for example. Daniel
understands = this, and is OK with the current mindset of the
document (which i= s only a hint, not a MUST). Additionally,
Daniel would prefer to = see the document move=C2=A0forward.

In order to tr= y to address Daniel's comments, I attempted
to rephrase the n= ormative section to suggest in more
stronger terms that servers r= eally shouldn't be sending
more than the client's request= , but keeping it a SHOULD.

Here is the PR with the= rephrase:

Here's a copy= of the updated paragraph in the PR:
=C2=A0 =C2=A0Clients can use= TicketRequestContents.count to indicate the number of
=C2=A0 =C2=A0tick= ets they would prefer to receive.=C2=A0 Servers SHOULD NOT send more
=C2= =A0 =C2=A0tickets than TicketRequestContents.count, as clients will most li= kely
=C2=A0 =C2=A0discard any additional tickets.=C2=A0 Servers SHOULD a= dditionally place a
=C2=A0 =C2=A0limit on the number of tickets they are= willing to send to save
=C2=A0 =C2=A0resources.=C2=A0 Therefore, the nu= mber of NewSessionTicket messages sent
=C2=A0 =C2=A0SHOULD be the minimu= m of the server's self-imposed limit and
=C2=A0 =C2=A0TicketRequestC= ontents.count.

I apology fo= r the late response. This addresses my MUST/SHOULD concern. Thanks David.
=C2=A0=C2=A0 =C2=A0
Regarding Viktor's suggesti= on, I personally believe it would increase the
complexity of the = proposal, and I don't see use-cases compelling enough
to warr= ant that complexity. I would rather keep this proposal as simple as
possible.

I particularly lik= e the proposal from Viktor and - at least as I see it - its associated simp= licity. I believe it would be beneficial for the document to include it.=C2= =A0
=C2=A0=C2=A0

Thanks,
David


On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On = Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote:

> > Somebody should try to avoid ending up with N new tickets after > > every connection, but in could well be the client.
>
> Yes, I think that can and ought to be the client. The client is really= the
> only party that can know how many tickets have been "consumed&quo= t; by potentially
> failed attempts to connect that the server didn't see in time or g= ot dropped.

OK, in that case, the proposal, is that on resumption, if the proposed
extension is *absent*, then the server should generally send just one rathe= r
than any larger default.

If the extension is present, it is up to the client to not blindly ask for = N
tickets each time, and generally ask for just one ticket on resumption, onc= e it
has sufficiently many tickets for the desired concurrency level, with each<= br> parallel thread obtaining one replacement ticket its next connection.

As discussed clients that prefer to reuse tickets, can ask for zero, and ge= t 1
only as-needed.=C2=A0 If the server supports reuse then all is well.

If the server does not support and refuses reuse, then it will issue a new<= br> ticket each time and may only accept it once, but the client may have a
single-slot cache.=C2=A0 If the client makes only one connection at a time,= this
also works, but if/when its handshakes with the server overlap (a narrow wi= ndow
of ~1RTT) and two connections attempt to resume with the same ticket, one o= f
them will end up doing a full handshake, but only when the client and serve= r
applications have incompatible ticket reuse expectations.=C2=A0 Some fricti= on
when the client and server are mismatched is not the end of the world.

So on the whole I think the proposal still works with just a numeric signal=
(tweaked with 0xff =3D=3D none and 0 =3D=3D reuse), and the onus to "g= enerally send 1"
on resumption moved to the client (i.e. clients that don't solicit tick= et reuse
should request only 1 ticket once they have enough).

--
=C2=A0 =C2=A0 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
--0000000000004f212f05990aabdf-- From nobody Fri Dec 6 08:50:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB457120998 for ; Fri, 6 Dec 2019 08:50:23 -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=bz+qEorh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QfdsqMEn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I97nZ8i57qqO for ; Fri, 6 Dec 2019 08:50:19 -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 0A4CE1209A9 for ; Fri, 6 Dec 2019 08:50:19 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3F1F822412 for ; Fri, 6 Dec 2019 11:50:18 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 06 Dec 2019 11:50:18 -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=lfRdmPtKkl5oAilVL4B6vm/SkECTIcd 24HaoYiiAKf0=; b=bz+qEorh5MkL2ogmLuL6EsCVplcOxfJigQs5LxO2SfzYjQn F+IVWO7UPbZuV5w8OO2lme+AowVe7n4O5cOkHSp3U61Izo8MvraVN2dtMh1rumi+ a7cWQsvANVQ+AuDycsuf7UeLhaxqujGsiPJx1vQmyqfCCO0phnueEWqGATFPu6Zd smAUwYrgGDlfoKyAsMXTlBAj200Cwr17HEP50hnILtdPW6mwTmFaebw9it2GFR76 4V5lpr66kiBhbTVwdKIEtf+t/jlb5CcC1gMUSzHPbyODDSWocok0BCpkueoYSKzV MSncwEWbnjMzUOcSDWiANXn/P0GD8fhjHXJGKtw== 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=fm1; bh=lfRdmP tKkl5oAilVL4B6vm/SkECTIcd24HaoYiiAKf0=; b=QfdsqMEnw8NWNc3CGa6IUx lELR/LahewVmnulWBQ1h7jrgkYnXHldXdKU+tnxN15UbFcxltutMouVTm7TtM1Os qXyynQAi/7XxetQjBS6ZjNlpfi9mssLsD5GDfymf504bcbSvRTOjWXMMsgDgN8N7 blZ2Z41tDCnsamFHbTZKwfJI+4/seaK/vu/rdeZhU8laS1daPML1NNTd4Yc8azu6 s/ZCZo0ZoUx9RRw+93fKIfb5HlrCJFtgW+VJmkWNbIGpOURFw1tbgtVJYKPSnZit h2wk3jqPq0+7w0oxpI4SrEjZjv7aGeA85AP2BOG/r1EpWedeXOMMQgOt2/1SnF5Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudekfedgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhephhhtthhpshdqfegrpg gpghhithhhuhgsrdgtohhmpghtlhhsfihgpghtlhhsqddvuggvgihpohhrthgvugdqvdgu rghuthhhvghnthhitggrthhorhgpphhulhhlpgehhegpfhhilhgvshdpghhithhhuhgsrd gtohhmpdhprhhoohhfphhoihhnthdrtghomhenucfrrghrrghmpehmrghilhhfrhhomhep tggrfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0B76E3C00A1; Fri, 6 Dec 2019 11:50:18 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-612-g13027cc-fmstable-20191203v1 Mime-Version: 1.0 Message-Id: <14b8d2ae-6415-47f8-b00b-28d05e238151@www.fastmail.com> In-Reply-To: <13DF0FBB-25E8-47B5-91C8-19F636C1EC59@akamai.com> References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20191118225035.GS20609@akamai.com> <430940ff-60f0-4ddd-9d71-9fe8b8ca9cae@www.fastmail.com> <20191121024019.GW20609@akamai.com> <892200AE-3D0A-4AF1-AD40-E3C46BE57F88@akamai.com> <13DF0FBB-25E8-47B5-91C8-19F636C1EC59@akamai.com> Date: Fri, 06 Dec 2019 08:49:57 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Secdir_last_call_review_of_draft-ietf-tls-export?= =?utf-8?q?ed-authenticator-09?= 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, 06 Dec 2019 16:50:24 -0000 On Wed, Nov 20, 2019, at 11:58 PM, Salz, Rich wrote: > > *>*In any case, we can address that when/if we get to it. Here's the > new proposed text: > > https://github.com/tlswg/tls-exported-authenticator/pull/55/files > > > > Agreed. The PR looks good to me. Based on the Singapore meeting and this thread, I went ahead and merged the PR. (If you do have comments yet didn't have time to share them, please do so!) Nick, can you please spin a new version? Thanks, Chris From nobody Fri Dec 6 09:10:03 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2EA12007C for ; Fri, 6 Dec 2019 09:10:02 -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 8x4s74ybi1og for ; Fri, 6 Dec 2019 09:10:00 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298AC1200CD for ; Fri, 6 Dec 2019 09:10:00 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id 66so6395530otd.9 for ; Fri, 06 Dec 2019 09:10: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 :cc; bh=pJsMgwpTFHmLcN7pkXvpm/GPNYlpJAZy43SVpEn79Ys=; b=NtIFvW7s3fJySGkfbxqrXBV0LJFT/afmDNawqBdWiZY1s5ODB1fB/PpF1cr6A+cBt1 8eGm7C3ZgKxjZLdROP2Ul+36n1bEFMvOAm2GsKkic8itbVgIVUYuV1ngEbOuqTsVcIB3 3FbawfFQoPfvC6KIafvLVaXC5oMLEVoT/Rvm1GmzBO3pnQKbQB7C3L4iKdixo8myW7sF Jhe39EecrtuatUihs9yKH4Pb3SAcedcGO+2Dm0mQPkGnqVU9lD1D0kWeRCNLpHsPW9hO g2SFpCkjWMmaJdjjH2EamUyccvl/jROt93rIlqqIKaLo4ORlniZHVkxzpFxy0UcxiccJ e8lg== 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=pJsMgwpTFHmLcN7pkXvpm/GPNYlpJAZy43SVpEn79Ys=; b=sjWWQZYd/o8J0qkwNARP9E1ClbZv5C0x4ZOph2vQctnFdHYJ30nn4hg3pvCcZD54vj yjhbP82OAbYYi8z8VZYlISE/baVOp7lS5REQEV849y+oLXqeDoXq9tzWQi1OVEQ4UO6L cLRBs9BlyA1YoVfHDG6Z3y9VzBdRzRp0F928zICfF8RYgtTBHLuNEwxhJZNTeWeKdiyT SmfzpEVCzUxe+7S1rqb1fYNV41OHyiZWk8nWzNsMCDH+7wMy9vR3ZuHwOP63mD+mnKZJ A/XLj5/G+TzKuAnW4bhaoBQO0Tq4bCZM9IXw7/yNO3DiAN20UuDBy2FVq2LiqDCH9kSh Yjpg== X-Gm-Message-State: APjAAAUkSPNVNyWAudsajAXU+a1CL6b2W7wrCStutd5AMLwD+sQlOSEW fqAPjFtQOMJ4a/gQTbsKdk2bpiqrmQkcbXnZAn5kGQ== X-Google-Smtp-Source: APXvYqwL4OoUlytD0iktme4Ykr3ZMzsvsBsxwoptFBt616Wz6MRlTQ8JY9aSZL8BON2U2RUYsoA25msx7eINkIByZ+A= X-Received: by 2002:a9d:630d:: with SMTP id q13mr11082863otk.31.1575652199472; Fri, 06 Dec 2019 09:09:59 -0800 (PST) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> In-Reply-To: From: Darin Pettis Date: Fri, 6 Dec 2019 11:09:48 -0600 Message-ID: To: Adam Langley Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a3a08505990c1d4e" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 06 Dec 2019 17:10:02 -0000 --000000000000a3a08505990c1d4e Content-Type: text/plain; charset="UTF-8" On Thu, Nov 14, 2019 at 4:43 PM Adam Langley wrote: People on this list who manage large corporate networks may wish to pay attention to this: while you may not have updated servers to TLS 1.3 yet, eventually it'll happen and I suspect some will find a significant amount of things like TPMs, in which you currently have client-certificate keys, which only sign with PKCS#1 v1.5. Without this draft adopted and implemented ahead of time, it's going to be painful. Adam - Wanted to thank you for the call-out to people on the list managing large corporate networks. Looking into the mutual authentication supported protocols issue that you and David raised. Will evaluate potential future impact. Cheers, Darin On Thu, Nov 14, 2019 at 4:43 PM Adam Langley wrote: > On Mon, Nov 11, 2019 at 11:33 AM Christopher Wood > wrote: > >> The adoption call is now (belatedly) finished. At this time, there's not >> enough interest to take this on as a WG item. We encourage further >> discussion on the list, perhaps based on subsequent draft updates, and will >> revisit adoption in the future if interest grows. >> > > People on this list who manage large corporate networks may wish to pay > attention to this: while you may not have updated servers to TLS 1.3 yet, > eventually it'll happen and I suspect some will find a significant amount > of things like TPMs, in which you currently have client-certificate keys, > which only sign with PKCS#1 v1.5. Without this draft adopted and > implemented ahead of time, it's going to be painful. > > > Cheers > > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a3a08505990c1d4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 14, 2019 at 4:43 PM Adam Langley <agl@imperialviolet.org> wrote: People on this l= ist who manage large corporate networks may wish to pay attention to this: = while you may not have updated servers to TLS 1.3 yet, eventually it'll= happen and I suspect some will find a significant amount of things like TP= Ms, in which you currently have client-certificate keys, which only sign wi= th PKCS#1 v1.5. Without this draft adopted and implemented ahead of time, i= t's going to be painful.

Adam - Wanted to thank you for the call-out to people on the list= managing large corporate networks.=C2=A0 Looking into the mutual authentic= ation supported protocols issue that you and David raised.=C2=A0 Will evalu= ate potential future impact. =C2=A0

Cheers,
Darin

On Thu, Nov 14, 2019= at 4:43 PM Adam Langley <agl@= imperialviolet.org> wrote:
<= div dir=3D"ltr">
On Mon, Nov 11, 2019 at 11:33 AM Christoph= er Wood <caw@he= apingbits.net> wrote:
The adoption call is now (belatedly= ) finished. At this time, there's not enough interest to take this on a= s a WG item. We encourage further discussion on the list, perhaps based on = subsequent draft updates, and will revisit adoption in the future if intere= st grows.

People on this list who manag= e large corporate networks may wish to pay attention to this: while you may= not have updated servers to TLS 1.3 yet, eventually it'll happen and I= suspect some will find a significant amount of things like TPMs, in which = you currently have client-certificate keys, which only sign with PKCS#1 v1.= 5. Without this draft adopted and implemented ahead of time, it's going= to be painful.


Cheers
AGL
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a3a08505990c1d4e-- From nobody Sat Dec 7 02:20:26 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEE9120164 for ; Sat, 7 Dec 2019 02:20:24 -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 ERqpd5DiyWXu for ; Sat, 7 Dec 2019 02:20:22 -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 1DFE1120142 for ; Sat, 7 Dec 2019 02:20:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 92D2A16095 for ; Sat, 7 Dec 2019 12:20:19 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id cYn1zoncpgCR for ; Sat, 7 Dec 2019 12:20:19 +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 E67F672 for ; Sat, 7 Dec 2019 12:20:17 +0200 (EET) Date: Sat, 7 Dec 2019 12:20:17 +0200 From: Ilari Liusvaara To: "tls@ietf.org" Message-ID: <20191207102017.GA1754124@LK-Perkele-VII> References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 07 Dec 2019 10:20:24 -0000 On Fri, Dec 06, 2019 at 11:09:48AM -0600, Darin Pettis wrote: > On Thu, Nov 14, 2019 at 4:43 PM Adam Langley wrote: > > People on this list who manage large corporate networks may wish to pay > > attention to this: while you may not have updated servers to TLS 1.3 yet, > > eventually it'll happen and I suspect some will find a significant amount > > of things like TPMs, in which you currently have client-certificate keys, > > which only sign with PKCS#1 v1.5. Without this draft adopted and > > implemented ahead of time, it's going to be painful. > > Adam - Wanted to thank you for the call-out to people on the list managing > large corporate networks. Looking into the mutual authentication supported > protocols issue that you and David raised. Will evaluate potential future > impact. There are also library issues where the physical device does allow RSA-PSS (e.g., because they can perform raw RSA root on arbitrary values[1]), but libraries/drivers do not support it. One test I just tried: - Smartcard capable of raw RSA. - OpenSC PKCS#11 drivers. - Firefox ESR 68 - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is enabled[2]). Result: Failed. Client hits internal error code SEC_ERROR_LIBRARY_FAILURE [3]. [1] Yeah, not great for security, but some devices are like that. [2] That option was a hack to make things work with Firefox ESR 52, which did send RSA PKCS#1v1.5 client signature (scheme 0x0401) in comparable situation. [3] My guess would be that browser asks drivers for RSA-PSS, which they do not support, causing the error. -Ilari From nobody Sat Dec 7 16:45:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B561200EF for ; Sat, 7 Dec 2019 16:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 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, PDS_BTC_ID=0.499, 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=VHOrtoam; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xgCJoMnh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3fq85DCwNKH for ; Sat, 7 Dec 2019 16:45:14 -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 9C6A612004A for ; Sat, 7 Dec 2019 16:45:14 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id EAA1F343 for ; Sat, 7 Dec 2019 19:45:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 07 Dec 2019 19:45:14 -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=76itsLHex5VldPeiMMcMCV2elcCWGgKe4N6Fl8iGF8U=; b=VHOrtoam 80PZbsyZzbjRmPJc8HKLGQhr2JQgJw5sqh4Swv7DrvPylpYYOp8iBcyYF88OG05K u4DGmA+WC39OnjlkmRtYKxRNf6OS6NWviToi5GBEuGPjgLKZRvURJ+uOQHas8CwS WWKn+eoLOk4KoFAVMOHqFLZqP7mcpQxPew6femB2WmuQZKDAQGBAfx+/HmtjkLyk tBblbMW3BQaRh5cSohbXLWnJ0CzX8kfNQzfsAMiC9EJhwZeLbXqP5JJKjcY4j8N9 t4MTFzAmFOyxProTYCwUAAYAZ8BlAKLv7lyZOVJgvHVT5MTtxRpWzEY6pWX3FysE Lu93ehLOZKWSCg== 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=76itsLHex5VldPeiMMcMCV2elcCWG gKe4N6Fl8iGF8U=; b=xgCJoMnhpdctv0gtJP+iGNCHu8qTi/rmIUhQq9LgJGUQp dxkAv9FbLZLKZd9v74SRQPrROEMaHIlRdl5jNrhi+fCRELV2wiKGrlwfA0V7W3sp AcouOXEhJpc0EFExqkbbb8n9LStFN+kW/Broxu16izzKNCY5jXbXgr40/K3BRqA9 /2j5uFe5dwC8ZSyD6uPm1JZdXc+qxoQ5ZceZTi5Lq8tl4FfOby06jSMQ5o0rTlyO yHr8iKU3tsIvp1B95TzZDg4/rMqsVEgCG6LfwS0ixccVIudX3fAPTXuB47swc/xx li+HnfFb67nacAjKLuVCVMWGaIxFdHcDplrm45bfQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudekiedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusgcupfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeeghedrjeelrdduudefrdduieehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 2FAC0306035B for ; Sat, 7 Dec 2019 19:45:12 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 4AC719D38C for ; Sun, 8 Dec 2019 00:45:11 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============8649684397160962420==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191208004511.4AC719D38C@cloud.mnot.net> Date: Sun, 8 Dec 2019 00:45:11 +0000 (UTC) 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, 08 Dec 2019 00:45:18 -0000 --===============8649684397160962420== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/tls-exported-authenticator (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #54 Secdir review final issue (1 by chris-wood) https://github.com/tlswg/tls-exported-authenticator/issues/54=20 1 issues closed: - Secdir review final issue https://github.com/tlswg/tls-exported-authent= icator/issues/54=20 Pull requests ------------- * tlswg/certificate-compression (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Link to Section 4.4.2 of RFC8446 when talking about Certificate message= s (by ghedo) https://github.com/tlswg/certificate-compression/pull/30=20 1 pull requests merged: - Link to Section 4.4.2 of RFC8446 when talking about Certificate messages https://github.com/tlswg/certificate-compression/pull/30=20 * tlswg/tls-exported-authenticator (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Nick/secdir2 https://github.com/tlswg/tls-exported-authenticator/pull/55=20 Repositories tracked by this digest: ----------------------------------- * 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 --===============8649684397160962420== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday December 08, 2019

Issues

tlswg/tls-exported-authenticator (+0/-1/=F0=9F=92=AC1)

1 issues received 1 new comments:

1 issues closed:

Pull requests

tlswg/certificate-compression (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

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

1 pull requests merged:

Repositories tracked by this digest:

--===============8649684397160962420==-- From nobody Mon Dec 9 01:13:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B85612004D for ; Mon, 9 Dec 2019 01:13:53 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bORoQgVw2uid for ; Mon, 9 Dec 2019 01:13:51 -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 CA92812004C for ; Mon, 9 Dec 2019 01:13:50 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id r14so10077084lfm.5 for ; Mon, 09 Dec 2019 01:13:50 -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=5hy2x8RiB0o7SG7DsRtAm56omGvRAzKw1uXMVHRAJU8=; b=ujcx81nAyeREwPg7RxCL2PhQ+jcapYvk1WPLkQaL9xS4kfYkSo1zssyNjEzfTMgI89 3XQS93NXTeikKytH4VehleAXPtAH5YYbzhUJq5ilhFLf029/5tqwYDAXQ8XGfQP2ZRTo +WkFDFmLOAPOU6irQGvbGfoUl9fvj8k7fC8Jmp3kOgUnhfS+rYot5Rg1NxbXvp98jDiY QXBH9Dz7bVyvhk1ujMTzWyHyYITKAFr2S2o2HXWfuNaQhIOwGxchJanEYQVYUTh1ENED bGE+UigNwLTgr3ix1+2QMS7Vz2HOf8hm6PYBUt53050KPR5PbG99nQa9qMgLAndPtFv0 TrMA== 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=5hy2x8RiB0o7SG7DsRtAm56omGvRAzKw1uXMVHRAJU8=; b=Ep2cmdoPJvycxc/cRT6kMbKyREmT531AJZXcgV+YmfXmz6MMng9RIbTifVuFRcMqqq akQ/5Y+51UmXztVm05Fq9Sut0/99O1vN4F0JoDOMRufGY33+w0M03zFin5V7Zb0klUx3 DECW0RxsmmeVOjWP8wa/H/pKNNHuJMkn1ee1JFL6vcjGaDCRKB3Lg47BX7Q4ARjnStNf 6Il5Lxs9gx6nv1oPWgfiFihZYmB40F7lDOkZ3UCo/6StGU0tz/UaJzw4S+EwbOOI8dfs CT6INfI5D+iCOUAfqROu671lM5LdG2ub7/DWTW+2mX4109TmwCsaeZBFmP9j3iRcOs2C 4q3w== X-Gm-Message-State: APjAAAUSq8/Ul4CiB1XaJ7DT/IzY6d2kSCO3HiaWiV5txctWljVgg1MG DvgD9rlQiZOHOfpiHAE6+C1xKA+bPPr92D1O5a80Kw== X-Google-Smtp-Source: APXvYqwu8jqgC3QOIoXl07K5nCZJf7w1bFyLrjLsQuvuhZQ0+noHazt9+UeNVjuhK6V4vMoXl61O2CDRrvet0PuTKis= X-Received: by 2002:ac2:5549:: with SMTP id l9mr14613172lfk.53.1575882828621; Mon, 09 Dec 2019 01:13:48 -0800 (PST) MIME-Version: 1.0 References: <157498929764.5575.7815291384505057169@ietfa.amsl.com> <20191205164212.GB12839@sokka.flat11.house> <1740c80a-498f-e706-5622-82d8115cf773@huitema.net> In-Reply-To: <1740c80a-498f-e706-5622-82d8115cf773@huitema.net> From: Victor Vasiliev Date: Mon, 9 Dec 2019 04:13:37 -0500 Message-ID: To: Christian Huitema Cc: Alessandro Ghedini , last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, "tls@ietf.org" , secdir@ietf.org Content-Type: multipart/alternative; boundary="00000000000035a0aa059941d0c2" Archived-At: Subject: Re: [TLS] [Last-Call] Secdir last call review of draft-ietf-tls-certificate-compression-07 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, 09 Dec 2019 09:13:53 -0000 --00000000000035a0aa059941d0c2 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 4:42 PM Christian Huitema wrote: > >> Second, my actual concern. Compression may leak information, because > different > >> certificate chains will compress differently. The authors mention that > an > >> attacker will not be able to inject data in the certificate chain, and > thus > >> that attacks of the CRIME variety are unlikely. That's correct, but > that's not > >> the entire story. > >> > >> TLS 1.3 will encrypt the compressed certificate message but the length > of that > >> message could be deduced from the length of the server's encrypted > message. > >> Attackers might be able to derive from that length the identity of the > server, > >> even if the SNI is encrypted. > >> > >> One could say that in the absence of compression the length of the > certificate > >> chain is also available. Indeed, the problem is flagged in > >> draft-ietf-tls-esni-05, which states in section 5.3 that "it (the > server) > >> SHOULD pad the Certificate message, via padding at the record layer, > such that > >> its length equals the size of the largest possible Certificate (message) > >> covered by the same ESNI key." > >> > >> Certificate compression introduces a level of complexity here. If only > some > >> servers in the anonymity set support compression, attackers can work > with a > >> smaller anonymity subset. If all attackers support compression, the > padding > >> should try to match the largest Compressed Certificate. > >> > >> It might be good to discuss this issue in the security consideration > section. > > I agree tha this is worth discussing, but it seems like it belongs in > the ESNI > > draft itself, so implementers of ESNI will be more likely to take > compression > > into consideration. That is, we can expand the section you quoted to also > > explicitly mention certificate compression. What do you think? I can > look into > > proposing a PR for this. > > I agree with you that the bulk of the work belongs in the ESNI draft. > However, it would be nice to have a short reminder of the issue in the > security section of the compression draft. Something like: > > Although the Certificate extension is encrypted in TLS 1.3, third > parties can deduce some information about the certificate from the > length of the handshake messages. Compression does not prevent this > issue, as different certificate chains will compress to different > lengths. When privacy is desired, implementers need to consider > appropriate padding strategies. Discussion of these padding strategies > is out of scope for this document. > > -- Christian Huitema > Thanks! Filed a PR addressing this issue: https://github.com/tlswg/certificate-compression/pull/31 Cheers, Victor. --00000000000035a0aa059941d0c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 4:42 PM Christian = Huitema <huitema@huitema.net&= gt; wrote:
>> Second, my actual concern. Compression may leak information, becau= se different
>> certificate chains will compress differently. The authors mention = that an
>> attacker will not be able to inject data in the certificate chain,= and thus
>> that attacks of the CRIME variety are unlikely. That's correct= , but that's not
>> the entire story.
>>
>> TLS 1.3 will encrypt the compressed certificate message but the le= ngth of that
>> message could be deduced from the length of the server's encry= pted message.
>> Attackers might be able to derive from that length the identity of= the server,
>> even if the SNI is encrypted.
>>
>> One could say that in the absence of compression the length of the= certificate
>> chain is also available. Indeed, the problem is flagged in
>> draft-ietf-tls-esni-05, which states in section 5.3 that "it = (the server)
>> SHOULD pad the Certificate message, via padding at the record laye= r, such that
>> its length equals the size of the largest possible Certificate (me= ssage)
>> covered by the same ESNI key."
>>
>> Certificate compression introduces a level of complexity here. If = only some
>> servers in the anonymity set support compression, attackers can wo= rk with a
>> smaller anonymity subset. If all attackers support compression, th= e padding
>> should try to match the largest Compressed Certificate.
>>
>> It might be good to discuss this issue in the security considerati= on section.
> I agree tha this is worth discussing, but it seems like it belongs in = the ESNI
> draft itself, so implementers of ESNI will be more likely to take comp= ression
> into consideration. That is, we can expand the section you quoted to a= lso
> explicitly mention certificate compression. What do you think? I can l= ook into
> proposing a PR for this.

I agree with you that the bulk of the work belongs in the ESNI draft.
However, it would be nice to have a short reminder of the issue in the
security section of the compression draft. Something like:

Although the Certificate extension is encrypted in TLS 1.3, third
parties can deduce some information about the certificate from the
length of the handshake messages. Compression does not prevent this
issue, as different certificate chains will compress to different
lengths. When privacy is desired, implementers need to consider
appropriate padding strategies. Discussion of these padding strategies
is out of scope for this document.

-- Christian Huitema

Thanks!
=
Filed a PR addressing this issue:=C2=A0https://github.com/tlswg/ce= rtificate-compression/pull/31

Cheers,
=C2=A0 Victor.=C2=A0
--00000000000035a0aa059941d0c2-- From nobody Mon Dec 9 14:10:21 2019 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 753921200F1; Mon, 9 Dec 2019 14:10:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee via Datatracker To: Cc: last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Peter Yee Message-ID: <157592941042.2180.9966958421606523994@ietfa.amsl.com> Date: Mon, 09 Dec 2019 14:10:10 -0800 Archived-At: Subject: [TLS] Genart last call review of draft-ietf-tls-certificate-compression-07 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: Mon, 09 Dec 2019 22:10:10 -0000 Reviewer: Peter Yee Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-certificate-compression-07 Reviewer: Peter Yee Review Date: 2019-12-09 IETF LC End Date: 2019-12-09 IESG Telechat date: Not scheduled for a telechat Summary: This draft specifies a means to negotiate and carry a compressed certificate chain for use in TLS 1.3. The document is clear and well-written. It's ready for publication as a Standards Track RFC, although the Secdir review raises interesting points that ought to be considered before moving forward. >From a general perspective, this draft appears to be useful extension to TLS 1.3. [Ready] Major issues: None Minor issues: None Nits/editorial comments: None From nobody Tue Dec 10 01:24:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743FE120861 for ; Tue, 10 Dec 2019 01:24:41 -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_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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiDp8c97SbIm for ; Tue, 10 Dec 2019 01:24:36 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0621.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::621]) (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 C0FEF120860 for ; Tue, 10 Dec 2019 01:24:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XkrLkeZ3PLSFjALvy0Vw+AkxmsXa7z7SrFreaSdpQ76PnsbMTuVrRKzL5FjjfRDcvr5Kr5qEHvxoJSHTfPPn+eQX5KLYNRc4mbD/JNgcgZBpGxgqXJ+TyvSeYCOuAYpXXaQZ3dMD4cdn/Ac1tpqwJafNF3jNKwGUBceNcpVd6NoFXwZblYql6aODNrYXmuzKkpPdIRXKEhbD05tXTry5YgnI8mi+jLUlU/BUU64iYYcV0VBx69t/B/10iqGw1Z8GPYlO9/SyPK8eGVi+Sph7foXjJxnRlmh2S/T4kJ4yRVv4EJ3Fj6VS1PvTAa3DqnUjP/bhIrMpMLnLCXJC4xVZow== 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=Vi4sPVnsp4syWGALHBYdAUwfqcX5MHcJHx3nKKLIGBY=; b=KLXOVdfkePghZXhO5fJqW7mVNx6GP5gdt3k6GJn9iNMQkmdDcXpI938+pu4w1JlPbPQf+m6lxqvm3Vwp7GVqZyuRnDIZ8KEMjgAiBk6O7rY1ttlsU67N+gtgrDTc+1KGS+zNADLiH2WjMX07sifcluYA3DXfh8zoW2n/KYTrCSOIFstlv/6cfOp7Vh6/GBuSO4qWk4h/VwqAHQq6qVMg9Ar9fFD5fAEq1YloJZg1XetoJtxJjByDTeI7H8eCFEU9JCTvLOGXKP/wIb7DQHQYrHLBmgZtCg3P3CEIoFkXl92m5RR2OqALb9KsNxx1xHWGYvMVvEi9fNRCAvcgyBg7iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vi4sPVnsp4syWGALHBYdAUwfqcX5MHcJHx3nKKLIGBY=; b=angyYvrRX61Ns9D4jg/9tbCXbsBMXg+qy5luIWhUmNO37cjzjKM5LKqJQYw1Yp2e5TmG8JlvYxoxD1lFBUPzfDtbLE2GYBya7r1wmjR4ldHG9Vdy6JxiqYjjKM/X9QS79qIXyD43sBLkp8d5A8MumI3pZXlgFjI3yonlFdkZPoA= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3420.eurprd07.prod.outlook.com (10.170.247.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.6; Tue, 10 Dec 2019 09:24:32 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::1986:9afa:b0a0:5636]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::1986:9afa:b0a0:5636%7]) with mapi id 15.20.2538.012; Tue, 10 Dec 2019 09:24:32 +0000 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: Comments on draft-yang-tls-tls13-sm-suites-02 Thread-Index: AQHVrzuhknAROWYegEaexuHSBN4F7g== Date: Tue, 10 Dec 2019 09:24:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 25a39904-72b3-45f6-678b-08d77d52c424 x-ms-traffictypediagnostic: HE1PR07MB3420: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(366004)(39860400002)(396003)(136003)(189003)(199004)(81156014)(71190400001)(5660300002)(76116006)(64756008)(66556008)(8936002)(66946007)(66446008)(66476007)(8676002)(6916009)(316002)(305945005)(81166006)(5640700003)(36756003)(2906002)(6486002)(91956017)(2616005)(6512007)(966005)(71200400001)(478600001)(6506007)(33656002)(86362001)(44832011)(186003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3420; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JWi7mthIgB28UWV/esxGH4qNB2Nc8gKLK4nVKRxGXKSbBcz8AY7JMLopJlIny402nwwW9cGF1dXcVDZKeDzNoNHkKyIv4E3/XSU9ijbuKEQx0dpmEN5cK54dctBEeCusZfcClE9tAHP7td4+bc2Ik0rSncDrFFFU68FFGMS70qbFyMP48ZjkyhaXjklkEJVPePn9VYf8GGGfo9caxOTeZY8GspC15Xl02kSprpKOC4TMiF7EUp7ZsIiZz7DgoYknBwVM3lmeiwW5BzvxMOA63bTB4zVcdb7DC2mvSSuS4Bl1Dt2wD7Y5fmWVI30w7VAp1oqDw0c8KLEMFjl4fVRKDP3Qye7rzRcf+OkfUMuLPXsQBXQt+aIKSFPZeivgIqvyxPNSUbTKKRVV2uvGN8bXN9jEhEUc4dpd0NOX2RpRULgkdjrMRKZGdMI0Azc/qLO+/vCeDfUVAcc3IXkLv4ryixbz29E8KwB08JnBheqsbWs= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3553EB5EB72AB04E9C033E07E827C085@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 25a39904-72b3-45f6-678b-08d77d52c424 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 09:24:32.6005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6fTh5RXSz55ZQm79mZpk+3idFFf8PrnuIRxm2arvPCtHWEMpZh3e4XXi7Vlz7j3h5HZS2S0gOJO9ot8AXnvdNzbPM9J6VKiJuMWesKwORDc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3420 Archived-At: Subject: [TLS] Comments on draft-yang-tls-tls13-sm-suites-02 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, 10 Dec 2019 09:24:41 -0000 SGksDQoNCg0KLS0gVGhlIGRvY3VtZW50IHNheXMgaW4gdGhlIGFic3RyYWN0IGFuZCBpbnRyb2R1 Y3Rpb24gdGhhdDog4oCcVGhlIFNNIGNpcGhlciBzdWl0ZXMgYXJlIGJlY29taW5nIG1hbmRhdG9y eSBpbiBDaGluYeKAnS4NCg0KVG8gbXkgdW5kZXJzdGF0aW5nIHRoZSBuZXcgQ2hpbmVzZSBjcnlw dG9ncmFwaHkvZW5jcnlwdGlvbiBsYXcgZWZmZWN0aXZlIG9uIEphbnVhcnkgMSwgMjAyMCBnb2Vz IGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24gYnkgcmVtb3ZpbmcgcmVndWxhdG9yeSBhbmQgbGVn YWwgcHJvYmxlbXMgd2l0aCB1c2luZyBjb21tZXJjaWFsIGVuY3J5cHRpb24gYW5kIGV4cGxpY2l0 bHkgYWxsb3dpbmcgZm9yZWlnbiBjb21tZXJjaWFsIGVuY3J5cHRpb24gcHJvZHVjdHMgdG8gYmUg dXNlZC4gVGhpcyBpcyBhbGwgdmVyeSBwb3NpdGl2ZS4gU2VlIGEgY29sbGVjdGlvbiBvZiByZWZl cmVuY2VzIGJlbG93Lg0KDQpJIHdvdWxkIHRoZXJlZm9yZSBzdWdnZXN0IGRlbGV0aW5nIHRoZSBz ZW50ZW5jZSDigJxUaGUgU00gY2lwaGVyIHN1aXRlcyBhcmUgYmVjb21pbmcgbWFuZGF0b3J5IGlu IENoaW5h4oCdLCBhbHRlcm5hdGl2ZWx5IHNwZWNpZnkgd2hlcmUgc3VjaCB1c2UgaXMgbWFuZGF0 b3J5IChwcmVmZXJhYmx5IHdpdGggYSByZWZlcmVuY2UpLg0KDQpodHRwOi8vd3d3Lm5wYy5nb3Yu Y24vbnBjL2MzMDgzNC8yMDE5MTAvNmY3YmU3ZGQ1YWU1NDU5YThkZThiYWYzNjI5NmJjNzQuc2h0 bWwNCiANCmh0dHBzOi8vdHJhbnNsYXRlLmdvb2dsZS5jb20vdHJhbnNsYXRlP2hsPWVuJnNsPXpo LUNOJnRsPWVuJnU9aHR0cCUzQSUyRiUyRnd3dy5ucGMuZ292LmNuJTJGbnBjJTJGYzMwODM0JTJG MjAxOTEwJTJGNmY3YmU3ZGQ1YWU1NDU5YThkZThiYWYzNjI5NmJjNzQuc2h0bWwNCiANCmh0dHBz Oi8vd3d3LmxleGJsb2cuY29tLzIwMTkvMTAvMzEvY2hpbmEtZW5hY3RzLWVuY3J5cHRpb24tbGF3 Lw0KDQpodHRwczovL3d3dy51c2NjLmdvdi9zaXRlcy9kZWZhdWx0L2ZpbGVzLzIwMTktMTEvTm92 ZW1iZXIlMjAyMDE5JTIwVHJhZGUlMjBCdWxsZXRpbi5wZGYgDQoNCmh0dHBzOi8vd3d3LnNjbXAu Y29tL25ld3MvY2hpbmEvcG9saXRpY3MvYXJ0aWNsZS8zMDM0NzY0L2NoaW5hLWhvcGVzLWNyeXB0 b2dyYXBoeS1sYXctd2lsbC1wcm92aWRlLXNlY3VyaXR5LWFuZA0KIA0KaHR0cHM6Ly93d3cuY292 LmNvbS8tL21lZGlhL2ZpbGVzL2NvcnBvcmF0ZS9wdWJsaWNhdGlvbnMvMjAxOS8xMC9jaGluYV9l bmFjdHNfZW5jcnlwdGlvbl9sYXcucGRmDQogDQpodHRwOi8vd3d3Lnhpbmh1YW5ldC5jb20vZW5n bGlzaC8yMDE5LTEwLzI2L2NfMTM4NTA1NjU1Lmh0bQ0KDQrCoA0KLS0gIlNNMiBpcyBhIHNldCBv ZiBlbGxpcHRpYyBjdXJ2ZSBiYXNlZCBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgaW5jbHVkaW5n IGRpZ2l0YWwgc2lnbmF0dXJlLCBwdWJsaWMga2V5IGVuY3J5cHRpb24gYW5kIGtleSBleGNoYW5n ZSBzY2hlbWUuIEluIHRoaXMgZG9jdW1lbnQsIG9ubHkgdGhlIFNNMiBkaWdpdGFsIHNpZ25hdHVy ZSBhbGdvcml0aG0gaXMgaW52b2x2ZWQiDQoNCiAgIFRoZSBkb2N1bWVudCBzZWVtcyB0byBkZWZp bmUgdGhlIHVzZSBvZiBTTTIgZm9yIGtleSBleGNoYW5nZSBhcyB3ZWxsIA0KDQoNCi0tIEkgZG9u J3Qgc2VlIHdoeSB0aGUgYWxnb3JpdGhtcyBhcmUgbm90IERUTFMtT0sNCg0KDQpCZXN0IFJlZ2Fy ZHMsDQpKb2huDQoNCg== From nobody Wed Dec 11 05:22:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C3012011C for ; Wed, 11 Dec 2019 05:21:59 -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, DKIMWL_WL_HIGH=-0.001, 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=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 YPRhVCu_bkO4 for ; Wed, 11 Dec 2019 05:21:55 -0800 (PST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.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 616FE120137 for ; Wed, 11 Dec 2019 05:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576070514; 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=Cu+tVTOjK7KzZBbWDjNVHHbaycpujpCYpEMe1wNKcS0=; b=OtoP7OplqTz4P2ezYCUuc1zWh6qGkBkfg8ex8BiZdmU7OvrhWP5y9RCbTa22+tEg9QjxnF gn7SQvYjUQDXk8P+uonK6y0Y7VyOlbObd352GA7xJY/xmlJCwZtjmYxiZqB+Km9jJxqKKt 0T81qKQ0I15NhjKiJXDO7bslbB0RyI4= 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-392-xIyTnjz0NRCf3ljO1_kbJQ-1; Wed, 11 Dec 2019 08:21:52 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 65C1318044A8 for ; Wed, 11 Dec 2019 13:21:51 +0000 (UTC) Received: from localhost (ovpn-200-54.brq.redhat.com [10.40.200.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F3863165F0 for ; Wed, 11 Dec 2019 13:21:50 +0000 (UTC) From: Hubert Kario To: Date: Wed, 11 Dec 2019 14:21:48 +0100 MIME-Version: 1.0 Message-ID: <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> In-Reply-To: <20191207102017.GA1754124@LK-Perkele-VII> References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: xIyTnjz0NRCf3ljO1_kbJQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 11 Dec 2019 13:21:59 -0000 On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: > On Fri, Dec 06, 2019 at 11:09:48AM -0600, Darin Pettis wrote: >> On Thu, Nov 14, 2019 at 4:43 PM Adam Langley=20 >> wrote: >>> People on this list who manage large corporate networks may wish to pay >>> attention to this: while you may not have updated servers to TLS 1.3 ye= t, >>> eventually it'll happen and I suspect some will find a significant amou= nt >>> of things like TPMs, in which you currently have client-certificate key= s, >>> which only sign with PKCS#1 v1.5. Without this draft adopted and ... >>=20 >> Adam - Wanted to thank you for the call-out to people on the list managi= ng >> large corporate networks. Looking into the mutual=20 >> authentication supported >> protocols issue that you and David raised. Will evaluate potential futu= re >> impact. > > There are also library issues where the physical device does allow > RSA-PSS (e.g., because they can perform raw RSA root on arbitrary > values[1]), but libraries/drivers do not support it. > > One test I just tried: > > - Smartcard capable of raw RSA. > - OpenSC PKCS#11 drivers. > - Firefox ESR 68 > - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is > enabled[2]). > > Result: Failed. Client hits internal error code SEC_ERROR_LIBRARY_FAILURE > [3]. That doesn't match my understanding of how NSS works =E2=80=93 AFAIK, NSS (= and as such, Firefox), will try both raw RSA and rsa-pss signatures with the=20 token, depending on what kind of algorithms the token advertises.=20 I think the issue was the old version of OpenSC, new versions can do=20 rsa-pss with rsa-raw: https://bugzilla.redhat.com/show_bug.cgi?id=3D1595626 https://github.com/OpenSC/OpenSC/pull/1435 > [1] Yeah, not great for security, but some devices are like that. > > [2] That option was a hack to make things work with Firefox ESR 52, > which did send RSA PKCS#1v1.5 client signature (scheme 0x0401) in > comparable situation. > > [3] My guess would be that browser asks drivers for RSA-PSS, which they > do not support, causing the error. --=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 Wed Dec 11 06:22:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1CD120033 for ; Wed, 11 Dec 2019 06:22:02 -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 lH5JB_Hzt2ET for ; Wed, 11 Dec 2019 06:22:00 -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 7A8C912000F for ; Wed, 11 Dec 2019 06:22:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id ADA4DBF72 for ; Wed, 11 Dec 2019 16:21:57 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id RVp0uY9r6xV3 for ; Wed, 11 Dec 2019 16:21:57 +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 4E3B2286 for ; Wed, 11 Dec 2019 16:21:56 +0200 (EET) Date: Wed, 11 Dec 2019 16:21:55 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20191211142155.GA1879660@LK-Perkele-VII> References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 11 Dec 2019 14:22:02 -0000 On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: > On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: > > > > One test I just tried: > > > > - Smartcard capable of raw RSA. > > - OpenSC PKCS#11 drivers. > > - Firefox ESR 68 > > - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is > > enabled[2]). > > > > Result: Failed. Client hits internal error code SEC_ERROR_LIBRARY_FAILURE > > [3]. > > That doesn't match my understanding of how NSS works – AFAIK, NSS (and as > such, Firefox), will try both raw RSA and rsa-pss signatures with the token, > depending on what kind of algorithms the token advertises. > > I think the issue was the old version of OpenSC, new versions can do rsa-pss > with rsa-raw: > https://bugzilla.redhat.com/show_bug.cgi?id=1595626 > https://github.com/OpenSC/OpenSC/pull/1435 Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes client certificates in TLS 1.3 in Firefox work with that card (works even if accept RSA PKCS#1v1.5 client signatures is disabled on server side). There is apparently no release with the fix. One needs 0.20-rcX or recent git master. -Ilari From nobody Wed Dec 11 09:06:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BA61200D8 for ; Wed, 11 Dec 2019 09:06:39 -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 yvf2OWSr2mwZ for ; Wed, 11 Dec 2019 09:06:36 -0800 (PST) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1F812000F for ; Wed, 11 Dec 2019 09:06:36 -0800 (PST) Received: by mail-pf1-x443.google.com with SMTP id x185so2105004pfc.5 for ; Wed, 11 Dec 2019 09:06:36 -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=DYRqBq3Bbo2n5e5bXEX2tTGpxehO/xetMASaLzhPVIo=; b=AAQkH8yO/e7cu3ZsdJ6DVVZkegzI1hXKS+avA6dj/kBF3jnL0f1NbZlCWee1F/uzn9 fTZtOoqEfRbKOYU0u7bPIljhj8/9yKk/DBMNOxCKzs29KQKiD1mx0/JakYolydwcR7i2 +Hc28w4KAp28/2vW1KnkE5B1wHmD8NJgzDSQU= 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=DYRqBq3Bbo2n5e5bXEX2tTGpxehO/xetMASaLzhPVIo=; b=OfXBX/xIM8fDd5HafEHXs2b6K58yWDB2R+43Qlp4ZUdSWy+qrkR5hCldSpkDlbRTFN 8P4FvWhm7BXxFjKMSrHyZkwazLajI4UIyjxg1Dfe6iTL+509Y1FZ5BaYzmcwthkA6RXH HWfAZa5McQqfKjxqgzrthKlJmMcYese/MUqtFGIVPuGQlt9z2imcNgMOxLpPVp46IHIU G4/2KsiPj6gO9zqJHTHTNX5RujDoa71vvnfgJ7rx+OBzFUC7+Kj4zMQYqZx8G3NthcRo YnS0wT8SUMYNT4KuUlQQJNVFkb9JOFBhaKhO+YGpjoRKCzhJ0PFZRX77IN8sis9AfZtD 667g== X-Gm-Message-State: APjAAAVZMGyhwD4uTNGekRO2mEJQmMlx2UDwUonvTlxUPE/6Fyd4v3Tz nLTPi4L3KGjKzLlDmDF4o9SYcd9eliG0x/42Nb3UV2PuAQ== X-Google-Smtp-Source: APXvYqywRKiB+nCGU9FAL5d0EqJ6UGPiYtrqJmZ47aKkPz3azZt60nR1X+KNKbEVm4B6ukzfQjoGoMq6WvdstGFQNf4= X-Received: by 2002:aa7:8e05:: with SMTP id c5mr4906890pfr.4.1576083995958; Wed, 11 Dec 2019 09:06:35 -0800 (PST) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> In-Reply-To: <20191211142155.GA1879660@LK-Perkele-VII> From: David Benjamin Date: Wed, 11 Dec 2019 12:06:19 -0500 Message-ID: To: Ilari Liusvaara Cc: "" Content-Type: multipart/alternative; boundary="000000000000b77aab059970a6a5" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 11 Dec 2019 17:06:39 -0000 --000000000000b77aab059970a6a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara wrote: > On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: > > On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: > > > > > > One test I just tried: > > > > > > - Smartcard capable of raw RSA. > > > - OpenSC PKCS#11 drivers. > > > - Firefox ESR 68 > > > - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is > > > enabled[2]). > > > > > > Result: Failed. Client hits internal error code > SEC_ERROR_LIBRARY_FAILURE > > > [3]. > > > > That doesn't match my understanding of how NSS works =E2=80=93 AFAIK, N= SS (and as > > such, Firefox), will try both raw RSA and rsa-pss signatures with the > token, > > depending on what kind of algorithms the token advertises. > > > > I think the issue was the old version of OpenSC, new versions can do > rsa-pss > > with rsa-raw: > > https://bugzilla.redhat.com/show_bug.cgi?id=3D1595626 > > https://github.com/OpenSC/OpenSC/pull/1435 > > Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes > client certificates in TLS 1.3 in Firefox work with that card (works even > if accept RSA PKCS#1v1.5 client signatures is disabled on server side). > > There is apparently no release with the fix. One needs 0.20-rcX or recent > git master. > Chrome likewise tries to polyfill PSS support out of raw RSA when the underlying keys support it, but PSS support is still a problem. In particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it with raw padding. (Oddly, the spec does reference OAEP, but signing is only PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. Between the negotiation ordering and the client certificate privacy flaw fixed in TLS 1.3, simply saying "no TLS 1.3 for those keys" is problematic. Thus, the draft. It's true that it adds some transitionary codepoints to TLS 1.3, but the point of TLS 1.3 was not switching to PSS. That's a minor bonus on top of *much* more important changes. Most properties negotiated by TLS can be unilaterally updated by the TLS-related components of a system. This is great because it means we can deploy TLS 1.3's improvements. The long-term credentials are one of the big exceptions here and, indeed, we didn't just make TLS 1.3 mandate Ed25519. We wanted to maintain continuity with existing RSA keys, but since it was possible to switch them to RSA-PSS we went ahead and did that. Sadly, it appears that last point can be more true for server keys than client keys. :-( David --000000000000b77aab059970a6a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 11, 2019 at 9:22 AM Ilari Liu= svaara <il= ariliusvaara@welho.com> wrote:
<= 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">On Wed, Dec 11, 2019 at 02= :21:48PM +0100, Hubert Kario wrote:
> On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote:
> >
> > One test I just tried:
> >
> > - Smartcard capable of raw RSA.
> > - OpenSC PKCS#11 drivers.
> > - Firefox ESR 68
> > - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signature= s is
> >=C2=A0 =C2=A0enabled[2]).
> >
> > Result: Failed. Client hits internal error code SEC_ERROR_LIBRARY= _FAILURE
> > [3].
>
> That doesn't match my understanding of how NSS works =E2=80=93 AFA= IK, NSS (and as
> such, Firefox), will try both raw RSA and rsa-pss signatures with the = token,
> depending on what kind of algorithms the token advertises.
>
> I think the issue was the old version of OpenSC, new versions can do r= sa-pss
> with rsa-raw:
> https://bugzilla.redhat.com/show_bug.cgi?= id=3D1595626
> https://github.com/OpenSC/OpenSC/pull/1435

Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes
client certificates in TLS 1.3 in Firefox work with that card (works even if accept RSA PKCS#1v1.5 client signatures is disabled on server side).

There is apparently no release with the fix. One needs 0.20-rcX or recent git master.

Chrome likewise tries to po= lyfill PSS support out of raw RSA when the underlying keys support it, but = PSS support is still a problem. In particular, I believe TPM 1.2 can neithe= r do RSA-PSS nor polyfill it with raw padding. (Oddly, the spec does refere= nce OAEP, but signing is only PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardwar= e lifecycles are long. Between the negotiation ordering and the client cert= ificate privacy flaw fixed in TLS 1.3, simply saying "no TLS 1.3 for t= hose keys" is problematic. Thus, the draft. It's true that it adds= some transitionary codepoints to TLS 1.3, but the point of TLS 1.3 was not= switching to PSS. That's a minor bonus on top of much=C2=A0more= important changes.

Most properties negotiated by TLS can be = unilaterally updated by the TLS-related components of a system. This is gre= at because it means we can deploy TLS 1.3's improvements. The long-term= credentials are one of the big exceptions here and, indeed, we didn't = just make TLS 1.3 mandate Ed25519. We wanted to maintain continuity with ex= isting RSA keys, but since it was possible to switch them to RSA-PSS we wen= t ahead and did that. Sadly, it appears that last point can be more true fo= r server keys than client keys. :-(

David
--000000000000b77aab059970a6a5-- From nobody Wed Dec 11 09:16:57 2019 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 F3856120088; Wed, 11 Dec 2019 09:16:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, Joseph Salowey , tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <157608461199.11437.2061730930042533586.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2019 09:16:51 -0800 Archived-At: Subject: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-tls13-cert-with-extern-psk-03=3A_=28with_COMMENT=29?= 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, 11 Dec 2019 17:16:52 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a small thing to double-check: I wonder if this sentence would actually require an update to RFC8446: "TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server." Or maybe it should be phrased differently, just: "If the "tls_cert_with_extern_psk" extension is negotiated, certificate-based authentication is allowed for both the client and the server." I guess it depends on what exactly is said in RFC8446 (and I didn't went and tried to find it). And as a side note, it is usually recommended to provide the link to the registry in the IANA section (to make life for IANA easier). From nobody Wed Dec 11 09:58:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417D71200E5 for ; Wed, 11 Dec 2019 09:58:41 -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=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 l7lpPZmxpfje for ; Wed, 11 Dec 2019 09:58:38 -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 88E12120088 for ; Wed, 11 Dec 2019 09:58:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2C46A300B30 for ; Wed, 11 Dec 2019 12:49:00 -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 ZdpWVAliYuG8 for ; Wed, 11 Dec 2019 12:48:58 -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 DDB4C3005DB; Wed, 11 Dec 2019 12:48:57 -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: <157608461199.11437.2061730930042533586.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2019 12:48:58 -0500 Cc: IESG , draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, Joe Salowey , TLS Chairs , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <157608461199.11437.2061730930042533586.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-tls13-cert-with-extern-psk-03=3A_=28with_COMMENT=29?= 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, 11 Dec 2019 17:58:41 -0000 Mirja: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Just a small thing to double-check: I wonder if this sentence would = actually > require an update to RFC8446: > "TLS 1.3 does not permit the server to send a CertificateRequest > message when a PSK is being used. This restriction is removed when > the "tls_cert_with_extern_psk" extension is negotiated, allowing > certificate-based authentication for both the client and the = server." > Or maybe it should be phrased differently, just: > "If the "tls_cert_with_extern_psk" extension is negotiated, = certificate-based > authentication is allowed for both the client and the server." I guess = it > depends on what exactly is said in RFC8446 (and I didn't went and = tried to find > it). I do not believe that an update is needed or appropriate. First, the = presence of this extension is an indication that this behavior will be = different. Second, this is going to be an Experimental RFC, so it = should not update a standards-track RFC. > And as a side note, it is usually recommended to provide the link to = the > registry in the IANA section (to make life for IANA easier) I will gladly add a reference to the registry: = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml Russ From nobody Wed Dec 11 15:58:28 2019 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 AAE801200C5; Wed, 11 Dec 2019 15:58:21 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157610870165.11430.14659542293830026467@ietfa.amsl.com> Date: Wed, 11 Dec 2019 15:58:21 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-08.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, 11 Dec 2019 23:58:22 -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 : TLS Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-08.txt Pages : 8 Date : 2019-12-11 Abstract: In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-08 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 11 16:04:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6B212018D for ; Wed, 11 Dec 2019 16:04:38 -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=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_vXIcO7pFBD for ; Wed, 11 Dec 2019 16:04:36 -0800 (PST) Received: from blastoise.ghedini.me (blastoise.ghedini.me [45.32.158.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F23A1200B3 for ; Wed, 11 Dec 2019 16:04:36 -0800 (PST) Received: from localhost (unknown [IPv6:2a02:8010:6241:1:4585:3d6b:2892:b4f7]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 36038DF451 for ; Thu, 12 Dec 2019 00:04:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1576109074; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XhQIdIS1zdeqvtMp8RwhTOKKr1Wo22VvENAkjEE/QVc=; b=fOQfig9+DJKvPhI/2gyJs1ro0lJXueSi849kGMFfcFUSvGEfVQyXXIlVsMF6OiScPjz7LY MM0IeH5Qd7vl+n80r4lH666A9WykSSSof6PAw+ITR96fojnQAA/WuSdQoHebtyyx+OxzPR Rs1nIwR0hrO48rcvL6X1J8tkkIRg8v0= Date: Thu, 12 Dec 2019 00:04:31 +0000 From: Alessandro Ghedini To: tls@ietf.org Message-ID: <20191212000431.GA10184@sokka.flat11.house> References: <157610870165.11430.14659542293830026467@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157610870165.11430.14659542293830026467@ietfa.amsl.com> User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-08.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, 12 Dec 2019 00:04:38 -0000 On Wed, Dec 11, 2019 at 03:58:21PM -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 : TLS Certificate Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-08.txt > Pages : 8 > Date : 2019-12-11 > > Abstract: > In TLS handshakes, certificate chains often take up the majority of > the bytes transmitted. > > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-08 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-08 This addresses the feedback from Christian's secdir last call review. Cheers From nobody Thu Dec 12 03:51:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0537B1208E1 for ; Thu, 12 Dec 2019 03:51:34 -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, DKIMWL_WL_HIGH=-0.001, 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=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 1IlcrOD6X9C9 for ; Thu, 12 Dec 2019 03:51:33 -0800 (PST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.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 CB6C11208DE for ; Thu, 12 Dec 2019 03:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576151491; 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=PaTu7ZDGCrDdKHhmaOgfnLW8ehxBhcnkS0m3pHN7tiI=; b=LwTpjB87vtBZTbd7HyK4QgB1emTFMMqgQ0xfjQvn/I33gqrJcoNBsm1pe/6oYtw9JZlzqm fGKNHURL3UWrEvQk4xc9+bou3bUO7fU/KNLzDrMPv86DmjMw1YVeo31LKUl9BK8Ccb26Cx MA+VoF+Pi5FLPI9JyAr+A3ySOeKj7GA= 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-19-cQdwjwEHMEKgm8020XHV5w-1; Thu, 12 Dec 2019 06:51:28 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B09C5DB20 for ; Thu, 12 Dec 2019 11:51:27 +0000 (UTC) Received: from localhost (ovpn-200-54.brq.redhat.com [10.40.200.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3EBE860BC9 for ; Thu, 12 Dec 2019 11:51:27 +0000 (UTC) From: Hubert Kario To: Date: Thu, 12 Dec 2019 12:51:24 +0100 MIME-Version: 1.0 Message-ID: <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> In-Reply-To: References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> 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.11 X-MC-Unique: cQdwjwEHMEKgm8020XHV5w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 12 Dec 2019 11:51:35 -0000 On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara > wrote: > >> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: >>> On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: >>>>=20 >>>> One test I just tried: >>>>=20 >>>> - Smartcard capable of raw RSA. >>>> - OpenSC PKCS#11 drivers. >>>> - Firefox ESR 68 >>>> - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is >>>> enabled[2]). >>>>=20 >>>> Result: Failed. Client hits internal error code >>>> SEC_ERROR_LIBRARY_FAILURE >>>> [3]. >>>=20 >>> That doesn't match my understanding of how NSS works =E2=80=93 AFAIK, N= SS (and as >>> such, Firefox), will try both raw RSA and rsa-pss signatures with the >>> token, >>> depending on what kind of algorithms the token advertises. >>>=20 >>> I think the issue was the old version of OpenSC, new versions can do >>> rsa-pss >>> with rsa-raw: >>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1595626 >>> https://github.com/OpenSC/OpenSC/pull/1435 >>=20 >> Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes >> client certificates in TLS 1.3 in Firefox work with that card (works eve= n >> if accept RSA PKCS#1v1.5 client signatures is disabled on server side). >>=20 >> There is apparently no release with the fix. One needs 0.20-rcX or recen= t >> git master. >>=20 > > Chrome likewise tries to polyfill PSS support out of raw RSA when the > underlying keys support it, but PSS support is still a problem. In > particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it with > raw padding. (Oddly, the spec does reference OAEP, but signing is only > PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. Betwe= en > the negotiation ordering and the client certificate privacy flaw fixed in > TLS 1.3, simply saying "no TLS 1.3 for those keys" is problematic. Thus, > the draft. It's true that it adds some transitionary codepoints to TLS 1.= 3, > but the point of TLS 1.3 was not switching to PSS. That's a minor bonus o= n > top of *much* more important changes. > > Most properties negotiated by TLS can be unilaterally updated by the > TLS-related components of a system. This is great because it means we can > deploy TLS 1.3's improvements. The long-term credentials are one of the b= ig > exceptions here and, indeed, we didn't just make TLS 1.3 mandate Ed25519. > We wanted to maintain continuity with existing RSA keys, but since it was > possible to switch them to RSA-PSS we went ahead and did that. Sadly, it > appears that last point can be more true for server keys than client keys= . > :-( If TLS 1.2 was looking insecure, I would be with you on this one. But given that TLS 1.2 can be configured to be as secure as TLS 1.3, I think=20 introducing weak points to TLS 1.3, weak points we will have to live with for the next decade, if not two, is counter-productive and will only delay deployemnt of= =20 RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual=20 pressure to replace that obsolete hardware, without exposing users to unnecessary=20 risk. --=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 Dec 12 07:26:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CDF120047 for ; Thu, 12 Dec 2019 07:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filippo.io header.b=sGdF+NmB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JKXK+z9z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLo0jkUdEfoE for ; Thu, 12 Dec 2019 07:26:19 -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 033D7120033 for ; Thu, 12 Dec 2019 07:26:18 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1BC152275F for ; Thu, 12 Dec 2019 10:26:18 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Thu, 12 Dec 2019 10:26:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=8w9sM eWyX/h6YdjxpuGlLOmOj31+a09DPzanVpZaE0Y=; b=sGdF+NmByxvkrn2cZKpQq kBvNttI06fj9SihhTffyzpqoKS0FYioOPMOs7cRmFX8XCdRIS8b0HgTRBkfGgUnq 8S8OJZ9XtN+OVMRdmrRt815FpM8Bq+WOkBDlYfJObo4foYdJHj3v9YPK2QpKGkS9 Q/3j8cUOmdsgJhZIZvzpguiQkYxmTV6P88bZVcbv+xMr4spYsUh/mVIIMMc+yQUI i/bxJ3QODQMnhTe22nyYMugS4SFoRy1N4Xj92zx9nID6ZnGXNL+ujCEUa/rVt/SJ 61mGJZvSBDnmbUmEGr9K3Vwa71IJMTS9TTwcejkuYepiMnmSPNW/ihSX6B/xTVft g== 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=fm1; bh=8w9sMeWyX/h6YdjxpuGlLOmOj31+a09DPzanVpZaE 0Y=; b=JKXK+z9zkdX150XDocqB8bBW2qokcqDe58k27lRFh3r6jtw2D3xjsbumc D/qug+YajFujuR6IwCyom4LS7sNa40ia1QlYj9nCCe7aF9nOhYEtWvQZnln7cdZK Ewcy173L/39T/INermnS9tPmk+USFbni59s2TRZr5LuFPbrioYf25lyvnvDAUkNO ZWoxt1l3JvMuhDsHSNKgbW/DSDmm1lRXCzA7PCvtZIBjySQNT/hVy2/qlOPNnTNN Q+VdpouwxGf7vdkGjHJk05syq7SczF+aPGy04cw5h3L3tWZxRrSZG/IZ4v889FYt rW5SozM8ZXvaiANmIHMwAwxMVRghg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeljedgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdfhihhlihhpphhoucggrghlshhorhgurgdfuceofhhi lhhiphhpohesmhhlrdhfihhlihhpphhordhioheqnecuffhomhgrihhnpehrvgguhhgrth drtghomhdpghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfihhl ihhpphhosehmlhdrfhhilhhiphhpohdrihhonecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B069DC200A4; Thu, 12 Dec 2019 10:26:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-679-g1f7ccac-fmstable-20191210v1 Mime-Version: 1.0 Message-Id: <8b89d2f0-589d-4019-8d17-2eeac84b0233@www.fastmail.com> In-Reply-To: <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> Date: Thu, 12 Dec 2019 10:25:55 -0500 From: "Filippo Valsorda" To: tls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 12 Dec 2019 15:26:21 -0000 2019-12-12 06:51 GMT-05:00 Hubert Kario : > On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: > > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara > > wrote: > > > >> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: > >>> On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: > >>>>=20 > >>>> One test I just tried: > >>>>=20 > >>>> - Smartcard capable of raw RSA. > >>>> - OpenSC PKCS#11 drivers. > >>>> - Firefox ESR 68 > >>>> - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signature= s is > >>>> enabled[2]). > >>>>=20 > >>>> Result: Failed. Client hits internal error code > >>>> SEC_ERROR_LIBRARY_FAILURE > >>>> [3]. > >>>=20 > >>> That doesn't match my understanding of how NSS works =E2=80=93 AFA= IK, NSS (and as > >>> such, Firefox), will try both raw RSA and rsa-pss signatures with = the > >>> token, > >>> depending on what kind of algorithms the token advertises. > >>>=20 > >>> I think the issue was the old version of OpenSC, new versions can = do > >>> rsa-pss > >>> with rsa-raw: > >>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1595626 > >>> https://github.com/OpenSC/OpenSC/pull/1435 > >>=20 > >> Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) ma= kes > >> client certificates in TLS 1.3 in Firefox work with that card (work= s even > >> if accept RSA PKCS#1v1.5 client signatures is disabled on server si= de). > >>=20 > >> There is apparently no release with the fix. One needs 0.20-rcX or = recent > >> git master. > >>=20 > > > > Chrome likewise tries to polyfill PSS support out of raw RSA when th= e > > underlying keys support it, but PSS support is still a problem. In > > particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it= with > > raw padding. (Oddly, the spec does reference OAEP, but signing is on= ly > > PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. = Between > > the negotiation ordering and the client certificate privacy flaw fix= ed in > > TLS 1.3, simply saying "no TLS 1.3 for those keys" is problematic. T= hus, > > the draft. It's true that it adds some transitionary codepoints to T= LS 1.3, > > but the point of TLS 1.3 was not switching to PSS. That's a minor bo= nus on > > top of *much* more important changes. > > > > Most properties negotiated by TLS can be unilaterally updated by the= > > TLS-related components of a system. This is great because it means w= e can > > deploy TLS 1.3's improvements. The long-term credentials are one of = the big > > exceptions here and, indeed, we didn't just make TLS 1.3 mandate Ed2= 5519. > > We wanted to maintain continuity with existing RSA keys, but since i= t was > > possible to switch them to RSA-PSS we went ahead and did that. Sadly= , it > > appears that last point can be more true for server keys than client= keys. > > :-( >=20 > If TLS 1.2 was looking insecure, I would be with you on this one. But = given > that TLS 1.2 can be configured to be as secure as TLS 1.3 TLS 1.3 provides privacy for client certificates, which TLS 1.2 does not= . > I think introducing > weak points to TLS 1.3, weak points we will have to live with for the = next > decade, if not two, is counter-productive and will only delay deployem= nt of=20 > RSA-PSS capable HSMs. This draft is only about client authentication, it does not release pressure from server-side HSMs. I just had to hold back a Go crypto/tls deployment from TLS 1.3 due to the same issue that David encountered, so I'd support this draft. Leaving behind entire client hardware generations is not the same thing as enforcing progress in software implementations. From nobody Thu Dec 12 07:27:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB385120921 for ; Thu, 12 Dec 2019 07:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 zgfr8k8SHmZR for ; Thu, 12 Dec 2019 07:26:55 -0800 (PST) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E4912092F for ; Thu, 12 Dec 2019 07:26:54 -0800 (PST) Received: by mail-ed1-f41.google.com with SMTP id v16so2127658edy.6 for ; Thu, 12 Dec 2019 07:26:54 -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=c0WAHVsOuBj8unqrCGdbQ6KWbDoxYQpdSFdatKXVaiw=; b=RY2XUC1hNw7I9ZW+lEeOp73q4p85HZnuTDO7QdWgkN6phL0Wea+yOvifF7dwq6AqD2 fj44nM5nHWueQgZHHK08kiaynJkRx4qj75qnIl2lHOehIof9hKlHzbgq/9ZNgS0wM9Cy jp0lUBKlPO/Mb00lYk6bTzaHEK/V2cX9PpdXwiWbmLvmHc6/Fvs5PkK1lAc0rQhXCzSV XmLHougtCMkeeis9VBlqXCRgrdMUvQ9d0lSS0zRRnxJdW/V8ZIR1QojyB2Zr8Qe8Kp0C 41vKG1gyF2Mk5A3yfrA+4CxkEZ6r/TVotV8rfh7mvXl+CyTuN45cUkAmXa4uJ7pqHcKh S/IQ== X-Gm-Message-State: APjAAAV39jTNs32QzaXL28Nc+jDDazgyDPrrYcOO2GCfPI+tAezs5DAG 9x495aLo7jiyWE8zMtTCTANqmrAz X-Google-Smtp-Source: APXvYqwPkYvqxn3a++9nT3UeV7mxkCoFnEAWzQeeAjXblMAbmQ7s/IOs6HMX3Dgca40OlqN0dtbjlg== X-Received: by 2002:a05:6402:148f:: with SMTP id e15mr10156605edv.254.1576164412644; Thu, 12 Dec 2019 07:26:52 -0800 (PST) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com. [209.85.221.49]) by smtp.gmail.com with ESMTPSA id x8sm124210eds.88.2019.12.12.07.26.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Dec 2019 07:26:52 -0800 (PST) Received: by mail-wr1-f49.google.com with SMTP id y11so3176075wrt.6 for ; Thu, 12 Dec 2019 07:26:52 -0800 (PST) X-Received: by 2002:a5d:6748:: with SMTP id l8mr7139189wrw.188.1576164412077; Thu, 12 Dec 2019 07:26:52 -0800 (PST) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> In-Reply-To: <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> From: Ryan Sleevi Date: Thu, 12 Dec 2019 10:26:41 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Hubert Kario Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e3c0200599835f6f" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 12 Dec 2019 15:26:59 -0000 --000000000000e3c0200599835f6f Content-Type: text/plain; charset="UTF-8" On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: > If TLS 1.2 was looking insecure, I would be with you on this one. But given > that TLS 1.2 can be configured to be as secure as TLS 1.3, I think > introducing > weak points to TLS 1.3, weak points we will have to live with for the next > decade, if not two, is counter-productive and will only delay deployemnt > of > RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual > pressure > to replace that obsolete hardware, without exposing users to unnecessary > risk. > That risk calculus doesn't seem to make sense, or even be internally consistent? If we apply the logic you're applying here - that the non-existence within TLS 1.3 somehow exerts pressure on organizations to replace - then that pressure only exists because the value proposition of TLS1.3 to these organizations is greater than the cost of replacing that hardware. But as you seemingly state, the value proposition of TLS 1.3 is not significant, because "TLS 1.2 can be configured as secure as TLS 1.3". So what's the pressure these organizations would face that would have them wanting to adopt TLS1.3? It seems that, at least with the information provided, the existence or non-existence of PKCS#1v1.5 in TLS1.3 cannot be the force that exerts pressure. Similarly, this argument implies organizations are rational actors that evaluate these protocols based on the security strength. If they are indeed rational, then the presumed weakness of PKCS#1v1.5 (and not TLS 1.2 vs TLS 1.3) would naturally exert a pressure on organizations to replace this hardware, in order to leverage the better security of RSA-PSS. Thus the existence within TLS1.3 does not actually meaningfully change the calculus for security or for organizational pressure. Setting aside for a second arguments about whether RSA-PSS vs PKCS#1v1.5 (in the context of client certificates) is a significant security differentiator, or whether the security properties of TLS1.2 vs TLS1.3 is are significant enough to exert pressure, it also seemingly overlooks the privacy value afforded by TLS1.3's encryption. If we're trying to make cost-based assumptions here about what pressures will be exerted, I feel like we have ample evidence from the TLS 1.3 adoption that benefits in security and privacy do not actually exert pressures on organizations to change, because the incremental value they provide is outweighed by the costs. The middlebox challenges are a case-study in this. This draft attempts to reduce those costs, making it possible to take advantage of those incremental improvements made in 1.3. The distinction isn't going from good to going from bad, which seems to be implied by arguing against adoption, it's going from worse (TLS1.2, with no privacy affordances and the ample considerations around the key schedules) to something meaningfully better (TLS1.3), even if it's not ideal. --000000000000e3c0200599835f6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 12, 2019 at 6:51 AM Huber= t Kario <hkario@redhat.com> = wrote:
If TLS 1.2 was looking insecure, I would be with you on this one. But given=
that TLS 1.2 can be configured to be as secure as TLS 1.3, I think
introducing
weak points to TLS 1.3, weak points we will have to live with for the next<= br> decade, if not two, is counter-productive and will only delay deployemnt of=
RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual
pressure
to replace that obsolete hardware, without exposing users to unnecessary risk.

That risk calculus doesn't se= em to make sense, or even be internally consistent?

If we apply the logic you're applying here - that the non-existence w= ithin TLS 1.3 somehow exerts pressure on organizations to replace - then th= at pressure only exists because the value proposition of TLS1.3 to these or= ganizations is greater than the cost of replacing that hardware. But as you= seemingly state, the value proposition of TLS 1.3 is not significant, beca= use "TLS 1.2 can be configured as secure as TLS 1.3". So what'= ;s the pressure these organizations would face that would have them wanting= to adopt TLS1.3? It seems that, at least with the information provided, th= e existence or non-existence of PKCS#1v1.5 in TLS1.3 cannot be the force th= at exerts pressure.

Similarly, this argument impli= es organizations are rational actors that evaluate these protocols based on= the security strength. If they are indeed rational, then the presumed weak= ness of PKCS#1v1.5 (and not TLS 1.2 vs TLS 1.3) would naturally exert a pre= ssure on organizations to replace this hardware, in order to leverage the b= etter security of RSA-PSS. Thus the existence within TLS1.3 does not actual= ly meaningfully change the calculus for security or for organizational pres= sure.

Setting aside for a second arguments about w= hether RSA-PSS vs PKCS#1v1.5 (in the context of client certificates) is a s= ignificant security differentiator, or whether the security properties of T= LS1.2 vs TLS1.3 is are significant enough to exert pressure, it also seemin= gly overlooks the privacy value afforded by TLS1.3's encryption.
<= div>
If we're trying to make cost-based assumptions here = about what pressures will be exerted, I feel like we have ample evidence fr= om the TLS 1.3 adoption that benefits in security and privacy do not actual= ly exert pressures on organizations to change, because the incremental valu= e they provide is outweighed by the costs. The middlebox challenges are a c= ase-study in this. This draft attempts to reduce those costs, making it pos= sible to take advantage of those incremental improvements made in 1.3.

The distinction isn't going from good to going fro= m bad, which seems to be implied by arguing against adoption, it's goin= g from worse (TLS1.2, with no privacy affordances and the ample considerati= ons around the key schedules) to something meaningfully better (TLS1.3), ev= en if it's not ideal.
--000000000000e3c0200599835f6f-- From nobody Thu Dec 12 07:51:07 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0636B120809 for ; Thu, 12 Dec 2019 07:51:06 -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 edFNNdqaC_2a for ; Thu, 12 Dec 2019 07:51:04 -0800 (PST) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786881200E9 for ; Thu, 12 Dec 2019 07:51:04 -0800 (PST) Received: by mail-pf1-x444.google.com with SMTP id 2so959872pfx.6 for ; Thu, 12 Dec 2019 07:51:04 -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=L+cL++88UfKjiyQLkx1g/r2oQBpmWoFwrfyNpFBD3YQ=; b=KzdosTYaiBaR+ptw+80no6sZtIOaEQ8obcR30iY8gQ/avD44kfSYEcTFumHe6BgM5r btYUJ1BfH/NunoPQ5mKCzRFluBcEIEb+P9Hs/K5LmuZ37wo+PtSvuIRwSYtTyz85p5U4 AElF6uzV3BE/ZLCYM34CGTXKaH7D20SARXtrs= 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=L+cL++88UfKjiyQLkx1g/r2oQBpmWoFwrfyNpFBD3YQ=; b=MaNmQj9DAZjRRA6qKRddiZwN1sOgEXf3j1BHtOeSEY7H6uL1KQVYw1rn0qyUBZuxvI Q01RmsWg8cV4vJ/4GCfzuHOISdCP8CBJ8FpV21XzS7brpQFAbBtX5wfDRCQ6jLfHIkv8 iRQMjx567G4MF51riF+bRWWFzqL9i1ayD9dIq8CZJT8MAZbSx07eJRLL3pEIB1GFVrUz PHrlOTdikuxTqzvgEpOZESwDBU3Ap+APw3IStn0eCNYtkF0Ic1Q3tzPiuYO/F9/Pkjlz v9XA9HGxfSbQL4i023d2mW9qEU3s6UgX7LMzZUaRRjWfehUnTw4l95mLULT23ELsRofi uOSw== X-Gm-Message-State: APjAAAUVz0YXHRUoBAO3yAB4dLKJr5cmVbnQFVpeVoyuQV9IBb91E0re 8GhSWJMI6XCdfp6Mbhq9m1j/Hb5FsYPd2TZawAPb X-Google-Smtp-Source: APXvYqzmiJLa1v+Aj8GLzGY8fy+MMm/BhzwvMwxPMaTKt+PDz0dLZBPRDlJSNTY3U2u2nHQdSQvsaQS/CT+T2h/cQ6c= X-Received: by 2002:a62:5547:: with SMTP id j68mr10799875pfb.6.1576165863801; Thu, 12 Dec 2019 07:51:03 -0800 (PST) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> In-Reply-To: <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> From: David Benjamin Date: Thu, 12 Dec 2019 10:50:45 -0500 Message-ID: To: Hubert Kario Cc: "" Content-Type: multipart/alternative; boundary="0000000000006bb34f059983b635" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 12 Dec 2019 15:51:06 -0000 --0000000000006bb34f059983b635 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: > On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: > > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > >> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: > >>> On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: > >>>> > >>>> One test I just tried: > >>>> > >>>> - Smartcard capable of raw RSA. > >>>> - OpenSC PKCS#11 drivers. > >>>> - Firefox ESR 68 > >>>> - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures i= s > >>>> enabled[2]). > >>>> > >>>> Result: Failed. Client hits internal error code > >>>> SEC_ERROR_LIBRARY_FAILURE > >>>> [3]. > >>> > >>> That doesn't match my understanding of how NSS works =E2=80=93 AFAIK,= NSS (and > as > >>> such, Firefox), will try both raw RSA and rsa-pss signatures with the > >>> token, > >>> depending on what kind of algorithms the token advertises. > >>> > >>> I think the issue was the old version of OpenSC, new versions can do > >>> rsa-pss > >>> with rsa-raw: > >>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1595626 > >>> https://github.com/OpenSC/OpenSC/pull/1435 > >> > >> Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes > >> client certificates in TLS 1.3 in Firefox work with that card (works > even > >> if accept RSA PKCS#1v1.5 client signatures is disabled on server side)= . > >> > >> There is apparently no release with the fix. One needs 0.20-rcX or > recent > >> git master. > >> > > > > Chrome likewise tries to polyfill PSS support out of raw RSA when the > > underlying keys support it, but PSS support is still a problem. In > > particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it wi= th > > raw padding. (Oddly, the spec does reference OAEP, but signing is only > > PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. > Between > > the negotiation ordering and the client certificate privacy flaw fixed = in > > TLS 1.3, simply saying "no TLS 1.3 for those keys" is problematic. Thus= , > > the draft. It's true that it adds some transitionary codepoints to TLS > 1.3, > > but the point of TLS 1.3 was not switching to PSS. That's a minor bonus > on > > top of *much* more important changes. > > > > Most properties negotiated by TLS can be unilaterally updated by the > > TLS-related components of a system. This is great because it means we c= an > > deploy TLS 1.3's improvements. The long-term credentials are one of the > big > > exceptions here and, indeed, we didn't just make TLS 1.3 mandate Ed2551= 9. > > We wanted to maintain continuity with existing RSA keys, but since it w= as > > possible to switch them to RSA-PSS we went ahead and did that. Sadly, i= t > > appears that last point can be more true for server keys than client > keys. > > :-( > > If TLS 1.2 was looking insecure, I would be with you on this one. But giv= en > that TLS 1.2 can be configured to be as secure as TLS 1.3, I think > introducing > weak points to TLS 1.3, weak points we will have to live with for the nex= t > decade, if not two, is counter-productive and will only delay deployemnt > of > RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual > pressure > to replace that obsolete hardware, without exposing users to unnecessary > risk. > For client certificates, TLS 1.2 cannot be configured to be as secure as TLS 1.3. The client certificates are sent in the clear. https://tma.ifip.org/wordpress/wp-content/uploads/2017/06/tma2017_paper2.pd= f You mentioned elsewhere you can renegotiate, but renegotiation doesn't work. It introduces a host of other problems from DoS risks to problems with changing the security state of a connection after the fact to general layering issues with the public API being odd. Some HTTP servers block renegotiation altogether (I believe NGINX does) and some TLS stacks don't support renegotiation as a server at all (BoringSSL and Go). More importantly, renegotiation is not supported with HTTP/2, which is an important improvement for performance and server load (fewer connections). Now, the HTTP/2 spec does say the following: > An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any renegotiation MUST occur prior to sending the connection preface. A server SHOULD request a client certificate if it sees a renegotiation request immediately after establishing a connection. However, I'm not aware of anyone implementing this, and I do not think this suggestion actually works. Chrome does not accept it as a client at all and will fail the connection, nor can I see any way to accept it. An HTTP/2 client speaks as soon as the handshake completes and does not know whether the server is going to do this. By the time the client receives a HelloRequest, it may have sent zero, one, or many HTTP requests. This means the fundamental ambiguities with a multiplexing protocol, as well as the handshake/app-data interleave problems, are immediately present. Conversely, as a server, the client may have sent arbitrarily many HTTP requests before it processed the HelloRequest, so the server must buffer them all up (DoS risk) or process them anonymously (changing security state mid-connection and not the same semantics as initial handshake authentication). David --0000000000006bb34f059983b635 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 12, 2019 at 6:51 AM Hubert Ka= rio <hkario@redhat.com> wrot= e:
On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin w= rote:
> On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara <ilariliusvaara@welho.com>= ;
> wrote:
>
>> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote:
>>> On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wro= te:
>>>>
>>>> One test I just tried:
>>>>
>>>> - Smartcard capable of raw RSA.
>>>> - OpenSC PKCS#11 drivers.
>>>> - Firefox ESR 68
>>>> - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client si= gnatures is
>>>>=C2=A0 =C2=A0enabled[2]).
>>>>
>>>> Result: Failed. Client hits internal error code
>>>> SEC_ERROR_LIBRARY_FAILURE
>>>> [3].
>>>
>>> That doesn't match my understanding of how NSS works =E2= =80=93 AFAIK, NSS (and as
>>> such, Firefox), will try both raw RSA and rsa-pss signatures w= ith the
>>> token,
>>> depending on what kind of algorithms the token advertises.
>>>
>>> I think the issue was the old version of OpenSC, new versions = can do
>>> rsa-pss
>>> with rsa-raw:
>>> https://bugzilla.redhat.com/show_b= ug.cgi?id=3D1595626
>>> https://github.com/OpenSC/OpenSC/pull/1435
>>
>> Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) m= akes
>> client certificates in TLS 1.3 in Firefox work with that card (wor= ks even
>> if accept RSA PKCS#1v1.5 client signatures is disabled on server s= ide).
>>
>> There is apparently no release with the fix. One needs 0.20-rcX or= recent
>> git master.
>>
>
> Chrome likewise tries to polyfill PSS support out of raw RSA when the<= br> > underlying keys support it, but PSS support is still a problem. In
> particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it w= ith
> raw padding. (Oddly, the spec does reference OAEP, but signing is only=
> PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. Be= tween
> the negotiation ordering and the client certificate privacy flaw fixed= in
> TLS 1.3, simply saying "no TLS 1.3 for those keys" is proble= matic. Thus,
> the draft. It's true that it adds some transitionary codepoints to= TLS 1.3,
> but the point of TLS 1.3 was not switching to PSS. That's a minor = bonus on
> top of *much* more important changes.
>
> Most properties negotiated by TLS can be unilaterally updated by the > TLS-related components of a system. This is great because it means we = can
> deploy TLS 1.3's improvements. The long-term credentials are one o= f the big
> exceptions here and, indeed, we didn't just make TLS 1.3 mandate E= d25519.
> We wanted to maintain continuity with existing RSA keys, but since it = was
> possible to switch them to RSA-PSS we went ahead and did that. Sadly, = it
> appears that last point can be more true for server keys than client k= eys.
> :-(

If TLS 1.2 was looking insecure, I would be with you on this one. But given=
that TLS 1.2 can be configured to be as secure as TLS 1.3, I think
introducing
weak points to TLS 1.3, weak points we will have to live with for the next<= br> decade, if not two, is counter-productive and will only delay deployemnt of=
RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual
pressure
to replace that obsolete hardware, without exposing users to unnecessary risk.


=
You mentioned elsewhere you can renegotiate, but renegotiation doesn&#= 39;t work. It introduces a host of other problems from DoS risks to problem= s with=C2=A0changing the security state of a connection after the fact to= =C2=A0general layering issues with the public API being odd. Some HTTP serv= ers block renegotiation altogether (I believe NGINX does) and some TLS stac= ks don't support renegotiation as a server at all (BoringSSL and Go).

More importantly, renegotiation is not supported wi= th HTTP/2, which is an important improvement for performance and server loa= d (fewer connections). Now, the HTTP/2 spec does say the following:

> An endpoint MAY use renegotiation to provide confide= ntiality protection for client credentials offered in the handshake, but an= y renegotiation MUST occur prior to sending the connection preface. A serve= r SHOULD request a client certificate if it sees a renegotiation request im= mediately after establishing a connection.

However= , I'm not aware of anyone implementing this, and I do not think this su= ggestion actually works. Chrome does not accept it as a client at all and w= ill fail the connection, nor can I see any way to accept it. An HTTP/2 clie= nt speaks as soon as the handshake completes and does not know whether the = server is going to do this. By the time the client receives a HelloRequest,= it may have sent zero, one, or many HTTP requests. This means the fundamen= tal ambiguities with a multiplexing protocol, as well as the handshake/app-= data interleave problems, are immediately present. Conversely, as a server,= the client may have sent arbitrarily many HTTP requests before it processe= d the HelloRequest, so the server must buffer them all up (DoS risk) or pro= cess them anonymously (changing security state mid-connection and not the s= ame semantics as initial handshake authentication).

David
--0000000000006bb34f059983b635-- From nobody Thu Dec 12 07:58:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616BF12008D for ; Thu, 12 Dec 2019 07:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=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 eDzwfmQGIHbU for ; Thu, 12 Dec 2019 07:58:45 -0800 (PST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.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 305981200A1 for ; Thu, 12 Dec 2019 07:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576166324; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0sKbZMMPG+rgrj82mmb1xiinod1GN8oVtx8wxVa8LNU=; b=Hn+Uj5ktfha5o2W9BUYkcf+5IqnUcBn5W7fTtVwoqgSi+yMqwJdi79ZqkE05mzYgB8lJNh mD1gqTacx1YWIyb8Sq7rfREx6rz+Yvkgwy11K6mQGNLu8SQWOdXSQWQNsebD6k5BGuoghR u7pp5t1Zu1vfiB1mJVGqmzHq/zFt7tk= 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-182-Qo_tuoguPICUu-vc-DxXwQ-1; Thu, 12 Dec 2019 10:58:42 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B13E618AAFAF; Thu, 12 Dec 2019 15:58:41 +0000 (UTC) Received: from localhost (unknown [10.43.21.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DE3D160BF3; Thu, 12 Dec 2019 15:58:40 +0000 (UTC) From: Hubert Kario To: Ryan Sleevi Cc: Date: Thu, 12 Dec 2019 16:58:39 +0100 MIME-Version: 1.0 Message-ID: <5b1ed226-ba32-496b-8afa-fbcd274b78d7@redhat.com> In-Reply-To: References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.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.12 X-MC-Unique: Qo_tuoguPICUu-vc-DxXwQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 12 Dec 2019 15:58:47 -0000 On Thursday, 12 December 2019 16:26:41 CET, Ryan Sleevi wrote: > On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: > >> If TLS 1.2 was looking insecure, I would be with you on this=20 >> one. But given >> that TLS 1.2 can be configured to be as secure as TLS 1.3, I think >> introducing >> weak points to TLS 1.3, weak points we will have to live with for the ne= xt >> decade, if not two, is counter-productive and will only delay deployemnt >> of >> RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual >> pressure >> to replace that obsolete hardware, without exposing users to unnecessary >> risk. >>=20 > > That risk calculus doesn't seem to make sense, or even be internally > consistent? > > If we apply the logic you're applying here - that the non-existence withi= n > TLS 1.3 somehow exerts pressure on organizations to replace - then that > pressure only exists because the value proposition of TLS1.3 to these > organizations is greater than the cost of replacing that hardware. But as > you seemingly state, the value proposition of TLS 1.3 is not significant, > because "TLS 1.2 can be configured as secure as TLS 1.3". So what's the > pressure these organizations would face that would have them wanting to > adopt TLS1.3? It seems that, at least with the information provided, the > existence or non-existence of PKCS#1v1.5 in TLS1.3 cannot be the force th= at > exerts pressure. a). configuring TLS 1.3 to be secure is easier - so using TLS 1.3=20 automatically makes the use of it more secure b). the evaluation I am performing is time dependant - i.e. I'm talking=20 about situation as it is *now,* in the future the situation may change and=20 TLS 1.2 may become weak/insecure while TLS 1.3 will remain secure. > Similarly, this argument implies organizations are rational actors that > evaluate these protocols based on the security strength. If they are inde= ed > rational, then the presumed weakness of PKCS#1v1.5 (and not TLS 1.2 vs TL= S > 1.3) would naturally exert a pressure on organizations to replace this > hardware, in order to leverage the better security of RSA-PSS. Thus the > existence within TLS1.3 does not actually meaningfully change the calculu= s > for security or for organizational pressure. c). non-use of TLS 1.3 by an organisation is something that will be easy to notice by an auditor, use of PKCS#1 v1.5 with client certificates is=20 not something that I would bet any money to be noticed by a typical auditor (e.g. PCI-DSS never went into such details) > Setting aside for a second arguments about whether RSA-PSS vs PKCS#1v1.5 > (in the context of client certificates) is a significant security > differentiator, or whether the security properties of TLS1.2 vs TLS1.3 is > are significant enough to exert pressure, it also seemingly overlooks the > privacy value afforded by TLS1.3's encryption. it doesn't, because deploying renegotiation in TLS 1.2 to encrypt client certificates is neither complex nor unheard-of > If we're trying to make cost-based assumptions here about what pressures > will be exerted, I feel like we have ample evidence from the TLS 1.3 > adoption that benefits in security and privacy do not actually exert > pressures on organizations to change, because the incremental value they > provide is outweighed by the costs. The middlebox challenges are a > case-study in this. This draft attempts to reduce those costs, making it > possible to take advantage of those incremental improvements made in 1.3. middleboxes affect many connections, client certificates are used by small minority of connections in very special deployments > The distinction isn't going from good to going from bad, which seems to b= e > implied by arguing against adoption, it's going from worse (TLS1.2, with = no > privacy affordances and the ample considerations around the key schedules= ) > to something meaningfully better (TLS1.3), even if it's not ideal. my argument is that TLS 1.2 is only potentially worse, not provably worse,= =20 at least now --=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 Dec 12 08:26:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEF412098A for ; Thu, 12 Dec 2019 08:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=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 kein1p_S5lZB for ; Thu, 12 Dec 2019 08:26:44 -0800 (PST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.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 CA056120975 for ; Thu, 12 Dec 2019 08:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576168002; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iZ/MFYFxEtt4R6T6Tfl6aMXYf6fR+Dh837cylwkoY4w=; b=VL5yEuPNmD64rFkE7XE6b3mSZeuau9oTH9feM633bW0aWgRhdBAT6JsffxQgZ3K6fH03e5 Jp4XD4wCD5pOf/BjKJhK/yswqxWE3Iz0tSYuh5JmBkE0rIV/x9nT6dxnMTyCze+8aP0F/E k4rFpRBPo5yLDlJ9Ti9wSyL3lsDCTPg= 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-428-C5lfZLUMNvaCPcQw2DqhgQ-1; Thu, 12 Dec 2019 11:26:39 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2F32991212; Thu, 12 Dec 2019 16:26:38 +0000 (UTC) Received: from localhost (unknown [10.43.21.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A91CD5D9E2; Thu, 12 Dec 2019 16:26:37 +0000 (UTC) From: Hubert Kario To: David Benjamin Cc: Date: Thu, 12 Dec 2019 17:26:35 +0100 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.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.14 X-MC-Unique: C5lfZLUMNvaCPcQw2DqhgQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 12 Dec 2019 16:26:50 -0000 On Thursday, 12 December 2019 16:50:45 CET, David Benjamin wrote: > On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: > >> On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: ... > > ... some TLS stacks don't > support renegotiation as a server at all (BoringSSL and Go). >=20 > ... Chrome does not accept it ... so because Google decided one thing, everybody has to bow down to it? and, sorry, but I consider the privacy angle a red herring, nobody is doing proper AppData padding, so the connections leak privacy information in TLS= =20 1.3 like a sieve too >> An endpoint MAY use renegotiation to provide confidentiality protection >> for client credentials offered in the handshake > > An HTTP/2 client speaks as soon as the handshake completes and does not k= now > whether the server is going to do this. if privacy was so important why nobody worked on it with HTTP/2? It's not= =20 like much has changed in the last 4 years on that front. sorry, I'm not buying that argument --=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 Dec 12 12:55:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57571200F3 for ; Thu, 12 Dec 2019 12:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.489 X-Spam-Level: X-Spam-Status: No, score=-17.489 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, T_FILL_THIS_FORM_SHORT=0.01, 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 (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 n78Z-Bor_Jvj for ; Thu, 12 Dec 2019 12:55:56 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83C9120024 for ; Thu, 12 Dec 2019 12:55:55 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id r27so3428426otc.8 for ; Thu, 12 Dec 2019 12:55:55 -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=0Y6lUfJG3J5KFmFy3cXHJOOvcD6DK8ibzbf3hOnWDvk=; b=LlOD228gqSMyVoPSE3AAkgQrAcIPkJXXHuljUYRVj1hm4fmmHJpbnePvPPvTTHc6yf G7+XiHbCSp9tteinSYTWNIkRSFdviciXCHJNmix0dZpsoB94E9y5y586GGjfQGdwHeOE 5xZomVOQlSbGwbMUcIBJ7DUnURS65ceN2epHxxFa36MMmPzrpraKMYMfuYJ19z+nGuxe XSYxURv4sI52Cmz5bXgHAkgc+tUOmdjpW31B6IhCOYnZJlSAqh1O09HnxnYC4RpLPDdY 8c+cSk2h2gm78xcjvCWNuKqzh7pzuaTOv6eULwQG4PYUgFkmxP6waM6MvCj8yqLnc/VI Zj3w== 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=0Y6lUfJG3J5KFmFy3cXHJOOvcD6DK8ibzbf3hOnWDvk=; b=jw7icjYkOmTlGizdl4lBLWKtSzFAbtSzdxo6P+9nUtvtaYO8WggiB/sePUxh7q4Mfc l63QQu5UpR3AxDfUzy8YFlPeBnuwcxGP6a7TtNnxi2Ik2ZRonG7yZ+evHVB58YF2kaNU Zk+7q5F1tB4RyTo9Z9cqxVFmEkMVbZbdFmjcg/RUgXeA5yyApfwH4wHuaZGvbqsz/j1z l50b3N8k5XwdxfrdXEKRt1HDLlcqbI9i138K0rWX/6EQ94Fzt8rH9kQADvj0PuQufbU3 HaBQaCQm/mGle1dz01v9lH+SpxRTGMtt6DiFacD1VTUlvPtdwpcRqyOG9v6g8pL6lqmX F2Ng== X-Gm-Message-State: APjAAAVj+eAKu1ioHmzMJeST9WCmM9m8dICRCpg3lQUlsxlCAm8BstpE OzY5ya8dBanvd0l6FejWwWTARtxUoFz1RvkdvQPXPA== X-Google-Smtp-Source: APXvYqwUDaH1HkQZ/hj+CQRALUilerrKnTBR9OcODc5WLO4a1IZTJznxcB0MG8tZ/kIacDorNjPL/ZzQNNm0/xipxFk= X-Received: by 2002:a9d:6a50:: with SMTP id h16mr10573627otn.267.1576184154776; Thu, 12 Dec 2019 12:55:54 -0800 (PST) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> In-Reply-To: From: Nick Harper Date: Thu, 12 Dec 2019 12:55:42 -0800 Message-ID: To: Hubert Kario Cc: David Benjamin , "" Content-Type: multipart/alternative; boundary="000000000000a5d620059987f854" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 12 Dec 2019 20:55:58 -0000 --000000000000a5d620059987f854 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 12, 2019 at 8:27 AM Hubert Kario wrote: > On Thursday, 12 December 2019 16:50:45 CET, David Benjamin wrote: > > On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: > > > >> On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: ... > > > > ... some TLS stacks don't > > support renegotiation as a server at all (BoringSSL and Go). > > > > ... Chrome does not accept it ... > > so because Google decided one thing, everybody has to bow down to it? > > and, sorry, but I consider the privacy angle a red herring, nobody is doi= ng > proper AppData padding, so the connections leak privacy information in TL= S > 1.3 > like a sieve too > Privacy isn't a red herring. There's a big difference between leaking ciphertext lengths vs leaking the user's name, email address, and other PII present in a client cert when the client cert is sent in the clear. > > >> An endpoint MAY use renegotiation to provide confidentiality protectio= n > >> for client credentials offered in the handshake > > > > An HTTP/2 client speaks as soon as the handshake completes and does not > know > > whether the server is going to do this. > > if privacy was so important why nobody worked on it with HTTP/2? It's not > like > much has changed in the last 4 years on that front. > HTTP/2 couldn't fix the issue with TLS 1.2 client certs being sent in the clear, but that problem was solved in TLS 1.3. Many of the problems not solved by H2 are being worked on in QUIC. It takes time to develop and deploy these protocols. Don't let perfect be the enemy of good. > > sorry, I'm not buying that argument > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a5d620059987f854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 12, 2019 at 8:27 AM Huber= t Kario <hkario@redhat.com> = wrote:
On Thursd= ay, 12 December 2019 16:50:45 CET, David Benjamin wrote:
> On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario <hkario@redhat.com> wrote:
>
>> On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote:= ...
>
> ... some TLS stacks don't
> support renegotiation as a server at all (BoringSSL and Go).
>
> ... Chrome does not accept it ...

so because Google decided one thing, everybody has to bow down to it?

and, sorry, but I consider the privacy angle a red herring, nobody is doing=
proper AppData padding, so the connections leak privacy information in TLS =
1.3
like a sieve too

Privacy isn't a re= d herring. There's a big difference between=C2=A0leaking ciphertext len= gths vs leaking the user's name, email address, and other PII present i= n a client cert when the client cert is sent in the clear.

>> An endpoint MAY use renegotiation to provide confidentiality prote= ction
>> for client credentials offered in the handshake
>
> An HTTP/2 client speaks as soon as the handshake completes and does no= t know
> whether the server is going to do this.

if privacy was so important why nobody worked on it with HTTP/2? It's n= ot
like
much has changed in the last 4 years on that front.
HTTP/2 couldn't fix the issue with TLS 1.2 client certs be= ing sent in the clear, but that problem was solved in TLS 1.3. Many of the = problems not solved by H2 are being worked on in QUIC. It takes time to dev= elop and deploy these protocols. Don't let perfect be the enemy of good= .

sorry, I'm not buying that argument
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a5d620059987f854-- From nobody Thu Dec 12 22:45:07 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8D912024E; Thu, 12 Dec 2019 22:45:06 -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 O153Mu9gpGC2; Thu, 12 Dec 2019 22:45:04 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 785B81200F7; Thu, 12 Dec 2019 22:45:01 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBD6irAo029797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Dec 2019 01:44:56 -0500 Date: Thu, 12 Dec 2019 22:44:53 -0800 From: Benjamin Kaduk To: Russ Housley Cc: Mirja =?iso-8859-1?Q?K=FChlewind?= , IETF TLS , Joe Salowey , IESG , draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, TLS Chairs Message-ID: <20191213064453.GF81833@kduck.mit.edu> References: <157608461199.11437.2061730930042533586.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-tls-tls13-cert-with-extern-psk-03=3A_=28with_COMMENT?= =?iso-8859-1?q?=29?= 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, 13 Dec 2019 06:45:06 -0000 On Wed, Dec 11, 2019 at 12:48:58PM -0500, Russ Housley wrote: > Mirja: > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Just a small thing to double-check: I wonder if this sentence would actually > > require an update to RFC8446: > > "TLS 1.3 does not permit the server to send a CertificateRequest > > message when a PSK is being used. This restriction is removed when > > the "tls_cert_with_extern_psk" extension is negotiated, allowing > > certificate-based authentication for both the client and the server." > > Or maybe it should be phrased differently, just: > > "If the "tls_cert_with_extern_psk" extension is negotiated, certificate-based > > authentication is allowed for both the client and the server." I guess it > > depends on what exactly is said in RFC8446 (and I didn't went and tried to find > > it). > > I do not believe that an update is needed or appropriate. First, the presence of this extension is an indication that this behavior will be different. Second, this is going to be an Experimental RFC, so it should not update a standards-track RFC. I agree; this is just an extension working as normal. (Not that I haven't asked the same question before for other documents....) -Ben > > And as a side note, it is usually recommended to provide the link to the > > registry in the IANA section (to make life for IANA easier) > > I will gladly add a reference to the registry: > > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml > > Russ > From nobody Fri Dec 13 00:15:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577571200C5; Fri, 13 Dec 2019 00:14:58 -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, 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 brma-6uFYKm3; Fri, 13 Dec 2019 00:14:56 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A071200EF; Fri, 13 Dec 2019 00:14:56 -0800 (PST) Received: from [129.192.10.3] (helo=[10.149.0.130]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ifg66-000267-L6; Fri, 13 Dec 2019 09:14:50 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: =?utf-8?Q?"Mirja_K=C3=BChlewind_=28IETF=29"?= Mime-Version: 1.0 (1.0) Date: Fri, 13 Dec 2019 09:04:49 +0100 Message-Id: <9F9CE876-B6EE-4229-B2E6-C43C8C229210@kuehlewind.net> References: <20191213064453.GF81833@kduck.mit.edu> Cc: Russ Housley , IETF TLS , Joe Salowey , IESG , draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, TLS Chairs In-Reply-To: <20191213064453.GF81833@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: iPhone Mail (17B111) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1576224896;6befbe05; X-HE-SMSGID: 1ifg66-000267-L6 Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-tls13-cert-with-extern-psk-03=3A_=28with_COMMENT=29?= 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, 13 Dec 2019 08:14:58 -0000 Okay that=E2=80=99s fine. It was just the wording of this one sentence that m= ade me ask this question. > Am 13.12.2019 um 07:45 schrieb Benjamin Kaduk : >=20 > =EF=BB=BFOn Wed, Dec 11, 2019 at 12:48:58PM -0500, Russ Housley wrote: >> Mirja: >>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> Just a small thing to double-check: I wonder if this sentence would actu= ally >>> require an update to RFC8446: >>> "TLS 1.3 does not permit the server to send a CertificateRequest >>> message when a PSK is being used. This restriction is removed when >>> the "tls_cert_with_extern_psk" extension is negotiated, allowing >>> certificate-based authentication for both the client and the server." >>> Or maybe it should be phrased differently, just: >>> "If the "tls_cert_with_extern_psk" extension is negotiated, certificate-= based >>> authentication is allowed for both the client and the server." I guess i= t >>> depends on what exactly is said in RFC8446 (and I didn't went and tried t= o find >>> it). >>=20 >> I do not believe that an update is needed or appropriate. First, the pre= sence of this extension is an indication that this behavior will be differen= t. Second, this is going to be an Experimental RFC, so it should not update= a standards-track RFC. >=20 > I agree; this is just an extension working as normal. (Not that I haven't= > asked the same question before for other documents....) >=20 > -Ben >=20 >>> And as a side note, it is usually recommended to provide the link to the= >>> registry in the IANA section (to make life for IANA easier) >>=20 >> I will gladly add a reference to the registry: >>=20 >> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensionty= pe-values.xhtml >>=20 >> Russ >>=20 >=20 From nobody Fri Dec 13 04:17:07 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DB6120130 for ; Fri, 13 Dec 2019 04:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 WvbPSU-t9qnu for ; Fri, 13 Dec 2019 04:17:04 -0800 (PST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.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 2E56612004A for ; Fri, 13 Dec 2019 04:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576239422; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S73lZC8qqvDFBjCSAl6G6iwSPxFoLlWKXIu/fBafkFk=; b=T72lz1qUJvsv7g2C05Ghja4u9vjo5+BRywW/JZMVJW3SoJoORuDvMccnanRUux7FtNsW4p VJBZzp3K02qXjbNGYPK7M6w1y5kBHg8YcGyhd9M1WeizMlRl0JfLnpVpn+TWPz9y3N7nIo AQT7nWE4iet2jVZVLVtj5KY5XSvqhxc= 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-103-nfBS1iMBNZmmrrsgruBo0g-1; Fri, 13 Dec 2019 07:16:58 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B72A3100550E; Fri, 13 Dec 2019 12:16:56 +0000 (UTC) Received: from localhost (unknown [10.43.21.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0F31D19C4F; Fri, 13 Dec 2019 12:16:55 +0000 (UTC) From: Hubert Kario To: Nick Harper Cc: David Benjamin , Date: Fri, 13 Dec 2019 13:16:54 +0100 MIME-Version: 1.0 Message-ID: <335a929b-a760-4768-b9fc-3649b3df2414@redhat.com> In-Reply-To: References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: nfBS1iMBNZmmrrsgruBo0g-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 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, 13 Dec 2019 12:17:07 -0000 On Thursday, 12 December 2019 21:55:42 CET, Nick Harper wrote: > On Thu, Dec 12, 2019 at 8:27 AM Hubert Kario wrote: > >> On Thursday, 12 December 2019 16:50:45 CET, David Benjamin wrote: >>> On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: >>> ... >>=20 >> so because Google decided one thing, everybody has to bow down to it? >>=20 >> and, sorry, but I consider the privacy angle a red herring,=20 >> nobody is doing >> proper AppData padding, so the connections leak privacy information in T= LS >> 1.3 >> like a sieve too >>=20 > > Privacy isn't a red herring. it is in discussion about signature mechanisms supported by legacy hardware > There's a big difference between leaking > ciphertext lengths vs leaking the user's name, email address, and other P= II > present in a client cert when the client cert is sent in the clear. which can be workarounded by doing client authentication in renegotiation handshake, the feature is there in the protocol, it's not IETF fault that some people decided to remove support for it >>>> ... >>> An HTTP/2 client speaks as soon as the handshake completes=20 >>> and does not ... >>> know >>> whether the server is going to do this. >>=20 >> if privacy was so important why nobody worked on it with HTTP/2? It's no= t >> like >> much has changed in the last 4 years on that front. >>=20 > > HTTP/2 couldn't fix the issue with TLS 1.2 client certs being sent in the > clear, again, renegotiation > but that problem was solved in TLS 1.3. Many of the problems not > solved by H2 are being worked on in QUIC. It takes time to develop and > deploy these protocols. and which part of QUIC addresses length hiding? Because either privacy is important, and it should be addressed by it, or mentioning privacy here is= =20 a red herring. > Don't let perfect be the enemy of good. no, it's not a question of "perfect" or "good", it's a question of putting legacy stuff in modern protocol or keeping it in legacy protocol, where its use is obvious and easy to audit. --=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 Fri Dec 13 14:06:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB85D120018 for ; Fri, 13 Dec 2019 14:06:00 -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=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUXP-mutL7pg for ; Fri, 13 Dec 2019 14:05:58 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEB01200D6 for ; Fri, 13 Dec 2019 14:05:58 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id c16so498485qko.6 for ; Fri, 13 Dec 2019 14:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MG7mp/okJMvqNm/TH0yeePfMTMyMwv+D+TQEbjYGCFs=; b=sYvXKYiLjJe+mG61l1wX4k08Z2+CzX+Gb/o+zr/eAfKOAYb947QDoXywn0EjD4KkZf HJO0R+nV5MuuXB9iKRMJey9hNeoMYA1+4dVQ+D6frYbB3AFEBxBGPj+z/zSmMzRQ8qQR bxP8sY9EB04gW4HXSlXSd+I0tvzxy+5a/KRrVJMWL+V2bDbWIzUH/3dSbI/NAug5Ka4H qAtI2HVFhAjTdHLH/FyUbAOajWlzb8UZ7DBOJxYix/jKX3vsQtWNNJtzjferV2iQVnwI 9Ud497gLNJ7FD731X5gvYXgBZ9vB1jZOB7um1dupW5jMPDlX94rlvyZajnJItK0zpGdp al3A== 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=MG7mp/okJMvqNm/TH0yeePfMTMyMwv+D+TQEbjYGCFs=; b=i3+pxS1gBD3XcIHyHqAiGzbw07SBogkKn4V0PS+EIaX8RoaAoY9jyXy9ccVyFRVjfs YX3W4ErgIpJAE7+zQT4tWY5ENEHD6BBI3c4cT4/iXSy0M7Aw5/R8fIUcGiTfmIVNXOux sOuQa6HD0QSZA3ThzvK037d4Mo/ggeDNn3DC/agaPQQYB0gWNGC7htLEGPvn82Px2azy mFYGXnxTvgC8K8GX9XGQtBLMBo1sdB9rgmHj8gvIsKNVJm3dEuQJ5zt4nBtWVHtOcV8y bPPXsHzKA/fsdYdXTEf/rx7yTM0joYNR5Xc/F7muGBA0JIDO6pNmq5b6rl/EKfKn2Cfa 3CMQ== X-Gm-Message-State: APjAAAVWeGO6ZLYs/Qck/xnNOP7Ks9cYJqD7yZCJVwEVRX4KADE3bjKi ksbVnRZAyTF4QHnk0vKxC/FqE7VWUHGtVzZeaJJM099Q X-Google-Smtp-Source: APXvYqzv4SaL+MaRtlCS1qppcGeecxrFG9mYWSZMoobJe/N2chew7BneJ3shAYOqKyqFEcMU397qVk0+744qU1Nko80= X-Received: by 2002:a05:620a:102e:: with SMTP id a14mr14997662qkk.159.1576274757624; Fri, 13 Dec 2019 14:05:57 -0800 (PST) MIME-Version: 1.0 References: <96B5CFA4-DF05-4BCF-A4FB-340DE2C890D2@sn3rd.com> <000001d5a0e5$2bac1330$83043990$@gmx.net> In-Reply-To: From: Richard Barnes Date: Fri, 13 Dec 2019 17:05:31 -0500 Message-ID: To: Eric Rescorla Cc: Hannes Tschofenig , TLS List Content-Type: multipart/alternative; boundary="000000000000ff3efd05999d1041" Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-semistatic-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: Fri, 13 Dec 2019 22:06:01 -0000 --000000000000ff3efd05999d1041 Content-Type: text/plain; charset="UTF-8" I am also in favor of advancing this document, for similar reasons to Hannes. On Fri, Nov 22, 2019 at 2:56 AM Eric Rescorla wrote: > +1 > > On Thu, Nov 21, 2019 at 7:30 PM wrote: > >> I am in favor of adopting this document as a starting point for further >> work. It fits nicely into the work on cTLS >> >> -----Original Message----- >> From: TLS On Behalf Of Sean Turner >> Sent: Friday, November 22, 2019 6:29 AM >> To: TLS List > >> Subject: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh >> >> At IETF 106 there was support for adoption of "Semi-Static Diffie-Hellman >> Key Establishment" for TLS 1.3 [0] as a WG item. To confirm this on the >> list: if you believe that the TLS WG should not adopt this as a WG item, >> then please let the chairs know by posting a message to the TLS list by >> 2359 >> UTC 13 December 2019 (and say why). >> >> NOTE: >> : If the consensus is that this draft should be adopted as a WG item, then >> this will necessarily result in a WG rechartering discussions. We would >> have gotten to this rechartering discussion anyway now that DTLS 1.3 is >> progressing out of the WG. >> >> Thanks, >> Joe and Sean >> >> [0] https://datatracker.ietf.org/doc/draft-rescorla-tls-semistatic-dh/ >> _______________________________________________ >> 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 > --000000000000ff3efd05999d1041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am also in favor of advancing this document, for similar= reasons to Hannes.

On Fri, Nov 22, 2019 at 2:56 AM Eric Rescorla <ekr@rtfm.com> wrote:
+1

=
On Thu, No= v 21, 2019 at 7:30 PM <Hannes.Tschofenig@gmx.net> wrote:
I am in favor of adopting this docum= ent as a starting point for further
work. It fits nicely into the work on cTLS

-----Original Message-----
From: TLS <tls= -bounces@ietf.org> On Behalf Of Sean Turner
Sent: Friday, November 22, 2019 6:29 AM
To: TLS List <tls@ietf= ..org>
Subject: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh

At IETF 106 there was support for adoption of "Semi-Static Diffie-Hell= man
Key Establishment" for TLS 1.3 [0] as a WG item.=C2=A0 To confirm this= on the
list: if you believe that the TLS WG should not adopt this as a WG item, then please let the chairs know by posting a message to the TLS list by 235= 9
UTC 13 December 2019 (and say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then<= br> this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld
have gotten to this rechartering discussion anyway now that DTLS 1.3 is
progressing out of the WG.

Thanks,
Joe and Sean

[0] https://datatracker.ietf.org/d= oc/draft-rescorla-tls-semistatic-dh/
_______________________________________________
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
--000000000000ff3efd05999d1041-- From nobody Sat Dec 14 16:45:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E96012004C for ; Sat, 14 Dec 2019 16:45:16 -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=2/+7qmkE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KQmW0o5c Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpL-c52NSkZE for ; Sat, 14 Dec 2019 16:45:13 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7402A120024 for ; Sat, 14 Dec 2019 16:45:13 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7992222274 for ; Sat, 14 Dec 2019 19:45:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 14 Dec 2019 19:45:12 -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=cSH/upKuVhDFXW57fRQdzcXs6+WrlmCMezgODQqpBTM=; b=2/+7qmkE KRTPkmomtFbmxN6KP3GsykzCbtbEbZJw/FBFWwaw50rAdjg5ZvpyOqgcImzmUC8g NWhMA/wumLfMcvxahpSkrbDYOo1OCVvoaCmF3FP3QMjKwbNcmCAp19pOBGzzJqjH IeIVDwf9ZP+tPOo7NYftscrzTkcuYl0dvf6FCQ6RfGNFaiAqQNijBSYa8CZRGo36 ekh4RJ7rQv0Wx+gkRVXBoieyb5kJe7LRuEZXgZCYLafD9RNMODMZPcZ5tTwzFVgi FuH2kNqWgGx3XF46E/muCeJsZrQI4SIRMB0tsaD1H9MwwUMGYUP4oi0ZvNpvTR52 gcOFxqWhZ5Z14Q== 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=cSH/upKuVhDFXW57fRQdzcXs6+Wrl mCMezgODQqpBTM=; b=KQmW0o5c4Z4NAhB0d2i8Bs5rMwC3oTztzU3JdHUeg7TAX /3JGI93b1zuyFIn9ArlvTILLDNgNMG9jjmib5oZDRz8NNp1XZNM46nsRxXtuT5nD M8MM0aU5R6HMnjeXx1+s3tKwOvVH7R/VySNhO98RcIUK+SEWKHbDWWCTCrR5B9G2 7ae/FPZGPwsLLWtX3/YRG2mAsf2NuBmSTYS0C9gD8hpEUCcbrdL4gUZnx/i2MHMJ tlidbWWd4YVw54CsM0+13ysDOgQk39/a3cfdo3OPmjwWCtt5ChDMfgbYuhLs9sZS 8H021+s70flzllXfFFJPo9+nznIW11s4G0FZwbV9A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddtvddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusgcupfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeeghedrjeelrdduudefrdduieehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id A43D78005A for ; Sat, 14 Dec 2019 19:45:11 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id C5DB09D385 for ; Sun, 15 Dec 2019 00:45:10 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============1331721584094866496==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191215004510.C5DB09D385@cloud.mnot.net> Date: Sun, 15 Dec 2019 00:45:10 +0000 (UTC) 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, 15 Dec 2019 00:45:16 -0000 --===============1331721584094866496== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * tlswg/certificate-compression (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Address Christian's comments regarding traffic analysis (by vasilvv) https://github.com/tlswg/certificate-compression/pull/31=20 1 pull requests merged: - Address Christian's comments regarding traffic analysis https://github.com/tlswg/certificate-compression/pull/31=20 * tlswg/draft-ietf-tls-ticketrequest (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Avoid seemingly-normative language https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/11=20 Repositories tracked by this digest: ----------------------------------- * 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 --===============1331721584094866496== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday December 15, 2019

Pull requests

tlswg/certificate-compression (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

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

1 pull requests merged:

Repositories tracked by this digest:

--===============1331721584094866496==-- From ratheesh.ksz@gmail.com Thu Dec 12 05:08:09 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F7E120915 for ; Thu, 12 Dec 2019 05:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.667 X-Spam-Level: * X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, SPOOFED_FREEMAIL=1.999, 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 8vPMGNG-pwmf for ; Thu, 12 Dec 2019 05:08:07 -0800 (PST) Received: from n7.nabble.com (n7.nabble.com [162.253.133.57]) by ietfa.amsl.com (Postfix) with ESMTP id E7A6212090E for ; Thu, 12 Dec 2019 05:08:07 -0800 (PST) Received: from n7.nabble.com (localhost [127.0.0.1]) by n7.nabble.com (Postfix) with ESMTP id 4573212016260 for ; Thu, 12 Dec 2019 06:17:47 -0700 (MST) Date: Thu, 12 Dec 2019 06:17:47 -0700 (MST) From: ratheesh To: tls@ietf.org Message-ID: <1576156667282-0.post@n7.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 15 Dec 2019 20:28:48 -0800 Subject: [TLS] TLS CCS message 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, 12 Dec 2019 13:09:41 -0000 Hi List, i have two questions: 1. As per TLS 1.2 RFC, CCS message is 1 byte with value 1. This should be encrypted with current cipher algorithm. My questions: when i captured packet, i could see that packet is not encrypted ( i could see value one). 2. TLS CCS packet is not encrypted with block cipher algorithms ? current cipher algorith is AES256-SHA256 in my case. but total size of CCS record is 6 bytes. -- Sent from: http://ietf.10.n7.nabble.com/IETF-TLS-f240755.html From nobody Sun Dec 15 20:34:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2B91200CC for ; Sun, 15 Dec 2019 20:34:05 -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 Rgh8wjx6WsIb for ; Sun, 15 Dec 2019 20:34:04 -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 35467120024 for ; Sun, 15 Dec 2019 20:34:04 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id e12so4295725qto.2 for ; Sun, 15 Dec 2019 20:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cumt3GXv1yB4mFZ+XUbbuOqoUcd6wstJAjEybejQesM=; b=vN7zquIBNsYSH65AaNI6UezMwczuh0MryQf9WAi9jw2ueBsjP3vecqJkpX4LZTobwW Rb1O9d0oYZd/QoJp3OsdJxlulb0H29cq1dLnMSlEuWAthmOFS6b2yZCSGW93JUUeJLbm 6YTtKI7Nw+e4DYR4byHMpq8Hg7e7JnMbvR8ilZi/tWAoYHLJlBdLh1iibI9P4k8o9ZBE 0580nQVGmngqBe0Tv/VIydbgtmm1h5kxxphCbFcifrAMOrH55M0wPmshrM2k7C6J8mGQ 9QGxameeYshrKUzmJGXYWJiAxH8FFIjO1ftD+DEXjzhlwKdbXjhYcEkd9bq69hVG0N3D frtQ== 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=Cumt3GXv1yB4mFZ+XUbbuOqoUcd6wstJAjEybejQesM=; b=R565FS4IENNFr/YdXnQuel89zAKrYdYo6SGqOtpo0y1Z06/yJAJAZ6GqBMRshbQzcn 8mvXl3FRPUo64IhpoZQSEUT8ruC33nAxy0dZazLuCFHC7q1/r5nnPkgWNrdhBAlWgn83 3nMKztgU6hPKoM+F2z/BwEim9R+ISqAowRl1pEYSRbhgyBXs0JRyR4b3V9y73oNavQht e0UI0hT+ncebFLJArsrnX96D8EdR26mhpJi+AFnCNWVDrzne+Q7PEV2pkLGo6SKK77tf 0jtUwszeVNA9yIadu5v0yPR1acUO8V/bdfu+L7HbAqOCTSu0Q0k0UnE+IT+bRWtfAuXl ko6Q== X-Gm-Message-State: APjAAAWWU2ARrs7oi8z47cD3oz8dKLK2X3Ar/0n6t4AsZNxubRVTUK1I jYGBDVFNAWdHqaRk/eFHmyzoi9EuemYvhkgcNBAWJp/q X-Google-Smtp-Source: APXvYqybUqNRbk+nGbNI66lsYn+1AUpNTQi98GCjRHYuIzQ0pIzOUzM6pmwcE5Ztm2vihqY7HlUCUUbpafqVB7cXRMI= X-Received: by 2002:ac8:5442:: with SMTP id d2mr11598174qtq.297.1576470843205; Sun, 15 Dec 2019 20:34:03 -0800 (PST) MIME-Version: 1.0 References: <1576156667282-0.post@n7.nabble.com> In-Reply-To: <1576156667282-0.post@n7.nabble.com> From: Joseph Salowey Date: Sun, 15 Dec 2019 20:33:52 -0800 Message-ID: To: ratheesh Cc: "" Content-Type: multipart/alternative; boundary="0000000000009bbf630599cab89c" Archived-At: Subject: Re: [TLS] TLS CCS message 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, 16 Dec 2019 04:34:06 -0000 --0000000000009bbf630599cab89c Content-Type: text/plain; charset="UTF-8" On Sun, Dec 15, 2019 at 8:28 PM ratheesh wrote: > Hi List, > > i have two questions: > > 1. As per TLS 1.2 RFC, CCS message is 1 byte with value 1. This should be > encrypted with current cipher algorithm. My questions: when i captured > packet, i could see that packet is not encrypted ( i could see value one). > > [Joe] If this is an initial handshake then the current cipher is null and the CCS is not encrypted. Encryption under the new cipher starts after the CCS message. > 2. TLS CCS packet is not encrypted with block cipher algorithms ? > cipher algorith is AES256-SHA256 in my case. but total size of CCS record > is > 6 bytes. > > > > > > -- > Sent from: http://ietf.10.n7.nabble.com/IETF-TLS-f240755.html > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009bbf630599cab89c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 15, 2019 at 8:28 PM rathe= esh <ratheesh.ksz@gmail.com> wrote:
Hi = List,

i have two questions:

1.=C2=A0 As per TLS 1.2 RFC,=C2=A0 CCS message is 1 byte with value 1. This= should be
encrypted with current cipher algorithm. My questions: when i captured
packet, i could see that packet is not encrypted ( i could see value one).<= br>

2.=C2=A0 TLS CCS packet is not encrypted with block cipher algorithms ?=C2= =A0
cipher algorith is AES256-SHA256 in my case. but total size of CCS record i= s
6 bytes.





--
Sent from: http://ietf.10.n7.nabble.com/IETF-TLS-f= 240755.html

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000009bbf630599cab89c-- From nobody Mon Dec 16 00:49:06 2019 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 4761C1200B5; Mon, 16 Dec 2019 00:49:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, Joseph Salowey , tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <157648614028.21609.11590282747489219348.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2019 00:49:00 -0800 Archived-At: Subject: [TLS] Barry Leiba's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT) 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: Mon, 16 Dec 2019 08:49:00 -0000 Barry Leiba has entered the following ballot position for draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From the shepherd writeup: There was concern raised that no one has reported implementation of this draft. The document has experimental status and that helped gain working group consensus to move it forward. ...and... The document has been reviewed and is supported by a few working group members. Not everyone in the group agrees that it is needed, This seems to imply that making it Experimental was a tactic to get it through the working group, and that concerns me a bit, though not enough to get to DISCUSS. I would be happier if there were some discussion in the document about how we would determine that it is, indeed, needed and useful, and when we might know that we should move it to Standards Track or else abandon it. Unfortunately, I suspect the answer to that is that we won’t know until we have quantum computers to mount attacks with, and that won’t be until certain places freeze over. I realize that preparing for maybe someday having quantum computers and what they might someday do is an exercise that not everyone will want to spend time working on and implementing. Some editorial comments, for which no reply is necessary: — Section 4 — Since the "tls_cert_with_extern_psk" extension is intended to be used only with initial handshakes, it MUST NOT be sent alongside the "early_data" extension. What happens if it is? Should this say that if they appear together the server aborts the handshake with an "illegal_parameter" alert? The hash algorithm MUST be set when the PSK is established, with a default of SHA-256. If it MUST be set, how is there a default? — Section 5 — If the server responds with a HelloRetryRequest message, then the client sends another ClientHello message as described in Section 4.1.2 of [RFC8446], including the same "tls_cert_with_extern_psk" extension as the original ClientHello message or abort the handshake. “, or aborts” (the comma closes the comma before “including”, and “aborts” is parallel to “sends”). — Section 5.1 — Most of those extension are not impacted in any way. This section discusses the impacts on the other extensions. Make it “those extensions”. And I would rephrase the second sentence as, “This section discusses the impacts on the extensions that are affected.” The "psk_key_exchange_modes" extension restricts both the use of PSKs offered in this ClientHello and those which the server might supply via a subsequent NewSessionTicket. “Use of” needs to be factored out of the “both” clause: NEW ...restricts the use of both the PSKs offered in this ClientHello and those that the server might supply... END — Section 7 — the external PSKs and searching the resulting small set of possibilities, rather than brute force searching the whole key space. “and search”, and “brute-force” The reasoning is explained in [K2016] (see Section 4.2). I suggest “The reasoning is explained in Section 4.2 of [K2016].” Otherwise it sounds like you should see 4.2 of this doc (and I think the html links will be generated better this way). This specification does not require that external PSK is known only “that the external PSK” From nobody Mon Dec 16 05:28:36 2019 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 946E312004E; Mon, 16 Dec 2019 05:28:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-tls-certificate-compression@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <157650291360.21504.14681246291594764273.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2019 05:28:33 -0800 Archived-At: Subject: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-certificate-compression-08: (with COMMENT) 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: Mon, 16 Dec 2019 13:28:34 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-tls-certificate-compression-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support publication of this document. One small question: 7.3. Registry for Compression Algorithms The procedures for requesting values in the Specification Required space are specified in [RFC8447]. RFC 8447 doesn't define "Specification Required", RFC 8126 does. Is there a more specific section of RFC 8447 that you can point to, as it is unclear to me which parts of RFC 8447 apply here. From nobody Mon Dec 16 10:10:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5882E120895 for ; Mon, 16 Dec 2019 10:10:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 7nUyyOxCbdxn for ; Mon, 16 Dec 2019 10:10:56 -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 DA7D612001A for ; Mon, 16 Dec 2019 10:10:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0A72A300B30 for ; Mon, 16 Dec 2019 13:10:54 -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 Av7V_nr3DDfi for ; Mon, 16 Dec 2019 13:10:51 -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 D32CB30046F; Mon, 16 Dec 2019 13:10:50 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <157648614028.21609.11590282747489219348.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2019 13:10:51 -0500 Cc: IESG , tls-chairs@ietf.org, draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <343163EC-6CFE-439A-AD90-8CBAA0A7CED0@vigilsec.com> References: <157648614028.21609.11590282747489219348.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Barry Leiba's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT) 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, 16 Dec 2019 18:10:57 -0000 Barry: You do not call for a response, but I want you to know that your = comments are being addressed. =20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >> =46rom the shepherd writeup: >=20 > There was concern raised that no one has reported implementation > of this draft. The document has experimental status and that helped > gain working group consensus to move it forward. >=20 > ...and... >=20 > The document has been reviewed and is supported by a few > working group members. Not everyone in the group agrees > that it is needed, >=20 > This seems to imply that making it Experimental was a tactic to get it = through > the working group, and that concerns me a bit, though not enough to = get to > DISCUSS. I would be happier if there were some discussion in the = document > about how we would determine that it is, indeed, needed and useful, = and when we > might know that we should move it to Standards Track or else abandon = it. >=20 > Unfortunately, I suspect the answer to that is that we won=E2=80=99t = know until we have > quantum computers to mount attacks with, and that won=E2=80=99t be = until certain places > freeze over. I realize that preparing for maybe someday having = quantum > computers and what they might someday do is an exercise that not = everyone will > want to spend time working on and implementing. I do not think we can add anything to the document. As was said on the = email thread on the TLS mail list, there is a plan to use it by the US = government. Others have not said one way or the other. > Some editorial comments, for which no reply is necessary: >=20 > =E2=80=94 Section 4 =E2=80=94 >=20 > Since the > "tls_cert_with_extern_psk" extension is intended to be used only = with > initial handshakes, it MUST NOT be sent alongside the "early_data" > extension. >=20 > What happens if it is? Should this say that if they appear together = the server > aborts the handshake with an "illegal_parameter" alert? I added a paragraph: If the client includes both the "tls_cert_with_extern_psk" extension and the "early_data" extension, then the server MUST terminate the connection with an "illegal_parameter" alert. > The hash algorithm MUST > be set when the PSK is established, with a default of SHA-256. >=20 > If it MUST be set, how is there a default? This is stated in RFC 8446 in Section 4.2.11. > =E2=80=94 Section 5 =E2=80=94 >=20 > If the server responds with a HelloRetryRequest > message, then the client sends another ClientHello message as > described in Section 4.1.2 of [RFC8446], including the same > "tls_cert_with_extern_psk" extension as the original ClientHello > message or abort the handshake. >=20 > =E2=80=9C, or aborts=E2=80=9D (the comma closes the comma before = =E2=80=9Cincluding=E2=80=9D, and =E2=80=9Caborts=E2=80=9D is > parallel to =E2=80=9Csends=E2=80=9D). Fixed. > =E2=80=94 Section 5.1 =E2=80=94 >=20 > Most of those extension are > not impacted in any way. This section discusses the impacts on the > other extensions. >=20 > Make it =E2=80=9Cthose extensions=E2=80=9D. And I would rephrase the = second sentence as, =E2=80=9CThis > section discusses the impacts on the extensions that are affected.=E2=80= =9D I suggest: Section 4 lists the extensions that are required to accompany the "tls_cert_with_extern_psk" extension. Most of those extension are used in the usual manner. This section discusses the impacts on the extensions that are affected the presence of the "tls_cert_with_extern_psk" extension. > The "psk_key_exchange_modes" extension restricts both the > use of PSKs offered in this ClientHello and those which the server > might supply via a subsequent NewSessionTicket. >=20 > =E2=80=9CUse of=E2=80=9D needs to be factored out of the =E2=80=9Cboth=E2= =80=9D clause: > NEW > ...restricts the use of both the PSKs offered in this ClientHello > and those that the server might supply... > END I accepted you better wording. > =E2=80=94 Section 7 =E2=80=94 >=20 > the external PSKs and searching the resulting small set of > possibilities, rather than brute force searching the whole key = space. >=20 > =E2=80=9Cand search=E2=80=9D, and =E2=80=9Cbrute-force=E2=80=9D I accepted you better wording. > The reasoning is explained in [K2016] (see > Section 4.2). >=20 > I suggest =E2=80=9CThe reasoning is explained in Section 4.2 of = [K2016].=E2=80=9D Otherwise it > sounds like you should see 4.2 of this doc (and I think the html links = will be > generated better this way). I accepted you better wording. > This specification does not require that external PSK is known only >=20 > =E2=80=9Cthat the external PSK=E2=80=9D I added the missing article. Russ From nobody Mon Dec 16 13:07:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F255C120927; Mon, 16 Dec 2019 13:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBxZhMgtAMTH; Mon, 16 Dec 2019 13:07:52 -0800 (PST) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BBB12008D; Mon, 16 Dec 2019 13:07:52 -0800 (PST) Received: by mail-io1-f43.google.com with SMTP id c16so6647530ioh.6; Mon, 16 Dec 2019 13:07:52 -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:content-transfer-encoding; bh=JiAJDk8aVeaiIwGyVBCNyQ4axDdhvxaez6d35hiwKoY=; b=hxtWZtfJeeC56xwYotmY/0BIBUik1aCjH+NYF8LZwIgcYKWZb/BRfUYinJuuQcszte Tm4OAy/yS0UuJ5oopiu8pF+haFPyAaSTvoKiBkq6jufHv7uDuvDWsJGOsvo02/phjEku GzPkUpoyZFdhuDSwZ7CRKu9YY9NzoBpj0qQ2B8hWwerG3+w7Rgkjy5qCoIHb9zQD6aGM lTOnSBnI5Spq4WIl1VWIqf6cDeUeeE0J6bZegCousbBff2ESKDV2grddo70yspv9iW/h 4xYROJ4yuWp4FDNDVp00azfTgqT6eGyLPSqcCH728GltPEem1QctOtAL9uZoc7SIzcIc bBfw== X-Gm-Message-State: APjAAAV5DdeMAAnqXnWun23e80pcDZlTuBWyaHb+DXgXdxota4/a1x8T GGC7y2OcB+ILy5YCxGb/4AzFUYr0tXVojeMyYRkLu/T8 X-Google-Smtp-Source: APXvYqwjhTh6D3k4EHHip9IJsF00rT04l43EVYSNTAInCtaEvoRzKr7AWb69+cTjEho2+KJYcQ+w/W/VPQbGCr1HrZ0= X-Received: by 2002:a02:4e46:: with SMTP id r67mr3455991jaa.118.1576530471432; Mon, 16 Dec 2019 13:07:51 -0800 (PST) MIME-Version: 1.0 References: <157648614028.21609.11590282747489219348.idtracker@ietfa.amsl.com> <343163EC-6CFE-439A-AD90-8CBAA0A7CED0@vigilsec.com> In-Reply-To: <343163EC-6CFE-439A-AD90-8CBAA0A7CED0@vigilsec.com> From: Barry Leiba Date: Mon, 16 Dec 2019 16:07:40 -0500 Message-ID: To: Russ Housley Cc: IESG , tls-chairs , draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, IETF TLS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Barry Leiba's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT) 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, 16 Dec 2019 21:07:54 -0000 Thanks, Russ. And, yes, my comment about knowing when the experiment is over and what the results are... was something of a rant, and I agree that I can't think of anything useful to say. Sigh. Anyway, thanks for addressing my comments. Barry On Mon, Dec 16, 2019 at 1:11 PM Russ Housley wrote: > > Barry: > > You do not call for a response, but I want you to know that your comments= are being addressed. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > >> From the shepherd writeup: > > > > There was concern raised that no one has reported implementation > > of this draft. The document has experimental status and that helped > > gain working group consensus to move it forward. > > > > ...and... > > > > The document has been reviewed and is supported by a few > > working group members. Not everyone in the group agrees > > that it is needed, > > > > This seems to imply that making it Experimental was a tactic to get it = through > > the working group, and that concerns me a bit, though not enough to get= to > > DISCUSS. I would be happier if there were some discussion in the docum= ent > > about how we would determine that it is, indeed, needed and useful, and= when we > > might know that we should move it to Standards Track or else abandon it= . > > > > Unfortunately, I suspect the answer to that is that we won=E2=80=99t kn= ow until we have > > quantum computers to mount attacks with, and that won=E2=80=99t be unti= l certain places > > freeze over. I realize that preparing for maybe someday having quantum > > computers and what they might someday do is an exercise that not everyo= ne will > > want to spend time working on and implementing. > > I do not think we can add anything to the document. As was said on the e= mail thread on the TLS mail list, there is a plan to use it by the US gover= nment. Others have not said one way or the other. > > > Some editorial comments, for which no reply is necessary: > > > > =E2=80=94 Section 4 =E2=80=94 > > > > Since the > > "tls_cert_with_extern_psk" extension is intended to be used only with > > initial handshakes, it MUST NOT be sent alongside the "early_data" > > extension. > > > > What happens if it is? Should this say that if they appear together th= e server > > aborts the handshake with an "illegal_parameter" alert? > > I added a paragraph: > > If the client includes both the "tls_cert_with_extern_psk" extension > and the "early_data" extension, then the server MUST terminate the > connection with an "illegal_parameter" alert. > > > The hash algorithm MUST > > be set when the PSK is established, with a default of SHA-256. > > > > If it MUST be set, how is there a default? > > This is stated in RFC 8446 in Section 4.2.11. > > > =E2=80=94 Section 5 =E2=80=94 > > > > If the server responds with a HelloRetryRequest > > message, then the client sends another ClientHello message as > > described in Section 4.1.2 of [RFC8446], including the same > > "tls_cert_with_extern_psk" extension as the original ClientHello > > message or abort the handshake. > > > > =E2=80=9C, or aborts=E2=80=9D (the comma closes the comma before =E2=80= =9Cincluding=E2=80=9D, and =E2=80=9Caborts=E2=80=9D is > > parallel to =E2=80=9Csends=E2=80=9D). > > Fixed. > > > =E2=80=94 Section 5.1 =E2=80=94 > > > > Most of those extension are > > not impacted in any way. This section discusses the impacts on the > > other extensions. > > > > Make it =E2=80=9Cthose extensions=E2=80=9D. And I would rephrase the s= econd sentence as, =E2=80=9CThis > > section discusses the impacts on the extensions that are affected.=E2= =80=9D > > I suggest: > > Section 4 lists the extensions that are required to accompany the > "tls_cert_with_extern_psk" extension. Most of those extension are > used in the usual manner. This section discusses the impacts on the > extensions that are affected the presence of the > "tls_cert_with_extern_psk" extension. > > > The "psk_key_exchange_modes" extension restricts both the > > use of PSKs offered in this ClientHello and those which the server > > might supply via a subsequent NewSessionTicket. > > > > =E2=80=9CUse of=E2=80=9D needs to be factored out of the =E2=80=9Cboth= =E2=80=9D clause: > > NEW > > ...restricts the use of both the PSKs offered in this ClientHello > > and those that the server might supply... > > END > > I accepted you better wording. > > > =E2=80=94 Section 7 =E2=80=94 > > > > the external PSKs and searching the resulting small set of > > possibilities, rather than brute force searching the whole key space. > > > > =E2=80=9Cand search=E2=80=9D, and =E2=80=9Cbrute-force=E2=80=9D > > I accepted you better wording. > > > The reasoning is explained in [K2016] (see > > Section 4.2). > > > > I suggest =E2=80=9CThe reasoning is explained in Section 4.2 of [K2016]= .=E2=80=9D Otherwise it > > sounds like you should see 4.2 of this doc (and I think the html links = will be > > generated better this way). > > I accepted you better wording. > > > This specification does not require that external PSK is known only > > > > =E2=80=9Cthat the external PSK=E2=80=9D > > I added the missing article. > > Russ > > From nobody Mon Dec 16 17:51:03 2019 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 E83DB120972; Mon, 16 Dec 2019 17:50:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, Joseph Salowey , tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <157654745794.24469.3021505269125375774.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2019 17:50:57 -0800 Archived-At: Subject: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT) 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: Tue, 17 Dec 2019 01:50:58 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 7. The paragraphs that start with “In this extension, the external PSK preserves secrecy if the EC(DH) key agreement” …” and “In the future, if the (EC)DH key agreement ..” seem to be saying the same thing differently. * Section 7. It’s worth mentioning somewhere the obvious thing – how to generate, distribute, manage the external PSKs is out of scope for this specification. * Section 7. Per “TLS 1.3 [RFC8446] has received careful security analysis, and some informal reasoning shows that the addition of this extension does not introduce any security defects”, is there a citation for this “informal reasoning”? Otherwise, it’s a soft statement. * Editorial Nits: - Section 3. Typo. s/inclue/include/ - Section 5.1. Typo. s/extension are/extensions are/ - Section 5.1. /Most of those extension are not impacted in any way. This section discusses the impacts on the other extensions./Most of those extension are not impacted in any way by this specification. However, this section discusses the extensions that require additional consideration./ - Section 5.1. Typo. s/may be know to other partiers/may be known to other parties/ - Section 5.1. Typo. s/know to other parties/known to other parties/ - Section 7. Typo. s/that external PSK/that the external PSK/ From nobody Tue Dec 17 11:51:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688B81208E4 for ; Tue, 17 Dec 2019 11:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DrLiu6uH9bmp for ; Tue, 17 Dec 2019 11:51:37 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EC4120883 for ; Tue, 17 Dec 2019 11:51:37 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id z14so9296859qkg.9 for ; Tue, 17 Dec 2019 11:51:37 -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=ifSY0fFNIE5rh3L30rAqw7PgISODCEx9i0x1uOIZnWc=; b=JTaVf2Q7JZdq042pQFYNVeU0xeNrEL1llNzlTjCL6q5Sk6d7MSdEJCuZoOdzk555ww NGuOwPfRdHZM3IRs6EIP/+pyxaC4JG88KbCgZRdM6GfH4gSjYHN1yrO3IWTtKtozbHVC UgFpJqu/nZ7An/qQfS9qv05XoncAy7Wg6RhjI= 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=ifSY0fFNIE5rh3L30rAqw7PgISODCEx9i0x1uOIZnWc=; b=AJBlDtdt/FYSFVSBHcrjUvVY0plxIVY/HjX5IpR1KLw1SjmPIfqggJRbhKy3u40AmT ekUNEy5NAu95PVUMpPYsutTErZKuaW867uhfc8WiLxKGl/bXnfcTJlDJ25U/rewT7T1d wKBMM+QfiDtJO6T8odZiHlqGEOnl7rup/6H9tNDK+HSSHnTMUjAuhpdZQU6mLugLhpzU Lxzrd0/Va9NM1evgvb0k9Dp6w1jv48+zOJVo0eElOHd1j8hmE+Jq/wHudgzJdaK6wkgK ZYNf6gHIfvu2jx3EHYGCjex3jYx43uPrCSnaWwM39NkN4pO3DS7KM/2QWQMGqom+oHaP GR6Q== X-Gm-Message-State: APjAAAXEyootT6BFO6eLIqxPJ9pAQ/4Dwi+BgnKIc/mZyV6UEiXNFEIN Y8X2h1UFHdsOnawYUe35oyXqi9RQGI8= X-Google-Smtp-Source: APXvYqx2/u5NUkT8MOCMEKsWOWObbA2hr0hyJ4OnzxfL0YbiFNapC3uFewLgerUVlBrt7T7xyYvhzQ== X-Received: by 2002:a05:620a:15ec:: with SMTP id p12mr7004356qkm.247.1576612295829; Tue, 17 Dec 2019 11:51:35 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id f42sm8502379qta.0.2019.12.17.11.51.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 11:51:34 -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\)) Date: Tue, 17 Dec 2019 14:51:33 -0500 References: To: TLS List In-Reply-To: Message-Id: <1FFF1CBF-A08A-4B49-A946-9497AE94B512@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls 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, 17 Dec 2019 19:51:41 -0000 The adoption call ended on Friday. There is support for adopting and = working on this draft as a WG item. A few thought the draft = could/should be split into different drafts, but the chairs believe we = can split the drafts later if that is the consensus of the WG. NOTE: Technically, we will formally adopt this draft (i.e., push the = buttons in the datatracker) once the WG re-charter process completes = successfully. Thanks, > On Nov 21, 2019, at 00:36, Sean Turner wrote: >=20 > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the = TLS WG and the LAKE BOF, which is now a chartered WG [3]. After some = discussions, the ADs suggested [4] that the TLS WG consider whether this = draft be adopted as a TLS WG item. LAKE could then later = specify/refer/adopt/profile it, as appropriate. The authors revised cTLS = and presented the revised draft at IETF 106 [5]. At IETF 106 there was = support for adoption of cTLS as a WG item. To confirm this on the list: = if you believe that the TLS WG should not adopt this as a WG item, then = please let the chairs know by posting a message to the TLS list by 2359 = UTC 13 December 2019 (and say why). >=20 > NOTE: > : If the consensus is that this draft should be adopted as a WG item, = then this will necessarily result in a WG rechartering discussions. We = would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG. >=20 > Thanks, > Chris, Joe, and Sean >=20 > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] = https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk > [5] = https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-= tls-13-00.pdf From nobody Tue Dec 17 11:51:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323EB120D79 for ; Tue, 17 Dec 2019 11:51:46 -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 0Iu0E5Ow4AjH for ; Tue, 17 Dec 2019 11:51:43 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30410120883 for ; Tue, 17 Dec 2019 11:51:43 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id 21so6574040qky.4 for ; Tue, 17 Dec 2019 11:51:43 -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=rhinhTQFdjq0KJQWUe6fRqNSI1mXz+oR4eokczd8ChA=; b=LEtQN9nMoHRp+yuVHeD1ZDtVQ0mWxBXlv7qKplytb6BLS+55ILB+OOvnd2vjZ4dALC 9t+fbbcMd6HpXtjCLQDZt07cZPY8gXw8dRVPRnrYKMsP1W4wHcOzeagji+r4JtifS5Kg ZqKLoWI7wJ6lPuKpG8v5CK168riJOTWv1nvr4= 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=rhinhTQFdjq0KJQWUe6fRqNSI1mXz+oR4eokczd8ChA=; b=T/fVh9oykgb5ltlfwcLvK5cIZ58Wwfa1t+vv6Q2q9y1XdfAhWwERGgCdEg2LNel2HH +WQDiK158K/+EYpIr1JML/hXr5rjtBpdOnuD3DByv5ID+h46tCTm78HdSYLYLe1niJSb YyToTTj7KC9XSMyzDZn+vVJbS/4hHzAAHLJ/3s/hWPraOZC6YYmDNwJAavYW54WMf7w1 h6V/uyh4LMyUG6CH5TjLhuvyagVB3w+6JiBgN7xeV24VQmwJ8tMeA6RL/J+eJgFLGDe+ IscMFep4Ij3epiI9IlnYAY6BG4ttB5LTjr1eCerq6iunYNqabXrruDWuHe832unuA868 oW2w== X-Gm-Message-State: APjAAAUQikipcQ7A7fGyxC3N1+a0lC4ghq7vP9aa0vjtmiCHD6eYUtAD 7uytR4mcGYgYM4sYoXysnkG2cKhb2Ts= X-Google-Smtp-Source: APXvYqzt3/niZn81dW/V+hCxMJSoXYIrnVqiu7X0XoJqTJ+ExJMFvyCmA1t1U84MYai78RQiwiulBA== X-Received: by 2002:a05:620a:b19:: with SMTP id t25mr7126658qkg.82.1576612302105; Tue, 17 Dec 2019 11:51:42 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id f42sm8502379qta.0.2019.12.17.11.51.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 11:51:41 -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\)) Date: Tue, 17 Dec 2019 14:51:41 -0500 References: <96B5CFA4-DF05-4BCF-A4FB-340DE2C890D2@sn3rd.com> To: TLS List In-Reply-To: <96B5CFA4-DF05-4BCF-A4FB-340DE2C890D2@sn3rd.com> Message-Id: <16853BCE-1D41-4253-B68A-2F9D40FEE6CC@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-semistatic-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, 17 Dec 2019 19:51:49 -0000 The adoption call ended on Friday. There is support for adopting and = working on this draft as a WG item. Most of the support was received = during the WG session at IETF 106, but there was additional support = provided on the list. NOTE: Technically, we will formally adopt this draft once (i.e., push = the buttons in the datatracker) the WG re-charter process completes = successfully. Thanks, Chris, Joe, and Sean > On Nov 21, 2019, at 17:28, Sean Turner wrote: >=20 > At IETF 106 there was support for adoption of "Semi-Static = Diffie-Hellman Key Establishment" for TLS 1.3 [0] as a WG item. To = confirm this on the list: if you believe that the TLS WG should not = adopt this as a WG item, then please let the chairs know by posting a = message to the TLS list by 2359 UTC 13 December 2019 (and say why). >=20 > NOTE: > : If the consensus is that this draft should be adopted as a WG item, = then this will necessarily result in a WG rechartering discussions. We = would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG. >=20 > Thanks, > Joe and Sean >=20 > [0] https://datatracker.ietf.org/doc/draft-rescorla-tls-semistatic-dh/ From nobody Tue Dec 17 11:52:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275CF120E7F for ; Tue, 17 Dec 2019 11:52:11 -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 kHKWVRD6qjKc for ; Tue, 17 Dec 2019 11:52:09 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E0D120DFD for ; Tue, 17 Dec 2019 11:52:03 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id w127so9290006qkb.11 for ; Tue, 17 Dec 2019 11:52:03 -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=/1uiBYqTvllxv95pR9XGHf0zLCs00iu+4bNXYSYhe4A=; b=kc1V5jhzxKaIZxhIQFhP1CSafFUeJrUXmSjxCqG7TlgzKR2qcpuK685y15ggCsVWFN 8vI9LJCiQ2CCFfUpCfrjAKVa06tZXvsqQsXhMX1iCuMS5BRNxy1hmwXxmFgLhO1jSoK+ 6PJ/vkNGTgR4CX77hug11f2UNYjMa6m0DdaIs= 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=/1uiBYqTvllxv95pR9XGHf0zLCs00iu+4bNXYSYhe4A=; b=GCGZoYPhLYtPQYAJLcXe9UqpWqLmw9AVyTw92uGqcf4XOk6qoxj06nnACAGURbnkf0 lN7oOkxgy31xvliq3f2sg/GLE+p6tjEx41eFtr7fef4S8RihttoPDtMaOTS/ul6TEOP5 k6AQivP0O0xgpnxLTwsJcsOaEM9RUhi/qNpZVdbayK2mD+B+9yP5S4VDQJ+4e6CFAmjB T7kOelCfKrJoqgZ6USevOo4Qun9WR++F+LB0zF1U70lzQ5XmVt1acM6Uwgl9IER3/Wqa MpiCGtkDgsgTeqTPJIznroHj/t9GjFRpERuEIRPfSC0CXiUM9+pWDUXMicSE9fuQqkWn eNfA== X-Gm-Message-State: APjAAAUf1b8aL/Ds/VD5k+XcMAbnQNem03BUUW5pW/2xoljsNfSIP+ZN yRCv092QhRSi5S/rl5DOtboZ8kWgGOk= X-Google-Smtp-Source: APXvYqyKe/xo4c4lMhITuo8tW0L9LXm6c/SrHnUXj44RkH4SUzqipWpVOPmuXecF63VdgWunLaM+Jg== X-Received: by 2002:a37:4b93:: with SMTP id y141mr7225639qka.205.1576612321956; Tue, 17 Dec 2019 11:52:01 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id f42sm8502379qta.0.2019.12.17.11.52.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 11:52:01 -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\)) Date: Tue, 17 Dec 2019 14:52:01 -0500 References: To: TLS List In-Reply-To: Message-Id: <7DC8305B-E201-477A-ADD1-CF4FB8155F33@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing 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, 17 Dec 2019 19:52:14 -0000 The adoption call ended on Friday. There is support for adopting and = working on this draft as a WG item. There was one voice of possible = dissent, but it appears as if the rationale provided by the authors of = this draft swayed them enough to not oppose adoption. NOTE: Technically, we will formally adopt this draft (i.e., push the = buttons in the datatracker) once the WG re-charter process completes = successfully. Thanks, Chris, Joe, and Sean > On Nov 21, 2019, at 01:56, Sean Turner wrote: >=20 > At IETF 106 there was support for adoption of "Batch Signing for TLS" = [0] as a WG item. To confirm this on the list: if you believe that the = TLS WG should not adopt this as a WG item, then please let the chairs = know by posting a message to the TLS list by 2359 UTC 13 December 2019 = (and say why). >=20 > NOTE: > : If the consensus is that this draft should be adopted as a WG item, = then this will necessarily result in a WG rechartering discussions. We = would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG. >=20 > Thanks, > Chris, Joe, and Sean >=20 > [0] https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/ From nobody Tue Dec 17 11:59:43 2019 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 C4696120077; Tue, 17 Dec 2019 11:59:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-tls-certificate-compression@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157661277479.26425.2644503135194355529.idtracker@ietfa.amsl.com> Date: Tue, 17 Dec 2019 11:59:34 -0800 Archived-At: Subject: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-certificate-compression-08: (with COMMENT) 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: Tue, 17 Dec 2019 19:59:35 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tls-certificate-compression-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3: Please add RFC citations for TLS 1.3 and TLS 1.2 on first use. From nobody Tue Dec 17 12:01:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAAC1208A5; Tue, 17 Dec 2019 12:01: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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=V3QivPUd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XyXQeaNR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68vYuIs-Yb8l; Tue, 17 Dec 2019 12:01:24 -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 60722120D9D; Tue, 17 Dec 2019 12:00:51 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id E29DC5D4; Tue, 17 Dec 2019 15:00:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 17 Dec 2019 15:00:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=4 02UKWpoYctOUW0sfMZw1RMIPRojWzUErCLVqu8WOmM=; b=V3QivPUd+AiIcCwd5 NZSUPePmt5gF78yn5xmqJAYQBRCrPuEc4WX9+o9QSyvvg7j8NPDUJ1tTBTfKwY35 5SqU3jWc5b4r2UBpeChBY1Q9EBIip6r02uNR/lmWhiFob49QoRwxScqHaRUYsMJ/ UmpmuiXKpThYUXOV/GZ+lF+e9rNaMWKsfuufoS1Q6d08eyD2hCs9CxjJHKXU/u5M YAHSwJxtIccQdAtrzLksd4wvTQTVviDABfMgzMUz4DHlajxNHkMdHqH9cgyw7tfG vdHiMpNPDOjjPHPnvI/0376Ixz0eVOpS7hohQb4I4WuIoCUNL0pgNOFXq4Gz9trt 92kng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=402UKWpoYctOUW0sfMZw1RMIPRojWzUErCLVqu8WO mM=; b=XyXQeaNRqkUAnHRRf27PUnbiScwLuRFlHoo0Gn5LwDyv33v6wu3YpwzNS cMs+EWV7RuR33013iRg7yrUfNvsDbx7FpZg7OjUK4Ptu5TT1KyxAys+/TwBSpmxo t/WOYAd2ZD8YvBfWHegz6InoMZZXA2Wgu5PJ3Rvc1XCPVte8OcYfmvVfxQ5fVGtZ bDK/wPtDF30MUN7bDs88smvU6FYlGcaxsTqDlleIEbfPwqaeRqkEgxvLIHT7N3lG LYMi5AGdX1IUlX95BDCNdZYiFDTASeSR/EnMASaIWqZuikuWhmtvSsnzC0Z4sxaF zgrkaJQQF/A7tl3HlzQx9vkq63OVA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddtjedgudeftdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdeltdenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id CB2DA8005B; Tue, 17 Dec 2019 15:00:48 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <157592941042.2180.9966958421606523994@ietfa.amsl.com> Date: Tue, 17 Dec 2019 15:00:46 -0500 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157592941042.2180.9966958421606523994@ietfa.amsl.com> To: Peter Yee X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-certificate-compression-07 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, 17 Dec 2019 20:01:36 -0000 Peter, thanks for your review. I entered a No Objection ballot. Alissa > On Dec 9, 2019, at 5:10 PM, Peter Yee via Datatracker = wrote: >=20 > Reviewer: Peter Yee > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-tls-certificate-compression-07 > Reviewer: Peter Yee > Review Date: 2019-12-09 > IETF LC End Date: 2019-12-09 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This draft specifies a means to negotiate and carry a = compressed > certificate chain for use in TLS 1.3. The document is clear and = well-written.=20 > It's ready for publication as a Standards Track RFC, although the = Secdir review > raises interesting points that ought to be considered before moving = forward.=20 >> =46rom a general perspective, this draft appears to be useful = extension to TLS > 1.3. [Ready] >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: None >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Dec 17 12:21:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485F0120125 for ; Tue, 17 Dec 2019 12:21:11 -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 xp7jG658EzXK for ; Tue, 17 Dec 2019 12:21:08 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C268120077 for ; Tue, 17 Dec 2019 12:21:08 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id x129so1916803qke.8 for ; Tue, 17 Dec 2019 12:21:08 -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=dxcs5R47u1hFc4h7B6d3NpP7Pbw8el69wA6mshBjbcE=; b=ljaYAHkcFUWOjKZllHIWb0k8fijrccok5soGoiAq2Z2orVtwQpz3BwDGiMiLxBxwfJ lUkENb5bqruWQKkBneyHUlwHOXc46aUUbFI5UNOgE10l1rJ+XppT2jn98LmW70aK43AR HSDUrs/tUFhYYvMkTcNRixn9tnEiYNjoYs3JI= 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=dxcs5R47u1hFc4h7B6d3NpP7Pbw8el69wA6mshBjbcE=; b=Zc5HI5AkfzhFhnZ4++9bnTzFBKfhSO8Vmp4TN9QoQC2nov57R8lR36BO85DoCkr0Fd dqm8py9193wohg9BpqQqk+0ct9rq3RhD1xHFK0SFEW62sUebUUreVH8+/s7QidqTtC+1 jK+e39KUl0pQAMw56DZ0aj0DV1M+2Qq9a5RXrDSdH80t4uWZowioBYEztE5lJv7ytMpc 0aTIFUkfF+Hl/pzwg2qSAAsDtNhVBQEVc6y2lnpig5kat9tkPuhWz/pDOiGB8aDY7rdo K3Y/TV7CyK1YL7vabic9Jb/I7KgHxfeQojecmVqwvkkek1AHsDce0BrjV5uZeEqY3HD0 HMzg== X-Gm-Message-State: APjAAAV7mhg7GupuoyRq+uHPvoMh9rzl85dI+EOM+UdAUtnhyZnbH4po aS9XRBmCdFG889vsFse4y3ucIq5RxeA= X-Google-Smtp-Source: APXvYqw2GcAE+mPX4O/f0JgctmW0UaosXqtKQ4aJKJv0QdkGlqNpjKJOOfejXQrgHmxTnFRFZD8aig== X-Received: by 2002:a37:98c6:: with SMTP id a189mr7163179qke.500.1576614066746; Tue, 17 Dec 2019 12:21:06 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id h1sm7251714qkc.38.2019.12.17.12.21.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 12:21:06 -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: Tue, 17 Dec 2019 15:21:05 -0500 References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> To: TLS List In-Reply-To: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> Message-Id: <77D49895-AC54-4FEA-AB71-76047748FC5D@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate 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, 17 Dec 2019 20:21:11 -0000 The WGLC ended on Friday. A couple of comments were received and need = to be addressed prior to progressing the draft to Ben. We will put the = document in the =E2=80=9CRevised I-D Needed=E2=80=9D state. Thanks, spt > On Nov 21, 2019, at 17:41, Sean Turner wrote: >=20 > All, >=20 > This is the working group last call for the "Deprecating MD5 and SHA-1 = signature hashes in TLS 1.2" draft available = https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. = Please review the document and send your comments to the list by 2359 = UTC on 13 December 2019. >=20 > Note the the GH repo for this draft can be found at: > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate >=20 > Cheers, >=20 > Joe, Chris, and Sean From nobody Tue Dec 17 23:48:07 2019 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 A39981208D8; Tue, 17 Dec 2019 23:47:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, Joseph Salowey , tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <157665527966.5054.14024150717281590041.idtracker@ietfa.amsl.com> Date: Tue, 17 Dec 2019 23:47:59 -0800 Archived-At: Subject: [TLS] Adam Roach's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT) 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, 18 Dec 2019 07:48:00 -0000 Adam Roach has entered the following ballot position for draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work on this document and its described mechanism. ID Nits reports: == Unused Reference: 'RFC2104' is defined on line 504, but no explicit reference was found in the text From nobody Wed Dec 18 02:48:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A064A120019; Wed, 18 Dec 2019 02:48:25 -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 (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XMx8FADuifT; Wed, 18 Dec 2019 02:48:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6B41200F6; Wed, 18 Dec 2019 02:48:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576666098; bh=94xx+9wv2xLCAtTO5/M9390vSB73QLuy7vN5a94a4C0=; h=X-UI-Sender-Class:From:To:Cc:References:In-Reply-To:Subject:Date; b=VDWNDRn49j5OKi1xN5pR6J+s0wQmnKvKTRraxIuFJwk9OTFADBKwp+9DmDea9K4Pz eJmn2GrreM6ocWr59YecGL7yrauHS4c4E1Rmf9pOTMxQw8iPOSsHGRifWiyUXcxAR5 m3WExVJe+0GGpQ/p0wi+RcM6n+igqDfhghC0SeP8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from E119863 ([195.149.223.43]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MtOGa-1hpIb61PMU-00upR9; Wed, 18 Dec 2019 11:48:18 +0100 From: To: , Cc: References: <19292_1574847682_5DDE44C2_19292_136_3_DA040352.6C797%dominique.barthel@orange.com> In-Reply-To: <19292_1574847682_5DDE44C2_19292_136_3_DA040352.6C797%dominique.barthel@orange.com> Date: Wed, 18 Dec 2019 11:48:16 +0100 Message-ID: <020901d5b590$a8789310$f969b930$@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020A_01D5B599.0A3FBA30" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDTg/c8JsCNYgxOeGZyBqYSGle3IanEDFtg Content-Language: en-us x-ts-tracking-id: c91d09f3-29bb-4708-9576-8dce9af185a1.0 x-checkrecipientchecked: true X-Provags-ID: V03:K1:IuH9AhlJCsgW+X2kz9hIldjT8R7FtjjodmxwYiMMQDxs9/zkvh/ lC9ULkXMumKBmRRX3Pp28UhaNHHk6dhIzXZuNX0R6zV8gwruiuU/iLwGNpq52mMDwzA3+s0 v191TiJITIDlgtTNKEocZMeFWsu6buzk+MWZqE4/oCR9UTkuYtRChIATfBcXyRwCsGXJVMp NGXy1uZzpifZUOkHrfyHA== X-UI-Out-Filterresults: notjunk:1;V03:K0:0k8OjFvjodY=:gT+YuCGDcQlqVJiVi5J0m6 uGFcZYRtgE1xJX5u9Ji8i9+mtAbD1X4Mo97jH3gHszaerjgZ0ayvYQLwubko4O4n1R8kqvlWW TV9vvg/3Vw+tmPAg8L9wSFss+yVoSaj7sOjWJyFQWp1EV5R4K2F+3QeHXiyW8uAxYldtK0F7N bKL5B/jK0X7gh9ab2oBuKeQxXOOsc9Y9et4doJh/52aAMgz+nO1Dhf7src/nlkU71a8L2JFR7 4TEJz3GeZ2SMNiETWQDJRRq/wiPi2PfRGTw9ZPnVhr7CLbCI62XVrCiN6sr+04WQqgPp/v7oF btp9WsNi2gi9/ZDfmLJkcJPcHFpqsMEf5F3rks1rtN2IhsBt6e9a4K6MVHOEV0/JG8XNKVEp3 zTF4gMfIu0sk4w0E3lmAnT17w0BQef2j6Puzxo+TeppNdXDFISVTM5rjPIIkjnKrx+dVHXrt9 fq/P1E7cFGwJyHG1fIAFDzRIJWybQWyOup3qjFWTXeRFNY+VYnGh84N/P2l0Fe9Z2wRzmDePN MJzgF0RLzB2Bwcg7Qt3JbKc5OJQMY9GQGWUQamuefWyfAH8tweeFy9mhhOPNRg15BI3HvvYM0 nfvqt/EAIwEvtZAkE2c3I7TI5XBmr7yVNo33558tqBOmai6zOtjO32vFqC608x+y5MZQeco+h fJks+8iGyAbUqg74SKQ1PYMVMvdSzP4xYTICxJIeh0Xau/KiQIzQ+KNvELf66rWoL5t5BOGbf rBLlo+UzFTfNNt6tua8Il7aUWPRVCyXYyXaDmlLRbJJSh6LWODtprfcQ0HCSxqLBaeqET4YAh /7NwQJTiy1tkjzyhvvp4RXGHxBUL+9E92G/ylXWSXPzWEH8NTEkkcXqWj1WR7cf65zTgauir6 +Ps4Ysm4zwnYI5Lw/66ltf5A5HShd/ZD26CdBbse2KuOo6R7FcueMTFhcxJ0/nTS1r+/SBVuz or2zyxE+74IMLKOh82kHmAAO3r9zX5pz3wcLbNsYr7F8ZbwsWQnrfKK/PR9E4fWNMl82kmmyi eSGZtbbt7CCU89cZzQa1ltB8Y3SecNXPqXQonmQqDYMG7QDZlw5z3Gq8JKTc8JSVxIAOWa7v6 IJMfZTgRSftWXBEUpvZNZggbeJRwmArrVayFug52VuMZWij6mXEXRV/B6eHLQfKv+Bji7+dwh xjSJkjmY72QRu3D+lx4ftvtlgR3K5I31r5goDAaORbRUDa7jCcVfr0m6DOGjio3UwIESMPBmf 4jabjW7/Yn9mKqGoLcDAXAKsZ/ueguHG/fqQqONlCznJnlUrEU9PnELtEaFA= Archived-At: Subject: Re: [TLS] SCHC header compression 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, 18 Dec 2019 10:48:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_020A_01D5B599.0A3FBA30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Dominique. This is a useful clarification. The way the document = is written does not made it clear that you indeed wanted to design a = more generic compression algorithm.=20 I don=E2=80=99t know whether there is still a chance for the LPWAN group = to restructure the document because there is pretty much nothing in = there that gives a reader the impression that the work has general = applicability.=20 =20 As you have seen from my post to the LPWAN list I have been wondering = about the overhead associated with SCHC because the LAKE community seems = to be concerned about every byte (on the wire, and on flash). = Unfortunately, there are no open source implementation in C available. = Maybe the code in your demo may provide some insight into the extra code = needed for this compression mechanism. This paper = https://biblio.ugent.be/publication/8613162/file/8613540.pdf tells me = that the overhead is roughly 6Kb of flash & 1Kb of RAM for the = compressor/decompressor plus some code for the rules (maybe 3Kb). The = paper focused on a different scenario and hence the results may vary = based on applications. As you can imagine I can already hear someone in = the LAKE group saying that they don=E2=80=99t have a SCHC stack on their = device and the extra ~9Kb is a complete no-go for them. So, I am a bit = careful about picking up a heavy cannon for removing a few fields in the = handshake. After all, the biggest message in a TLS handshake is the = Certificate message. The beauty of cTLS is that it does not change the = TLS 1.3 security properties nor does it require a lot of changes to the = implementations.=20 =20 As you may have seen in the cTLS draft we selectively pick fields that = can be omitted or replaced. It is not obvious to me how SCHC would be = integrated into a security protocol like TLS where you have to consider = the downgrading protection in the compression. I am interested to learn = more about your thoughts on this issue.=20 =20 I will re-read the draft to get a better understanding of the SCHC work = and its applicability to TLS.=20 =20 Ciao Hannes =20 From: TLS On Behalf Of = dominique.barthel@orange.com Sent: Wednesday, November 27, 2019 10:41 AM To: tls@ietf.org Cc: draft-ietf-lpwan-ipv6-static-context-hc@ietf.org Subject: [TLS] SCHC header compression =20 Hello Hannes, all, I'm a co-author of the SCHC draft = (https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc= /), which has passed IESG review. I may be unfortunate that the draft contains 3 distinct deliverables in = one document - a generic header compression mechanism, which uses a static context = for compression (Static Context Header Compression =3D SCHC) (Section 7) - a fragmentation protocol, which comes in 3 flavors, some of which have = ack/retransmissions built-in. (Section 8) - an application of the compression mechanism to compress UDP+IPv6 = headers (Section 10) This situation may lead to the conclusion that the header compression = and fragmentation work together, or that SCHC only applies to UDP+IPv6 = headers. The truth is different. The draft clearly states that fragmentation is optional: "If needed by = the underlying layer, the optional SCHC Fragmentation MAY be applied to = the SCHC Packet." Typically, some lower layers already have a fragmentation mechanism = (e.g. NB-IoT), and don't need another one. As another data point, we have a demo showing the benefits of = compressing CoAP headers, over a natively-IP network (LTE-m). We only = use the generic compression mechanism of the above-mentioned draft, and = we only use it to compress the CoAP headers. We believe that other protocols could benefit from the generic header = compression framework established by SCHC and could save design time and = code size by instantiating a set of SCHC compression rules for their own = headers. If you are interested, we'd be happy to tell you a bit more about SCHC, = either at an upcoming IETF meeting or during a dedicated conf call. Best regards, =20 Dominique > Hi Hannes, >=20 > My reading is that only compression/decompression applies to our case. > Fragmentation is optional and only concerns ipv6. I did not intent to = make > the comment at an inappropriate time, but if so, please consider it = when it > is appropriate. >=20 > Yours, > Daniel >=20 > On Thu, Nov 21, 2019 at 10:34 PM >; wrote: >=20 > Hi Daniel >=20 >=20 >=20 > Although inappropriate to discuss at the time of the adoption call I > wanted to point out that I looked at SCHC and was surprised to learn = that > it is more than a compression scheme but also includes a protocol for > adding reliability. In my reading is essentially a replacement for = 6lowpan. > Unfortunately, this design decision does not make it a well suited > mechanism for a generic compression mechanism. I am happy to get = convinced > otherwise. >=20 >=20 >=20 > Ciao >=20 > Hannes >=20 >=20 >=20 > *From:* TLS >; = *On Behalf Of *Daniel Migault > *Sent:* Friday, November 22, 2019 10:20 AM > *To:* Panos Kampanakis (pkampana) >; > *Cc:* TLS List >; > *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls >=20 >=20 >=20 > I clearly support the adoption of the work, but it seems important to > ensure cTLS integrates or remains in line with the work on compression = that > has been accomplished at the IETF - SCHC defined in lpwan might be a > starting point. It also seems important to me that cTLS defines = mechanisms > that could be reused as TLS 1.3 evolves. >=20 >=20 >=20 > Yours, >=20 > Daniel _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_020A_01D5B599.0A3FBA30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks, = Dominique. This is a useful clarification. The way the document is = written does not made it clear that you indeed wanted to design a more = generic compression algorithm.

I = don=E2=80=99t know whether there is still a chance for the LPWAN group = to restructure the document because there is pretty much nothing in = there that gives a reader the impression that the work has general = applicability.

 

As you have = seen from my post to the LPWAN list I have been wondering about the = overhead associated with SCHC because the LAKE community seems to be = concerned about every byte (on the wire, and on flash). Unfortunately, = there are no open source implementation in C available. Maybe the code = in your demo may provide some insight into the extra code needed for = this compression mechanism. This paper htt= ps://biblio.ugent.be/publication/8613162/file/8613540.pdf tells me = that the overhead is roughly 6Kb of flash & 1Kb of RAM for the = compressor/decompressor plus some code for the rules (maybe 3Kb). The = paper focused on a different scenario and hence the results may vary = based on applications. As you can imagine I can already hear someone in = the LAKE group saying that they don=E2=80=99t have a SCHC stack on their = device and the extra ~9Kb is a complete no-go for them. So, I am a bit = careful about picking up a heavy cannon for removing a few fields in the = handshake. After all, the biggest message in a TLS handshake is the = Certificate message. The beauty of cTLS is that it does not change the = TLS 1.3 security properties nor does it require a lot of changes to the = implementations.

 

As you may = have seen in the cTLS draft we selectively pick fields that can be = omitted or replaced. It is not obvious to me how SCHC would be = integrated into a security protocol like TLS where you have to consider = the downgrading protection in the compression. I am interested to learn = more about your thoughts on this issue.

 

I will = re-read the draft to get a better understanding of the SCHC work and its = applicability to TLS.

 

Ciao
Hannes

 

From: TLS = <tls-bounces@ietf.org> On Behalf Of = dominique.barthel@orange.com
Sent: Wednesday, November 27, = 2019 10:41 AM
To: tls@ietf.org
Cc: = draft-ietf-lpwan-ipv6-static-context-hc@ietf.org
Subject: = [TLS] SCHC header compression

 

Hello Hannes, =
all,
I'm a =
co-author of the SCHC draft (https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-c=
ontext-hc/), which has passed IESG =
review.
I may be =
unfortunate that the draft contains 3 distinct deliverables in one =
document
- =
a generic header compression mechanism, which uses a static context for =
compression (Static Context Header Compression =3D SCHC) (Section =
7)
- =
a fragmentation protocol, which comes in 3 flavors, some of which have =
ack/retransmissions built-in. (Section =
8)
- an =
application of the compression mechanism to compress UDP+IPv6 headers =
(Section 10)
This situation may lead to the conclusion that the =
header compression and fragmentation work together, or that SCHC only =
applies to UDP+IPv6 headers.
The truth is =
different.
The =
draft clearly states that fragmentation is optional: "If needed by =
the underlying layer, the optional SCHC Fragmentation MAY be applied to =
the SCHC Packet."
Typically, some lower layers already have a =
fragmentation mechanism (e.g. NB-IoT), and don't need another =
one.
As another =
data point, we have a demo showing the benefits of compressing CoAP =
headers, over a natively-IP network (LTE-m). We only use the generic =
compression mechanism of the above-mentioned draft, and we only use it =
to compress the CoAP headers.
We believe that other protocols could benefit from =
the generic header compression framework established by SCHC and could =
save design time and code size by instantiating a set of SCHC =
compression rules for their own =
headers.
If you =
are interested, we'd be happy to tell you a bit more about SCHC, either =
at an upcoming IETF meeting or during a dedicated conf =
call.
Best =
regards,
 
Dominique
> Hi Hannes,
> 
> My reading is that only =
compression/decompression applies to our =
case.
> =
Fragmentation is optional and only concerns ipv6. I did not intent to =
make
> the =
comment at an inappropriate time, but if so, please consider it when =
it
> is =
appropriate.
> 
> Yours,
> Daniel
> 
> On Thu, Nov 21, 2019 at 10:34 PM <Hannes.Tschofenig@gmx.ne=
t>; wrote:
> 
> Hi Daniel
> 
> 
> 
> Although inappropriate to discuss at the time =
of the adoption call I
> wanted to point out that I looked at SCHC and =
was surprised to learn that
> it is more than a compression scheme but also =
includes a protocol for
> adding reliability. In my reading is =
essentially a replacement for 6lowpan.
> Unfortunately, this design decision does not =
make it a well suited
> mechanism for a generic compression =
mechanism. I am happy to get convinced
> otherwise.
> 
> 
> 
> Ciao
> 
> Hannes
> 
> 
> 
> *From:* TLS <tls-bounces@ietf.org>;=
 *On Behalf Of *Daniel Migault
> *Sent:* Friday, November 22, 2019 10:20 =
AM
> *To:* =
Panos Kampanakis (pkampana) <pkampana@cisco.com>;
> *Cc:* TLS List =
<tls@ietf.org>;
> *Subject:* Re: [TLS] =
Adoption call for =
draft-rescorla-tls-ctls
> 
> 
> 
> I clearly support the adoption of the work, =
but it seems important to
> ensure cTLS integrates or remains in line =
with the work on compression that
> has been accomplished at the IETF - SCHC =
defined in lpwan might be a
> starting point. It also seems important to me =
that cTLS defines mechanisms
> that could be reused as TLS 1.3 =
evolves.
> 
> 
> 
> Yours,
> 
> Daniel
___________________________________________________=
______________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir =
des informations confidentielles ou privilegiees et ne doivent =
donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le =
signaler
a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce message =
a ete altere, deforme ou falsifie. =
Merci.
 
This message and its attachments may contain =
confidential or privileged information that may be protected by =
law;
they should =
not be distributed, used or copied without =
authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its =
attachments.
As =
emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank =
you.
------=_NextPart_000_020A_01D5B599.0A3FBA30-- From nobody Wed Dec 18 08:24:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174F6120994 for ; Wed, 18 Dec 2019 08:23:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 aiHGeTylilq9 for ; Wed, 18 Dec 2019 08:23:55 -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 753AB120992 for ; Wed, 18 Dec 2019 08:23:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E4DF2300B34 for ; Wed, 18 Dec 2019 11:18:42 -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 5hVkISzYEGNV for ; Wed, 18 Dec 2019 11:18:41 -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 4C2273005C5; Wed, 18 Dec 2019 11:18:41 -0500 (EST) From: Russ Housley Message-Id: <0CF3F538-4A48-47A0-89AB-B157D5061C91@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A7FC92A0-B536-486A-86FB-BF5B20D23502" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Dec 2019 11:18:41 -0500 In-Reply-To: <157665527966.5054.14024150717281590041.idtracker@ietfa.amsl.com> Cc: IESG , tls-chairs@ietf.org, draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, IETF TLS To: Adam Roach References: <157665527966.5054.14024150717281590041.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT) 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, 18 Dec 2019 16:23:56 -0000 --Apple-Mail=_A7FC92A0-B536-486A-86FB-BF5B20D23502 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Adam: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work on this document and its described mechanism. > > ID Nits reports: > > == Unused Reference: 'RFC2104' is defined on line 504, but no explicit > reference was found in the text I added references in two place. Russ --Apple-Mail=_A7FC92A0-B536-486A-86FB-BF5B20D23502 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Adam:

---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thanks for the work on this = document and its described mechanism.

ID = Nits reports:

 =3D=3D Unused = Reference: 'RFC2104' is defined on line 504, but no explicit
    reference was found in the text

I= added references in two place.

Russ

= --Apple-Mail=_A7FC92A0-B536-486A-86FB-BF5B20D23502-- From nobody Wed Dec 18 10:20:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDD7120ABB for ; Wed, 18 Dec 2019 10:20:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2VgOvL3JwJqx for ; Wed, 18 Dec 2019 10:20:15 -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 DCF78120241 for ; Wed, 18 Dec 2019 10:20:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5FB4A300B29 for ; Wed, 18 Dec 2019 13:20:14 -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 BhQBFKvr4H4P for ; Wed, 18 Dec 2019 13:20:13 -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 EF6BD300AEE; Wed, 18 Dec 2019 13:20:12 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <77D49895-AC54-4FEA-AB71-76047748FC5D@sn3rd.com> Date: Wed, 18 Dec 2019 13:20:13 -0500 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <7AF01AC5-996C-402D-A78D-C10376D0365F@vigilsec.com> References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <77D49895-AC54-4FEA-AB71-76047748FC5D@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate 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, 18 Dec 2019 18:20:18 -0000 I support the progress of this document, but I have one tardy comment. I think that Section 6 should have some introductory text similar to the = text at the beginning of Section 7. Russ > On Dec 17, 2019, at 3:21 PM, Sean Turner wrote: >=20 > The WGLC ended on Friday. A couple of comments were received and need = to be addressed prior to progressing the draft to Ben. We will put the = document in the =E2=80=9CRevised I-D Needed=E2=80=9D state. >=20 > Thanks, >=20 > spt >=20 >> On Nov 21, 2019, at 17:41, Sean Turner wrote: >>=20 >> All, >>=20 >> This is the working group last call for the "Deprecating MD5 and = SHA-1 signature hashes in TLS 1.2" draft available = https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. = Please review the document and send your comments to the list by 2359 = UTC on 13 December 2019. >>=20 >> Note the the GH repo for this draft can be found at: >> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate >>=20 >> Cheers, >>=20 >> Joe, Chris, and Sean >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Dec 18 10:36:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7E8120AD8 for ; Wed, 18 Dec 2019 10:36:47 -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 3g-rjBLHKkol for ; Wed, 18 Dec 2019 10:36:45 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0: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 03A80120ACF for ; Wed, 18 Dec 2019 10:36:45 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id d62so1588118oia.11 for ; Wed, 18 Dec 2019 10:36: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=VIiRMJKLciQ7yAX48rsg2OlPJpTApF/vKqWSiLCMBaI=; b=BdSjp69Z/AEmocf/Wba5MLKI/NBccUPjBMh0xDSrgC1VL5SeNQ7vHB3sYi4JDDdVIi RUTLTNV2/mnuu6Jz9zg2ow2C3HbD91hrAb943JUpg+5Sw99RcwqPfcugNfq92HgjkbK1 ets+T7fuUn/cI0h2xuIBjkfjYJN44JS9lmFBkRluBjReGRF+ZV94RTbBoVmZg6aGocPF grf4rH8q1c+Z4CvX4njQcBag7xMURpVEJMLXJfQPw6hLoBwzaO93TfVQezupXpBCBERV L1Wo7ajp+rpaNs9Cj8LFatLy/ddq9MF5csKwUJFzE1Pftxqg41iLKE8oJ/l39XDHztju Q+5Q== 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=VIiRMJKLciQ7yAX48rsg2OlPJpTApF/vKqWSiLCMBaI=; b=be238mXbVCsQFYHfKO6BM2yYaSvpareWFvKw6u+uxAkovDXXrZKM8M4O/ZDDzNytq1 wE82KFb57y3t0vR9TB0yfFOua4BAn5fET7JXutchJrV78Fu04iMWBFmP7T9H4D8MKpIx 9pkjlSXpMnRyYzq1Slhx5RaqA6ZlFLsYI+u9qeR09l/V272TZJyELuJ1lfEMz24P0iFH WqADrgXc1Wesdc4qMjljaIMdToYYtOhUmwJFda5lfqlNqrS46YMAzyYQReiEMhC8pYxs Vz0Z+4ECPFY19MWlkEJ0nkhO4NhQtxOD4DScU8spHiLUXQdEJqu/q+xFQjecIwesGV4V epKQ== X-Gm-Message-State: APjAAAWDwNZyjHfE8xgc3CjgG8nijClCGOORQPSMnFEfBoZzLdo3KsuT txG2OW5zdHX3aYgZmJWoEiq25ecdP10S7i4YkXuvSrGI X-Google-Smtp-Source: APXvYqwOq29EYpS4fHulYQZ88+7w5E/62vIZkezQPwCZaT7AE5NYHcv8ZC39R1lKYTRAvHZSqcHNQvQCqlSRdn+wg6c= X-Received: by 2002:a54:4f04:: with SMTP id e4mr1108898oiy.111.1576694204294; Wed, 18 Dec 2019 10:36:44 -0800 (PST) MIME-Version: 1.0 References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <77D49895-AC54-4FEA-AB71-76047748FC5D@sn3rd.com> <7AF01AC5-996C-402D-A78D-C10376D0365F@vigilsec.com> In-Reply-To: <7AF01AC5-996C-402D-A78D-C10376D0365F@vigilsec.com> From: Kathleen Moriarty Date: Wed, 18 Dec 2019 13:36:08 -0500 Message-ID: To: Russ Housley Cc: Sean Turner , IETF TLS Content-Type: multipart/alternative; boundary="000000000000f76c140599feb951" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate 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, 18 Dec 2019 18:36:47 -0000 --000000000000f76c140599feb951 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 18, 2019 at 1:20 PM Russ Housley wrote: > I support the progress of this document, but I have one tardy comment. > > I think that Section 6 should have some introductory text similar to the > text at the beginning of Section 7. > Thank you, Russ. > > Russ > > > > On Dec 17, 2019, at 3:21 PM, Sean Turner wrote: > > > > The WGLC ended on Friday. A couple of comments were received and need > to be addressed prior to progressing the draft to Ben. We will put the > document in the =E2=80=9CRevised I-D Needed=E2=80=9D state. > > > > Thanks, > > > > spt > > > >> On Nov 21, 2019, at 17:41, Sean Turner wrote: > >> > >> All, > >> > >> This is the working group last call for the "Deprecating MD5 and SHA-1 > signature hashes in TLS 1.2" draft available > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. > Please review the document and send your comments to the list by 2359 UTC > on 13 December 2019. > >> > >> Note the the GH repo for this draft can be found at: > >> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate > >> > >> Cheers, > >> > >> Joe, Chris, and Sean > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen --000000000000f76c140599feb951 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 18, 2019 at 1:20 PM Russ = Housley <housley@vigilsec.com> wrote:
I s= upport the progress of this document, but I have one tardy comment.

I think that Section 6 should have some introductory text similar to the te= xt at the beginning of Section 7.


Russ


> On Dec 17, 2019, at 3:21 PM, Sean Turner <sean@sn3rd.com> wrote:
>
> The WGLC ended on Friday.=C2=A0 A couple of comments were received and= need to be addressed prior to progressing the draft to Ben.=C2=A0 We will = put the document in the =E2=80=9CRevised I-D Needed=E2=80=9D state.
>
> Thanks,
>
> spt
>
>> On Nov 21, 2019, at 17:41, Sean Turner <sean@sn3rd.com> wrote:
>>
>> All,
>>
>> This is the working group last call for the "Deprecating MD5 = and SHA-1 signature hashes in TLS 1.2" draft available https://datatracker.ietf.org/doc/draft-ietf-tls-= md5-sha1-deprecate/.=C2=A0 Please review the document and send your com= ments to the list by 2359 UTC on 13 December 2019.
>>
>> Note the the GH repo for this draft can be found at:
>> https://github.com/tlswg/draft-ie= tf-tls-md5-sha1-deprecate
>>
>> Cheers,
>>
>> Joe, Chris, and Sean
>
> _______________________________________________
> 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


--

Best regards,
Kathleen
--000000000000f76c140599feb951-- From nobody Wed Dec 18 12:14:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9291B120967 for ; Wed, 18 Dec 2019 12:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 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_LOW=-0.7, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtOz2D_DAfRd for ; Wed, 18 Dec 2019 12:14:30 -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 9F4E5120A77 for ; Wed, 18 Dec 2019 12:14:30 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBIJrQMT024891 for ; Wed, 18 Dec 2019 20:14:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=I0Fg8aWZ4mgAX8p7XRX9YQQXQ1uvim7hjfMzi9LHQ5w=; b=gNq+WTzDFmiLmLM73MgqdHOb+BjUgfqYKUGXFGMIAUAoh7Omt0evat3hh5tZGrYDJT0S Rs0FKPWgdiLUUSuqhxTU0+gUQ7qp2jEZGSSKmtvs2Otbolk7AZFxCRvp4N+/qfVATmew Hx9dkI1j2FplVMBVf1jI8s39wOwdq5w/9zbDicYtXpmh+og9m4HcvHxbIxdskNWMYaVb ah0qEbpPRZmbeCe2WFW2uA4ZD8oXTRqeQbIQiAaoClOlohoDO87iT4Su0lWSVxj9vVKS bzvE9/JbXsdWibv3i1WsWjgs6p4ld0BBRywUDsIooLotsKX3T1T3vDtMnSVJ+Vh0hHvE GA== 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 2wvqvd9p0y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 18 Dec 2019 20:14:30 +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 xBIJl81Q020430 for ; Wed, 18 Dec 2019 15:14:28 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint6.akamai.com with ESMTP id 2wvuxyv38c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 18 Dec 2019 15:14:28 -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; Wed, 18 Dec 2019 15:14:27 -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; Wed, 18 Dec 2019 15:14:28 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: Peter Gutmann on why RSA-PSS is worse than PKCS v1.5 Thread-Index: AQHVtd+/QO6+hp6SUE+OThTIsTv1UA== Date: Wed, 18 Dec 2019 20:14:27 +0000 Message-ID: <38E6D2D6-AF2F-4DEA-97B3-642B787CD0CB@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.117.187] Content-Type: multipart/alternative; boundary="_000_38E6D2D6AF2F4DEA97B3642B787CD0CBakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-18_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=399 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912180154 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-18_06:2019-12-17,2019-12-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 suspectscore=0 spamscore=0 mlxscore=0 malwarescore=0 clxscore=1015 priorityscore=1501 mlxlogscore=372 adultscore=0 bulkscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912180154 Archived-At: Subject: [TLS] Peter Gutmann on why RSA-PSS is worse than PKCS v1.5 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, 18 Dec 2019 20:14:32 -0000 --_000_38E6D2D6AF2F4DEA97B3642B787CD0CBakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHRob3NlIG5vdCBvbiB0aGUgY3J5cHRvZ3JhcGh5IG1haWxpbmcgbGlzdCwgaGVyZeKAmXMg c29tZSBob2xpZGF5IHJlYWRpbmcgZnJvbSB0aGUgaW5pbWl0YWJsZSBQZXRlciBHdXRtYW5uDQog ICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cubWV0emRvd2QuY29tL3BpcGVybWFpbC9jcnlwdG9n cmFwaHkvMjAxOS1Ob3ZlbWJlci8wMzU0NDkuaHRtbA0KDQo= --_000_38E6D2D6AF2F4DEA97B3642B787CD0CBakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5Gb3IgdGhvc2Ugbm90IG9uIHRoZSBjcnlwdG9ncmFwaHkgbWFpbGluZyBs aXN0LCBoZXJl4oCZcyBzb21lIGhvbGlkYXkgcmVhZGluZyBmcm9tIHRoZSBpbmltaXRhYmxlIFBl dGVyIEd1dG1hbm48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lm1ldHpkb3dkLmNvbS9waXBlcm1haWwvY3J5cHRv Z3JhcGh5LzIwMTktTm92ZW1iZXIvMDM1NDQ5Lmh0bWwiPg0KaHR0cHM6Ly93d3cubWV0emRvd2Qu Y29tL3BpcGVybWFpbC9jcnlwdG9ncmFwaHkvMjAxOS1Ob3ZlbWJlci8wMzU0NDkuaHRtbDwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_38E6D2D6AF2F4DEA97B3642B787CD0CBakamaicom_-- From nobody Wed Dec 18 16:20:19 2019 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 09B51120129; Wed, 18 Dec 2019 16:20:17 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157671481695.4973.7785415875095236674@ietfa.amsl.com> Date: Wed, 18 Dec 2019 16:20:17 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-11.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: Thu, 19 Dec 2019 00:20:17 -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 : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-11.txt Pages : 14 Date : 2019-12-18 Abstract: This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of a certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-11 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 19 05:31:55 2019 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 BF0E91207FB; Thu, 19 Dec 2019 05:31:48 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157676230869.27409.12346548799188905988@ietfa.amsl.com> Date: Thu, 19 Dec 2019 05:31:48 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-04.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: Thu, 19 Dec 2019 13:31:49 -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 : TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key Author : Russ Housley Filename : draft-ietf-tls-tls13-cert-with-extern-psk-04.txt Pages : 12 Date : 2019-12-19 Abstract: This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-extern-psk-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-cert-with-extern-psk-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 19 05:34:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E51112029C for ; Thu, 19 Dec 2019 05:34:31 -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 SAFD1W70qo4w for ; Thu, 19 Dec 2019 05:34:29 -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 9733512023E for ; Thu, 19 Dec 2019 05:34:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3FFE7300B00 for ; Thu, 19 Dec 2019 08:34:27 -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 1PvC2HmO9IFV for ; Thu, 19 Dec 2019 08:34:26 -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 11C0B3005DB for ; Thu, 19 Dec 2019 08:34:25 -0500 (EST) From: Russ Housley 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\)) Date: Thu, 19 Dec 2019 08:34:26 -0500 References: <157676230869.27409.12346548799188905988@ietfa.amsl.com> To: IETF TLS In-Reply-To: <157676230869.27409.12346548799188905988@ietfa.amsl.com> Message-Id: <57322C37-482B-4C4B-8FBF-D1A62DE173F4@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-04.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, 19 Dec 2019 13:34:32 -0000 This version addresses the comments that were received during IESG = Evaluation.=20 Russ > On Dec 19, 2019, at 8:31 AM, 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 : TLS 1.3 Extension for Certificate-based = Authentication with an External Pre-Shared Key > Author : Russ Housley > Filename : = draft-ietf-tls-tls13-cert-with-extern-psk-04.txt > Pages : 12 > Date : 2019-12-19 >=20 > Abstract: > This document specifies a TLS 1.3 extension that allows a server to > authenticate with a combination of a certificate and an external = pre- > shared key (PSK). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-04 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-exter= n-psk-04 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-cert-with-extern-= psk-04 >=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/ From nobody Thu Dec 19 05:54:49 2019 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 974D9120241; Thu, 19 Dec 2019 05:54:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, Joseph Salowey , tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157676368761.27454.108976243186682719.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2019 05:54:47 -0800 Archived-At: Subject: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-04: (with COMMENT) 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: Thu, 19 Dec 2019 13:54:47 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tls-tls13-cert-with-extern-psk-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Building on a point Barry made, I think it would be useful to distinguish in the document whether this spec is experimental because we are waiting for quantum computers to materialize, or whether it is experimental because current implementors want to gain more experience with it before standardization. That way if it does come back at some future point on the standards track the context for why it was experimental in the first place will be there. Please respond to the Gen-ART reviewer. From nobody Thu Dec 19 05:55:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A76120803; Thu, 19 Dec 2019 05:55:14 -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, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=QDfrkfkf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qqZTZIqB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO8Csi2e0oYo; Thu, 19 Dec 2019 05:55:12 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB832120241; Thu, 19 Dec 2019 05:55:09 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 22EF322128; Thu, 19 Dec 2019 08:55:09 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 19 Dec 2019 08:55:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=q Q8oshm2EVsPVB1Rax4uQIw/6EvImZSWSvYje7sBP4w=; b=QDfrkfkfRLmaKla1O ToXQF2aqno6u9m3k2dTDwLJecjcPUM/AWCOkcaiYIkyiLysLxwPbT1Sdnh9eHW+q cqJBauogKM3NT0zMMpNR6YCELWHYeedaB20AhlJSACEKlHNeFtgfoe1QQ/GD0ioe hFyrz6jN2d2o7S3mdpy4nH12xmVvxw/M9igqdTGlVhX1xclNQRluqJ3s4pxvP77z VxJmK3HIvtBDYpzBIMH6YS8JkPEyLP71E45HPDbY66dQXvViKxlGAHaTQqoVDGVv fexYMINMlTR5cxHMavCTC8arXPPOvvR8WVrTYjXlLvDa5I2UW5DxTFU2TI4qkvIO Ycbyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=qQ8oshm2EVsPVB1Rax4uQIw/6EvImZSWSvYje7sBP 4w=; b=qqZTZIqBYnl6uTxDiEC/ZablhuBDMZanekxOlw0EXbCFAXEux2IjqHwMm BjPXQdyd8Tx3Y0QX+2vHmc2nLxXCtKRbdx0SMerLJ/8sci4Kky9plHib6+HJ+2Wd voX59meCKkiJJyLIU8TiobrHGjJjJGcFMqbGqV8tzpj2JH/4tmVeTtQw6Zv5kbMw HGJ6PaY+IpELGD+ZF/y9bYxIZSzwWVlE8AfQYEeuKgdIqbmACTjLM3xtYs1SGyMQ tq4lzNZkucwaSgvVlTu1VVX9cCXAwq9gMFYf1QDBGWUa0P9CSw/JHPr/GLJqKtZ/ I9WWkOhhn4D6XZmcQocZoQLdTtjJw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdduuddgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgpdhirghnrgdrohhrghenucfkphepudejfedrfeekrdduudej rdeiheenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrd hinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 9CCF080062; Thu, 19 Dec 2019 08:55:08 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <157533115179.2256.879699004944357388@ietfa.amsl.com> Date: Thu, 19 Dec 2019 08:55:08 -0500 Cc: gen-art@ietf.org, last-call@ietf.org, tls@ietf.org, draft-ietf-tls-tls13-cert-with-extern-psk.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <961ACE56-8BF5-4AC5-AC78-2F9235BDE916@cooperw.in> References: <157533115179.2256.879699004944357388@ietfa.amsl.com> To: Ines Robles X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-tls13-cert-with-extern-psk-03 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, 19 Dec 2019 13:55:15 -0000 Ines, thanks for your review. I entered a No Objection ballot. Alissa > On Dec 2, 2019, at 6:59 PM, Ines Robles via Datatracker = wrote: >=20 > Reviewer: Ines Robles > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-tls-tls13-cert-with-extern-psk-?? > Reviewer: Ines Robles > Review Date: 2019-12-02 > IETF LC End Date: 2019-12-02 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > The document is well written. >=20 > This document specifies a TLS 1.3 extension permitting = certificate-based server > authentication to be combined with an external PSK as an input to the = TLS 1.3 > key schedule. >=20 > Major issues: Not found >=20 > Minor issues: Not found >=20 > Nits/editorial comments: >=20 > I think that would be nice to add in IANA Considerations a table = specifying the > fields of the TLS ExtensionType Values indicated in > = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml >=20 > Thank you for this document, >=20 > Ines. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Dec 19 07:08:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5412007C for ; Thu, 19 Dec 2019 07:08:47 -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, 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 lSUlBif6nujC for ; Thu, 19 Dec 2019 07:08:46 -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 2DA1812004C for ; Thu, 19 Dec 2019 07:08:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 337C3300B15 for ; Thu, 19 Dec 2019 10:08:44 -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 j30V4r9Er3ON for ; Thu, 19 Dec 2019 10:08:41 -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 9BA01300688; Thu, 19 Dec 2019 10:08:41 -0500 (EST) From: Russ Housley Message-Id: <86068E17-D072-4B53-BB68-3914A3F35D8E@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CAADB6BD-E74F-42ED-B885-C7957657A159" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Dec 2019 10:08:41 -0500 In-Reply-To: <961ACE56-8BF5-4AC5-AC78-2F9235BDE916@cooperw.in> Cc: IETF Gen-ART , IETF TLS To: Ines Robles References: <157533115179.2256.879699004944357388@ietfa.amsl.com> <961ACE56-8BF5-4AC5-AC78-2F9235BDE916@cooperw.in> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-tls13-cert-with-extern-psk-03 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, 19 Dec 2019 15:08:48 -0000 --Apple-Mail=_CAADB6BD-E74F-42ED-B885-C7957657A159 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ines: Thanks for taking the time to review the document. > Reviewer: Ines Robles > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-tls-tls13-cert-with-extern-psk-?? > Reviewer: Ines Robles > Review Date: 2019-12-02 > IETF LC End Date: 2019-12-02 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > The document is well written. >=20 > This document specifies a TLS 1.3 extension permitting = certificate-based server > authentication to be combined with an external PSK as an input to the = TLS 1.3 > key schedule. >=20 > Major issues: Not found >=20 > Minor issues: Not found >=20 > Nits/editorial comments: >=20 > I think that would be nice to add in IANA Considerations a table = specifying the > fields of the TLS ExtensionType Values indicated in > = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml = I am willing to add the table, but I observe that IANA was able to = correctly add the entry based on the words in the document. You will = see that they have assigned the number 33 to this extension. Russ --Apple-Mail=_CAADB6BD-E74F-42ED-B885-C7957657A159 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ines:

Thanks for taking the time to review the document.

Reviewer: Ines Robles
Review result: Ready

I am the assigned Gen-ART reviewer for this = draft. The General Area
Review Team (Gen-ART) reviews all = IETF documents being processed
by the IESG for the IETF = Chair.  Please treat these comments just
like any = other last call comments.

For more = information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: = draft-ietf-tls-tls13-cert-with-extern-psk-??
Reviewer: = Ines Robles
Review Date: 2019-12-02
IETF LC = End Date: 2019-12-02
IESG Telechat date: Not scheduled for = a telechat

Summary:

The document is well written.

This= document specifies a TLS 1.3 extension permitting certificate-based = server
authentication to be combined with an external PSK = as an input to the TLS 1.3
key schedule.

Major issues: Not found

Minor = issues: Not found

Nits/editorial = comments:

I think that would be nice to add = in IANA Considerations a table specifying the
fields of = the TLS ExtensionType Values indicated in
https://www.iana.org/assignments/tls-extensiontype-values/tls-e= xtensiontype-values.xhtml

I am willing to add the table, but I observe that = IANA was able to correctly add the entry based on the words in the = document.  You will see that they have assigned the number 33 to = this extension.

Russ

= --Apple-Mail=_CAADB6BD-E74F-42ED-B885-C7957657A159-- From nobody Thu Dec 19 07:13:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEC312007C for ; Thu, 19 Dec 2019 07:13:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z-5ojuJSNh1E for ; Thu, 19 Dec 2019 07:13:56 -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 265BB12004C for ; Thu, 19 Dec 2019 07:13:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0FFA1300AD5 for ; Thu, 19 Dec 2019 10:08: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 zV21XDj-btLj for ; Thu, 19 Dec 2019 10:08:49 -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 5BA8F300688; Thu, 19 Dec 2019 10:08:49 -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: <157676368761.27454.108976243186682719.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2019 10:08:50 -0500 Cc: IESG , TLS Chairs , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <2FF24421-69A0-43CB-B3C4-020457ABBCE5@vigilsec.com> References: <157676368761.27454.108976243186682719.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-04: (with COMMENT) 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, 19 Dec 2019 15:13:57 -0000 Alissa: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Building on a point Barry made, I think it would be useful to = distinguish in > the document whether this spec is experimental because we are waiting = for > quantum computers to materialize, or whether it is experimental = because current > implementors want to gain more experience with it before = standardization. That > way if it does come back at some future point on the standards track = the > context for why it was experimental in the first place will be there. There was a lot of discussion in the TLS WG, and several implementors = wanted to gain more experience with the specification before producing a = standards-track RFC. I am not sure that really helps if this document = comes back in the future. > Please respond to the Gen-ART reviewer. I have done so. Russ From nobody Thu Dec 19 10:06:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304C41209F8 for ; Thu, 19 Dec 2019 10:06: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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWB1G9wcrgTk for ; Thu, 19 Dec 2019 10:06:28 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CCF1209EA for ; Thu, 19 Dec 2019 10:06:27 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id e28so7220150ljo.9 for ; Thu, 19 Dec 2019 10:06:27 -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=qkDbm+c8i7EOireRFsi2Hht081XhOLKbVv7XKoPWUYc=; b=pxu2XTks7w2WrlvdijjJqT9vgHXY8ZBMC8NnoJ1sNJBNnlNqhlQ7tBsVfPhjNFU5XT OCzwUyTNVbyhcjsiV5BqM+HQwofkIVJetDGKrtqx/pPeSKXTvxK8V0zuVC7hunf/6TvU 4ibCqzeoMGOuXdnvBr+tRTO/m9k/6fxa7rFhSab5TVaUZjFkdLMMcbuQv92cle6y0goO bPS3DJWbk7qzA0O/ROdiHJRgxpTSIYRqZIL9CyoLhU2luO45i1v827KFt5HpFS0VzqV6 MchPOljdkojXowlVnxAaPS+MVB/Lf2eZg++sbmVK86Tv4lcIgxddVr658GsWnybk4z80 HgnQ== 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=qkDbm+c8i7EOireRFsi2Hht081XhOLKbVv7XKoPWUYc=; b=EcpZkbzcFTw6EbkMJpysJ4TD3PWbBeemHNYGfyzGmTKoFWe/Kw1Fd/YDGP+gyWlsEj ZtwzZe8aNBL/bFvyH+eDN4mmb0jFZwRcGeC2a27ej3/A7xdAK1G5lX5RWveowefqXgal t9f42ooTRz5OX5l5Hw45R/ctJDxmuJDDD/Rz5kaFWHaUUxRDlxDul74jicIHpzG8BXGh GzmdfEIYVanALbiImfxRts+9aYxqbUikCtUrdt+BXXz8DcQALoUwBrt3UTHSzuFBut0R MSIvhJ84uwhkjIm4zPxfVTuCh5AyGuqsoNo5el2bS2+nMFBiiLkULYfjuZyF9cbyVw/3 /Tfg== X-Gm-Message-State: APjAAAUVA4+u46w9lxN6wLaky4XUWeFwJZY56ZWXFKNuxIXFX35T/XMi EZCPYp+5kskf1LqzePedYwXIwRyBpY8pSoXws50hIg== X-Google-Smtp-Source: APXvYqyiPghlpXRjb0VP570/9WI3JfhNKvaR1zcAMLb6G1GL5jvY/u6f2Iuj1KVNO2jLciKtjGh6JhkEtw9HytrPt6o= X-Received: by 2002:a2e:88c5:: with SMTP id a5mr7167675ljk.201.1576778786172; Thu, 19 Dec 2019 10:06:26 -0800 (PST) MIME-Version: 1.0 References: <157676368761.27454.108976243186682719.idtracker@ietfa.amsl.com> In-Reply-To: <157676368761.27454.108976243186682719.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 19 Dec 2019 10:05:49 -0800 Message-ID: To: Alissa Cooper Cc: The IESG , tls-chairs , draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, "" Content-Type: multipart/alternative; boundary="00000000000070b558059a126b4e" Archived-At: Subject: Re: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-04: (with COMMENT) 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, 19 Dec 2019 18:06:30 -0000 --00000000000070b558059a126b4e Content-Type: text/plain; charset="UTF-8" On Thu, Dec 19, 2019 at 5:54 AM Alissa Cooper via Datatracker < noreply@ietf.org> wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-tls-tls13-cert-with-extern-psk-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Building on a point Barry made, I think it would be useful to distinguish > in > the document whether this spec is experimental because we are waiting for > quantum computers to materialize, or whether it is experimental because > current > implementors want to gain more experience with it before standardization. >From my perspective it's experimental because there was very little interest from implementors and we're trying to have more interest before we do standard track protocols. -Ekr That > way if it does come back at some future point on the standards track the > context for why it was experimental in the first place will be there. > > Please respond to the Gen-ART reviewer. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000070b558059a126b4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 19, 2019 at 5:54 AM Aliss= a Cooper via Datatracker <noreply@ie= tf.org> wrote:
Alissa Cooper has entered the following ballot position for
draft-ietf-tls-tls13-cert-with-extern-psk-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.= org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Building on a point Barry made, I think it would be useful to distinguish i= n
the document whether this spec is experimental because we are waiting for quantum computers to materialize, or whether it is experimental because cur= rent
implementors want to gain more experience with it before standardization. <= /blockquote>

From my perspective it's experimental b= ecause there was very little interest from implementors and we're tryin= g to have more interest before we do standard track protocols.

-Ekr

That
way if it does come back at some future point on the standards track the context for why it was experimental in the first place will be there.

Please respond to the Gen-ART reviewer.


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000070b558059a126b4e-- From nobody Thu Dec 19 10:40:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744CA120A7F; Thu, 19 Dec 2019 10:40:09 -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, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=CqG6pwbs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yRkLKXJU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmXTcPwENAPi; Thu, 19 Dec 2019 10:40:08 -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 E93CF120830; Thu, 19 Dec 2019 10:40:07 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E97F02268F; Thu, 19 Dec 2019 13:40:06 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 19 Dec 2019 13:40:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=1 48BhCAYXqVk1hzCvxA+9mOHQCkqpYIk0Q0rn7zqvbg=; b=CqG6pwbsF1+xNINZo CVWg09v4uxsEVY3t47Yr4c9fg5Ci8u6ZBeo3eru11ym6f7Rw0afhF2ZSAVoa5X5+ feT0fmzTsHnQuyOU3SV2DekcynYTPAYwtFQFto7ORZcH/ZU+des9ePVAtRxDiX0t 55mZOYTYT9yAdMiRzXhjcPIxDNb39KN2+69D1WoxFMKfFz2m99z6f6PtH0UMGoRG BIuSrg9DA8COykIDzYLdo7KeKhBkFU7+S5Y7z5LftJmS0n6484ljYP25ddUdawhr xmrhCuN2YqX+c/X0SgNKAe60qfUJLLq5uxJ+KGJiZ7JAwcoqK4ZmDAXflHSaFA+b 7oyAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=148BhCAYXqVk1hzCvxA+9mOHQCkqpYIk0Q0rn7zqv bg=; b=yRkLKXJUsm7FJZA8t4Hs/Dv3YPA7sPy4fWu3Lj+/IPeQ3y3wMF/My8X2A 9liMFYDMzDgkAmSXt9olwff2v2eP36J2YM3hWa3e/bMSWJm8HsmPDzdQNglSQph+ SJZXgrBta2bL+JJtrwNuehP5UOo9HGOvvVIv1Zmq0V2NYhOkuPp8JZ9jNdxZjN8V A4pPuM/fgUW3IOFg4Kl/1i0yhV8nnQ+8ffjn82qRzgeH6R8ZzJPi0pki9HsRW+tB 34n9OlLfGY/SQcy/EjpoEfNMVGlfV3cFhJpR4ec4AsjmBiL0/aAb7iGlPZQMd2Gn X5lYDnF4tLmtretmg+cM6BlpaapIg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdduuddguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecukfhppe dujeefrdefkedruddujedrieehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhs rgestghoohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 15D7180063; Thu, 19 Dec 2019 13:40:06 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <2FF24421-69A0-43CB-B3C4-020457ABBCE5@vigilsec.com> Date: Thu, 19 Dec 2019 13:40:05 -0500 Cc: IESG , TLS Chairs , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <08790F0C-96F3-4BF3-A4B2-80C696C2D6D2@cooperw.in> References: <157676368761.27454.108976243186682719.idtracker@ietfa.amsl.com> <2FF24421-69A0-43CB-B3C4-020457ABBCE5@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-04: (with COMMENT) 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, 19 Dec 2019 18:40:10 -0000 Hi Russ, > On Dec 19, 2019, at 10:08 AM, Russ Housley = wrote: >=20 > Alissa: >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Building on a point Barry made, I think it would be useful to = distinguish in >> the document whether this spec is experimental because we are waiting = for >> quantum computers to materialize, or whether it is experimental = because current >> implementors want to gain more experience with it before = standardization. That >> way if it does come back at some future point on the standards track = the >> context for why it was experimental in the first place will be there. >=20 > There was a lot of discussion in the TLS WG, and several implementors = wanted to gain more experience with the specification before producing a = standards-track RFC. I am not sure that really helps if this document = comes back in the future. I=E2=80=99m quite sure that it would, given that most of the time when = the IESG reviews a document that is being promoted from experimental to = standards track there is some discussion about why that is happening. = The more that can be done to explain the context for the original = classification, the better, because then readers do not have to guess. = Asking future reviewers to re-read the TLS mailing list from X number of = years ago is suboptimal compared to having one sentence in the document = that explains this. As currently written, I think people could conclude = that this document is experimental because large-scale quantum computers = do not yet exist. Best, Alissa >=20 >> Please respond to the Gen-ART reviewer. >=20 > I have done so. >=20 > Russ >=20 From nobody Thu Dec 19 14:36:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD091208B0 for ; Thu, 19 Dec 2019 14:36:35 -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 nu9sVAvNu6J5 for ; Thu, 19 Dec 2019 14:36: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 9796D1201DC for ; Thu, 19 Dec 2019 14:36:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 01763300AEE for ; Thu, 19 Dec 2019 17:36:32 -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 0hVrbUdDe4ye for ; Thu, 19 Dec 2019 17:36:30 -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 EDA593001CC; Thu, 19 Dec 2019 17:36:29 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <08790F0C-96F3-4BF3-A4B2-80C696C2D6D2@cooperw.in> Date: Thu, 19 Dec 2019 17:36:30 -0500 Cc: IESG , TLS Chairs , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <2770A95F-3E2C-4B00-8D5E-384652922055@vigilsec.com> References: <157676368761.27454.108976243186682719.idtracker@ietfa.amsl.com> <2FF24421-69A0-43CB-B3C4-020457ABBCE5@vigilsec.com> <08790F0C-96F3-4BF3-A4B2-80C696C2D6D2@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-04: (with COMMENT) 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, 19 Dec 2019 22:36:36 -0000 > On Dec 19, 2019, at 1:40 PM, Alissa Cooper wrote: >=20 > Hi Russ, >=20 >> On Dec 19, 2019, at 10:08 AM, Russ Housley = wrote: >>=20 >> Alissa: >>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Building on a point Barry made, I think it would be useful to = distinguish in >>> the document whether this spec is experimental because we are = waiting for >>> quantum computers to materialize, or whether it is experimental = because current >>> implementors want to gain more experience with it before = standardization. That >>> way if it does come back at some future point on the standards track = the >>> context for why it was experimental in the first place will be = there. >>=20 >> There was a lot of discussion in the TLS WG, and several implementors = wanted to gain more experience with the specification before producing a = standards-track RFC. I am not sure that really helps if this document = comes back in the future. >=20 > I=E2=80=99m quite sure that it would, given that most of the time when = the IESG reviews a document that is being promoted from experimental to = standards track there is some discussion about why that is happening. = The more that can be done to explain the context for the original = classification, the better, because then readers do not have to guess. = Asking future reviewers to re-read the TLS mailing list from X number of = years ago is suboptimal compared to having one sentence in the document = that explains this. As currently written, I think people could conclude = that this document is experimental because large-scale quantum computers = do not yet exist. Would adding this to the Introduction meet you needs? Several implementors wanted to gain more experience with this specification before producing a standards-track RFC. As a result, this specification is being published as an Experimental RFC to enable interoperable implementations and gain deployment and operational experience. Russ From nobody Thu Dec 19 15:56:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEA6120077 for ; Thu, 19 Dec 2019 15:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, 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 (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 sSkUYVWLSATo for ; Thu, 19 Dec 2019 15:56:34 -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 1120812001A for ; Thu, 19 Dec 2019 15:56:33 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id n25so5627671lfl.0 for ; Thu, 19 Dec 2019 15:56:33 -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=b3WmAZvtWvc6IIygPuymWtg11/EBGzQ3sxo/93AfM+A=; b=qEyJpQsjRzX2FVft1u+xbjMd0uIwdxbOS5qxlbCS5FOxByAIHnn8sEIzi3Y+u+CYHD ZU2BaYgCtTRtuDBiz9D3wV0FEo9cKpE0vLFPxL0jVJ07UOl4PMxmpzpTXgguZUka/GCn Y9GoG+armFy1QdsuUaYlx/3L6ixUMBMj2DpxvX4dhP5QLpg0WjdtvwJlSZPQcXAVvObD SGMieE9dbO0wR6C3MzXA00V2V6Llgem1RGVd4oAXDann6OYpzbmUIB1doheP5FobVlvT 7xRkrf2e2g7MpjBjq5cADbTQ8jjRE17qWim0h+WMb0D2HoniS4nHDPvX+h1EGBUBZKy5 QZbg== 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=b3WmAZvtWvc6IIygPuymWtg11/EBGzQ3sxo/93AfM+A=; b=bO6to4qxYyKZb5G9aVQ1oCu8raaU9i+fzph58KqHh2IUeZOv66M9uoWvBu7y8SMdo8 2efd6/Zi+fyKErFKSeWaBxCpHk85Aa+PATadrUhQ3aXeDp3MNqMDr75M9B6qA01frP97 2fhreCyDH2R1AOvyObR1SGfZDcsxgK9VU20JHflfIHzuPgenYBD4oGQwCxruMA+Ag80C GY7HwRNGTuMBD4dQAoVCiBKgZRCPv7RWU6cPWbytZlIvgqf4+Z4YDLAMR5SNxZmDjOey PKCjWlBsZznu8CcPk6ELONMEkjqJiix4aqAmWweBo4+6QjO19ifQ4JyU0T+BpPel/f7e 82jA== X-Gm-Message-State: APjAAAWR6Dxaxw3X988t2SnwAg2LnSmtrvkh4+v9zUpOBLKFDoM0z5/N 6NlpCTIfNTmM+B6y0+Me0x/u8sjkeVaJiAs+o3gnJA== X-Google-Smtp-Source: APXvYqzrMmpXcITES4uhpq5szCQsO7Q8aWOLLat0ksLSwQ5o17bRn0ytMXnmDsV+qqHcwGO2tjIIzTJW7N6gNg2jlQE= X-Received: by 2002:ac2:57cc:: with SMTP id k12mr7393181lfo.36.1576799791796; Thu, 19 Dec 2019 15:56:31 -0800 (PST) MIME-Version: 1.0 References: <157650291360.21504.14681246291594764273.idtracker@ietfa.amsl.com> In-Reply-To: <157650291360.21504.14681246291594764273.idtracker@ietfa.amsl.com> From: Victor Vasiliev Date: Thu, 19 Dec 2019 18:56:20 -0500 Message-ID: To: Alexey Melnikov Cc: The IESG , draft-ietf-tls-certificate-compression@ietf.org, Sean Turner , tls-chairs , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000796127059a174f20" Archived-At: Subject: Re: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-certificate-compression-08: (with COMMENT) 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, 19 Dec 2019 23:56:36 -0000 --000000000000796127059a174f20 Content-Type: text/plain; charset="UTF-8" I believe the intention was to refer to Section 17 of RFC 8447 < https://tools.ietf.org/html/rfc8447#section-17>, as it contains details of how Specification Required works with TLS-related registrations. I've sent out a PR to clarify that < https://github.com/tlswg/certificate-compression/pull/32/files>. On Mon, Dec 16, 2019 at 8:28 AM Alexey Melnikov via Datatracker < noreply@ietf.org> wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-tls-certificate-compression-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support publication of this document. One small question: > > 7.3. Registry for Compression Algorithms > > The procedures for requesting values in the Specification Required > space are specified in [RFC8447]. > > RFC 8447 doesn't define "Specification Required", RFC 8126 does. Is there a > more specific section of RFC 8447 that you can point to, as it is unclear > to me > which parts of RFC 8447 apply here. > > > --000000000000796127059a174f20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the intention was to refer to Section 17 of RFC = 8447 <https:/= /tools.ietf.org/html/rfc8447#section-17>, as it contains details of = how Specification Required works with TLS-related registrations.=C2=A0 I= 9;ve sent out a PR to clarify that <https://github.com/tlswg/certificate= -compression/pull/32/files>.

On Mon, Dec 16, 2019 at 8:28 AM Alexey M= elnikov via Datatracker <noreply@iet= f.org> wrote:
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-certificate-compression-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org= /doc/draft-ietf-tls-certificate-compression/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support publication of this document. One small question:

7.3.=C2=A0 Registry for Compression Algorithms

=C2=A0 =C2=A0The procedures for requesting values in the Specification Requ= ired
=C2=A0 =C2=A0space are specified in [RFC8447].

RFC 8447 doesn't define "Specification Required", RFC 8126 do= es. Is there a
more specific section of RFC 8447 that you can point to, as it is unclear t= o me
which parts of RFC 8447 apply here.


--000000000000796127059a174f20-- From nobody Fri Dec 20 01:42:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55DB120807 for ; Fri, 20 Dec 2019 01:42:36 -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 8bv-8LTQBxvD for ; Fri, 20 Dec 2019 01:42:34 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF08120273 for ; Fri, 20 Dec 2019 01:42:34 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id n11so2045364iom.9 for ; Fri, 20 Dec 2019 01:42:34 -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=iBRGuov3ofWio0uhW3lyXRbm+X8tT9S9+BDgTdZ3xbQ=; b=aCWPynbUU8YPjYlEWKTffVjguylqPJWvuDZtj7SxjWfKUAYuGFMtco44J7VYrk/DLH l+rNGJmDJF3lQ7vvhYAYShQyxRE7XcTtSZdmxOX6VX9jX2Z4h0h9GV7tVVC6iuWc9zde diFfmhtKUrahOIV5WqH2Y6PN+Kfa2Egx4KzogC4iKnMiJsO89oy+vKBsr6G1A3jBNiJk VBTuJNv90DuVdymN3Jb1dz5zf3BZC9d6CXhtcAakjyqUcu47VcBFNaRrcSg0jEOcQ27D eNdVTqeszL7e+Wr2LqCOnLAg2FdM6DlBZeLR09Q7sCCcxbGdKrbxu+o12tOCwmaIOj7D O/Ow== 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=iBRGuov3ofWio0uhW3lyXRbm+X8tT9S9+BDgTdZ3xbQ=; b=nEL/yFNaPdEK4iNNG+6zNEMBZ+UPgfim9p6gctR4IyECdbV+hOI1X/YRQiQrInk5pI +o7WH51gh2CIebZA0OwIpuvux1TJs3R6yAgU7I/L79nU8fsv+skQsF7JfLYfgiSv0E00 Nvq0RAOfgBJeo+lwnBmEOabJb0it7h/qnqk1xZaiNOSyF4YGUCcTA2RCrXWrOrTo4Lrr dtkuzQI9Ko+5FRb7VXTnDuIwWUCkeyQWHeO7dA4Hjhj75t5GQ2Y+rwO8QwQ0RLrxl+at xxDFAAKw5gRle344642pHaZTB6rMqTysbVPBTxvCjQ2lI6qYLwMZnksaeDfzDgzRXNil NvnA== X-Gm-Message-State: APjAAAWCvUX67TaBLCcTh6hGVXyXYNaVgM3Kvspfu5VVvEJ+TGXR+eGk PK3PpiGbH2QPSm25ZcmzHf6VVOW+R4+YTGsePt9B3PIo X-Google-Smtp-Source: APXvYqxkpAkKZ7xnlYzXo+irT21AqpxT8QAVlHl0kG+sFp0ZRheObd5VIM1qdFV5orhQ2eDly3jGSfHiLe4CvzrEy7c= X-Received: by 2002:a5e:c314:: with SMTP id a20mr9650321iok.300.1576834953059; Fri, 20 Dec 2019 01:42:33 -0800 (PST) MIME-Version: 1.0 References: <157679659723.15798.2398049069532848341.idtracker@ietfa.amsl.com> In-Reply-To: <157679659723.15798.2398049069532848341.idtracker@ietfa.amsl.com> From: Raja Ashok Date: Fri, 20 Dec 2019 17:42:21 +0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000003f2146059a1f7f48" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-rashok-tls-ticket-request-msg-00.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, 20 Dec 2019 09:42:37 -0000 --0000000000003f2146059a1f7f48 Content-Type: text/plain; charset="UTF-8" Hi All, Requesting to go through this draft and provide your views on it. Thanks & Regards, Raja Ashok ---------- Forwarded message --------- From: Date: Fri 20 Dec, 2019, 7:03 AM Subject: New Version Notification for draft-rashok-tls-ticket-request-msg-00.txt To: Raja Ashok A new version of I-D, draft-rashok-tls-ticket-request-msg-00.txt has been successfully submitted by Raja Ashok and posted to the IETF repository. Name: draft-rashok-tls-ticket-request-msg Revision: 00 Title: TLS Ticket Request Message Document date: 2019-12-20 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-rashok-tls-ticket-request-msg-00.txt Status: https://datatracker.ietf.org/doc/draft-rashok-tls-ticket-request-msg/ Htmlized: https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-rashok-tls-ticket-request-msg Abstract: TLS session ticket provides a stateless mechanism for server to resume connection with client. As per TLS 1.3 [RFC8446], server always sends arbitary number of session ticket after handshake. This document introduces a new message which is TicketRequest message, it can be send by client after handshake at any point of connection lifetime to retrieve session ticket. The proposed mechanism in this document is only for TLS 1.3 and DTLS 1.3 and future versions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000003f2146059a1f7f48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Requ= esting to go through this draft and provide your views on it.=C2=A0

Thanks & Regards,=C2=A0
Raja Ashok

---------- Forwarded message ---------<= br>From: <internet-drafts@ietf.org>
Date: Fri 20 Dec, 2019, 7:03 AM=
Subject: New Version Notification for draft-rashok-tls-ticket-request-m= sg-00.txt
To: Raja Ashok <ra= shok.ietf@gmail.com>



A new version of I-D, draft-rashok-tls-ticket-request-msg-00.txt
has been successfully submitted by Raja Ashok and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-rashok-tls-ticket-reque= st-msg
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS Ticket Request Message
Document date:=C2=A0 2019-12-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dr= aft-rashok-tls-ticket-request-msg-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-rashok-tls-tick= et-request-msg/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-rashok-tls-ticket-request-ms= g-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-rashok-tls-= ticket-request-msg


Abstract:
=C2=A0 =C2=A0TLS session ticket provides a stateless mechanism for server t= o
=C2=A0 =C2=A0resume connection with client.=C2=A0 As per TLS 1.3 [RFC8446],= server
=C2=A0 =C2=A0always sends arbitary number of session ticket after handshake= .=C2=A0 This
=C2=A0 =C2=A0document introduces a new message which is TicketRequest messa= ge, it
=C2=A0 =C2=A0can be send by client after handshake at any point of connecti= on
=C2=A0 =C2=A0lifetime to retrieve session ticket.=C2=A0 The proposed mechan= ism in this
=C2=A0 =C2=A0document is only for TLS 1.3 and DTLS 1.3 and future versions.=




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

The IETF Secretariat

--0000000000003f2146059a1f7f48-- From nobody Fri Dec 20 07:55:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22411200CC; Fri, 20 Dec 2019 07:55:20 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=llQvamgR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PrtPy6dF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-UUgW08OSfe; Fri, 20 Dec 2019 07:55:18 -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 8E4E11200CE; Fri, 20 Dec 2019 07:55:18 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4650E222B2; Fri, 20 Dec 2019 10:55:17 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Fri, 20 Dec 2019 10:55:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=7wzs01ikTkEwU2MvFBiYaJ/PR8g0Rg2 2Xyyuw7xIkxc=; b=llQvamgRahfiWAwUon+8x4Jml87quv6PO3RxnufL1PzWAyD Q01o5jscl40kIYU50WF/8UkSIADSgswfcP8qk2zo3R6iDI7dAJBgh1qecADnFtR/ +dfastBUUFAKbs2sKjEaYDjjMzZ6l1ER3Y6hjEwzupTPYIImjBdLpDZNlNNuWH2d +ShdkTxT/yYMqNWXkLoOsMaYzP7/tFUXJVIbJvVgg8yI3u4/WBMdJ3yBFazSE7k3 0DOIZCwC9cQq1Twztzl9TuBl4z/azlDF4q+/NvHxXOLqLMcIa0ALzRVh2iGdmHIH hoqYGSVuRL5SZ/ITZn+E1ZGWjEJ1c+MQna+QwDA== 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=fm1; bh=7wzs01 ikTkEwU2MvFBiYaJ/PR8g0Rg22Xyyuw7xIkxc=; b=PrtPy6dFkY0lS5LqJ7nUNz WxzHyMmI3LcmBINdGCGg0E2g/3pozSG66T6LEyRofDa0L3CV5figsnfwcl9oisb+ awFB8S9W9qVHGGa6LXAnque2nqCZ1LNPRrUnBislLP+G63zqTgh9sgLW/EoenJ5m vN3jypF2U80pc9a7lIZg8uPszdfkJinAS9y4jPEyQgyl84U175cDma+M6TZCkg61 XOcoJ+aQTGz2pUVFAXq8KmfcFhcspNpBCoFJO7XEKL2Sgj58Efvjm9akA23iJQ1o QIgE6YjVkrpMs6vBEBn/eQOtXuH7oFH4JG6V/OhLublfI9srEFtfZ8PgA0CYzXqQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddufedgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecurfgr rhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh enucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id ECF9DC200A4; Fri, 20 Dec 2019 10:55:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1 Mime-Version: 1.0 Message-Id: <420bfeac-faad-4572-9819-93265f543ef3@www.fastmail.com> In-Reply-To: References: <157650291360.21504.14681246291594764273.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 15:53:54 +0000 From: "Alexey Melnikov" To: "Victor Vasiliev" Cc: "The IESG" , draft-ietf-tls-certificate-compression@ietf.org, "Sean Turner" , tls-chairs , "tls@ietf.org" Content-Type: multipart/alternative; boundary=196d3b710de145df8e1659ccdea4ce69 Archived-At: Subject: Re: [TLS] =?utf-8?q?Alexey_Melnikov=27s_No_Objection_on_draft-ietf-t?= =?utf-8?q?ls-certificate-compression-08=3A_=28with_COMMENT=29?= 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, 20 Dec 2019 15:55:21 -0000 --196d3b710de145df8e1659ccdea4ce69 Content-Type: text/plain On Thu, Dec 19, 2019, at 11:56 PM, Victor Vasiliev wrote: > I believe the intention was to refer to Section 17 of RFC 8447 , as it contains details of how Specification Required works with TLS-related registrations. I've sent out a PR to clarify that . Great, thank you. > > On Mon, Dec 16, 2019 at 8:28 AM Alexey Melnikov via Datatracker wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-tls-certificate-compression-08: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I support publication of this document. One small question: >> >> 7.3. Registry for Compression Algorithms >> >> The procedures for requesting values in the Specification Required >> space are specified in [RFC8447]. >> >> RFC 8447 doesn't define "Specification Required", RFC 8126 does. Is there a >> more specific section of RFC 8447 that you can point to, as it is unclear to me >> which parts of RFC 8447 apply here. >> >> --196d3b710de145df8e1659ccdea4ce69 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Dec 19,= 2019, at 11:56 PM, Victor Vasiliev wrote:
I believe the intention was to refer to= Section 17 of RFC 8447 <https://tools.ietf.org/html/rfc8447#section-17>, a= s it contains details of how Specification Required works with TLS-relat= ed registrations.  I've sent out a PR to clarify that <https:/= /github.com/tlswg/certificate-compression/pull/32/files>.
Great, thank you.


<= div class=3D"qt-gmail_attr" dir=3D"ltr">On Mon, Dec 16, 2019 at 8:28 AM = Alexey Melnikov via Datatracker <= noreply@ietf.org> wrote:
Alexey Melnikov has entere= d the following ballot position for
draft-ietf-tls-certif= icate-compression-08: No Objection

When r= esponding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cu= t this
introductory paragraph, however.)
<= br>

for= more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot= positions, can be found here:



----------------------------------------------------------------------=
COMMENT:
--------------------------------= --------------------------------------

I = support publication of this document. One small question:
=
7.3.  Registry for Compression Algorithms

   The procedures for requesting values= in the Specification Required
   space are spe= cified in [RFC8447].

RFC 8447 doesn't def= ine "Specification Required", RFC 8126 does. Is there a
m= ore specific section of RFC 8447 that you can point to, as it is unclear= to me
which parts of RFC 8447 apply here.
=


--196d3b710de145df8e1659ccdea4ce69-- From nobody Fri Dec 20 14:00:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1CF1200EF for ; Fri, 20 Dec 2019 14:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, 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 (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 33o04rMO4RjA for ; Fri, 20 Dec 2019 14:00:02 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B901200C1 for ; Fri, 20 Dec 2019 14:00:02 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id b18so13637842otp.0 for ; Fri, 20 Dec 2019 14:00:02 -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=Qk3LsB1XX2gzX5EBBCdlu47xEIavOgynZgtFz0/tbrY=; b=WFart5ImwjFUbIm8LeRKA6BXHE+Bv/nFd/wUzJUEmhYQ8k9BdK4SsvxV3n3BzriX6E 4KJhQv7SlnBD2ZOS9at1aWBeaJNdyPUxJkldjs8Ade6BWQpTu3+KmFMAb/18x/OclVKN qKNN8c8Nt2kLfr2jHQW2KButZT0vwx4WC1zCx7VIQbGpPqpzfN+Kji/yJQloPkwuJTsM bHfCrt81BxNelLzSkkq63YYGJKywLub0dqpZQ+C22lr19wwOyiPwbtr2DLnKB+sME5Z+ Nxmqs80pbN9C9M1tUN/3TtNl/bs5SFgphYo2LdMIchDqPWYtZ2v0Wl5FHy0e7LMO1ucA u8hw== 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=Qk3LsB1XX2gzX5EBBCdlu47xEIavOgynZgtFz0/tbrY=; b=CdVyVHpGANyF1Q/RAwT1KZjBhtooTn+tkMs7UYOvYvdgnh7a9HtlOl4J9XWPLTSOUY biNZG0vbs400ctMkSgN+AHls0GpGAVyZHG1B/XwQbdCpHbyYAZZa1FAJsdMz4mWTjsxk zCiWhM/TWewpn+duDnWLHFO/745F0Qi20RZ0rCupWAUAbMQYoQLVVKkwWbdDlTkGv5I3 ghpd7+YTjxF9cwXm63sifGNlHXhmfkLC/AqNU9L0Q3O8ce/CvZV8bm990j8yi8FDMg20 qZKhxPcGgIALyi4vHZU0wMJZUecOnB99o6Ql6prKNF+6vXFN4f/pb9ThqOaiMBzU19rb pkrg== X-Gm-Message-State: APjAAAXjx5EpctLkVnCl266YkbytX6qU3v8xVlsz4xZI7R/r2Iqal6LE XILCuwlt5aCJTyKdaOvWB8gSNhU6QFFSYX8uYPWZ+Q== X-Google-Smtp-Source: APXvYqy6GloabedG4bcxQk6n5yU92T3UHEqBE8kTUPNIAY7UCg0tIE7qTnHebuSWpDmtUZ1XgAaaejGA1HdVbd6e64U= X-Received: by 2002:a9d:6251:: with SMTP id i17mr17611780otk.14.1576879201086; Fri, 20 Dec 2019 14:00:01 -0800 (PST) MIME-Version: 1.0 References: <157679659723.15798.2398049069532848341.idtracker@ietfa.amsl.com> In-Reply-To: From: Nick Harper Date: Fri, 20 Dec 2019 13:59:49 -0800 Message-ID: To: Raja Ashok Cc: "" Content-Type: multipart/alternative; boundary="000000000000a2c232059a29ccb3" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-rashok-tls-ticket-request-msg-00.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, 20 Dec 2019 22:00:04 -0000 --000000000000a2c232059a29ccb3 Content-Type: text/plain; charset="UTF-8" This seems to be solving a very similar problem to draft-ietf-tls-ticketrequests (which I see you reference in your draft). I see two cases where this mechanism might be useful compared to the ticket_request extension, but I'm skeptical those are useful use cases. The first case is if partway through a connection a client decides it wants more tickets from the server. With the ticket_request extension, a client can only specify at the beginning of a connection how many tickets it wants, whereas with this TicketRequest message the client can ask for more later. I can't think of a use case where a client would need more tickets from this specific connection; if a client does need more tickets it can get them from a new connection. The other case is one you mentioned in the draft: delaying sending tickets to prioritize sending application data. There's no requirement that a server send NewSessionTicket messages immediately after the handshake. A server could prioritize sending application data over sending tickets and delay sending tickets for some period of time. On Fri, Dec 20, 2019 at 1:42 AM Raja Ashok wrote: > Hi All, > > Requesting to go through this draft and provide your views on it. > > Thanks & Regards, > Raja Ashok > > ---------- Forwarded message --------- > From: > Date: Fri 20 Dec, 2019, 7:03 AM > Subject: New Version Notification for > draft-rashok-tls-ticket-request-msg-00.txt > To: Raja Ashok > > > > A new version of I-D, draft-rashok-tls-ticket-request-msg-00.txt > has been successfully submitted by Raja Ashok and posted to the > IETF repository. > > Name: draft-rashok-tls-ticket-request-msg > Revision: 00 > Title: TLS Ticket Request Message > Document date: 2019-12-20 > Group: Individual Submission > Pages: 4 > URL: > https://www.ietf.org/internet-drafts/draft-rashok-tls-ticket-request-msg-00.txt > Status: > https://datatracker.ietf.org/doc/draft-rashok-tls-ticket-request-msg/ > Htmlized: > https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-rashok-tls-ticket-request-msg > > > Abstract: > TLS session ticket provides a stateless mechanism for server to > resume connection with client. As per TLS 1.3 [RFC8446], server > always sends arbitary number of session ticket after handshake.. This > document introduces a new message which is TicketRequest message, it > can be send by client after handshake at any point of connection > lifetime to retrieve session ticket. The proposed mechanism in this > document is only for TLS 1.3 and DTLS 1.3 and future versions. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a2c232059a29ccb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This seems to be solving a very similar problem to draft-i= etf-tls-ticketrequests (which I see you reference in your draft). I see two= cases where this mechanism might be useful compared to the ticket_request = extension, but I'm skeptical those are useful use cases.

=
The first case is if partway through a connection a client decides it = wants more tickets from the server. With the ticket_request extension, a cl= ient can only specify at the beginning of a connection how many tickets it = wants, whereas with this TicketRequest message the client can ask for more = later. I can't think of a use case where a client would need more ticke= ts from this specific connection; if a client does need more tickets it can= get them from a new connection.

The other case is= one you mentioned in the draft: delaying sending tickets to prioritize sen= ding application data. There's no requirement that a server send NewSes= sionTicket messages immediately after the handshake. A server could priorit= ize sending application data over sending tickets and delay sending tickets= for some period of time.

On Fri, Dec 20, 2019 at 1:42 AM Raja Ashok &= lt;rashok.ietf@gmail.com> w= rote:
Hi All,

Requesting t= o go through this draft and provide your views on it.=C2=A0

Thanks & Regards,=C2=A0
Raja Ashok

---------- Forwarded message ---------
Fro= m: <internet-drafts@ietf.org>
Date: Fri 20 Dec, 2= 019, 7:03 AM
Subject: New Version Notification for draft-rashok-tls-tick= et-request-msg-00.txt
To: Raja Ashok <rashok.ietf@gmail.com>


=
A new version of I-D, draft-rashok-tls-ticket-request-msg-00.txt
has been successfully submitted by Raja Ashok and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-rashok-tls-ticket-reque= st-msg
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS Ticket Request Message
Document date:=C2=A0 2019-12-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dr= aft-rashok-tls-ticket-request-msg-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-rashok-tls-tick= et-request-msg/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-rashok-tls-ticket-request-ms= g-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-rashok-tls-= ticket-request-msg


Abstract:
=C2=A0 =C2=A0TLS session ticket provides a stateless mechanism for server t= o
=C2=A0 =C2=A0resume connection with client.=C2=A0 As per TLS 1.3 [RFC8446],= server
=C2=A0 =C2=A0always sends arbitary number of session ticket after handshake= ..=C2=A0 This
=C2=A0 =C2=A0document introduces a new message which is TicketRequest messa= ge, it
=C2=A0 =C2=A0can be send by client after handshake at any point of connecti= on
=C2=A0 =C2=A0lifetime to retrieve session ticket.=C2=A0 The proposed mechan= ism in this
=C2=A0 =C2=A0document is only for TLS 1.3 and DTLS 1.3 and future versions.=




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

The IETF Secretariat

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a2c232059a29ccb3-- From nobody Sat Dec 21 07:53:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563A4120020 for ; Sat, 21 Dec 2019 07:53:40 -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 Rp6wgDnaZPR7 for ; Sat, 21 Dec 2019 07:53:38 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0: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 60434120018 for ; Sat, 21 Dec 2019 07:53:38 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id z12so10584338iln.11 for ; Sat, 21 Dec 2019 07:53: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 :cc; bh=vQ0N5gc0xSm70HXhMlQsg8X6a9XkOhNKNLQxJWUucBQ=; b=eyhedYKc+vl8BefkhlpLkBXI/NMR/zLvTX+SJfSBehGath50g5dVze0yvzm1wi6E/J uMbi35vekCPUHsogShJFzcTEX5XXJ8wIz49dX8ehNiuH8ocyNCEHxQji0MpGaR/LSB3F 0H3u05Nmuqi0uyzXbXITs47A/hcw+lFV4WSXkphdZ+Y7943/ZXqM3qE+C7kNL7peolaS K8KZ+aWz4UbCHLIGUIFmXbx/6oRMJPsqDgHCAsqKecP3K7wqDvQ/FKv0FuGSu5B7jGHr h4E7tonX1sYPLP8p+CkexuqUoA6s5q13ZHzE0pOLP/DPgHUKvWDHD5f7bxnjoLy8hHpO rc3Q== 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=vQ0N5gc0xSm70HXhMlQsg8X6a9XkOhNKNLQxJWUucBQ=; b=l4mKSEyTg6buhvH9W34SIkKFlFX6uTbujxhjr4DmSWOK2AWdpFr4GrndHgDYIgjpKa va14TVpUKpCw6/mqok0DnmlsZw0Q+FvSKGCl4JatAybV9aW527ZmImqfNavY2zztj1w8 hT+UkSefEu4k/Li7eiDQSgsY53YnokNBvc7FK/6cOoDksr/zl8o7DcZTniBXP7pGck0f +vwdUfGG12N+I53cJJxQ+irFAz346Rn1r/ogptfcFRIgKLELX45z53sXVoPYVqVE+62T M8mAgat0sGx0xYXr9M8uKm5POUfIj3VlB4fIz0hnQucscG8H95NV9wc7b27+HVB0yk/Q 8D4g== X-Gm-Message-State: APjAAAV7rbIMM7c9zcNnUybusl/9P0dnmXJTDVX5Q2iqxcO5LJ6Q4cGs CAOvkDrpc13brBbfM7M1fwUMy2bQBbppajjGE6w= X-Google-Smtp-Source: APXvYqwUP9QN96f6RL0TbOyprBOdbDiVJ8jejlPuVGCzSnchhzMO0nizWp/PYNb0nWJteov+zOYqKjnxQaeBdOMjTw0= X-Received: by 2002:a92:5d8d:: with SMTP id e13mr1629225ilg.285.1576943617626; Sat, 21 Dec 2019 07:53:37 -0800 (PST) MIME-Version: 1.0 References: <157679659723.15798.2398049069532848341.idtracker@ietfa.amsl.com> In-Reply-To: From: Raja Ashok Date: Sat, 21 Dec 2019 23:53:26 +0800 Message-ID: To: Nick Harper Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="00000000000028d7ac059a38cc7c" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-rashok-tls-ticket-request-msg-00.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, 21 Dec 2019 15:53:40 -0000 --00000000000028d7ac059a38cc7c Content-Type: text/plain; charset="UTF-8" This seems to be solving a very similar problem to > draft-ietf-tls-ticketrequests (which I see you reference in your draft). I > see two cases where this mechanism might be useful compared to the > ticket_request extension, but I'm skeptical those are useful use cases. > > The first case is if partway through a connection a client decides it > wants more tickets from the server. With the ticket_request extension, a > client can only specify at the beginning of a connection how many tickets > it wants, whereas with this TicketRequest message the client can ask for > more later. I can't think of a use case where a client would need more > tickets from this specific connection; > Consider a Video Streaming Application, which holds a TLS (HTTPS) connection to URI of lower resolution video (and audio). Based on dynamic improvement on bandwidth it might switch to higher resolution video content, which inturn might have different URIs for video and audio. At this point TLS client needs to open another TLS connection. So if TicketRequest msg support is there, at this scenario it can get ticket on the fly. Getting more amount of session ticket after handshake delays application data processing as well as some ticket might not be used. Like this there a lot of scenarios are there for a TLS client to choose how many tickets are needed on the fly. Basically TicketRequest msg gives 2 benefits to application - Avoid wastage of ticket - Improves application data processing by postponing session ticket msg issuance. > if a client does need more tickets it can get them from a new connection. > Consider a TLSv1.3 client opens a fresh Connection, and retrieves one ticket immediately after handshake. Now it opens 2nd connection (resumed) with ticket_request extension count as zero, by assuming not needed. But later if it needs to open one more connection based on dynamic need, then there is no way to get ticket without TicketRequest msg. > > The other case is one you mentioned in the draft: delaying sending tickets > to prioritize sending application data. There's no requirement that a > server send NewSessionTicket messages immediately after the handshake. A > server could prioritize sending application data over sending tickets and > delay sending tickets for some period of time. > As per my understanding RFC8446 says a TLSv1.3 server should send session ticket immediately after handshake. Even if it can delay, it will be very difficult to identify how long it should delay sending session ticket by prioritizing application data. Thanks & Regards, Raja Ashok --00000000000028d7ac059a38cc7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


This seems to be solving a very similar problem to = draft-ietf-tls-ticketrequests (which I see you reference in your draft). I = see two cases where this mechanism might be useful compared to the ticket_r= equest extension, but I'm skeptical those are useful use cases.
The first case is if partway through a connection a client deci= des it wants more tickets from the server. With the ticket_request extensio= n, a client can only specify at the beginning of a connection how many tick= ets it wants, whereas with this TicketRequest message the client can ask fo= r more later. I can't think of a use case where a client would need mor= e tickets from this specific connection;

<= /div>
Consider a Video Streaming Application, which holds a TLS (HTTPS)= connection to URI of lower resolution video (and audio). Based on dynamic = improvement on bandwidth it might switch to higher resolution video content= , which inturn might have different URIs for video and audio. At this point= TLS client needs to open another TLS connection. So if TicketRequest msg s= upport is there, at this scenario it can get ticket on the fly. Getting mor= e amount of session ticket after handshake delays application data processi= ng as well as some ticket might not be used.

Like this there a lot o= f scenarios are there for a TLS client to choose how many tickets are neede= d on the fly.

Basically TicketRequest msg gives 2 benefits to applic= ation
- Avoid wastage of ticket
- Improves application data processin= g by postponing session ticket msg issuance.
=C2=A0
if a c= lient does need more tickets it can get them from a new connection.

Consider a TLSv1.3 cl= ient opens a fresh Connection, and retrieves one ticket immediately after h= andshake. Now it opens 2nd connection (resumed) with ticket_request extensi= on count as zero, by assuming not needed. But later if it needs to open one= more connection based on dynamic need, then there is no way to get ticket = without TicketRequest msg.
=C2=A0
=C2=A0
The other case is one you mentioned in the draft: delaying sending= tickets to prioritize sending application data. There's no requirement= that a server send NewSessionTicket messages immediately after the handsha= ke. A server could prioritize sending application data over sending tickets= and delay sending tickets for some period of time.

As per my understanding RFC8446 says a TLSv1.3 server = should send session ticket immediately after handshake. Even if it can dela= y, it will be very difficult to identify how long it should delay sending s= ession ticket by prioritizing application data.

Th= anks & Regards,
Raja Ashok
--00000000000028d7ac059a38cc7c-- From nobody Sat Dec 21 16:45:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C979412006E for ; Sat, 21 Dec 2019 16:45:17 -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=g8ss7QOz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WnYqHEVY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u0ppETybgY8 for ; Sat, 21 Dec 2019 16:45:13 -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 BCCE1120025 for ; Sat, 21 Dec 2019 16:45:13 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 16DFC49F for ; Sat, 21 Dec 2019 19:45:13 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 21 Dec 2019 19:45:13 -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=b7Q7bCieHQbrxsCPVRj6zixQzTjiYV1LLwhdVmp3N9U=; b=g8ss7QOz h6dgwT6q0JbHPCxMyh70G77nBhuBzaw1SdTMb4JRnniychDZ+2n+QlrI3A+THoZJ FKxopa/rnC4Lk0f819KOVWaQiJvheqiTGhVAkFvrGSX1lODUG3lqjhvHpYsUnr5C UomE2ln4zltYucgXOmgB8VhGq9DFPYJAZijBIq+Pd+KWiuXM+vjDo7w1Ck0B5lWW OwWAaPLEKjU0rvZU029rkBqePzQyG4unnb3qd/pfvmDREhPqrulFqCQv7NmDuUJ3 gbqB9XdqScHtB7gagZbEK+yfvFmam+k7ebPduT2pE38MBGS4OXQAGWbsc7bH3cY3 AW7Hybn9HpPb7Q== 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=b7Q7bCieHQbrxsCPVRj6zixQzTjiY V1LLwhdVmp3N9U=; b=WnYqHEVYpf8Yt4+Jad89CFBt7S9WGcII+GxtWYYEkLoaS KSVZoUhhZfxSDo5yiowLSMZxcYdPaCkLZSnI/iKkVIzRPi2GnWM2ixde0/guH7dl RrkkKYOlVLjKBl+l50IiyVr4RC8AMm3Kx6WWgR1l/Lcv9EYel6ss0L1XOasOtd5B 3QkzBYMSrdA3QZNcS1bs2bQPfDPM8RCE+on/nuKLG7HRdI9rGhK2UEPDVl6uwPKk pYqh4grdkqN92aUFj+BrWi8/bvzsT5b4PQsk9YC0mtXX+aVMI3aGU82cJCNMbTRc c3SowohC/6ROXg5WtO4snpZTZBxO79y+EK69ed3Zw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdduiedgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusgcupfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeeghedrjeelrdduudefrdduieehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 769F48005A for ; Sat, 21 Dec 2019 19:45:11 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 7516A9D37E for ; Sun, 22 Dec 2019 00:45:10 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============7350748998291412326==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191222004510.7516A9D37E@cloud.mnot.net> Date: Sun, 22 Dec 2019 00:45:10 +0000 (UTC) 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, 22 Dec 2019 00:45:18 -0000 --===============7350748998291412326== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * tlswg/certificate-compression (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Address comments from the IESG (by vasilvv) https://github.com/tlswg/certificate-compression/pull/32=20 Repositories tracked by this digest: ----------------------------------- * 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 --===============7350748998291412326== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday December 22, 2019

Pull requests

tlswg/certificate-compression (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

Repositories tracked by this digest:

--===============7350748998291412326==-- From nobody Sun Dec 22 05:19:20 2019 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 80592120104; Sun, 22 Dec 2019 05:19:12 -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.114.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157702075247.3972.8648112504384441326@ietfa.amsl.com> Date: Sun, 22 Dec 2019 05:19:12 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-05.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, 22 Dec 2019 13:19:12 -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 : TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key Author : Russ Housley Filename : draft-ietf-tls-tls13-cert-with-extern-psk-05.txt Pages : 12 Date : 2019-12-22 Abstract: This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-extern-psk-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-cert-with-extern-psk-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 22 05:25:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226FA120110 for ; Sun, 22 Dec 2019 05:25: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, 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 Zx8GFCCBXfQx for ; Sun, 22 Dec 2019 05:25:26 -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 85EE312010D for ; Sun, 22 Dec 2019 05:25:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0990B300B23 for ; Sun, 22 Dec 2019 08:25:25 -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 Ik7KKeU8SCu8 for ; Sun, 22 Dec 2019 08:25: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 8509B300AA3 for ; Sun, 22 Dec 2019 08:25:23 -0500 (EST) From: Russ Housley 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\)) Date: Sun, 22 Dec 2019 08:25:24 -0500 References: <157702075247.3972.8648112504384441326@ietfa.amsl.com> To: IETF TLS In-Reply-To: <157702075247.3972.8648112504384441326@ietfa.amsl.com> Message-Id: <443D0415-A77D-4835-94EC-9A81F218D561@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-05.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, 22 Dec 2019 13:25:28 -0000 This update adds the following paragraph to the Introduction: Several implementors wanted to gain more experience with this specification before producing a standards-track RFC. As a result, this specification is being published as an Experimental RFC to enable interoperable implementations and gain deployment and operational experience. I believe this resolves the last comment from IESG Evaluation. Russ > On Dec 22, 2019, at 8:19 AM, 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 : TLS 1.3 Extension for Certificate-based = Authentication with an External Pre-Shared Key > Author : Russ Housley > Filename : = draft-ietf-tls-tls13-cert-with-extern-psk-05.txt > Pages : 12 > Date : 2019-12-22 >=20 > Abstract: > This document specifies a TLS 1.3 extension that allows a server to > authenticate with a combination of a certificate and an external = pre- > shared key (PSK). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-exter= n-psk-05 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-cert-with-extern-= psk-05 >=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/ From nobody Mon Dec 23 06:35:58 2019 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 4391B120026; Mon, 23 Dec 2019 06:35: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.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157711175212.21397.7723583515307074524@ietfa.amsl.com> Date: Mon, 23 Dec 2019 06:35:52 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-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: Mon, 23 Dec 2019 14:35:52 -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 : TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key Author : Russ Housley Filename : draft-ietf-tls-tls13-cert-with-extern-psk-06.txt Pages : 12 Date : 2019-12-23 Abstract: This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-06 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-extern-psk-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-cert-with-extern-psk-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 Mon Dec 23 06:38:03 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C6C1200B6 for ; Mon, 23 Dec 2019 06:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 B06ltWbMahI5 for ; Mon, 23 Dec 2019 06:37:59 -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 04A45120026 for ; Mon, 23 Dec 2019 06:37:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 86640300AA3 for ; Mon, 23 Dec 2019 09:37:57 -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 bFRkw62UbfpM for ; Mon, 23 Dec 2019 09:37:56 -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 747513005DB for ; Mon, 23 Dec 2019 09:37:56 -0500 (EST) From: Russ Housley 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\)) Date: Mon, 23 Dec 2019 09:37:57 -0500 References: <157711175212.21397.7723583515307074524@ietfa.amsl.com> To: IETF TLS In-Reply-To: <157711175212.21397.7723583515307074524@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-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, 23 Dec 2019 14:38:01 -0000 This update addresses a set of comments from IESG Evaluation that I = inadvertently missed yesterday. Russ > On Dec 23, 2019, at 9:35 AM, 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 : TLS 1.3 Extension for Certificate-based = Authentication with an External Pre-Shared Key > Author : Russ Housley > Filename : = draft-ietf-tls-tls13-cert-with-extern-psk-06.txt > Pages : 12 > Date : 2019-12-23 >=20 > Abstract: > This document specifies a TLS 1.3 extension that allows a server to > authenticate with a combination of a certificate and an external = pre- > shared key (PSK). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-06 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-exter= n-psk-06 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-cert-with-extern-= psk-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/ From nobody Mon Dec 23 06:39:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622F6120026 for ; Mon, 23 Dec 2019 06:39:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 In-0Vku49VWX for ; Mon, 23 Dec 2019 06:39:43 -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 E32671200B7 for ; Mon, 23 Dec 2019 06:39:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B2F89300B34 for ; Mon, 23 Dec 2019 09:34:27 -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 eNsyzHjb073x for ; Mon, 23 Dec 2019 09:34:24 -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 A8F2A3005DB; Mon, 23 Dec 2019 09:34:24 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <157654745794.24469.3021505269125375774.idtracker@ietfa.amsl.com> Date: Mon, 23 Dec 2019 09:34:25 -0500 Cc: IESG , TLS Chairs , draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <92554FDB-2404-4D3F-B7D1-4146E01EEBC0@vigilsec.com> References: <157654745794.24469.3021505269125375774.idtracker@ietfa.amsl.com> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT) 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, 23 Dec 2019 14:39:44 -0000 Roman: Thanks for the careful read and the resulting comments. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > * Section 7. The paragraphs that start with =E2=80=9CIn this = extension, the external > PSK preserves secrecy if the EC(DH) key agreement=E2=80=9D =E2=80=A6=E2=80= =9D and =E2=80=9CIn the future, if > the (EC)DH key agreement ..=E2=80=9D seem to be saying the same thing = differently. Not really. The first one is talking about the PSK preserving secrecy = (probably should say confidentiality). The second one is talking about = forward secrecy. I will merge the two paragraphs: In this extension, the external PSK preserves confidentiality if the (EC)DH key agreement is ever broken by cryptanalysis or the future invention of a large-scale quantum computer. As long as the attacker does not know the PSK and the key derivation algorithm remains unbroken, the attacker cannot derive the session secrets even if they are able to compute the (EC)DH shared secret. Should the attacker be able compute the (EC)DH shared secret, the forward secrecy advantages traditionally associated with ephemeral (EC)DH keys will no longer be relevant. Although the ephemeral private keys used during a given TLS session are destroyed at the end of a session, preventing the attacker from later accessing them, these private keys would nevertheless be recoverable due to the break in the algorithm. However, a more general notion of "secrecy after key material is destroyed" would still be achievable using external PSKs, if they are managed in a way that ensures their destruction when they are no longer needed, and with the assumption that the algorithms that use the external PSKs remain quantum-safe. > * Section 7. It=E2=80=99s worth mentioning somewhere the obvious thing = =E2=80=93 how to > generate, distribute, manage the external PSKs is out of scope for = this > specification. Gladly. I put it at the bottom of the third paragraph in Section 7, = which now reads: Implementations must protect the external pre-shared key (PSK). Compromise of the external PSK will make the encrypted session content vulnerable to the future development of a large-scale quantum computer. However, the generation, distribution, and management of the external PSKs is out of scope for this specification. > * Section 7. Per =E2=80=9CTLS 1.3 [RFC8446] has received careful = security analysis, > and some informal reasoning shows that the addition of this extension = does not > introduce any security defects=E2=80=9D, is there a citation for this = =E2=80=9Cinformal > reasoning=E2=80=9D? Otherwise, it=E2=80=99s a soft statement. The informal reasoning follows the paragraph, and I think the only = reference would be my slides from IETF 104. To make this clear, I will change "some informal reasoning" to "the = following informal reasoning". > * Editorial Nits: > - Section 3. Typo. s/inclue/include/ >=20 > - Section 5.1. Typo. s/extension are/extensions are/ >=20 > - Section 5.1. /Most of those extension are not impacted in any way. = This > section discusses the impacts on the other extensions./Most of those = extension > are not impacted in any way by this specification. However, this = section > discusses the extensions that require additional consideration./ >=20 > - Section 5.1. Typo. s/may be know to other partiers/may be known to = other > parties/ >=20 > - Section 5.1. Typo. s/know to other parties/known to other parties/ >=20 > - Section 7. Typo. s/that external PSK/that the external PSK/ Two of these must have been fixed based on comments from others. = Anyway, they are all fixed now. Russ From nobody Mon Dec 23 06:50:30 2019 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 C63181200B7; Mon, 23 Dec 2019 06:50:23 -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.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157711262373.21483.14577052896250499397@ietfa.amsl.com> Date: Mon, 23 Dec 2019 06:50:23 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-07.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: Mon, 23 Dec 2019 14:50:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key Author : Russ Housley Filename : draft-ietf-tls-tls13-cert-with-extern-psk-07.txt Pages : 12 Date : 2019-12-23 Abstract: This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-07 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-extern-psk-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-cert-with-extern-psk-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 23 06:52:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14771200BA for ; Mon, 23 Dec 2019 06:52:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 P5sb6Uc3xlfo for ; Mon, 23 Dec 2019 06:52:17 -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 F0F331200B7 for ; Mon, 23 Dec 2019 06:52:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7A0FD300A48 for ; Mon, 23 Dec 2019 09:52:15 -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 9K7HfuZvHx1l for ; Mon, 23 Dec 2019 09:52:14 -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 2D9683005DB for ; Mon, 23 Dec 2019 09:52:14 -0500 (EST) From: Russ Housley 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\)) Date: Mon, 23 Dec 2019 09:52:14 -0500 References: <157711262373.21483.14577052896250499397@ietfa.amsl.com> To: IETF TLS In-Reply-To: <157711262373.21483.14577052896250499397@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-07.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, 23 Dec 2019 14:52:19 -0000 Apparently I ran xml2rfc for -06 with a few unsaved changes still in my = edit buffer. Here are the rest of the changes. Russ > On Dec 23, 2019, at 9:50 AM, 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 : TLS 1.3 Extension for Certificate-based = Authentication with an External Pre-Shared Key > Author : Russ Housley > Filename : = draft-ietf-tls-tls13-cert-with-extern-psk-07.txt > Pages : 12 > Date : 2019-12-23 >=20 > Abstract: > This document specifies a TLS 1.3 extension that allows a server to > authenticate with a combination of a certificate and an external = pre- > shared key (PSK). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-07 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-exter= n-psk-07 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-cert-with-extern-= psk-07 >=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/ From nobody Mon Dec 23 11:03:18 2019 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 439A8120CD4; Mon, 23 Dec 2019 11:03:17 -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.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157712779719.21365.15071250690241344262@ietfa.amsl.com> Date: Mon, 23 Dec 2019 11:03:17 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-09.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: Mon, 23 Dec 2019 19:03:17 -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 : TLS Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-09.txt Pages : 8 Date : 2019-12-23 Abstract: In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-09 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 23 11:14:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8C2120CD8 for ; Mon, 23 Dec 2019 11:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpMwJ16vzwdk for ; Mon, 23 Dec 2019 11:14:37 -0800 (PST) Received: from blastoise.ghedini.me (blastoise.ghedini.me [45.32.158.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4318120096 for ; Mon, 23 Dec 2019 11:14:37 -0800 (PST) Received: from localhost (unknown [IPv6:2001:b07:5d31:6b94:44a9:24f2:d1a7:ec22]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 9415ADF454 for ; Mon, 23 Dec 2019 19:14:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1577128472; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nWnw0sdC9vKjFTslnovZvSfi630I/bu8KVHzqwnxmBc=; b=QT5i7aM+U+PishQUR30NZnpcJXKhNhAMS5XvEiHFQtMbDwUGxcJyj4s84/WnsJhrrLDxFj 1Tdg5SCrzKbxQj7YmtB2R+7IeX+PPm25ktJrHRxNplkbjgE8eydI+1niwL/MeRjSzVDWsV xDb+hJyZn1YhNfVQeRqjlfeUaPiRAl8= Date: Mon, 23 Dec 2019 19:14:29 +0000 From: Alessandro Ghedini To: tls@ietf.org Message-ID: <20191223191429.GA6198@wakko.flat11.house> References: <157712779719.21365.15071250690241344262@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157712779719.21365.15071250690241344262@ietfa.amsl.com> Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-09.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, 23 Dec 2019 19:14:40 -0000 On Mon, Dec 23, 2019 at 11:03:17AM -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 : TLS Certificate Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-09.txt > Pages : 8 > Date : 2019-12-23 > > Abstract: > In TLS handshakes, certificate chains often take up the majority of > the bytes transmitted. > > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-09 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-09 This addresses some comments from IESG review. Cheers From nobody Mon Dec 23 13:37:00 2019 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 31907120043; Mon, 23 Dec 2019 13:36:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , tls-chairs@ietf.org, Joseph Salowey , tls@ietf.org, draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, joe@salowey.net, rfc-editor@rfc-editor.org, kaduk@mit.edu Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157713701319.2535.6611486654159053453.idtracker@ietfa.amsl.com> Date: Mon, 23 Dec 2019 13:36:53 -0800 Archived-At: Subject: [TLS] Document Action: 'TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key' to Experimental RFC (draft-ietf-tls-tls13-cert-with-extern-psk-07.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: Mon, 23 Dec 2019 21:36:53 -0000 The IESG has approved the following document: - 'TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key' (draft-ietf-tls-tls13-cert-with-extern-psk-07.txt) as Experimental RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ Technical Summary This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). Working Group Summary The document has strong support from a small number of participants in the working group. Concerns have been raised about the lack of implementation plans, but there was enough support to move this experimental draft forward. Document Quality Implementation plans are unknown, but the core of the proposal involves using a "joint in the protocol" in a usage that was envisioned in the original design; the main work is to record the specific semantics and signaling involved, to ensure interoperability. Personnel Joe Salowey is the document shepherd. Benjamin Kaduk is the responsible AD. From nobody Mon Dec 23 13:37:58 2019 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 C65AF120D0E; Mon, 23 Dec 2019 13:37:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , tls-chairs@ietf.org, Sean Turner , draft-ietf-tls-certificate-compression@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org, sean@sn3rd.com, kaduk@mit.edu Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157713707380.2486.15116992272061356860.idtracker@ietfa.amsl.com> Date: Mon, 23 Dec 2019 13:37:53 -0800 Archived-At: Subject: [TLS] Protocol Action: 'TLS Certificate Compression' to Proposed Standard (draft-ietf-tls-certificate-compression-09.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: Mon, 23 Dec 2019 21:37:57 -0000 The IESG has approved the following document: - 'TLS Certificate Compression' (draft-ietf-tls-certificate-compression-09.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ Technical Summary This draft defines a TLS extension to compress certificate chains to reduce the amount of data transmitted and avoid some round trips. The compression algorithms defined, zlib, brotli, and zstd, are all documented in RFCs. Working Group Summary The WG process was unremarkable; the document has been around and stable for a couple years, and the idea around before that. Document Quality Google, Cloudflare, Apple, and FaceBook have implemented this extension. Firefox has also indicated they intend to prototype it. It should also be noted that others. eg., the EMU WG, are interested in this feature. Personnel Sean Turner is the document shepherd. Ben Kaduk is the responsible Area Director. From nobody Sat Dec 28 16:45:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B191201DB for ; Sat, 28 Dec 2019 16:45:15 -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=FOhyRkVU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=boArJyVb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KysKddQS7BbM for ; Sat, 28 Dec 2019 16:45:13 -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 44D4D120018 for ; Sat, 28 Dec 2019 16:45:13 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 746E241C for ; Sat, 28 Dec 2019 19:45:12 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 28 Dec 2019 19:45:12 -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=+5ax24iiux9cxGx8RyN+NY9HATcEZqCFtGF1O5jtBAk=; b=FOhyRkVU AApiiMm+IIJPg5UfUw8cjkHia2fpIqyBVS81qA8m63IoO/R+zofiaAQZJCGUmXDL k651mEUEactjmYbUj/2zItXnHSUwqmq/bg5Yy8KvskSbw7xGa69j7RC15M0Tl26Y NUD9EXgk3sU9X7VBl5h5jxuSoatotoagkFxV/BmPmpjpLJ0rmcticBtrGn+vtx2Z S86U5TArwA95Y0l4WJsE6hLRArNUuW6gAj9lFNkEX9IamljvnBTEaKCaK1r/J5eT MYDOQPpd4S2cdbrEbvOKRCOXM189iPEefwdoI6rqgWZe/RWOkaUewPC0YsnTA5wI gHHKcCSXjj6/hA== 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=+5ax24iiux9cxGx8RyN+NY9HATcEZ qCFtGF1O5jtBAk=; b=boArJyVbtFmDZPEJ3P3d3mG8mR8IBqy9o1LV1M9I6PG3F Mm3FVfpazwlyxw0mick0eTzsS6X0X3pA70/hvTzfCrX/jpcW8ILhR+QkW1zcxGU9 xR6ryDOt60Isr4Eh0nIs7mSH9UTlLHVIkn6Fouiowf8irU5whrKVFWoVlnPVFpUb Gmu3T+GBzq0KnaoTy980zmOs2vVg5Qti66T1U9mTepYl4rqDQGeGtxs70ovSEKZ7 ioXg/Btf7uTiZlz21z+iRwS6N9Gnzc8NR/gEpKWtDFcrJVR39IIsEcM8H/oP7Xrp im0/mxHfY3lmyUaXMPm/r3a4nEjA6/vCuPcBTy67Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdefuddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusgcupfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeeghedrjeelrdduudefrdduieehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 71E723060910 for ; Sat, 28 Dec 2019 19:45:11 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 7D40D9D377 for ; Sun, 29 Dec 2019 00:45:10 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============5834304221469853168==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191229004510.7D40D9D377@cloud.mnot.net> Date: Sun, 29 Dec 2019 00:45:10 +0000 (UTC) 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, 29 Dec 2019 00:45:16 -0000 --===============5834304221469853168== 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: - Additional data definition is broken (by ekr) https://github.com/tlswg/dtls13-spec/issues/116=20 Pull requests ------------- * tlswg/certificate-compression (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Address comments from the IESG https://github.com/tlswg/certificate-compression/pull/32=20 * tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Reference update (by hannestschofenig) https://github.com/tlswg/dtls13-spec/pull/115=20 Repositories tracked by this digest: ----------------------------------- * 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 --===============5834304221469853168== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday December 29, 2019

Issues

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

1 issues created:

Pull requests

tlswg/certificate-compression (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

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

1 pull requests submitted:

Repositories tracked by this digest:

--===============5834304221469853168==--